On 7 November 2013 22:22, Marvin Humphrey <mar...@rectangular.com> wrote:
> > > Concretely, there are several possible implementations. > > There's this pTLP variant: > > 1. Start with a Board resolution establishing a pTLP PMC seeded with IPMC > members. > 2. Vote podling contributors onto the PMC as they demonstrate merit. > 3. When there are enough PMC members, consider graduation. > +1 this is essentially what I proposed for the pTLP experiment with Stratos. I wrote the proposal up in outline on the Stratos dev list a few days after the podling got started. Unfortunately the mentors who signed up to oversee that experiment never found the time to do so. I still think this is an approach worth exploring more fully and will be happy to sig out that email for you if it would help. > > A more incremental approach, suggested upthread, is to start voting select > podling contributors onto the IPMC more aggressively. However, there are a > few drawbacks: > > * With rare exceptions, podling contributors have generally been voted > onto > the IPMC to replace missing Mentors. Rewarding excellence proactively > is > a completely different mentality. For example, under this model it > would > have been *wrong* that CloudStack made it through to graduation without > landing at least two of its stellar contributors on the IPMC. > * Enlarging the IPMC makes a lot of people uncomfortable. I'm leery that > increasing the pace too much may provoke controversy and "too many > cooks" > squabbling. > The too many cooks problem has solutions too. This approach is just fine as long as the IPMC membership as a whole doesn't regularly interject in projects they are not fully up to speed with. There are proposed solutions to this issue in the wiki. Pick one and try it out. > * The private@incubator list would get a lot noisier. > Why? There should be nothing on private other than voting in new members and the occasional sensitive issue. Votes are easily managed in mail clients (or switch to using Steve) and having more IPMC members shouldn't increase the number of sensitive issues. > > Then there's the suggestion of electing "Podling Chairs", possibly > augmented > with Co-Chairs. Granting extra privileges to a solo leader seems somewhat > less Apache-like than rewarding merit on an individual basis. However, in > practice having a podling Chair would solve *other* problems in addition to > mitigating the problem of vote scarcity, and it would probably be the least > controversial option to implement. > > Would "Podling Chairs" join the IPMC, presumably voted in by the podling's > Mentors? If not, how would we grant them a binding vote? > This would create one vote per project, so probably doesn't solve the issue. I'm not sure this adds much over the idea of making some podling members IPMC members. Personally I wouldn't waste my time on this, but it is an incremental step towards the bigger idea. While I wouldn't bother with this if I were chair I do understand the "least controversial" argument and thus this might be a good step to take. > > Also, if a new person gets voted in as "Podling Chair", are we OK with the > podling's increasing IPMC representation? (I think that could have the > desirable side effect of encouraging project founders to give up the > "Podling > Chair" position for the greater good of the podling.) > See my too many cooks comment above. It does create slower growth so again a more incremental step. In summary I am +1 on you picking any of these and implementing them. All are reversible steps. Good luck. Ross > > Marvin Humphrey > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
