> > + some mailing list management software + some product release software) it > > would be very beneficial to push the administration down onto project "leads" > > So we'll also have 'project leads' ? > > And some people who write and maintain code, but have different rights ?
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]>
