Re: an experiment
On Wed, Aug 11, 2010 at 19:24, Joe Schaefer wrote: >> From: Davanum Srinivas >> To: general@incubator.apache.org >> Sent: Wed, August 11, 2010 6:28:17 PM >> Subject: Re: an experiment >> >> Ant, >> >> My personal opinion (and i am hoping!) was that such individuals >> from ppmc's who end up in ipmc would help build bridges >> between podlings and will help get lessons learned (when any ppmc >> has issues/problems/roadblocks) back to their ppmc. >> This is one area where i've seen people struggle, folks from >> different projects learning the same lessons the hard way. > > Good point. Yup. Goodness. >> I am not too worried about "binding" vote one podling ppmc >> member have over another podling's release. the "binding" is >> for me a legal thing (as in we need 3 binding ipmc votes for a release). > > I think ant is more concerned about graduation votes. We > could simply write a new rule that podling committers on > the IPMC brought in through my initiative MUST ABSTAIN from > graduation votes. I don't think the board would be the > least bit upset if we did that. Nah. Don't impose more rules. In Subversion, we vote in committers and we tell them "only commit to /some/path". And they do that. We don't need technical measures. We simply *ask*. Let new IPMC members know that they should be wary of voting on issues outside of their "domain of expertise." If they *do* vote, then let them. If they are out of line, then let them discuss why they voted/thought that way. It can be a learning exercise. Maybe they'll change their vote. If you find somebody that just never "gets it" and is "obstructionist", *then* you can deal with it. Be optimistic and give them rights. What is the true failure mode here? What is the full exposure? Is it really a problem? Is it such a problem that rules are required? [beyond simple social requests] Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Thu, Aug 12, 2010 at 1:45 AM, Joe Schaefer wrote: > The first idea should be fairly straightforward: that for > the projects I participate in (so far thrift and sis), that > the IPMC delegates to the PPMC the decision-making process > for voting in new committers: basically rolling back the clock > to May 1, 2007 on guides/ppmc.html. Please refrain from that phrase; since it is debatable what was the actual policy previously. I am +1 to the suggestion that Thrift and Sis are empowered to be self-governing in respect to committers. I am even positive to do this across all podlings, if roo@ is ok with it. > The second idea is more controversial: to hold IPMC votes to > admit all significant committers to those projects to the IPMC > itself. The purpose of this concept is to allow those who > best know the codebase to provide IPMC oversight over it, > especially as it pertains to releases. Yes, definitely more controversial. Pros would include greater exposure to the Incubator noise, learning from others, becoming part of Apache for real. The main cons is that doesn't happen and instead we have podlings inadvertently becomes even more isolated islands, as they no longer required to get others involved at all. Let's try this with Thrift and Sis, as Thrift is always quoted as a troubled community, no releases and so forth. If it will work for that podling, I am convinced. If it doesn't work for either, then I think we need some other mechanism. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On 2010-08-11, Joe Schaefer wrote: > From: Davanum Srinivas >> +1 to IPMC delegates to the PPMC the decision-making process for >> voting in new committers (one question, would they need an ACK from >> IPMC - similar to how PMC's send a note to the board for an ACK for >> new pmc members)? > That certainly sounds like a reasonable thing to do, sure. +1 >> In the 2nd question, "significant committers", are we asking >> mentors to identify such candidates for addition to IPMC, >> especially release managers for example? if so, +1 for that >> as well. > Absolutely, especially RM's that have gotten into the habit > of running RAT themselves. There isn't anything that would stop a mentor from proposing a podling committer who is not an ASF member as an IPMC member today, is there? I'd expect you'd get the required votes for people who have been RMs or contributed "significantly" from enough other IPMC members. Stefan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
>> >> +1 to IPMC delegates to the PPMC the decision-making >> >> process for voting in new committers (one question, >> >> would they need an ACK from IPMC - similar to how PMC's >> >> send a note to the board for an ACK for new pmc members)? >> > >> > That certainly sounds like a reasonable thing to do, sure. +1 >> >> In the 2nd question, "significant committers", are we asking >> >> mentors to identify such candidates for addition to IPMC, >> >> especially release managers for example? if so, +1 for that >> >> as well. >> >> I was also curious as to the mechanism for determining >> "significance"--I would be satisfied with mentors' >> recommendation as outlined by dims. > > By significant I mean active and clueful participants > in the project. > >> I wonder if there should be some limit/function >> to determine the number of non-Member representatives >> a given podling may have on the IPMC. > > I don't care for artificial limits. Trust has a way > of maintaining its own balance. > +1 Both ideas sound very good to me Christian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message > From: Matt Benson > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 5:19:53 PM > Subject: Re: an experiment > > > On Aug 11, 2010, at 4:14 PM, Joe Schaefer wrote: > > > > > > > - Original Message > > > >> From: Davanum Srinivas > >> To: general@incubator.apache.org > >> Sent: Wed, August 11, 2010 5:07:33 PM > >> Subject: Re: an experiment > >> > >> +1 to IPMC delegates to the PPMC the decision-making > >> process for voting in new committers (one question, > >> would they need an ACK from IPMC - similar to how PMC's > >> send a note to the board for an ACK for new pmc members)? > > > > That certainly sounds like a reasonable thing to do, sure. > > > > +1 > > >> In the 2nd question, "significant committers", are we asking > >> mentors to identify such candidates for addition to IPMC, > >> especially release managers for example? if so, +1 for that > >> as well. > > > > I was also curious as to the mechanism for determining > "significance"--I would be satisfied with mentors' > recommendation as outlined by dims. By significant I mean active and clueful participants in the project. IOW people who have earned the trust of the project mentors. It would be an evolving process for a new project: at first nobody would meet that description, but over time as the mentors got to know the participants and see how they work, collaborate, review, and critique releases, we'd gain their trust and offer them up to an IPMC vote for inclusion. > I wonder if there should be some limit/function > to determine the number of non-Member representatives > a given podling may have on the IPMC. I don't care for artificial limits. Trust has a way of maintaining its own balance. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message > From: Joe Schaefer > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 8:14:26 PM > Subject: Re: an experiment > > - Original Message > > > From: Davanum Srinivas > > To: general@incubator.apache.org > > Sent: Wed, August 11, 2010 8:07:50 PM > > Subject: Re: an experiment > > > > Joe, > > > > Can they not +1 it either? :) seriously, it would be a > > bit hard to track 2 levels of ipmc members > > If we're concerned about tracking, we could simplify the > rule to say only ASF members on the IPMC may participate > in graduation voting. Otherwise publishing a list of > podling committers on the IPMC would probably be required, > which I'd like to avoid as well ;-). FWIW I just checked that only one person, James Holmes, would have his graduation voting rights rescinded if we followed this recommendation. Everyone else currently on the IPMC is an ASF member. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] NPanday to enter the incubator
On Wed, Aug 11, 2010 at 8:31 PM, Brett Porter wrote: >> We have finalised the proposal with the additional committer and it has now >> been posted for a couple of weeks, so I'd like to put it to a vote. ... > Obviously +1 from me. > > Would anybody else like to weigh in? Who, me? +1 :) -- Wendy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] NPanday to enter the incubator
> -Original Message- > From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett > Porter > Sent: Thursday, 12 August 2010 10:31 AM > To: general@incubator.apache.org > Subject: Re: [VOTE] NPanday to enter the incubator > > > > On 07/08/2010, at 1:21 AM, Brett Porter wrote: > > > Hi, > > > > We have finalised the proposal with the additional committer and it > has now been posted for a couple of weeks, so I'd like to put it to a > vote. > > > > With the weekend included, I'll tally the votes after 5 days (120 > hours). > > > > Obviously +1 from me. > > Would anybody else like to weigh in? ooh ooh is that my que, am I on ? Seriously, +1 Gav... > > Cheers, > Brett > > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > > > > - > 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: [VOTE] NPanday to enter the incubator
On 07/08/2010, at 1:21 AM, Brett Porter wrote: > Hi, > > We have finalised the proposal with the additional committer and it has now > been posted for a couple of weeks, so I'd like to put it to a vote. > > With the weekend included, I'll tally the votes after 5 days (120 hours). > Obviously +1 from me. Would anybody else like to weigh in? Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message > From: Davanum Srinivas > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 8:07:50 PM > Subject: Re: an experiment > > Joe, > > Can they not +1 it either? :) seriously, it would be a > bit hard to track 2 levels of ipmc members If we're concerned about tracking, we could simplify the rule to say only ASF members on the IPMC may participate in graduation voting. Otherwise publishing a list of podling committers on the IPMC would probably be required, which I'd like to avoid as well ;-). > > -- dims > > > > On 08/11/2010 07:24 PM, Joe Schaefer wrote: > > - Original Message > > > >> From: Davanum Srinivas > >> To: general@incubator.apache.org > >> Sent: Wed, August 11, 2010 6:28:17 PM > >> Subject: Re: an experiment > >> > >> Ant, > >> > >> My personal opinion (and i am hoping!) was that such individuals > >> from ppmc's who end up in ipmc would help build bridges > >> between podlings and will help get lessons learned (when any ppmc > >> has issues/problems/roadblocks) back to their ppmc. > >> This is one area where i've seen people struggle, folks from > >> different projects learning the same lessons the hard way. > > > > Good point. > > > >> I am not too worried about "binding" vote one podling ppmc > >> member have over another podling's release. the "binding" is > >> for me a legal thing (as in we need 3 binding ipmc votes for a release). > > > > I think ant is more concerned about graduation votes. We > > could simply write a new rule that podling committers on > > the IPMC brought in through my initiative MUST ABSTAIN from > > graduation votes. I don't think the board would be the > > least bit upset if we did that. > > > > > > > > > > - > > 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 > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
Joe, Can they not +1 it either? :) seriously, it would be a bit hard to track 2 levels of ipmc members -- dims On 08/11/2010 07:24 PM, Joe Schaefer wrote: - Original Message From: Davanum Srinivas To: general@incubator.apache.org Sent: Wed, August 11, 2010 6:28:17 PM Subject: Re: an experiment Ant, My personal opinion (and i am hoping!) was that such individuals from ppmc's who end up in ipmc would help build bridges between podlings and will help get lessons learned (when any ppmc has issues/problems/roadblocks) back to their ppmc. This is one area where i've seen people struggle, folks from different projects learning the same lessons the hard way. Good point. I am not too worried about "binding" vote one podling ppmc member have over another podling's release. the "binding" is for me a legal thing (as in we need 3 binding ipmc votes for a release). I think ant is more concerned about graduation votes. We could simply write a new rule that podling committers on the IPMC brought in through my initiative MUST ABSTAIN from graduation votes. I don't think the board would be the least bit upset if we did that. - 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: an experiment
On Wed, Aug 11, 2010 at 10:49 AM, Mattmann, Chris A (388J) wrote: > Hi Joe, > >> The first idea should be fairly straightforward: that for >> the projects I participate in (so far thrift and sis), that >> the IPMC delegates to the PPMC the decision-making process >> for voting in new committers: basically rolling back the clock >> to May 1, 2007 on guides/ppmc.html. > > +1 from me, and I'd like to OODT to that experimental list as well :) It > would probably make sense for Lucy too, but we're in our nascence there (not > that it should matter). +1 to trying this out in OODT as well. =P As far as the ACK process, I'd be okay with an after-the-vote ACK (a la what the Board does with PMC members), but the goofy "pre-vote" ACK is what got us in OODT-land taken out to the woodshed by the IPMC. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message > From: Davanum Srinivas > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 6:28:17 PM > Subject: Re: an experiment > > Ant, > > My personal opinion (and i am hoping!) was that such individuals > from ppmc's who end up in ipmc would help build bridges > between podlings and will help get lessons learned (when any ppmc > has issues/problems/roadblocks) back to their ppmc. > This is one area where i've seen people struggle, folks from > different projects learning the same lessons the hard way. Good point. > I am not too worried about "binding" vote one podling ppmc > member have over another podling's release. the "binding" is > for me a legal thing (as in we need 3 binding ipmc votes for a release). I think ant is more concerned about graduation votes. We could simply write a new rule that podling committers on the IPMC brought in through my initiative MUST ABSTAIN from graduation votes. I don't think the board would be the least bit upset if we did that. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
Ant, My personal opinion (and i am hoping!) was that such individuals from ppmc's who end up in ipmc would help build bridges between podlings and will help get lessons learned (when any ppmc has issues/problems/roadblocks) back to their ppmc. This is one area where i've seen people struggle, folks from different projects learning the same lessons the hard way. I am not too worried about "binding" vote one podling ppmc member have over another podling's release. the "binding" is for me a legal thing (as in we need 3 binding ipmc votes for a release). -- dims On 08/11/2010 06:16 PM, ant elder wrote: On Wed, Aug 11, 2010 at 6:45 PM, Joe Schaefer wrote: The second idea is more controversial: to hold IPMC votes to admit all significant committers to those projects to the IPMC itself. The purpose of this concept is to allow those who best know the codebase to provide IPMC oversight over it, especially as it pertains to releases. Without some more explanation I'm not that convinced about doing that. The main purpose of the IPMC is to vote on the graduation of poddlings, why should some random ASF poddling newbie get a binding vote on the graduation of _any_ poddling? I'm guessing the motivation for this proposal is not to give poddling committers binding votes on other poddling graduations but to give them binding votes on their own poddling activities, and that i agree with. The things they need binding votes on is their committer votes, ppmc votes (they already have that), and release votes - lets just give them those. ...ant - 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: an experiment
- Original Message > From: ant elder > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 6:16:16 PM > Subject: Re: an experiment > > On Wed, Aug 11, 2010 at 6:45 PM, Joe Schaefer wrote: > > > > The second idea is more controversial: to hold IPMC votes to > > admit all significant committers to those projects to the IPMC > > itself. The purpose of this concept is to allow those who > > best know the codebase to provide IPMC oversight over it, > > especially as it pertains to releases. > > > > Without some more explanation I'm not that convinced about doing that. > The main purpose of the IPMC is to vote on the graduation of > poddlings, why should some random ASF poddling newbie get a binding > vote on the graduation of _any_ poddling? > > I'm guessing the motivation for this proposal is not to give poddling > committers binding votes on other poddling graduations but to give > them binding votes on their own poddling activities, and that i agree > with. The things they need binding votes on is their committer votes, > ppmc votes (they already have that), and release votes - lets just > give them those. You do have a very good point, however my experience with being on the httpd PMC as a subproject committer is that I will remain a non-participant in the decision-making process of the projects I don't work on. So what I'm saying is that the theoretical concern that podling committers with IPMC membership will have the authority to vote on the graduation of other projects (including their own I suppose), in practice those privileges are not going to be exercised for "social reasons". The main problem here is in coming to terms with release voting, because there are foundation-wide rules and policies that *every* release must follow. I am not sure the IPMC can simply delegate those decisions to the PPMC without tacit board approval of such a policy. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Wed, Aug 11, 2010 at 6:45 PM, Joe Schaefer wrote: > The second idea is more controversial: to hold IPMC votes to > admit all significant committers to those projects to the IPMC > itself. The purpose of this concept is to allow those who > best know the codebase to provide IPMC oversight over it, > especially as it pertains to releases. > Without some more explanation I'm not that convinced about doing that. The main purpose of the IPMC is to vote on the graduation of poddlings, why should some random ASF poddling newbie get a binding vote on the graduation of _any_ poddling? I'm guessing the motivation for this proposal is not to give poddling committers binding votes on other poddling graduations but to give them binding votes on their own poddling activities, and that i agree with. The things they need binding votes on is their committer votes, ppmc votes (they already have that), and release votes - lets just give them those. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message > From: Joe Schaefer > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 5:29:55 PM > Subject: Re: an experiment > > - Original Message > > > From: Donald Woods > > To: general@incubator.apache.org > > Sent: Wed, August 11, 2010 5:19:03 PM > > Subject: Re: an experiment > > Would still like this to be an opt-in, where any existing PMC member > > interested in helping with the Incubator could request membership and be > > added after 72 hours (expanding ASF member rules to apply to all PMC > > members.) > > Are you referring to ASF members here? PMC members themselves who > are not ASF members must be voted in by the IPMC to gain IPMC membership. > ASF members interested in IPMC membership need only notify the chair > of their intentions. I don't expect any of that to change with what > I'm proposing. Oh I see what you're saying now. Expanding the opt-in rule from ASF members to any PMC member is an interesting concept, but not part of what I was planning to do. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On 08/11/2010 05:19 PM, Donald Woods wrote: On 8/11/10 1:45 PM, Joe Schaefer wrote: So. Following some advice given to me by Sam Ruby, I'd like to start experimenting with different organizational and procedural approaches to the projects I participate in here. What I want to do is to see how far I can push the envelope on the whole notion of empowerment and self-governance in an incubating project, following the lessons I've learned from httpd's treatment of the subprojects it happens to be responsible for. The first idea should be fairly straightforward: that for the projects I participate in (so far thrift and sis), that the IPMC delegates to the PPMC the decision-making process for voting in new committers: basically rolling back the clock to May 1, 2007 on guides/ppmc.html. How about requiring at least one mentor on the vote, so there is still some oversight? Having all mentors vote is good but not necessary...IMHO The second idea is more controversial: to hold IPMC votes to admit all significant committers to those projects to the IPMC itself. The purpose of this concept is to allow those who best know the codebase to provide IPMC oversight over it, especially as it pertains to releases. Would still like this to be an opt-in, where any existing PMC member interested in helping with the Incubator could request membership and be added after 72 hours (expanding ASF member rules to apply to all PMC members.) For committers (non-PMC members), I'd want an existing IPMC or PMC member nominate the person to the IPMC and require a 72hr lazy consensus, since IPMC members are expected to mentor and teach new podlings about the Apache way. By PMC you mean PPMC? i am confused. I welcome your comments, criticisms, and other feedback. Thanks. - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message > From: Donald Woods > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 5:19:03 PM > Subject: Re: an experiment > > > > On 8/11/10 1:45 PM, Joe Schaefer wrote: > > So. Following some advice given to me by Sam Ruby, > > I'd like to start experimenting with different organizational > > and procedural approaches to the projects I participate in > > here. What I want to do is to see how far I can push > > the envelope on the whole notion of empowerment and > > self-governance in an incubating project, following the > > lessons I've learned from httpd's treatment of the subprojects > > it happens to be responsible for. > > > > The first idea should be fairly straightforward: that for > > the projects I participate in (so far thrift and sis), that > > the IPMC delegates to the PPMC the decision-making process > > for voting in new committers: basically rolling back the clock > > to May 1, 2007 on guides/ppmc.html. > > How about requiring at least one mentor on the vote, so there is still > some oversight? I'm actually not in favor of that idea because relatively few mentors are active developers in their projects (I'm certainly in that category). Part of what I'm trying to teach is that self-governance requires active participants to be making the critical decisions. OTOH I would be perfectly OK with the idea that a mentor must file the account request, or more simply must submit an ACK request regarding the vote to either gene...@incubator or priv...@incubator. > > > > The second idea is more controversial: to hold IPMC votes to > > admit all significant committers to those projects to the IPMC > > itself. The purpose of this concept is to allow those who > > best know the codebase to provide IPMC oversight over it, > > especially as it pertains to releases. > > Would still like this to be an opt-in, where any existing PMC member > interested in helping with the Incubator could request membership and be > added after 72 hours (expanding ASF member rules to apply to all PMC > members.) Are you referring to ASF members here? PMC members themselves who are not ASF members must be voted in by the IPMC to gain IPMC membership. ASF members interested in IPMC membership need only notify the chair of their intentions. I don't expect any of that to change with what I'm proposing. > For committers (non-PMC members), I'd want an existing IPMC > or PMC member nominate the person to the IPMC and require a 72hr lazy > consensus, since IPMC members are expected to mentor and teach new > podlings about the Apache way. I would expect a more formal process of consensus voting for IPMC membership in the case of a podling committer, ie 3 +1's and no vetoes. The vote would be held on priv...@incubator naturally. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Aug 11, 2010, at 4:14 PM, Joe Schaefer wrote: > > > - Original Message > >> From: Davanum Srinivas >> To: general@incubator.apache.org >> Sent: Wed, August 11, 2010 5:07:33 PM >> Subject: Re: an experiment >> >> +1 to IPMC delegates to the PPMC the decision-making >> process for voting in new committers (one question, >> would they need an ACK from IPMC - similar to how PMC's >> send a note to the board for an ACK for new pmc members)? > > That certainly sounds like a reasonable thing to do, sure. > +1 >> In the 2nd question, "significant committers", are we asking >> mentors to identify such candidates for addition to IPMC, >> especially release managers for example? if so, +1 for that >> as well. > I was also curious as to the mechanism for determining "significance"--I would be satisfied with mentors' recommendation as outlined by dims. I wonder if there should be some limit/function to determine the number of non-Member representatives a given podling may have on the IPMC. -Matt > Absolutely, especially RM's that have gotten into the habit > of running RAT themselves. > > > > > - > 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: an experiment
On 8/11/10 1:45 PM, Joe Schaefer wrote: > So. Following some advice given to me by Sam Ruby, > I'd like to start experimenting with different organizational > and procedural approaches to the projects I participate in > here. What I want to do is to see how far I can push > the envelope on the whole notion of empowerment and > self-governance in an incubating project, following the > lessons I've learned from httpd's treatment of the subprojects > it happens to be responsible for. > > The first idea should be fairly straightforward: that for > the projects I participate in (so far thrift and sis), that > the IPMC delegates to the PPMC the decision-making process > for voting in new committers: basically rolling back the clock > to May 1, 2007 on guides/ppmc.html. How about requiring at least one mentor on the vote, so there is still some oversight? > > The second idea is more controversial: to hold IPMC votes to > admit all significant committers to those projects to the IPMC > itself. The purpose of this concept is to allow those who > best know the codebase to provide IPMC oversight over it, > especially as it pertains to releases. Would still like this to be an opt-in, where any existing PMC member interested in helping with the Incubator could request membership and be added after 72 hours (expanding ASF member rules to apply to all PMC members.) For committers (non-PMC members), I'd want an existing IPMC or PMC member nominate the person to the IPMC and require a 72hr lazy consensus, since IPMC members are expected to mentor and teach new podlings about the Apache way. > > I welcome your comments, criticisms, and other feedback. > Thanks. > > > > > - > 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: an experiment
- Original Message > From: Davanum Srinivas > To: general@incubator.apache.org > Sent: Wed, August 11, 2010 5:07:33 PM > Subject: Re: an experiment > > +1 to IPMC delegates to the PPMC the decision-making > process for voting in new committers (one question, > would they need an ACK from IPMC - similar to how PMC's > send a note to the board for an ACK for new pmc members)? That certainly sounds like a reasonable thing to do, sure. > In the 2nd question, "significant committers", are we asking > mentors to identify such candidates for addition to IPMC, > especially release managers for example? if so, +1 for that > as well. Absolutely, especially RM's that have gotten into the habit of running RAT themselves. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
+1 to IPMC delegates to the PPMC the decision-making process for voting in new committers (one question, would they need an ACK from IPMC - similar to how PMC's send a note to the board for an ACK for new pmc members)? In the 2nd question, "significant committers", are we asking mentors to identify such candidates for addition to IPMC, especially release managers for example? if so, +1 for that as well. thanks, dims On 08/11/2010 01:45 PM, Joe Schaefer wrote: So. Following some advice given to me by Sam Ruby, I'd like to start experimenting with different organizational and procedural approaches to the projects I participate in here. What I want to do is to see how far I can push the envelope on the whole notion of empowerment and self-governance in an incubating project, following the lessons I've learned from httpd's treatment of the subprojects it happens to be responsible for. The first idea should be fairly straightforward: that for the projects I participate in (so far thrift and sis), that the IPMC delegates to the PPMC the decision-making process for voting in new committers: basically rolling back the clock to May 1, 2007 on guides/ppmc.html. The second idea is more controversial: to hold IPMC votes to admit all significant committers to those projects to the IPMC itself. The purpose of this concept is to allow those who best know the codebase to provide IPMC oversight over it, especially as it pertains to releases. I welcome your comments, criticisms, and other feedback. Thanks. - 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: Future of RAT
On Wed, Aug 11, 2010 at 15:30, Mattmann, Chris A (388J) wrote: > Hi Guys, > >>> [...] >>> So yes, development activity is low. >>> >>> OTOH patches get applied and releases are made if there is anything to >>> fix. I'm sure we could have gotten more people to vote if it had been >>> necessary on the last release, it just wasn't necessary so people >>> preferred to work on other things rather than checking releases. >> >> Right. it is being properly managed. >> >> Just like the Apache Tcl TLP. And Apache Excalibur. And Apache Perl. >> ... could probably find a few more low-activity TLPs, but I believe >> you see my point. It isn't about activity either. It is about whether >> you have eyeballs on the community and the codebase. > > Right. And if RAT is thinking about taking the next out of the Incubator > (i.e., graduation there are only 2 options): > > * graduate into a TLP > * graduate into a sub-project of another TLP > > IMHO, graduation by its nature means that the community/project are capable > of self-governance and trained in "the Apache way". I think RAT fits that > bill. My concerns about RAT being a sub project of Apache Foo is that we add > more sub-projects to Apache Foo. Though by itself this doesn't indicate > "umbrella", I've seen a movement towards establishing TLPs so that those > doing the work can sit on the PMC, have binding votes on releases, etc. > Adding RAT to Apache Foo may lead to Apache Foo PMC members holding the > binding votes, which I'm not sure is a) good, or b) something that > elucidates self-governance. Exactly why I've been advocating graduation to its own TLP, despite its "size" or "activity". Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Future of RAT
Hi Guys, >> [...] >> So yes, development activity is low. >> >> OTOH patches get applied and releases are made if there is anything to >> fix. I'm sure we could have gotten more people to vote if it had been >> necessary on the last release, it just wasn't necessary so people >> preferred to work on other things rather than checking releases. > > Right. it is being properly managed. > > Just like the Apache Tcl TLP. And Apache Excalibur. And Apache Perl. > ... could probably find a few more low-activity TLPs, but I believe > you see my point. It isn't about activity either. It is about whether > you have eyeballs on the community and the codebase. Right. And if RAT is thinking about taking the next out of the Incubator (i.e., graduation there are only 2 options): * graduate into a TLP * graduate into a sub-project of another TLP IMHO, graduation by its nature means that the community/project are capable of self-governance and trained in "the Apache way". I think RAT fits that bill. My concerns about RAT being a sub project of Apache Foo is that we add more sub-projects to Apache Foo. Though by itself this doesn't indicate "umbrella", I've seen a movement towards establishing TLPs so that those doing the work can sit on the PMC, have binding votes on releases, etc. Adding RAT to Apache Foo may lead to Apache Foo PMC members holding the binding votes, which I'm not sure is a) good, or b) something that elucidates self-governance. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Future of RAT
On Wed, Aug 11, 2010 at 12:12, Stefan Bodewig wrote: > On 2010-08-11, Niall Pemberton wrote: > >> The real point though is not size - its *activity*. > > [absolutely correct observation of low activity snipped] > >> My concern is if RAT goes TLP then it may be a small step away from >> not being able to get 3 PMC votes. > > I understand that and share the concern to some degree. > > RAT has probably never been the primary project for any of its > contributors. Most of us jumped in to scratch specific itches and other > than that RAT is a side project somewhere down the list of projects we > contribute to regularly. Pretty far down. > > That being said, we are aware of the problem and have tried to address > that by adding four more committers last December, that doesn't seem to > have been enough. > > One reason probably is that RAT does what it is supposed to do well > enough for most of us - the feedback of people who said RAT was so > important to them that it should become a TLP indicates it is good > enough for most other people as well. In a way RAT has already been > mature and in maintenance mode when it entered incubation. > > So yes, development activity is low. > > OTOH patches get applied and releases are made if there is anything to > fix. I'm sure we could have gotten more people to vote if it had been > necessary on the last release, it just wasn't necessary so people > preferred to work on other things rather than checking releases. Right. it is being properly managed. Just like the Apache Tcl TLP. And Apache Excalibur. And Apache Perl. ... could probably find a few more low-activity TLPs, but I believe you see my point. It isn't about activity either. It is about whether you have eyeballs on the community and the codebase. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
Given that the IPMC can still veto a decision of the podling, I like this idea. +1 LieGrue, strub - Original Message > From: "Mattmann, Chris A (388J)" > To: "general@incubator.apache.org" > Sent: Wed, August 11, 2010 7:49:45 PM > Subject: Re: an experiment > > Hi Joe, > > > The first idea should be fairly straightforward: that for > > the projects I participate in (so far thrift and sis), that > > the IPMC delegates to the PPMC the decision-making process > > for voting in new committers: basically rolling back the clock > > to May 1, 2007 on guides/ppmc.html. > > +1 from me, and I'd like to OODT to that experimental list as well :) It > would probably make sense for Lucy too, but we're in our nascence there (not > that it should matter). > > > > > The second idea is more controversial: to hold IPMC votes to > > admit all significant committers to those projects to the IPMC > > itself. The purpose of this concept is to allow those who > > best know the codebase to provide IPMC oversight over it, > > especially as it pertains to releases. > > I wouldn't have a problem with this. > > Cheers, > Chris > > ++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: chris.mattm...@jpl.nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++ > > > > - > 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: an experiment
Hi Joe, > The first idea should be fairly straightforward: that for > the projects I participate in (so far thrift and sis), that > the IPMC delegates to the PPMC the decision-making process > for voting in new committers: basically rolling back the clock > to May 1, 2007 on guides/ppmc.html. +1 from me, and I'd like to OODT to that experimental list as well :) It would probably make sense for Lucy too, but we're in our nascence there (not that it should matter). > > The second idea is more controversial: to hold IPMC votes to > admit all significant committers to those projects to the IPMC > itself. The purpose of this concept is to allow those who > best know the codebase to provide IPMC oversight over it, > especially as it pertains to releases. I wouldn't have a problem with this. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
an experiment
So. Following some advice given to me by Sam Ruby, I'd like to start experimenting with different organizational and procedural approaches to the projects I participate in here. What I want to do is to see how far I can push the envelope on the whole notion of empowerment and self-governance in an incubating project, following the lessons I've learned from httpd's treatment of the subprojects it happens to be responsible for. The first idea should be fairly straightforward: that for the projects I participate in (so far thrift and sis), that the IPMC delegates to the PPMC the decision-making process for voting in new committers: basically rolling back the clock to May 1, 2007 on guides/ppmc.html. The second idea is more controversial: to hold IPMC votes to admit all significant committers to those projects to the IPMC itself. The purpose of this concept is to allow those who best know the codebase to provide IPMC oversight over it, especially as it pertains to releases. I welcome your comments, criticisms, and other feedback. Thanks. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Future of RAT
On 2010-08-11, Niall Pemberton wrote: > The real point though is not size - its *activity*. [absolutely correct observation of low activity snipped] > My concern is if RAT goes TLP then it may be a small step away from > not being able to get 3 PMC votes. I understand that and share the concern to some degree. RAT has probably never been the primary project for any of its contributors. Most of us jumped in to scratch specific itches and other than that RAT is a side project somewhere down the list of projects we contribute to regularly. Pretty far down. That being said, we are aware of the problem and have tried to address that by adding four more committers last December, that doesn't seem to have been enough. One reason probably is that RAT does what it is supposed to do well enough for most of us - the feedback of people who said RAT was so important to them that it should become a TLP indicates it is good enough for most other people as well. In a way RAT has already been mature and in maintenance mode when it entered incubation. So yes, development activity is low. OTOH patches get applied and releases are made if there is anything to fix. I'm sure we could have gotten more people to vote if it had been necessary on the last release, it just wasn't necessary so people preferred to work on other things rather than checking releases. Stefan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Future of RAT
On Tue, Aug 10, 2010 at 6:20 PM, Greg Stein wrote: > Let me repeat: where does it say a TLP must be "at least THIS size" ? > > Answer: nowhere. > > Small projects are just fine. We're looking at the overall community > and the people to shepherd that community. Those are the RAT > developers and users. Not the Apache Commons or Apache Maven people. > They have other concerns and focus points. > > TLPs are not "expensive", so they don't have to have a "minimum size" > to justify their existence. The real point though is not size - its *activity*. Take a look at the recent vote for the RAT 0.7 release on the RAT dev list[1] - it only managed to get 3 vote. I know commit stats are not everything but of the 7 people who have committed on RAT trunk in the past year only 3 are in double figures. My concern is if RAT goes TLP then it may be a small step away from not being able to get 3 PMC votes. Niall [1] http://markmail.org/message/yoaxt3yeo2gb23rg > Cheers, > -g > > On Tue, Aug 10, 2010 at 12:37, Mark Struberg wrote: >> RAT is very important and helpful, but I don't think it's big enough to >> justify >> an own TLP. >> It previously was under codehaus and I agree it would best fit under the >> maven >> TLP. >> >> LieGrue, >> strub >> >> >> - Original Message >>> From: Jochen Wiedmann >>> To: general@incubator.apache.org >>> Sent: Tue, August 10, 2010 4:47:49 PM >>> Subject: Re: Future of RAT >>> >>> On Tue, Aug 10, 2010 at 4:03 PM, Mattmann, Chris A (388J) >>> wrote: >>> >>> > I feel kind of the opposite -- RAT is an important tool that's required >>> > of >>> > all the Incubator projects, but pretty widely integrated (at least in >>> > Java >>> > land) outside of the Incubator as a tool to help check ASF policies. To >>> > me, >>> > that's a big scope and an important community, and just based on the >>> > telltale signs it seems like a TLP to me. >>> >>> Quick, hire him for chair ;-) >>> >>> >>> >>> -- >>> I Am What I Am And That's All What I Yam (Popeye) >>> >>> - >>> 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 >> >> > > - > 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
