Re: Wrapping it up: Retirement decision making
Hi, On Sun, Dec 9, 2012 at 8:13 PM, Alan Cabrera wrote: > Also, I'm too lazy to troll through the list to collect the two new > additional mentors for Chukwa, > I think that it was Ant and Jukka. Can Ant and Jukka confirm? Confirmed. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Wrapping it up: Retirement decision making
If no one minds I think it would be a good idea for the docs to be updated with our new common understanding. What I propose is for for a wiki page with the new wording to be created for us to comment/vote on. I'm happy to consolidate the current thinking on this. Also, I'm too lazy to troll through the list to collect the two new additional mentors for Chukwa, I think that it was Ant and Jukka. Can Ant and Jukka confirm? Regards, Alan On Nov 28, 2012, at 5:32 AM, Benson Margulies wrote: > The current vote thread for retirement of Chukwa, coupled with some of > the other discussion threads, raises some questions that need to be > resolved. > > How do we make retirement decisions? > > http://incubator.apache.org/guides/retirement.html says: > > "Before following the retirement steps, the remaining developers of > the project should be informed and vote should happen on the projects > dev list. After the vote, the IPMC must vote on the general list to > retire the project. > > In some cases the developers of a project might be opposed to > retirement, while the IPMC is in favour because its members cannot see > a succesfull graduation now or in future. In this case the IPMC > _decides_ about the retirement." > > In general, Apache projects strive to reach decisions by consensus, > using votes to memorialize consensus. > > In the Chukwa case, there seems to have been a consensus some months > ago about how things would proceed. However, I don't think it's > reasonable to view that decision as a self-operating process in which > the community pre-decided exactly how and when the plug would be > pulled. Actually deciding to retire the project, over the objections > of even one of its contributors, is a decision point that the > community has to cope with -- however frustrating this may be for > mentors. > > So, in hindsight, it would have been good to have a [DISCUSS] thread > in which the mentors could present their view, Eric could argue back, > and other people could pose questions of clarification. If people > really want to compare to Wink, someone could do the necessary > slogging to bring forth real comparative data for Wink. > > But let's imagine that we have a DISCUSS thread and a clear lack of > consensus. In essence, that's what the current [VOTE] thread amounts > to. Now what? Do we say, 'well, in the absence of consensus, we must > continue the podling'? Do we say this even in the absence of enough > mentors willing to supervise it? > > I stupidly posted an initial version of this question to private@, and > Ross replied with some very clear thinking on this, which I trust that > he will re-send to this thread. I'll stop here and wait for that. > > --benson > > - > 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: Retirement decision making
+1 on active PMC duties would be fine to ensure continuation of the project. regards, Eric On Fri, Nov 30, 2012 at 1:27 AM, Ross Gardler wrote: > On 30 November 2012 00:52, Benson Margulies wrote: > > > Hard cases make bad law. The rough parameters of the recent 'small > > graduates' was that they had around 5 initial PMC members, and some > > detectable evidence that all of them were in the reasonably regular > > habit of contributing code, let alone voting for releases. If we > > insist on testing the absolute lower limit of viability, we're may > > bump into the absurd. > > > > +1 (where "reasonably regular habit of contributing code" should be > "reasonably regular habit of contributing in some way" - that is only being > active in PMC duties would be fine, need not be active committer, as long > as it is responsible activity (i.e. voting from an informed position) > > Ross > > > > > > > > > > On Thu, Nov 29, 2012 at 4:45 PM, Andy Seaborne wrote: > > > On 29/11/12 14:53, Bertrand Delacretaz wrote: > > >> > > >> On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera > > >> wrote: > > >>> > > >>> ... Would you also add the three or more active PMC members > > requirement? > > >>> What constitutes active?... > > >> > > >> > > >> IMO the bare minimum is being able to find three PMC members to vote > > >> on things when needed. > > >> > > >> Once a project gets below this limit it's in trouble and usually > > >> headed for the attic, but that's not the only possibility - see > > >> "Resolution to reboot the Apache Xalan PMC" at > > >> > > >> > > > http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt > > >> for example. > > > > > > > > > I think we need to be a bit careful about graduating a podling that is > a > > > minimum viable project. That's not say it shouldn't be done but if > it's > > > minimal, and looks ropey, then we're aren't doing us or them any > favours > > if > > > the project looks likely to get into problems quite soon. After all, > > > graduation itself requires project resource. > > > > > > Andy > > > > > > > > >> > > >> -Bertrand > > >> > > >> - > > >> 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 > > > > > > > -- > Ross Gardler (@rgardler) > Programme Leader (Open Development) > OpenDirective http://opendirective.com >
Re: Retirement decision making
On Fri, Nov 30, 2012 at 10:56 AM, Bertrand Delacretaz wrote: > On Fri, Nov 30, 2012 at 4:49 PM, Alan Cabrera wrote: >> On Nov 30, 2012, at 12:56 AM, Bertrand Delacretaz wrote: >>>...I'd say you need at least five >>> active PMC members at graduation time... > >> ...Maybe that could be a requirement, if the mentors think that the podling >> is not diverse and >> vibrant yet, then they must stay on as active PMC members until such time >> that they believe >> that the TLP has achieved it; kind of a put your money where your mouth is >> thing > It's arguable that one or two of my PMC memberships fall under this provision. I'd merely adjust that the word 'vibrant' means nothing specific to me, it's not a criteria I've ever thought about, and my willingness to become the long-term mentor of these folks outside the incubator is, in my mind, mostly a matter of compensating for small numbers and lack of ASF prior experience. Aside from being an extra release voter, I'm there to pay some attention and help with issues that come up when they (finally) absorb some new people. > Works for me. > -Bertrand > > - > 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: Retirement decision making
On Fri, Nov 30, 2012 at 4:49 PM, Alan Cabrera wrote: > On Nov 30, 2012, at 12:56 AM, Bertrand Delacretaz wrote: >>...I'd say you need at least five >> active PMC members at graduation time... > ...Maybe that could be a requirement, if the mentors think that the podling > is not diverse and > vibrant yet, then they must stay on as active PMC members until such time > that they believe > that the TLP has achieved it; kind of a put your money where your mouth is > thing Works for me. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On Nov 30, 2012, at 12:56 AM, Bertrand Delacretaz wrote: > On Fri, Nov 30, 2012 at 4:18 AM, Alan Cabrera wrote: >> Hence my idea to do away with the rule of thumb and stick to at least one >> responsible PMC member > > How will that work? IIUC your idea, the resulting PMC cannot get 3 PMC > votes so it cannot operate. > > I don't want to burden the board with more Xalan-like project saving > exercices if it can be avoided, that case was driven by historic > evolution of the project, graduating projects that are headed in that > direction doesn't make sense to me. > > People come and go, so to be realistic I'd say you need at least five > active PMC members at graduation time, so as to get three votes when > needed, with some "spares". Mentors staying on board can of course > count in those five. Ok, I think I get it. Maybe that could be a requirement, if the mentors think that the podling is not diverse and vibrant yet, then they must stay on as active PMC members until such time that they believe that the TLP has achieved it; kind of a put your money where your mouth is thing. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On Fri, Nov 30, 2012 at 4:27 AM, Ross Gardler wrote: > On 30 November 2012 00:52, Benson Margulies wrote: > > > Hard cases make bad law. The rough parameters of the recent 'small > > graduates' was that they had around 5 initial PMC members, and some > > detectable evidence that all of them were in the reasonably regular > > habit of contributing code, let alone voting for releases. If we > > insist on testing the absolute lower limit of viability, we're may > > bump into the absurd. > > > > +1 (where "reasonably regular habit of contributing code" should be > "reasonably regular habit of contributing in some way" - that is only being > active in PMC duties would be fine, need not be active committer, as long > as it is responsible activity (i.e. voting from an informed position) > Yes. Particularly for more mature code-bases, I'd put a lot of weight on whether people are around to answer user questions -- quite possibly, explaining the system helps attract new users more than tinkering with it does. --Ari -- Ari Rabkin asrab...@gmail.com Princeton Computer Science Department
Re: Retirement decision making
On 30 November 2012 00:52, Benson Margulies wrote: > Hard cases make bad law. The rough parameters of the recent 'small > graduates' was that they had around 5 initial PMC members, and some > detectable evidence that all of them were in the reasonably regular > habit of contributing code, let alone voting for releases. If we > insist on testing the absolute lower limit of viability, we're may > bump into the absurd. > +1 (where "reasonably regular habit of contributing code" should be "reasonably regular habit of contributing in some way" - that is only being active in PMC duties would be fine, need not be active committer, as long as it is responsible activity (i.e. voting from an informed position) Ross > > > > On Thu, Nov 29, 2012 at 4:45 PM, Andy Seaborne wrote: > > On 29/11/12 14:53, Bertrand Delacretaz wrote: > >> > >> On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera > >> wrote: > >>> > >>> ... Would you also add the three or more active PMC members > requirement? > >>> What constitutes active?... > >> > >> > >> IMO the bare minimum is being able to find three PMC members to vote > >> on things when needed. > >> > >> Once a project gets below this limit it's in trouble and usually > >> headed for the attic, but that's not the only possibility - see > >> "Resolution to reboot the Apache Xalan PMC" at > >> > >> > http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt > >> for example. > > > > > > I think we need to be a bit careful about graduating a podling that is a > > minimum viable project. That's not say it shouldn't be done but if it's > > minimal, and looks ropey, then we're aren't doing us or them any favours > if > > the project looks likely to get into problems quite soon. After all, > > graduation itself requires project resource. > > > > Andy > > > > > >> > >> -Bertrand > >> > >> - > >> 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 > > -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: Retirement decision making
On Fri, Nov 30, 2012 at 4:18 AM, Alan Cabrera wrote: > Hence my idea to do away with the rule of thumb and stick to at least one > responsible PMC member How will that work? IIUC your idea, the resulting PMC cannot get 3 PMC votes so it cannot operate. I don't want to burden the board with more Xalan-like project saving exercices if it can be avoided, that case was driven by historic evolution of the project, graduating projects that are headed in that direction doesn't make sense to me. People come and go, so to be realistic I'd say you need at least five active PMC members at graduation time, so as to get three votes when needed, with some "spares". Mentors staying on board can of course count in those five. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
Hence my idea to do away with the rule of thumb and stick to at least one responsible PMC member. What problem are we trying to avoid by having this activity/diversity boundary? Regards, Alan On Nov 29, 2012, at 4:52 PM, Benson Margulies wrote: > Hard cases make bad law. The rough parameters of the recent 'small > graduates' was that they had around 5 initial PMC members, and some > detectable evidence that all of them were in the reasonably regular > habit of contributing code, let alone voting for releases. If we > insist on testing the absolute lower limit of viability, we're may > bump into the absurd. > > > > On Thu, Nov 29, 2012 at 4:45 PM, Andy Seaborne wrote: >> On 29/11/12 14:53, Bertrand Delacretaz wrote: >>> >>> On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera >>> wrote: ... Would you also add the three or more active PMC members requirement? What constitutes active?... >>> >>> >>> IMO the bare minimum is being able to find three PMC members to vote >>> on things when needed. >>> >>> Once a project gets below this limit it's in trouble and usually >>> headed for the attic, but that's not the only possibility - see >>> "Resolution to reboot the Apache Xalan PMC" at >>> >>> http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt >>> for example. >> >> >> I think we need to be a bit careful about graduating a podling that is a >> minimum viable project. That's not say it shouldn't be done but if it's >> minimal, and looks ropey, then we're aren't doing us or them any favours if >> the project looks likely to get into problems quite soon. After all, >> graduation itself requires project resource. >> >>Andy >> >> >>> >>> -Bertrand >>> >>> - >>> 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
Re: Retirement decision making
Hard cases make bad law. The rough parameters of the recent 'small graduates' was that they had around 5 initial PMC members, and some detectable evidence that all of them were in the reasonably regular habit of contributing code, let alone voting for releases. If we insist on testing the absolute lower limit of viability, we're may bump into the absurd. On Thu, Nov 29, 2012 at 4:45 PM, Andy Seaborne wrote: > On 29/11/12 14:53, Bertrand Delacretaz wrote: >> >> On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera >> wrote: >>> >>> ... Would you also add the three or more active PMC members requirement? >>> What constitutes active?... >> >> >> IMO the bare minimum is being able to find three PMC members to vote >> on things when needed. >> >> Once a project gets below this limit it's in trouble and usually >> headed for the attic, but that's not the only possibility - see >> "Resolution to reboot the Apache Xalan PMC" at >> >> http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt >> for example. > > > I think we need to be a bit careful about graduating a podling that is a > minimum viable project. That's not say it shouldn't be done but if it's > minimal, and looks ropey, then we're aren't doing us or them any favours if > the project looks likely to get into problems quite soon. After all, > graduation itself requires project resource. > > Andy > > >> >> -Bertrand >> >> - >> 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: Retirement decision making
On 29/11/12 14:53, Bertrand Delacretaz wrote: On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera wrote: ... Would you also add the three or more active PMC members requirement? What constitutes active?... IMO the bare minimum is being able to find three PMC members to vote on things when needed. Once a project gets below this limit it's in trouble and usually headed for the attic, but that's not the only possibility - see "Resolution to reboot the Apache Xalan PMC" at http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt for example. I think we need to be a bit careful about graduating a podling that is a minimum viable project. That's not say it shouldn't be done but if it's minimal, and looks ropey, then we're aren't doing us or them any favours if the project looks likely to get into problems quite soon. After all, graduation itself requires project resource. Andy -Bertrand - 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: Retirement decision making
On Nov 29, 2012, at 7:45 AM, Ross Gardler wrote: > On 29 November 2012 14:59, Alan Cabrera wrote: > >> >> On Nov 29, 2012, at 6:53 AM, Bertrand Delacretaz wrote: >> >>> On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera >> wrote: ... Would you also add the three or more active PMC members >> requirement? What constitutes active?... >>> >>> IMO the bare minimum is being able to find three PMC members to vote >>> on things when needed. >>> >>> Once a project gets below this limit it's in trouble and usually >>> headed for the attic, but that's not the only possibility - see >>> "Resolution to reboot the Apache Xalan PMC" at >>> >> http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt >>> for example. >> >> And so by extension we can apply this to podlings as well. >> >> So if the IP is vetted and we trust the PPMC members then the podling has >> met all the requirements for incubation? >> >> >> > > +1 Well this dramatically changes what I though I was supposed to do. I thought I was doing my duty as a mentor when I scraped up my 9 pence and dragged Chukwa to the curb. http://www.youtube.com/watch?v=Sh8mNjeuyV4 By the criteria described above the podling is most likely good to go; in the good way not the bad way. It would probably be a good idea to add some kind of designation to the graduating podling officially informing it that in the estimation of the IPMC it has not yet obtained its vibrant and diverse requirements and that it will be required to submit a plan and track progress in its board reports. Maybe TLPs can be put on some kind of official probation, or some term less severe. The Attic can be the shepherds for TLPs in probation. The benefits are that the podlings no longer need to go through the sometimes arduous Incubator release cycle. They loose the "stigma" of being a podling. Strangers coming in understand that the TLP does not meet the ASF standard for diversity and vibrancy but the ASF still holds out great hope. Regards, Alan
Re: Retirement decision making
On 29 November 2012 14:59, Alan Cabrera wrote: > > On Nov 29, 2012, at 6:53 AM, Bertrand Delacretaz wrote: > > > On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera > wrote: > >> ... Would you also add the three or more active PMC members > requirement? What constitutes active?... > > > > IMO the bare minimum is being able to find three PMC members to vote > > on things when needed. > > > > Once a project gets below this limit it's in trouble and usually > > headed for the attic, but that's not the only possibility - see > > "Resolution to reboot the Apache Xalan PMC" at > > > http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt > > for example. > > And so by extension we can apply this to podlings as well. > > So if the IP is vetted and we trust the PPMC members then the podling has > met all the requirements for incubation? > > > +1 > > -- > Ross Gardler (@rgardler) > Programme Leader (Open Development) > OpenDirective http://opendirective.com >
Re: Retirement decision making
On Nov 29, 2012, at 6:53 AM, Bertrand Delacretaz wrote: > On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera wrote: >> ... Would you also add the three or more active PMC members requirement? >> What constitutes active?... > > IMO the bare minimum is being able to find three PMC members to vote > on things when needed. > > Once a project gets below this limit it's in trouble and usually > headed for the attic, but that's not the only possibility - see > "Resolution to reboot the Apache Xalan PMC" at > http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt > for example. And so by extension we can apply this to podlings as well. So if the IP is vetted and we trust the PPMC members then the podling has met all the requirements for incubation? Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera wrote: >... Would you also add the three or more active PMC members requirement? What >constitutes active?... IMO the bare minimum is being able to find three PMC members to vote on things when needed. Once a project gets below this limit it's in trouble and usually headed for the attic, but that's not the only possibility - see "Resolution to reboot the Apache Xalan PMC" at http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt for example. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On Nov 29, 2012, at 1:14 AM, Ross Gardler wrote: > On 29 November 2012 08:56, Bertrand Delacretaz wrote: > >> On Wednesday, November 28, 2012, Greg Reddin wrote: >>> ...What difference does it make to >>> the ASF if a project is very small or very slow?... >> >> IMO, as long as there's three or more active PMC members who react when >> needed, and provide the quarterly board reports, a small/slow project is >> fine and there's no need to move it to the attic. >> > > +1 - oversight is what matters. If the PMC is happy to continue as is then > all is good. As previously stated my concern is whether the PMC is > operating in a way in which the building and maintenance of a diverse > community is possible. For example, when a new patch turns up are they > reviewing and applying it and are they bringing in the new community member. > > Note that in this months reports the board were asked, by a TLP, for > feedback on the "dormant" state they found themselves in, the PMC was > reactive when necessary but not proactively developing the code or the > community. The boards feedback was in line with Bertrands comment above - > the PMC is providing sufficient oversight so no problem. In another case > this month a TLP indicated one of their sub-projects was dormant to the > extent that patches were not being reviewed. The board asked if there was a > plan and the PMC responded with unity that it will be addressed. So no > problem, the PMC is aware of the issue and is addressing it. > > Drawing this to its natural conclusion a podling should be graduated once > it demonstrates an ability to operate as an Apache project without the need > for binding IPMC votes on releases etc. A podling should be retired if > there is insufficient interest from both the PPMC and the IPMC to move it > towards this state (which brings me back to my original 3 stages of > decision making about podling retirement). Would you also add the three or more active PMC members requirement? What constitutes active? Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On 29 November 2012 08:56, Bertrand Delacretaz wrote: > On Wednesday, November 28, 2012, Greg Reddin wrote: > > ...What difference does it make to > > the ASF if a project is very small or very slow?... > > IMO, as long as there's three or more active PMC members who react when > needed, and provide the quarterly board reports, a small/slow project is > fine and there's no need to move it to the attic. > +1 - oversight is what matters. If the PMC is happy to continue as is then all is good. As previously stated my concern is whether the PMC is operating in a way in which the building and maintenance of a diverse community is possible. For example, when a new patch turns up are they reviewing and applying it and are they bringing in the new community member. Note that in this months reports the board were asked, by a TLP, for feedback on the "dormant" state they found themselves in, the PMC was reactive when necessary but not proactively developing the code or the community. The boards feedback was in line with Bertrands comment above - the PMC is providing sufficient oversight so no problem. In another case this month a TLP indicated one of their sub-projects was dormant to the extent that patches were not being reviewed. The board asked if there was a plan and the PMC responded with unity that it will be addressed. So no problem, the PMC is aware of the issue and is addressing it. Drawing this to its natural conclusion a podling should be graduated once it demonstrates an ability to operate as an Apache project without the need for binding IPMC votes on releases etc. A podling should be retired if there is insufficient interest from both the PPMC and the IPMC to move it towards this state (which brings me back to my original 3 stages of decision making about podling retirement). (Ant's email about "trust" overlapped with me typing this one, I think that is another side of the same coin and fully support his comments) Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: Retirement decision making
On Thu, Nov 29, 2012 at 8:56 AM, Bertrand Delacretaz wrote: > On Wednesday, November 28, 2012, Greg Reddin wrote: > > ...What difference does it make to > > the ASF if a project is very small or very slow?... > > IMO, as long as there's three or more active PMC members who react when > needed, and provide the quarterly board reports, a small/slow project is > fine and there's no need to move it to the attic. > > -Bertrand > One of the issues with that is the interpretation of what "active" means. So we can look at poddlings which aren't very active and say it doesn't have three people committing regularly and therefore doesn't meet that requirement. However in reality there maybe three people who are at least watching and would step up and interact on votes etc when things require it. There are TLPs that operate like that. Is that enough for a poddling? I think the answer comes down to that trust issue, if its a bunch of ASF members we all know we're more lenient than if its a bunch of new comers none of us know. ...ant
Re: Retirement decision making
On Wednesday, November 28, 2012, Greg Reddin wrote: > ...What difference does it make to > the ASF if a project is very small or very slow?... IMO, as long as there's three or more active PMC members who react when needed, and provide the quarterly board reports, a small/slow project is fine and there's no need to move it to the attic. -Bertrand
Re: Retirement decision making
On Wed, Nov 28, 2012 at 4:00 PM, Alan Cabrera wrote: > If we have shepherds to monitor the all too human mentors, should we not > also have reapers, to monitor TLPs? I'm all for being on the optimistic > side and graduate small projects but, sometimes, I feel it's done because > we don't wish to face uncomfortable facts. > IIRC, the attic kinda served as the "reaper" when it first got started, but maybe got a little less aggressive about sweeping up after a while. Greg
Re: Retirement decision making
On Wed, Nov 28, 2012 at 3:48 PM, Benson Margulies wrote: > TLPs do, sometimes, retire. Some of them have retired precisely > because all the contributors disappeared due to seismic events at > work. The board has been observed to keep a TLP alive really to the > last possible moment -- the point where there were less than three > people to vote on a release. > > This does not entirely reply to your point; how much viability should > the board want to see before establishing a TLP? I write, 'the board', > since a IPMC votes are _recommendations_ to the board. > This is a good question and I don't know if it can be answered. What is the minimal acceptable level of activity for an ASF project? I'm the chair of a project that just doesn't want to die: Tiles. Tiles has never had a huge amount of activity, especially when compared to Struts, which is the project that birthed us. There have been times where the activity has dwindled to near zero for the course of a few quarters. Then just when I'm about to write a board report saying the project is ready for the attic here comes some more work. If we had "retired early" Tiles 3 would not exist. We were very near closing up shop before a new contributor came along with some very interesting ideas. So the question remains: What difference does it make to the ASF if a project is very small or very slow? Maybe it is dormant for a year because it just does what it is supposed to do, or it has some bugs, but none of the users are so motivated to fix them that they actually offer patches, then it gets revived with some new ideas and work continues for a while. What's the motivation for closing down a project that slows considerably? Greg
Re: Retirement decision making
On Nov 28, 2012, at 1:48 PM, Benson Margulies wrote: > TLPs do, sometimes, retire. Some of them have retired precisely > because all the contributors disappeared due to seismic events at > work. The board has been observed to keep a TLP alive really to the > last possible moment -- the point where there were less than three > people to vote on a release. > > This does not entirely reply to your point; how much viability should > the board want to see before establishing a TLP? I write, 'the board', > since a IPMC votes are _recommendations_ to the board. > > After last year's discussions about the incubator, we decided that it > was better to err a bit on the optimistic side and graduate some small > projects, rather than retiring them or keeping them in the incubator > forever. In a year or two, depending on how some of them do, we may > learn something from this that will cause us to change our view and > try something else. > > Subjective? Yup. The alternative isn't attractive; a strict adherence > to some objective criteria can also end up with the wrong answer. There is another alternative, which is do away with the criteria altogether. If we have shepherds to monitor the all too human mentors, should we not also have reapers, to monitor TLPs? I'm all for being on the optimistic side and graduate small projects but, sometimes, I feel it's done because we don't wish to face uncomfortable facts. Ultimately what value does the ASF Imprimatur have? As I mentioned before, it doesn't mean that project is diverse and vibrant since there are many times we let projects "prematurely" slip in. So, effectively, anyone coming in to evaluate a project in the ASF still has to do their own sleuthing to estimate if it's a fledgling project that may or may not pan out, a fully active and diverse project, or a project that has waned and waiting for a reaper to come. Virtually, with regards to the ASF Imprimatur, the criteria of diversity and vibrancy has been watered down if not nullified. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
TLPs do, sometimes, retire. Some of them have retired precisely because all the contributors disappeared due to seismic events at work. The board has been observed to keep a TLP alive really to the last possible moment -- the point where there were less than three people to vote on a release. This does not entirely reply to your point; how much viability should the board want to see before establishing a TLP? I write, 'the board', since a IPMC votes are _recommendations_ to the board. After last year's discussions about the incubator, we decided that it was better to err a bit on the optimistic side and graduate some small projects, rather than retiring them or keeping them in the incubator forever. In a year or two, depending on how some of them do, we may learn something from this that will cause us to change our view and try something else. Subjective? Yup. The alternative isn't attractive; a strict adherence to some objective criteria can also end up with the wrong answer. On Wed, Nov 28, 2012 at 4:36 PM, Alan Cabrera wrote: > > On Nov 28, 2012, at 12:56 PM, Bertrand Delacretaz wrote: > >> On Wed, Nov 28, 2012 at 9:46 PM, Alan Cabrera wrote: >>> ...I'm wondering if it makes sense to do away with the diversity and vibrant >>> dictum and merely state that at least one person is reasonably active and >>> that >>> all the PMC members are trustworthy >> >> I wouldn't want to graduate a project that doesn't seem to be able to >> grow a sustainable community. Demonstrating potential for that, even >> though the results might not be here yet at the time of graduation, is >> important for me as a mentor. It's quite subjective, but in case of >> doubt this PMC can certainly help make the right decisions. > > Too subjective, IMO. If we're really serious about this then would we not > also need a process to vacuum old projects? > > Plus, in addition to being extremely subjective, and contentious, isn't > sustainability and diversity a transitory aspect? Someone who's been working > on a project for ten years now has his project booted because some company > decided to pull out developers? That seems like a no win situation for that > person and for the company who may end up looking like the bad guy. > > > Regards, > Alan > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On Nov 28, 2012, at 12:56 PM, Bertrand Delacretaz wrote: > On Wed, Nov 28, 2012 at 9:46 PM, Alan Cabrera wrote: >> ...I'm wondering if it makes sense to do away with the diversity and vibrant >> dictum and merely state that at least one person is reasonably active and >> that >> all the PMC members are trustworthy > > I wouldn't want to graduate a project that doesn't seem to be able to > grow a sustainable community. Demonstrating potential for that, even > though the results might not be here yet at the time of graduation, is > important for me as a mentor. It's quite subjective, but in case of > doubt this PMC can certainly help make the right decisions. Too subjective, IMO. If we're really serious about this then would we not also need a process to vacuum old projects? Plus, in addition to being extremely subjective, and contentious, isn't sustainability and diversity a transitory aspect? Someone who's been working on a project for ten years now has his project booted because some company decided to pull out developers? That seems like a no win situation for that person and for the company who may end up looking like the bad guy. Regards, Alan
Re: Retirement decision making
On Wed, Nov 28, 2012 at 9:46 PM, Alan Cabrera wrote: > ...I'm wondering if it makes sense to do away with the diversity and vibrant > dictum and merely state that at least one person is reasonably active and that > all the PMC members are trustworthy I wouldn't want to graduate a project that doesn't seem to be able to grow a sustainable community. Demonstrating potential for that, even though the results might not be here yet at the time of graduation, is important for me as a mentor. It's quite subjective, but in case of doubt this PMC can certainly help make the right decisions. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
+1 For me mentoring ends when the PPMC is able to demonstrate that it can work in a way that will build diversity, not necessarily when diversity is achieved. Ross Sent from my tablet On Nov 28, 2012 8:47 PM, "Alan Cabrera" wrote: > I've been giving this some thought and I've worked hard at keeping it > short and sweet. So finer points are left out but I hope they are obvious. > > What does ASF's Imprimatur mean? > > Does it mean that project is diverse and vibrant? No. > > Does it mean that the project's committers and PMC members are > trustworthy? Yes. > > I'm wondering if it makes sense to do away with the diversity and vibrant > dictum and merely state that at least one person is reasonably active and > that all the PMC members are trustworthy. > > If we do this then all manner of things are simplified especially with > respect to those projects that were, seemingly, unfairly fast tracked. > > > Regards, > Alan > > > > On Nov 28, 2012, at 6:57 AM, Benson Margulies wrote: > > > The question of a time limit is like other questions we deal with: we > > don't want to set a hard limit, but the idea of incubation going along > > for years and years is not consistent with the vision of what the > > incubator is. Sam was at pains to present this dilemma, not to ask for > > some kind of hard limit. > > > > Ross, I can now see how your 'follow the mentors' model should have > > the effect of solving this problem, too. > > > > I didn't start this thread with 'we have a broken process,' I started > > it with, 'I want to clarify what our process is.' > > > > To me, this discussion feeds my prior belief that we need to continue > > to emphasize the importance of active, engaged, mentors, and see their > > absence in a podling as a problem that demands attention. > > > > There are people here (notable Greg) who are very skeptical of this > > mentor-centric model. However, it seems to me that the consensus of > > the community continues to be to try to tune/repair it, not replace > > it. > > > > On Wed, Nov 28, 2012 at 9:41 AM, ant elder wrote: > >> On Wed, Nov 28, 2012 at 2:32 PM, Bertrand Delacretaz < > bdelacre...@apache.org > >>> wrote: > >> > >>> On Wed, Nov 28, 2012 at 3:24 PM, ant elder > wrote: > ...Slow poddlings don't use much ASF resource so aren't a burden... > >>> > >>> I disagree: podlings do use mentor's energy - graduating or retiring > >>> them is a way to free up mentors for other incoming podlings. > >>> > >> > >> I did say "If there are willing participants" which includes the > mentors. > >> > >> And I don't think looking at mentors as a pot of resource is the correct > >> view. > >> > >> ...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: Retirement decision making
I've been giving this some thought and I've worked hard at keeping it short and sweet. So finer points are left out but I hope they are obvious. What does ASF's Imprimatur mean? Does it mean that project is diverse and vibrant? No. Does it mean that the project's committers and PMC members are trustworthy? Yes. I'm wondering if it makes sense to do away with the diversity and vibrant dictum and merely state that at least one person is reasonably active and that all the PMC members are trustworthy. If we do this then all manner of things are simplified especially with respect to those projects that were, seemingly, unfairly fast tracked. Regards, Alan On Nov 28, 2012, at 6:57 AM, Benson Margulies wrote: > The question of a time limit is like other questions we deal with: we > don't want to set a hard limit, but the idea of incubation going along > for years and years is not consistent with the vision of what the > incubator is. Sam was at pains to present this dilemma, not to ask for > some kind of hard limit. > > Ross, I can now see how your 'follow the mentors' model should have > the effect of solving this problem, too. > > I didn't start this thread with 'we have a broken process,' I started > it with, 'I want to clarify what our process is.' > > To me, this discussion feeds my prior belief that we need to continue > to emphasize the importance of active, engaged, mentors, and see their > absence in a podling as a problem that demands attention. > > There are people here (notable Greg) who are very skeptical of this > mentor-centric model. However, it seems to me that the consensus of > the community continues to be to try to tune/repair it, not replace > it. > > On Wed, Nov 28, 2012 at 9:41 AM, ant elder wrote: >> On Wed, Nov 28, 2012 at 2:32 PM, Bertrand Delacretaz >> wrote: >> >>> On Wed, Nov 28, 2012 at 3:24 PM, ant elder wrote: ...Slow poddlings don't use much ASF resource so aren't a burden... >>> >>> I disagree: podlings do use mentor's energy - graduating or retiring >>> them is a way to free up mentors for other incoming podlings. >>> >> >> I did say "If there are willing participants" which includes the mentors. >> >> And I don't think looking at mentors as a pot of resource is the correct >> view. >> >> ...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: Retirement decision making
On Wed, Nov 28, 2012 at 3:41 PM, ant elder wrote: > On Wed, Nov 28, 2012 at 2:32 PM, Bertrand Delacretaz > wrote: > >> On Wed, Nov 28, 2012 at 3:24 PM, ant elder wrote: >> > ...Slow poddlings don't use much ASF resource so aren't a burden... >> >> I disagree: podlings do use mentor's energy - graduating or retiring >> them is a way to free up mentors for other incoming podlings. >> > > I did say "If there are willing participants" which includes the mentors. > > And I don't think looking at mentors as a pot of resource is the correct > view. The ASF slogan is: Community over Code. If there is no community, why should there be code? A single person is simply not a community. If there were at least two or three people, then there would be a community. In the case of Chukwa I see it like that: is there somebody else (mentor or contributor) interested in Chukwa? If yes, go ahead. If no, move to github. The criteria are the same as when entering the incubator. Most people oppose an incubation when there is community. And if there are no mentors, there is no incubation too. That said, why shouldn't we just check if this is true for Chukwa? Cheers Christian > >...ant -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
The question of a time limit is like other questions we deal with: we don't want to set a hard limit, but the idea of incubation going along for years and years is not consistent with the vision of what the incubator is. Sam was at pains to present this dilemma, not to ask for some kind of hard limit. Ross, I can now see how your 'follow the mentors' model should have the effect of solving this problem, too. I didn't start this thread with 'we have a broken process,' I started it with, 'I want to clarify what our process is.' To me, this discussion feeds my prior belief that we need to continue to emphasize the importance of active, engaged, mentors, and see their absence in a podling as a problem that demands attention. There are people here (notable Greg) who are very skeptical of this mentor-centric model. However, it seems to me that the consensus of the community continues to be to try to tune/repair it, not replace it. On Wed, Nov 28, 2012 at 9:41 AM, ant elder wrote: > On Wed, Nov 28, 2012 at 2:32 PM, Bertrand Delacretaz > wrote: > >> On Wed, Nov 28, 2012 at 3:24 PM, ant elder wrote: >> > ...Slow poddlings don't use much ASF resource so aren't a burden... >> >> I disagree: podlings do use mentor's energy - graduating or retiring >> them is a way to free up mentors for other incoming podlings. >> > > I did say "If there are willing participants" which includes the mentors. > > And I don't think looking at mentors as a pot of resource is the correct > view. > >...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On Wed, Nov 28, 2012 at 2:32 PM, Bertrand Delacretaz wrote: > On Wed, Nov 28, 2012 at 3:24 PM, ant elder wrote: > > ...Slow poddlings don't use much ASF resource so aren't a burden... > > I disagree: podlings do use mentor's energy - graduating or retiring > them is a way to free up mentors for other incoming podlings. > I did say "If there are willing participants" which includes the mentors. And I don't think looking at mentors as a pot of resource is the correct view. ...ant
Re: Retirement decision making
On 28 November 2012 14:32, Bertrand Delacretaz wrote: > On Wed, Nov 28, 2012 at 3:24 PM, ant elder wrote: > > ...Slow poddlings don't use much ASF resource so aren't a burden... > > I disagree: podlings do use mentor's energy - graduating or retiring > them is a way to free up mentors for other incoming podlings. > In practice what happens is mentors stop caring. Their time is not taken up because they are not mentoring the projects. Unfortunately this serves no purpose. Mentors who feel their time is not well used (or is unavailable on a podling should actively step down. If they did then my simple three step decision making process for retirement comes into play (i.e. they reach stage 3 which was where insufficient mentor support is available). Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: Retirement decision making
On Wed, Nov 28, 2012 at 3:24 PM, ant elder wrote: > ...Slow poddlings don't use much ASF resource so aren't a burden... I disagree: podlings do use mentor's energy - graduating or retiring them is a way to free up mentors for other incoming podlings. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On Wed, Nov 28, 2012 at 1:42 PM, Benson Margulies wrote: > I have only one point of discomfort with Ross' writing here. > > Ross's position, in this and other messages, seems to me to be that it > a podling can persist indefinitely, so long as (a) it has involved > mentors, and (b) there's no ongoing violation of Foundation policy. > > I have two reasons to wonder about this. > > 1: My recollection of the original set of messages from the Board by > way of Sam were that indefinite residence in the incubator was a > problem, even well properly supervised. > > 2: While I appreciate that mentors are not entirely fungible, I tend > to think in terms of a limited pool of volunteer effort, so indefinite > incubation worries me. > > Neither of these are a reason to change the short-term outcome of > Chuckwa, one way or the other. I'm thinking of starting a Wiki page on > the Incubator's mission and scope that might result in a clarification > of (1). As for (2), Ross' formulation in this message, and in others, > is to help the community to find consensus by offering a constructive > logical view. It's always better to do that than to reach, or worry > about, an impasse. > > Retirement of small poddlings in a lot of cases will in reality mean death. As much as its said they can just move to github or somewhere else because the poddling is small and not so active there's probably not going to be enough people with enough spare time to make the move successfully. They'll have to migrate their website which could be a lot of work especially if its CMS based one which isn't even available outside the ASF so will require a complete rewrite, they'll have to rename things like org.apache Java package names which would be a major blow and would likely lose many of their already small number of existing users. Etc etc for all the other ASF provided infrastructure. Retirement seems like a harsh and drastic action, and unless there is a pressing need i think we should try to avoid it. Slow poddlings don't use much ASF resource so aren't a burden. If there are willing participants and ASF polices aren't being flagrantly breached then i don't see a problem with a lengthy incubation. You mentioned Sam, he and others said a lot of things back in that discussion you refer to not all of which were speaking for the board, FWIR the one subsequent summary message from the board talked about oversight not time limits, but i can't find the email, can anyone? Anyway, i don't think Chuwka is at the limit yet whatever it may be, so while there is a semblance of another plan i think its worth a shot continuing. An alternative to long incubation is graduation. I've already mentioned Wink, Apache Steve is another interesting example - few committers, commit activity there was low and sporadic with many months at a time with zero activity, and no evidence of things like community building or promotion or all the other things being suggested. But Steve skipped incubation entirely and went straight to being a TLP. The Incubator has a bunch of policies and guidelines and perceptions on what it takes to be ready for graduation, what i think it really boils down to (IP clearance etc aside) is do we trust the participants - will they do the right thing, will they follow The Apache Way? I think what we really want is to find ways to be more trusting and so more easily enable graduation. (and yes i agree with the procedures outlined in Ross's email) ...ant
Re: Retirement decision making
On 28 November 2012 13:42, Benson Margulies wrote: > I have only one point of discomfort with Ross' writing here. > > Ross's position, in this and other messages, seems to me to be that it > a podling can persist indefinitely, so long as (a) it has involved > mentors, and (b) there's no ongoing violation of Foundation policy. > > I have two reasons to wonder about this. > > 1: My recollection of the original set of messages from the Board by > way of Sam were that indefinite residence in the incubator was a > problem, even well properly supervised. > I agree indefinite incubation is a problem and my suggestion is not intended to allow it. The Incubator was always designed to scale in a self contained and managed way. If a project could muster sufficient mentors then it could enter incubation. If it can retain sufficient mentor interest it can remain. My mail simply restates this original design feature. I hope that when Sam expressed his concerns he didn't intend to say that there should be a time limit. I hope he meant there should be active efforts to graduate projects. I don't see that my view is in conflict with this. Perhaps the problem is that the IPMC has lost sight of the self-regulating model designed for it. I feel that we started to loose sight of the fact that the mentor role is one of support and guidance on how to get from "here" to graduation. We began to treat the mentor role as a rubber-stamping exercise. The shepherd role is a nice lightweight approach to catching when mentoring is not doing the job it should (helping chart the course from "here" to graduation). In the case of Chuckwa this model is working well. A mentor expressed an informed opinion, the community respond to that opinion. The IPMC demands a new plan to get from "here" to graduation and some new mentors step up. In x months time I expect those mentors to report successful progress towards graduation or I expect them to be recommending retirement from an informed position rather than an uniformed observer vote on the general@incubatorlist. I didn't vote this time around as I didn't have the time to review and couldn't see consensus in the community. Next time I will be better informed as a result of the recent discussion and will have the opinions of new mentors I trust to dig a little deeper in the coming months. I see this as validation of the existing process, not evidence that the process is broken and needs to change. Ross > > Neither of these are a reason to change the short-term outcome of > Chuckwa, one way or the other. I'm thinking of starting a Wiki page on > the Incubator's mission and scope that might result in a clarification > of (1). As for (2), Ross' formulation in this message, and in others, > is to help the community to find consensus by offering a constructive > logical view. It's always better to do that than to reach, or worry > about, an impasse. > > > > On Wed, Nov 28, 2012 at 8:35 AM, Benson Margulies > wrote: > > On Wed, Nov 28, 2012 at 8:32 AM, Benson Margulies > wrote: > >> The current vote thread for retirement of Chukwa, coupled with some of > >> the other discussion threads, raises some questions that need to be > >> resolved. > >> > >> How do we make retirement decisions? > >> > >> http://incubator.apache.org/guides/retirement.html says: > >> > >> "Before following the retirement steps, the remaining developers of > >> the project should be informed and vote should happen on the projects > >> dev list. After the vote, the IPMC must vote on the general list to > >> retire the project. > >> > >> In some cases the developers of a project might be opposed to > >> retirement, while the IPMC is in favour because its members cannot see > >> a succesfull graduation now or in future. In this case the IPMC > >> _decides_ about the retirement." > >> > >> In general, Apache projects strive to reach decisions by consensus, > >> using votes to memorialize consensus. > >> > >> In the Chukwa case, there seems to have been a consensus some months > >> ago about how things would proceed. However, I don't think it's > >> reasonable to view that decision as a self-operating process in which > >> the community pre-decided exactly how and when the plug would be > >> pulled. Actually deciding to retire the project, over the objections > >> of even one of its contributors, is a decision point that the > >> community has to cope with -- however frustrating this may be for > >> mentors. > >> > >> So, in hindsight, it would have been good to have a [DISCUSS] thread > >> in which the mentors could present their view, Eric could argue back, > >> and other people could pose questions of clarification. If people > >> really want to compare to Wink, someone could do the necessary > >> slogging to bring forth real comparative data for Wink. > >> > >> But let's imagine that we have a DISCUSS thread and a clear lack of > >> consensus. In essence, that's what the current [VOTE] thread amounts > >> to. Now what? Do
Re: Retirement decision making
On Wed, Nov 28, 2012 at 8:42 AM, Benson Margulies wrote: > 2: While I appreciate that mentors are not entirely fungible, I tend > to think in terms of a limited pool of volunteer effort, so indefinite > incubation worries me. It's their decision to volunteer their efforts in that way so I don't think the IPMC should have any worries with how mentors spend their time - let's leave that for their spouses to worry with. I suggest a policy of "A project will be retired from the incubator when it is the consensus of the PPMC or when the PPMC fails to attract enough qualified mentors." ... in hopes that the second half of that will ultimately address the 'indefinite' concern... Thanks, --tim - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
I have only one point of discomfort with Ross' writing here. Ross's position, in this and other messages, seems to me to be that it a podling can persist indefinitely, so long as (a) it has involved mentors, and (b) there's no ongoing violation of Foundation policy. I have two reasons to wonder about this. 1: My recollection of the original set of messages from the Board by way of Sam were that indefinite residence in the incubator was a problem, even well properly supervised. 2: While I appreciate that mentors are not entirely fungible, I tend to think in terms of a limited pool of volunteer effort, so indefinite incubation worries me. Neither of these are a reason to change the short-term outcome of Chuckwa, one way or the other. I'm thinking of starting a Wiki page on the Incubator's mission and scope that might result in a clarification of (1). As for (2), Ross' formulation in this message, and in others, is to help the community to find consensus by offering a constructive logical view. It's always better to do that than to reach, or worry about, an impasse. On Wed, Nov 28, 2012 at 8:35 AM, Benson Margulies wrote: > On Wed, Nov 28, 2012 at 8:32 AM, Benson Margulies > wrote: >> The current vote thread for retirement of Chukwa, coupled with some of >> the other discussion threads, raises some questions that need to be >> resolved. >> >> How do we make retirement decisions? >> >> http://incubator.apache.org/guides/retirement.html says: >> >> "Before following the retirement steps, the remaining developers of >> the project should be informed and vote should happen on the projects >> dev list. After the vote, the IPMC must vote on the general list to >> retire the project. >> >> In some cases the developers of a project might be opposed to >> retirement, while the IPMC is in favour because its members cannot see >> a succesfull graduation now or in future. In this case the IPMC >> _decides_ about the retirement." >> >> In general, Apache projects strive to reach decisions by consensus, >> using votes to memorialize consensus. >> >> In the Chukwa case, there seems to have been a consensus some months >> ago about how things would proceed. However, I don't think it's >> reasonable to view that decision as a self-operating process in which >> the community pre-decided exactly how and when the plug would be >> pulled. Actually deciding to retire the project, over the objections >> of even one of its contributors, is a decision point that the >> community has to cope with -- however frustrating this may be for >> mentors. >> >> So, in hindsight, it would have been good to have a [DISCUSS] thread >> in which the mentors could present their view, Eric could argue back, >> and other people could pose questions of clarification. If people >> really want to compare to Wink, someone could do the necessary >> slogging to bring forth real comparative data for Wink. >> >> But let's imagine that we have a DISCUSS thread and a clear lack of >> consensus. In essence, that's what the current [VOTE] thread amounts >> to. Now what? Do we say, 'well, in the absence of consensus, we must >> continue the podling'? Do we say this even in the absence of enough >> mentors willing to supervise it? >> >> I stupidly posted an initial version of this question to private@, and >> Ross replied with some very clear thinking on this, which I trust that >> he will re-send to this thread. I'll stop here and wait for that. >> >> --benson > > Here are Ross' remarks: > > In my opinion retirement should not be a decision made by a VOTE of the IPMC. > > Firstly, the ASF is not governed by votes, it is governed by > consensus. Secondly, in votes people often pile on without doing the > appropriate background work (a +/-1 is easier than discussing the > various options to reach consensus). > > Votes in the ASF are usually used to confirm consensus that has > already been achieved through discussion. So, in addition to > supporting your suggestion to have a [DISCUSS] thread before a [VOTE] > thread I suggest we follow the following guidelines with respect to > podling retirement: > > 1) If the PPMC unanimously recommends retirement, it gets retired. No > need for a VOTE, just notify the IPMC, leave for 72 hours minimum and > retire it. > > 2) If the mentors say it should be retired but the PPMC does not > unanimously agree then the podling should seek to recruit new mentors. > No need to VOTE, just get on with it. > > 3) If there insufficient mentors willing to continue working with the > project then the IPMC has a problem to address on a case by case > basis. The shepherd role ensures that these cases are spotted during > the reporting process. If necessary a [DISCUSS} thread can be started > and a sensible plan is developed (which may include a VOTE to retire, > at this point there should be no -1's as a -1 needs to be backed by a > willingness to act and thus this should have been surfaced in case 2) > above. > > Note, this is exactl
Re: Retirement decision making
On Wed, Nov 28, 2012 at 8:32 AM, Benson Margulies wrote: > The current vote thread for retirement of Chukwa, coupled with some of > the other discussion threads, raises some questions that need to be > resolved. > > How do we make retirement decisions? > > http://incubator.apache.org/guides/retirement.html says: > > "Before following the retirement steps, the remaining developers of > the project should be informed and vote should happen on the projects > dev list. After the vote, the IPMC must vote on the general list to > retire the project. > > In some cases the developers of a project might be opposed to > retirement, while the IPMC is in favour because its members cannot see > a succesfull graduation now or in future. In this case the IPMC > _decides_ about the retirement." > > In general, Apache projects strive to reach decisions by consensus, > using votes to memorialize consensus. > > In the Chukwa case, there seems to have been a consensus some months > ago about how things would proceed. However, I don't think it's > reasonable to view that decision as a self-operating process in which > the community pre-decided exactly how and when the plug would be > pulled. Actually deciding to retire the project, over the objections > of even one of its contributors, is a decision point that the > community has to cope with -- however frustrating this may be for > mentors. > > So, in hindsight, it would have been good to have a [DISCUSS] thread > in which the mentors could present their view, Eric could argue back, > and other people could pose questions of clarification. If people > really want to compare to Wink, someone could do the necessary > slogging to bring forth real comparative data for Wink. > > But let's imagine that we have a DISCUSS thread and a clear lack of > consensus. In essence, that's what the current [VOTE] thread amounts > to. Now what? Do we say, 'well, in the absence of consensus, we must > continue the podling'? Do we say this even in the absence of enough > mentors willing to supervise it? > > I stupidly posted an initial version of this question to private@, and > Ross replied with some very clear thinking on this, which I trust that > he will re-send to this thread. I'll stop here and wait for that. > > --benson Here are Ross' remarks: In my opinion retirement should not be a decision made by a VOTE of the IPMC. Firstly, the ASF is not governed by votes, it is governed by consensus. Secondly, in votes people often pile on without doing the appropriate background work (a +/-1 is easier than discussing the various options to reach consensus). Votes in the ASF are usually used to confirm consensus that has already been achieved through discussion. So, in addition to supporting your suggestion to have a [DISCUSS] thread before a [VOTE] thread I suggest we follow the following guidelines with respect to podling retirement: 1) If the PPMC unanimously recommends retirement, it gets retired. No need for a VOTE, just notify the IPMC, leave for 72 hours minimum and retire it. 2) If the mentors say it should be retired but the PPMC does not unanimously agree then the podling should seek to recruit new mentors. No need to VOTE, just get on with it. 3) If there insufficient mentors willing to continue working with the project then the IPMC has a problem to address on a case by case basis. The shepherd role ensures that these cases are spotted during the reporting process. If necessary a [DISCUSS} thread can be started and a sensible plan is developed (which may include a VOTE to retire, at this point there should be no -1's as a -1 needs to be backed by a willingness to act and thus this should have been surfaced in case 2) above. Note, this is exactly what happens with board oversight of TLPs, the language and role titles change but in general the board merely implement the wishes of the community. The only time the board makes an actual decision is when the community is breaking down for some reason. This is done on a case by case basis after spending time trying to understand the situation (case 3) above) Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
