Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 88681 invoked from network); 24 May 2002 23:05:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 24 May 2002 23:05:12 -0000 Received: (qmail 652 invoked by uid 97); 24 May 2002 23:05:04 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 596 invoked by uid 97); 24 May 2002 23:05:03 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 572 invoked by uid 98); 24 May 2002 23:05:02 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Sat, 25 May 2002 00:06:58 +0100 Subject: [PROPOSAL] Committer access and responsibilities... From: Pier Fumagalli To: Jakarta General List , Tomcat Developers List Message-ID: Mime-version: 1.0 Organization: Betaversion Productions Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: