incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Mentors and Voting on Podling Releases
Date Tue, 12 Mar 2019 17:04:01 GMT
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
- 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 <> 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.


> As I understood Craig this goes in the same direction as he (and also others) think we
should go.
> Best
> Julian
> [1]
> [2]
> [3]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message