incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: proposal: mentor re-boot
Date Wed, 07 Jan 2015 20:09:30 GMT

> On Jan 7, 2015, at 11:35 AM, Upayavira <> wrote:
> On Wed, Jan 7, 2015, at 06:46 PM, jan i wrote:
>> On 7 January 2015 at 19:32, Alan D. Cabrera <> wrote:
>>>> On Jan 7, 2015, at 10:13 AM, Branko Čibej <> wrote:
>>>> On 07.01.2015 18:42, Alan D. Cabrera wrote:
>>>>> I’ve written up a more comprehensive proposal that would not only hold
>>> mentors accountable but also give them a fair bit of autonomous authority
>>> during releases.
>>>>> <
>> "Being put on hold means that no committers can be added, no PPMC members
>> can be added, and no releases can be performed"
>> This would be a no go for me. If a podling has lost a mentor, but are
>> actively seeking a new mentor, the IPMC must step in to accept a new
>> committer, PPMC member or release. The IPMC has accepted the podling, so
>> it
>> is very unfair, to punish a podling, that does a active job to replace a
>> mentor.
> The IPMC *cannot* replace a mentor. We have no power to make someone
> take on that role. Alan, please add a section to your doc about the fact
> that podlings retain responsibility for engaging with their mentors, and
> for recruiting replacements should a mentor quit or go AWOL.

A very good idea.  Though I will quickly add that I think that Jan meant to say “it is unfair
to make the podling recruit a new mentor to replace the removed mentor”.

> It is great to clarify the responsibilities of mentors, but please let's
> set the expectations and responsibilities of podling members, otherwise
> we keep this idea that the Incubator PMC is a body that has power to do
> things (like make someone step up as a mentor for a project), which it
> doesn't.

Yes, definitely.  This is the document that I alluded to in the proposal, "mentors must acknowledge
that they will perform their duties as out lined in a clearly defined document".  I wanted
to garner consensus on the broad strokes before filling it in, but since the initial reaction
seems to generally favorable, I should probably create that now.


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