Those sound like fine experiments to try - having a release auditor, and a new podling with the PPMC have binding votes and initially seeded just with IPMC members - however they aren't the experiments i was thinking of.
What i'd like to try is more similar to the pTLP approach previously talked about. So take some existing podling, eg Stratos and/or VXQuery, and give the PPMC binding votes. They have experienced and active mentors so there will be oversight and nothing to worry about. They already have experienced participants so know what they're doing anyway. Anyone on the Incubator PMC can join in or watch what happens and intervene at any point to have the experiment shutdown in the unlikely event that they go wild. Its just a small experimental trial. Even if successful this likely wouldn't ever become the approach used for most podlings, but it could be a useful step for some. Lets give it a try. What do you say? ...ant On Wed, Nov 13, 2013 at 7:05 PM, Suresh Marru <sma...@apache.org> wrote: > On Nov 13, 2013, at 1:14 PM, Marvin Humphrey <mar...@rectangular.com> wrote: > >> On Tue, Nov 12, 2013 at 11:58 PM, ant elder <ant.el...@gmail.com> wrote: >>> So, we _can_ let podlings have their own binding release votes and we >>> could do our own "pTLP" type experiments without even needing to go to >>> the board. We should try that. Not for every podling but just for >>> select ones where the circumstances mean it will work better than the >>> current approach. If there are no major objections to some experiments >>> with this approach then i'd like to start trying one. >> >> +1 to run an experiment. The position that Roy has taken changes the >> equation. >> >> While a number of people have expressed a preference for the approach of >> electing more podling contributors directly onto the IPMC, in practice it >> remains uncertain whether the IPMC is capable of identifying, nominating and >> voting in enough candidates -- as evidenced by some threads currently in >> progress on private@incubator. >> >> I propose that the experiment take the following form: >> >> 1. The initial PPMC shall be composed exclusively of IPMC members. >> 2. PPMC votes are binding for every release except the first. >> 3. One IPMC vote is required for each release after the first. >> >> I believe that this model provides sufficient oversight because the first >> release must cross a high bar, and because it changes the dynamics of >> electing PPMC members: even core contributors will now have to earn PPMC >> membership, demonstrating to an initial PPMC composed of IPMC members that >> they understand the Apache Way well enough to steward their project. > > + 1, I like this balance and caveats. > > In my personal view (which I am not generalizing), getting the first release > is very time consuming but educational and very much worth it. I do not look > at it as one month or so for a release is unreasonable, but rather think it > as, one month amortized over quality subsequent releases. Which ever approach > or policy changes we take, we still need patient incumbents and overly > patient mentors. The only way mentors scale is to teach the process and groom > new teachers. Ofcourse not many students will like the teachers until they > also become teachers. Atleast this happened to me, I appreciate my mentors > more now then when I was a student :) > > Suresh > >> >> Marvin Humphrey >> >> --------------------------------------------------------------------- >> 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
