Re: proposal: mentor re-boot
On Jan 7, 2015, at 8:18 PM, Marvin Humphrey mar...@rectangular.com wrote: What has changed in the last year and a half is that we no longer ignore it when podlings fail to report -- we put them into monthly and review the situation month to month. Between that and requiring Mentor checkoff, we'll notice 90% of podlings that go adrift. This really has no teeth and effectively just gives the mentors and podlings a “bye” for the month. Regards, Alan
Re: proposal: mentor re-boot
On Wed, Jan 7, 2015 at 12:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote: We do have problems; see above. To address our problems, I advocate incremental, reversible changes and controlled experiments. With that said, my proposal is not a radical overhaul. There are parts of it I can get behind. Taken together, it is too much. Retiring the role of Champion sounds like an idea whose time has come. We gave the Champion additional oversight responsibilities a while back -- but how many times since then has having that additional layer made a difference? I also think we can do without Shepherds -- in fact we are already for a lot of podlings because Shepherd participation is spotty. What has changed in the last year and a half is that we no longer ignore it when podlings fail to report -- we put them into monthly and review the situation month to month. Between that and requiring Mentor checkoff, we'll notice 90% of podlings that go adrift. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
What is The Apache Way?
On Wed, Jan 7, 2015 at 12:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote: Some podlings are graduating w/ no clear understanding of the Apache Way. What is The Apache Way? No one can say. There is no bounded set of expectations that an Apache project must fulfill. Where do Apache's official policies begin and end? Which best practices must be mastered? What will be enforced, what will be ignored? Every last podling graduates without a clear understanding of The Apache Way, because it is impossible to attain a clear understanding of The Apache Way. We can't fix that by restructuring the Incubator. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
Alan, thanks for the clarification. I agree that this is in the context of podling/ incubator projects. - Henry On Wed, Jan 7, 2015 at 2:21 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 7, 2015, at 1:45 PM, Henry Saputra henry.sapu...@gmail.com wrote: One wording that could confuse people: after which they are removed from the PMC unless they are committers. If someone already a PMC, he or she is also a committer. In ASF a committer is someone who can commit code into the repository. Yes, that is how we currently setup committership but it doesn’t have to happen that way for a podling. If a mentor asked to stay as PMC after graduation just for the sake of continue mentoring, I think I account for that. I am not sure how can the community ask the mentor to leave the PMC because he/ she is by default a committer. Again, being a committer by default is a description of what happens now. It doesn’t have to be that way and if it does then you are describing a problem with the tooling. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On 07.01.2015 22:45, Henry Saputra wrote: If a mentor asked to stay as PMC after graduation just for the sake of continue mentoring, then I would argue that the podling was not ready for graduation. A graduated TLP inviting the former mentor to the PMC is a different matter, but then the IPMC has neither mandate nor power to remove that person from the PMC. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Jan 7, 2015, at 12:13 PM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Jan 7, 2015 at 9:42 AM, Alan D. Cabrera l...@toolazydogs.com wrote: https://wiki.apache.org/incubator/MentorRebootProposal From that page: People who wish to become mentors that are not in the IPMC must be a novice mentor, whose mentorship is not counted as an active mentor, for at least one podling's incubation. ASF members can become IPMC members. Non-ASF members must mentor a project before becoming an IPMC member. No more layers. Looks to me like the proposal invents a new layer: the novice mentor”. It’s not a layer. It’s a phase that mentors need to go through. This is not new and it’s something we currently do. I’ve just made it more explicit. I deeply dislike how this proposal erects barriers to keep us from electing people onto the IPMC. One of reasons the Incubator is functioning well these days is because we've welcomed lots of new people who have brought lots of energy! And if our process/roll churn died down, what use is the IPMC other than mentoring podlings through incubation? IMO, you are either “here” to directly help podlings incubate or your here to contribute to process/roll churn. I’m all for energy. Great. I want that energy directed toward facilitating successful incubations. If you don’t want to be a mentor then why are you here? Mentoring and vetting is what the incubator is all about. If anything, I'd rather go the opposite route: no more automatic joining for ASF members. (I'm not proposing that, I just think it's less bad.) I thought about that. The thinking is that ASF members are already “trustworthy”. Maybe we should remove it and see if the proposal still flies. Anyone else have an opinion on that? Similarly, this proposal effectively prevents us from elevating outstanding podling contributors onto the IPMC, undoing the wildly successful reforms Joe Schaefer championed that have gotten podlings like Thrift, ManifoldCF and Allura unstuck. Why discard that crucial tool from the toolbox? Would not these outstanding podling contributors be considered podling novices who have been vetted by “one” podling incubation? The Incubator has made important progress. * We're not chronically losing track of podlings the way we once did. I’m not so sure. Isn’t the lack of reporting and the need for shepherds symptomatic of us chronically losing track of podlings? * Our report is consistently on-time and well-put-together, and it's become a team effort that starts great conversations and doesn't burn out the Chair. I’m confused. Automated reporting does not mean we have a handle on things While the Incubator report itself is consistently on time, mentors have consistently not signed off on podling reports, if the reports get filed at all. The problem is so endemic that we “needed to create the role of shepherds. Now, we need people to review the shepherds to make sure they review the mentors who were supposed to review the podlings. Some podlings are graduating w/ no clear understanding of the Apache Way. This is all symptomatic of MIA mentors. * Releases are getting approved faster, with fewer RC cycles and with less arguing. That’s a function of how much spare time people in the IPMC have… I would not say the problem has been solved. I keep hearing how the IPMC is too large to achieve consensus so we have to keep people out. But the people who have brought back these radical overhaul proposals and are inundating general@incubator with dozens of emails each day are the same discontented core who were doing it two years ago. I do not claim that the IPMC is too large and those that do do not understand the fundamental problems we have, imo. We do have problems; see above. This is what precipitated the recent few proposals. With that said, my proposal is not a radical overhaul. The proposal is not rebooting the IPMC. The proposal is making things more explicit and transparent while not changing the amount of expected responsibilities. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Wed, Jan 7, 2015 at 9:42 AM, Alan D. Cabrera l...@toolazydogs.com wrote: https://wiki.apache.org/incubator/MentorRebootProposal From that page: People who wish to become mentors that are not in the IPMC must be a novice mentor, whose mentorship is not counted as an active mentor, for at least one podling's incubation. ASF members can become IPMC members. Non-ASF members must mentor a project before becoming an IPMC member. No more layers. Looks to me like the proposal invents a new layer: the novice mentor. I deeply dislike how this proposal erects barriers to keep us from electing people onto the IPMC. One of reasons the Incubator is functioning well these days is because we've welcomed lots of new people who have brought lots of energy! If anything, I'd rather go the opposite route: no more automatic joining for ASF members. (I'm not proposing that, I just think it's less bad.) Similarly, this proposal effectively prevents us from elevating outstanding podling contributors onto the IPMC, undoing the wildly successful reforms Joe Schaefer championed that have gotten podlings like Thrift, ManifoldCF and Allura unstuck. Why discard that crucial tool from the toolbox? The Incubator has made important progress. * We're not chronically losing track of podlings the way we once did. * Our report is consistently on-time and well-put-together, and it's become a team effort that starts great conversations and doesn't burn out the Chair. * Releases are getting approved faster, with fewer RC cycles and with less arguing. I keep hearing how the IPMC is too large to achieve consensus so we have to keep people out. But the people who have brought back these radical overhaul proposals and are inundating general@incubator with dozens of emails each day are the same discontented core who were doing it two years ago. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Jan 7, 2015, at 11:35 AM, Upayavira u...@odoko.co.uk wrote: On Wed, Jan 7, 2015, at 06:46 PM, jan i wrote: On 7 January 2015 at 19:32, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 7, 2015, at 10:13 AM, Branko Čibej br...@apache.org wrote: On 07.01.2015 18:42, Alan D. Cabrera wrote: 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 Being put on hold means that no committers can be added, no PPMC members can be added, and no releases can be performed This would be a no go for me. If a podling has lost a mentor, but are actively seeking a new mentor, the IPMC must step in to accept a new committer, PPMC member or release. The IPMC has accepted the podling, so it is very unfair, to punish a podling, that does a active job to replace a mentor. The IPMC *cannot* replace a mentor. We have no power to make someone take on that role. Alan, please add a section to your doc about the fact that podlings retain responsibility for engaging with their mentors, and for recruiting replacements should a mentor quit or go AWOL. A very good idea. Though I will quickly add that I think that Jan meant to say “it is unfair to make the podling recruit a new mentor to replace the removed mentor”. It is great to clarify the responsibilities of mentors, but please let's set the expectations and responsibilities of podling members, otherwise we keep this idea that the Incubator PMC is a body that has power to do things (like make someone step up as a mentor for a project), which it doesn't. Yes, definitely. This is the document that I alluded to in the proposal, mentors must acknowledge that they will perform their duties as out lined in a clearly defined document. I wanted to garner consensus on the broad strokes before filling it in, but since the initial reaction seems to generally favorable, I should probably create that now. Regards, Alan
Re: proposal: mentor re-boot
On Jan 7, 2015, at 12:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote: The Incubator has made important progress. I want to quickly acknowledge that we have made immense, immense, progress thanks in no small part to our IPMC chairs over the years. A lot of hard work was done and that produced very good results. Regards, Alan
Re: proposal: mentor re-boot
One wording that could confuse people: after which they are removed from the PMC unless they are committers. If someone already a PMC, he or she is also a committer. In ASF a committer is someone who can commit code into the repository. If a mentor asked to stay as PMC after graduation just for the sake of continue mentoring, I am not sure how can the community ask the mentor to leave the PMC because he/ she is by default a committer. - Henry On Wed, Jan 7, 2015 at 9:42 AM, Alan D. Cabrera l...@toolazydogs.com wrote: 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
Re: proposal: mentor re-boot
On Jan 7, 2015, at 1:45 PM, Henry Saputra henry.sapu...@gmail.com wrote: One wording that could confuse people: after which they are removed from the PMC unless they are committers. If someone already a PMC, he or she is also a committer. In ASF a committer is someone who can commit code into the repository. Yes, that is how we currently setup committership but it doesn’t have to happen that way for a podling. If a mentor asked to stay as PMC after graduation just for the sake of continue mentoring, I think I account for that. I am not sure how can the community ask the mentor to leave the PMC because he/ she is by default a committer. Again, being a committer by default is a description of what happens now. It doesn’t have to be that way and if it does then you are describing a problem with the tooling. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
+1 I would recommend to remove that particular line about mentor staying as mentor sake. Either mentors join in as full fledge PMC (and as committer) or not at all. - Henry On Wed, Jan 7, 2015 at 4:56 PM, Branko Čibej br...@apache.org wrote: On 07.01.2015 22:45, Henry Saputra wrote: If a mentor asked to stay as PMC after graduation just for the sake of continue mentoring, then I would argue that the podling was not ready for graduation. A graduated TLP inviting the former mentor to the PMC is a different matter, but then the IPMC has neither mandate nor power to remove that person from the PMC. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On 07.01.2015 18:42, Alan D. Cabrera wrote: 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. What you're proposing, then, is that we institute mentor licenses with requirements over and above those for ASF membership. In effect, you'd create an additional level of earned merit for mentors ... which is probably a good thing. What I don't understand is this: where's the motivation for anyone to submit to this additional burden? There's a lot of stick in your proposal, but a woeful lack of carrot ... so, most likely not going to work for a bunch of volunteers. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Jan 7, 2015, at 10:13 AM, Branko Čibej br...@apache.org wrote: On 07.01.2015 18:42, Alan D. Cabrera wrote: 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. What you're proposing, then, is that we institute mentor licenses with requirements over and above those for ASF membership. In effect, you'd create an additional level of earned merit for mentors ... which is probably a good thing. I don’t think that I’m following. Mentors need to be members of the IPMC but that doesn’t mean they need to be ASF members. What I don't understand is this: where's the motivation for anyone to submit to this additional burden? There's a lot of stick in your proposal, but a woeful lack of carrot ... so, most likely not going to work for a bunch of volunteers. What extra burden? The proposal is not asking mentors to do anything more than what they shouldn’t already be doing. All the proposal does is hold the mentors accountable for their inactivity and to add more of an incentive for PPMCs to be proactive in their relationships w/ mentors; something that the PPMCs shouldn’t already be doing. The carrot for both podlings and mentors is that there is no second gauntlet of voting/review by the IPMC for releases. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On 7 January 2015 at 19:32, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 7, 2015, at 10:13 AM, Branko Čibej br...@apache.org wrote: On 07.01.2015 18:42, Alan D. Cabrera wrote: 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. What you're proposing, then, is that we institute mentor licenses with requirements over and above those for ASF membership. In effect, you'd create an additional level of earned merit for mentors ... which is probably a good thing. I don’t think that I’m following. Mentors need to be members of the IPMC but that doesn’t mean they need to be ASF members. What I don't understand is this: where's the motivation for anyone to submit to this additional burden? There's a lot of stick in your proposal, but a woeful lack of carrot ... so, most likely not going to work for a bunch of volunteers. What extra burden? The proposal is not asking mentors to do anything more than what they shouldn’t already be doing. All the proposal does is hold the mentors accountable for their inactivity and to add more of an incentive for PPMCs to be proactive in their relationships w/ mentors; something that the PPMCs shouldn’t already be doing. The carrot for both podlings and mentors is that there is no second gauntlet of voting/review by the IPMC for releases. In general I like the proposal especially the carrot. But I do have a couple of concerns: An active mentor is removed from a podling if that mentor does not review/sign off on a release. An active mentor is removed from a podling if that mentor does not review/sign off on a board report. Can a mentor not take vacation ? I think this need to contain a clause, that if the mentor has adviced the PPMC about the absence this will not happen. Being put on hold means that no committers can be added, no PPMC members can be added, and no releases can be performed This would be a no go for me. If a podling has lost a mentor, but are actively seeking a new mentor, the IPMC must step in to accept a new committer, PPMC member or release. The IPMC has accepted the podling, so it is very unfair, to punish a podling, that does a active job to replace a mentor. I really like the clear ruleset, this would also remove the need for shepherds I assume. rgds jan I. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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
