Hi -
> On Mar 1, 2019, at 7:23 AM, Kevin A. McGrail <kmcgr...@apache.org> wrote:
>
> On 3/1/2019 5:12 AM, Justin Mclean wrote:
>>> The Board isn't gonna worry about something like that.
>> I wasn’t expecting the board to say anything re that, but the IPMC could of.
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.
Members who join just to vote on a Proposal ought to be (a) a proposed Mentor
or (b) an initial PPMC member.
>
> I personally don't know the impact of that statement either. Sometimes
> opinion in a report and a call to action is helpful.
>
> What can I do to help fix this issue?
A number of issues were raised in these threads. I don’t think that extra
people on the IPMC is the issue with the highest priority. Davor and others
raised some points around Mentors and what it means to be one. Myrle had an
excellent incremental idea to soften the role of IPMC votes on releases to be
advisory reviews. In addition, Jim clearly asks the real question of what value
does the Incubator provide podlings? And is it serving its purpose and
following The Apache Way.
With those issues in mind:
(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. To graduate both must be
accomplished. Some podlings are very successful while still in the Incubator
while others atrophy.
(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.
Yes that is a big list and for each podling can be a large responsibility for a
mentor. It’s a high bar and I am sure I don’t always succeed. Between the three
or four mentors for a podling experience will tell us that one or two mentors
will never engage and the longer it takes to boot the podling community the
more who will drop. Some podling’s already have community members who
understand The Apache Way and these do very well.
(3) With the above duties what are the responsibilities of the IPMC? Here is my
list.
- Evaluate podling proposals and determine if the project is suitable.
- Make sure that podling Mentors are actively helping.
- Recruit more Mentors as needed.
- Tracking the progress of podlings towards graduation. Trust but verify
reports.
- Review podling releases to assure that they trend towards alignment with
Apache Policies.
- Recommend podling graduation to the Board.
- Retire podlings that are not viable or who wish to move on.
- Report to the Board.
I would like to suggest (repeat) some improvements. Some of these are more a
change in emphasis.
(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?
(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 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
(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.
(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.
- Other mentors are like committers and are either Apache Members or voted on
by the IPMC.
- Shepherds are IPMC members.
- Only IPMC votes are binding on accepting proposals.
- The IPMC could vote to recommend that a proposal be direct to TLP.
The hopeful net result here is that the IPMC will have a lighter and more
efficient approach to incubating projects.
Please think about this before responding with “spread the flow” criticisms. In
response please do not over snip the proposals.
Regards,
Dave
> --
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
