Re: Incubator report sign-off
Thanks Roman. On Thu, Jan 8, 2015 at 10:29 AM, Roman Shaposhnik wrote: > On Mon, Jan 5, 2015 at 5:49 PM, Andrew Purtell > wrote: > >> One extra thing to note, that while we can *start* this comittee as > > dedicated > >> > > to Incubating projects, it will be a very natural extension to get it > > involved > >> > > in monitoring all of TLPs, not just pTLPs. > > > > What problem exists today where the Board needs > > such a buffer? > > Nobody says it does. At least not long term. If the board > feels like they can handle the load themselves -- there's > no need for the side of the committee that acts that way. > However, it feels like a safer bet to try and have it first > and then see if the load is light enough so that the board > can act directly 100%. > > Btw, board *does* act directly even today (case in point > the thread started by Rich). > > > In what ways could this committee substitute its judgement for PMC of the > > TLP? > > Just as the board's job is to tell PMC when something's going wrong > ditto with the committee. > > > How would one apply to be on this committee? Would this be a case of some > > members being more member than others? > > I see it same way as ComDev (or any other ground like that). There's > a voting process, you get nominated and accepted. The only > qualification is that you *have* to be an ASF member. > > > What would be the process and expectations for resolving disagreements > > between the TLP and this committee? > > Again, since the comittee is just acting as a 'clerk' for the board, the > process is still the same as what we have today between the board > and the TLPs. > >
Re: Incubator report sign-off
On Mon, Jan 5, 2015 at 5:49 PM, Andrew Purtell wrote: >> One extra thing to note, that while we can *start* this comittee as > dedicated >> > to Incubating projects, it will be a very natural extension to get it > involved >> > in monitoring all of TLPs, not just pTLPs. > > What problem exists today where the Board needs > such a buffer? Nobody says it does. At least not long term. If the board feels like they can handle the load themselves -- there's no need for the side of the committee that acts that way. However, it feels like a safer bet to try and have it first and then see if the load is light enough so that the board can act directly 100%. Btw, board *does* act directly even today (case in point the thread started by Rich). > In what ways could this committee substitute its judgement for PMC of the > TLP? Just as the board's job is to tell PMC when something's going wrong ditto with the committee. > How would one apply to be on this committee? Would this be a case of some > members being more member than others? I see it same way as ComDev (or any other ground like that). There's a voting process, you get nominated and accepted. The only qualification is that you *have* to be an ASF member. > What would be the process and expectations for resolving disagreements > between the TLP and this committee? Again, since the comittee is just acting as a 'clerk' for the board, the process is still the same as what we have today between the board and the TLPs. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Mon, Jan 5, 2015 at 5:41 PM, Andrew Purtell wrote: >> An addition of the overseeing committee, will shield the board from >> > *some* of the day-to-day business of telling the pTLP that something >> > needs to be fixed. > > Is this pretty close to IPMC in another name? No it isn't. First of all, the overseeing committee is NOT specific to incubation projects it can (and should!) be applied to all the project that board review reports for. Second of all, the comittee is a much more realistic extension of the board in that it, upfront, declares total absence of 'collective' responsibility. You don't approach the committee with the expectaions that it has collective responsibility to find volunteers that 'help projects'. The committee members have no other business but telling PMC of the pTLP (and hopefully TLPs at some point) that something is broken. That's it. This is very different from the charter that the IPMC has. > Who gets to be on the new overseeing committee? Not current IPMC membership > right? Correct. > So is that a revocation of privilege in some respects? I don't think so. In a way, it is a promotion. All the *active* members (AKA mentors) get promoted to PMCs of pTLPs. A few IPMC members get promoted to the membership on the committee. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
Yes which is why I am proposing for less change than what others are proposing. Sent from my iPhone > On Jan 5, 2015, at 5:07 PM, Ross Gardler (MS OPEN TECH) > wrote: > > Careful... most mentors do a great job. The problem is when all mentors fade > away (which as volunteers they are entitled to do) and the IPMC doesn't > notice. > > Ross > > Microsoft Open Technologies, Inc. > A subsidiary of Microsoft Corporation > > -Original Message- > From: Alan Cabrera [mailto:l...@toolazydogs.com] > Sent: Monday, January 5, 2015 4:50 PM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > This statement confuses the lack of active mentors with the sheer size of the > IPMC. The problem is not the size of the IPMC. The problem is that mentors > are not doing their jobs > > Sent from my iPhone > >> On Jan 5, 2015, at 3:41 PM, Mattmann, Chris A (3980) >> wrote: >> >> Yep and let all from that 170+ person committee be tracked down for >> responsibility. Talk about s fun activity it's simply not scalable >> >> Sent from my iPhone >> >>> On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) >>> wrote: >>> >>> But the board is not responsible for any actions resulting from those >>> reviews, the IPMC is. >>> >>> Ross >>> >>> -----Original Message- >>> From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] >>> Sent: Monday, January 5, 2015 9:31 AM >>> To: general@incubator.apache.org >>> Subject: Re: Incubator report sign-off >>> >>> It’s not a pawning off to the board - the board is already >>> responsible for reviewing the IPMC report which includes *all of the same >>> detail* that the IPMC also .. reviews. >>> >>> Cheers, >>> Chris >>> >>> >>> >>> -Original Message- >>> From: "Alan D. Cabrera" >>> Reply-To: "general@incubator.apache.org" >>> >>> Date: Monday, January 5, 2015 at 8:59 AM >>> To: "general@incubator.apache.org" >>> Subject: Re: Incubator report sign-off >>> >>>> >>>>> On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik wrote: >>>>> >>>>> On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera >>>>> >>>>> wrote: >>>>>> >>>>>>> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >>>>>>> >>>>>>> 1. get rid of IPMC altogether and move to the pTLP model >>>>>> >>>>>> This is effectively an IPMC reboot. I don’t really see anything >>>>>> substantially different. >>>>> >>>>> At this point, I'm convinced this is the only fruitful path >>>>> forward, the rest is a shell game with responsibility. See the other >>>>> thread. >>>>> >>>>>>> 3. patch the current process with starting to drop the mentors from >>>>>>>the project who don't sign off. This will essentially serve >>>>>>>as a heartbeat for mentors (now, in my opinion it'll quickly >>>>>>> deteriorate into mindless tick-offs -- but at least it does >>>>>>> not harm). >>>>>> >>>>>> How is it that a mentor became an IPMC member and do such an >>>>>> unethical thing such as a mindless tick-off? >>>>> >>>>> We're talking about human being here. The one who never ever cut >>>>> corners in his life can cast the first stone. >>>> >>>> I think that you misunderstood my rhetorical question. It is my >>>> experience/understanding that if a mentor makes an effort to review >>>> reports/releases then this mentor is actually doing a good job at it. >>>> It is my experience/understanding that the overwhelming problem is >>>> that mentors simply go MIA and do nothing at all. >>>> >>>> I am in favor of #3 since it holds mentors accountable. #1 is >>>> simply a washing of our hands and pawning the problem off on the >>>> board simple because some of us are unwilling to do uncomfortable things. >>>> >>>> >>>> Regards, >>>> Alan >>>> >>>> >>>> >>>> >>>
Re: Incubator report sign-off
> One extra thing to note, that while we can *start* this comittee as dedicated > to Incubating projects, it will be a very natural extension to get it involved > in monitoring all of TLPs, not just pTLPs. What problem exists today where the Board needs such a buffer? In what ways could this committee substitute its judgement for PMC of the TLP? How would one apply to be on this committee? Would this be a case of some members being more member than others? What would be the process and expectations for resolving disagreements between the TLP and this committee? On Mon, Jan 5, 2015 at 3:38 PM, Roman Shaposhnik wrote: > I am clearly hitting my rate-limit with emails to general@, still since > Ross' reply was one of the few pieces of feedback from the board, > I'll do this one and then wait for others to chime in (Benson?). > > On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) > wrote: > > This proposal is not necessarily flawed, but it is incomplete. > > Couldn't agree more. But! The whole point is to try our best > to get this: > https://wiki.apache.org/incubator/IncubatorV2 > to completion. Your direct feedback (as a sort of proxy for the > board) is *very* much appreciated. > > > As I've said repeatedly. This simply moves the problem it does > > not solve it. Today, a project has mentors, usually it works, > > but sometimes it doesn't. When it doesn't work someone needs > > to fix it. That is the work that is being moved from the IPMC to > > the board by the pTLP proposal. > > Benson, perhaps we need to create an FAQ around failure scenarios > on your wiki page. Here's what I would say to address the failure > scenario described by Ross. > > An addition of the overseeing committee, will shield the board from > *some* of the day-to-day business of telling the pTLP that something > needs to be fixed. So lets, break the cases down: >1. pTLP is *really* doing fine, which means: > 1.1. overseeing committee has nothing to address > 1.2. board *still* has to review the reports (as it does today) >and agrees with the overseeing committee >END RESULT: no additional work for the board > >2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee: > 2.1. board expresses its concerns *directly* to the pTLP PMC >while CCing the committee essentially pointing out something > that >fell through the cracks when it should NOT have. NOTE: a huge >difference here is that board does NOT expect a committee to >fix the issue, but rather makes it aware of something that > should've >been flagged by it. Only pTLP PMC can act to remedy the issue, >nobody else can help them (they could, of course, request help, >but again -- it has to come from them > 2.2. pTLP PMC either fixes the issue. The comittee and the board > are >happy again > 2.3. pTLP PMC doesn't fix the issue ==> GOTO #3 (we are expecting >the level of maturity and dedication from the committee members > so >that GOTO #2 becomes impossible since the board explicitly > flagged >this issue in 2.1) >END RESULT: no additional work for the board > >3. pTLP is NOT doing fine and it gets flagged by the committee, which > means: > 3.1. since committee is treated as an extension of the board, > its authority > and the gravity of its opinion have exactly the same > consequences if > the board flagged it (we may need to come up with > additional steps for > the board to vet the committee's opinion, though) > 3.2. the committee STILL is not responsible for fixing the > problem, the PMC is. >END RESULT: no additional work for the board > > Essentially, the overseeing committee acts as an extension of > the board, but the ultimate responsibility lies with pTLP PMCs. > In that sense the overseeing committee inherits the good and > the bad sides of the board. More specifically: > 1. it becomes a jackhammer, not a scalpel > 2. it is NOT expected to fix the problem, but rather unearth it > and delegate the solution to the PMC > 3. if PMC doesn't act *really* grave consequences could follow > 4. the level of maturity and the size of the committee needs to be > as close to the board's level as possible. That is the part that is > nicely addressed in Benson's wiki. > > Here's an elevator pitch: when it comes to running the foundation > according to the 'Apache Way', the committee is a vice-board. > > One extra thing to note, that while we can *start* this comittee as > dedicated > to Incubating projects, it will be a very natural extension to get it > involved > in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea > couldn't > have been timelier. > > Honestly, I really feel we've collectively stumbled on something really > promising her
Re: Incubator report sign-off
> An addition of the overseeing committee, will shield the board from > *some* of the day-to-day business of telling the pTLP that something > needs to be fixed. Is this pretty close to IPMC in another name? Who gets to be on the new overseeing committee? Not current IPMC membership right? So is that a revocation of privilege in some respects? On Mon, Jan 5, 2015 at 3:38 PM, Roman Shaposhnik wrote: > I am clearly hitting my rate-limit with emails to general@, still since > Ross' reply was one of the few pieces of feedback from the board, > I'll do this one and then wait for others to chime in (Benson?). > > On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) > wrote: > > This proposal is not necessarily flawed, but it is incomplete. > > Couldn't agree more. But! The whole point is to try our best > to get this: > https://wiki.apache.org/incubator/IncubatorV2 > to completion. Your direct feedback (as a sort of proxy for the > board) is *very* much appreciated. > > > As I've said repeatedly. This simply moves the problem it does > > not solve it. Today, a project has mentors, usually it works, > > but sometimes it doesn't. When it doesn't work someone needs > > to fix it. That is the work that is being moved from the IPMC to > > the board by the pTLP proposal. > > Benson, perhaps we need to create an FAQ around failure scenarios > on your wiki page. Here's what I would say to address the failure > scenario described by Ross. > > An addition of the overseeing committee, will shield the board from > *some* of the day-to-day business of telling the pTLP that something > needs to be fixed. So lets, break the cases down: >1. pTLP is *really* doing fine, which means: > 1.1. overseeing committee has nothing to address > 1.2. board *still* has to review the reports (as it does today) >and agrees with the overseeing committee >END RESULT: no additional work for the board > >2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee: > 2.1. board expresses its concerns *directly* to the pTLP PMC >while CCing the committee essentially pointing out something > that >fell through the cracks when it should NOT have. NOTE: a huge >difference here is that board does NOT expect a committee to >fix the issue, but rather makes it aware of something that > should've >been flagged by it. Only pTLP PMC can act to remedy the issue, >nobody else can help them (they could, of course, request help, >but again -- it has to come from them > 2.2. pTLP PMC either fixes the issue. The comittee and the board > are >happy again > 2.3. pTLP PMC doesn't fix the issue ==> GOTO #3 (we are expecting >the level of maturity and dedication from the committee members > so >that GOTO #2 becomes impossible since the board explicitly > flagged >this issue in 2.1) >END RESULT: no additional work for the board > >3. pTLP is NOT doing fine and it gets flagged by the committee, which > means: > 3.1. since committee is treated as an extension of the board, > its authority > and the gravity of its opinion have exactly the same > consequences if > the board flagged it (we may need to come up with > additional steps for > the board to vet the committee's opinion, though) > 3.2. the committee STILL is not responsible for fixing the > problem, the PMC is. >END RESULT: no additional work for the board > > Essentially, the overseeing committee acts as an extension of > the board, but the ultimate responsibility lies with pTLP PMCs. > In that sense the overseeing committee inherits the good and > the bad sides of the board. More specifically: > 1. it becomes a jackhammer, not a scalpel > 2. it is NOT expected to fix the problem, but rather unearth it > and delegate the solution to the PMC > 3. if PMC doesn't act *really* grave consequences could follow > 4. the level of maturity and the size of the committee needs to be > as close to the board's level as possible. That is the part that is > nicely addressed in Benson's wiki. > > Here's an elevator pitch: when it comes to running the foundation > according to the 'Apache Way', the committee is a vice-board. > > One extra thing to note, that while we can *start* this comittee as > dedicated > to Incubating projects, it will be a very natural extension to get it > involved > in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea > couldn't > have been timelier. > > Honestly, I really feel we've collectively stumbled on something really > promising here. > > > It's not necessarily a bad thing and may be acceptable to the board, > > but I don't understand why proponents of this approach feel it is a > > solution rather than a moving of the problem. > > Benson, another useful sectio
RE: Incubator report sign-off
Careful... most mentors do a great job. The problem is when all mentors fade away (which as volunteers they are entitled to do) and the IPMC doesn't notice. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan Cabrera [mailto:l...@toolazydogs.com] Sent: Monday, January 5, 2015 4:50 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off This statement confuses the lack of active mentors with the sheer size of the IPMC. The problem is not the size of the IPMC. The problem is that mentors are not doing their jobs Sent from my iPhone > On Jan 5, 2015, at 3:41 PM, Mattmann, Chris A (3980) > wrote: > > Yep and let all from that 170+ person committee be tracked down for > responsibility. Talk about s fun activity it's simply not scalable > > Sent from my iPhone > >> On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) >> wrote: >> >> But the board is not responsible for any actions resulting from those >> reviews, the IPMC is. >> >> Ross >> >> -Original Message- >> From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] >> Sent: Monday, January 5, 2015 9:31 AM >> To: general@incubator.apache.org >> Subject: Re: Incubator report sign-off >> >> It’s not a pawning off to the board - the board is already responsible for >> reviewing the IPMC report which includes *all of the same detail* that the >> IPMC also .. reviews. >> >> Cheers, >> Chris >> >> >> >> -Original Message----- >> From: "Alan D. Cabrera" >> Reply-To: "general@incubator.apache.org" >> >> Date: Monday, January 5, 2015 at 8:59 AM >> To: "general@incubator.apache.org" >> Subject: Re: Incubator report sign-off >> >>> >>>> On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik wrote: >>>> >>>> On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera >>>> >>>> wrote: >>>>> >>>>>> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >>>>>> >>>>>> 1. get rid of IPMC altogether and move to the pTLP model >>>>> >>>>> This is effectively an IPMC reboot. I don’t really see anything >>>>> substantially different. >>>> >>>> At this point, I'm convinced this is the only fruitful path >>>> forward, the rest is a shell game with responsibility. See the other >>>> thread. >>>> >>>>>> 3. patch the current process with starting to drop the mentors from >>>>>> the project who don't sign off. This will essentially serve >>>>>> as a heartbeat for mentors (now, in my opinion it'll quickly >>>>>>deteriorate into mindless tick-offs -- but at least it does >>>>>> not harm). >>>>> >>>>> How is it that a mentor became an IPMC member and do such an >>>>> unethical thing such as a mindless tick-off? >>>> >>>> We're talking about human being here. The one who never ever cut >>>> corners in his life can cast the first stone. >>> >>> I think that you misunderstood my rhetorical question. It is my >>> experience/understanding that if a mentor makes an effort to review >>> reports/releases then this mentor is actually doing a good job at it. >>> It is my experience/understanding that the overwhelming problem is >>> that mentors simply go MIA and do nothing at all. >>> >>> I am in favor of #3 since it holds mentors accountable. #1 is >>> simply a washing of our hands and pawning the problem off on the >>> board simple because some of us are unwilling to do uncomfortable things. >>> >>> >>> Regards, >>> Alan >>> >>> >>> >>> >>> >>> >>> >>> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >> >> B >> C >> B [ X ÜšX KK[XZ[ [ \ [ ][ X ÜšX P[ X ]Ü‹ \X K Ü™ B >> ܈Y][Û˜[ [X[ K[XZ[ [ \ [ Z[ [ X ]Ü‹ \X K Ü™ B >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org > Т > ÐÐ¥Fò > Vç7V'67&–&RÂRÖ֖âvVæW&Â×Vç7V'67&–&T–æ7V&F÷"æ6†Ræ÷&pФf÷"FF > —F–öæÂ6öÖÖæG2ÂRÖ֖âvVæW&ÂÖ†VÇ–æ7V&F÷"æ6†Ræ÷&pÐ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
This statement confuses the lack of active mentors with the sheer size of the IPMC. The problem is not the size of the IPMC. The problem is that mentors are not doing their jobs Sent from my iPhone > On Jan 5, 2015, at 3:41 PM, Mattmann, Chris A (3980) > wrote: > > Yep and let all from that 170+ person committee be tracked down for > responsibility. Talk about s fun activity it's simply not scalable > > Sent from my iPhone > >> On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) >> wrote: >> >> But the board is not responsible for any actions resulting from those >> reviews, the IPMC is. >> >> Ross >> >> -Original Message- >> From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] >> Sent: Monday, January 5, 2015 9:31 AM >> To: general@incubator.apache.org >> Subject: Re: Incubator report sign-off >> >> It’s not a pawning off to the board - the board is already responsible for >> reviewing the IPMC report which includes *all of the same detail* that the >> IPMC also .. reviews. >> >> Cheers, >> Chris >> >> >> >> -Original Message----- >> From: "Alan D. Cabrera" >> Reply-To: "general@incubator.apache.org" >> Date: Monday, January 5, 2015 at 8:59 AM >> To: "general@incubator.apache.org" >> Subject: Re: Incubator report sign-off >> >>> >>>> On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik wrote: >>>> >>>> On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera >>>> >>>> wrote: >>>>> >>>>>> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >>>>>> >>>>>> 1. get rid of IPMC altogether and move to the pTLP model >>>>> >>>>> This is effectively an IPMC reboot. I don’t really see anything >>>>> substantially different. >>>> >>>> At this point, I'm convinced this is the only fruitful path forward, >>>> the rest is a shell game with responsibility. See the other thread. >>>> >>>>>> 3. patch the current process with starting to drop the mentors from >>>>>> the project who don't sign off. This will essentially serve >>>>>> as a heartbeat for mentors (now, in my opinion it'll quickly >>>>>>deteriorate into mindless tick-offs -- but at least it does >>>>>> not harm). >>>>> >>>>> How is it that a mentor became an IPMC member and do such an >>>>> unethical thing such as a mindless tick-off? >>>> >>>> We're talking about human being here. The one who never ever cut >>>> corners in his life can cast the first stone. >>> >>> I think that you misunderstood my rhetorical question. It is my >>> experience/understanding that if a mentor makes an effort to review >>> reports/releases then this mentor is actually doing a good job at it. >>> It is my experience/understanding that the overwhelming problem is that >>> mentors simply go MIA and do nothing at all. >>> >>> I am in favor of #3 since it holds mentors accountable. #1 is simply a >>> washing of our hands and pawning the problem off on the board simple >>> because some of us are unwilling to do uncomfortable things. >>> >>> >>> Regards, >>> Alan >>> >>> >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >> >> B CB >> [ X ÜšX KK[XZ[ >> [ \ [ >> ][ X ÜšX P[ X ]Ü‹ \X K Ü™ B ܈Y][Û˜[ [X[ K[XZ[ >> [ \ [ >> Z[ [ X ]Ü‹ \X K Ü™ B >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org > ТÐÐ¥FòVç7V'67&–&RÂRÖ֖âvVæW&Â×Vç7V'67&–&T–æ7V&F÷"æ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âvVæW&ÂÖ†VÇ–æ7V&F÷"æ6†Ræ÷&pÐ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
Thanks Roman, this looks like a really good step forward. With these modifications this proposal is very similar to my original proposal to have a subset of the PMC act like the board and have all the authority of the board when dealing with podlings/pTLP or any other incubation vehicle we might want to try. I think I first made it about three years ago and have repeated it numerous times over the years, including recently in these thread. The first time I proposed this it got watered down into the shepherds role (which certainly helped but is not complete). I've talked to Sam about leveraging the tools we use for the board here in the IPMC. He says it would require a little work on both the tools and the processes but he is game for it. He's ready to discuss onlist if this is something that people want to explore, as am I. It also occurs to me that this same committee could perform the periodic reviews Rich is proposing, using the same tooling. Any other of the many proposals can also work within this construct. Nothing here should be seen as mutually exclusive. All I'm trying to do is ensure that some group of people take responsibility. A bit of a rant follows feel free to stop reading now, I leave it for those who want to see into my reasoning ... Let's think about the work a Director should do when reviewing a report. It’s not reading the report and then ticking a box. It's reading a report, comparing it to previous reports. Taking a quick look at the tone of emails on the dev list. Looking at commit activity. Checking the private list is not too active and more. We have some great tools (thanks Sam) for helping with this process, but it's still time consuming. We also have the concept of Shepherds. Those shepherds are expected to fully review a projects report and status. They will typically spend 10 minutes more than other directors and will be able to answer any questions that come up in the meeting from other directors. To really review a project properly takes a good 10 mins for non-shepherds and 20-30 minutes for shepherds (at least that is how long *I* spend on each report, I think most, if not all, directors would say the same). This is the case if there is no difficulties. If there are difficulties you can be talking about hours. Even with no problems this is around half a day *extra* work for each *volunteer* board member to review the podling/pTLP/whetever reports properly. I don't know about other Directors but I can't afford another half day of distractions from my day job - my employer is already being very generous with my time for the ASF. As an example of how long it takes to decide whether or not action is taken let me give you two concrete examples. Last night I spent just over four hours reviewing the archives of a TLP to see if a potential problem was actually a problem. I've spent maybe another 2 hours in email threads on the topic. For another project a different director has spent what I would estimate to be at least three hours reviewing and addressing an issue while I've spent maybe an hour tracking those threads to see if I need to help out. That's just in the last week, just the items I'm aware of and it doesn't address other things the directors do on a weekly basis. If, however, we run the IPMC like the board with formal review meetings with identified responsible people (Bensons committee if you prefer that over my earlier proposals) then things start to look more manageable because the responsibility remains delegated across a larger team of people who are accountable. It gives a group of individuals the authority to act if and when they need to, just as the board does for TLPs. It need not be surgical (that's what mentors are for), but it does need to act. It also gives that group the recognition that they deserve do doing a job well. This is very similar to Bensons proposal with your modifications below. It just removes the need for the board to take on additional responsibility which, in my opinion, it doesn't have the time for even if one or two directors do (those directors can volunteer that time to the IPMC either as part of the core committee, to count ticks in boxes, to properly review podling status or to conduct parallel pTLP experiments or whetever). 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: Monday, January 5, 2015 3:39 PM To: general@incubator.apache.org; Benson Margulies Subject: Re: Incubator report sign-off I am clearly hitting my rate-limit with emails to general@, still since Ross' reply was one of the few pieces of feedback from the board, I'll do this one and then wait for others to chime in (Benson?). On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (M
RE: Incubator report sign-off
Note from the board - from an IPMC member (and yes, my opinions don't change if I put my Director hat on but don't assume that I speak for all board members) 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: Monday, January 5, 2015 3:39 PM To: general@incubator.apache.org; Benson Margulies Subject: Re: Incubator report sign-off I am clearly hitting my rate-limit with emails to general@, still since Ross' reply was one of the few pieces of feedback from the board, I'll do this one and then wait for others to chime in (Benson?). On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) wrote: > This proposal is not necessarily flawed, but it is incomplete. Couldn't agree more. But! The whole point is to try our best to get this: https://wiki.apache.org/incubator/IncubatorV2 to completion. Your direct feedback (as a sort of proxy for the board) is *very* much appreciated. > As I've said repeatedly. This simply moves the problem it does not > solve it. Today, a project has mentors, usually it works, but > sometimes it doesn't. When it doesn't work someone needs to fix it. > That is the work that is being moved from the IPMC to the board by the > pTLP proposal. Benson, perhaps we need to create an FAQ around failure scenarios on your wiki page. Here's what I would say to address the failure scenario described by Ross. An addition of the overseeing committee, will shield the board from *some* of the day-to-day business of telling the pTLP that something needs to be fixed. So lets, break the cases down: 1. pTLP is *really* doing fine, which means: 1.1. overseeing committee has nothing to address 1.2. board *still* has to review the reports (as it does today) and agrees with the overseeing committee END RESULT: no additional work for the board 2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee: 2.1. board expresses its concerns *directly* to the pTLP PMC while CCing the committee essentially pointing out something that fell through the cracks when it should NOT have. NOTE: a huge difference here is that board does NOT expect a committee to fix the issue, but rather makes it aware of something that should've been flagged by it. Only pTLP PMC can act to remedy the issue, nobody else can help them (they could, of course, request help, but again -- it has to come from them 2.2. pTLP PMC either fixes the issue. The comittee and the board are happy again 2.3. pTLP PMC doesn't fix the issue ==> GOTO #3 (we are expecting the level of maturity and dedication from the committee members so that GOTO #2 becomes impossible since the board explicitly flagged this issue in 2.1) END RESULT: no additional work for the board 3. pTLP is NOT doing fine and it gets flagged by the committee, which means: 3.1. since committee is treated as an extension of the board, its authority and the gravity of its opinion have exactly the same consequences if the board flagged it (we may need to come up with additional steps for the board to vet the committee's opinion, though) 3.2. the committee STILL is not responsible for fixing the problem, the PMC is. END RESULT: no additional work for the board Essentially, the overseeing committee acts as an extension of the board, but the ultimate responsibility lies with pTLP PMCs. In that sense the overseeing committee inherits the good and the bad sides of the board. More specifically: 1. it becomes a jackhammer, not a scalpel 2. it is NOT expected to fix the problem, but rather unearth it and delegate the solution to the PMC 3. if PMC doesn't act *really* grave consequences could follow 4. the level of maturity and the size of the committee needs to be as close to the board's level as possible. That is the part that is nicely addressed in Benson's wiki. Here's an elevator pitch: when it comes to running the foundation according to the 'Apache Way', the committee is a vice-board. One extra thing to note, that while we can *start* this comittee as dedicated to Incubating projects, it will be a very natural extension to get it involved in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea couldn't have been timelier. Honestly, I really feel we've collectively stumbled on something really promising here. > It's not necessarily a bad thing and may be acceptable to the board, > but I don't understand why proponents of this approach feel it is a > solution rather than
Re: Incubator report sign-off
Yep and let all from that 170+ person committee be tracked down for responsibility. Talk about s fun activity it's simply not scalable Sent from my iPhone > On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) > wrote: > > But the board is not responsible for any actions resulting from those > reviews, the IPMC is. > > Ross > > -Original Message- > From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] > Sent: Monday, January 5, 2015 9:31 AM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > It’s not a pawning off to the board - the board is already responsible for > reviewing the IPMC report which includes *all of the same detail* that the > IPMC also .. reviews. > > Cheers, > Chris > > > > -Original Message- > From: "Alan D. Cabrera" > Reply-To: "general@incubator.apache.org" > Date: Monday, January 5, 2015 at 8:59 AM > To: "general@incubator.apache.org" > Subject: Re: Incubator report sign-off > >> >>> On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik wrote: >>> >>> On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera >>> >>> wrote: >>>> >>>>> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >>>>> >>>>> 1. get rid of IPMC altogether and move to the pTLP model >>>> >>>> This is effectively an IPMC reboot. I don’t really see anything >>>> substantially different. >>> >>> At this point, I'm convinced this is the only fruitful path forward, >>> the rest is a shell game with responsibility. See the other thread. >>> >>>>> 3. patch the current process with starting to drop the mentors from >>>>> the project who don't sign off. This will essentially serve >>>>> as a heartbeat for mentors (now, in my opinion it'll quickly >>>>> deteriorate into mindless tick-offs -- but at least it does >>>>> not harm). >>>> >>>> How is it that a mentor became an IPMC member and do such an >>>> unethical thing such as a mindless tick-off? >>> >>> We're talking about human being here. The one who never ever cut >>> corners in his life can cast the first stone. >> >> I think that you misunderstood my rhetorical question. It is my >> experience/understanding that if a mentor makes an effort to review >> reports/releases then this mentor is actually doing a good job at it. >> It is my experience/understanding that the overwhelming problem is that >> mentors simply go MIA and do nothing at all. >> >> I am in favor of #3 since it holds mentors accountable. #1 is simply a >> washing of our hands and pawning the problem off on the board simple >> because some of us are unwilling to do uncomfortable things. >> >> >> Regards, >> Alan >> >> >> >> >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org > > B CB > [ X ܚX KK[XZ[ > [ \ [ > ][ X ܚX P[ X ]܋ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ > [ \ [ > Z[ [ X ]܋ \X K ܙ B > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
I am clearly hitting my rate-limit with emails to general@, still since Ross' reply was one of the few pieces of feedback from the board, I'll do this one and then wait for others to chime in (Benson?). On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) wrote: > This proposal is not necessarily flawed, but it is incomplete. Couldn't agree more. But! The whole point is to try our best to get this: https://wiki.apache.org/incubator/IncubatorV2 to completion. Your direct feedback (as a sort of proxy for the board) is *very* much appreciated. > As I've said repeatedly. This simply moves the problem it does > not solve it. Today, a project has mentors, usually it works, > but sometimes it doesn't. When it doesn't work someone needs > to fix it. That is the work that is being moved from the IPMC to > the board by the pTLP proposal. Benson, perhaps we need to create an FAQ around failure scenarios on your wiki page. Here's what I would say to address the failure scenario described by Ross. An addition of the overseeing committee, will shield the board from *some* of the day-to-day business of telling the pTLP that something needs to be fixed. So lets, break the cases down: 1. pTLP is *really* doing fine, which means: 1.1. overseeing committee has nothing to address 1.2. board *still* has to review the reports (as it does today) and agrees with the overseeing committee END RESULT: no additional work for the board 2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee: 2.1. board expresses its concerns *directly* to the pTLP PMC while CCing the committee essentially pointing out something that fell through the cracks when it should NOT have. NOTE: a huge difference here is that board does NOT expect a committee to fix the issue, but rather makes it aware of something that should've been flagged by it. Only pTLP PMC can act to remedy the issue, nobody else can help them (they could, of course, request help, but again -- it has to come from them 2.2. pTLP PMC either fixes the issue. The comittee and the board are happy again 2.3. pTLP PMC doesn't fix the issue ==> GOTO #3 (we are expecting the level of maturity and dedication from the committee members so that GOTO #2 becomes impossible since the board explicitly flagged this issue in 2.1) END RESULT: no additional work for the board 3. pTLP is NOT doing fine and it gets flagged by the committee, which means: 3.1. since committee is treated as an extension of the board, its authority and the gravity of its opinion have exactly the same consequences if the board flagged it (we may need to come up with additional steps for the board to vet the committee's opinion, though) 3.2. the committee STILL is not responsible for fixing the problem, the PMC is. END RESULT: no additional work for the board Essentially, the overseeing committee acts as an extension of the board, but the ultimate responsibility lies with pTLP PMCs. In that sense the overseeing committee inherits the good and the bad sides of the board. More specifically: 1. it becomes a jackhammer, not a scalpel 2. it is NOT expected to fix the problem, but rather unearth it and delegate the solution to the PMC 3. if PMC doesn't act *really* grave consequences could follow 4. the level of maturity and the size of the committee needs to be as close to the board's level as possible. That is the part that is nicely addressed in Benson's wiki. Here's an elevator pitch: when it comes to running the foundation according to the 'Apache Way', the committee is a vice-board. One extra thing to note, that while we can *start* this comittee as dedicated to Incubating projects, it will be a very natural extension to get it involved in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea couldn't have been timelier. Honestly, I really feel we've collectively stumbled on something really promising here. > It's not necessarily a bad thing and may be acceptable to the board, > but I don't understand why proponents of this approach feel it is a > solution rather than a moving of the problem. Benson, another useful section on the wiki could be explicit listing of the benefits of the proposal. Here's what I see as benefits: 1. the new scheme avoids a very dangerous delusion that IPMC somehow can 'fix' problems. In the new scheme that is clearly not the case -- only PMC can fix problems (or perish!). This is very much in-line with how TLPs are setup. 2. it avoids a very dangerous idea of IPMC having a 'collective responsibility' for projects (and we all know if everybody is responsible -- nobody really is). In the new scheme, the only place responsible for success of the project
RE: Incubator report sign-off
As I've said repeatedly. This simply moves the problem it does not solve it. Today, a project has mentors, usually it works, but sometimes it doesn't. When it doesn't work someone needs to fix it. That is the work that is being moved from the IPMC to the board by the pTLP proposal. It's not necessarily a bad thing and may be acceptable to the board, but I don't understand why proponents of this approach feel it is a solution rather than a moving of the problem. Furthermore, I've not even started on who would own the documentation aspect (yes the proposal is ComDev but just as last time this was circulated nobody has asked ComDev if they are willing to take it on and nobody has turned up in ComDev to do the work. This proposal is not necessarily flawed, but it is incomplete. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Monday, January 5, 2015 1:52 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off On Mon, Jan 5, 2015 at 1:07 PM, Ross Gardler (MS OPEN TECH) wrote: > But the board is not responsible for any actions resulting from those > reviews, the IPMC is. Agreed for the state of the things today. What is being proposed is that actions resulting from those reviews are going to be pTLPs PMC responsibility. Since in the new world order each pTLP PMC is guaranteed to have 3 ASF members and a chair (one of the 3) that is also an ASF member, I don't think I can see how this would be disagreeable with the mechanics of ASF board. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Mon, Jan 5, 2015 at 1:07 PM, Ross Gardler (MS OPEN TECH) wrote: > But the board is not responsible for any actions resulting from those > reviews, the IPMC is. Agreed for the state of the things today. What is being proposed is that actions resulting from those reviews are going to be pTLPs PMC responsibility. Since in the new world order each pTLP PMC is guaranteed to have 3 ASF members and a chair (one of the 3) that is also an ASF member, I don't think I can see how this would be disagreeable with the mechanics of ASF board. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
But the board is not responsible for any actions resulting from those reviews, the IPMC is. Ross -Original Message- From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] Sent: Monday, January 5, 2015 9:31 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off It’s not a pawning off to the board - the board is already responsible for reviewing the IPMC report which includes *all of the same detail* that the IPMC also .. reviews. Cheers, Chris -Original Message- From: "Alan D. Cabrera" Reply-To: "general@incubator.apache.org" Date: Monday, January 5, 2015 at 8:59 AM To: "general@incubator.apache.org" Subject: Re: Incubator report sign-off > >On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik wrote: > >> On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera >> >>wrote: >>> >>>> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >>>> >>>> 1. get rid of IPMC altogether and move to the pTLP model >>> >>> This is effectively an IPMC reboot. I don’t really see anything >>>substantially different. >> >> At this point, I'm convinced this is the only fruitful path forward, >> the rest is a shell game with responsibility. See the other thread. >> >>>> 3. patch the current process with starting to drop the mentors from >>>> the project who don't sign off. This will essentially serve >>>> as a heartbeat for mentors (now, in my opinion it'll quickly >>>> deteriorate into mindless tick-offs -- but at least it does >>>>not harm). >>> >>> How is it that a mentor became an IPMC member and do such an >>>unethical thing such as a mindless tick-off? >> >> We're talking about human being here. The one who never ever cut >> corners in his life can cast the first stone. > >I think that you misunderstood my rhetorical question. It is my >experience/understanding that if a mentor makes an effort to review >reports/releases then this mentor is actually doing a good job at it. >It is my experience/understanding that the overwhelming problem is that >mentors simply go MIA and do nothing at all. > >I am in favor of #3 since it holds mentors accountable. #1 is simply a >washing of our hands and pawning the problem off on the board simple >because some of us are unwilling to do uncomfortable things. > > >Regards, >Alan > > > > > > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > B CB [ X ܚX KK[XZ[ [ \ [ ][ X ܚX P[ X ]܋ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ [ \ [ Z[ [ X ]܋ \X K ܙ B - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
It’s not a pawning off to the board - the board is already responsible for reviewing the IPMC report which includes *all of the same detail* that the IPMC also .. reviews. Cheers, Chris -Original Message- From: "Alan D. Cabrera" Reply-To: "general@incubator.apache.org" Date: Monday, January 5, 2015 at 8:59 AM To: "general@incubator.apache.org" Subject: Re: Incubator report sign-off > >On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik wrote: > >> On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera >>wrote: >>> >>>> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >>>> >>>> 1. get rid of IPMC altogether and move to the pTLP model >>> >>> This is effectively an IPMC reboot. I don’t really see anything >>>substantially different. >> >> At this point, I'm convinced this is the only fruitful path forward, >> the rest is a shell game with responsibility. See the other thread. >> >>>> 3. patch the current process with starting to drop the mentors from >>>> the project who don't sign off. This will essentially serve >>>> as a heartbeat for mentors (now, in my opinion it'll quickly >>>> deteriorate into mindless tick-offs -- but at least it does not >>>>harm). >>> >>> How is it that a mentor became an IPMC member and do such an unethical >>>thing such as a mindless tick-off? >> >> We're talking about human being here. The one who never >> ever cut corners in his life can cast the first stone. > >I think that you misunderstood my rhetorical question. It is my >experience/understanding that if a mentor makes an effort to review >reports/releases then this mentor is actually doing a good job at it. It >is my experience/understanding that the overwhelming problem is that >mentors simply go MIA and do nothing at all. > >I am in favor of #3 since it holds mentors accountable. #1 is simply a >washing of our hands and pawning the problem off on the board simple >because some of us are unwilling to do uncomfortable things. > > >Regards, >Alan > > > > > > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org >
Re: Incubator report sign-off
On Mon, Jan 5, 2015 at 8:59 AM, Alan D. Cabrera wrote: > I am in favor of #3 since it holds mentors accountable. #1 is simply a > washing of > our hands and pawning the problem off on the board simple because some of us > are unwilling to do uncomfortable things. Here's the bit that seems to be misunderstood a lot in pTLP discussion: the appealing part of that proposal is making mentors part of *real* PMCs of *real* projects, as opposed to being beholden to a vague committee (IPMC). In my (and a few others) opinion, this is the only structuring of incentive that would make a needle on mentors being there *for real*. At least as real as all the other PMCs of TLPs (which should be as good as it gets at ASF). That said, lets argue this in a thread where it belongs (the one started by Benson). Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik wrote: > On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera wrote: >> >>> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >>> >>> 1. get rid of IPMC altogether and move to the pTLP model >> >> This is effectively an IPMC reboot. I don’t really see anything >> substantially different. > > At this point, I'm convinced this is the only fruitful path forward, > the rest is a shell game with responsibility. See the other thread. > >>> 3. patch the current process with starting to drop the mentors from >>> the project who don't sign off. This will essentially serve >>> as a heartbeat for mentors (now, in my opinion it'll quickly >>> deteriorate into mindless tick-offs -- but at least it does not harm). >> >> How is it that a mentor became an IPMC member and do such an unethical thing >> such as a mindless tick-off? > > We're talking about human being here. The one who never > ever cut corners in his life can cast the first stone. I think that you misunderstood my rhetorical question. It is my experience/understanding that if a mentor makes an effort to review reports/releases then this mentor is actually doing a good job at it. It is my experience/understanding that the overwhelming problem is that mentors simply go MIA and do nothing at all. I am in favor of #3 since it holds mentors accountable. #1 is simply a washing of our hands and pawning the problem off on the board simple because some of us are unwilling to do uncomfortable things. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera wrote: > >> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: >> >>1. get rid of IPMC altogether and move to the pTLP model > > This is effectively an IPMC reboot. I don’t really see anything > substantially different. At this point, I'm convinced this is the only fruitful path forward, the rest is a shell game with responsibility. See the other thread. >>3. patch the current process with starting to drop the mentors from >>the project who don't sign off. This will essentially serve >>as a heartbeat for mentors (now, in my opinion it'll quickly >> deteriorate into mindless tick-offs -- but at least it does not harm). > > How is it that a mentor became an IPMC member and do such an unethical thing > such as a mindless tick-off? We're talking about human being here. The one who never ever cut corners in his life can cast the first stone. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
> Our goal as a foundation is not to > be large, it is to be high quality. +100 !oneoneone :) The problem is that sub-par technical contributions quickly lead to community issues as well. Please all ask yourself: would YOU like to contribute to a project where you have to look at every single commit someone does because they often are not of the quality you would expect from an ASF project? And imagine what the community effect is if you need to clean up after every other commit someone does. Sometimes it gets better over time, sometimes it doesn't. In any case it's very time consuming and to be a proper mentor we imo cannot just glimpse over the project but we need to dig under the skin of it. It might not be needed to know all the subtle details of the project you are mentoring. But you must at least get a feeling if something technically and community wise has a bad taste. Often this can be fixed by real mentoring (not in the ASF but in the literal sense) and sometimes we probably also need to use the emergency exit. LieGrue, strub > On Friday, 19 December 2014, 20:01, Ross Gardler (MS OPEN TECH) > wrote: > > Strawman: > > What if a mentor is *required* to be an active participant of the project. > That > is contributing code, voting on releases and generally engaging with the > community, they would be a better mentor since they have a vested interest in > the project itself. Sure, we might reduce the number of projects coming into > the > foundation but (IMHO) that is not a problem. Our goal as a foundation is not > to > be large, it is to be high quality. > > Maybe we should simply scrap the idea of "mentors" and change the role > of the "champion" to one of an initial committer who will help build > an Apache project as it incubates and into being a TLP. > > We could scrap the role of shepherd and change the role of mentors. A team of > 9 > mentors would meet monthly to review *all* podlings reports (as submitted by > the > champion). Their responsibility is not to engage with the projects but to > review > the reports crafted by the champion. Any follow up actions would be taken by > a > single mentor and podlings (especially the champion) are expected to address > the > issues raised. > > If a champion's priorities change during the course of incubation then the > project must find another champion (potentially from within their own ranks) > who > is sufficiently qualified and committed to take on the responsibility. The > important thing is that the Champion is personally invested in seeing the > podling succeed and acts as a true mentor (as opposed to someone with a title > and an entry on a web page). The champion is still answerable to the podling > community. Where conflict arises within the community they can call upon the > IPMC mentoring team to ask for independent guidance. > > This model is almost identical to the way the board and TLPs work (where > Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) > are > roughly equivalent to Directors and he monthly meeting is roughly equivalent > to > the monthly board meeting to review TLP reports). I've designed it this way > (and proposed the same solution before) because it is proven to work for TLPs > and we have tooling to assist with the process. > > I look forward to the PMC tearing this strawman proposal apart and (most > importantly) suggesting alternatives and/or tweaks of value. We've been > skirting this issue for far too long. Things have improved (thanks to all who > have worked hard on this), but we have not yet solved the problem. > > 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: Friday, December 19, 2014 10:11 AM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > Hi Rich! > > Thanks for raising this point and giving us a bit more of a forcing function > to > tackle an old problem: accountability for mentors. > > On Fri, Dec 19, 2014 at 9:10 AM, Rich Bowen wrote: >> I certainly don't expect that every mentor has their full attention on >> a podling every month, but I do expect that a podling that cares about >> its incubation will seek out that mentor sign-off, and that the >> mentors who have committed to help a podling into the family will have >> a few moments every few months to look in and approve a report. > > I've been thinking about this for quite some time (and trying to seek a > solution by
Re: Incubator report sign-off
> On Dec 29, 2014, at 6:40 AM, Rich Bowen wrote: > >> 3. patch the current process with starting to drop the mentors from >> the project who don't sign off. This will essentially serve >> as a heartbeat for mentors (now, in my opinion it'll quickly >>deteriorate into mindless tick-offs -- but at least it does not harm). >> > > ... who don't sign off N times, perhaps? Missing one should be a warning, two > a scolding, three the boot, perhaps? +1 Regards, Alan
Re: Incubator report sign-off
> On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik wrote: > >1. get rid of IPMC altogether and move to the pTLP model This is effectively an IPMC reboot. I don’t really see anything substantially different. >2. make this a poddling issue: if a poddling fails to hunt down ALL >the mentors for a sign-off -- reject its report This tactic has no teeth. If the mentors are MIA do you think that they would care if a report were rejected? >3. patch the current process with starting to drop the mentors from >the project who don't sign off. This will essentially serve >as a heartbeat for mentors (now, in my opinion it'll quickly > deteriorate into mindless tick-offs -- but at least it does not harm). How is it that a mentor became an IPMC member and do such an unethical thing such as a mindless tick-off? Regards, Alan
Re: Incubator report sign-off
> On Dec 19, 2014, at 9:10 AM, Rich Bowen wrote: > > I noted in my comments on the recent Incubator board report that I am > concerned, month after month, at the number of podlings that have no mentor > sign-off at all, as well as the ones where a minority of the mentors sign-off. > > I certainly don't expect that every mentor has their full attention on a > podling every month, but I do expect that a podling that cares about its > incubation will seek out that mentor sign-off, and that the mentors who have > committed to help a podling into the family will have a few moments every few > months to look in and approve a report. > > The result, unfortunately, is that we have projects graduating with no notion > of the importance of reporting, and so we have TLPs that look at reporting as > a checkbox, submit exactly the same cut-and-paste report each month, some of > them without even changing stats and dates, or skip their reporting entirely. > > I don't mean to point fingers here - this is a problem that has existed > literally since the beginning of the Incubator, and I'm not innocent of it > myself. Indeed, I don't show up often enough even on this list. > > But I wonder if we might, as the Board does, reject reports that have no > sign-off, and force projects to report again the following month, in an > attempt to require them to engage with their mentor(s) a little more? This > seems like a small, easily reversible, step, that has a good chance of > achieving something. > > Thoughts? A while back I proposed to make the podlings and mentors accountable. Podlings would be required to have a minimum of two active mentors. A mentor is free to become inactive but must explicitly state this else the mentor risks being removed for not performing their duties. Podlings that do not have the minimum of two active mentors are put on hold until they find enough mentors to fill the quota. Being put on hold means that no committers can be added, no PPMC members can be added, and no releases can be performed. It does not stop development. Mentors who do not review and vote on a podlings releases are marked inactive. Mentors who do not review and sign board reports are marked inactive. Regards, Alan
RE: Process over Ego [Was: Re: Incubator report sign-off
Inviting those people to become members is a good idea (and in fact was agreed a long time ago when we brought the first non-members into the IPMC). I think we have a number of members now who started out as IPMC members. It is clear (at least to me) that anyone who proves themselves to be a good mentor should be a Member. However, you can't "promote" people to ComDev. ComDev is a project like any other. If folks want to show up there and do work they will be welcomed like any other volunteer. However, we can't assume that people signing up to the IPMC are also interested in the work ComDev do. At this time ComDev is *not* responsible for incubation processes, the IPMC is. Of course what ComDev does is dependent on who shows up there to help. The idea of moving incubation to ComDev has been discussed many times (or more accurately the maintenance of the incubation process and docs). However, to date nobody has joined ComDev to make it happen and the existing ComDev team signed up for a different purpose. As for the board "ignoring the problem" it should be understood the board have delegated the incubation process to the IPMC. It is the IPMC that need to solve the problem - not the board. However, lets not pretend the board are "ignoring" things. Take a look at who it is that brings this up every x months. It's always the board. Now, if the current chair and the IPMC really feels that disbanding the IPMC is the right solution then submit a resolution to do so. That will make it a board problem, until then it is an IPMC problem. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Tuesday, December 30, 2014 8:25 PM To: general@incubator.apache.org Subject: Re: Process over Ego [Was: Re: Incubator report sign-off On Tue, Dec 30, 2014 at 9:48 AM, Mattmann, Chris A (3980) wrote: > So, promote those 20 people to ComDev PMC, promote them to ASF > members, promote them however, my guess is that they *care* about the > foundation; we want these people helping new projects, and they will > continue to help those new projects - along with the board - along > with everyone else. Thank you! Thank you for saying out loud what has become painfully obvious for me during the course of my tenure as an IPMC Chair. Personally, I see this as the only *honest* way forward. But I guess, IPMC has become too convenient a way for everybody to ignore the real problem. Including, I am sorry to say this, the board itself. I think it is time we address it instead of blindly going through the motions. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process over Ego [Was: Re: Incubator report sign-off
On Tue, Dec 30, 2014 at 9:48 AM, Mattmann, Chris A (3980) wrote: > So, promote those 20 people to ComDev PMC, promote them to ASF > members, promote them however, my guess is that they *care* about > the foundation; we want these people helping new projects, and they > will continue to help those new projects - along with the board - along > with everyone else. Thank you! Thank you for saying out loud what has become painfully obvious for me during the course of my tenure as an IPMC Chair. Personally, I see this as the only *honest* way forward. But I guess, IPMC has become too convenient a way for everybody to ignore the real problem. Including, I am sorry to say this, the board itself. I think it is time we address it instead of blindly going through the motions. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Tue, Dec 30, 2014 at 8:07 PM, Ross Gardler (MS OPEN TECH) wrote: > This is at the root of my proposal to *expect* mentors to have a vested > interest in the success of a project. Every single one of us here shares that *expectation*. What this thread fails to address is a *practically* mechanism for that expectation to be met. After re-reading what Chris and Benson wrote, personally I'm convinced that this is, in part, because IPMC is just not incentivised to solve this problem. Just like if developers on an ASF project are not incentivised to work on a particular feature -- there will be no code, regardless of the ammount of email traffic and JIRA "tracking". I'll start a separate thread on this in the final [futile] attempt to move the needle on what a better, more responsible version of the incubation process should be offer. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
:-) Yes, it is shocking that the Ripple project had a number of signed off reports while inappropriate releases were being made. This problem only came to light because the community was considering retirement and some of my day job colleagues wanted me to look at it. In other words, I have a vested interest in seeing if things can be fixed, so I stepped up to see if they can. This is at the root of my proposal to *expect* mentors to have a vested interest in the success of a project. Ross -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, December 30, 2014 8:05 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off Ross, I think we're actually on the same page. My point with ripple was not so much that it wasn't bringing it to anyone's attention (in fact the opposite, it's plastered all over the report) but more that a simple checkbox doesn't mean everything's great. John On Tue Dec 30 2014 at 10:59:33 PM Ross Gardler (MS OPEN TECH) < ross.gard...@microsoft.com> wrote: > John, > > Actually John I disagree with one of your examples (Ripple). This is > actually a case where things have gone as they would expect. > > The mail you link to is from me. I had previously made the IPMC aware > of the issue prior to that email on the mailing list. I was asked if I > was undertaking to fix it (I replied yes and requested the podling > added me as a mentor in order to do so). The podling report indicated > that getting a release out was a focus "No release made as yet, this > will be the first item to recieve attention." > > The report does not need more detail than that since the IPMC had > already been made aware that there was a problem, that it had been > spotted and that the community and mentors indicated that they were to > address it. > > Finally, if you review the shepherds notes from that report they > acknowledge the concern and the fact that there was activity to address it. > > Ripple still has not addressed the issue raised those emails. > Therefore it will not graduate until it does. The email you link to > makes this perfectly clear. > > This is, in my opinion, exactly what should be happening. We provide > oversight to ensure project acts as an Apache project. If it does so > we graduate it, if it doesn't we retire it. > > I do agree with the overall intention of your mail, but it seems I > disagree on what adequate oversight is. > > Ross > > -Original Message- > From: John D. Ament [mailto:johndam...@apache.org] > Sent: Tuesday, December 30, 2014 7:47 PM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > On Tue Dec 30 2014 at 1:26:31 PM Ted Dunning > wrote: > > > On Tue, Dec 30, 2014 at 7:26 AM, John D. Ament > > > > wrote: > > > > > > Absolutely not just noise. Take the extra 2 seconds to add your > > > > sign > > off. > > > > > > > > > > I disagree. Checking a check box is much different than adding > > meaningful > > > comments, either on mailing lists or on the report itself. > > > > > > For example, which gives you better info that I feel confident in > > Tamaya's > > > board report. > > > > > > My check here: https://wiki.apache.org/incubator/December2014 > > > > > > or my comments in this thread: > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-tamaya- > > dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mO > > h- > > 6Q% > > 40mail.gmail.com%3E > > > > > > All the check does (from my point of view) is give someone a brief > > summary > > > that things are looking good. The check mark doesn't imply any > > > due diligence on the mentor's part. It's very misleading to see > > > it that > way. > > > Take a look for example at the log4cxx2 podling's report. It has > > > mentor sign off, but the contents are barely present. The only > > > reason it has mentor sign off is because the mentor wrote the > > > report, after I (as the > > > shepherd) reminded the podling. > > > > > > > John, > > > > Are you seriously suggesting that the board should be delving into > > all the incubator mailing lists to determine whether you are paying > > attention to your mentoree groups? > > > > No, not in the slightest. But someone needs to look at it. Our > current notion of a board report is completely on the honour system. > It doesn't safeguard fro
Re: Incubator report sign-off
Ross, I think we're actually on the same page. My point with ripple was not so much that it wasn't bringing it to anyone's attention (in fact the opposite, it's plastered all over the report) but more that a simple checkbox doesn't mean everything's great. John On Tue Dec 30 2014 at 10:59:33 PM Ross Gardler (MS OPEN TECH) < ross.gard...@microsoft.com> wrote: > John, > > Actually John I disagree with one of your examples (Ripple). This is > actually a case where things have gone as they would expect. > > The mail you link to is from me. I had previously made the IPMC aware of > the issue prior to that email on the mailing list. I was asked if I was > undertaking to fix it (I replied yes and requested the podling added me as > a mentor in order to do so). The podling report indicated that getting a > release out was a focus "No release made as yet, this will be the first > item to recieve attention." > > The report does not need more detail than that since the IPMC had already > been made aware that there was a problem, that it had been spotted and that > the community and mentors indicated that they were to address it. > > Finally, if you review the shepherds notes from that report they > acknowledge the concern and the fact that there was activity to address it. > > Ripple still has not addressed the issue raised those emails. Therefore it > will not graduate until it does. The email you link to makes this perfectly > clear. > > This is, in my opinion, exactly what should be happening. We provide > oversight to ensure project acts as an Apache project. If it does so we > graduate it, if it doesn't we retire it. > > I do agree with the overall intention of your mail, but it seems I > disagree on what adequate oversight is. > > Ross > > -Original Message----- > From: John D. Ament [mailto:johndam...@apache.org] > Sent: Tuesday, December 30, 2014 7:47 PM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > On Tue Dec 30 2014 at 1:26:31 PM Ted Dunning > wrote: > > > On Tue, Dec 30, 2014 at 7:26 AM, John D. Ament > > > > wrote: > > > > > > Absolutely not just noise. Take the extra 2 seconds to add your > > > > sign > > off. > > > > > > > > > > I disagree. Checking a check box is much different than adding > > meaningful > > > comments, either on mailing lists or on the report itself. > > > > > > For example, which gives you better info that I feel confident in > > Tamaya's > > > board report. > > > > > > My check here: https://wiki.apache.org/incubator/December2014 > > > > > > or my comments in this thread: > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-tamaya- > > dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mOh- > > 6Q% > > 40mail.gmail.com%3E > > > > > > All the check does (from my point of view) is give someone a brief > > summary > > > that things are looking good. The check mark doesn't imply any due > > > diligence on the mentor's part. It's very misleading to see it that > way. > > > Take a look for example at the log4cxx2 podling's report. It has > > > mentor sign off, but the contents are barely present. The only > > > reason it has mentor sign off is because the mentor wrote the > > > report, after I (as the > > > shepherd) reminded the podling. > > > > > > > John, > > > > Are you seriously suggesting that the board should be delving into all > > the incubator mailing lists to determine whether you are paying > > attention to your mentoree groups? > > > > No, not in the slightest. But someone needs to look at it. Our current > notion of a board report is completely on the honour system. It doesn't > safeguard from the chance (which from what I can tell is more often the > case) of a mentor writing and signing a report saying it's good to go. > > You can see some examples of this effect here: > > http://mail-archives.apache.org/mod_mbox/logging-log4cxx- > dev/201412.mbox/%3C1418063938.3890690.200338789.1D0EE7B3% > 40webmail.messagingengine.com%3E > > There are also cases where there are clear issues w/ the podling but > aren't getting communicated properly on the report (or maybe just > oversight?) > > http://mail-archives.apache.org/mod_mbox/incubator-ripple- > dev/201412.mbox/%3CBY2PR03MB490FFD83B71E97C269A12DF99660%40BY2PR03MB490. > namprd03.prod.outlook.com%3E > > My point is that just because there'
RE: Incubator report sign-off
John, Actually John I disagree with one of your examples (Ripple). This is actually a case where things have gone as they would expect. The mail you link to is from me. I had previously made the IPMC aware of the issue prior to that email on the mailing list. I was asked if I was undertaking to fix it (I replied yes and requested the podling added me as a mentor in order to do so). The podling report indicated that getting a release out was a focus "No release made as yet, this will be the first item to recieve attention." The report does not need more detail than that since the IPMC had already been made aware that there was a problem, that it had been spotted and that the community and mentors indicated that they were to address it. Finally, if you review the shepherds notes from that report they acknowledge the concern and the fact that there was activity to address it. Ripple still has not addressed the issue raised those emails. Therefore it will not graduate until it does. The email you link to makes this perfectly clear. This is, in my opinion, exactly what should be happening. We provide oversight to ensure project acts as an Apache project. If it does so we graduate it, if it doesn't we retire it. I do agree with the overall intention of your mail, but it seems I disagree on what adequate oversight is. Ross -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, December 30, 2014 7:47 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off On Tue Dec 30 2014 at 1:26:31 PM Ted Dunning wrote: > On Tue, Dec 30, 2014 at 7:26 AM, John D. Ament > > wrote: > > > > Absolutely not just noise. Take the extra 2 seconds to add your > > > sign > off. > > > > > > > I disagree. Checking a check box is much different than adding > meaningful > > comments, either on mailing lists or on the report itself. > > > > For example, which gives you better info that I feel confident in > Tamaya's > > board report. > > > > My check here: https://wiki.apache.org/incubator/December2014 > > > > or my comments in this thread: > > > > http://mail-archives.apache.org/mod_mbox/incubator-tamaya- > dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mOh- > 6Q% > 40mail.gmail.com%3E > > > > All the check does (from my point of view) is give someone a brief > summary > > that things are looking good. The check mark doesn't imply any due > > diligence on the mentor's part. It's very misleading to see it that way. > > Take a look for example at the log4cxx2 podling's report. It has > > mentor sign off, but the contents are barely present. The only > > reason it has mentor sign off is because the mentor wrote the > > report, after I (as the > > shepherd) reminded the podling. > > > > John, > > Are you seriously suggesting that the board should be delving into all > the incubator mailing lists to determine whether you are paying > attention to your mentoree groups? > No, not in the slightest. But someone needs to look at it. Our current notion of a board report is completely on the honour system. It doesn't safeguard from the chance (which from what I can tell is more often the case) of a mentor writing and signing a report saying it's good to go. You can see some examples of this effect here: http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/201412.mbox/%3C1418063938.3890690.200338789.1D0EE7B3%40webmail.messagingengine.com%3E There are also cases where there are clear issues w/ the podling but aren't getting communicated properly on the report (or maybe just oversight?) http://mail-archives.apache.org/mod_mbox/incubator-ripple-dev/201412.mbox/%3CBY2PR03MB490FFD83B71E97C269A12DF99660%40BY2PR03MB490.namprd03.prod.outlook.com%3E My point is that just because there's a checkbox checked doesn't mean there's issues. Maybe what would help is to have, during shepherd perhaps, some coaxing in to putting more into the issues for the IPMC/board section. Maybe it's more of a "don't hesitate to put something in that area" thing that needs to happen. John > > The check-box is the concise way that you indicate that the activity > on the mailing lists is happening. There is a known defect with > checkboxes in that they can be ticked without mentoring activity > behind them, but that doesn't mean that we should introduce a new > failure mechanism where there is good activity but no tick box. > > Yes, the tick box is supposed to be an echo. It is a redundant > summarization. And it is very helpful because all the tick boxes are > in one place for easier review. >
Re: Incubator report sign-off
On Mon, Dec 29, 2014 at 6:23 PM, Benson Margulies wrote: > I'd like to look at this through a lens of failure analysis. How do > podlings fail? I see two main patterns. > > 1. Failure to build a community. These are the podlings that we find > adrift in space with the lights on but no one home on the mailing > list. > > 2. Failure to build an _Apache_ community. These are the podlings that > JimJag was referring to in another thread; they are here, perhaps, for > the brand, perhaps launched/dumped here by a commercial enterprise. > They have people, they make releases, but there's an empty resonant > cavity where the Apache Way is supposed to be. > > We observe missing mentors in both cases, but I claim that it's only a > serious problem in the second case. In the first case, the problem > isn't lack of supervision. > > Here is where the 'Mentors in the Project' (whether directly reporting > to the board or not) leaps up and looks like a great idea to me. The > whole goal of incubation is to run an Apache project on training > wheels. How does an Apache project run? WIth a chair and PMC members > supervising it and _reporting to the board_. The proposal, as I see > it, is to tell the champion and other mentors that they, and not the > entire IPMC in some nebulous fashion, are the PMC in the PPMC. By the > time the podling graduates, their need to have expanded themselves to > a larger group. > > The board may choose to keep the IPMC around to organize and support > this process. The board may choose to continue to ask the IPMC to add > an extra layer of supervision. But the heart of the proposal is to > insist that every podling be nucleated around at least three people > who have the experience to operate as a PMC and have volunteered for > the responsibility. I really like what you're saying. How can we make it a reality? Petition the board? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Tue Dec 30 2014 at 1:26:31 PM Ted Dunning wrote: > On Tue, Dec 30, 2014 at 7:26 AM, John D. Ament > wrote: > > > > Absolutely not just noise. Take the extra 2 seconds to add your sign > off. > > > > > > > I disagree. Checking a check box is much different than adding > meaningful > > comments, either on mailing lists or on the report itself. > > > > For example, which gives you better info that I feel confident in > Tamaya's > > board report. > > > > My check here: https://wiki.apache.org/incubator/December2014 > > > > or my comments in this thread: > > > > http://mail-archives.apache.org/mod_mbox/incubator-tamaya- > dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mOh-6Q% > 40mail.gmail.com%3E > > > > All the check does (from my point of view) is give someone a brief > summary > > that things are looking good. The check mark doesn't imply any due > > diligence on the mentor's part. It's very misleading to see it that way. > > Take a look for example at the log4cxx2 podling's report. It has mentor > > sign off, but the contents are barely present. The only reason it has > > mentor sign off is because the mentor wrote the report, after I (as the > > shepherd) reminded the podling. > > > > John, > > Are you seriously suggesting that the board should be delving into all the > incubator mailing lists to determine whether you are paying attention to > your mentoree groups? > No, not in the slightest. But someone needs to look at it. Our current notion of a board report is completely on the honour system. It doesn't safeguard from the chance (which from what I can tell is more often the case) of a mentor writing and signing a report saying it's good to go. You can see some examples of this effect here: http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/201412.mbox/%3C1418063938.3890690.200338789.1D0EE7B3%40webmail.messagingengine.com%3E There are also cases where there are clear issues w/ the podling but aren't getting communicated properly on the report (or maybe just oversight?) http://mail-archives.apache.org/mod_mbox/incubator-ripple-dev/201412.mbox/%3CBY2PR03MB490FFD83B71E97C269A12DF99660%40BY2PR03MB490.namprd03.prod.outlook.com%3E My point is that just because there's a checkbox checked doesn't mean there's issues. Maybe what would help is to have, during shepherd perhaps, some coaxing in to putting more into the issues for the IPMC/board section. Maybe it's more of a "don't hesitate to put something in that area" thing that needs to happen. John > > The check-box is the concise way that you indicate that the activity on the > mailing lists is happening. There is a known defect with checkboxes in > that they can be ticked without mentoring activity behind them, but that > doesn't mean that we should introduce a new failure mechanism where there > is good activity but no tick box. > > Yes, the tick box is supposed to be an echo. It is a redundant > summarization. And it is very helpful because all the tick boxes are in > one place for easier review. >
Re: Incubator report sign-off
On Tue, Dec 30, 2014 at 7:26 AM, John D. Ament wrote: > > Absolutely not just noise. Take the extra 2 seconds to add your sign off. > > > > I disagree. Checking a check box is much different than adding meaningful > comments, either on mailing lists or on the report itself. > > For example, which gives you better info that I feel confident in Tamaya's > board report. > > My check here: https://wiki.apache.org/incubator/December2014 > > or my comments in this thread: > > http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mOh-6Q%40mail.gmail.com%3E > > All the check does (from my point of view) is give someone a brief summary > that things are looking good. The check mark doesn't imply any due > diligence on the mentor's part. It's very misleading to see it that way. > Take a look for example at the log4cxx2 podling's report. It has mentor > sign off, but the contents are barely present. The only reason it has > mentor sign off is because the mentor wrote the report, after I (as the > shepherd) reminded the podling. > John, Are you seriously suggesting that the board should be delving into all the incubator mailing lists to determine whether you are paying attention to your mentoree groups? The check-box is the concise way that you indicate that the activity on the mailing lists is happening. There is a known defect with checkboxes in that they can be ticked without mentoring activity behind them, but that doesn't mean that we should introduce a new failure mechanism where there is good activity but no tick box. Yes, the tick box is supposed to be an echo. It is a redundant summarization. And it is very helpful because all the tick boxes are in one place for easier review.
Re: Process over Ego [Was: Re: Incubator report sign-off
On Tue, Dec 30, 2014 at 6:48 PM, Mattmann, Chris A (3980) wrote: > ...what’s also not useful is acting like a proposal that’s existed for > years is something new - it’s been discussed - a simple Google search > yielded hundreds of emails no the topic Besides taking a bit of time to read, hundreds of emails don't allow people reading this thread to converge on a single view of what "the experiment" is, so thanks for pointing out http://wiki.apache.org/incubator/IncubatorDeconstructionProposal , that's what I was missing. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process over Ego [Was: Re: Incubator report sign-off
Hi Bertrand, -Original Message- From: Bertrand Delacretaz Reply-To: "general@incubator.apache.org" Date: Tuesday, December 30, 2014 at 9:30 AM To: Incubator General Subject: Re: Process over Ego [Was: Re: Incubator report sign-off >Hi Chris, > >On Tue, Dec 30, 2014 at 6:07 PM, Mattmann, Chris A (3980) > wrote: >> ...http://wiki.apache.org/incubator/IncubatorDeconstructionProposal ... > >Thanks for this, this looks like a good definition of "the experiment". Thanks. This has been in existence FYI for many years, so please excuse my skepticism this is the first time folks have seen it. > >> ...1. the documentation on *what* to do for incoming projects is >> already there and in good shape > >I disagree, to me http://incubator.apache.org/ needs a lot of work - >it is way too verbose in many places for example, and mixes up best >practices with policy. I don't see how shifting the responsibility to >comdev would help. Great, so like software, it’s a living, breathing thing. Is it perfect, no? Is it “releasable” and has it been “delivered”? Yes? Does it need a 3.0? A 4.0? Sure. It will get it. However it’s good enough for incoming projects, along with mentors and people on those projects who “get” Apache to use, cite, and interpret. > >> ...2. the process on *what* to do for incoming projects is already >> there and in good shape. Nothing prevents folks from continuing >> to work on it, even without an “IPMC”... > >Ok but define "folks". > >Currently it's the active members of the IPMC, and IIUC your plan is >to move this responsibility to the board, which is busy enough IMO. Nope. My plan is to move the responsibility to a variety of committees and people, doing away with the meta committee that is the IPMC. Please review the specific table I’ve listed at the bottom of the proposal. > >>[..snip..] > >> ...Yes there was a time that the Incubator didn’t exist, and *gasp* >> the foundation still ran fine > >We didn't have 30-50 podlings and about 200 TLPs at the time. > >Some easy podlings need very little work, while troublesome ones might >need lots of attention and time. What’s new? The board regularly reviews ~150 TLPs - and what’s funnier - is that the board is also *already* responsible for reviewing those 200 TLPs - the board is responsible for reviewing the IPMC report which includes all of those “sub/meta/etc.” reports from the podlings. Sure, you can argue that the IPMC is responsible for “vetting” that, but I again cite that vetting is what keeps up > >> ...It seems to me there are always a set of folks that think the >> Incubator PMC needs to exist in order for the documentation, >> the process, and the *care* from the people who care about the >> things related to release management; legal help; community help, >> etc., to exist. To me, that’s ridiculous... > >Well, someone needs to do the work of maintaining >http://incubator.apache.org/ for example. > >Moving that responsibility to the board sounds like a huge waste of >those people's time - the board is all about delegation and that's a >good thing. Please read the table at the bottom of the wiki page. > >> ...And finally, I guess for those folks who think that PMCs should >> always be around... > >Who are those folks exactly? >Not me - I think the IPMC should stay around, that's it. Generalizing >this into and "old farts never change their minds" discussion is not >useful. And what’s also not useful is acting like a proposal that’s existed for years is something new - it’s been discussed - a simple Google search yielded hundreds of emails no the topic. > >I'm not against an experiment with 1-2 podlings based on >http://wiki.apache.org/incubator/IncubatorDeconstructionProposal if >people want that but I'm very skeptical of that as a general way of >managing incoming projects. If those 1-2 podlings happen to be "easy" >ones that will work of course, but with troublesome podlings that >sounds to me like a huge waste of the board's energy. It’s not just the board - again please see the table I’ve listed at the bottom of the wiki. What my proposal does is remove the thinly veiled “IPMC” as the “catch all” which in fact doesn’t catch all. On its 150+ person committee - I supposed there are < 20 active people who keep showing up. I have statistics to prove it (see my active mentors tool I’ve shown) - I have experience having mentored many podlings to prove it; and the mailing threads prove it. So, promote those 20 people to ComDev PMC, promote them to ASF members, promote them however, my guess is that they *care* about the foundation; we want these people helping new projects, and they will continue to help those new projects - along with the board - along with everyone else. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process over Ego [Was: Re: Incubator report sign-off
Hi Chris, On Tue, Dec 30, 2014 at 6:07 PM, Mattmann, Chris A (3980) wrote: > ...http://wiki.apache.org/incubator/IncubatorDeconstructionProposal ... Thanks for this, this looks like a good definition of "the experiment". > ...1. the documentation on *what* to do for incoming projects is > already there and in good shape I disagree, to me http://incubator.apache.org/ needs a lot of work - it is way too verbose in many places for example, and mixes up best practices with policy. I don't see how shifting the responsibility to comdev would help. > ...2. the process on *what* to do for incoming projects is already > there and in good shape. Nothing prevents folks from continuing > to work on it, even without an “IPMC”... Ok but define "folks". Currently it's the active members of the IPMC, and IIUC your plan is to move this responsibility to the board, which is busy enough IMO. > ...3. the main issue that keeps arising, related to mentoring, will keep > arising if we keep growing this ethereal presence that’s the > “IPMC”... Removing inactive IPMC members is easy, like that's done for other PMCs. > ...In addition all of those new great folks we are now unlike before > adding to the IPMC can simply be part of e.g., ComDev, as folks > who “get” the foundation, or simply be strong ASF members, etc.,... Makes me think that the goal is to end up with comdev being the "folks" that you mention above. Adjusting the IPMC membership to people who are actually active would have the exact same effect then. > ...Yes there was a time that the Incubator didn’t exist, and *gasp* > the foundation still ran fine We didn't have 30-50 podlings and about 200 TLPs at the time. Some easy podlings need very little work, while troublesome ones might need lots of attention and time. > ...It seems to me there are always a set of folks that think the > Incubator PMC needs to exist in order for the documentation, > the process, and the *care* from the people who care about the > things related to release management; legal help; community help, > etc., to exist. To me, that’s ridiculous... Well, someone needs to do the work of maintaining http://incubator.apache.org/ for example. Moving that responsibility to the board sounds like a huge waste of those people's time - the board is all about delegation and that's a good thing. > ...And finally, I guess for those folks who think that PMCs should > always be around... Who are those folks exactly? Not me - I think the IPMC should stay around, that's it. Generalizing this into and "old farts never change their minds" discussion is not useful. I'm not against an experiment with 1-2 podlings based on http://wiki.apache.org/incubator/IncubatorDeconstructionProposal if people want that but I'm very skeptical of that as a general way of managing incoming projects. If those 1-2 podlings happen to be "easy" ones that will work of course, but with troublesome podlings that sounds to me like a huge waste of the board's energy. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process over Ego [Was: Re: Incubator report sign-off
The problems that you cite were already cited long before (nearly a year) in my proposal to “blow the whole thing up” as you state: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal And we can keep spinning around the target, growing the “IPMC”, and trying to keep whatever “it” is together, but you will find like I have stated ad naseum that: 1. the documentation on *what* to do for incoming projects is already there and in good shape. Nothing prevents folks from continuing to work on it, even without an “IPMC” 2. the process on *what* to do for incoming projects is already there and in good shape. Nothing prevents folks from continuing to work on it, even without an “IPMC” 3. the main issue that keeps arising, related to mentoring, will keep arising if we keep growing this ethereal presence that’s the “IPMC”, instead of simply making projects under the review of the board monthly, quarterly, etc. The board doesn’t go AWOL. The board can’t b/c the checks and balances are in place to keep them around: the membership; the foundation; the reviewing process and the way the foundation has existed since even *before* the Incubator. And it’s within the board’s charter to be in this reviewing phase/entity that is really needed and that continues to appear and disappear within the IPMC. In addition all of those new great folks we are now unlike before adding to the IPMC can simply be part of e.g., ComDev, as folks who “get” the foundation, or simply be strong ASF members, etc., who can hang around on the incoming projects. An incoming project doesn’t have a person with experience reviewing Apache releases on the incoming committee? Let that be discussed and caught, and then adapted on the incoming proposal *to the board*. Yes there was a time that the Incubator didn’t exist, and *gasp* the foundation still ran fine. It seems to me there are always a set of folks that think the Incubator PMC needs to exist in order for the documentation, the process, and the *care* from the people who care about the things related to release management; legal help; community help, etc., to exist. To me, that’s ridiculous. That stuff will still exist. In fact, it can even exist in a concrete entity - have it be the ComDev PMC as I originally suggested in my proposal to, *gasp*, “blow the whole thing up”. And finally, I guess for those folks who think that PMCs should always be around, we should probably still have Jakarta, and other PMCs - heck let’s never have PMCs go away - I mean, we still have Java projects, right? Cheers, Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Bertrand Delacretaz Reply-To: "general@incubator.apache.org" Date: Tuesday, December 30, 2014 at 1:09 AM To: Incubator General Subject: Re: Process over Ego [Was: Re: Incubator report sign-off >On Tue, Dec 30, 2014 at 12:54 AM, Stian Soiland-Reyes >wrote: >> ...It would be sad if this Incubator Community disappears in the >>proposed >> move of incubating project to be reporting directly to the ASF Board... > >With my board member hat on, you can count on a strong -1 from me on >that suggestion. I suspect I'm not the only board member with that >opinion, so if people actually think of making this happen it might be >worth polling the board first to avoid wasting time discussing that >option. > >Once again, IMO focusing on actual concrete problems like we started >listing at https://wiki.apache.org/incubator/IncubatorIssues2013 would >be much more productive than blowing the whole thing up in the hope >that it will somewhat re-materialize in a better form. > >-Bertrand > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org >
Re: Incubator report sign-off
On Dec 30, 2014 10:27 AM, "John D. Ament" wrote: > > On Mon Dec 29 2014 at 9:50:49 AM Rich Bowen wrote: > > > > > > > On 12/21/2014 11:14 AM, John D. Ament wrote: > > > I don't particularly like that idea. For one, I know that if I were to > > see > > > 50%+ of mentors on a project I'm a mentor on sign off on the report, I'm > > > probably going to look at things, but not add my signature. Not out of > > > laziness, but in seeing that others are dealing with it as well and my > > > signature is just more "noise" on the report. > > > > And as someone reviewing that report, it is *absolutely* not just noise. > > It tells me that the mentors are engaged, and that are in tune with what > > the podling is doing, and that the podling is listening to their mentors > > are are learning the ropes. > > > > Podlings that have 100% mentor signoff indicate that everything is going > > perfectly, and there's no reason for concern. > > > > Absolutely not just noise. Take the extra 2 seconds to add your sign off. > > > > I disagree. Checking a check box is much different than adding meaningful > comments, either on mailing lists or on the report itself. > > For example, which gives you better info that I feel confident in Tamaya's > board report. > > My check here: https://wiki.apache.org/incubator/December2014 > > or my comments in this thread: > http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mOh-6Q%40mail.gmail.com%3E > > All the check does (from my point of view) is give someone a brief summary > that things are looking good. The check mark doesn't imply any due > diligence on the mentor's part. It's very misleading to see it that way. > Take a look for example at the log4cxx2 podling's report. It has mentor > sign off, but the contents are barely present. The only reason it has > mentor sign off is because the mentor wrote the report, after I (as the > shepherd) reminded the podling. > > I was referring to tlp pmc chairs reporting to the board.
Re: Incubator report sign-off
On Mon Dec 29 2014 at 9:50:49 AM Rich Bowen wrote: > > > On 12/21/2014 11:14 AM, John D. Ament wrote: > > I don't particularly like that idea. For one, I know that if I were to > see > > 50%+ of mentors on a project I'm a mentor on sign off on the report, I'm > > probably going to look at things, but not add my signature. Not out of > > laziness, but in seeing that others are dealing with it as well and my > > signature is just more "noise" on the report. > > And as someone reviewing that report, it is *absolutely* not just noise. > It tells me that the mentors are engaged, and that are in tune with what > the podling is doing, and that the podling is listening to their mentors > are are learning the ropes. > > Podlings that have 100% mentor signoff indicate that everything is going > perfectly, and there's no reason for concern. > > Absolutely not just noise. Take the extra 2 seconds to add your sign off. > I disagree. Checking a check box is much different than adding meaningful comments, either on mailing lists or on the report itself. For example, which gives you better info that I feel confident in Tamaya's board report. My check here: https://wiki.apache.org/incubator/December2014 or my comments in this thread: http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mOh-6Q%40mail.gmail.com%3E All the check does (from my point of view) is give someone a brief summary that things are looking good. The check mark doesn't imply any due diligence on the mentor's part. It's very misleading to see it that way. Take a look for example at the log4cxx2 podling's report. It has mentor sign off, but the contents are barely present. The only reason it has mentor sign off is because the mentor wrote the report, after I (as the shepherd) reminded the podling. > > --Rich > > > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Incubator report sign-off
On 12/30/2014 09:00 AM, Louis Suárez-Potts wrote: On 30 Dec 2014, at 03:56, Bertrand Delacretaz wrote: > >On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell > wrote: >>...Certainly some projects have a de facto lead that coincide with Chair and I'm pretty sure >>in some cases that is an honorary arrangement agreed to by the community > >*loud red alarms going off all over my brain* > >If that's the case, such projects should make sure they implement a >regular PMC chair rotation. Or be prepared to go down in flames once >that leader changes their mind and no one has a clue how their project >runs. Indeed. But outside of self-policing, is there a mechanism to ensure that something like this, disfavouring egoistic power, is in place? Note, I’m not sure it’s actually needed, just curious. There certainly is such a mechanism. It's called "quarterly reports to the board." Which is why it's so important that reviewing board reports is more than just a checkbox, as has been accused in the past. Fortunately, I've seen pretty strong evidence in the last few years that it's *way* more than just a checkbox, with board members routinely citing older reports, going back months and years, to support their comments about projects that are drifting from the course. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Tue, Dec 30, 2014 at 3:00 PM, Louis Suárez-Potts wrote: > ...outside of self-policing, is there a mechanism to ensure that something > like this, disfavouring egoistic > power, is in place? Note, I’m not sure it’s actually needed, just curious I don't think there's a formal mechanism, but our consensus best practices and voting rules are meant to give everyone a voice, so if project members are wary of someone grabbing too much power they have means to bring things back to sanity, IMO. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
+1 -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Tuesday, December 30, 2014 00:56 To: Incubator General Subject: Re: Incubator report sign-off On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell wrote: > ...Certainly some projects have a de facto lead that coincide with Chair and > I'm pretty sure > in some cases that is an honorary arrangement agreed to by the community *loud red alarms going off all over my brain* If that's the case, such projects should make sure they implement a regular PMC chair rotation. Or be prepared to go down in flames once that leader changes their mind and no one has a clue how their project runs. -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: Incubator report sign-off
> On 30 Dec 2014, at 03:56, Bertrand Delacretaz wrote: > > On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell > wrote: >> ...Certainly some projects have a de facto lead that coincide with Chair and >> I'm pretty sure >> in some cases that is an honorary arrangement agreed to by the community > > *loud red alarms going off all over my brain* > > If that's the case, such projects should make sure they implement a > regular PMC chair rotation. Or be prepared to go down in flames once > that leader changes their mind and no one has a clue how their project > runs. Indeed. But outside of self-policing, is there a mechanism to ensure that something like this, disfavouring egoistic power, is in place? Note, I’m not sure it’s actually needed, just curious. > > -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: Incubator report sign-off
On Tue, Dec 30, 2014 at 11:12 AM, Greg Stein wrote: > ...I cannot see the Board ever mandating chair rotations. That is up to the > community > ...For projects that don't understand the difference between "supportive" and > "lead": yeah, they could use a dose of trout-slapping and a chair rotation > or three... +1 to both statements. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Tue, Dec 30, 2014 at 4:04 AM, jan i wrote: > On Tuesday, December 30, 2014, Bertrand Delacretaz > > wrote: > > > On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell > > > wrote: > > > ...Certainly some projects have a de facto lead that coincide with > Chair > > and I'm pretty sure > > > in some cases that is an honorary arrangement agreed to by the > > community > > > > *loud red alarms going off all over my brain* > > > > If that's the case, such projects should make sure they implement a > > regular PMC chair rotation. Or be prepared to go down in flames once > > that leader changes their mind and no one has a clue how their project > > runs. > > big +1actually the chair rotation is something we should consider > having as a rule (and allow deviations for good reasins). > I cannot see the Board ever mandating chair rotations. That is up to the community. As long as the chair/VP remains administrative, then there isn't a problem. We have *many* chairs across the Foundation (myself included) that have been in their position for many years. It works well because we *support* the project, rather than any attempt to direct, steer, or lead based upon that position. The VP is the link between a project's needs and the Foundation's support for that project, along with bidirectional communication. For projects that don't understand the difference between "supportive" and "lead": yeah, they could use a dose of trout-slapping and a chair rotation or three. Cheers, -g
Re: Incubator report sign-off
On Tuesday, December 30, 2014, Bertrand Delacretaz wrote: > On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell > > wrote: > > ...Certainly some projects have a de facto lead that coincide with Chair > and I'm pretty sure > > in some cases that is an honorary arrangement agreed to by the > community > > *loud red alarms going off all over my brain* > > If that's the case, such projects should make sure they implement a > regular PMC chair rotation. Or be prepared to go down in flames once > that leader changes their mind and no one has a clue how their project > runs. big +1actually the chair rotation is something we should consider having as a rule (and allow deviations for good reasins). rgds jan i > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > -- Sent from My iPad, sorry for any misspellings.
Re: Process over Ego [Was: Re: Incubator report sign-off
On Tue, Dec 30, 2014 at 12:54 AM, Stian Soiland-Reyes wrote: > ...It would be sad if this Incubator Community disappears in the proposed > move of incubating project to be reporting directly to the ASF Board... With my board member hat on, you can count on a strong -1 from me on that suggestion. I suspect I'm not the only board member with that opinion, so if people actually think of making this happen it might be worth polling the board first to avoid wasting time discussing that option. Once again, IMO focusing on actual concrete problems like we started listing at https://wiki.apache.org/incubator/IncubatorIssues2013 would be much more productive than blowing the whole thing up in the hope that it will somewhat re-materialize in a better form. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell wrote: > ...Certainly some projects have a de facto lead that coincide with Chair and > I'm pretty sure > in some cases that is an honorary arrangement agreed to by the community *loud red alarms going off all over my brain* If that's the case, such projects should make sure they implement a regular PMC chair rotation. Or be prepared to go down in flames once that leader changes their mind and no one has a clue how their project runs. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process over Ego [Was: Re: Incubator report sign-off
On Mon, Dec 29, 2014 at 7:08 PM, Louis Suárez-Potts wrote: > >> On 29 Dec 2014, at 18:54, Stian Soiland-Reyes wrote: >> >> But a move of reporting-to authority does not have to change any of >> that, does it? > > Depends on how much of an anarchist one is :-) and what is meant by > authority, too, I suppose. > > But, to answer the question, I would say, no: it does not. Authority that is > vested with the > power to execute decisions is needed, at least if one is to engage in any > kind commerce. Well, the modern US corporate structure is really not any more of an intelligent design than your appendix is. It is actually interesting to compare hot organizational structure evolved in countries other than those with roots in prussian military model and Catholic church. I guess what I'm trying to say is this: it all depends on one's constraints and whether the system equilibrium is expected on average or worst case scenarios. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process over Ego [Was: Re: Incubator report sign-off
> On 29 Dec 2014, at 18:54, Stian Soiland-Reyes wrote: > > But a move of reporting-to authority does not have to change any of > that, does it? Depends on how much of an anarchist one is :-) and what is meant by authority, too, I suppose. But, to answer the question, I would say, no: it does not. Authority that is vested with the power to execute decisions is needed, at least if one is to engage in any kind commerce. Indeed, I’ve long counselled open source groups to form effectively corporate structures with authority characteristics resembling those familiar to the purchasers of proprietary software. A company (public or private sector) that’s always bought from a big single vendor has been shaped by this historical practice and cannot easily change, no matter how free & even good the alternative is. Too much is at stake and there is too much momentum—too many involved. louis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
+1 well said. Sent from my Windows Phone From: Benson Margulies<mailto:bimargul...@gmail.com> Sent: 12/29/2014 6:25 PM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: Incubator report sign-off I'd like to look at this through a lens of failure analysis. How do podlings fail? I see two main patterns. 1. Failure to build a community. These are the podlings that we find adrift in space with the lights on but no one home on the mailing list. 2. Failure to build an _Apache_ community. These are the podlings that JimJag was referring to in another thread; they are here, perhaps, for the brand, perhaps launched/dumped here by a commercial enterprise. They have people, they make releases, but there's an empty resonant cavity where the Apache Way is supposed to be. We observe missing mentors in both cases, but I claim that it's only a serious problem in the second case. In the first case, the problem isn't lack of supervision. Here is where the 'Mentors in the Project' (whether directly reporting to the board or not) leaps up and looks like a great idea to me. The whole goal of incubation is to run an Apache project on training wheels. How does an Apache project run? WIth a chair and PMC members supervising it and _reporting to the board_. The proposal, as I see it, is to tell the champion and other mentors that they, and not the entire IPMC in some nebulous fashion, are the PMC in the PPMC. By the time the podling graduates, their need to have expanded themselves to a larger group. The board may choose to keep the IPMC around to organize and support this process. The board may choose to continue to ask the IPMC to add an extra layer of supervision. But the heart of the proposal is to insist that every podling be nucleated around at least three people who have the experience to operate as a PMC and have volunteered for the responsibility. On Mon, Dec 29, 2014 at 7:01 PM, Roman Shaposhnik wrote: > On Mon, Dec 29, 2014 at 6:40 AM, Rich Bowen wrote: >> Roman, please forgive me absence from this conversation. I started the >> thread, and then went on Christmas vacation. I am still on vacation for >> another week, but will attempt to keep up with the conversation here, and >> not abandon the thread I started. Please also forgive the dozen responses >> that I'm dropping all at once. > > This totally makes two of us. Every time Christmas season begins this is > very much the predicament I find myself in. > > Thanks, > Roman. > > P.S. Not even sure whether it would be better to simply go away 100% so > at least folks get a nice auto-responder email while I can't be present > anyway. > > - > 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: Incubator report sign-off
I'd like to look at this through a lens of failure analysis. How do podlings fail? I see two main patterns. 1. Failure to build a community. These are the podlings that we find adrift in space with the lights on but no one home on the mailing list. 2. Failure to build an _Apache_ community. These are the podlings that JimJag was referring to in another thread; they are here, perhaps, for the brand, perhaps launched/dumped here by a commercial enterprise. They have people, they make releases, but there's an empty resonant cavity where the Apache Way is supposed to be. We observe missing mentors in both cases, but I claim that it's only a serious problem in the second case. In the first case, the problem isn't lack of supervision. Here is where the 'Mentors in the Project' (whether directly reporting to the board or not) leaps up and looks like a great idea to me. The whole goal of incubation is to run an Apache project on training wheels. How does an Apache project run? WIth a chair and PMC members supervising it and _reporting to the board_. The proposal, as I see it, is to tell the champion and other mentors that they, and not the entire IPMC in some nebulous fashion, are the PMC in the PPMC. By the time the podling graduates, their need to have expanded themselves to a larger group. The board may choose to keep the IPMC around to organize and support this process. The board may choose to continue to ask the IPMC to add an extra layer of supervision. But the heart of the proposal is to insist that every podling be nucleated around at least three people who have the experience to operate as a PMC and have volunteered for the responsibility. On Mon, Dec 29, 2014 at 7:01 PM, Roman Shaposhnik wrote: > On Mon, Dec 29, 2014 at 6:40 AM, Rich Bowen wrote: >> Roman, please forgive me absence from this conversation. I started the >> thread, and then went on Christmas vacation. I am still on vacation for >> another week, but will attempt to keep up with the conversation here, and >> not abandon the thread I started. Please also forgive the dozen responses >> that I'm dropping all at once. > > This totally makes two of us. Every time Christmas season begins this is > very much the predicament I find myself in. > > Thanks, > Roman. > > P.S. Not even sure whether it would be better to simply go away 100% so > at least folks get a nice auto-responder email while I can't be present > anyway. > > - > 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: Incubator report sign-off
On Mon, Dec 29, 2014 at 6:40 AM, Rich Bowen wrote: > Roman, please forgive me absence from this conversation. I started the > thread, and then went on Christmas vacation. I am still on vacation for > another week, but will attempt to keep up with the conversation here, and > not abandon the thread I started. Please also forgive the dozen responses > that I'm dropping all at once. This totally makes two of us. Every time Christmas season begins this is very much the predicament I find myself in. Thanks, Roman. P.S. Not even sure whether it would be better to simply go away 100% so at least folks get a nice auto-responder email while I can't be present anyway. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process over Ego [Was: Re: Incubator report sign-off
Yes, the Apache bureaucracy takes time to learn to love :) - I guess that is part of incubating.. What is great is that there is an open discussion about those processes - here in a forum that includes all the incubators - so that we see why processes are the way they are, and that they are indeed open for change by a common decision rather than decided on a whim by the king. It would be sad if this Incubator Community disappears in the proposed move of incubating project to be reporting directly to the ASF Board. I feel, at least for my part, that our incubating project is learning a lot about the Apache Way just by lurking here and seeing what other projects are facing of challenges when they are doing their releases, managing NOTICE files, voting in members, etc. But a move of reporting-to authority does not have to change any of that, does it? On 29 December 2014 at 14:45, Louis Suárez-Potts wrote: > Ross, et al., > Note the change in subject. > > I think that one crucial fact about Apache that I love and respect is its > regard for process over ego. It can be dull and unless one rather likes, or > at least understands the value of, bureaucratic processes, can be > frustrating, especially to those in love with swift and ego-driven acts. But > process does not depend on individuals and is not a form suited to benevolent > dictators. It’s also not a panacea for community. But it can lead to a > lasting and productive one. > > louis > >> On 29 Dec 2014, at 14:46, Ross Gardler (MS OPEN TECH) >> wrote: >> >> In Apache there is no such thing as a "Project Leader" >> >> The PMC Chair has no more authority over the project than anyone else. >> >> The PMC Chair absolutely does *not* have the power to dissolve the PMC. Only >> the Board of Directors have that authority and they will only do that at the >> request of the PMC as a whole (or when there is no active PMC to make such a >> request). >> >> Ross >> >> -Original Message- >> From: Andrew Purtell [mailto:andrew.purt...@gmail.com] >> Sent: Monday, December 29, 2014 10:45 AM >> To: general@incubator.apache.org >> Subject: Re: Incubator report sign-off >> >> There are honorary and practical reasons why a project may view the PMC >> Chair and the project leader as one in the same. >> >> Honorary: The community elevated one member as lead and assigned the Chair >> role out of respect. >> >> Practical: The PMC Chair has the power to dissolve the PMC, and is an >> officer of the Foundation. Nobody else on the project has such power nor >> indemnification. "Secretary" as a term does not adequately encompass that. >> >> >> >>> On Dec 29, 2014, at 6:46 AM, Rich Bowen wrote: >>> >>> >>> >>> On 12/23/2014 03:34 PM, sebb wrote: >>>>> Flex had three great mentors, but to expect them to be the PMC Chair >>>>> on >>>>>> graduation would have been problematic. They were great mentors >>>>>> because they had lots of experience from their work on other Apache >>>>>> projects, and thus didn’t have time to stay active on a new TLP, >>>>>> plus they really weren’t users or developers of the technology, >>>>>> just our coaches on the Apache Way, and thus wouldn’t be good Chair >>>>>> candidates as they weren’t as invested in the technology. But they >>>>>> did stick around on at least the private@ lists and continue to do >>>>>> so even 2 years after graduation where we consult them on occasion. >>>>>> To require that a mentor be an active contributor limits the kinds >>>>>> of technologies that can come to Apache to only those who can interest >>>>>> someone with a lot of spare cycles. >>>>>> >>>>>> IMO, the mentors job is to teach, not to lead. >>>> The job of the PMC chair is almost entirely administrative. >>>> They are the link between the board and the PMC and their main role >>>> is to ensure the board gets timely reports and to feed back comments >>>> from the board. >>>> >>>> If a PMC is relying on the chair to drive it forward technically, >>>> then I think something has gone wrong with the PMC. >>>> >>> >>> Indeed. Big +1 on this. >>> >>> There are some projects that I've been watching lately where the PMC chair >>> is viewed as the project lead, and that has a number
Re: Incubator report sign-off
On Mon, Dec 29, 2014 at 6:15 AM, Rich Bowen wrote: > This is what happens when I write email like this and then go for two weeks > off of work. Catching up ... Oh, man! I was about to take a strong and decisive action today ;-) Seriously -- welcome back into this conversation. > You make a good point. I have been critical, of late, of projects that have > N mentors, and only 1 or 2 mentors sign off on a report. However, I think > you may have changed my perspective here, and I appreciate your insight. I am really happy we're in agreement on this one. An additional consideration of using sign-off as a heartbeat function for mentors has been proposed. Personally, I'm +0 on it, but was about to start incorporating it into the report mechanics. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Process over Ego [Was: Re: Incubator report sign-off
Ross, et al., Note the change in subject. I think that one crucial fact about Apache that I love and respect is its regard for process over ego. It can be dull and unless one rather likes, or at least understands the value of, bureaucratic processes, can be frustrating, especially to those in love with swift and ego-driven acts. But process does not depend on individuals and is not a form suited to benevolent dictators. It’s also not a panacea for community. But it can lead to a lasting and productive one. louis > On 29 Dec 2014, at 14:46, Ross Gardler (MS OPEN TECH) > wrote: > > In Apache there is no such thing as a "Project Leader" > > The PMC Chair has no more authority over the project than anyone else. > > The PMC Chair absolutely does *not* have the power to dissolve the PMC. Only > the Board of Directors have that authority and they will only do that at the > request of the PMC as a whole (or when there is no active PMC to make such a > request). > > Ross > > -Original Message- > From: Andrew Purtell [mailto:andrew.purt...@gmail.com] > Sent: Monday, December 29, 2014 10:45 AM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > There are honorary and practical reasons why a project may view the PMC Chair > and the project leader as one in the same. > > Honorary: The community elevated one member as lead and assigned the Chair > role out of respect. > > Practical: The PMC Chair has the power to dissolve the PMC, and is an officer > of the Foundation. Nobody else on the project has such power nor > indemnification. "Secretary" as a term does not adequately encompass that. > > > >> On Dec 29, 2014, at 6:46 AM, Rich Bowen wrote: >> >> >> >> On 12/23/2014 03:34 PM, sebb wrote: >>>> Flex had three great mentors, but to expect them to be the PMC Chair >>>> on >>>>> graduation would have been problematic. They were great mentors >>>>> because they had lots of experience from their work on other Apache >>>>> projects, and thus didn’t have time to stay active on a new TLP, >>>>> plus they really weren’t users or developers of the technology, >>>>> just our coaches on the Apache Way, and thus wouldn’t be good Chair >>>>> candidates as they weren’t as invested in the technology. But they >>>>> did stick around on at least the private@ lists and continue to do >>>>> so even 2 years after graduation where we consult them on occasion. >>>>> To require that a mentor be an active contributor limits the kinds >>>>> of technologies that can come to Apache to only those who can interest >>>>> someone with a lot of spare cycles. >>>>> >>>>> IMO, the mentors job is to teach, not to lead. >>> The job of the PMC chair is almost entirely administrative. >>> They are the link between the board and the PMC and their main role >>> is to ensure the board gets timely reports and to feed back comments >>> from the board. >>> >>> If a PMC is relying on the chair to drive it forward technically, >>> then I think something has gone wrong with the PMC. >>> >> >> Indeed. Big +1 on this. >> >> There are some projects that I've been watching lately where the PMC chair >> is viewed as the project lead, and that has a number of problems that go >> along with it. The PMC chair is a secretary, whose job is to file the right >> paperwork. A *hugely* important role, but not a technical lead role. >> >> -- >> Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - >> @apachecon >> >> - >> 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: Incubator report sign-off
Agreed, it's not worth debating project lead as a formal or informal construct. I don't think we are on the same page. Certainly some projects have a de facto lead that coincide with Chair and I'm pretty sure in some cases that is an honorary arrangement agreed to by the community. > On Dec 29, 2014, at 11:51 AM, Rich Bowen wrote: > > > >> On 12/29/2014 01:45 PM, Andrew Purtell wrote: >> There are honorary and practical reasons why a project may view the PMC >> Chair and the project leader as one in the same. >> >> Honorary: The community elevated one member as lead and assigned the Chair >> role out of respect. >> >> Practical: The PMC Chair has the power to dissolve the PMC, and is an >> officer of the Foundation. Nobody else on the project has such power nor >> indemnification. "Secretary" as a term does not adequately encompass that. > > That's all well and good, however: > > 1) I'm not aware of even a single time that the PMC chair has actually > unilaterally dissolved the PMC, and I think the board would have serious > objections if that were to actually happen, as it would indicate pretty > serious community failure. > > 2) ASF projects don't have project leads. Sure, a project may, at one time or > another, have a person that is clearly at the forefront of decision making, > but to designate them a project lead indicates dysfunction in a > collaboration-based structure. > > This seems a tad of a diversion from the topic, but definitely worth > mentioning. > > >> >> >>> On Dec 29, 2014, at 6:46 AM, Rich Bowen wrote: >>> >>> >>> On 12/23/2014 03:34 PM, sebb wrote: >> Flex had three great mentors, but to expect them to be the PMC Chair on >> graduation would have been problematic. They were great mentors because >> they had lots of experience from their work on other Apache projects, and >> thus didn’t have time to stay active on a new TLP, plus they really >> weren’t users or developers of the technology, just our coaches on the >> Apache Way, and thus wouldn’t be good Chair candidates as they weren’t as >> invested in the technology. But they did stick around on at least the >> private@ lists and continue to do so even 2 years after graduation where >> we consult them on occasion. To require that a mentor be an active >> contributor limits the kinds of technologies that can come to Apache to >> only those who can interest someone with a lot of spare cycles. >> >> IMO, the mentors job is to teach, not to lead. The job of the PMC chair is almost entirely administrative. They are the link between the board and the PMC and their main role is to ensure the board gets timely reports and to feed back comments from the board. If a PMC is relying on the chair to drive it forward technically, then I think something has gone wrong with the PMC. >>> >>> Indeed. Big +1 on this. >>> >>> There are some projects that I've been watching lately where the PMC chair >>> is viewed as the project lead, and that has a number of problems that go >>> along with it. The PMC chair is a secretary, whose job is to file the right >>> paperwork. A *hugely* important role, but not a technical lead role. >>> >>> -- >>> Rich Bowen - rbo...@rcbowen.com - @rbowen >>> http://apachecon.com/ - @apachecon >>> >>> - >>> 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 > > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > - > 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: Incubator report sign-off
On 12/29/2014 02:46 PM, Ross Gardler (MS OPEN TECH) wrote: The PMC Chair absolutely does*not* have the power to dissolve the PMC. Only the Board of Directors have that authority and they will only do that at the request of the PMC as a whole (or when there is no active PMC to make such a request). ... or in the case of extremely serious project management dysfunction, which has happened only one time in the history of the Foundation. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
> On 29 Dec 2014, at 14:46, Ross Gardler (MS OPEN TECH) > wrote: > > In Apache there is no such thing as a "Project Leader" > > The PMC Chair has no more authority over the project than anyone else. > > The PMC Chair absolutely does *not* have the power to dissolve the PMC. Only > the Board of Directors have that authority and they will only do that at the > request of the PMC as a whole (or when there is no active PMC to make such a > request). > > Ross > Thanks, Ross, for the reminder! louis > -Original Message- > From: Andrew Purtell [mailto:andrew.purt...@gmail.com] > Sent: Monday, December 29, 2014 10:45 AM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > There are honorary and practical reasons why a project may view the PMC Chair > and the project leader as one in the same. > > Honorary: The community elevated one member as lead and assigned the Chair > role out of respect. > > Practical: The PMC Chair has the power to dissolve the PMC, and is an officer > of the Foundation. Nobody else on the project has such power nor > indemnification. "Secretary" as a term does not adequately encompass that. > > > >> On Dec 29, 2014, at 6:46 AM, Rich Bowen wrote: >> >> >> >> On 12/23/2014 03:34 PM, sebb wrote: >>>> Flex had three great mentors, but to expect them to be the PMC Chair >>>> on >>>>> graduation would have been problematic. They were great mentors >>>>> because they had lots of experience from their work on other Apache >>>>> projects, and thus didn’t have time to stay active on a new TLP, >>>>> plus they really weren’t users or developers of the technology, >>>>> just our coaches on the Apache Way, and thus wouldn’t be good Chair >>>>> candidates as they weren’t as invested in the technology. But they >>>>> did stick around on at least the private@ lists and continue to do >>>>> so even 2 years after graduation where we consult them on occasion. >>>>> To require that a mentor be an active contributor limits the kinds >>>>> of technologies that can come to Apache to only those who can interest >>>>> someone with a lot of spare cycles. >>>>> >>>>> IMO, the mentors job is to teach, not to lead. >>> The job of the PMC chair is almost entirely administrative. >>> They are the link between the board and the PMC and their main role >>> is to ensure the board gets timely reports and to feed back comments >>> from the board. >>> >>> If a PMC is relying on the chair to drive it forward technically, >>> then I think something has gone wrong with the PMC. >>> >> >> Indeed. Big +1 on this. >> >> There are some projects that I've been watching lately where the PMC chair >> is viewed as the project lead, and that has a number of problems that go >> along with it. The PMC chair is a secretary, whose job is to file the right >> paperwork. A *hugely* important role, but not a technical lead role. >> >> -- >> Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - >> @apachecon >> >> - >> 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: Incubator report sign-off
On 12/29/2014 01:45 PM, Andrew Purtell wrote: There are honorary and practical reasons why a project may view the PMC Chair and the project leader as one in the same. Honorary: The community elevated one member as lead and assigned the Chair role out of respect. Practical: The PMC Chair has the power to dissolve the PMC, and is an officer of the Foundation. Nobody else on the project has such power nor indemnification. "Secretary" as a term does not adequately encompass that. That's all well and good, however: 1) I'm not aware of even a single time that the PMC chair has actually unilaterally dissolved the PMC, and I think the board would have serious objections if that were to actually happen, as it would indicate pretty serious community failure. 2) ASF projects don't have project leads. Sure, a project may, at one time or another, have a person that is clearly at the forefront of decision making, but to designate them a project lead indicates dysfunction in a collaboration-based structure. This seems a tad of a diversion from the topic, but definitely worth mentioning. On Dec 29, 2014, at 6:46 AM, Rich Bowen wrote: On 12/23/2014 03:34 PM, sebb wrote: Flex had three great mentors, but to expect them to be the PMC Chair on graduation would have been problematic. They were great mentors because they had lots of experience from their work on other Apache projects, and thus didn’t have time to stay active on a new TLP, plus they really weren’t users or developers of the technology, just our coaches on the Apache Way, and thus wouldn’t be good Chair candidates as they weren’t as invested in the technology. But they did stick around on at least the private@ lists and continue to do so even 2 years after graduation where we consult them on occasion. To require that a mentor be an active contributor limits the kinds of technologies that can come to Apache to only those who can interest someone with a lot of spare cycles. IMO, the mentors job is to teach, not to lead. The job of the PMC chair is almost entirely administrative. They are the link between the board and the PMC and their main role is to ensure the board gets timely reports and to feed back comments from the board. If a PMC is relying on the chair to drive it forward technically, then I think something has gone wrong with the PMC. Indeed. Big +1 on this. There are some projects that I've been watching lately where the PMC chair is viewed as the project lead, and that has a number of problems that go along with it. The PMC chair is a secretary, whose job is to file the right paperwork. A *hugely* important role, but not a technical lead role. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - 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 -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
In Apache there is no such thing as a "Project Leader" The PMC Chair has no more authority over the project than anyone else. The PMC Chair absolutely does *not* have the power to dissolve the PMC. Only the Board of Directors have that authority and they will only do that at the request of the PMC as a whole (or when there is no active PMC to make such a request). Ross -Original Message- From: Andrew Purtell [mailto:andrew.purt...@gmail.com] Sent: Monday, December 29, 2014 10:45 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off There are honorary and practical reasons why a project may view the PMC Chair and the project leader as one in the same. Honorary: The community elevated one member as lead and assigned the Chair role out of respect. Practical: The PMC Chair has the power to dissolve the PMC, and is an officer of the Foundation. Nobody else on the project has such power nor indemnification. "Secretary" as a term does not adequately encompass that. > On Dec 29, 2014, at 6:46 AM, Rich Bowen wrote: > > > > On 12/23/2014 03:34 PM, sebb wrote: >>> Flex had three great mentors, but to expect them to be the PMC Chair >>> on >>> >graduation would have been problematic. They were great mentors >>> >because they had lots of experience from their work on other Apache >>> >projects, and thus didn’t have time to stay active on a new TLP, >>> >plus they really weren’t users or developers of the technology, >>> >just our coaches on the Apache Way, and thus wouldn’t be good Chair >>> >candidates as they weren’t as invested in the technology. But they >>> >did stick around on at least the private@ lists and continue to do >>> >so even 2 years after graduation where we consult them on occasion. >>> >To require that a mentor be an active contributor limits the kinds >>> >of technologies that can come to Apache to only those who can interest >>> >someone with a lot of spare cycles. >>> > >>> >IMO, the mentors job is to teach, not to lead. >> The job of the PMC chair is almost entirely administrative. >> They are the link between the board and the PMC and their main role >> is to ensure the board gets timely reports and to feed back comments >> from the board. >> >> If a PMC is relying on the chair to drive it forward technically, >> then I think something has gone wrong with the PMC. >> > > Indeed. Big +1 on this. > > There are some projects that I've been watching lately where the PMC chair is > viewed as the project lead, and that has a number of problems that go along > with it. The PMC chair is a secretary, whose job is to file the right > paperwork. A *hugely* important role, but not a technical lead role. > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - > @apachecon > > - > 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: Incubator report sign-off
There are honorary and practical reasons why a project may view the PMC Chair and the project leader as one in the same. Honorary: The community elevated one member as lead and assigned the Chair role out of respect. Practical: The PMC Chair has the power to dissolve the PMC, and is an officer of the Foundation. Nobody else on the project has such power nor indemnification. "Secretary" as a term does not adequately encompass that. > On Dec 29, 2014, at 6:46 AM, Rich Bowen wrote: > > > > On 12/23/2014 03:34 PM, sebb wrote: >>> Flex had three great mentors, but to expect them to be the PMC Chair on >>> >graduation would have been problematic. They were great mentors because >>> >they had lots of experience from their work on other Apache projects, and >>> >thus didn’t have time to stay active on a new TLP, plus they really >>> >weren’t users or developers of the technology, just our coaches on the >>> >Apache Way, and thus wouldn’t be good Chair candidates as they weren’t as >>> >invested in the technology. But they did stick around on at least the >>> >private@ lists and continue to do so even 2 years after graduation where >>> >we consult them on occasion. To require that a mentor be an active >>> >contributor limits the kinds of technologies that can come to Apache to >>> >only those who can interest someone with a lot of spare cycles. >>> > >>> >IMO, the mentors job is to teach, not to lead. >> The job of the PMC chair is almost entirely administrative. >> They are the link between the board and the PMC and their main role is >> to ensure the board gets timely reports and to feed back comments from >> the board. >> >> If a PMC is relying on the chair to drive it forward technically, then >> I think something has gone wrong with the PMC. >> > > Indeed. Big +1 on this. > > There are some projects that I've been watching lately where the PMC chair is > viewed as the project lead, and that has a number of problems that go along > with it. The PMC chair is a secretary, whose job is to file the right > paperwork. A *hugely* important role, but not a technical lead role. > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > - > 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: Incubator report sign-off
Part of the apache way is to recognize all contributions. That's why I wrote "active participant of the project ... and generally engaging with the community" The key part is requiring active participation as a community member. That is "vested interest in the project itself" rather than simply saying "sure I'd like to see more projects at the ASF" Sent from my Windows Phone From: Rich Bowen<mailto:rbo...@rcbowen.com> Sent: 12/29/2014 6:13 AM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: Incubator report sign-off On 12/19/2014 02:00 PM, Ross Gardler (MS OPEN TECH) wrote: > Strawman: > > What if a mentor is *required* to be an active participant of the project. > That is contributing code, voting on releases and generally engaging with the > community, they would be a better mentor since they have a vested interest in > the project itself. Sure, we might reduce the number of projects coming into > the foundation but (IMHO) that is not a problem. Our goal as a foundation is > not to be large, it is to be high quality. > The role of the Mentor is to coach the project into the Apache philosophy, not to guide the technical progress of the project. Requiring that they contribute code eliminates almost anyone that could participate on *most* of the projects that have come to the ASF in recent years, because almost all of them have been composed primarily of "outsiders". Is that seen as a problem? --Rich -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Dec 29, 2014 12:11 PM, "Hadrian Zbarcea" wrote: > > > On 12/29/2014 09:40 AM, Rich Bowen wrote: >> >> >> >> On 12/22/2014 11:42 AM, Roman Shaposhnik wrote: >>> >>> Hi! >>> >>> before answering Ross' proposal, I'd like to remark that I was holding >>> off on replying to see whether viewpoints that we haven's seen before >>> would emerge. It seems that they didn't. It seems that we're still limited >>> by the following options wrt. resolving mentors AWOL issues: >>> 1. get rid of IPMC altogether and move to the pTLP model >>> 2. make this a poddling issue: if a poddling fails to hunt down ALL >>> the mentors for a sign-off -- reject its report >> >> >> -0.5 to punishing podlings for the failings of mentors. That would really suck. >> > Why not? They get "punished" anyway by the results. This is to me a fail fast mechanism. I think they should understand early on in the incubation projects what's expected of them and what they should expect from the ASF, among other things mentoring. Maybe they made a poor choice early on to chose mentors that don't fit their needs. They can then ping the mentors first and ask for more involvement, and if that doesn't happen, well, change mentors. Or maybe something changed in the personal life of the mentor that prevents them from providing effective mentorship (and say they didn't get to notify the podling). Same thing. In the end what matters are the results. If we emphasized that this is not about punishing or assigning blame, but about providing podlings with the support they need and we signed up to provide, it would be ok, I think. > What I object to is the requirement that *all* mentors sign off. We all have an off month now and then.
Re: Incubator report sign-off
+1 On 12/29/2014 09:15 AM, Rich Bowen wrote: This is what happens when I write email like this and then go for two weeks off of work. Catching up ... On 12/19/2014 01:10 PM, Roman Shaposhnik wrote: First of all,*my* expectation is that multiple mentors on the project are more of redundancy or HA consideration. IOW, my expectation that a project needs to have at least one active mentor at all times, but it doesn't have to be the same person. Thus, I expect at least a signle sign-off on the report and I don't mind if it ends up being a single one too much. You make a good point. I have been critical, of late, of projects that have N mentors, and only 1 or 2 mentors sign off on a report. However, I think you may have changed my perspective here, and I appreciate your insight. Second biggest expectation that I have is that mentors are extension of the IPMC, not part of the poddling. They are akin to professors or faculty members -- they are not part of the student body. As such we, as IPMC are accountable to make sure that mentors perform their duties. My expectation is that it is as unfair to ask poddling to actively pursue mentors who are missing in action as it would be unfair to ask students to hire detectives to hunt down professors who don't show up for class. What is fair, is to provide poddlings with a semi-format feedback channel for IPMC to monitor things like mentors MIA. Agreed. Presumably, projects with no signoff are sent back to report again, with a scolding note to the MIA mentors. As mentioned elsewhere, we don't want to punish the podling for underperforming mentors. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On 12/29/2014 09:40 AM, Rich Bowen wrote: On 12/22/2014 11:42 AM, Roman Shaposhnik wrote: Hi! before answering Ross' proposal, I'd like to remark that I was holding off on replying to see whether viewpoints that we haven's seen before would emerge. It seems that they didn't. It seems that we're still limited by the following options wrt. resolving mentors AWOL issues: 1. get rid of IPMC altogether and move to the pTLP model 2. make this a poddling issue: if a poddling fails to hunt down ALL the mentors for a sign-off -- reject its report -0.5 to punishing podlings for the failings of mentors. That would really suck. Why not? They get "punished" anyway by the results. This is to me a fail fast mechanism. I think they should understand early on in the incubation projects what's expected of them and what they should expect from the ASF, among other things mentoring. Maybe they made a poor choice early on to chose mentors that don't fit their needs. They can then ping the mentors first and ask for more involvement, and if that doesn't happen, well, change mentors. Or maybe something changed in the personal life of the mentor that prevents them from providing effective mentorship (and say they didn't get to notify the podling). Same thing. In the end what matters are the results. If we emphasized that this is not about punishing or assigning blame, but about providing podlings with the support they need and we signed up to provide, it would be ok, I think. My $0.02, Hadrian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On 12/21/2014 11:14 AM, John D. Ament wrote: I don't particularly like that idea. For one, I know that if I were to see 50%+ of mentors on a project I'm a mentor on sign off on the report, I'm probably going to look at things, but not add my signature. Not out of laziness, but in seeing that others are dealing with it as well and my signature is just more "noise" on the report. And as someone reviewing that report, it is *absolutely* not just noise. It tells me that the mentors are engaged, and that are in tune with what the podling is doing, and that the podling is listening to their mentors are are learning the ropes. Podlings that have 100% mentor signoff indicate that everything is going perfectly, and there's no reason for concern. Absolutely not just noise. Take the extra 2 seconds to add your sign off. --Rich -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On 12/23/2014 03:34 PM, sebb wrote: Flex had three great mentors, but to expect them to be the PMC Chair on >graduation would have been problematic. They were great mentors because >they had lots of experience from their work on other Apache projects, and >thus didn’t have time to stay active on a new TLP, plus they really >weren’t users or developers of the technology, just our coaches on the >Apache Way, and thus wouldn’t be good Chair candidates as they weren’t as >invested in the technology. But they did stick around on at least the >private@ lists and continue to do so even 2 years after graduation where >we consult them on occasion. To require that a mentor be an active >contributor limits the kinds of technologies that can come to Apache to >only those who can interest someone with a lot of spare cycles. > >IMO, the mentors job is to teach, not to lead. The job of the PMC chair is almost entirely administrative. They are the link between the board and the PMC and their main role is to ensure the board gets timely reports and to feed back comments from the board. If a PMC is relying on the chair to drive it forward technically, then I think something has gone wrong with the PMC. Indeed. Big +1 on this. There are some projects that I've been watching lately where the PMC chair is viewed as the project lead, and that has a number of problems that go along with it. The PMC chair is a secretary, whose job is to file the right paperwork. A *hugely* important role, but not a technical lead role. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On 12/22/2014 11:42 AM, Roman Shaposhnik wrote: Hi! before answering Ross' proposal, I'd like to remark that I was holding off on replying to see whether viewpoints that we haven's seen before would emerge. It seems that they didn't. It seems that we're still limited by the following options wrt. resolving mentors AWOL issues: 1. get rid of IPMC altogether and move to the pTLP model 2. make this a poddling issue: if a poddling fails to hunt down ALL the mentors for a sign-off -- reject its report -0.5 to punishing podlings for the failings of mentors. That would really suck. 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). ... who don't sign off N times, perhaps? Missing one should be a warning, two a scolding, three the boot, perhaps? FWIW, I personally think #2 is a useless middles ground and if we really feel like #2, we may as well man up and do #1. Frankly, I'd be appalled to remain part of IPMC that treats its podlings like #2 without providing even the slightest accountability for its own members. +1 Thus, to me, the choice is really about #1 and #3. So perhaps, the path forward is to try #3 first and then, if things don't improve, go all the way to #1. Please let me know what do you think. Yes. Agreed. And now to comment on Ross's proposal. The only one that addressed my original issue of lack of clear R&R understanding (which I think everybody else, with an exception of folks bringing up #1 is avoiding): On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH) wrote: Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Well, than I suggest we solicit an opinion on this list of how many mentors will remain if the requirement is to be put in place. I can tell you this much: personally I will have to resign from every single poddling I am currently mentoring. There is absolutely no way I can promise the level of commitment that goes beyond helping them with 'the Apache Way' and releases. IOW, if I were to be required to understand their technology -- I don't think I can stay. I'm considering serving as a mentor, because I think that my experience at the ASF would benefit an incoming podling. If I was required to be a coder on that project, I would no longer be able to participate in that capacity, as my coding abilities have atrophied over the last few years. I also object strongly to the use of the phrase "contributing code" becoming part of any written policy. (#INCLUDE standard conversation about documentors, marketers, event planners, community managers, etc, being every bit as meritorious as coders.) Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. But it is to be high quality on the level of understanding of the 'Apache Way' which has very little to do with the quality of code, documentation or any other piece of technology. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. I actually like this proposal, but only if we can cut out the middleman alltogether. What you're describing is essentially pTLPs. Which is a fine idea. I like the proposal a lot too, and almost proposed it myself. It's a mirror of what the board does, obviously, and raises the bar a little when it comes to podling reports. It also gives the podlings a little more idea of what to expect once they do graduate. The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. Let me ask you this: do you think it would be worth our while to try this without any other changes? IOW, make #2 a champion's problem, instead of poddling's problem? No other changes needed. I look forward to the PMC tearing this strawman proposal apart and (most importantly) suggesting alternatives That was my expectation as well. Sadly, I don't think we've got too many alternatives :-( Roman, please forgive me absence from this conversation. I started the thread, and then went on Christmas vacation. I am still
Re: Incubator report sign-off
On 12/19/2014 02:20 PM, Mattmann, Chris A (3980) wrote: What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. Having read more, and understood more, and consumed more coffee ... I wonder if we might implement this proposal with one incoming project, as a test, under close observation by the board and the IPMC? Might be seen as grossly unfair by the project that remain in the old regime (or, who knows, maybe also by the test project), but it might give us some deeper insight into whether this fixes anything? --Rich -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On 12/19/2014 02:20 PM, Mattmann, Chris A (3980) wrote: 1. Incubation yes, Incubator no a. (all Incubator documentation, active folks, etc., become part of the pool of [incoming project VP]) b. IPMC is dissolved c. We create a new “Incubation PMC” that includes most active members of Incubator currently (those who are good at reviewing releases; watching projects, etc.) 2. All incoming projects are proposed directly as pTLPs (provisional TLPs) - provisional part is defined as: a. 3 members of new Incubation PMC from #1c assigned as PMC and potentially VP of incoming project b. PMC += all incoming folks from proposal c. board VOTEs to approve incoming projects d. project retirement happens same as it currently does, with Attic support To me this would solve the problem of AWOL or mentors who don’t sign off. Mentoring happens via new Incubation PMC who are assigned to the PMCs of incoming pTLPs. Project VP is either one of those Incubation PMC members, or via Ross’s suggestion below, the most active person or “Champion” of the incoming project. The health of these projects are monitored by the Incubation PMC and reported on monthly directly to the board instead of hidden inside the Incubator report each month, without sign off. All of the other problems would seem to go away too IMO. Hmm. I need to read this a few more times and try to figure out what this changes. Initially, it sounds like renaming some things. Since I know you're guy that thinks about these things deeply, I'm obviously missing something. Can you point me to a thread where this was discussed in more detail? -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
This is what happens when I write email like this and then go for two weeks off of work. Catching up ... On 12/19/2014 01:10 PM, Roman Shaposhnik wrote: First of all,*my* expectation is that multiple mentors on the project are more of redundancy or HA consideration. IOW, my expectation that a project needs to have at least one active mentor at all times, but it doesn't have to be the same person. Thus, I expect at least a signle sign-off on the report and I don't mind if it ends up being a single one too much. You make a good point. I have been critical, of late, of projects that have N mentors, and only 1 or 2 mentors sign off on a report. However, I think you may have changed my perspective here, and I appreciate your insight. Second biggest expectation that I have is that mentors are extension of the IPMC, not part of the poddling. They are akin to professors or faculty members -- they are not part of the student body. As such we, as IPMC are accountable to make sure that mentors perform their duties. My expectation is that it is as unfair to ask poddling to actively pursue mentors who are missing in action as it would be unfair to ask students to hire detectives to hunt down professors who don't show up for class. What is fair, is to provide poddlings with a semi-format feedback channel for IPMC to monitor things like mentors MIA. Agreed. Presumably, projects with no signoff are sent back to report again, with a scolding note to the MIA mentors. As mentioned elsewhere, we don't want to punish the podling for underperforming mentors. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On 12/19/2014 02:00 PM, Ross Gardler (MS OPEN TECH) wrote: Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. The role of the Mentor is to coach the project into the Apache philosophy, not to guide the technical progress of the project. Requiring that they contribute code eliminates almost anyone that could participate on *most* of the projects that have come to the ASF in recent years, because almost all of them have been composed primarily of "outsiders". Is that seen as a problem? --Rich -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
Yay progress! +1 Thanks Roman (and everyone else on the thread) Sent from my Windows Phone From: Roman Shaposhnik<mailto:r...@apache.org> Sent: 12/22/2014 8:42 AM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: Incubator report sign-off Hi! before answering Ross' proposal, I'd like to remark that I was holding off on replying to see whether viewpoints that we haven's seen before would emerge. It seems that they didn't. It seems that we're still limited by the following options wrt. resolving mentors AWOL issues: 1. get rid of IPMC altogether and move to the pTLP model 2. make this a poddling issue: if a poddling fails to hunt down ALL the mentors for a sign-off -- reject its report 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). FWIW, I personally think #2 is a useless middles ground and if we really feel like #2, we may as well man up and do #1. Frankly, I'd be appalled to remain part of IPMC that treats its podlings like #2 without providing even the slightest accountability for its own members. Thus, to me, the choice is really about #1 and #3. So perhaps, the path forward is to try #3 first and then, if things don't improve, go all the way to #1. Please let me know what do you think. And now to comment on Ross's proposal. The only one that addressed my original issue of lack of clear R&R understanding (which I think everybody else, with an exception of folks bringing up #1 is avoiding): On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH) wrote: > Strawman: > > What if a mentor is *required* to be an active participant of the project. > That is contributing code, > voting on releases and generally engaging with the community, they would be a > better mentor > since they have a vested interest in the project itself. Well, than I suggest we solicit an opinion on this list of how many mentors will remain if the requirement is to be put in place. I can tell you this much: personally I will have to resign from every single poddling I am currently mentoring. There is absolutely no way I can promise the level of commitment that goes beyond helping them with 'the Apache Way' and releases. IOW, if I were to be required to understand their technology -- I don't think I can stay. > Sure, we might reduce the number of projects coming into the foundation > but (IMHO) that is not a problem. Our goal as a foundation is not to be > large, it is to be high quality. But it is to be high quality on the level of understanding of the 'Apache Way' which has very little to do with the quality of code, documentation or any other piece of technology. > We could scrap the role of shepherd and change the role of mentors. A team > of 9 mentors would meet monthly to review *all* podlings reports (as submitted > by the champion). Their responsibility is not to engage with the projects but > to > review the reports crafted by the champion. Any follow up actions would be > taken by a single mentor and podlings (especially the champion) are expected > to address the issues raised. I actually like this proposal, but only if we can cut out the middleman alltogether. What you're describing is essentially pTLPs. Which is a fine idea. > The champion is still answerable to the podling community. > Where conflict arises within the community they can call upon the IPMC > mentoring team to ask for independent guidance. Let me ask you this: do you think it would be worth our while to try this without any other changes? IOW, make #2 a champion's problem, instead of poddling's problem? No other changes needed. > I look forward to the PMC tearing this strawman proposal apart and (most > importantly) > suggesting alternatives That was my expectation as well. Sadly, I don't think we've got too many alternatives :-( Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Fri Dec 19 2014 at 1:16:32 PM Roman Shaposhnik wrote: > On Fri, Dec 19, 2014 at 10:12 AM, Marvin Humphrey > wrote: > > (Adapting my response from the private list...) > > > > +1 to reject reports where not a single Mentor has signed off and to > require > > the podling to report next month. > > I am confused. We're already doing that. Are you just +1ing an > existing practice? > I'll add some verbiage to this [page] to clarify that, if we had that as a known practice I had no idea. John [page]: http://incubator.apache.org/guides/ppmc.html > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Incubator report sign-off
On 23 Dec 2014 11:39, "Stian Soiland-Reyes" wrote: > We have found that our champion had the right camera and has helped with most of the bootstrapping Before people start joking about incubator selfies, "camera"above is the auto complete version of "karma".. ;) although I think Andy also has a good camera somewhere.
Re: Incubator report sign-off
On 23 December 2014 at 16:43, Alex Harui wrote: > > > On 12/22/14, 11:54 PM, "Niclas Hedhman" wrote: > >>On Tue, Dec 23, 2014 at 12:42 AM, Roman Shaposhnik wrote: >> >>>While Provisional TLP proposals are tested, I would favor; >> >> a. single mentor, the "always present person" who is "first person to >>ask" and "with enough karma", the friendly neighborhood convenience store, >>the oracle of Delphi. I would even like to see him/her be the first PMC >>Chair on graduation, to raise the expectation of responsibility. > > Flex had three great mentors, but to expect them to be the PMC Chair on > graduation would have been problematic. They were great mentors because > they had lots of experience from their work on other Apache projects, and > thus didn’t have time to stay active on a new TLP, plus they really > weren’t users or developers of the technology, just our coaches on the > Apache Way, and thus wouldn’t be good Chair candidates as they weren’t as > invested in the technology. But they did stick around on at least the > private@ lists and continue to do so even 2 years after graduation where > we consult them on occasion. To require that a mentor be an active > contributor limits the kinds of technologies that can come to Apache to > only those who can interest someone with a lot of spare cycles. > > IMO, the mentors job is to teach, not to lead. The job of the PMC chair is almost entirely administrative. They are the link between the board and the PMC and their main role is to ensure the board gets timely reports and to feed back comments from the board. If a PMC is relying on the chair to drive it forward technically, then I think something has gone wrong with the PMC. > Also, IMO, this topic of inactive mentors seems to be too “parent” > oriented, maybe because when we use the word “incubator” we think of > babies. IMO, any worthy podling shouldn’t have a PPMC of babies, it > should have a PPMC of adults committed to success, and those adults should > be equally responsible for their graduation. What would have been helpful > for me to know upon entry to the incubator was truly what the mentor MUST > do and what they SHOULD do and what to do if they didn’t. If I knew that > I needed more than one mentor to sign the IPMC report, I would have bugged > them if they didn’t and asked for help on general@ if they didn’t respond. > No need for shepherds, you would have heard from me. Maybe the incubator > should be renamed “Apache University” or “Apache Training Program”. > > Any rules on some minimum bar of mentor activity is probably doomed to > failure. A podling full of experienced Apache folks will need a lot less > mentoring than one full of folks new to Apache. That’s why I think the > most important message for the mentors to deliver to a new PPMC is that > they are responsible for their graduation, the mentor is just a coach, how > to work with the mentors, and what to do if the mentors can’t be found. > > -Alex > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On 22 Dec 2014 10:42, "Roman Shaposhnik" wrote: > Well, than I suggest we solicit an opinion on this list of how many mentors > will remain if the requirement is to be put in place. I can tell you this much: > personally I will have to resign from every single poddling I am currently > mentoring. There is absolutely no way I can promise the level of commitment > that goes beyond helping them with 'the Apache Way' and releases. IOW, > if I were to be required to understand their technology -- I don't think I can > stay. I fully agree that mentors should not be expected to gain full understanding of the incubator's project. The role of the mentor is to guide the project along Apache Ways, with regards to community building and management, but also on ensuring releases are done in an open source manner. As part of an incubutor, I would however be grateful if at least one of the mentors were capable in the foundational technology, e.g. in our case Java/Maven/OSGi. Why? There is a strong tie between those and release management, dependency management and licensing. We have found that our champion had the right camera and has helped with most of the bootstrapping, while mentors have had a wider view and can say things like "Look at project X and how they do Y".
Re: Incubator report sign-off
On 12/22/14, 11:54 PM, "Niclas Hedhman" wrote: >On Tue, Dec 23, 2014 at 12:42 AM, Roman Shaposhnik wrote: > >>While Provisional TLP proposals are tested, I would favor; > > a. single mentor, the "always present person" who is "first person to >ask" and "with enough karma", the friendly neighborhood convenience store, >the oracle of Delphi. I would even like to see him/her be the first PMC >Chair on graduation, to raise the expectation of responsibility. Flex had three great mentors, but to expect them to be the PMC Chair on graduation would have been problematic. They were great mentors because they had lots of experience from their work on other Apache projects, and thus didn’t have time to stay active on a new TLP, plus they really weren’t users or developers of the technology, just our coaches on the Apache Way, and thus wouldn’t be good Chair candidates as they weren’t as invested in the technology. But they did stick around on at least the private@ lists and continue to do so even 2 years after graduation where we consult them on occasion. To require that a mentor be an active contributor limits the kinds of technologies that can come to Apache to only those who can interest someone with a lot of spare cycles. IMO, the mentors job is to teach, not to lead. Also, IMO, this topic of inactive mentors seems to be too “parent” oriented, maybe because when we use the word “incubator” we think of babies. IMO, any worthy podling shouldn’t have a PPMC of babies, it should have a PPMC of adults committed to success, and those adults should be equally responsible for their graduation. What would have been helpful for me to know upon entry to the incubator was truly what the mentor MUST do and what they SHOULD do and what to do if they didn’t. If I knew that I needed more than one mentor to sign the IPMC report, I would have bugged them if they didn’t and asked for help on general@ if they didn’t respond. No need for shepherds, you would have heard from me. Maybe the incubator should be renamed “Apache University” or “Apache Training Program”. Any rules on some minimum bar of mentor activity is probably doomed to failure. A podling full of experienced Apache folks will need a lot less mentoring than one full of folks new to Apache. That’s why I think the most important message for the mentors to deliver to a new PPMC is that they are responsible for their graduation, the mentor is just a coach, how to work with the mentors, and what to do if the mentors can’t be found. -Alex
Re: Incubator report sign-off
On Tue, Dec 23, 2014 at 12:42 AM, Roman Shaposhnik wrote: > 1. get rid of IPMC altogether and move to the pTLP model > 2. make this a poddling issue: if a poddling fails to hunt down ALL > the mentors for a sign-off -- reject its report > 3. patch the current process with starting to drop the mentors from > the project who don't sign off. This will essentially serve > as a heartbeat for mentors (now, in my opinion it'll quickly >deteriorate into mindless tick-offs -- but at least it does not harm). There is a fairly long tradition in ASF to not make any irreversible steps, so "get rid of the IPMC" isn't an option until "pTLP model" has been tried, tested and evaluated. The "move to" is in the wrong direction... Doug even suggested "Put proposals in front of the Board, and see what happens" (my words, not his). I would imagine years from "first pTLP" to "finally get rid of IPMC", so if #2 is not an option, neither is the first 5 words of #1. I always felt that the "many mentors" idea was an anti-pattern, as sense of responsibility quickly declines for the individual mentor -- "the others can take care of this"-attitude. While Provisional TLP proposals are tested, I would favor; a. single mentor, the "always present person" who is "first person to ask" and "with enough karma", the friendly neighborhood convenience store, the oracle of Delphi. I would even like to see him/her be the first PMC Chair on graduation, to raise the expectation of responsibility. b. incubating projects don't make ASF releases, hence the IPMC doesn't need to vote the release, just like the Board doesn't vote on a TLP's release. Let the ppmc (with Mentor help) handle it all in-house. They MAY announce releases on general@, but MUST bring it up in the reports. c. podling acts identically to a TLP, except IPMC acts "as Board" d. hence IPMC assigns a Shepard (possibly rotating), who checks report sent, check the mentor is active and that podling is "healthy". This better matches the ASF modus operandi, less changes on graduation and solves the AWOL mentor problem. But it also creates new ones; fewer volunteers for mentor role, transitional pain from current system, and probably much else I haven't thought of. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
Re: Incubator report sign-off
On 22.12.2014 17:42, Roman Shaposhnik wrote: > Thus, to me, the choice is really about #1 and #3. So perhaps, the > path forward is to try #3 first and then, if things don't improve, go > all the way to #1. Please let me know what do you think. +1 >> Sure, we might reduce the number of projects coming into the foundation >> but (IMHO) that is not a problem. Our goal as a foundation is not to be >> large, it is to be high quality. > But it is to be high quality on the level of understanding of the 'Apache Way' > which has very little to do with the quality of code, documentation or any > other piece of technology. That's my take as well. Meritocracy; community structure; when to vote and especially when *not* to vote; requirements for releases, etc. and the reasons for all of the above are the things that a mentor should be expected to keep an eye on. Especially at the beginning of incubation, because bad habits are harder to break later on. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
I am down with this, but would really rather allow reports that have less than all of the mentors signing off to be accepted. Right now, I am involved in mentoring a new podling and at least one other of the mentors has done literally nothing. No email answers, no help editing the proposal. No setting up mailing lists. I expect the level of effort to be stable. Sure, at some point, he ought to be booted from being a mentor. But in the meantime, we have two very active mentors who are busy helping the project get going. If we get two sign-offs, is it really necessary penalize the podling? I can see that after 3 reports with a missing mentor, it is reasonable to boot the mentor if there is a safety net and I can see that having no mentor sign-off is a serious problem for the podling in any case. But having *only* two mentors hardly seems like an emergency. On Mon, Dec 22, 2014 at 12:31 AM, Bertrand Delacretaz < bdelacre...@apache.org> wrote: > On Sun, Dec 21, 2014 at 5:14 PM, John D. Ament > wrote: > > ... is everyone OK if we mark > > podlings who don't have mentor sign off as monthly?... > > I am ok with that - basically, a report without sign off is like a > missing report. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Incubator report sign-off
+1, this makes sense to me, Roman. For #3, please feel free to use my apachestuff code: http://github.com/chrismattmann/apachestuff/ in particular, incubator_mentor_tally, the latest results of which are here: https://github.com/chrismattmann/apachestuff/blob/master/incubator-mentors- tally.txt ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Roman Shaposhnik Reply-To: "general@incubator.apache.org" Date: Monday, December 22, 2014 at 8:42 AM To: "general@incubator.apache.org" Subject: Re: Incubator report sign-off >Hi! > >before answering Ross' proposal, I'd like to remark that I was holding >off on replying to see whether viewpoints that we haven's seen before >would emerge. It seems that they didn't. It seems that we're still limited >by the following options wrt. resolving mentors AWOL issues: >1. get rid of IPMC altogether and move to the pTLP model >2. make this a poddling issue: if a poddling fails to hunt down ALL >the mentors for a sign-off -- reject its report >3. patch the current process with starting to drop the mentors from >the project who don't sign off. This will essentially serve >as a heartbeat for mentors (now, in my opinion it'll quickly > deteriorate into mindless tick-offs -- but at least it does not >harm). > >FWIW, I personally think #2 is a useless middles ground and if we >really feel like #2, we may as well man up and do #1. Frankly, I'd >be appalled to remain part of IPMC that treats its podlings like #2 >without providing even the slightest accountability for its own members. > >Thus, to me, the choice is really about #1 and #3. So perhaps, the >path forward is to try #3 first and then, if things don't improve, go >all the way to #1. Please let me know what do you think. > >And now to comment on Ross's proposal. The only one that addressed >my original issue of lack of clear R&R understanding (which I think >everybody else, with an exception of folks bringing up #1 is avoiding): > >On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH) > wrote: >> Strawman: >> >> What if a mentor is *required* to be an active participant of the >>project. That is contributing code, >> voting on releases and generally engaging with the community, they >>would be a better mentor >> since they have a vested interest in the project itself. > >Well, than I suggest we solicit an opinion on this list of how many >mentors >will remain if the requirement is to be put in place. I can tell you this >much: >personally I will have to resign from every single poddling I am currently >mentoring. There is absolutely no way I can promise the level of >commitment >that goes beyond helping them with 'the Apache Way' and releases. IOW, >if I were to be required to understand their technology -- I don't think >I can >stay. > >> Sure, we might reduce the number of projects coming into the foundation >> but (IMHO) that is not a problem. Our goal as a foundation is not to be >> large, it is to be high quality. > >But it is to be high quality on the level of understanding of the 'Apache >Way' >which has very little to do with the quality of code, documentation or any >other piece of technology. > >> We could scrap the role of shepherd and change the role of mentors. A >>team >> of 9 mentors would meet monthly to review *all* podlings reports (as >>submitted >> by the champion). Their responsibility is not to engage with the >>projects but to >> review the reports crafted by the champion. Any follow up actions would >>be >> taken by a single mentor and podlings (especially the champion) are >>expected >> to address the issues raised. > >I actually like this proposal, but only if we can cut out the >middleman alltogether. >What you're describing is essentially pTLPs. Which is a fine idea. > >> The champion is still answerable to the podling community. >> Where conflict arises within the community they can call upon the IPMC >> mentoring team to ask for independent guidance. > >Let me ask
RE: Incubator report sign-off
+1 -- in reply to -- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Monday, December 22, 2014 08:42 To: general@incubator.apache.org Subject: Re: Incubator report sign-off Hi! before answering Ross' proposal, I'd like to remark that I was holding off on replying to see whether viewpoints that we haven's seen before would emerge. It seems that they didn't. It seems that we're still limited by the following options wrt. resolving mentors AWOL issues: 1. get rid of IPMC altogether and move to the pTLP model 2. make this a poddling issue: if a poddling fails to hunt down ALL the mentors for a sign-off -- reject its report 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). [ ... ] Thus, to me, the choice is really about #1 and #3. So perhaps, the path forward is to try #3 first and then, if things don't improve, go all the way to #1. Please let me know what do you think. [ ... ] Let me ask you this: do you think it would be worth our while to try this without any other changes? IOW, make #2 a champion's problem, instead of poddling's problem? No other changes needed. That was a question to Ross. I am chiming in to favor the "try this." [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Monday, December 22, 2014, Roman Shaposhnik wrote: > Hi! > > before answering Ross' proposal, I'd like to remark that I was holding > off on replying to see whether viewpoints that we haven's seen before > would emerge. It seems that they didn't. It seems that we're still limited > by the following options wrt. resolving mentors AWOL issues: > 1. get rid of IPMC altogether and move to the pTLP model could you waste a couple of words on pTLP, to me at least its a new term, I would like to understand. rgds jan i > 2. make this a poddling issue: if a poddling fails to hunt down ALL > the mentors for a sign-off -- reject its report > 3. patch the current process with starting to drop the mentors from > the project who don't sign off. This will essentially serve > as a heartbeat for mentors (now, in my opinion it'll quickly >deteriorate into mindless tick-offs -- but at least it does not > harm). > > FWIW, I personally think #2 is a useless middles ground and if we > really feel like #2, we may as well man up and do #1. Frankly, I'd > be appalled to remain part of IPMC that treats its podlings like #2 > without providing even the slightest accountability for its own members. > > Thus, to me, the choice is really about #1 and #3. So perhaps, the > path forward is to try #3 first and then, if things don't improve, go > all the way to #1. Please let me know what do you think. > > And now to comment on Ross's proposal. The only one that addressed > my original issue of lack of clear R&R understanding (which I think > everybody else, with an exception of folks bringing up #1 is avoiding): > > On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH) > > wrote: > > Strawman: > > > > What if a mentor is *required* to be an active participant of the > project. That is contributing code, > > voting on releases and generally engaging with the community, they would > be a better mentor > > since they have a vested interest in the project itself. > > Well, than I suggest we solicit an opinion on this list of how many mentors > will remain if the requirement is to be put in place. I can tell you this > much: > personally I will have to resign from every single poddling I am currently > mentoring. There is absolutely no way I can promise the level of commitment > that goes beyond helping them with 'the Apache Way' and releases. IOW, > if I were to be required to understand their technology -- I don't think I > can > stay. > > > Sure, we might reduce the number of projects coming into the foundation > > but (IMHO) that is not a problem. Our goal as a foundation is not to be > > large, it is to be high quality. > > But it is to be high quality on the level of understanding of the 'Apache > Way' > which has very little to do with the quality of code, documentation or any > other piece of technology. > > > We could scrap the role of shepherd and change the role of mentors. A > team > > of 9 mentors would meet monthly to review *all* podlings reports (as > submitted > > by the champion). Their responsibility is not to engage with the > projects but to > > review the reports crafted by the champion. Any follow up actions would > be > > taken by a single mentor and podlings (especially the champion) are > expected > > to address the issues raised. > > I actually like this proposal, but only if we can cut out the > middleman alltogether. > What you're describing is essentially pTLPs. Which is a fine idea. > > > The champion is still answerable to the podling community. > > Where conflict arises within the community they can call upon the IPMC > > mentoring team to ask for independent guidance. > > Let me ask you this: do you think it would be worth our while to try this > without any other changes? IOW, make #2 a champion's problem, instead > of poddling's problem? No other changes needed. > > > > I look forward to the PMC tearing this strawman proposal apart and (most > importantly) > > suggesting alternatives > > That was my expectation as well. Sadly, I don't think we've got too many > alternatives :-( > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > -- Sent from My iPad, sorry for any misspellings.
Re: Incubator report sign-off
Hi! before answering Ross' proposal, I'd like to remark that I was holding off on replying to see whether viewpoints that we haven's seen before would emerge. It seems that they didn't. It seems that we're still limited by the following options wrt. resolving mentors AWOL issues: 1. get rid of IPMC altogether and move to the pTLP model 2. make this a poddling issue: if a poddling fails to hunt down ALL the mentors for a sign-off -- reject its report 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). FWIW, I personally think #2 is a useless middles ground and if we really feel like #2, we may as well man up and do #1. Frankly, I'd be appalled to remain part of IPMC that treats its podlings like #2 without providing even the slightest accountability for its own members. Thus, to me, the choice is really about #1 and #3. So perhaps, the path forward is to try #3 first and then, if things don't improve, go all the way to #1. Please let me know what do you think. And now to comment on Ross's proposal. The only one that addressed my original issue of lack of clear R&R understanding (which I think everybody else, with an exception of folks bringing up #1 is avoiding): On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH) wrote: > Strawman: > > What if a mentor is *required* to be an active participant of the project. > That is contributing code, > voting on releases and generally engaging with the community, they would be a > better mentor > since they have a vested interest in the project itself. Well, than I suggest we solicit an opinion on this list of how many mentors will remain if the requirement is to be put in place. I can tell you this much: personally I will have to resign from every single poddling I am currently mentoring. There is absolutely no way I can promise the level of commitment that goes beyond helping them with 'the Apache Way' and releases. IOW, if I were to be required to understand their technology -- I don't think I can stay. > Sure, we might reduce the number of projects coming into the foundation > but (IMHO) that is not a problem. Our goal as a foundation is not to be > large, it is to be high quality. But it is to be high quality on the level of understanding of the 'Apache Way' which has very little to do with the quality of code, documentation or any other piece of technology. > We could scrap the role of shepherd and change the role of mentors. A team > of 9 mentors would meet monthly to review *all* podlings reports (as submitted > by the champion). Their responsibility is not to engage with the projects but > to > review the reports crafted by the champion. Any follow up actions would be > taken by a single mentor and podlings (especially the champion) are expected > to address the issues raised. I actually like this proposal, but only if we can cut out the middleman alltogether. What you're describing is essentially pTLPs. Which is a fine idea. > The champion is still answerable to the podling community. > Where conflict arises within the community they can call upon the IPMC > mentoring team to ask for independent guidance. Let me ask you this: do you think it would be worth our while to try this without any other changes? IOW, make #2 a champion's problem, instead of poddling's problem? No other changes needed. > I look forward to the PMC tearing this strawman proposal apart and (most > importantly) > suggesting alternatives That was my expectation as well. Sadly, I don't think we've got too many alternatives :-( Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Sun, Dec 21, 2014 at 5:14 PM, John D. Ament wrote: > ... is everyone OK if we mark > podlings who don't have mentor sign off as monthly?... I am ok with that - basically, a report without sign off is like a missing report. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Sat Dec 20 2014 at 6:09:33 AM Branko Čibej wrote: > On 19 December 2014 at 18:10, Rich Bowen wrote: > > I certainly don't expect that every mentor has their full attention on a > > podling every month, but I do expect that a podling that cares about its > > incubation will seek out that mentor sign-off, and that the mentors who > have > > committed to help a podling into the family will have a few moments every > > few months to look in and approve a report. > > > I have to disagree. If someone volunteers to be a mentor, they should > commit to checking the podling's progress on a daily basis, not just > once every few months. There are some people on the IPMC who are > mentors to a plethora of podlings; I can never understand how they > expect to do their job, and the fact that there are so many absent > mentors tends to suggest that they don't. > > Certainly, we're all volunteers here. But being a volunteer does not > imply that one doesn't have to take their task seriously. If someone > runs out of time, the least I'd expect would be notifying the IPMC and > the podling about that and arranging for a new mentor. Otherwise, I > expect not only monthly (or quarterly) sign-offs, but regular > oversight and moderately active involvement in the community. Because > after all, how are people supposed to learn how things are done > hereabouts, if not from active mentors? > > In that note ... i'd propose that, if a mentor does not sign off on a > report, said mentor should be reminded once; if nothing changes, they > should be removed and replaced by someone else. > I don't particularly like that idea. For one, I know that if I were to see 50%+ of mentors on a project I'm a mentor on sign off on the report, I'm probably going to look at things, but not add my signature. Not out of laziness, but in seeing that others are dealing with it as well and my signature is just more "noise" on the report. Maybe I missed it somewhere in this thread, but is everyone OK if we mark podlings who don't have mentor sign off as monthly? John > > -- Brane > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Incubator report sign-off
On 19 December 2014 at 18:10, Rich Bowen wrote: > I certainly don't expect that every mentor has their full attention on a > podling every month, but I do expect that a podling that cares about its > incubation will seek out that mentor sign-off, and that the mentors who have > committed to help a podling into the family will have a few moments every > few months to look in and approve a report. I have to disagree. If someone volunteers to be a mentor, they should commit to checking the podling's progress on a daily basis, not just once every few months. There are some people on the IPMC who are mentors to a plethora of podlings; I can never understand how they expect to do their job, and the fact that there are so many absent mentors tends to suggest that they don't. Certainly, we're all volunteers here. But being a volunteer does not imply that one doesn't have to take their task seriously. If someone runs out of time, the least I'd expect would be notifying the IPMC and the podling about that and arranging for a new mentor. Otherwise, I expect not only monthly (or quarterly) sign-offs, but regular oversight and moderately active involvement in the community. Because after all, how are people supposed to learn how things are done hereabouts, if not from active mentors? In that note ... i'd propose that, if a mentor does not sign off on a report, said mentor should be reminded once; if nothing changes, they should be removed and replaced by someone else. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
> On 19 Dec 2014, at 18:30, Benson Margulies wrote: > > On Fri, Dec 19, 2014 at 6:09 PM, Louis Suárez-Potts wrote: >> Are we top posting now? >> >> My comments below Ross’ >> >> >>> On 19 Dec 2014, at 16:33, Dennis E. Hamilton >>> wrote: >>> >>> As a participant, I have two concerns about a player-mentor requirement. >>> >>> 1. Sustainability. In many ways, it is mentors who need to have their >>> attention on The Apache Way and cultivating a sustainable project. That >>> means, from my perspective, that mentors need to encourage others to do >>> things, especially around project management and procedural matters, and >>> not just take on matters without leaving any bread crumbs. It seems >>> important that others learn how to do that sort of thing too, whether or >>> not special karma is eventually required to perform the same activities. >>> >>> 2. I have learned repeatedly, and it is evidently well-known, that a >>> developer is his own worst project manager. It has to do with attention >>> being at a completely different place when heads-down in development tasks >>> than when heads-up watching the horizon and keeping objectives and current >>> effort aligned. When I am in developer mode, I need someone else to pull my >>> attention out of the weeds and look to see what course I am on and where I >>> am at on that course. >>> >>> I remember in the 60s when a colleague had ended up managing a project at >>> GE Medical Systems (or something similar) and he confessed that his team >>> made a terrible mistake -- they allowed him to program on their project. >>> >>> I'm not saying that a mentor could not be an effective player. I think >>> doing it well while mentoring is not common and it might interfere with >>> training and development as well. >>> >>> - Dennis >>> >>> >>> -Original Message- >>> From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] >>> Sent: Friday, December 19, 2014 11:01 >>> To: general@incubator.apache.org >>> Subject: RE: Incubator report sign-off >>> >>> Strawman: >>> >>> What if a mentor is *required* to be an active participant of the project. >>> That is contributing code, voting on releases and generally engaging with >>> the community, they would be a better mentor since they have a vested >>> interest in the project itself. Sure, we might reduce the number of >>> projects coming into the foundation but (IMHO) that is not a problem. Our >>> goal as a foundation is not to be large, it is to be high quality. >>> >>> [ … >>> ] >>> >> Accepting Dennis’ point, but I think that there’s a difference between being >> in a large corporation doing in-house work and participating part time as a >> mentor. It’s as if I were (as I do) to teach courses after work that relate >> to my expertise but are not identical to it, if only because I like to think >> that I’m more advanced than any student I’d have. >> >> In prior instances where we’ve had mentors, or where I know of them, e.g., >> Mozilla’s Firefox extension program at Seneca College, Toronto, where the >> lead instructor of the classroom of students (as well as of individual >> pupils) is a developer at Mozilla. (He’s paid indirectly by Mozilla to >> teach, I believe; that, at least, was at the arrangement we had with Seneca >> for OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, >> the argument presented to me by the instructor was that it was essential to >> be an active developer, at least if one were instructing students on both >> the collaborative dynamics as well as the code itself. To be sure, one need >> not be immersed in the project (i.e., have it as a day job), but being >> engaged and current with the latest was important. >> >> But to stipulate it as a requirement? Why? Why make it a requirement and not >> just a recommendation, albeit a strong one? the only thing gained by making >> it a requirement—and in bold, too—is to have a tool by which one could >> eliminate candidates. And I do not think that is in the spirit of a >> pragmatic open source project. >> >> louis >> >> >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For
Re: Incubator report sign-off
On Fri, Dec 19, 2014 at 6:09 PM, Louis Suárez-Potts wrote: > Are we top posting now? > > My comments below Ross’ > > >> On 19 Dec 2014, at 16:33, Dennis E. Hamilton wrote: >> >> As a participant, I have two concerns about a player-mentor requirement. >> >> 1. Sustainability. In many ways, it is mentors who need to have their >> attention on The Apache Way and cultivating a sustainable project. That >> means, from my perspective, that mentors need to encourage others to do >> things, especially around project management and procedural matters, and not >> just take on matters without leaving any bread crumbs. It seems important >> that others learn how to do that sort of thing too, whether or not special >> karma is eventually required to perform the same activities. >> >> 2. I have learned repeatedly, and it is evidently well-known, that a >> developer is his own worst project manager. It has to do with attention >> being at a completely different place when heads-down in development tasks >> than when heads-up watching the horizon and keeping objectives and current >> effort aligned. When I am in developer mode, I need someone else to pull my >> attention out of the weeds and look to see what course I am on and where I >> am at on that course. >> >> I remember in the 60s when a colleague had ended up managing a project at GE >> Medical Systems (or something similar) and he confessed that his team made a >> terrible mistake -- they allowed him to program on their project. >> >> I'm not saying that a mentor could not be an effective player. I think doing >> it well while mentoring is not common and it might interfere with training >> and development as well. >> >> - Dennis >> >> >> -----Original Message- >> From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] >> Sent: Friday, December 19, 2014 11:01 >> To: general@incubator.apache.org >> Subject: RE: Incubator report sign-off >> >> Strawman: >> >> What if a mentor is *required* to be an active participant of the project. >> That is contributing code, voting on releases and generally engaging with >> the community, they would be a better mentor since they have a vested >> interest in the project itself. Sure, we might reduce the number of projects >> coming into the foundation but (IMHO) that is not a problem. Our goal as a >> foundation is not to be large, it is to be high quality. >> >> [ … >> ] >> > Accepting Dennis’ point, but I think that there’s a difference between being > in a large corporation doing in-house work and participating part time as a > mentor. It’s as if I were (as I do) to teach courses after work that relate > to my expertise but are not identical to it, if only because I like to think > that I’m more advanced than any student I’d have. > > In prior instances where we’ve had mentors, or where I know of them, e.g., > Mozilla’s Firefox extension program at Seneca College, Toronto, where the > lead instructor of the classroom of students (as well as of individual > pupils) is a developer at Mozilla. (He’s paid indirectly by Mozilla to teach, > I believe; that, at least, was at the arrangement we had with Seneca for > OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, the > argument presented to me by the instructor was that it was essential to be an > active developer, at least if one were instructing students on both the > collaborative dynamics as well as the code itself. To be sure, one need not > be immersed in the project (i.e., have it as a day job), but being engaged > and current with the latest was important. > > But to stipulate it as a requirement? Why? Why make it a requirement and not > just a recommendation, albeit a strong one? the only thing gained by making > it a requirement—and in bold, too—is to have a tool by which one could > eliminate candidates. And I do not think that is in the spirit of a pragmatic > open source project. > > louis > > >> >> - >> 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 > I'm not top-posting. I think the 'involved mentors' is part of an attempt to resolve several conflicting desires. The ment
RE: [OFF-LIST] RE: Incubator report sign-off
Sorry, I forgot to change the automatic reply to list when moving this to an off-list investigation. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Friday, December 19, 2014 15:07 To: general@incubator.apache.org Subject: [OFF-LIST] RE: Incubator report sign-off Now we are getting somewhere? This post disappeared too. But yours in the same thread before it didn't. Are you replying to Chris's post or another here? Was there anything else at all different? Is there more than one way you read from the lists (i.e., via a news reader or something)? -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 12:46 To: general@incubator.apache.org Subject: RE: Incubator report sign-off - 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: Incubator report sign-off
Are we top posting now? My comments below Ross’ > On 19 Dec 2014, at 16:33, Dennis E. Hamilton wrote: > > As a participant, I have two concerns about a player-mentor requirement. > > 1. Sustainability. In many ways, it is mentors who need to have their > attention on The Apache Way and cultivating a sustainable project. That > means, from my perspective, that mentors need to encourage others to do > things, especially around project management and procedural matters, and not > just take on matters without leaving any bread crumbs. It seems important > that others learn how to do that sort of thing too, whether or not special > karma is eventually required to perform the same activities. > > 2. I have learned repeatedly, and it is evidently well-known, that a > developer is his own worst project manager. It has to do with attention > being at a completely different place when heads-down in development tasks > than when heads-up watching the horizon and keeping objectives and current > effort aligned. When I am in developer mode, I need someone else to pull my > attention out of the weeds and look to see what course I am on and where I am > at on that course. > > I remember in the 60s when a colleague had ended up managing a project at GE > Medical Systems (or something similar) and he confessed that his team made a > terrible mistake -- they allowed him to program on their project. > > I'm not saying that a mentor could not be an effective player. I think doing > it well while mentoring is not common and it might interfere with training > and development as well. > > - Dennis > > > -Original Message- > From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] > Sent: Friday, December 19, 2014 11:01 > To: general@incubator.apache.org > Subject: RE: Incubator report sign-off > > Strawman: > > What if a mentor is *required* to be an active participant of the project. > That is contributing code, voting on releases and generally engaging with the > community, they would be a better mentor since they have a vested interest in > the project itself. Sure, we might reduce the number of projects coming into > the foundation but (IMHO) that is not a problem. Our goal as a foundation is > not to be large, it is to be high quality. > > [ … > ] > Accepting Dennis’ point, but I think that there’s a difference between being in a large corporation doing in-house work and participating part time as a mentor. It’s as if I were (as I do) to teach courses after work that relate to my expertise but are not identical to it, if only because I like to think that I’m more advanced than any student I’d have. In prior instances where we’ve had mentors, or where I know of them, e.g., Mozilla’s Firefox extension program at Seneca College, Toronto, where the lead instructor of the classroom of students (as well as of individual pupils) is a developer at Mozilla. (He’s paid indirectly by Mozilla to teach, I believe; that, at least, was at the arrangement we had with Seneca for OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, the argument presented to me by the instructor was that it was essential to be an active developer, at least if one were instructing students on both the collaborative dynamics as well as the code itself. To be sure, one need not be immersed in the project (i.e., have it as a day job), but being engaged and current with the latest was important. But to stipulate it as a requirement? Why? Why make it a requirement and not just a recommendation, albeit a strong one? the only thing gained by making it a requirement—and in bold, too—is to have a tool by which one could eliminate candidates. And I do not think that is in the spirit of a pragmatic open source project. louis > > - > 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
[OFF-LIST] RE: Incubator report sign-off
Now we are getting somewhere? This post disappeared too. But yours in the same thread before it didn't. Are you replying to Chris's post or another here? Was there anything else at all different? Is there more than one way you read from the lists (i.e., via a news reader or something)? -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 12:46 To: general@incubator.apache.org Subject: RE: Incubator report sign-off - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
Thank you Benson. And that food fight taught me a lot too and so did the conversations with you. Cheers and happy holidays. Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Benson Margulies Reply-To: "general@incubator.apache.org" Date: Friday, December 19, 2014 at 12:15 PM To: "general@incubator.apache.org" Subject: Re: Incubator report sign-off >Back when I was trying to be the chair of this operation, we (ChrisM & >I & others) had a lovely old food fight about Chris M's proposal. It >seems to me that the fundamental situation as I saw it remains: this >is a proposal to the board to dissolve the IPMC and replace it with >something else. And just to be clear: I think that it's a _good idea_ >as a proposal to the board. > >I think that it amounts to making the Foundation's policy be: > >You can launch a new project in the Foundation if you can recruit >three foundation members (or others acceptable to the board) as the >nucleus of your PMC to teach you the ropes and ensure that policies >are respected; from the start, you're an 'incubating TLP' reporting to >the board like all other TLPs. > >I don't think that those three people have, necessarily to be coders. >But they have to be fully engaged -- they have to be members of the >community and the PMC. > >It seems to me that any scheme short of this is guaranteed to end up >right back where we are; struggling to simulate working PMCs with >shepherds and mentors and champions and, I don't know, curators and >wardens and counselors. > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org >
RE: Incubator report sign-off
As a participant, I have two concerns about a player-mentor requirement. 1. Sustainability. In many ways, it is mentors who need to have their attention on The Apache Way and cultivating a sustainable project. That means, from my perspective, that mentors need to encourage others to do things, especially around project management and procedural matters, and not just take on matters without leaving any bread crumbs. It seems important that others learn how to do that sort of thing too, whether or not special karma is eventually required to perform the same activities. 2. I have learned repeatedly, and it is evidently well-known, that a developer is his own worst project manager. It has to do with attention being at a completely different place when heads-down in development tasks than when heads-up watching the horizon and keeping objectives and current effort aligned. When I am in developer mode, I need someone else to pull my attention out of the weeds and look to see what course I am on and where I am at on that course. I remember in the 60s when a colleague had ended up managing a project at GE Medical Systems (or something similar) and he confessed that his team made a terrible mistake -- they allowed him to program on their project. I'm not saying that a mentor could not be an effective player. I think doing it well while mentoring is not common and it might interfere with training and development as well. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 11:01 To: general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Fri, Dec 19, 2014 at 12:45 PM, Ross Gardler (MS OPEN TECH) wrote: > I do question the need to dissolve the IPMC Indeed. Chris' proposal is not exclusive with keeping the Incubator as it is. Folks could currently submit a resolution to the board to start a TLP and see what happens. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
Assuming that the project "VP" is someone personally invested in the project I have no real problem with the core of this proposal. If they are not personally invested, if they are instead a semi-random person from the IPMC then I do not see how this will address the real problem (which is *not* having people tick a box on a report). I do question the need to dissolve the IPMC, but we've been over that before and at this point is probably an unnecessary distraction from the important topic of ensuring mentors have a vested interest in the project. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] Sent: Friday, December 19, 2014 11:21 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off And how could the below proposal return without me passing along my comment regarding it - if we’re going to emulate the board and TLPs, etc., why emulate it when we could cut through the middle man and simply rely on the board to do so? I guess to protect the board from an influx of “incubating” projects (+30-40 at this point in time?) I myself as a board member would welcome this. What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. TL;DR 1. Incubation yes, Incubator no a. (all Incubator documentation, active folks, etc., become part of the pool of [incoming project VP]) b. IPMC is dissolved c. We create a new “Incubation PMC” that includes most active members of Incubator currently (those who are good at reviewing releases; watching projects, etc.) 2. All incoming projects are proposed directly as pTLPs (provisional TLPs) - provisional part is defined as: a. 3 members of new Incubation PMC from #1c assigned as PMC and potentially VP of incoming project b. PMC += all incoming folks from proposal c. board VOTEs to approve incoming projects d. project retirement happens same as it currently does, with Attic support To me this would solve the problem of AWOL or mentors who don’t sign off. Mentoring happens via new Incubation PMC who are assigned to the PMCs of incoming pTLPs. Project VP is either one of those Incubation PMC members, or via Ross’s suggestion below, the most active person or “Champion” of the incoming project. The health of these projects are monitored by the Incubation PMC and reported on monthly directly to the board instead of hidden inside the Incubator report each month, without sign off. All of the other problems would seem to go away too IMO. My 2c. Cheers, Chris -Original Message- From: "Ross Gardler (MS OPEN TECH)" Reply-To: "general@incubator.apache.org" Date: Friday, December 19, 2014 at 11:00 AM To: "general@incubator.apache.org" Subject: RE: Incubator report sign-off >Strawman: > >What if a mentor is *required* to be an active participant of the >project. That is contributing code, voting on releases and generally >engaging with the community, they would be a better mentor since they >have a vested interest in the project itself. Sure, we might reduce the >number of projects coming into the foundation but (IMHO) that is not a >problem. Our goal as a foundation is not to be large, it is to be high >quality. > >Maybe we should simply scrap the idea of "mentors" and change the role >of the "champion" to one of an initial committer who will help build an >Apache project as it incubates and into being a TLP. > >We could scrap the role of shepherd and change the role of mentors. A >team of 9 mentors would meet monthly to review *all* podlings reports >(as submitted by the champion). Their responsibility is not to engage >with the projects but to review the reports crafted by the champion. >Any follow up actions would be taken by a single mentor and podlings >(especially the champion) are expected to address the issues raised. > >If a champion's priorities change during the course of incubation then >the project must find another champion (potentially from within their >own >ranks) who is sufficiently qualified and committed to take on the >responsibility. The important thing is that the Champion is personally >invested in seeing the podling succeed and acts as a true mentor (as >opposed to someone with a title and an entry on a web page). The >champion is still answerable to the podling community. Where conflict >arises within the community they can call upon the IPMC mentoring team >to ask for independent guidance. > >This model is almost identical to the way the board and TLPs work >(where Champions are roughly equivalent to PMC Chairs and mentors (nee >she
Re: Incubator report sign-off
Back when I was trying to be the chair of this operation, we (ChrisM & I & others) had a lovely old food fight about Chris M's proposal. It seems to me that the fundamental situation as I saw it remains: this is a proposal to the board to dissolve the IPMC and replace it with something else. And just to be clear: I think that it's a _good idea_ as a proposal to the board. I think that it amounts to making the Foundation's policy be: You can launch a new project in the Foundation if you can recruit three foundation members (or others acceptable to the board) as the nucleus of your PMC to teach you the ropes and ensure that policies are respected; from the start, you're an 'incubating TLP' reporting to the board like all other TLPs. I don't think that those three people have, necessarily to be coders. But they have to be fully engaged -- they have to be members of the community and the PMC. It seems to me that any scheme short of this is guaranteed to end up right back where we are; struggling to simulate working PMCs with shepherds and mentors and champions and, I don't know, curators and wardens and counselors. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
+1 for Chris's proposal. Without diminishing the creativity applied to solving problems with the incubator, perhaps the better solution is to trade those problems for tractable ones. -C On Fri, Dec 19, 2014 at 11:20 AM, Mattmann, Chris A (3980) wrote: > And how could the below proposal return without me passing along > > my comment regarding it - if we’re going to emulate the board and > TLPs, etc., why emulate it when we could cut through the middle man > and simply rely on the board to do so? I guess to protect the board > from an influx of “incubating” projects (+30-40 at this point in time?) > I myself as a board member would welcome this. > > What it would do however if we simply did away with the notion of the > IPMC/Incubator/etc., is to return to the notion of pTLPs which were > proposed earlier which I would most wholeheartedly support. > > TL;DR > > 1. Incubation yes, Incubator no > a. (all Incubator documentation, active folks, etc., become part of the > pool of [incoming project VP]) > b. IPMC is dissolved > c. We create a new “Incubation PMC” that includes most active members of > Incubator currently (those who are good at reviewing releases; watching > projects, > etc.) > > 2. All incoming projects are proposed directly as pTLPs (provisional > TLPs) > - provisional part is defined as: >a. 3 members of new Incubation PMC from #1c > assigned as PMC and potentially VP of incoming project >b. PMC += all incoming folks from proposal >c. board VOTEs to approve incoming projects >d. project retirement happens same as it currently does, with Attic > support > > To me this would solve the problem of AWOL or mentors who don’t sign off. > Mentoring happens via new Incubation PMC who are assigned > to the PMCs of incoming pTLPs. Project VP is either one of those > Incubation PMC > members, or via Ross’s suggestion below, the most active person > or “Champion” of the incoming project. The health of these projects are > monitored > by the Incubation PMC and reported on monthly directly to the board > instead of hidden > inside the Incubator report each month, without sign off. All of the other > problems > would seem to go away too IMO. > > My 2c. > > Cheers, > Chris > > -Original Message- > From: "Ross Gardler (MS OPEN TECH)" > Reply-To: "general@incubator.apache.org" > Date: Friday, December 19, 2014 at 11:00 AM > To: "general@incubator.apache.org" > Subject: RE: Incubator report sign-off > >>Strawman: >> >>What if a mentor is *required* to be an active participant of the >>project. That is contributing code, voting on releases and generally >>engaging with the community, they would be a better mentor since they >>have a vested interest in the project itself. Sure, we might reduce the >>number of projects coming into the foundation but (IMHO) that is not a >>problem. Our goal as a foundation is not to be large, it is to be high >>quality. >> >>Maybe we should simply scrap the idea of "mentors" and change the role of >>the "champion" to one of an initial committer who will help build an >>Apache project as it incubates and into being a TLP. >> >>We could scrap the role of shepherd and change the role of mentors. A >>team of 9 mentors would meet monthly to review *all* podlings reports (as >>submitted by the champion). Their responsibility is not to engage with >>the projects but to review the reports crafted by the champion. Any >>follow up actions would be taken by a single mentor and podlings >>(especially the champion) are expected to address the issues raised. >> >>If a champion's priorities change during the course of incubation then >>the project must find another champion (potentially from within their own >>ranks) who is sufficiently qualified and committed to take on the >>responsibility. The important thing is that the Champion is personally >>invested in seeing the podling succeed and acts as a true mentor (as >>opposed to someone with a title and an entry on a web page). The champion >>is still answerable to the podling community. Where conflict arises >>within the community they can call upon the IPMC mentoring team to ask >>for independent guidance. >> >>This model is almost identical to the way the board and TLPs work (where >>Champions are roughly equivalent to PMC Chairs and mentors (nee >>shepherds) are roughly equivalent to Directors and he monthly meeting is >>roughly equivalent to the monthly board meeting to review TLP reports). >>I've designed it this way (and proposed the same solution before)
Re: Incubator report sign-off
And how could the below proposal return without me passing along my comment regarding it - if we’re going to emulate the board and TLPs, etc., why emulate it when we could cut through the middle man and simply rely on the board to do so? I guess to protect the board from an influx of “incubating” projects (+30-40 at this point in time?) I myself as a board member would welcome this. What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. TL;DR 1. Incubation yes, Incubator no a. (all Incubator documentation, active folks, etc., become part of the pool of [incoming project VP]) b. IPMC is dissolved c. We create a new “Incubation PMC” that includes most active members of Incubator currently (those who are good at reviewing releases; watching projects, etc.) 2. All incoming projects are proposed directly as pTLPs (provisional TLPs) - provisional part is defined as: a. 3 members of new Incubation PMC from #1c assigned as PMC and potentially VP of incoming project b. PMC += all incoming folks from proposal c. board VOTEs to approve incoming projects d. project retirement happens same as it currently does, with Attic support To me this would solve the problem of AWOL or mentors who don’t sign off. Mentoring happens via new Incubation PMC who are assigned to the PMCs of incoming pTLPs. Project VP is either one of those Incubation PMC members, or via Ross’s suggestion below, the most active person or “Champion” of the incoming project. The health of these projects are monitored by the Incubation PMC and reported on monthly directly to the board instead of hidden inside the Incubator report each month, without sign off. All of the other problems would seem to go away too IMO. My 2c. Cheers, Chris -Original Message- From: "Ross Gardler (MS OPEN TECH)" Reply-To: "general@incubator.apache.org" Date: Friday, December 19, 2014 at 11:00 AM To: "general@incubator.apache.org" Subject: RE: Incubator report sign-off >Strawman: > >What if a mentor is *required* to be an active participant of the >project. That is contributing code, voting on releases and generally >engaging with the community, they would be a better mentor since they >have a vested interest in the project itself. Sure, we might reduce the >number of projects coming into the foundation but (IMHO) that is not a >problem. Our goal as a foundation is not to be large, it is to be high >quality. > >Maybe we should simply scrap the idea of "mentors" and change the role of >the "champion" to one of an initial committer who will help build an >Apache project as it incubates and into being a TLP. > >We could scrap the role of shepherd and change the role of mentors. A >team of 9 mentors would meet monthly to review *all* podlings reports (as >submitted by the champion). Their responsibility is not to engage with >the projects but to review the reports crafted by the champion. Any >follow up actions would be taken by a single mentor and podlings >(especially the champion) are expected to address the issues raised. > >If a champion's priorities change during the course of incubation then >the project must find another champion (potentially from within their own >ranks) who is sufficiently qualified and committed to take on the >responsibility. The important thing is that the Champion is personally >invested in seeing the podling succeed and acts as a true mentor (as >opposed to someone with a title and an entry on a web page). The champion >is still answerable to the podling community. Where conflict arises >within the community they can call upon the IPMC mentoring team to ask >for independent guidance. > >This model is almost identical to the way the board and TLPs work (where >Champions are roughly equivalent to PMC Chairs and mentors (nee >shepherds) are roughly equivalent to Directors and he monthly meeting is >roughly equivalent to the monthly board meeting to review TLP reports). >I've designed it this way (and proposed the same solution before) because >it is proven to work for TLPs and we have tooling to assist with the >process. > >I look forward to the PMC tearing this strawman proposal apart and (most >importantly) suggesting alternatives and/or tweaks of value. We've been >skirting this issue for far too long. Things have improved (thanks to all >who have worked hard on this), but we have not yet solved the problem. > >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: Friday, December 19, 2014 10:1
