Hi Dave,
thanks for your feedback.
I totally agree with what you say and from all the discussions I read, I have
the impression that there is a good direction where many IPMC members think
this should be going and the "right" points are addressed.
Regarding the release process: We just had a discussion in a podling to do
regular releases but agreed that to discuss the topic futher AFTER graduation
to keep the workload for the IPMC low.
So I fully agree that we should find a way to make the release process smooth
for both sides, especially the IPMC to allow Podlings to keep their (official)
releases frequent (which is especially important for young projects) without
too much work for the IPMC members.
I am mostly involved in incubating projects, thus I have a bit of a different
perspective and will happily share my impressions in the discussion and also
help to update docs or so to make things smoother.
So please come back to me whenever you need help on these matters.
Best
Julian
Am 12.03.19, 18:04 schrieb "Dave Fisher" <dave2w...@comcast.net>:
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
