incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Date Tue, 20 Jan 2015 00:37:55 GMT
I agree with Andrew. Creating a sub-board of the most vocal members of
the IPMC distills its dysfunction.

But this doesn't require consensus. The proposals focus on identifying
the "true" members of the IPMC; clearly, the authors believe
themselves to be among the elect. So make a list of the IPMC members
you believe should judge the other 90%, and submit a proposal to the
board to start a new project. Fork the incubator.

If the board is interested in your proposal, then you can demonstrate
how successful a small, committed group can be in contrast to the 150+
member IPMC. Concurrently, others may propose TLPs directly to the
board, and this committee will continue as-is.

Surely all of you have better things to do than... this. -C

On Mon, Jan 19, 2015 at 3:55 PM, Andrew Purtell <apurtell@apache.org> wrote:
> 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message