On Jul 12, 2005, at 8:32 PM, Alan D. Cabrera wrote:
Geir Magnusson Jr. wrote, On 7/12/2005 8:43 AM:
On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
All code donations go into
/geronimo/incubator/donationx/*
The contributors would get restricted committer access to their
project; granting committer access gives us better visibility
how well the person works in a community setting. They and,
hopefully Geronimo committers, would whip it into shape. The
community would provide guidance and, hopefully, vote it into
Geronimo once its ready and all the appropriate paper work was
obtained.
The "probationary" committers would, hopefully, get voted into
Geronimo, regardless of their projects status. I have never
heard of a motivated developer not getting committer access.
I'd like to propose a slight modification. That we give them
committer access w/o a formal, restricted ACL, but a clear
understanding that there's a place where they are bring brought in
to work, and if they wish to participate elsewhere, they do so
via standard engagement of working with others, learning about
the area, proposing changes on dev@ etc, until they and others
are comfortable, etc.
Any change can be vetoed, and any change can be rolled back. I
think we should assume a level of trust, and if broken, commit
priv can be revoked.
Just consider for a little while. I believe that this won't be a
popular suggestion, but the risk is small, and the upside great,
it keeps things simple, and I believe leads to a more unified,
richer community. :)
I don't think that the extended privs would necessarily lead to "a
more unified, richer community" but would, instead, increase the
burden on those Geronimo committers charged with monitoring the
contribution under probation.
Let me elaborate - the burden is the same. We are responsible for
the entire codebase. Whether or not the new committers have an ACL
that lets the write to modules/kernel doesn't remove our
responsibility for the new code that was brought in.
I can picture a process where there is no probation. We'd be saying
that the contribution of the code is, to the PMC, reasonable
demonstration of commitment (this is a judgement we'd have to make
each and every time for every offered contribution), and that we are
willing to trust that they'll work on that contribution in a "good
way" with us. For the other parts of the Geronimo codebase, we ask
that they never just go jumping into anything, but work with the
other committers to be sure that they are working in a way compatible
with the existing community.
Anyone who violates that trust that we offered will have committer
privs revoked. Anyone who respects the trust offered will naturally
blend into the rest of the committer community.
Any bad code change can be vetoed (and I think that we must become
more comfortable with vetoing and more comfortable as accepting it in
a non-personal, technical manner...)
I think that this is the cleanest, simplest and most elegant way.
OTOH, I do recognize that there's a large element of trust as well as
a real lack of exposure and experience with the new people we'd be
bringing in. OTOOH, there are no guarantees in life :)
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
