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

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.  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.


			Mark.