Apache Incubator Issues - 2013 review and proposals

The goal of this page is to come up with concrete, actionable proposals for improving the Incubator's operation.

Recent (May 2013) discussions on the general@a.o list indicate that a number of improvements, or radical changes, could be beneficial to the Incubator, but it's very hard to get the big picture and to build consensus from that large pile of email.

To help converge on concrete proposals on which we can build consensus, I suggest listing individual issues below, with suggestions for improvements.

Please keep this as concise as possible so one doesn't need ages to review and comment. Link to other pages if you really need more space, but in general shorter messages have a better chance of being read understood.

Use an unique ID for each issue and suggestion below so we can refer to them precisely.

Please add your name in brackets when you add content here or comment on it.

Feel free to add as many issues and suggestions as you think makes sense, but if you can merge with existing content that's probably better.

Issue 01 - lack of mentor participation

Some podlings have mostly inactive mentors, and/or a stale list of mentors that doesn't reflect reality (Bertrand)

(Foo Barzinsky) - here's how Foo would comment on this.

Suggestions

01.1 As an annual Spring cleaning activity, ask all mentors to reconfirm their availability and motivation. Podlings that have no active mentors left will need to hunt for mentors or close shop. (Bertrand)

• (rgardler) - Could semi-automate this - if a mentor has not signed off a review in the last six months reconfirm availability and motivation
  

01.2 Before voting in a new podling, ask all mentors to explicitly state their availability and make sure there's enough for a robust set of mentors. (Bertrand)

01.3 Make sure each podling has an active champion, according to the expanded role described at http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion where the Champion looks over the podling in terms of mentoring activities. (Bertrand)

01.4 Require champions to supervise and report on the presence of mentors every month, and force action if that report is negative or missing (Benson)

01.5 The shepherd role should be done away with. Shepherds dilute the mentor role and creates a need of shepherding the shepherds. (Cabrera)

(wave) The shepherd role is misunderstood. If mentors are active then the shepherd has nothing to do.

(Cabrera) Agreed, 01.5 and 01.6 only make sense if we make mentors truly responsible.

01.6 The champion role should be done away with in spite of the fact that it is not a new role. Re-shuffling responsibilities amongst roles in an already confusing Incubator pantheon is not the way to go. Champions are another form of shepherds and does not approach the core problem, inactive mentors. No, what it merely does is effectively make the champion a mentor, a rose by any other name... (Cabrera)

(rgardler) Note the Champion role is not a new role, although some suggestions redefine the role. The Champion role has been there since day one. It was, as originally defined, important at the start of a project (helping in the initial formulation of the proposal, finding mentors, understanding the process etc.) Originally the champions job ended with acceptance of the podling and the mentors took over. I don't think we want to remove the original champion role, although an argument can be made for not expanding it further. See 01.8 for a suggestion which attempts to resolve the conflict between 01.4 and 01.6.

01.7 Each podling should have at least two active mentors. A mentor can mark them selves as inactive. Active mentors are required to vote on all releases and review all reports. Active mentors who do not do so automatically are marked inactive. A podling that does not have the minimum two active mentors is automatically frozen; no releases, no new committers/PPMC members. Podlings that are frozen for six months are moved to the attic. (Cabrera)

01.8 Instead of a Champion that remains responsible for a podling through incubation create the role of PPMC chair. This is a direct parallel to the role of PMC chair and carries all the same responsibilities with respect to reporting (including reporting any issues they have with respect to their community such as absent mentors). (rgardler)

(Cabrera) Another role with a new name. Choosing a podlings chair is a contentious issue and will discourage podling members that may have an interest in the chair. Plus, we are still stuck with inactive mentors monitoring the PPMC chair.

(ke4qqq) One of the goals is for the community to learn to be self-governing. I admit it's a difficult balance to achieve to get the right amount of mentor involvement to foster ownership and self-governance, but setting a champion up as a chair early on makes it more difficult in my eyes.

(rgardler) I don't agree it is a new role with a new name. It is part of a TLP. No problem introducing self-governance through self-appointed chair in the same way that a TLP would. Of course, it's just one option I just wanted to clarify what I meant. And for further clarity (ke4qqq) I agree, my thinking was that the PPMC chair would be a podling member (guided by the mentors).

01.9 The shepherd's role is to examine the podling community which includes detecting if the mentors are active. (wave)

Issue 02 - lack of progress towards graduation

Some podlings stay in the Incubator for way too long, in general graduation should happen within about one year. (Bertrand)

