Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12

[Rich Freeman <rich@thefreemanclan.net>]

On Thu, Jul 31, 2014 at 7:49 AM, hasufell <hasufell@gentoo.org> wrote:
> Rich Freeman:
>>
>> Some options open to the council are:
>> 1.  Let the games project keep its policy, and anybody who wants to
>> change this has to join the project and call for elections (the
>> council can shoe-horn members onto the project if necessary).
>
> You want to force-push members into a team while "preserving" the old
> structure? That calls for trouble.

I'm just saying it is one possible option, so don't get carried away
with the "you."  It was actually my first preference though, and it
looks like others would prefer this as well.

It isn't about force-pushing.  Gentoo projects are generally supposed
to be open-access (with the exception of QA, Comrel, and Infra), so if
people want to join they should be able to do so unless there is a
good reason to exclude them.

Likewise, teams are supposed to elect leads annually.

So, this is just about removing bureaucratic roadblocks for people who
want to join the games project.  The majority can then set policy as
they see fit, which is basically the process in GLEP 39.  Project
leads not responding to requests to join is an abnormality.

However, I don't exactly see people lining up to join the games
project, so this is a bit of a moot point.

>
>> 2.  Directly tweak games policy but preserve the project and its
>> scope.  So, games would still have to adhere to games project policy,
>> but the Council might change specific policies (use of eclass, group,
>> etc).
>
> That's contradictory, IMO. You are practically telling the games team
> "your policies suck, so we just changed them". That doesn't really mean
> they preserve their scope.

To clarify - by scope I meant preserving their claim on any game in
the tree.  So, with this option all games have to still follow games
project policy, but those policies would be directly tweaked by the
Council.

I don't like this option either - I was just trying to spark
discussion and include potential options.

>> 3.  Restrict the games project scope, such as giving it authority if
>> the package maintainer elects to put it in the games herd.
>
> This calls for trouble as well and will cause massive inconsistency.

It certainly has that potential.  However, part of GLEP 39 is that
projects are allowed to compete, and inconsistent treatment of
/usr/games or the games group isn't half as confusing as multiple udev
implementations, sysvinit, package managers, and so on.

I think it is an option worth considering.  I wouldn't call it my
favorite option though.

>
> 5. Have undertakers check for slacking project leads and accept related
> complaints. If a project has a slacking lead, then the project should be
> given a (long) deadline to fix it. If they don't fix it, then they
> should be disbanded. A project cannot function properly without an
> active lead (unless the project structure defines that there is no lead
> anyway).
>

So, this is basically a variation on #1, but I'd rather see people
joining a project and breathing life into it rather than projects
simply being disbanded entirely.

That said, if NOBODY was on the games project and its policies were in
the way then disbanding it would be an option.  That really isn't the
case - there are active devs on the games project - they're just not
following GLEP 39 by holding elections and generally being accepting
of members.

I realize this isn't really adding anything much - I really just
wanted to clarify my meaning with the various options and generally
spark feedback.

Rich