On 02/06/2012 01:41 AM, Marvin Humphrey wrote:
On Sun, Feb 05, 2012 at 01:26:47PM -0600, William A. Rowe Jr. wrote:
It might be worthwhile to require 3 ASF members on the initial release,
2 on the next, 1 on the following and then trust the committee to follow
the established precedent.

+1

Instead of automatically decreasing the count, the device I'd suggest is for
the ASF Members on the committee to vote to grant binding votes to individual
contributors who they believe have demonstrated a thorough understanding of
the Apache Way.

Release Managers would be prime candidates; given the challenge of getting an
incubating release out the door, an RM will likely have acquired greater
expertise than many ASF PMC members who have been voted directly into TLP
PMCs.  Just being an RM might not be enough, but it would be left to the
judgment of the ASF Members / Mentors to vet and vote on candidates.

The canonical path towards project autonomy would thus be to make three
incubating releases with three different contributors serving as RM.

What worries me a lot about the recent proposals, not only the text above, is that project autonomy seems to be measured foremost by just doing proper releases.

To me, Apache == Community over code.

Code is important, it is what we are all here for (too), but the 'Apache Way' and especially community development and a healthy diversity IMO are even more critical. And especially for reaching project autonomy: *that* IMO is what the Incubator is (or should be) about.

Learning the 'tricks' and reasons of doing proper releases isn't easy, and for sure required. But a 'perfect' RM doesn't automatically make a 'perfect' Apache TLP PMC member in my book. Which has been discussed quite a lot as well last week.

The thing I'm worried about with the 'radical/revolutionary proposals of creating Incubator projects as TLPs from the start, is that they they also start 'on their own', even with 3 Mentors on board. Meaning: there is no 'glue' or common community between individual 'incubator' TLPs anymore which can help them, with the help of (many more) experienced IPMC members, as well as fellow Incubator PPMC members, to learn the ropes.
Beyond merely doing proper releases.

I fully agree the current Incubator has its issues, but radically killing it off IMO will also kill off more than just those issues: it will also kill the Incubator community itself. Maybe ComDev can or actually then will have to take over, but we should be really careful before breaking something down without having a replacement 'safety net' in place.

Ate


This mechanism incentivizes the following healthy habits:

   * Release early, release often.
   * Share crucial responsibilities and disperse knowledge amongst multiple
     contributors.
   * Learn ASF documentation and relevant legal issues (thoroughly enough to
     pass muster in the eyes of the ASF Members / Mentors).

I don't worry too much that promoting individuals one-at-a-time will create a
class of pseudo-BDFL contributors who are "more equal" than others.  Every
project is going to have people who contribute disproportionally; what we
want is for those people to do less coding and more community building and
small-m mentoring.

projects should earn incremental trust and authority.

+1 for incremental increases in autonomy.

+1 for making it clear that the increased autonomy is *earned*.

We want newcomers to internalize ASF values.  We want them to understand both
how much we care about doing things the way we do and why.

We also have oversight responsibilities that it would be best if we
relinquished progressively.

Marvin Humphrey


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to