Gentoo Archives: gentoo-project

From: Rich Freeman <rich@××××××××××××××.net>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12
Date: Fri, 01 Aug 2014 00:29:30
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12 by hasufell
1 On Thu, Jul 31, 2014 at 7:49 AM, hasufell <hasufell@g.o> wrote:
2 > Rich Freeman:
3 >>
4 >> Some options open to the council are:
5 >> 1. Let the games project keep its policy, and anybody who wants to
6 >> change this has to join the project and call for elections (the
7 >> council can shoe-horn members onto the project if necessary).
8 >
9 > You want to force-push members into a team while "preserving" the old
10 > structure? That calls for trouble.
12 I'm just saying it is one possible option, so don't get carried away
13 with the "you." It was actually my first preference though, and it
14 looks like others would prefer this as well.
16 It isn't about force-pushing. Gentoo projects are generally supposed
17 to be open-access (with the exception of QA, Comrel, and Infra), so if
18 people want to join they should be able to do so unless there is a
19 good reason to exclude them.
21 Likewise, teams are supposed to elect leads annually.
23 So, this is just about removing bureaucratic roadblocks for people who
24 want to join the games project. The majority can then set policy as
25 they see fit, which is basically the process in GLEP 39. Project
26 leads not responding to requests to join is an abnormality.
28 However, I don't exactly see people lining up to join the games
29 project, so this is a bit of a moot point.
31 >
32 >> 2. Directly tweak games policy but preserve the project and its
33 >> scope. So, games would still have to adhere to games project policy,
34 >> but the Council might change specific policies (use of eclass, group,
35 >> etc).
36 >
37 > That's contradictory, IMO. You are practically telling the games team
38 > "your policies suck, so we just changed them". That doesn't really mean
39 > they preserve their scope.
41 To clarify - by scope I meant preserving their claim on any game in
42 the tree. So, with this option all games have to still follow games
43 project policy, but those policies would be directly tweaked by the
44 Council.
46 I don't like this option either - I was just trying to spark
47 discussion and include potential options.
49 >> 3. Restrict the games project scope, such as giving it authority if
50 >> the package maintainer elects to put it in the games herd.
51 >
52 > This calls for trouble as well and will cause massive inconsistency.
54 It certainly has that potential. However, part of GLEP 39 is that
55 projects are allowed to compete, and inconsistent treatment of
56 /usr/games or the games group isn't half as confusing as multiple udev
57 implementations, sysvinit, package managers, and so on.
59 I think it is an option worth considering. I wouldn't call it my
60 favorite option though.
62 >
63 > 5. Have undertakers check for slacking project leads and accept related
64 > complaints. If a project has a slacking lead, then the project should be
65 > given a (long) deadline to fix it. If they don't fix it, then they
66 > should be disbanded. A project cannot function properly without an
67 > active lead (unless the project structure defines that there is no lead
68 > anyway).
69 >
71 So, this is basically a variation on #1, but I'd rather see people
72 joining a project and breathing life into it rather than projects
73 simply being disbanded entirely.
75 That said, if NOBODY was on the games project and its policies were in
76 the way then disbanding it would be an option. That really isn't the
77 case - there are active devs on the games project - they're just not
78 following GLEP 39 by holding elections and generally being accepting
79 of members.
81 I realize this isn't really adding anything much - I really just
82 wanted to clarify my meaning with the various options and generally
83 spark feedback.
85 Rich