Hi Julian - Thanks for bringing this discussion to general@.
I think that there are two calls to action here: (1) How can Mentors service the Podlings they have volunteered to help by VOTING on releases? For me the issues can be any of: - The Release was not discussed on the dev@ list until the VOTE is called. - 72 hours may not be enough time to find the cycles. - I know the podling is going to call the next step on general@ and if I don’t have time then I can defer and VOTE later (or not.) - I sometimes resent feeling like the only active mentor. These are my human reasons. I am a volunteer and no one is paying me to do this. (2) Documentation and guidance can be improved. - The incubator site is mostly in Github at https://github.com/apache/incubator/tree/master/pages <https://github.com/apache/incubator/tree/master/pages> - PRs after discussions are welcome. My current distraction/obsession is INCUBATOR-231 which will improve the site. I am looking to make a Podling’s status and issues easier to see and act upon. More inline. > On Mar 12, 2019, at 2:19 AM, Julian Feinauer <j.feina...@pragmaticminds.de> > wrote: > > Hi all, > > I just wanted to bring back a short summary of a discussion we had with Craig > Russel on a private list regarding the role of podling mentors in the release > approval process. > And as there are currently many thoughts and discussions going on about these > topics, I thought it would be good to have the essence of the discussion > public. > > Basically the point was when mentors should vote. In the IPMC Vote only or > already in the Podlings Vote. > > Currently, the rules state that the approval of a podling release can only be > given by IPMC Vote, see [1] and [2]. > Both these documents do not mention the “mentor” explicitly but only speak of > the podling and the IPMC. > Also, the role of the mentor does say nothing about releases [3] and > describes the mentor (as I read it) more as a lawyer of the podling with > regards to the IPMC (and not vice versa). > On the other hand, with the current dimension of the incubator, there is a > huge “load” of approvals put on the IPMC. To me the responsibility of the Mentor is to the Podling to provide guidance to the podling community in how to interact with the Apache Software Foundation. Mentors should be able to direct the podling to the following committees and resources: - Infrastructure for Resources and Release Distribution Policy - Legal-Discuss for License interpretation and Release Policy - Brand/Trademarks for Name Search, Logos, and Website organization. Also, large event approval. - Press for announcements within the rules for podlings. - ComDev for community information like the maturity model and help with events. - Conference committee. We should not duplicate documentation, but should point to the Foundation docs. To me the Incubator is about. - Entry of a project community - proposal - Bootstrap by Champion and Mentors - Watching that Podlings are making progress and helping mentors help the community. - Making sure that Release and Release Distribution Policies are followed. > > So I thought if it wouldn’t be possible to discuss and perhaps redefine the > mentor role a bit with regards to release approval or voting. > My observation is, that often times the IPMC vote consists mostly of votes > from mentors (or PPMCs who happen to be also IPMC members) and from very few > other IPMC members. > I also think that this makes sense, as mentors follow the projects closely > and can have an eye on the specifics of the project and have a strong > relation to the project which makes them decide to vote for the project. Mentors also need to encourage discussion on the dev@ list, discourage discussion which should be public on the private@ list, and encourage the podling to recognize contributors who merit becoming committers and PPMC members. > > On the other hand it would be a too big of a change (I guess) to simply skip > the IPMC Vote and change it to a “Mentor-only” vote (and also Craig raised a > lot of reasonable concerns and “technical” difficulties about what changes > this would impose). Only if we can get exceptions to the Release and Release Distribution Policies. We can argue and guess the effect on how many releases before graduation. Some might think that this will slow graduation, but others might say increased release cadence to the point the release is good would be an improvement. There is a reason some podlings keep doing “unapproved” releases. I think by getting an exception we will smooth this transition. If there is consensus to try this then someone will need to bring the concept to the Legal Affairs committee through a LEGAL jira. > > But perhaps one could find a sensible compromise to e.g. motivate mentors to > vote in the PPMC Vote and also state this in the IPMC Vote thread (how many > mentors / IPMC members already voted). > This would make it easier for the other IPMC members to scan through these > mails and see if they have the feeling that they should also check the > release or if they feel confident enough about the podling. > And if 3 IPMC members already voted in the PPMC Vote one could simply close > the Vote 72h later if no one else went active without big overhead. Exactly and then we can use the [REVIEW] or [DISCUSS] to get IPMC feedback. Regards, Dave > > As I understood Craig this goes in the same direction as he (and also others) > think we should go. > > Best > Julian > > [1] https://incubator.apache.org/policy/incubation.html#releases > [2] https://incubator.apache.org/guides/releasemanagement.html > [3] https://incubator.apache.org/policy/roles_and_responsibilities.html#mentor >