Currently 17 of the 35 poddlings, nearly half, are older than one year, almost 30% of poddlings are over two years old. Also, AFAIR we've never had the board reject a graduation proposal saying the poddling is not ready, which makes it seem possible we're being too conservative and holding back poddlings too long.

(Cabrera) - As for many of the suggestions below, I would have thought that mentors would already be doing this. Is this bit symptomatic if inactive mentors? I'm all for this. Great suggestions, but I am worried that we'll end up with a telephone book of obvious goals with no clear and specific guidelines.

(Bertrand) - As noted by Dave Fisher on general@a.o, lack of progress might be caused by various factors, including: inactive podling, missing mentors, no development, no release, podling thinks there is a prerequisite to graduation that is not really there, IP issues still in progress, infrastructure help needed, podling thinks it doesn't need mentors, podling thinks it needs more diversity.

Suggestions

02.1 Find volunteers to form a cleanup task force that looks at the "old" podlings and makes suggestions to either graduate or terminate them. There's nothing urgent, so if we have few volunteers they could probably look at just one podling per month to keep the workload low. (Bertrand)

02.2 Actively encourage podlings to graduate sooner. All they need is a) to have made a release with at least 3 +1 votes from potential PMC members and b) to have demonstrated that they understand the Apache Way (rgardler)

02.3 For "old" poddlings that have met most of the Incubator requirements but are being held back from graduating due to size/diversity/activity/whatEverItIsThatsTakingTime assign mentors to the new PMC to provide oversight and then just graduate the poddling (perhaps with a special label like "probationary TLP" or "board managed poddling")(ant)

(Cabrera) - All this does is get the problem podling off the books. The intrinsic problems that plague it in the Incubator, most likely lack of interest from the larger community, as well as the requirement for oversight and oversight of the oversight will still exist. I would like to hear the reasons for a small slow podling because, IMHO, a small slow podling growing into a large vibrant community is an unchallenged myth.

(ant) A large vibrant community is not a requirement for being a TLP and lots of existing TLPs are small and slow, we just need the poddling to have a reasonable chance of being self sustaining

