The proposed need to announce release votes on the IPMC list is how things were when the incubator was created. The need for IPMC to control the process is another case of the IPMC over-reaching itself and in so doing causing problems by creating a bottleneck in the process.
It used to be that it was only required to *notify* the IPMC of a release vote underway. Thereby giving interested IPMC members the opportunity to review artifacts and processes during the normal release cycle. IPMC members were expected to cast their votes on the PPMC list where such things belong. I'm not sure where this idea that the vote actually occurs on the IPMC list came from but it's flat wrong in my opinion (someone may dig through the archives and find a good reason it was changed, but my feeling is that it changed gradually through edits-on-edits-on-edits of the incubation policy). The fact is that the PPMC (with IPMC representation from the mentors) should be in charge of their releases, and pretty much everything else. The IPMC role is one of teaching the PPMC how manage itself. Mentors should do this through mentoring and the IPMC should ensure it is done through an appropriate level of oversight (not an inappropriate amount of control). Consider this... The board does not bring TLP release votes to board@, why on earth must the IPMC do so? I've half a mind to got back the wayback machine and pull the original incubator polices and propose them as the "new" policies (yes, some changes have been good, but it seems to me that many have not) Ross -----Original Message----- From: Konstantin Boudnik [mailto:c...@apache.org] Sent: Sunday, July 26, 2015 5:15 PM To: general@incubator.apache.org Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator) On Sun, Jul 26, 2015 at 01:38PM, Branko Čibej wrote: > On 26.07.2015 10:56, jan i wrote: > > On 26 July 2015 at 10:40, Justin Mclean <jus...@classsoftware.com> wrote: > > > >> Hi, > >> > >>> About 40% of the last 100 threads on general@ is "vote release"... > >>> Cut > >> that > >>> away is a good start in reforming the Incubator… > >> IMO Which provides a valuable service in showing poddlings on how > >> to make good releases. Do we want to get rid of that? > >> > > No that is an important service, on the other hand I also agree that > > the mentors should be guiding/running the podlings not general@ > > > > Maybe we can find some middle ground. > > - Mentors "run" the podlings, can accept releases etc. > > - Mentors decide when a podlng can graduate (maybe with some form > > of, needs to accepted by all mentors of the project) > > - Any release must be announced (not voted) on general@, so that > > people like you have a chance of controlling it just like today. > > > > I think this would make incubator a lot more efficient, reduce our > > inboxes, and give us spare time to concentrate on other things. > > I like this proposal very much. One of the constant frustrations in > the podlings I'd mentored was the delay between release bits being > ready and the IPMC getting around to vote. It's now a lot better than > it was a couple years ago, when in some instances it took a month or more ... > > 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. > > The other frustration is of course evident in the Ignite graduation > discussion. > > 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. > > Other than that, big +1. I like the idea of the post factum release reviews. It doesn't mean that IPMC at large aren't welcome to jump in and help with the podling release voting. Perhaps a sane and courteous thing would be to Cc: general@ on the podling [VOTE] thread? But +1 even as it stands right now. One of the moot points that has came up a few times recently about the diversity clause in the graduation guidelines. Namely: "A major criterion for graduation is to have developed an open and diverse meritocratic community. Time has demonstrated that these kinds of communities are more robust and productive than more closed ones." The semantic of "diverse" isn't clear and is being interpreted in different ways. I'd like to propose to change the above paragraph to "A major criterion for graduation is to have developed an open and meritocratic community. Time has demonstrated that these kinds of communities are more robust and productive than more closed ones." to avoid possible confusing interpretations in the future. Regards, Cos --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
