incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: Cultivating Outstanding IP Stewards
Date Fri, 08 Nov 2013 07:59:06 GMT
On 7 November 2013 22:22, Marvin Humphrey <marvin@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message