> On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman <nic...@hedhman.org> wrote:
>> About 40% of the last 100 threads on general@ is "vote release"... >> Cut that away is a good start in reforming the Incubator… Many of those vote threads are very high quality and valuable. Successful vote threads are short: a few +1 votes and it's over. Frequently, those +1 votes will be accompanied by a description what was reviewed. Unsuccessful vote threads yield targeted action items and cogent explanations. Since the end of 2013, when the Incubator community established an improved consensus about release requirements, fewer RCs get rejected and rancor has been rare. On Sun, Jul 26, 2015 at 4:38 AM, Branko Čibej <br...@apache.org> wrote: > It's now a lot better than it was a > couple years ago, when in some instances it took a month or more ... Yes, we have for the most part solved the problem of RCs twisting in the wind. Both proposals in this thread will bring that problem back. Mentor attrition is a fundamental law of the Incubator: because Mentors are not core contributors, they fall away at increased rate. It is not possible to change that fact, only to compensate for it. The wider IPMC has a certain limited capacity for picking up the slack on release votes. Since the end of 2013, we have been using that precious capacity wisely. These proposals squander that capacity and put it all back on the Mentors. Some of those Mentors will be unavailable when they are needed, compounding the difficulties faced by smaller and more troubled podlings. > Concretely: I think it's perfectly OK to review podling releases after > the fact. The incubation disclaimer tells users clearly enough that they > should be extra careful when using releases from incubating projects. We routinely see problematic release candidates on general@incubator. It would seem that the expertise and temperament for exacting release QC is not evenly distributed among the Mentor corps -- just like other valuable skills and talents. Since 2013, the wider IPMC in collaboration with Mentors has been working well at cleaning up problematic releases in an expedited manner -- and once a podling is producing clean releases regularly, it is probably nearing graduation and will not be affected by the extra 3 days for long. I don't see any urgency to change this dynamic. > The other frustration is of course evident in the Ignite graduation > discussion. The outcome of the Ignite graduation discussion was never in doubt. The wider IPMC was never going to vote down graduation when there were multiple attentive Ignite Mentors united in favor -- it was only a matter of time before people came around. I think the discussion was more voluminous than it needed to be, but I attribute that to individual participants sending too many emails in one day. 1-2 per day on a given thread is a good rate. In the meantime, interested podling observers got to witness a decent debate on project independence and off-list dev discussion -- which is generally one of the hardest aspects of Apache-style open development to master. > The only downside of this proposal is that it assumes that every podling > has at least three active (!) mentors. That doesn't always happen; and > currently we expect the podling to chase down inactive mentors or find > new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more > active role in finding mentors for podlings. Recruiting Mentors for podlings at any stage other than entry has always been difficult. It would be deeply unfair to small podlings to establish a policy which denies this reality. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
