incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Date Tue, 20 Jan 2015 19:55:00 GMT
It may already be a “practice" but it is not part of the mentor-reboot proposal.


Regards,
Alan

> On Jan 20, 2015, at 11:17 AM, Andrew Purtell <apurtell@apache.org> wrote:
> 
> I just experienced being placed on a naughty list in the last incubator
> report because I was travelling for business and missed checking the box
> for HTrace. It may not be on any specific proposal. It seems to already be
> in practice.
> 
> 
> 
> On Tue, Jan 20, 2015 at 6:36 AM, Alan D. Cabrera <list@toolazydogs.com>
> wrote:
> 
>> Can you add your concerns to the end each of the wiki pages?
>> 
>> I intend to update my proposal to clear up the apprehensions that you seem
>> to have.  You can then remove/amend your concerns from the wiki proposal.
>> I will quickly state that “naughty lists” are not part of the mentor-reboot
>> proposal.
>> 
>> 
>> Thanks!
>> 
>> 
>> Regards,
>> Alan
>> 
>>> On 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
>> <mailto: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 <
>> 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 <
>> 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)
>> 
>> 
> 
> 
> -- 
> 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