Re: proposal: mentor re-boot
On Fri, Jan 9, 2015 at 3:31 AM, Dave Fisher dave2w...@comcast.net wrote: ...I think the IPMC is doing almost all of the above better. Everything except for Failed. I think that now we are blaming the mentor. Let's get over it. Not every podling will work That's distinct concerns IMO: some podlings are failing and no mentor can save them, but there are also podlings that would be doing better if they had sufficiently active mentors. Also, from the point of view of oversight, the IPMC needs a way to find out how podlings are doing, and that's delegated to mentors. Failing that, poor IPMC volunteers have to step up and that gets boring over time. -Bertrand - 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 9, 2015, at 1:35 AM, Bertrand Delacretaz wrote: On Fri, Jan 9, 2015 at 3:31 AM, Dave Fisher dave2w...@comcast.net wrote: ...I think the IPMC is doing almost all of the above better. Everything except for Failed. I think that now we are blaming the mentor. Let's get over it. Not every podling will work That's distinct concerns IMO: some podlings are failing and no mentor can save them, but there are also podlings that would be doing better if they had sufficiently active mentors. And that depends on mentors who are sufficiently interested with enough time and also the type of mentoring required. Maybe it is community help or it could be release help. Also, from the point of view of oversight, the IPMC needs a way to find out how podlings are doing, and that's delegated to mentors. Failing that, poor IPMC volunteers have to step up and that gets boring over time. So we have Shepherds as delegates from the IPMC to take a look every so often. It is a Role that is more like a scout. We've had Shepherds report Mentor issues, Release issues, Community issues. Regards, Dave -Bertrand - 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
Hi - We could better spend our energy looking at podlings with Mentor problems and deciding which of three possible states fits the podling. - Failed - no community is trully involved and there is nothing an active mentor could do. Let's just admit it and retire the podling. - Needs Help - a mentor would really help. They need it and want it. We try to find one. - Going Fine - could be a TLP. We help them graduate. I think the IPMC is doing almost all of the above better. Everything except for Failed. I think that now we are blaming the mentor. Let's get over it. Not every podling will work. Thanks. Regards, Dave On Jan 8, 2015, at 11:12 AM, Alan D. Cabrera wrote: On Jan 8, 2015, at 10:12 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: I'm not seeing how this proposal fixes the problem either. However, I do like that this proposal doesn't move responsibility and I like that it adds some teeth to the IPMC (e.g. removal of inactive mentors and pausing of podlings with insufficient mentors - though I still dispute ticking a box is hardly an indication of an active mentor) The thinking is that a mentor is at least honest; a reasonable assumption. If they claim to have reviewed a release or board report then they can be trusted to have done so to the best of their abilities. The two mentor minimum rule addresses the possible unevenness in ernest mentors’ abilities. There is no silver bullet but this proposal covers a lot of the perennial problems that the Incubator seems run into without changing responsibilities; a nice incremental step. It also simplifies the roles that podlings need to grok. Finally, it adds more impetus for PPMCs to take ownership in their incubation. 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 Wednesday, January 7, 2015, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 7, 2015, at 10:46 AM, jan i j...@apache.org javascript:; wrote: On 7 January 2015 at 19:32, Alan D. Cabrera l...@toolazydogs.com javascript:; wrote: On Jan 7, 2015, at 10:13 AM, Branko Čibej br...@apache.org javascript:; 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. Yes, they certainly can! All they need to do is notify the PPMC and IPMC that they are going to be inactive. :) well You say that , but the text does not state the same. 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. If a mentor really goes MIA, should those things be taking place without mentor oversight? IMO, no. No, this is not punishment, this just makes the current state of affairs clear and explicit. Plus, the PPMC needs to take on a more active role in things; they are not teenagers in the back seat. of course they would! first of all it only takes 1 mentor to do that not 2, secondly - new committers is the responsibility of the PPMC not the mentor - PPMC is the responsibility of PPMC/IPMC not the mentor - Releases is the responsibility of PPMC/IPMC not the mentor according to our current documentation. I don't disagree with your proposal, I just want an escape clausal in case a podling run into problems caused by our eager to over administrate. rgds jan i I really like the clear ruleset, this would also remove the need for shepherds I assume. Yep, and champions go away too. You’ll notice I've added a few more rules so that we address the reverse of “fascination of the ASF brand” issue. That being the “fascination of a podling brand”. If a mentor wants to be on the red carpet on opening day, they need to have put some skin in the game. Soo many things get simpler. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Sent from My iPad, sorry for any misspellings.
Re: proposal: mentor re-boot
On 08/01/15 16:48, Chip Childers wrote: On Wed, Jan 07, 2015 at 08:18:59PM -0800, Marvin Humphrey wrote: 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? My 2 cents: In my experience, the Champion is a useful concept for the purpose of having discussions with the incoming project's community *before* they become a podling. I've acted as a champion for one podling so far, as well as acted in this role for one community that ended up *not* wanting to incubate. I see this as a valuable activity (I don't care what it's called), because it's important that incoming projects understand what they are signing up for. As much as it's an investment for the ASF to accept podlings, it's an investment for the inbound communities to make the proposal. For the project that I acted as a Champion for, I considered that part of the work to be done when they became a podling. I also asked to be a mentor, and am doing so now... and being a mentor is a bit different from that initial introduction. In the end though, regardless of what we name things, podlings should have support from people here in the incubator from the time they start considering the move to the time they become a TLP. +1 The other minor aspect of champion can making sure getting bootstrap happens quickly. Other mentors may not immediately be active, or as well known to the podling. It is admin smoothing over the transition, not vital, but helpful. Andy - 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 All we care about is that the podling has an active mentor who knows when to ask for support and gets that support when they need it. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Branko Čibej [mailto:br...@apache.org] Sent: Thursday, January 8, 2015 7:06 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On 08.01.2015 15:32, Alan D. Cabrera wrote: The two mentor minimum is critical. I was going to make it three but reasoned that if two were active, they could do the job. Why? I've not yet seen a single argument that would explain why you need at least two active mentors. One active mentor at any given time is sufficient for all current requirements. -- 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 8, 2015, at 10:06 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: +1 All we care about is that the podling has an active mentor who knows when to ask for support and gets that support when they need it. Following that statement to a logical conclusion, all podlings need to make a release is for one mentor to +1 it. That doesn’t match what we do today. How do you reconcile the minimum +1 voting requirement for releases we have to day with what you state above? Or are you guys saying that the podling can do everything but release w/ one active mentor, they need two to perform a release? Regards, Alan
RE: proposal: mentor re-boot
pTLP adds a great deal of overhead to the board unless there is a review process somewhere else. I've posted on this before so will not repeat here beyond summarizing as moving responsibility for the problem does not fix the problem. I'm not seeing how this proposal fixes the problem either. However, I do like that this proposal doesn't move responsibility and I like that it adds some teeth to the IPMC (e.g. removal of inactive mentors and pausing of podlings with insufficient mentors - though I still dispute ticking a box is hardly an indication of an active mentor) Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Thursday, January 8, 2015 8:09 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Thu, Jan 8, 2015 at 7:05 AM, Branko Čibej br...@apache.org wrote: On 08.01.2015 15:32, Alan D. Cabrera wrote: The two mentor minimum is critical. I was going to make it three but reasoned that if two were active, they could do the job. Why? I've not yet seen a single argument that would explain why you need at least two active mentors. One active mentor at any given time is sufficient for all current requirements. A very, very strong +1 to that. In fact, I'd say anything that adds to the complexity and bureaucracy of mentorship requirements -- is a 'no go' in my opinion. That's one reason I'm so strongly in favor of pTLP. They piggyback off of the process we already have adding very little bureaucracy and tracking overhead. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: proposal: mentor re-boot
Chip is correct. The tools we use in board meetings make it easy for us to see how many PMC members in a TLP resolution are members. If there are not enough we will sometimes put the project on an informal watch list (as well as ensuring appropriate people from the PMC go on the members watch list), occasionally we bounce the proposal back (this is pretty rare). With my Directors hat on I don't want a member being there just for mentoring, it confuses the evaluation since that person will appear as a committed PMC member but will in fact be nothing more than a mentor. What is important is that the PMC knows where to go for help when they are unsure of something. That expertise can (and should be) be present without a mentor or a Member on the PMC. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, January 8, 2015 8:42 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Wed, Jan 07, 2015 at 05:20:40PM -0800, Henry Saputra wrote: +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. +1, with the one comment that I've heard the board(s) review a list of initial PMC members to be sure that they believe there is enough experience within the PMC (typically by seeing if there are mentors and / or ASF members). IMO, this is likely a bit of a backstop in situations where a TLP would otherwise be an island. - 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 - 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
An ASF release needs three binding +1 votes (I see you say two but in your proposal but that would require a policy change in the ASF which I doubt will happen). If there is only a single mentor approaches the IPMC to ask for those votes. As a single active mentor on projects I have both asked the broader IPMC and sought out help from people privately who I trust to do the job well. Ross -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Thursday, January 8, 2015 10:11 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Jan 8, 2015, at 10:06 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: +1 All we care about is that the podling has an active mentor who knows when to ask for support and gets that support when they need it. Following that statement to a logical conclusion, all podlings need to make a release is for one mentor to +1 it. That doesn’t match what we do today. How do you reconcile the minimum +1 voting requirement for releases we have to day with what you state above? Or are you guys saying that the podling can do everything but release w/ one active mentor, they need two to perform a release? Regards, Alan
Re: proposal: mentor re-boot
On Thu, Jan 8, 2015 at 1:16 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Chip is correct. The tools we use in board meetings make it easy for us to see how many PMC members in a TLP resolution are members. If there are not enough we will sometimes put the project on an informal watch list (as well as ensuring appropriate people from the PMC go on the members watch list), occasionally we bounce the proposal back (this is pretty rare). With my Directors hat on I don't want a member being there just for mentoring, it confuses the evaluation since that person will appear as a committed PMC member but will in fact be nothing more than a mentor. What is important is that the PMC knows where to go for help when they are unsure of something. That expertise can (and should be) be present without a mentor or a Member on the PMC. Maybe there's a hair to be split here. On a few occasions, I was asked by board members if I would join a graduating PMC that I had mentored. I have never felt that my role on these PMCs was to be a continuing mentor, it was to be a PMC member who had some extra experience, and I have been gradually leaving them over time.
Re: proposal: mentor re-boot
On Wed, Jan 07, 2015 at 08:18:59PM -0800, Marvin Humphrey wrote: 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? My 2 cents: In my experience, the Champion is a useful concept for the purpose of having discussions with the incoming project's community *before* they become a podling. I've acted as a champion for one podling so far, as well as acted in this role for one community that ended up *not* wanting to incubate. I see this as a valuable activity (I don't care what it's called), because it's important that incoming projects understand what they are signing up for. As much as it's an investment for the ASF to accept podlings, it's an investment for the inbound communities to make the proposal. For the project that I acted as a Champion for, I considered that part of the work to be done when they became a podling. I also asked to be a mentor, and am doing so now... and being a mentor is a bit different from that initial introduction. In the end though, regardless of what we name things, podlings should have support from people here in the incubator from the time they start considering the move to the time they become a TLP. - 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 07, 2015 at 05:20:40PM -0800, Henry Saputra wrote: +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. +1, with the one comment that I've heard the board(s) review a list of initial PMC members to be sure that they believe there is enough experience within the PMC (typically by seeing if there are mentors and / or ASF members). IMO, this is likely a bit of a backstop in situations where a TLP would otherwise be an island. - 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 - 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 Thu, Jan 8, 2015 at 7:05 AM, Branko Čibej br...@apache.org wrote: On 08.01.2015 15:32, Alan D. Cabrera wrote: The two mentor minimum is critical. I was going to make it three but reasoned that if two were active, they could do the job. Why? I've not yet seen a single argument that would explain why you need at least two active mentors. One active mentor at any given time is sufficient for all current requirements. A very, very strong +1 to that. In fact, I'd say anything that adds to the complexity and bureaucracy of mentorship requirements -- is a 'no go' in my opinion. That's one reason I'm so strongly in favor of pTLP. They piggyback off of the process we already have adding very little bureaucracy and tracking overhead. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: proposal: mentor re-boot
Yes, Benson. You should take it as a compliment that if the board invite you to do remain and you agree then they trust you to be their eyes and ears, and if necessary the person they turn to in order to investigate a potentially issue. That's different from the mentor role in the IPMC though. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Thursday, January 8, 2015 10:36 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Thu, Jan 8, 2015 at 1:16 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Chip is correct. The tools we use in board meetings make it easy for us to see how many PMC members in a TLP resolution are members. If there are not enough we will sometimes put the project on an informal watch list (as well as ensuring appropriate people from the PMC go on the members watch list), occasionally we bounce the proposal back (this is pretty rare). With my Directors hat on I don't want a member being there just for mentoring, it confuses the evaluation since that person will appear as a committed PMC member but will in fact be nothing more than a mentor. What is important is that the PMC knows where to go for help when they are unsure of something. That expertise can (and should be) be present without a mentor or a Member on the PMC. Maybe there's a hair to be split here. On a few occasions, I was asked by board members if I would join a graduating PMC that I had mentored. I have never felt that my role on these PMCs was to be a continuing mentor, it was to be a PMC member who had some extra experience, and I have been gradually leaving them over time. - 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 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
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
