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

Reply via email to