incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <>
Subject Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))
Date Fri, 01 Mar 2019 22:15:42 GMT

Thanks for taking to time to distill this.

> Many PMCs contain what could be called inactive PMC members. The concern is if that makes
any difference or impedes the active IPMC members. I’m not sure how inactive IPMC members
are impacting the functioning of the IPMC.

I also don’t think it is a concern, but as others have raised it as one, and it’s something
that can be easily changed (and undone if needed). Small reversible steps and all that.

> (1) The purpose of the Incubator is to introduce project communities of individuals to
The Apache Way and help them come into alignment with those principles.


> Currently, I think that the "Legal Shield” value has been elevated above the Community
aspect.Communities are harmed because coming to the ASF can be a sharp, direct change in how
they operate and this is a negative disruption. In some podlings the Community aspect of the
Apache Way is harder than Legal and in others Legal is harder.

Do we need to ask the board to spend more on the legal shield? (I don't know what we pay now
or how it is worded.) Do these suggested changes required it to be changed? Or do we make
need to make podlings aware that they do not have legal protections if's might assume they

> To graduate both must be accomplished.


> (2) With this service orientation what are the duties of Mentors? Here is my non exhaustive
> - Boot the Podling Community by making sure that podling community is setup in Apache
Infra with Mailing Lists, CLAs, SGAs, LDAP, Code Repositories, Issue Trackers, etc. 
> - Make sure that decisions are memorialized on the Mailing Lists and how that benefits
the community.
> - Make sure that the PPMC is recognizing contributors and growing the community.
> - Make sure that the podling’s releases meet ASF Legal, Distribution and Release policies
and why that is important.
> - Make sure that the podling understands Branding issues in order to protect their community.
> - Make sure that the podling understands the ASF committee structure in order to find
> - Do all of the above in a gentle, respectful manner.
> - Keep track of the above to protect the podling.
> - Guide the podling in how to report to the IPMC (and later the Board)
> - Defend the podling if the IPMC or Apache is too demanding.

Great list I’d also add:
- Make sure the podling acts in a way that’s free from corporate influence
- That the podling acts in a respectful manner to people on it list and the wider ASF and
is aware of our code of conduct
- Makes sure they understand consensus and when to (and not to) vote
- Make sure that releases are repeatable and the knowledge of how to do them captured
- That they recognises and vote in new committers and PPMC members
- No BDFY in the making
- Comply with incubator policy on making press releases while in incubation (see corporate
- They don’t get avoid the ASF release policy by making release elsewhere and call those
ASF releases.

And there probably a few other things that have slipped my mind.

For the suggested changed it may be best to separate them out and have seperate discussion
and votes on each.

> (A) On general@ replace [VOTE] on releases with [DISCUSS] or [REVIEW]. The podling would
do the release and the review would consist of both Release and Distribution Policy compliance.
> - 3 or more PPMC votes are still required.
> - It is an open question about how many IPMC votes we should require. Is it 0, 1, or

I would say 3, lets not added yet another voting method, podling (and it seems old ASF members)
get confused as it is.

> (B) Explicitly evaluate Podling Proposals for the following:
> - if the PPMC has several Apache Members the IPMC should recommend direct to TLP.
> - explicitly make sure that
> 	(i) there is at least one mentor who is experienced via successful incubation.
> 	(ii) that the mentors all have a clear understanding of the Apache Way.
> 	(iii) that they currently have enough free time to do the necessary work.
> - confirm what SGAs will be required and assure that these will be signed quickly. (Podlings
and Mentors have trouble if it takes the better part of a year for the SGA to happen.)
> - the above may require updates to the proposal template.


> (C) Formalize the Shepherd role as follows.
> - Permanently assign a Shepherd to every podling.
> - The shepherd tracks mentor engagement.
> - The shepherd tracks progress of podlings and updates the content/podlings/${podling}.yml
> - The shepherd “sends” report reminders and is a backstop for the Mentors. 
> - Shepherds are IPMC members whose touch is generally very light like the Board is with

Podling already have shepherd they don’t tend to do much (with some exceptions) and we have
a shortage of them. How do we recruit more / ensure they do the task they are assigned? Do
we require sign off from them on the report for it to be accepted?

> (D) Recruit Mentors.
> - The IPMC should send periodic emails to members@
> - The IPMC should periodically ask ComDev if there is anyone active there to recommend
as a Mentor.

+1 and the IPMC has done several things recent to improve this. Others include:
- identifying inactive mentors and asking them if they want to cary on
- asking podlings if their mentors are active on the report
- meeting people we may not be aware of propose themselves for consideration

> (E) Change the IPMC structure (this depends on whether we change the podling release
VOTE rules)
> - IPMC members are reduced to those who have successfully mentored a project through
to graduation and affirmatively wish to remain on the IPMC.

I’ve not looked at the number but this may leave many existing podlings with a reduced set
of mentors. That may be unfair to mentors (and their podlings) who are active.

> - Other mentors are like committers and are either Apache Members or voted on by the

On TLP only PMC members can approve releases, given the mentors are now committers can their
votes binding on release?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message