On Jul 27, 2006, at 9:53 AM, ant elder wrote:
One of the reasons I started this thread was to try to get a common
understanding about what everyone expects is required to become a
Tuscany
committer. Its hard to publicly say you think someone isn't ready
yet, even
on the private list, so a common understanding would mean
nominations would
more likely get unanimous approval. If a nomination is being
discussed on
the private list how do we know when its ok to call a public vote
on the dev
list? Are just a few positive responses enough? Are lots of positive
responses required? Or just no negative ones? Or does there need to
be at
least positive responses from all the committers active in that
area? I
think maybe the latter of those for now while there's still not so
many of
us, but what do others think?
As Jeremy mentioned previously, it is a question of trust and hence
subjective.
That said, for me, I don't have a "personal point system" (or take
bribes ;-) ) but I do try and follow some guidelines. For example, I
generally group committers into two broad categories, those that earn
it through substantial code contributions and those that have earned
it through smaller but still important contributions (not necessarily
code) over a longer period of time. To take an example, Dan Kulp fit
in the former category, as he contributed a Celtix binding, cleaned
up the existing code base (at the time) to use Java 5 properly,
helped with the build system, and was active on the mailing lists.
Had he not contributed the binding, and instead focused on the Java 5
refactorings, I would have waited longer to see more contributions
along those lines. That said, I don't think that anyone who
contributes a binding "automatically" qualifies for committer status.
Again, because it is about trust, I would want to make sure the code
quality meets our standards, the potential committer aligns with our
goals as a community, and they are committed to ongoing
participation. What we should avoid are people who do "drive-by" code
drops and move on to the next project when they get bored.
I also see a longer-term path to gaining commit rights as well. This
may or may not involve code contributions. In terms of code
contributions, someone could submit patches, refactorings, test
cases, etc. over an extended period of time. In non-code cases, I
think someone could become a committer that never produces a single
line of code, since there are other forms of tangible contribution.
For example, someone could write a ton of documentation or do a lot
of things for the community. For me, though, the timeframe is
generally much longer for non-code contributions and the quality of
the contribution has to be high.
In terms of the specific questions related to when a vote should be
called, my criteria would be:
1. The "sponsoring" committer is willing and able to mentor the new
committer
2. I would say we need to have a significant number of committers in
the area the prospective committer intends to work give +1s. By area,
the level of granularity would be "Java SCA", "C++ SCA", "Java SDO",
DAS, etc. For example, I don't always feel comfortable dealing with
cases in the C++ arena as I am not involved in that part of the
project to be able to make a fair judgement in most cases. Of course,
there may be times when it is patently obvious someone has earned the
right, in which case I would +1 it. I also don't think we need
everyone to respond as people may be on vacation or not available,
but the majority should be "substantial".
3. If there is a negative response, I think we follow the process of
reaching consensus before nominating someone on the public list.
Jim
...ant
On 7/6/06, Jeremy Boynes < [EMAIL PROTECTED]> wrote:
On Jul 5, 2006, at 4:42 PM, Raymond Feng wrote:
> Hi,
>
> I guess I can understand how to get credits for the "committer"
> status.
>
> As a contributor, I would like to see a well-defined measurable
> path which I can see how I make progresses toward the goal. It
> leads two questions:
>
> 1) How many points do we need to gain to become a committer?
> 2) How do we measure the contributions? Is it just an impression or
> sense from existing committers or do we run some statistics once a
> while?
>
It's about trust so hard-facts don't tell all the story - it really
is about what the existing committers think.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]