Re: Identifying and removing inactive mentors
On Monday, 2013-03-25, Alex Karasulu wrote: On Sun, Mar 24, 2013 at 10:43 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: [...] IMO it's the podlings who need to make sure they have enough mentor energy available - they are best placed to judge that, and delegating that to them scales much better than burdening the incubator PMC. In total agreement. No one knows better than the podling. I was never sure how much mentoring our podling was supposed to get. And I certainly wouldn't have reported an inactive mentor because I had no idea what kind of discussions that would have started. Regards, Matthias - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Identifying and removing inactive mentors
Yeah... the question of how much mentoring is kind of one of those things that mentors should advise on. Hmm... there's a problem. This is one place that the shepherds really, really can come in handy for. Likewise, simple hurdles like all mentors have to sign off every report help highlight problems. On Mon, Mar 25, 2013 at 8:21 AM, Matthias Friedrich m...@mafr.de wrote: On Monday, 2013-03-25, Alex Karasulu wrote: On Sun, Mar 24, 2013 at 10:43 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: [...] IMO it's the podlings who need to make sure they have enough mentor energy available - they are best placed to judge that, and delegating that to them scales much better than burdening the incubator PMC. In total agreement. No one knows better than the podling. I was never sure how much mentoring our podling was supposed to get. And I certainly wouldn't have reported an inactive mentor because I had no idea what kind of discussions that would have started. Regards, Matthias - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Identifying and removing inactive mentors
Exactly. Simple rule. If mentors don't sign two reports in a row, shepherd checks they are subscribed to the dev list, and then contacts them asking if they still want to be involved. If they don't answer, then the shepherd goes to the podling private list, and tells them that mentor x is not responding - and allows them to act as they wish (most likely seeking an additional mentor). The aim is not to strike off inactive mentors, but to ensure that a podling has enough active mentors. Having said that, there *are* perks to being a mentor, even an inactive one. I can say I mentored project X, and I see myself listed with karma on projects I mentored, which gives me kudos in the outside world. I'd personally rather not loose that kudos, it is kinda cool. Yet, do we want to 'give that' in return for zero activity? Did they really mentor project X? Upayavira On Mon, Mar 25, 2013, at 07:27 AM, Ted Dunning wrote: Yeah... the question of how much mentoring is kind of one of those things that mentors should advise on. Hmm... there's a problem. This is one place that the shepherds really, really can come in handy for. Likewise, simple hurdles like all mentors have to sign off every report help highlight problems. On Mon, Mar 25, 2013 at 8:21 AM, Matthias Friedrich m...@mafr.de wrote: On Monday, 2013-03-25, Alex Karasulu wrote: On Sun, Mar 24, 2013 at 10:43 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: [...] IMO it's the podlings who need to make sure they have enough mentor energy available - they are best placed to judge that, and delegating that to them scales much better than burdening the incubator PMC. In total agreement. No one knows better than the podling. I was never sure how much mentoring our podling was supposed to get. And I certainly wouldn't have reported an inactive mentor because I had no idea what kind of discussions that would have started. Regards, Matthias - 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: Vote on personal matters: majority vote vs consensus
On Sat, Mar 23, 2013 at 8:02 PM, Christian Grobmeier grobme...@gmail.com wrote: Hi, following a thread on private@, I would like to bring the discussion on how we vote on nominated IPMC members. We had the case were one person was nominated and received three +1. Another voter had concerns an voted -1. The vote has been marked as failed, because no consensus could be found. Now this was my understanding and I was surprised that the vote failed: Votes on procedural issues follow the common format of majority rule unless otherwise stated. http://www.apache.org/foundation/voting.html Joe brought this up before around 14 months: http://s.apache.org/majorityinipmc We have not found a consens, but one might highlight Roy Fieldings e-mail: http://s.apache.org/royCommitterVeto I still think like Joe and feel that consensus should not apply in the IPMC. We are way to different to normal PMCs. As IPMC members we have no code which we can veto. Its all about accepting podlings, discussing rules and mentoring. We also have 172 IPMC members to date (according committer index). Most of the people are not seen often; we have many awol mentors. Currently becoming an IPMC member is necessary to become a Mentor. It always felt wrong to me. I think one should be able to become a Mentor and finally be able to join the IPMC and discuss rules, when he has shown merit. With an IPMC of that size it becomes more and more easy to get a -1. Personally I would like to see the IPMC separating IPMC-ship and Mentor-ship. I have proposed this already, but it seems nobody else except me wants that. So I am proposing now to reconsider Joes original proposal and change our community voting to a majority voting unless we restructure the IPMC. I am sorry to bring this lengthy discussion up again, but from the original thread I have learned a couple of other IPMC members are thinking similar on majority / consensus. I would also like to suggest that this time we finish the discussion with a vote. Cheers Christian A concern with changing to majority votes instead of consensus is that it will get misunderstood and at some point someone will think its ok to do that in other projects too. Your second suggestion sounds like the thing to do to me - separating IPMC-ship and Mentor-ship - that would solve several of the problems we've being having including this one, it would open up a much bigger pool of potential mentors, and IPMC'ers would get much more visibility of people as they work here which should make the PMC voting easier. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Identifying and removing inactive mentors
On Mon, Mar 25, 2013 at 7:21 AM, Matthias Friedrich m...@mafr.de wrote: On Monday, 2013-03-25, Alex Karasulu wrote: On Sun, Mar 24, 2013 at 10:43 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: [...] IMO it's the podlings who need to make sure they have enough mentor energy available - they are best placed to judge that, and delegating that to them scales much better than burdening the incubator PMC. In total agreement. No one knows better than the podling. I was never sure how much mentoring our podling was supposed to get. And I certainly wouldn't have reported an inactive mentor because I had no idea what kind of discussions that would have started. And thats going to be the problem with most poddlings i would guess. They don't really know what to expect, and, they would be put off by worry of causing trouble. I was on an Incubating poddling once which had a couple of not terribly active mentors, i'm not sure that they read the dev list regularly. However they were both experienced ASF oldtimers and if you pinged them for help they jumped in and helped out which on several occasions proved invaluable (it was a bit of a troubled poddling). The problem with making some new rule, eg must sign reports, is that some people will then just make sure they do that without changing the activeness of their mentoring. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Mon, Mar 25, 2013, at 07:52 AM, ant elder wrote: On Sat, Mar 23, 2013 at 8:02 PM, Christian Grobmeier grobme...@gmail.com wrote: Hi, following a thread on private@, I would like to bring the discussion on how we vote on nominated IPMC members. We had the case were one person was nominated and received three +1. Another voter had concerns an voted -1. The vote has been marked as failed, because no consensus could be found. Now this was my understanding and I was surprised that the vote failed: Votes on procedural issues follow the common format of majority rule unless otherwise stated. http://www.apache.org/foundation/voting.html Joe brought this up before around 14 months: http://s.apache.org/majorityinipmc We have not found a consens, but one might highlight Roy Fieldings e-mail: http://s.apache.org/royCommitterVeto I still think like Joe and feel that consensus should not apply in the IPMC. We are way to different to normal PMCs. As IPMC members we have no code which we can veto. Its all about accepting podlings, discussing rules and mentoring. We also have 172 IPMC members to date (according committer index). Most of the people are not seen often; we have many awol mentors. Currently becoming an IPMC member is necessary to become a Mentor. It always felt wrong to me. I think one should be able to become a Mentor and finally be able to join the IPMC and discuss rules, when he has shown merit. With an IPMC of that size it becomes more and more easy to get a -1. Personally I would like to see the IPMC separating IPMC-ship and Mentor-ship. I have proposed this already, but it seems nobody else except me wants that. So I am proposing now to reconsider Joes original proposal and change our community voting to a majority voting unless we restructure the IPMC. I am sorry to bring this lengthy discussion up again, but from the original thread I have learned a couple of other IPMC members are thinking similar on majority / consensus. I would also like to suggest that this time we finish the discussion with a vote. Cheers Christian A concern with changing to majority votes instead of consensus is that it will get misunderstood and at some point someone will think its ok to do that in other projects too. Your second suggestion sounds like the thing to do to me - separating IPMC-ship and Mentor-ship - that would solve several of the problems we've being having including this one, it would open up a much bigger pool of potential mentors, and IPMC'ers would get much more visibility of people as they work here which should make the PMC voting easier. The structural problem here is that at the ASF, it is only PMC members whose votes are binding. Without being on the incubator PMC, votes on releases are non-binding. Now, you might argue that mentoring is a lot more than voting, but we could create another bottleneck in getting release votes through, requiring votes from incubator PMC members who are not particularly focused on the podling. Solve that, and the idea has merit in my eyes. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Mon, Mar 25, 2013 at 8:36 AM, Upayavira u...@odoko.co.uk wrote: Now, you might argue that mentoring is a lot more than voting, but we could create another bottleneck in getting release votes through, requiring votes from incubator PMC members who are not particularly focused on the podling. Thats exactly what i would argue, mentoring is a lot more than voting on releases. Many (most?) poddlings don't get three mentor votes on releases anyway and have to come to general@ so changing to have non-PMC mentors isn't going to make that worse than it already is. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Identifying and removing inactive mentors
On Mon, Mar 25, 2013 at 8:47 AM, Upayavira u...@odoko.co.uk wrote: ...Simple rule. If mentors don't sign two reports in a row, shepherd checks they are subscribed to the dev list, and then contacts them asking if they still want to be involved. If they don't answer, then the shepherd goes to the podling private list, and tells them that mentor x is not responding - and allows them to act as they wish (most likely seeking an additional mentor) That's a lot of work for the shepherd IMO - my proposal to just have the podling find out if they have adequate mentoring might be a bit extreme, but if we ask for an opinion on that in the podling reports we should still be fine, don't you think so? It should be relatively easy for the shepherd to check that the podling as at least one active mentor, and that mentor should feel free to ask for help if they feel they need it. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
Hi, On Sat, Mar 23, 2013 at 9:02 PM, Christian Grobmeier grobme...@gmail.com wrote: ...We also have 172 IPMC members to date (according committer index). Most of the people are not seen often; we have many awol mentors. Currently becoming an IPMC member is necessary to become a Mentor. It always felt wrong to me. I think one should be able to become a Mentor and finally be able to join the IPMC and discuss rules, when he has shown merit The problem is that people must be members of the Incubator PMC to vote on releases. I don't have a problem with having 172 members on this PMC, it is clear that many of them are not currently active and that's fine. ...I am proposing now to reconsider Joes original proposal and change our community voting to a majority voting unless we restructure the IPMC What does that mean exactly? That we consider -1s in votes on IPMC membership to be just a -1 on a majority vote, as opposed to a veto? I'm in favor of that, and I don't think we need more rules. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Falcon into the Apache Incubator (was originally named Ivory)
+1 (non-binding) On Mar 20, 2013, at 9:54 PM, Srikanth Sundarrajan wrote: Hi, Thanks for participating in the proposal discussion on Falcon (formerly Ivory). I'd like to call a VOTE for acceptance of Apache Falcon into the Incubator. I'll let the vote run till (Tue 3/26 6pm IST). [ ] +1 Accept Apache Falcon into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Falcon into the Incubator because... Full proposal is pasted at the bottom of this email, and the corresponding wiki is http://wiki.apache.org/incubator/FalconProposal. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thanks, Srikanth Sundarrajan -- _ The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
Re: [VOTE] Accept Falcon into the Apache Incubator (was originally named Ivory)
+1 (non-binding) Hi, Thanks for participating in the proposal discussion on Falcon (formerly Ivory). I'd like to call a VOTE for acceptance of Apache Falcon into the Incubator. I'll let the vote run till (Tue 3/26 6pm IST). [ ] +1 Accept Apache Falcon into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Falcon into the Incubator because... Full proposal is pasted at the bottom of this email, and the corresponding wiki is http://wiki.apache.org/incubator/FalconProposal. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thanks, Shaik Idris
Re: [VOTE] Accept Falcon into the Apache Incubator (was originally named Ivory)
+ 1 non biding On Mon, Mar 25, 2013 at 3:19 PM, Idris Ali psychid...@gmail.com wrote: +1 (non-binding) Hi, Thanks for participating in the proposal discussion on Falcon (formerly Ivory). I'd like to call a VOTE for acceptance of Apache Falcon into the Incubator. I'll let the vote run till (Tue 3/26 6pm IST). [ ] +1 Accept Apache Falcon into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Falcon into the Incubator because... Full proposal is pasted at the bottom of this email, and the corresponding wiki is http://wiki.apache.org/incubator/FalconProposal. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thanks, Shaik Idris
Re: [VOTE] Accept Falcon into the Apache Incubator (was originally named Ivory)
+1 (non-binding) On Mar 20, 2013, at 9:54 PM, Srikanth Sundarrajan wrote: Hi, Thanks for participating in the proposal discussion on Falcon (formerly Ivory). I'd like to call a VOTE for acceptance of Apache Falcon into the Incubator. I'll let the vote run till (Tue 3/26 6pm IST). [ ] +1 Accept Apache Falcon into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Falcon into the Incubator because... Full proposal is pasted at the bottom of this email, and the corresponding wiki is http://wiki.apache.org/incubator/FalconProposal. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thanks, Srikanth Sundarrajan
Re: Vote on personal matters: majority vote vs consensus
On 25/03/13 08:41, ant elder wrote: On Mon, Mar 25, 2013 at 8:36 AM, Upayavira u...@odoko.co.uk wrote: Now, you might argue that mentoring is a lot more than voting, but we could create another bottleneck in getting release votes through, requiring votes from incubator PMC members who are not particularly focused on the podling. Thats exactly what i would argue, mentoring is a lot more than voting on releases. Many (most?) poddlings don't get three mentor votes on releases anyway and have to come to general@ so changing to have non-PMC mentors isn't going to make that worse than it already is. ...ant I agree mentoring is a lot more than voting. One point though (not suggesting new process) - there is some value in coming to general@ at least once in the podlings incubation. It brings in a wider perspective and understanding because small-N mentors on a podling may not themselves have a complete awareness of everything. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Falcon into the Apache Incubator (was originally named Ivory)
On Mar 20, 2013, at 9:54 PM, Srikanth Sundarrajan wrote: [ ] +1 Accept Apache Falcon into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Falcon into the Incubator because... +1. Binding. -- Leif - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Sat, Mar 23, 2013 at 1:02 PM, Christian Grobmeier grobme...@gmail.com wrote: So I am proposing now to reconsider Joes original proposal and change our community voting to a majority voting unless we restructure the IPMC. +1 for majority voting on personnel issues for the IPMC. I'm also fine with requiring a supermajority of 2/3 or 3/4 of those voting, though I favor plain majority voting for the sake of simplicity. I would also like to suggest that this time we finish the discussion with a vote. +1 It will be disappointing if we get sidetracked into debating more controversial proposals and miss another opportunity to make some meaningful incremental progress. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Identifying and removing inactive mentors
On Mar 25, 2013, at 2:17 AM, Bertrand Delacretaz wrote: On Mon, Mar 25, 2013 at 8:47 AM, Upayavira u...@odoko.co.uk wrote: ...Simple rule. If mentors don't sign two reports in a row, shepherd checks they are subscribed to the dev list, and then contacts them asking if they still want to be involved. If they don't answer, then the shepherd goes to the podling private list, and tells them that mentor x is not responding - and allows them to act as they wish (most likely seeking an additional mentor) That's a lot of work for the shepherd IMO - my proposal to just have the podling find out if they have adequate mentoring might be a bit extreme, but if we ask for an opinion on that in the podling reports we should still be fine, don't you think so? As a shepherd (like many I missed last time, sorry one of those things), I like looking at a different flock/podling each time. The diversity is very cool. I look to see if the podling looks healthy and see if the report indicates if they are moving towards graduation and making a release. In these discussions let's not forget why three mentors are needed and why they should all be IPMC members, this is so that three +1 IPMC release votes are possible. Simple signs of not enough mentors: - Cannot get releases passed. - Cannot get IPMC signoff on Committer and PPMC votes. It should be relatively easy for the shepherd to check that the podling as at least one active mentor, and that mentor should feel free to ask for help if they feel they need it. Yes, reviewing the private and dev lists should give that answer quickly. I would have to review my shepherd reports, but I think that podlings are more likely to have a release, community or infra issue than a mentor issue. One thing that Flex did was to use a [MENTOR] tag on emails when they wanted our advice. This helped given the huge volume of emails. Of the four mentors, three were active ... I'm not mentoring at the moment, and won't until I think I have the time. MemoryMap is interesting, but... 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
