incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Date Mon, 19 Jan 2015 23:55:38 GMT
I think the cures are all problematic and might be worse than the disease.


On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik <rvs@apache.org> wrote:

> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rvs@apache.org> wrote:
> > Hi!
> >
> > at this point we have had a few lively threads
> > discussing three somewhat different proposals:
> >    #1 mentor re-boot
> >    #2 pTLP
> >    #3 Ross's strawman http://s.apache.org/8eS
> > it feels to me that all three need additional work
> > to be done before we can have any reasonable
> > consensus around them (let alone voting).
> >
> > Wearing my chair hat, I would like to suggest that
> > the next step should be: for each proposal we identify
> > points that are going to block consensus (AKA would
> > result in -1 vote if it comes to a vote). I suggest we
> > do it on the wiki pages themselves (I'll wikify Ross's
> > proposal tonight). Not editing the wikis but simply
> > collecting this feedback as the last section in each
> > proposal. The idea would be to identify all such
> > points in a week or so.
> >
> > Sounds good?
>
> To follow up. Each of the proposals:
>     https://wiki.apache.org/incubator/MentorRebootProposal


​"​An active mentor is removed from a podling if that mentor does not
review/sign off on a release."

​The above implies the foundation has a pool of mentors able to
consistently meet every reporting requirement in a timely manner, without
regard to personal or professional obstacles.​ I don't see it. For an
organization almost entirely made up of volunteers this seems overly
optimistic. There is only a small core membership who are capable and
willing to do this as evidenced by a skim of history of general@incubator
and members@. Perhaps this core group will end up shouldering the
incubation load in its entirety. Although sadly this is more or less the
current state of affairs, individual podlings do come with new mentors not
part of the "professional membership" motivated to see at least that
specific podling through. It's also risky to expect mentors kicked from a
podling to be okay with it and want to try again, especially if listed on
some "naughty list" to the board.



>
>     https://wiki.apache.org/incubator/Strawman


​"​Only ASF members on the PPMC will have binding votes for the releases."

​This proposal seems better than the others in my estimation, but doesn't
allow podlings full investment in their own release management. The members
on the PPMC who have binding votes will drive the release process out of
necessity. Once the podling graduates and the members on the PPMC leave to
resume other interests or duties, only then for the first time is the
project running their own releases. I think it was better to let the
podling own their release process but have the IPMC (or equivalent) have an
up-or-down vote afterward as a check on their activities.



>
>     https://wiki.apache.org/incubator/IncubatorV2
>

This proposal revokes merit earned by existing IPMC members and reboots
incubator supervision as a "sub-board" limited to 15 members. How members
apply to this board is not specified. It is suggested the current board
make recommendations to the board for their replacements, a very
unmeritocratic suggestion that is quite surprising. It's not clear at all
how the membership can address issues with this "sub-board" as they can
with the Board. I think this proposal takes the likely outcome of the first
proposal, that only a small core group of "professional membership" can
manage sufficient activity as mentors to not be kicked from podlings, and
codifies it with new structure and bylaws. Maybe in the end this is
admitting reality. However, discussion of this proposal also floated the
idea that the "sub-board" be later given authority to supervise the affairs
of established TLPs, which is deeply problematic* and I suspect still
hovers in the wings. I would hope not.

"All proposals for new ASF projects must include an initial PMC chair and
an initial set of PMC members. These people must be acceptable to the
board. It is the responsibility of the Incubator Committee to vett these
people. All of them must have experience on existing PMCs"

This doubles down on the aspect of the Strawman proposal where PPMC members
are powerless to vote on releases. Here they are powerless to make any and
all project management decisions about their own software they brought to
Apache. It's not mentoring if you make all of the decisions for them.

​* - Find me any PMC of any TLP that would ​welcome the self-introduction
of newly empowered meddlers who by definition are uninformed of their
project particulars.



> now has the feedback gathering section at the end.
> I am done with my personal feedback. Please provide
> yours.
>
> Here's the criteria you can apply when deciding whether
> to spend time on this or not: imagine that the proposal
> the way it is written were to come to a vote. If at that point
> you'd be inclined to vote -1 -- please let us know NOW.
>
> Using a VOTE thread as a forcing function for folks to
> provide feedback would be *really* unfortunate.
>
> Also, please try to keep 'deal breakers' section as small
> as possible (pushing all the non-critical piece of your
> feedback to the 'suggestions' section). When in doubt
> (even if it is -0) -- make it go to suggestions.
>
> The only items that belong to 'dealbreakers' are the ones
> that would *strongly* motivate you to vote -1
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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