What exactly are we trying to achieve here? There is a record number of podlings in incubation and the best ideas so far are to shame more labor out of the people that are already overloaded. Sure that will work, as if burnout wasn't already a problem for mentors.
What is the lesson for the podling? That the only votes Apache cares about are those performed by people who have never vetted a single commit to the codebase? Is this what community based development is all about, where overworked bureaucrats put their fingers in various dykes pretending that only they can function as the true gatekeepers to the arcane secrets of the org? Is it any wonder where animosity towards the org by those being subjected to this mindset comes from, or that in the end what it breeds is more harmful to the overall mission to graduate healthy projects than any policy imperfections in podling releases overlooked by actual engineers trying to get shit out the door? Isn't that what the disclaimer is supposed to be there for, instead of yet another imposition on the victims of this nonsense? Grow up folks. On Wed, Apr 26, 2017 at 2:04 AM, Niclas Hedhman <nic...@hedhman.org> wrote: > Either you draw the parallels to the TLPs or you don't. > > If you do, TLPs don't have Mentors, but they do have a PMC, typically with > engaged members and a 'phone line" to the board in forms of a Chair. If the > "Chair" goes AWOL, then either the PMC members request help from the board > to appoint a new Chair, typically by submission of a resolution, or the > board notices that the phone is no longer ringing, in which case the PMC is > asked if it has died or not. > > Translate; > PMC -> Podling committers > PMC Chair -> Mentor > Board -> Incubator PMC > > Now, we have the complication that there are 3 mentors, sometimes all > assuming that the "others" will handle it, and podlings are unwise about > what is expected. > > I have argued before for a single Mentor, with responsibilities just like > the PMC Chairs and if failing the duties, duly replaced by IPMC. The > counter-argument to single Mentor is that podlings need 3 binding votes, > and I suggest to change the role names here to perhaps "Supporter" and the > Mentor simply emeritus any Supporter that is absent too long, and come to > IPMC to request more help. > > Hopefully, we can get to a position where podlings are not asking for IPMC > release votes, just like TLPs are not asking for Board's approval of > releases. > > And I think that if the Mentors are then keeping a up-to-date rooster on > Supporters, we have a pretty good overview of podlings' health. > > > Cheers > Niclas > > > > On Wed, Apr 26, 2017 at 1:37 PM, Bertrand Delacretaz < > bdelacre...@codeconsult.ch> wrote: > > > On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz <ptgo...@gmail.com> > > wrote: > > > ...I mostly agree, but would hesitate with the idea that a podling be > > responsible for raising a red flag > > > when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on > > us, not the projects we incubate.... > > > > The IPMC will typically not know before it's too late, so it's good > > for the podlings to raise those red flags - and ask the IPMC for help. > > > > -Bertrand > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org - New Energy for Java >
