If you want to simplify policy, get rid of the champion. Or rather, reduce the champion’s role to nominating a project for incubation. Once the project has entered incubation, the champion’s role ends.
While Calcite was in incubation no one (including the champion) had a clue what the role of the champion was. Was the champion implicitly on the PPMC? Did they have a binding vote? Were they implicitly a mentor? If we needed karma to do xyz, should we email the champion or the mentors? It would be simpler if there were just mentors. And of course the champion can become a mentor if he/she wants to. Julian > On Mar 22, 2016, at 11:39 AM, Craig Russell <craig.russ...@oracle.com> wrote: > >> >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org