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)
