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> 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 "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-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)
