Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[hasufell <hasufell@gentoo.org>]

Rich Freeman:
> On Mon, Dec 29, 2014 at 2:34 PM, hasufell <hasufell@gentoo.org> wrote:
>> Anthony G. Basile:
>>>
>>> I'd like to add a discussion on glep 39.  In particular, under
>>> specifications we have:
>>>
>>> "It may have one or many leads, and the leads are selected by the
>>> members of the project. This selection must occur at least once every 12
>>> months, and may occur at any time."
>>>
>>
>> That requirement imposes a specific structure on projects. There are
>> ways to have a functional project without any lead.
>>
>> So that phrase should be removed altogether.
>>
> 
> I think we need to step back and think about why we have projects.
> The whole point of projects is to have something in-between the
> Council and anything-goes.  So, if you want to know whether doing xyz
> is acceptable for Python modules, you can ask the Python project.  If
> you REALLY disagree you can then complain to the Council, but they're
> probably going to just side with the Python project since that is the
> whole reason for having a Python project.
> 
> Well, since projects are inanimate concepts you can't actually ask
> them questions - you need people to talk for them.  So, if 3 people on
> the Python project say one thing, and 3 others say something else,
> then what IS the opinion of the Python project?  To settle that we
> have project leads.
> 

No, you don't need a project lead. You can just say any member can speak
for the whole project at any time. Whether that works or not, is a
different thing, but it's a valid model.
Decisions can be reached by whatever method you want, with or without a
lead.

What matters is that the project is _functional_ and _responsive_. How
they do that should be up to the and should not be specified anywhere.

> I think that some of what sparked this question is that some projects
> are fairly non-responsive, and devs don't feel at liberty to make
> commits to packages under the authority of that project.  IMHO the
> simplest solution here is to tell people to just announce their
> changes and go ahead and make them if there are no objections.  The
> onus has to be on the person blocking change to prevent it, unless we
> want to fossilize.  Of course, anybody can always go to the Council
> for help, but the point isn't to micromanage every little decision
> anybody wants to make.
> 

Yeah, that's your diplomatic approach, but it doesn't work.