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 <apurt...@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 <l...@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 <apurt...@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 <r...@apache.org >> <mailto:r...@apache.org>> wrote: >>> >>>> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <r...@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-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@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)
