> On Mar 22, 2016, at 11:25 AM, John D. Ament <johndam...@apache.org> wrote: > > On Tue, Mar 22, 2016 at 12:19 PM Marvin Humphrey <mar...@rectangular.com> > wrote: > >> On Mon, Mar 21, 2016 at 9:57 AM, Craig Russell <craig.russ...@oracle.com> >> wrote: >>> There is a sorta technical reason for the Champion to be a member of the >> PMC >>> of the sponsor. >>> >>> I’d expect the Champion to subscribe to the private@ list and to have >>> binding votes on podling releases. These both require PMC membership. >>> >>> The alternative is to create two different “exceptions” that would allow >>> Champions to subscribe to private@ and to have binding release votes. >> >> These are legitimate concerns that would need to be dealt should such an >> unlikely scenario arise. However, I don't think we need to carve >> exceptions >> into policy here -- other creative solutions are available, like voting the >> Champion onto the Sponsor PMC. >> > > Moreso, the champion is responsible for bringing the project into the ASF. > The Champion holds no bearing on the project after that point. > > It sounds like what we're being pitched here is that the champion must stay > on to mentor the project. That hasn't been followed too much.
I did not think this thread was discussing the role of the Champion, just the pre-requisites. http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion During incubation, the Champion: • Coordinates the creation and timely delivery of the podling's board reports. • Keeps an eye on the mentors' activity and takes action (ask for new mentors, talk to the Incubator PMC) if they don't seem to provide enough oversight or mentorship to the podling, The podling can elect a new Champion at any time, and must notify the Incubator PMC when that happens. The podling reports indicate who the current Champion is, and that information is kept up to date in the Incubator PMC's records (currently content/podlings.xml@champion). Craig > > >> >> And I'd like to take this opportunity to make a more general point: >> >> Policy should be simple. >> >> There are many reasons that policy should be simple, and I'm sure others >> will >> be happy to weigh in with their own favorites. But for me, this is the >> most compelling: >> >> Complexity harms newcomers. >> >> Right now, Apache's rules are so complex that we are all in perpetual >> violation. You can't even know what all the rules are! >> >> In such an environment, success is dependent, not on your own ability, but >> on >> securing alliances with powerful insiders who can help you bend or break >> the rules. >> >> This state of affairs is not worthy of our core principles. Particularly >> since the ASF does not exercise technical control over its projects, what >> we >> do here is not really that complicated. >> >> Apache, and the Incubator in particular, welcomes newcomers. It should be >> possible for a newcomers to discover and follow our rules largely through >> their own efforts. >> >> Of course a rejoinder to "Policy should be simple" is "As simple as >> possible >> and no simpler". But how close are we to "as simple as possible"? >> >> Marvin Humphrey >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> Craig L Russell Architect craig.russ...@oracle.com P.S. A good JDO? O, Gasp! --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
