Hi,
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.
+1
> 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 have?
> To graduate both must be accomplished.
+1
> (2) With this service orientation what are the duties of Mentors? Here is my
> non exhaustive list.
> - 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 services.
> - 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 influence)
- 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 3?
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.
+1
> (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 file.
> - 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 TLPs
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 IPMC.
On TLP only PMC members can approve releases, given the mentors are now
committers can their votes binding on release?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
