Re: Earned autonomy
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
Re: Earned autonomy
On Sun, Feb 5, 2012 at 5:33 PM, Ate Douma wrote: > 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. > > Agreed that we need to have supervision on the initial phase, and that some type of gradual phasing is required before they can handle the releases by themselves. > 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. > Code and Releases are things that the Foundation might have legal liability, that's why I have some concerns about leaving it without any supervision. I also agreed with your point about community, and I think this is the place where ComDev would get pluged in. > 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 > > Yes, moving from one "Incubator" to "ComDev" will not really fix all the issues... but it seems that consensus is being built on this direction. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Earned autonomy
On Feb 5, 2012, at 8:00 PM, Luciano Resende wrote: > On Sun, Feb 5, 2012 at 5:33 PM, Ate Douma wrote: >> >> >> 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 >> >> > > Yes, moving from one "Incubator" to "ComDev" will not really fix all > the issues... but it seems that consensus is being built on this > direction. I don't agree that consensus is being built on that direction or any other. At this point I only see consensus on giving podlings more autonomy and authority. The disagreement seems to be that some want podlings to essentially be a TLP from the beginning while others prefer transitioning them from podling to TLP but faster than happens today. FWIW, I'm in complete agreement with Jim's message from early this morning which i read as effectively saying, the IPMC should not be worrying so much about how podlings are doing but about how mentors are doing. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Earned autonomy
On 6 February 2012 01:33, Ate Douma wrote: > 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. +1000 (I fully support everything Ate says here and I will further observe that I have learned much about mentoring from Ate). Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Earned autonomy
Hi, Ate, On Mon, Feb 06, 2012 at 02:33:11AM +0100, Ate Douma wrote: > 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. The case I have been trying to make is that there are community benefits when a podling is allowed to earn progressively increasing autonomy over its releases. For what it's worth, the poor state of the Incubator release system has had negative impact on our podling's ability to recruit and retain new contributors. When you're accustomed to the instantaneous gratification of releasing to Github, CPAN, or RubyGems.org, coming into the Incubator and seeing that it is routine for release candidates to be delayed for *weeks* awaiting three IPMC votes is shocking. If you were trying to pick which open source project to spend your time on, why would you want to stick around an organization that has so much trouble getting its act together? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Earned autonomy
On Feb 6, 2012, at 8:23 AM, Marvin Humphrey wrote: Hi, Ate, On Mon, Feb 06, 2012 at 02:33:11AM +0100, Ate Douma wrote: 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. The case I have been trying to make is that there are community benefits when a podling is allowed to earn progressively increasing autonomy over its releases. To me, this increasing autonomy can be handled today if the Mentors step up. The first release should be vetted by each of the three Mentors, before it even gets to the full IPMC membership. If the Mentors do the minimum of checking signatures, looking over the RAT report, they can then rely on the PPMC members to technically vet the release. And the second time around, reviewing a release should take even less time. And once the Mentors have confidence in the ability of the PPMC members to properly review, they can choose to vote +1 on a release with confidence that the release satisfies the requirements. Thus, a Mentor can give more autonomy simply by voting. For what it's worth, the poor state of the Incubator release system has had negative impact on our podling's ability to recruit and retain new contributors. When you're accustomed to the instantaneous gratification of releasing to Github, CPAN, or RubyGems.org, coming into the Incubator and seeing that it is routine for release candidates to be delayed for *weeks* awaiting three IPMC votes is shocking. The delay is shocking. Why can't the Mentors check signatures and review RAT? There is no requirement by the incubator that a release actually do anything useful. So to sign off on a release should be a 30 minute task. We know that Mentors need to pay attention to the community interactions, which is where I expect most of their time to be spent. Reviewing a release for proper licensing and signatures should be a tiny part of the job. Craig If you were trying to pick which open source project to spend your time on, why would you want to stick around an organization that has so much trouble getting its act together? 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
