On Sat, May 31, 2014 at 10:18 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: >> Regardless, I guess my real question is this: if a podling feels that they >> need to achieve a certain milestone in software completeness before >> they can confidently graduate, are we really in a position to push >> them out of the incubator somewhat against their will? > > I can imagine situations in which you'd graduate a podling that has a > diverse and self-managing PPMC and advise the PMC to work with Press, or > Infra, or Brand, or Comdev post-graduation to improve some aspect or > another.
I can't. If the community doesn't think it is ready the best you can do is try to persuade them that they are ready, but not graduate by force. > Back to the instance at hand: the project reported that adding a feature > is a graduation blocker. That is unusual. The likely explanation is > that they misunderstood what graduation is about. The situation should > therefore be checked. > If the project has a misunderstanding then it > should be corrected, and if it doesn't then it'd be better if they > clarified in future reports why they, unusually, consider adding a > feature to be a graduation blocker. That's a good point, but see below. > A podling was asked "Has your community grown" and replied that the > statistics server was down. To me, that's not a satisfactory answer, > for the same reason that (with car drivers) a broken speedometer is not > a carte blanche to speeding. I'd agree with you in theory. In practice, the only way for this kind of checks-n-balances to happen is for mentors to stay super engaged and take it onto themselves to address these kind of issues during report review within the community (before the report is every submitted to the wiki). Perhaps this email thread will be a reminder to all the mentors out there to make sure they follow up ASAP. The next best thing (just as Marvin proposed) would be for the entire report to be submitted for a short review window (instead of just shepherding notes). That would also engage the entire IPMC community, but only as a measure of last resort where we ourselves would flag this issues to both mentors and the board. At the end of the day -- just like the board is a hammer, not a scalpel, IPMC (as a collective) is not a proper tool for the kind of intricate job you've meant in your replies. Our only hope is to have good mentors. > Time for reductio ad absurdum. Never a good move on an email thread ;-) Thanks, Roman. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
