Sorry not caught up with the full thread so I will not critique the overall proposal until I have. However, I have a concern with the abolition of the champion role. I don't care about the title of the role, but the champion is much more than "merely a mentor who is publicly stating that s/he will be more active in the podlings incubation". In fact, originally the champion role was merely the initial conduit into the Incubator. It was the friendly face that brought the team up to speed and ensured everyone was aligned before the project started talking publicly about its intentions to be an ASF project. In my experience steps 1-3 result in at least 50% of the projects I talk to never coming to the ASF. That, IMHO, is the result we want. If the ASF is not right for a project then we should catch it before they become an ASF project and tart to try to push the boundaries of The Apache Way.
To be honest I didn't know that the Champions role had changed and I'm not sure that it was ever documented as this. I see that the IPMC docs now define the role to be much more like that of a mentor. This is, IMHO, a mistake that I didn't see happening at the time - sorry for the late arrival on this. Here’s a slightly modified version of what I recently wrote for a PPMC about how *I* see *my* role as a champion, you'll see it is *much* more than being a mentor: 1) Have at least one call with all interested parties to explain what incubation is, what the proposal process will be (including things like individuals not companies and no PR), what the incubation process will be (including community building and no leader figures), what the Apache Way is, what the participants can expect from the foundation (there are always many questions and it is thus often necessary to have one-on-ones with different people in technical, business and legal roles in different orgs to address these questions) 2) By email work through the proposal template explaining why each section is present and pointing to appropriate ASF resources for further information. This might trigger many more questions and sometimes a second call. 3) Have the project team draw up the initial proposal, review, update, repeat (this often highlights a few remaining issues which might prompt another call) 4) While the above is happening recruit mentors that are trusted to do a good job and have a personal interest in the project succeeding. 5) Once the proposal is ready post it to the Wiki and invite discussion on the general mailing list, where all participants have already been instructed to subscribe. The proposal team should respond to any technical or community questions (they should understand enough about the Apache Way by now to be able to address community issues). The champion should address any process/legal questions because the IPMC (and to be fair the ASF generally) can be very difficult to deal with on such points. The champions experience and understanding of the ASF should help them cut through the noise in a way newcomers wouldn't be able to do. Allow a minimum of 5 days for discussion but try not to close the discussion period until after the thread has been quiet for at least three days. There may be some changes to the proposal during this discussion phase. 6) Call the vote and let run for a minimum of 3 days (possibly more for weekends). This whole process takes at least one month for steps 1-3 (sometimes much longer for complex cases). At the end of these steps everyone who feels they have an interest in the project moving forwards has had the opportunity to ask their questions and have them answered. Critical to this is that the champion has answered them personally, before linking to the ASF resources that address things. We have to remember that for many of these folks this is their first experience of an open source project we must explain things to them in language *they* understand. Not language that is comfortable for ASF Members. We can make no assumptions in those explanations. Remember that our documentation is difficult to read, sometimes conflicting and spread across the foundation. It is unreasonable to expect people new to the ASF to find their way (or to "get ahead of it" as one person recently described it to me). On a personal note I'd add that if I'm expected to also be a mentor for any project that I champion then the result will be that I won't champion as many new projects. While I can find the time to champion projects I can't always find the time to mentor projects effectively (personally, I usually budget 5 days over one month for the above champion role and 1 day per week for the first month and then 1/2 day per week for two months, then 1/4 day per week until graduation, planning on a 6-9 month incubation period). ASIDE: one of the things that moved the need on the quality of GSoC mentoring was to state our expectations on the amount of time mentors would need to put in - we should do that in the Incubator too. While I have no objection to removing the champions title, I would like to see us setting expectations about what is necessary even before a proposal hits the ASF. People can still perform this function without having the title of "Champion". Unfortunately, I get the impression that many podlings do not get this pre-proposal introduction into how the ASF works and are surprised once they are a podling - there should be no surprises. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -----Original Message----- From: Alan D.Cabrera [mailto:l...@toolazydogs.com] Sent: Wednesday, January 7, 2015 9:43 AM To: general@incubator.apache.org Subject: proposal: mentor re-boot I’ve written up a more comprehensive proposal that would not only hold mentors accountable but also give them a fair bit of autonomous authority during releases. https://wiki.apache.org/incubator/MentorRebootProposal <https://wiki.apache.org/incubator/MentorRebootProposal> What we would gain is transparency and simplicity. There would be no false expectations. Podlings would know where they stand. Work would be equitably distributed. No more layers. No more additional roles and confusing/diluted responsibilities. No more shuffling. Regards, Alan --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
