Re: Welcome Craig McClanahan in his continued membership in the IPMC
Yay! Welcome back Craig! =) - Henry On Tue, Nov 27, 2012 at 5:44 AM, Benson Margulies wrote: > Craig is returning to active duty as a mentor. He never actually quite > managed to leave this PMC, but anyhow we're happy to see him around. > > - > 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 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
Permission on Jira log4j2
Hi Ralph, could you make Gary and me Admins of the log4j2 Jira project? I think it would make sense cheers Christian -- 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
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: What constitute a successful project?
Hi all. I've been following this discussion for a while, collecting my thoughts. I think I've actually come around to Eric Y's feeling here: the project is closer to graduation than to retirement. Chukwa, as a community, has a few distinctive features. The system is specialized big-data infrastructure, and it's mature enough to be used in production. That has a few consequences: 1) It's not going to have a high rate of change; it's more maintenance than new development. 2) It's not going to be an easy project for hobbyists to contribute to, since testing requires access to big infrastructure for extended periods. 3) There is a small set of highly motivated users, who are really using the code, and therefore have strong incentives to keep the project healthy. My sense is that the community is needed more for support and maintenance than for major rewriting. And my sense is that the community is able to do that. As Eric points out, there have been a bunch of patches from people who weren't original core developers. As part of the podling growth strategy: I think it would be good to cut some releases. Let's see if the community has enough energy to test and vote on release candidates. Let's see how well people understand the Apache release process. I'd like, if possible, for somebody new to be the release manager. Eric and I have both cut releases before and I would take it as a strong good sign if somebody new stepped up. If the community has enough energy and activity to respond to user queries and to do regular releases,I would think it was a plausible graduation candidate. --Ari On Wed, Nov 28, 2012 at 2:12 AM, Eric Yang wrote: > Continue the retirement vote, and see if it passes in IPMC. If it does, I > will gladly setup shop in github. If it doesn't, Chukwa community should > prepare for Chukwa 0.6.0 release, and start voting on Chukwa 0.6.0 release, > and follow by vote for graduation. Content in Chukwa trunk contains a > number of good features and fixes generated by the community. I really > appreciate the support by Incubator community to make this possible. Does > this sound like a plan? > -- Ari Rabkin asrab...@gmail.com Princeton Computer Science Department - 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: How to grow podling communities
Let me note, that one can use Apache software (Openmeetings Incubating) to run video conferences simply by using the following URL http://demo.dataved.ru/public/?firstname=Ross&lastname=Gardler -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Wed, Nov 28, 2012 at 1:03 AM, Ross Gardler wrote: > Forgot a couple for the list... > > Lucy is running a book club - they meet on Google Hangouts and discuss how an > appropriate book chapter might apply to their project. This was recently > reported in their board report and early feedback is very positive. > > OpenOffice are building a "course" for new community members. The goal is to > guide people through the learning process around contribution with regular > check-ins with the community lists where the community works hard to > congratulate and welcome. > > Ross > > > >> -Original Message- >> From: Luciano Resende [mailto:luckbr1...@gmail.com] >> Sent: 27 November 2012 17:40 >> To: general@incubator.apache.org >> Subject: Re: How to grow podling communities >> >> On Mon, Nov 26, 2012 at 3:50 PM, Ross Gardler >> wrote: >> >> > Growing community is about "getting the message out there". There has >> > to be someone in the project who wants to do that. Some techniques are: >> > >> > - press >> > - community events >> > - mentoring (that is mentoring of potential new committers) >> > - fast turnaround on patch reviews >> > - regular releases >> > - decent website >> > - tutorials >> > - screencasts >> > - public discussion (even with self while no community exists) >> > >> > Developing code for one's own use is all well can good but it does not >> > build community and trying to build community doesn't, in the short >> > term, write code. It's a catch-22. >> > >> > Personally I have no problem with a podling having low activity. A >> > single developer doing their thing in the incubator is not going to hurt >> anyone. >> > What I'm concerned about is a podling that is not doing any of the >> > above community development activities or, even worse, is ignoring >> > potential contributors. >> > >> > I don't think it is the responsibility of ComDev to do this, although >> > one could argue ComDev should be documenting these techniques in ways >> > useful to mentors. I don't think it is the job of mentors (or the >> > IPMC) to do this either. It is entirely the PPMC responsibility. In my >> > opinion. >> > >> > >> This is exactly things that I want to bring up to the podling attentions, a >> list of >> things that they could do to try to build/increase the community. >> Once we collect a list of them, we can document it and use it as suggestions >> for struggling podlings. >> >> My main goal is to avoid mentors coming to a podling and telling them its >> time to retire, but pointing them to resources that can help them get out of >> the retirement situation. >> >> The IPMC and ComDev should always be here to help, documenting the >> things that have worked in the past, and facilitating access to resources >> that >> can help the podlings. >> >> -- >> Luciano Resende >> http://people.apache.org/~lresende >> http://twitter.com/lresende1975 >> http://lresende.blogspot.com/ > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] Retire Chukwa from incubation
I'm sending this message a placeholder to move our process from a [VOTE] to a [DISCUSS]. However, I'd encourage people to read Ross' thoughts on the subject of retirement decision-making before contributing here. We don't have to repost all the thinking from the [VOTE] thread; we do have to reach a consensus, but, much as it pains me to be 'Mr Process' here, I think we need to be clear on how we are going about it first. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire Chukwa from incubation
_Please Consider This Vote Thread Closed_ As chair, I feel confident that a [VOTE] was not the right step to take at this time. Ongoing _discussion_ is entirely on point. I do not think that it is appropriate to tally this thread and declare a result. I am going to reply to this thread changing the subject to [DISCUSS], and we'll see what we have in the way of a consensus. On Wed, Nov 28, 2012 at 8:46 AM, Alexei Fedotov wrote: > Let me rephrase the question. Could the actual reason behind Chukwa > retirement be related to the fact, that there exist Flume and Kafka > which gives users same opportunites to manage distributed systems? I > better understand this before trying to spread the word about joinging > Chukwa community. > > If this is the case, could it be that there are ways to mergre > projects somehow, e.g. provide Chukwa API on the top of Flume or > Kafka? > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Tue, Nov 27, 2012 at 6:23 PM, Alexei Fedotov > wrote: >> Hello guys, >> I want to understand Chukwa community building strategy better. Are >> there any insights why companies which use Hadoop (in Moscow those >> include Deutche Bank, Yandex, Rambler and Microsoft) do not crowd >> around or stay in line to get a chance to use Chukwa? >> >> -- >> With best regards / с наилучшими пожеланиями, >> Alexei Fedotov / Алексей Федотов, >> http://dataved.ru/ >> +7 916 562 8095 >> >> >> On Tue, Nov 27, 2012 at 3:55 PM, ant elder wrote: >>> On Tue, Nov 27, 2012 at 11:48 AM, Benson Margulies >>> wrote: >>> One interesting point about consensus decision-making process is the need to define the starting point. The process assumes that there is a clear 'status quo', and that a consensus is required to change it. This may not always be the appropriate way to think about retiring a podling, but it's clearly the way we're thinking about this one. Does anyone else feel that this could have benefitted from a [DISCUSS] before the [VOTE]. At the bottom line, if there are new mentors to be fully responsible, I think it's reasonable to continue; however, I don't want to have exactly the same conversation in N months. Would the new mentors like to propose a time limit, and is the group willing to subscribe to the notion that, if after that time, the new mentors have the same report as the old mentors, we're at the end? >>> Could we maybe include a time limit next month with the credible plan to >>> give new mentors a little time to get up to speed with the project? >>> >>>...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: [VOTE] Retire Chukwa from incubation
Let me rephrase the question. Could the actual reason behind Chukwa retirement be related to the fact, that there exist Flume and Kafka which gives users same opportunites to manage distributed systems? I better understand this before trying to spread the word about joinging Chukwa community. If this is the case, could it be that there are ways to mergre projects somehow, e.g. provide Chukwa API on the top of Flume or Kafka? -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Tue, Nov 27, 2012 at 6:23 PM, Alexei Fedotov wrote: > Hello guys, > I want to understand Chukwa community building strategy better. Are > there any insights why companies which use Hadoop (in Moscow those > include Deutche Bank, Yandex, Rambler and Microsoft) do not crowd > around or stay in line to get a chance to use Chukwa? > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Tue, Nov 27, 2012 at 3:55 PM, ant elder wrote: >> On Tue, Nov 27, 2012 at 11:48 AM, Benson Margulies >> wrote: >> >>> One interesting point about consensus decision-making process is the >>> need to define the starting point. The process assumes that there is a >>> clear 'status quo', and that a consensus is required to change it. >>> This may not always be the appropriate way to think about retiring a >>> podling, but it's clearly the way we're thinking about this one. >>> >>> Does anyone else feel that this could have benefitted from a [DISCUSS] >>> before the [VOTE]. >>> >>> At the bottom line, if there are new mentors to be fully responsible, >>> I think it's reasonable to continue; however, I don't want to have >>> exactly the same conversation in N months. Would the new mentors like >>> to propose a time limit, and is the group willing to subscribe to the >>> notion that, if after that time, the new mentors have the same report >>> as the old mentors, we're at the end? >>> >>> >> Could we maybe include a time limit next month with the credible plan to >> give new mentors a little time to get up to speed with the project? >> >>...ant - 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
