Well said. I subscribe to this. We should remember that people that contribute so much should be proposed as committers, regardless to the code submitted, as is done AFAIK in POI, Struts, Cocoon, Forrest, Avalon, and the Krysalis projects (that refer to Apache guidelines).
-- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- ----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Jakarta General List" <[EMAIL PROTECTED]> Sent: Sunday, May 26, 2002 6:59 PM Subject: Re: [PROPOSAL] Committer access and responsibilities... > Those who do the work of creating a Jakarta product are entitled to make > the decisions regarding that product. A successful product is more than > code, it also requires documentation and support and easy-to-use > distributions. > > Whether a patch is to the code or the documentation isn't relevant. A > patch is a patch, a contribution is a contribution, and anyone who > makes sustained contributions to a product is elligible to become a > committer. > > A change to the codebase can affect everyone, including them that don't > code but "simply" document. They should have as much to say about the > codebase as everyone else. > > The real point behind meritocracy, I believe, is that we are all equal > and there is no formal hierarchy. It's also a big part of what > makes Jakarta both fun and different from our regular jobs. > > We have a simple and effective system here that's been proven to work. > I don't believe that the formal system is broken or needs to be > refactored. > > -1 on there being shades of gray between contributors and committers. > > A contributor is anyone who has submitted code, documentation or > any other deliverable that has been made part of the product. > Committers do the work of creating the product by posting > contributions to the CVS or other secure area. > > +1 on "non-coders" or "specialists" being voted as committers when > the circumstances warrant. There is nothing to prevent this now > nor should there ever be. If its OK with the other committers to a > product, there's no reason for the rest of us to care. If it's not > OK with the other committers, then it is not the system that's > broken, but the committers -- and no amount of tinkering is going > to fix that. > > -- 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 > > > > Pier Fumagalli wrote: > > > > Chatted with a lot of people, seen many, different development models, went > > around, asked, talked, and I believe I have a pretty decent picture, and > > maybe even a solution... > > > > So the major topic of discussion is that I perceive a substantial difference > > between being able to commit code to a CVS repository, and being a > > "committer" committer, with all dues and responsibilities that this role > > concerns... > > > > For example sometimes someone might want to have commit access just because > > he is working for a company that deals with a particular project in Apache > > (we've seen this happening several times with some projects such as Xerces > > and Tomcat), but he really doesn't care about the whole fuzz of Apache and > > stuff, and once the employment contract ends, the relationship with Apache > > terminates as well (I don't need to enumerate all those examples along those > > lines). > > > > One other example, if we didn't have Henri building RPMs for basically all > > Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, > > don't you think that he would deserve committer status even if he's not tied > > to any particular codebase? We had this "problem" in the current election of > > the members, Sally Khudairi: Sally doesn't code, but she was involved with > > the ASF since before it was even created as a press organizer. Does she > > deserve to be a member of the foundation? Even if she doesn't code? Yes she > > does, IMO (and she was elected and nominated a member today)... > > > > So, IMO, there's a great difference between being a coder, and being a > > member of the Jakarta community, at least in my opinion. There might be > > coders who are not involved with the community, and there might be > > non-coders who are much involved with it, want to participate, are active > > and deserve to be committers... > > > > Our current structure doesn't "allow" that to happen, both things. If you > > need to write code in a particular source-base, and you need CVS access, you > > are automagically made a committer, even if you don't care about much else, > > and if you're very much involved with the overall project, but not tied to > > ANY whatsoever codebase, and really, don't want / can't do it. > > > > So, given this little background, I would like to ask to the PMC, and all > > other committers, if others agree that we should "splitting" the "committer" > > figure in two parts: > > > > - contributor: a contributor is someone who has access to a particular CVS > > tree, but for any reason doesn't want/need to be involved with the whole > > Jakarta community. He just wants to code his little bit and live a long > > life. > > > > - member: is someone who is involved with the Jakarta community, somehow, > > somewhere (might be just giving a great deal in supporting users of our > > projects, or providing extra value to projects, like guidance in respect to > > overall specifications, binary builds). He is effectively a member of the > > community and has all the rights and dues of every member, such as > > participate in the election of the PMC. > > > > And redefining the figure of the "committer" as follows: > > > > - committer: is a contributor, but also a member, therefore he has all the > > privileges and dues of a contributor (having CVS access, and overlooking the > > code he's contributing to) and of a member (can vote for PMCs, should > > participate and contribute to discussions on the overall structure of > > Jakarta). > > > > I believe this makes sense, more sense than what we have now, also because > > we've seen that happening in the ASF for the very first time with a > > non-coding member. Comments please? > > > > Pier > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>