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. |
11 |
|
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. |
15 |
|
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. |
20 |
|
21 |
Likewise, teams are supposed to elect leads annually. |
22 |
|
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. |
27 |
|
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. |
30 |
|
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. |
40 |
|
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. |
45 |
|
46 |
I don't like this option either - I was just trying to spark |
47 |
discussion and include potential options. |
48 |
|
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. |
53 |
|
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. |
58 |
|
59 |
I think it is an option worth considering. I wouldn't call it my |
60 |
favorite option though. |
61 |
|
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 |
> |
70 |
|
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. |
74 |
|
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. |
80 |
|
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. |
84 |
|
85 |
Rich |