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

Reply via email to