Lots to distill here...
> On Mar 1, 2019, at 2:15 PM, Justin Mclean <jus...@classsoftware.com> wrote:
>
> 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.
I agree that it's not ideal but it is not a symptom of a big problem either. We
have inactive IPMC members who might become active again later if a community
wants to join the incubator but it's a hassle to leave and then join again.
>
>> (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?
From my perspective, the legal issues discussed here are overblown. By the time
a podling graduates, they have to learn how to make a perfect release. During
incubation, they have to make releases, not all of which have to be perfect.
That's what we need to keep in mind. The podling releases have a disclaimer
that the releases may not be perfect.
So my takeaway is that we should give podlings a bit more leeway on their first
(few) releases. Nothing bad will happen by noting what needs to be changed but
letting out the release. As long as the podling shows that they can fix bad
releases in the next cycle, all's good.
But I don't think we gain anything by trying to bypass the three +1 rule for
releases. The IPMC must approve releases according to the rules that every PMC
has to adhere to. If the mentors are doing their job, podling releases should
have had a good review before coming to the IPMC for approval. And if there are
three mentors voting on the dev list, they can decide if a "bad" podling
release should block external review/release. Once a podling has three mentor
reviews and three mentor +1 votes, the IPMC should step back.
But if a podling can't get their mentors to review and vote, that is the
problem we should focus on. But if the larger IPMC needs to review a podling
release because mentors have not done, we should give them a bit more leeway
and allow e.g. binaries in the release, old copyright notices in code, license
files with too much information. As long as the podling understands (in
writing) why these are issues.
>
>> 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.
I'd restate this: Review podling releases and document the deficiencies. Help
move toward perfection.
>> - 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
i.e. Document the release process in a public place.
> - 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.
I agree. Once they graduate, they will need three binding +1 votes. Why confuse
things?
>
>> (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.)
I think that we need to take a closer look at the github repository migration.
In the past, it was easier to bring a code base into the incubator because it
was always a copy operation, not a move. So these things were explicitly
possible:
1. There were no questions about the legitimacy of copying a repository from an
existing location and starting work in Apache simultaneously with the old
project committers working on the old repository.
2. The old project could continue to make releases while the Apache podling was
setting up shop.
3. The SGA/ICLA was a gate to exiting the incubator not entering the incubator.
But with the new strategy of moving the github repository, we need to take care
that the committers on the old project are ok with losing their rights to
commit to the repository pending the podling setup. This is one reason for the
lengthy migration. And why I recommend that the podling decide on a
repository-by-repository strategy for migration. And explicitly allow continued
releases from the old repository while the podling is setting up.
>> - 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?
I would prefer that we continue on the path we are on with the podlings
explicitly noting whether they need more help from their mentors.
>
>> (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.
I honestly do not see how reducing the size of the IPMC solves anything. From
what I've seen, the biggest issue is how to get mentors to be more involved
with their podlings. How does reducing address mentor involvement?
Regards, Craig
>
>> - 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
>
Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo
<http://db.apache.org/jdo>