(rgardler) To me 02.2 and 02.3 are almost the same thing. A mentor certainly counts as a "potential PMC member" (I don't want to assume mentors will be PMC members upon graduation). For me there is no need for the special label in this case. This would bring the IPMC role back to what it was originally set out to be - to ensure incoming products could find their way within the Apache Way (see original resolution at https://whimsy.apache.org/board/minutes/Incubator.html

(ant) I agree 02.2 and 02.3 are almost the same thing. A problem is what to do with small slow poddlings, and that topic comes up regularly, sometimes mentors are added and the poddling graduates, othertimes small slow poddlings just get stuck here. The Incubator isn't really adding any value we're just waiting for them to do a bit more and then they'd graduate. We need some way to make it easier to let them go which is one thing the new label might help do. These are the current poddlings over a year old that have done a release and met most other requirements with some analysis of why they are still here. I've suggested eight of them could graduate, though I don't expect everyone will agree with that!

02.4 Podlings have one year to graduate. If they do not then the podling is automatically put in the attic. The podling can re-apply to be accepted provided it proven that the deficiencies that prevented graduation are well on their way to being remedied and has the requisite two active mentors. Hard and fast rules seem cruel but are much more fair and efficient; witness the huge email storms every time we treat a podling differently. (Cabrera)

Issue 03 - Too many cooks spoil the IPMC broth

The IPMC is a large and noisy place where success are not celebrated and problems are quickly amplified due to size and varied approaches of IPMC membership (rgardler)

(Cabrera) - IMNSHO, it's this Montessori School of podling management that has gotten us here to begin with. With the myriad of precedents that are always being set no wonder it's confusing for both IPMC members and podlings.

Suggestions

03.1 Mentor responsibilities are limited to their own podlings - if they are not a mentor they don't have a say in other podlings activities. A smaller sub-group manage the IPMC's broader supporting role (graduation votes, report compilation, release vote assistance, mentor recruitment etc.) (rgardler)

(Cabrera) How does someone like Sebb participate?

(rgardler) He is made a mentor on the projects he wants to mentor. The idea that only ASF Members understand community development is nonsense. If a podling wants them and the IPMC feels they are good enough then make them mentors.

03.2 A mentor must be a part of the IPMC, but only starts to have a say in IPMC matters when they are an active mentor for 2+ podlings (upayavira)

(Benson) To take these suggestions, we have to explicitly turn the IPMC into something structurally different from an ordinary PMC, in effect if not in 'legal' structure. That is, we could adopt these suggestions by convention, while retaining the usual PMC structure in which everybody has a binding vote. Or we could explicitly create structure in which different people have votes in different cases. Since, at the end of the day, all the authority is granted by the board to the VP, the VP could in theory operate such a structure, and the question would be whether the board rejected it or not when reported.

(ant) What that sounds like is we're trying to find something that makes the Incubator more like an ordinary PMC, i.e make mentor equivalent to committer, and only make mentors PMC members after they've demonstrated merit. A problem with that would be mentors not getting binding votes on poddling releases. Maybe that doesn't matter, part of being an Incubator PMC member could be having to do release reviews.

(Bertrand) You could also see that as an "Incubator board" that drives the Incubator. Mentors are still IPMC members, but votes on matters of Incubator governance are delegated to a smaller subset.

Issue 04 - Horrible signal-to-noise ratio on general@a.o for podling contributors

They're made to subscribe to general@ and to sift through vast amounts of noise to find guidance and policy changes, and when they post things like release votes there they can get ignored for weeks.

(Cabrera) IMO, the cause of this is the constant change of our policies and organization. As an IPMC member I am obligated to keep track of such discussions. Moving the discussions off to another mailing list or adding a [GOV] subject does little to solve the real churn. While 300-500 messages per month doesn't seem like much for some individuals, remember that 100 emails can arrive within one or two days. Juggling 300-500 messages per month on top of monitoring the podling traffic does not seem reasonable to me, personally.

(ke4qqq) I'll personally disagree with the premise for this issue. Having just come through incubation, seeing the various discussions on general@i.a.o helped set expectations, and provided lots of insight without having to run into the specific issues myself. 300-500 messages per month doesn't strike me as particularly high volume to begin with. The issue of ignored podlings on the list is a different matter.

(ant) i can see it could be useful for poddling participants to see all the mails but they will still be able to on the new list which would be public. Think of it as like the dev@/user@ split, there are good reasons on a busy project to move all the internal dev discussion off the user list and the same applies here.

Suggestions

04.1 Move internal Incubator PMC chatter off general@ to another mailing list (eg dev@?) (ant)

04.2 Instead of separate lists, just require a [GOV] subject line tag on discussions about the Incubator's governance. I like exposing podling contributors to the general Incubator traffic as it helps get a sense of how Apache works. (Bertrand)

(Cabrera) IMO, this will just get us mailing threads that have 120 messages with the [GOV] subject line tag. Maybe we can have the person who started the [GOV] thread provide daily summaries, [GOV][SUMMARY[ subject line tag.

04.3 Instead of separate lists and/or special subject line tag, a wiki page like this is created with a problem statement and ideas to solve the problem. (Cabrera)

Issue 05 - Inadequate reporting

Podlings frequently fail to meet minimal reporting requirements necessary for the IPMC report to be complete. All too often, podlings fail, altogether, to report. I've never seen anyone add a release to the list at the top of the report. Even podlings that do report fail to indicate when they are suffering from mentor inattention (benson)

Suggestions

05.1 Reject reports that do not include this information and request an updated report the following month. (rgardler)

05.2 Whilst we don't want to create a template for podling reporting (reporting is not a checkbox exercise) we could create an online form for submitting reports which ensured essential information (last release date, last committer added, mentor signoff etc.) was present. The majority of the report would still be a free-form text box. This form could be used to construct the report for VP Incubator. (rgardler)

Um, we have a template. My script generates them every month. Somehow, podlings don't even make it as far as editing the wiki and filling it in. (benson)

05.3 Using the definition of active mentors above, missing reports automatically marks the mentors as inactive. In this case the podling looses "quorum" and is automatically frozen. That seems like pretty good motivation to get the report done. And if it is not, then maybe it's time for the podling to move on. (Cabrera)

Issue 06 - Podlings status metadata is not reliable

Information about each podling is stored in SVN at content/podlings.xml (see notes). It is used to assist everyone to immediately know the state of any podling. It is data for various management facilities such as which projects are due to report each month. Some initial metadata is used for infrastructure operations. However for many podlings this file is out-of-date and incomplete. (crossley)

Suggestions

06.1 Encourage each podling to take more care of their status metadata. Mentors and others can help to oversee, but each podling project team should attend to it. Projects should learn to be self-sufficient from the very start of incubation and continue through as a TLP. (crossley)

(rgardler) See my suggestion 05.2, perhaps the suggested reporting form could also be used to ensure meta-data were updated e.g. do a timestamp check and ask for confirmation that it is up-to-date. Also have the release/committer etc fields read only and pull the info from the meta-data thus forcing an update in order to have accurate board reports (we must be careful not to make reporting and data collection a chore, can these suggested tools make life easier?)

06.2 Make sure important data comes from a single place. Lists of mentors, for example, are often duplicated and inconsistent between the podlings.xml file, podlings status files and podlings websites. http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings.xml can be displayed in a browser, so instead of copies we could point to it.

(crossley) Each podling's status page can reliably refer directly to their section of the page that is automatically generated from that master file (see notes) e.g. http://incubator.apache.org/projects/#allura

06.3 Better tooling that presents a unified canonical model of the ASF organization. This tooling will wrap and manage the disparate data sources that we have. Better tooling will also make a mentor's job easier. (Cabrera)

06.4 Make this metadata even more useful. When people come to rely on it, then they might tend to keep it up-to-date. (crossley)

06.5 Clearly link and refer to all available resources that are generated from the podling metadata. Also refer to the tools that generate these pages so that people can help to enhance them. (crossley)

(crossley) Now see http://incubator.apache.org/facilities.html

Issue 07 - Vetting releases is a huge pain

Vetting releases is a huge pain. It is my personal, probably incorrect, impression that half of the pain is due to new rules being vetted by the IPMC as the vote takes place; e.g. what goes into a NOTICE file. (Cabrera)

(rgardler, Cabrera) A symptom of Issue 03

(crossley) And a symptom of Issue 11

Suggestions

07.1 Better tooling will help. Maybe we can have a set of release profiles that podlings can select that will allow automatic checking. To be sure this will not solve everything but it will go a long way to making things easier. (Cabrera)

07.2 I don't think we have a simple checklist for vetting releases, it probably doesn't need more than 6-10 items with unique IDs to be able to validate releases in a predictable and understandable way. (Bertrand)

07.3 Have people be a little more lenient when voting on poddling releases. There was a discussion a while back where it was agreed poddling releases should be allowed some wiggle room. Instead of demanding a respin for any transgression consider just explaining the issue and asking for it to be fixed in trunk/next release (ant)

Issue 08 - The IPMC is broken

As titled. (Mattmann)

(Cabrera) - "IPMC is broken" is vague. There are no concrete and specific details that explain what exactly is broken about the IPMC so as to require its disbandment.

(Cutting) This proposal moves a lot of oversight for podlings from the IPMC to the board. Before such a proposal is seriously considered you should ask whether the board wants to accept these duties. At present the board has delegated these to the IPMC. If the IPMC is completely unwilling to continue to accept this job then the board would be forced to find a new way to for projects to enter Apache. But if some on the IPMC are still willing, then the board might prefer to continue delegate this oversight.

Suggestions

08.1 "Destroy it" See: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal (Mattmann)

Issue 09 - People do not follow through to improve Incubator documentation

Generally speaking, there is not sufficient attention to the documentation. Over time it should improve, as people make contributions to clarify bits that were hurdles for them. (crossley)

Suggestions

09.1 The documentation already does remind that everyone has access, and can make edits as they proceed through incubation. Perhaps we need to emphasise that. Plead with them to help make the Incubator better for everyone. (crossley)

09.2 Ensure that mail list discussions are summarised and documented so that we do not keep re-visiting the topics. (crossley)

Issue 10 - Steps for Podlings to Acquire Resources Are Disparate and Poorly Documented

Some resources are created by opening Jira tickets. Sometimes the Mentor has to open the ticket other times a committer can do it. If there's an issue with the ticket it's closed as invalid. Other resources are requested via email. Etc. (randgalt)

Suggestions

10.1 Streamline the resource acquisition process via templates. A single Jira ticket with multiple sub-tasks (can be a Jira template as well). One stop shopping for a podling to get their repo, svn, git, etc. Different templates for different kinds of podling projects could be created. (randgalt)

Issue 11 - Clearly and concisely document the "principles and constraints" for the ASF

There are various fundamental things that many people seem to not understand. Once they grasp those and utilise common-sense, then they will need less documentation to explain intricacies. (crossley)

Suggestions

11.1 Some existing discussion can be turned into clear documentation, e.g. http://s.apache.org/aJz and http://s.apache.org/EZc and http://s.apache.org/SHu (crossley)

(rgardler) Another for the list http://community.apache.org/projectIndependence.html

Issue 12 - Cold welcome for new projects

New projects which come outside of Apache, cannot find Apache champion or mentors. The general request is too wide to reach someone's ear. It may take several years to get people on board. Rarely a good programmer is persistent enough to wait patiently.

Suggestions

12.1 One possible way to address it is to assign an eco-champion to the new project who performs the project evaluation. The champion comes from the Apache project of the same area. Sometimes this may end up with community merges. The eco-champion acts until the real champion is chosen, or he claims the project has little chances of starting following Apache ways.