I think the real point is that while, given the chance, some people may prefer to do one thing or another, as Committers we all can potentially do anything that needs to be done whenever we have time to do it.
Since this is a volunteer organization, and we all have other pressing responsibilities, it is important that we do not encourage any systemic bottlenecks. If the Committer who likes to do the releases can't, someone else can just step up to bat without any hoopla. A committer is a committer .. from each according to their abilities, to each according to their needs. Regardless of what we choose to do from time to time, the codebase is our joint responsiblity. And when we drift away, someone else will step into our shoes. When we are gone, another committer may elect to do what we used to do, or a new contributor may fill the void and then be nominated as the product's newest Committer. The real problem I would have with non-voting Committers is that comitting is an important way of how we vote. Because we are all responsible for the entire codebase, jointly and severally, we don't have to vote on every little thing. We can vote through our commits -- unless and until another Committer points out an error in our judgment. Since committing is voting, what I think what some people want is a non-vetoing Committer. Someone to do the work without sharing in the responsibility. Which is to say, we can reject what they do, but they can't reject what we do. Personally, I would find that type of master/slave relationship difficult to maintain in a volunteer organization like this. If you are working hard enough to need commit rights, you are working hard enough to have veto rights. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Leo Simons wrote: > we have, in practice, in quite a few of the subprojects. The "in > practice" part in that sentence explains the quotes around "leads". > > We have a nice theoretical meritocracy model defining several "roles and > responsibilities". That's just fine. The current model defines "user", > "developer", "committer" and "pmc member". > > In real life, there's more roles, overlapping roles, more specific > roles, less specific roles. > > Examples: with Avalon, Peter and Berin handle most of our releases; they > assume the role of "release manager". Jeff Turner's been working on the > build process; he had the cap of "build process manager", now passed > over to Nicola Ken, all informally. > > Fortunately, this is all okay and no-one complains. Like Ted said, we're > pragmatic about it. > > Thing is, formal roles and responsibilities currently are > (as per http://jakarta.apache.org/site/roles.html): > > user: no rights, no responsibilities > developer: right to get quoted as author for authored pieces, no > responsibility > committer: right to vote as per voting guidelines, responsibility to > sign and submit Contributor License Agreement > pmc member: right and obligation to set overall project direction > > when these no longer reflect the ad hoc pragmatic roles defined within > subprojects, or when they make using these pragmatic "roles" difficult, > we should think about changing these definitions, roles and > responsibilities. > > Fact of the matter is, the model is not perfect, and not everyone in our > community fits into these categories very well. Saying that everyone who > submits a patch is a developer is a bit of a strange definition, as you > don't really "develop" documentation, etc etc etc. > > Pier brings this up, perhaps in a somewhat clumsy way, but with a valid > point and valid arguments: voila, heated discussion and comments on a > personal note. > > "if it ain't broken, don't fix it" leads to things like windows. We'd > still be forced to work with AWT and JSP. > > - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
