Re: Re: A Call For Open Governance Of X Development (Egbert Eich)

Mark Vojkovich wrote:
> On Sat, 22 Mar 2003, Keith Whitwell wrote:
> 
> 
>>Mark Vojkovich wrote:
>>
>>>On Sat, 22 Mar 2003, Keith Whitwell wrote:
>>>
>>>
>>>
>>>>Hmm, I think there's a big difference between a commercial company and an open 
>>>>source project in terms of the skillset required to set the direction for the 
>>>>group.
>>>>
>>>>I'd see the ideal membership of an elected advisory board as being the type of 
>>>>experienced developers who are involved in the current BOD and core team.  In 
>>>>fact, if there ever were an elected board, I don't have any doubt that David 
>>>>Dawes would continue to find himself the leader, and rest of the BOD & core 
>>>>teams as valued members.
>>>
>>>
>>>   I think this depends on who you let vote.  If this vote took 
>>>place on Slashdot you would likely have: ESR, Stallman, Keith Packard,
>>>Jim Gettys and CowboyNeal running the project.  I wouldn't want 
>>>to work for any of these people.
>>>
>>>   One of the problems with voting that is too open is that this
>>>becomes a popularity contest.  I believe that most of the community
>>>doesn't have the knowledge necessary to pick the leadership that
>>>is best for the project - they merely know who they LIKE, and they
>>>haven't had enough experience to know who they can actually TRUST.
>>>Also, they're not the people who have to work under this management.
>>>It's people like myself who have to work under this management.
>>>
>>>   We've already seen an example of someone who thinks the current
>>>management is incompetent because his laptop doesn't work 
>>>correctly.  Who wants that guy voting?
>>>
>>>   Overall, I think your suggestions are good ones, but careful
>>>consideration needs to be given to how we allow people to get
>>>in positions of policy making.  In the current organization, 
>>>voting hasn't really been necessary - senior contributors have
>>>generally come to an easy concensus on what the right thing
>>>to do is, so I'm still trying to figure out what an advisory
>>>board would do.
>>
>>Well the two ideas I have are somewhat circular, so probably can't exist at once:
>>
>>	1) The powers of the advisory board include (but might not be limited to) 
>>granting and revoking cvs privileges.
>>    	
>>	2) The committers get to vote who goes on the board.
> 
> 
>     A less round-about way would be to have the committers chose the
> other committers.
> 
> 
>>Actually by relaxing 2) you get something reasonable:
>>
>>	2b) Everyone who's ever had a patch accepted can vote for the board.
> 
> 
>    That sounds more like a loophole.
> 
> 
>>People who've submitted a oneliner once probably won't be bothered voting, so 
>>I think that potential argument is a straw man.
>>
>>Any system is open to abuse.  If it becomes apparent that abuse is taking 
>>place, it will be necessary to change the system again.
>>
>>Anyway, I agree that careful consideration is required before making changes. 
>>  These ideas are starting points for discussions, not demands or dictats or 
>>whatever...
>>
>>And let me reiterate:  I think the big question is CVS access, a board for me 
>>is secondary, but give it a role managing CVS access and it gains some 
>>concrete relevance.
>>
> 
> 
>    I think committers should be chosen by their peers. 

I'm fine with this concept, but by defining peers as 'other committers', you 
end up with no actual change to the current process.

That could *still* result in change if there was a collective resolve by the 
current group of committers to expand their number.

Otherwise, it's worth pointing out that the non-committing developers are also 
your peers.

> The problem
> with having an advisory committee chose committers is that it lets
> polical interests into the picture (consider an organization trying
> to get a committer installed to speed up integration of their
> patches by circumventing peer review).  It's important to maintain
> a high level of quality in the tree.  In the scheme I've been 
> advocating we're not just adding committers, we are making people
> maintainers.  I think it's a bug that we currently have maintainers
> who don't have commit access.  Also, I don't see why anyone other
> than maintainers needs commit access.  
>
>   It's a natural occurance that sections of the tree start out with 
> one person maintaining a whole branch of it (the DRI for example) 
> and then as it branches out into smaller components like different
> drivers, maintainers for individual drivers are added. 
> It doesn't have to be one maintainer per driver.  You can
> have one maintainer handle two drivers or several people on a
> complicated driver.  The work should be split up as appropriate,
> but in all cases, the people doing the committing should be
> the most competent people for the job.  This is my perception
> of the Linux kernel model.
> 
>    In my opinion, this model delegates tree maintainence while
> maintaining a high level of quality.  It also has some other
> benefits such as making the experts more visible to people
> who have questions, and allows patches to get applied more
> quickly since you can send them directly to the maintainer.
> 
>    If this scheme were adopted, once again the advisory board
> is without a job.  I don't think we should try to fabricate
> a job for an advisory board either.

I hadn't seen you elaborate your scheme in such detail before, and I have to 
say I like it.

I hadn't put much effort into explaining what the expectations of giving 
someone commit access would be, but the above looks pretty good to me.

Keith