Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Fri, Feb 3, 2012 at 6:27 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Fri, Feb 3, 2012 at 5:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal As already mentioned by others, instead of deconstructing everything in one go, wouldn't it make more sense to gradually shift into a new way of doing things?... Big +1 to that. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/4/12 12:28 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/3/2012 9:01 PM, Franklin, Matthew B. wrote: Personally, I feel that walking in the door as a full PMC with authority could be just as problematic in the long run as not granting it once the community has demonstrated viability. I think that everyone here agrees. These would not be 'full PMC's... the ASF has a general 'set your own policies, hands off until it's broke' policy towards projects. Nobody is suggesting that an incoming 'project under incubation' would be free of such rules, policies or oversight. Where usual TLP's are free to set the most flexible policies that suit their participants, any project under incubation has a more stringent set of ComDev defined 'best practices' that they must and will follow. If as a full TLP they decide a tweak here or there help their community, it's up to the board to permit that. And generally, the board is flexibly permissive. But with one Champion not of the project itself, but of the ASF, and several additional mentors/overseers/ombudsmen, no incubating effort is going to enjoy the free reign that TLP's have. If only all projects had that sort of supervision, the foundation would be quite secure in knowing that all projects are running as non-factional, non-partisan and non-commercial efforts to create software for the public good. I think the disconnect I was trying to point out is that the proposal itself assumes that the new PMC is fully functional so long as at least 3 ASF members are a part of it and the PMC chair is the champion. Taking Rave as an example, we walked in the door with ~20 non-ASF member PPMC members. Not that it would have happened in our instance, but I can envision a case where a project enters the ASF and isn't forced to understand how things are done here (bad releases, policies, etc). At that point, the board is forced to step in and rectify the situation, when the same outcome could have been avoided by gradually stepping the community up in authority. I have no real opinion as to whether the IPMC stays, or changes structure, or any of the other possibilities discussed; but, I do think there is an important oversight mechanism that can't be lost. If you were to tell me that the incoming PMC would ONLY be comprised of ASF members, and new community members are voted in as they demonstrate an understanding of the Apache Way, then that is a different story. However, that is not what the proposal in the wiki states. Also, if that were to be the case, what happens when the mentors aren't available for release voting (A case that has happened to us 3 times even with 5 ASF member mentors)? Again, I am not saying change isn't important or needed, just that we need to take a breath and look at what we are trying to solve and why. To that end, I intend on putting together a counter proposal and posting it to the wiki that addresses some of the concerns I (and others) have voiced. Good concerns to raise, but i think they are unfounded in light of the current proposal[s]. Bill - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
I've added http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis to the wiki, offering a more or less concrete alternative that is more evolutionary and less revolutionary. Get out your darts, and feel free to edit. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
Benson, I read your proposal. This statement: This leads to my first major qualm about Chris' proposal: everything good, useful, or necessary about the existing PMC is dumped upon ComDev. There is, in my mind, some circularity to the argument here. The incubator is a cesspit, so we should dismantle it. Oh, *that* essential function? ComDev can do it. Is patently not upheld by anything I've written in the proposal and it's flat out wrong. Did you read my proposal? http://wiki.apache.org/incubator/IncubatorDeconstructionProposal If *everything* good, useful, or necessary about the existing PMC is dumped on ComDev, how come they are only responsible for *1* of the *10* transitions of oversight? And the essential function I'm asking ComDev to do is to send an email pointing some newbie to the existing Incubator site, and if they are too lazy to find the right page there, just point them to the main page and let them navigate it themselves. How in the world is that everything good, useful or necessary? And even more, how in the world is that hard? Cheers, Chris P.S. I would have updated your proposal on the wiki, but if you truly believe what you wrote in there, then count me out. On Feb 4, 2012, at 5:48 AM, Benson Margulies wrote: I've added http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis to the wiki, offering a more or less concrete alternative that is more evolutionary and less revolutionary. Get out your darts, and feel free to edit. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
I am +1 to what your proposal does. I am not so fond of the wording of it. I've tried to make changes to eliminate pointing fingers but just couldn't with the last section. I would suggest you take another stab at editing it to: a) make this proposal a general document, not just from you, and b) try to remove as many names as possible. It also might be helpful if the proposal was worded as if Chris' didn't exist. Just document what the process would be and how it solves the problems we have now. Ralph On Feb 4, 2012, at 5:48 AM, Benson Margulies wrote: I've added http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis to the wiki, offering a more or less concrete alternative that is more evolutionary and less revolutionary. Get out your darts, and feel free to edit. - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
Chris, I read your proposal, and I read as lot of other email, and it appears that the results in my head were a bit of a salad. After re-reading your proposal, I will make some mods in a moment and remove that remark in particular. --benson On Sat, Feb 4, 2012 at 11:35 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I am +1 to what your proposal does. I am not so fond of the wording of it. I've tried to make changes to eliminate pointing fingers but just couldn't with the last section. I would suggest you take another stab at editing it to: a) make this proposal a general document, not just from you, and b) try to remove as many names as possible. It also might be helpful if the proposal was worded as if Chris' didn't exist. Just document what the process would be and how it solves the problems we have now. Ralph On Feb 4, 2012, at 5:48 AM, Benson Margulies wrote: I've added http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis to the wiki, offering a more or less concrete alternative that is more evolutionary and less revolutionary. Get out your darts, and feel free to edit. - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
I see that Ralph already removed the worst of my excesses, and I fixed a few others. Are we good? I'm really not in this to win a fight ( -- or an election --) but rather to help the community reach a consensus by stating a (hopefully) clear alternative. On Sat, Feb 4, 2012 at 11:47 AM, Benson Margulies bimargul...@gmail.com wrote: Chris, I read your proposal, and I read as lot of other email, and it appears that the results in my head were a bit of a salad. After re-reading your proposal, I will make some mods in a moment and remove that remark in particular. --benson On Sat, Feb 4, 2012 at 11:35 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I am +1 to what your proposal does. I am not so fond of the wording of it. I've tried to make changes to eliminate pointing fingers but just couldn't with the last section. I would suggest you take another stab at editing it to: a) make this proposal a general document, not just from you, and b) try to remove as many names as possible. It also might be helpful if the proposal was worded as if Chris' didn't exist. Just document what the process would be and how it solves the problems we have now. Ralph On Feb 4, 2012, at 5:48 AM, Benson Margulies wrote: I've added http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis to the wiki, offering a more or less concrete alternative that is more evolutionary and less revolutionary. Get out your darts, and feel free to edit. - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 4, 2012, at 8:51 AM, Benson Margulies wrote: I see that Ralph already removed the worst of my excesses, and I fixed a few others. Are we good? I'm really not in this to win a fight ( -- or an election --) but rather to help the community reach a consensus by stating a (hopefully) clear alternative. I added a chart at the bottom that is similar to Chris' regarding shifts in responsibility with my best guess at what your proposal does. Please review that and edit it as needed. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
Ralph, I'm inclined to hair up the chart to distinguish 'podlings' from 'probationary projects'. Otherwise, fine. I'll do that. On Sat, Feb 4, 2012 at 11:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Feb 4, 2012, at 8:51 AM, Benson Margulies wrote: I see that Ralph already removed the worst of my excesses, and I fixed a few others. Are we good? I'm really not in this to win a fight ( -- or an election --) but rather to help the community reach a consensus by stating a (hopefully) clear alternative. I added a chart at the bottom that is similar to Chris' regarding shifts in responsibility with my best guess at what your proposal does. Please review that and edit it as needed. - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On Sat, Feb 4, 2012 at 1:36 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On Feb 4, 2012, at 8:59 AM, Benson Margulies wrote: Ralph, I'm inclined to hair up the chart to distinguish 'podlings' from 'probationary projects'. Otherwise, fine. I'll do that. I see from your latest updates that you still have the podlings requiring IPMC approval for releases and new members. I suppose that works if are only in the incubator a few months but I can easily imagine a project performing a few releases and still preferring to stay in the incubator while they build community. I'd really prefer to delegate these to the podlings, subject to approval from their mentors and only involve the IPMC if they can't get the required mentor approval. IOW, the vote threads would take place on the podling lists and only the results would be published to the IPMC and the IPMC would use a process similar to the board's for approval (I believe the new process is a 72 hr wait with an implied ack upon receipt). So, here's the difference I'm splitting. For what I hope can be a really brief period of time, the podling is stuck with the IPMC just as podlings are currently stuck with the IPMC. Thereafter, just as in Chris' proposal, off they go to make their own mistakes. The advantage of this, as I see it, is to avoid inventing any new governance structure for the Foundation. Initially, in the IPMC, subsequently, on their own. However, if you and others would rather push this in a direction more like: 'podlings are born self-governing under the supervision of the IPMC, and move to self-governance under the supervision of the board' (I'm thinking a bit of Roy's email) I have no objection at all, feel free to edit it that way. What about the current requirement that mentors be members of the IPMC? Personally, I don't see the value of that, especially for ASF members. The IPMC should be made up of people who care about the incubator as a whole, not just specific podlings. I agree. In either of the alternatives above, there's no reason to load up the IPMC. Ralph - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/4/2012 2:07 PM, William A. Rowe Jr. wrote: [offlist] (sorry, trying to respond individually to keep down the noise, stupid trackpad+palm of my thumb sometimes lets notes fly prematurely. My bad.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
+1 on this. Work the bugs out before everyone transitions. Karl On Fri, Feb 3, 2012 at 12:27 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, [Forking a new thread thread to make this easier to track.] On Fri, Feb 3, 2012 at 5:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal As already mentioned by others, instead of deconstructing everything in one go, wouldn't it make more sense to gradually shift into a new way of doing things? You're proposing that podlings should start as full TLPs (with ASF members on board for mentoring) right from the beginning. Instead of changing the rules on all podlings at the same time, how about we try this out by giving interested podlings (or new proposals) this direct to TLP option? If that works out better than the current Incubator model, we can stop accepting more old-style podlings and just direct them into TLPs right from the beginning. Meanwhile any existing podlings should have a chance to graduate under the existing rules unless they rather choose to use this direct to TLP option. If as a result there's no more podlings in the Incubator, that's IMHO then the right time to shut down the IPMC, not before. And if it turns out that the proposed new model doesn't work as expected, we still have the current processes and structures to fall back to. The current Incubator model certainly has flaws, but it also does a lot of things right. There are good reasons for things like the extra publicity and release constraints placed on podlings, and the proposed model doesn't address how such restrictions would still work without the incubator. I note that many of the original constraints of the Incubator (no releases, etc.) turned out to be unnecessarily strict in practice, so it could well be that everything will work out smoothly also without the extra red tape. But small, reversible steps into such unknown territory are clearly preferable to major leaps of faith. BR, Jukka Zitting - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 11:47 AM, Karl Wright wrote: +1 on this. Work the bugs out before everyone transitions. One doesn't preclude the other. As I wrote in response to an almost entirely different thread, Podlings are accountable to the Incubator PMC. A Project, Incubating would be accountable to the policies of the Incubator VP. Both can co-exist. The documentation is near-identical. One does not have the independent ability to release code, the other does. One changes their composition by notifying IPMC, the other would change their composition by notifying the board. One has no actual titular head, but a vague 'Champion' and several 'Mentors' overseeing the day to day operation and interaction in the project. The other would have a titular head, VP e.g. 'Champion', and several 'Mentors' overseeing the day to day operation and interaction in the project. One goes through a process to have the IPMC ratify that it is ready to be a TLP, and the IPMC presents a resolution to the board to establish a regular project of the ASF, and appointing its first Chair/VP. The other would self-certify the same graduation checklist, and present a resolution to the board to establish a regular project of the ASF, replacing the Project, Incubating committee, and appointing an appropriate Chair/VP (to replace the Champion) at that time. What is missing is the entry documentation into this process, and the exit documentation from this process. This is what I would hope to present to the Board for consideration and generic right track/ wrong track guidance at their February meeting. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Evolution instead of a revolution (Was: Time to vote the chair?)
-Original Message- From: Jukka Zitting [mailto:jukka.zitt...@gmail.com] Sent: Friday, February 03, 2012 12:27 PM To: general@incubator.apache.org Subject: Evolution instead of a revolution (Was: Time to vote the chair?) Hi, [Forking a new thread thread to make this easier to track.] On Fri, Feb 3, 2012 at 5:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal As already mentioned by others, instead of deconstructing everything in one go, wouldn't it make more sense to gradually shift into a new way of doing things? +1 You're proposing that podlings should start as full TLPs (with ASF members on board for mentoring) right from the beginning. Instead of changing the rules on all podlings at the same time, how about we try this out by giving interested podlings (or new proposals) this direct to TLP option? If that works out better than the current Incubator model, we can stop accepting more old-style podlings and just direct them into TLPs right from the beginning. Meanwhile any existing podlings should have a chance to graduate under the existing rules unless they rather choose to use this direct to TLP option. If as a result there's no more podlings in the Incubator, that's IMHO then the right time to shut down the IPMC, not before. And if it turns out that the proposed new model doesn't work as expected, we still have the current processes and structures to fall back to. The current Incubator model certainly has flaws, but it also does a lot of things right. There are good reasons for things like the extra publicity and release constraints placed on podlings, and the proposed model doesn't address how such restrictions would still work without the incubator. I note that many of the original constraints of the Incubator (no releases, etc.) turned out to be unnecessarily strict in practice, so it could well be that everything will work out smoothly also without the extra red tape. But small, reversible steps into such unknown territory are clearly preferable to major leaps of faith. In my year working in an incubator podling, I have come to see that there are a lot of very valuable aspects to the organization; some IMO critical to the success and growth of Apache as a whole. IMHO, any changes made must be cognizant of all aspects of the incubator and not be a reaction to specific pain points. That isn't to say that new things shouldn't be tried and new direction isn't important. Likewise, these revolution style proposals themselves hold value as they explore out-of-the-box approaches that can be incorporated into an evolutionary roadmap or maybe even adopted wholesale if the entire community agrees on the approach. From what I can tell from the 4+ threads, thousands of written words and multitudes of opinions there is a need to address some issues that haven't scaled with the incubator. I think Leo in a different thread attempted to catalog some invariants and desires that highlight these points. I personally favor the evolutionary approach Jukka is suggesting; but I am having a hard time keeping up with where, how and when to participate in these discussions. So that everyone affected by these proposals has the opportunity to engage in the discussion, I recommend that we pull these out of e-mail for a while and ask everyone who has a new plan for the incubator to draft proposals on the wiki as Chris did. At that point, we could have a bake-off discussion where the community has the ability to evaluate and chime in with their concerns/comments/suggestions. Thoughts? BR, Jukka Zitting - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 12:51 PM, Franklin, Matthew B. wrote: So that everyone affected by these proposals has the opportunity to engage in the discussion, I recommend that we pull these out of e-mail for a while and ask everyone who has a new plan for the incubator to draft proposals on the wiki as Chris did. At that point, we could have a bake-off discussion where the community has the ability to evaluate and chime in with their concerns/comments/suggestions. Funny you mention it, the Incubator itself was the product of a bake off between two proposed resolutions, still recorded in the board minutes :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Fri, Feb 3, 2012 at 14:04, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/3/2012 12:51 PM, Franklin, Matthew B. wrote: So that everyone affected by these proposals has the opportunity to engage in the discussion, I recommend that we pull these out of e-mail for a while and ask everyone who has a new plan for the incubator to draft proposals on the wiki as Chris did. At that point, we could have a bake-off discussion where the community has the ability to evaluate and chime in with their concerns/comments/suggestions. Funny you mention it, the Incubator itself was the product of a bake off between two proposed resolutions, still recorded in the board minutes :) http://www.apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 02/03/2012 06:47 PM, Karl Wright wrote: +1 on this. Work the bugs out before everyone transitions. +1 on that Ate Karl On Fri, Feb 3, 2012 at 12:27 PM, Jukka Zittingjukka.zitt...@gmail.com wrote: Hi, [Forking a new thread thread to make this easier to track.] On Fri, Feb 3, 2012 at 5:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal As already mentioned by others, instead of deconstructing everything in one go, wouldn't it make more sense to gradually shift into a new way of doing things? You're proposing that podlings should start as full TLPs (with ASF members on board for mentoring) right from the beginning. Instead of changing the rules on all podlings at the same time, how about we try this out by giving interested podlings (or new proposals) this direct to TLP option? If that works out better than the current Incubator model, we can stop accepting more old-style podlings and just direct them into TLPs right from the beginning. Meanwhile any existing podlings should have a chance to graduate under the existing rules unless they rather choose to use this direct to TLP option. If as a result there's no more podlings in the Incubator, that's IMHO then the right time to shut down the IPMC, not before. And if it turns out that the proposed new model doesn't work as expected, we still have the current processes and structures to fall back to. The current Incubator model certainly has flaws, but it also does a lot of things right. There are good reasons for things like the extra publicity and release constraints placed on podlings, and the proposed model doesn't address how such restrictions would still work without the incubator. I note that many of the original constraints of the Incubator (no releases, etc.) turned out to be unnecessarily strict in practice, so it could well be that everything will work out smoothly also without the extra red tape. But small, reversible steps into such unknown territory are clearly preferable to major leaps of faith. BR, Jukka Zitting - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
-Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Friday, February 03, 2012 2:13 PM To: general@incubator.apache.org Subject: Re: Evolution instead of a revolution (Was: Time to vote the chair?) On Fri, Feb 3, 2012 at 14:04, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/3/2012 12:51 PM, Franklin, Matthew B. wrote: So that everyone affected by these proposals has the opportunity to engage in the discussion, I recommend that we pull these out of e-mail for a while and ask everyone who has a new plan for the incubator to draft proposals on the wiki as Chris did. At that point, we could have a bake-off discussion where the community has the ability to evaluate and chime in with their concerns/comments/suggestions. Funny you mention it, the Incubator itself was the product of a bake off between two proposed resolutions, still recorded in the board minutes :) http://www.apache.org/foundation/records/minutes/2002/board_minutes_ 2002_10_16.txt Interesting. What are your thoughts on using this approach for our current discussion? As I said, staying abreast of all the threads where these discussions are occurring is difficult at best and I feel like some are treating certain ideas as foregone conclusions because the entire community hasn't been given the time and opportunity to engage without joining the melee. In the end, I imagine we will end up compromising, but I think it is important to take a step back and let others propose a few strategies without it adding to the current frenzy. - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On 02/03/2012 08:35 PM, Franklin, Matthew B. wrote: -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Friday, February 03, 2012 2:13 PM To: general@incubator.apache.org Subject: Re: Evolution instead of a revolution (Was: Time to vote the chair?) On Fri, Feb 3, 2012 at 14:04, William A. Rowe Jr.wr...@rowe-clan.net wrote: On 2/3/2012 12:51 PM, Franklin, Matthew B. wrote: So that everyone affected by these proposals has the opportunity to engage in the discussion, I recommend that we pull these out of e-mail for a while and ask everyone who has a new plan for the incubator to draft proposals on the wiki as Chris did. At that point, we could have a bake-off discussion where the community has the ability to evaluate and chime in with their concerns/comments/suggestions. Funny you mention it, the Incubator itself was the product of a bake off between two proposed resolutions, still recorded in the board minutes :) http://www.apache.org/foundation/records/minutes/2002/board_minutes_ 2002_10_16.txt Interesting. What are your thoughts on using this approach for our current discussion? As I said, staying abreast of all the threads where these discussions are occurring is difficult at best and I feel like some are treating certain ideas as foregone conclusions because the entire community hasn't been given the time and opportunity to engage without joining the melee. In the end, I imagine we will end up compromising, but I think it is important to take a step back and let others propose a few strategies without it adding to the current frenzy. Thanks for voicing this Matt, I can't agree more. Last weeks discussions on general@ (and private) really were impossible to follow with everyone jumping the gun or at each others troat, thread hijacking, too many half-baked/refined/opposed/amended/etc. proposals to booth. And it seemed like some were even trying to turn that mess to their advantage by trying to 'force' some conclusions or at least make it seem so. What *is* this rush about, so all of the sudden? There surely is a lot to improve, but rushing into half-backed and not properly thought through radical changes doesn't make sense to me. So, taking a step back, and have the proposers draft up a comprehensible story first, and *please* not on this list but on the wiki, really would be appreciated. Thanks, Ate - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 11:12 AM, Greg Stein wrote: On Fri, Feb 3, 2012 at 14:04, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/3/2012 12:51 PM, Franklin, Matthew B. wrote: So that everyone affected by these proposals has the opportunity to engage in the discussion, I recommend that we pull these out of e-mail for a while and ask everyone who has a new plan for the incubator to draft proposals on the wiki as Chris did. At that point, we could have a bake-off discussion where the community has the ability to evaluate and chime in with their concerns/comments/suggestions. Funny you mention it, the Incubator itself was the product of a bake off between two proposed resolutions, still recorded in the board minutes :) http://www.apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt It is actually interesting reading those resolutions - although to be honest I didn't see much difference between them. I don't really see anything wrong with them. As I see it, the problem with the PMC isn't its charter but how it has chosen to carry it out. For example, requiring mentors to be IPMC members vs ASF members means constantly pinging the board with people who are coming and going who are interested in helping a podling succeed but who aren't really interested in running the incubator. I really see nothing wrong with having an incubator PMC whose job it is to monitor the podlings, make sure they have active mentors, are getting the help they need and then make a decision on graduating or retiring them. However, that PMC doesn't need more than a dozen people on it. Disbanding the PMC seems to me to be a very reactionary approach to the problem. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 5:55 PM, Ralph Goers wrote: Disbanding the PMC seems to me to be a very reactionary approach to the problem. That's because disbanding the IPMC isn't in response to /that/ problem, so little wonder you are confused. Disbanding the IPMC, and making PPMC contributors part of their own committees, gives them voices in a process that they are locked out of. One recent response was to hand pick a select few of the PPMC contributors who went above and beyond, and give these exalted few individual membership in the IPMC, so their votes would be binding. But Roy has always been fond of saying that if you are creating the code you should be the one with voting privileges. All of 'you'. Making each 'podling' an actual committee, with additional restrictions due to their 'freshness' and new exposure to ASF culture, gives the core of each new podling the voice and authority to act on their own code. And /that/ is the problem that we are trying to solve ;) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 4:20 PM, William A. Rowe Jr. wrote: On 2/3/2012 5:55 PM, Ralph Goers wrote: Disbanding the PMC seems to me to be a very reactionary approach to the problem. That's because disbanding the IPMC isn't in response to /that/ problem, so little wonder you are confused. Disbanding the IPMC, and making PPMC contributors part of their own committees, gives them voices in a process that they are locked out of. One recent response was to hand pick a select few of the PPMC contributors who went above and beyond, and give these exalted few individual membership in the IPMC, so their votes would be binding. And who said the IPMC had to fix the problem that way? Why is making a podling effectively a TLP with a PMC that reports to the board and a VP of incubation the only way to fix this? What is preventing us from allowing the PPMC to have much more control over what they do while preserving the IPMC? The rule that says a PMC created by the board has to have 3 votes for a release? This seems like a sledgehammer approach to fix that. After all, all the bylaws say about this is the PMC chair shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible. It would be perfectly reasonable to me for the IPMC to find other ways for a PPMC to have binding votes. But Roy has always been fond of saying that if you are creating the code you should be the one with voting privileges. All of 'you'. Making each 'podling' an actual committee, with additional restrictions due to their 'freshness' and new exposure to ASF culture, gives the core of each new podling the voice and authority to act on their own code. While each podling should be an actual committee, there is no reason they can't be sub-committees of the IPMC with the authority that has been delegated to them. And /that/ is the problem that we are trying to solve ;) I agree with that. I think everyone is saying it is stupid to require mentors to be IPMC members. So fix that. I'd prefer a structure where every PPMC had active and qualified mentors to help with community building and performing a release, and without having to go to the IPMC to add new committers or get a release approved. The purpose of the IPMC would then be to make sure each podling had active and qualified mentors, to add new podlings or terminate dead podlings and recommend graduation to the board. The main problem I see, and what Joe seems to complain about a lot, is that mentors seem to fail at mentoring. Creating a project that reports to the board whose mentors stop mentoring just pushes the problem to the board, which is IMO not what they should be having to deal with. Ralph
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 7:06 PM, Ralph Goers wrote: It would be perfectly reasonable to me for the IPMC to find other ways for a PPMC to have binding votes. I don't see a reasonable alternative structure. Feel free to propose one. I explored the idea of having subcommittees make these releases. That would /still/ mean having the board acknowledge those who are doing the voting, or making a rather complex structure of the board conveying the responsibility for granting code review/approval karma to another body. It all falls back on the board. Right now, we are running two boards, one over incubating efforts and one over 'mature' projects; one is empowering projects and the other emasculating them. This is really quite silly and seems we aught to quit it already. My interest goes beyond any of those topics, though. Incubator is very tedious. Very little is resolved. Deck chairs are shuffled. But at the end of the day, projects don't have ownership of their code, many micro-managers do, we aren't necessarily creating better projects than Chris's proposed structure, and the entire process and participation is simply not enjoyable (except to the sadists or masochists). - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 4 February 2012 01:06, Ralph Goers ralph.go...@dslextreme.com wrote: The main problem I see, and what Joe seems to complain about a lot, is that mentors seem to fail at mentoring. Creating a project that reports to the board whose mentors stop mentoring just pushes the problem to the board, which is IMO not what they should be having to deal with. I agree. This proposal in its current form solves on problem (IPMC inefficiencies) and moves another the problem (inadequate mentoring), I think the problem here is that the supporters of this proposal are diligent and committed mentors. I'm here to tell them that sometimes mentors are not as able to remain focussed in this way. We need to put a safety net in place for the podlings that find themselves lost at sea. The IPMC was created to provide that safety net. Over the years it has become so entangled it is no longer useful. We need to rebuild the safety net, not remove it completely (that doesn't necessarily mean we have to keep the IPMC) Ross I say it is needed. Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 7:19 PM, Ross Gardler wrote: On 4 February 2012 01:06, Ralph Goers ralph.go...@dslextreme.com wrote: The main problem I see, and what Joe seems to complain about a lot, is that mentors seem to fail at mentoring. Creating a project that reports to the board whose mentors stop mentoring just pushes the problem to the board, which is IMO not what they should be having to deal with. I agree. This proposal in its current form solves on problem (IPMC inefficiencies) and moves another the problem (inadequate mentoring), No. The existing problem remains the revised problem. Any solution applicable to the IPMC intervening in a dysfunctional PPMC applies to the Champion and VP, Incubator intervening in a dysfunctional PMC, Incubating. Except that the board is likely to be much less tolerant and much quicker to disband a failed effort that the motley band of IPMC has been. The problem set is identical, and this proposal does not address it any better or worse than the current committee structure. The problem varies in one dimension only; in the IPMC, the general@ comes to the rescue of absent mentors. That won't be possible in the revised structure without the rescuers signing up and committing to mentor the Project, Incubating as PMC members. And since there are many complaints about insufficient commitment, this is probably not a bad thing. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 5:17 PM, William A. Rowe Jr. wrote: On 2/3/2012 7:06 PM, Ralph Goers wrote: It would be perfectly reasonable to me for the IPMC to find other ways for a PPMC to have binding votes. I don't see a reasonable alternative structure. Feel free to propose one. I thought I did. The proposal that Chris put forth seems to make podlings formal PMCs that report to the board simply so they have authority to vote on releases, add new committers, etc.. My proposal is to give podlings the authority to make the releases and add new committers as long as they have approval of their mentors. It doesn't require a change in bylaws or even, so far as I can tell, explicit board approval to do this. It might require someone to change the voting page to clarify that the incubator works differently. Big deal. I explored the idea of having subcommittees make these releases. That would /still/ mean having the board acknowledge those who are doing the voting, or making a rather complex structure of the board conveying the responsibility for granting code review/approval karma to another body. Please point me to anything that says the board has to be involved in any of that. It all falls back on the board. Right now, we are running two boards, one over incubating efforts and one over 'mature' projects; one is empowering projects and the other emasculating them. This is really quite silly and seems we aught to quit it already. Everything falls back on the board. But the board delegates. The IPMC has the authority to delegate, but only what the board has given it ownership of. If desired, the IPMC can propose a resolution to the board to seek explicit approval for the delegation, but I'm not sure even that is required. My interest goes beyond any of those topics, though. Incubator is very tedious. Very little is resolved. Deck chairs are shuffled. But at the end of the day, projects don't have ownership of their code, many micro-managers do, we aren't necessarily creating better projects than Chris's proposed structure, and the entire process and participation is simply not enjoyable (except to the sadists or masochists). As Ross said, while the proposal gets rid of the tediousness it also removes much of the oversight and practically all of the help and support. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 5:27 PM, William A. Rowe Jr. wrote: On 2/3/2012 7:19 PM, Ross Gardler wrote: On 4 February 2012 01:06, Ralph Goers ralph.go...@dslextreme.com wrote: The main problem I see, and what Joe seems to complain about a lot, is that mentors seem to fail at mentoring. Creating a project that reports to the board whose mentors stop mentoring just pushes the problem to the board, which is IMO not what they should be having to deal with. I agree. This proposal in its current form solves on problem (IPMC inefficiencies) and moves another the problem (inadequate mentoring), No. The existing problem remains the revised problem. Any solution applicable to the IPMC intervening in a dysfunctional PPMC applies to the Champion and VP, Incubator intervening in a dysfunctional PMC, Incubating. So why wouldn't the VP, Incubator have a committee to help him? Shoot even the Attic has a committee. Except that the board is likely to be much less tolerant and much quicker to disband a failed effort that the motley band of IPMC has been. The problem set is identical, and this proposal does not address it any better or worse than the current committee structure. Well, to be blunt, that sucks. The problem varies in one dimension only; in the IPMC, the general@ comes to the rescue of absent mentors. That won't be possible in the revised structure without the rescuers signing up and committing to mentor the Project, Incubating as PMC members. And since there are many complaints about insufficient commitment, this is probably not a bad thing. Couldn't disagree more. Getting rid of threads like these would make the list quite useful as podlings could actually ask for help and not have to wade through endless discussions to get it. With the alternative the discussions will be forced to move to members@ or some other obscure list. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 7:40 PM, Ralph Goers wrote: I thought I did. The proposal that Chris put forth seems to make podlings formal PMCs that report to the board simply so they have authority to vote on releases, add new committers, etc.. My proposal is to give podlings the authority to make the releases and add new committers as long as they have approval of their mentors. It doesn't require a change in bylaws or even, so far as I can tell, explicit board approval to do this. It might require someone to change the voting page to clarify that the incubator works differently. Big deal. That's not a proposal the board can ratify at the next board meeting. Try again. It's not all that simple. Give it a shot :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 5:40 PM, Ralph Goers wrote: [...snip...] My interest goes beyond any of those topics, though. Incubator is very tedious. Very little is resolved. Deck chairs are shuffled. But at the end of the day, projects don't have ownership of their code, many micro-managers do, we aren't necessarily creating better projects than Chris's proposed structure, and the entire process and participation is simply not enjoyable (except to the sadists or masochists). As Ross said, while the proposal gets rid of the tediousness it also removes much of the oversight and practically all of the help and support. Umm, no it doesn't. It makes formal what is currently happening and what should be happening in successful projects (and podlings). The help and support is there. There is a sh*t ton of Incubator docs; almost a page for every possible thing you could think of. Ask the current set of RMs on the podlings how easy it is to navigate? And beyond the docs, the safety net is there. You're ignoring that there is a VP for each project, responsible to the board, and there is a PMC for each project that should consist of people that get along and care. And my proposal says 3 of them should be ASF members. If in that sea of membership above for an incoming project, we can't mentor, train, or muster 3 VOTEs, why the hell is the project here at the ASF? Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 7:47 PM, Ralph Goers wrote: On Feb 3, 2012, at 5:27 PM, William A. Rowe Jr. wrote: The existing problem remains the revised problem. Any solution applicable to the IPMC intervening in a dysfunctional PPMC applies to the Champion and VP, Incubator intervening in a dysfunctional PMC, Incubating. So why wouldn't the VP, Incubator have a committee to help him? Shoot even the Attic has a committee. I've stated previously, I believe they will appoint one, with some of the helpful individuals who will ensure things get done. The VP is the one accountable and I'm sure that person would find people to share the load, just as with the Attic. Except that the board is likely to be much less tolerant and much quicker to disband a failed effort that the motley band of IPMC has been. The problem set is identical, and this proposal does not address it any better or worse than the current committee structure. Well, to be blunt, that sucks. No. In all reality, it doesn't. Far too many resources were drained in the past five years on a handful of projects which never had a hope of graduating. An example was Blue Sky. This will force mentors to pick their battles, stand by their battles, and not to completely walk away from them for months at a time. The problem varies in one dimension only; in the IPMC, the general@ comes to the rescue of absent mentors. That won't be possible in the revised structure without the rescuers signing up and committing to mentor the Project, Incubating as PMC members. And since there are many complaints about insufficient commitment, this is probably not a bad thing. Couldn't disagree more. Getting rid of threads like these would make the list quite useful as podlings could actually ask for help and not have to wade through endless discussions to get it. With the alternative the discussions will be forced to move to members@ or some other obscure list. And show me evidence over the past /eight/ years where that has happened? Let's stop hand waving and produce examples and cases we can discuss. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 5:57 PM, William A. Rowe Jr. wrote: On 2/3/2012 7:40 PM, Ralph Goers wrote: I thought I did. The proposal that Chris put forth seems to make podlings formal PMCs that report to the board simply so they have authority to vote on releases, add new committers, etc.. My proposal is to give podlings the authority to make the releases and add new committers as long as they have approval of their mentors. It doesn't require a change in bylaws or even, so far as I can tell, explicit board approval to do this. It might require someone to change the voting page to clarify that the incubator works differently. Big deal. That's not a proposal the board can ratify at the next board meeting. Re-read what I've written. I don't believe the board needs to ratify anything. The IPMC has the ability to re-model itself without requiring a board resolution. What I've suggested is exactly in line with the resolution that was passed in 2002. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 6:01 PM, William A. Rowe Jr. wrote: On 2/3/2012 7:47 PM, Ralph Goers wrote Well, to be blunt, that sucks. No. In all reality, it doesn't. Far too many resources were drained in the past five years on a handful of projects which never had a hope of graduating. An example was Blue Sky. This will force mentors to pick their battles, stand by their battles, and not to completely walk away from them for months at a time. Yes - in reality it does. Your opinion doesn't count more than mine and we can go around in this circle endlessly. Yes, too many resources have been drained but that is only because the IPMC seemed to think it could only operate one way. I have no idea why. You are obviously in favor of Chris' proposal. I'm not. This isn't going to be solved by which of us posts last. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 6:05 PM, William A. Rowe Jr. wrote: On 2/3/2012 7:40 PM, Ralph Goers wrote: My interest goes beyond any of those topics, though. Incubator is very tedious. Very little is resolved. Deck chairs are shuffled. But at the end of the day, projects don't have ownership of their code, many micro-managers do, we aren't necessarily creating better projects than Chris's proposed structure, and the entire process and participation is simply not enjoyable (except to the sadists or masochists). As Ross said, while the proposal gets rid of the tediousness it also removes much of the oversight and practically all of the help and support. One of my problems is that most of the biggest fans of micromanagement and endless debate here at incubator spend nearly no time looking over the graduated projects throughout the foundation to ensure they are being overseen. If that doesn't happen, the ASF will suffer the death of 1000 fractures. This proposal suggests that every project throughout the ASF needs the support of the ASF's members, that incubating projects simply need to pay extra attentions to each and every one of those requirements at first, in order to prove they are likely to succeed. Then they can move on to operating as a full TLP, going back to the very same resources they enjoyed during their incubation during the rough patches. Your statement above could just as easily be applied to having each podling be a subproject of the IPMC (as it is today), but be given the authority and responsibility they are missing today. You don't need to blow away the IPMC to fix this problem. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 6:11 PM, Ralph Goers wrote: On Feb 3, 2012, at 6:05 PM, William A. Rowe Jr. wrote: On 2/3/2012 7:40 PM, Ralph Goers wrote: My interest goes beyond any of those topics, though. Incubator is very tedious. Very little is resolved. Deck chairs are shuffled. But at the end of the day, projects don't have ownership of their code, many micro-managers do, we aren't necessarily creating better projects than Chris's proposed structure, and the entire process and participation is simply not enjoyable (except to the sadists or masochists). As Ross said, while the proposal gets rid of the tediousness it also removes much of the oversight and practically all of the help and support. One of my problems is that most of the biggest fans of micromanagement and endless debate here at incubator spend nearly no time looking over the graduated projects throughout the foundation to ensure they are being overseen. If that doesn't happen, the ASF will suffer the death of 1000 fractures. This proposal suggests that every project throughout the ASF needs the support of the ASF's members, that incubating projects simply need to pay extra attentions to each and every one of those requirements at first, in order to prove they are likely to succeed. Then they can move on to operating as a full TLP, going back to the very same resources they enjoyed during their incubation during the rough patches. Your statement above could just as easily be applied to having each podling be a subproject of the IPMC (as it is today), but be given the authority and responsibility they are missing today. You don't need to blow away the IPMC to fix this problem. So, let me get this straight. Make incoming projects have the authority and responsibility that they are missing today? Sounds a ton like my existing proposal. With some kitchen sink (the IPMC) added in. If incoming projects have the authority and responsibility that they lack have today, there is no IPMC. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/12 9:28 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: On Feb 3, 2012, at 6:11 PM, Ralph Goers wrote: On Feb 3, 2012, at 6:05 PM, William A. Rowe Jr. wrote: On 2/3/2012 7:40 PM, Ralph Goers wrote: My interest goes beyond any of those topics, though. Incubator is very tedious. Very little is resolved. Deck chairs are shuffled. But at the end of the day, projects don't have ownership of their code, many micro-managers do, we aren't necessarily creating better projects than Chris's proposed structure, and the entire process and participation is simply not enjoyable (except to the sadists or masochists). As Ross said, while the proposal gets rid of the tediousness it also removes much of the oversight and practically all of the help and support. One of my problems is that most of the biggest fans of micromanagement and endless debate here at incubator spend nearly no time looking over the graduated projects throughout the foundation to ensure they are being overseen. If that doesn't happen, the ASF will suffer the death of 1000 fractures. This proposal suggests that every project throughout the ASF needs the support of the ASF's members, that incubating projects simply need to pay extra attentions to each and every one of those requirements at first, in order to prove they are likely to succeed. Then they can move on to operating as a full TLP, going back to the very same resources they enjoyed during their incubation during the rough patches. Your statement above could just as easily be applied to having each podling be a subproject of the IPMC (as it is today), but be given the authority and responsibility they are missing today. You don't need to blow away the IPMC to fix this problem. So, let me get this straight. Make incoming projects have the authority and responsibility that they are missing today? Sounds a ton like my existing proposal. With some kitchen sink (the IPMC) added in. If incoming projects have the authority and responsibility that they lack have today, there is no IPMC. Personally, I feel that walking in the door as a full PMC with authority could be just as problematic in the long run as not granting it once the community has demonstrated viability. Having watched the Rave community (and myself) grow into the Apache way under the incubator, I can tell you that we needed time to figure out who we as a community were before we were ready to have any authority. I will also say that we wouldn't have been able to grow as quickly if there wasn't something like this community to watch and engage with as needed. If every project came as essentially a TLP, we lose some of the teaching advantages that the incubator currently offers. I do agree with some of your concerns and feel that we moved through this early phase quickly and were ready to assume some authority; but, I can't say that we were ready day 0. I think your proposal perfectly targets communities that have demonstrated that they are engaging in the Apache Way; but, if you assume that, then what we need is a restructuring of the incubator, not a dismantling of it. In the end, I think you can meet your goals and maybe even reach some approximation of for proposal, so long as you don't forget the valuable parts of the incubator while planning the future. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 6:28 PM, Mattmann, Chris A (388J) wrote: On Feb 3, 2012, at 6:11 PM, Ralph Goers wrote: Your statement above could just as easily be applied to having each podling be a subproject of the IPMC (as it is today), but be given the authority and responsibility they are missing today. You don't need to blow away the IPMC to fix this problem. So, let me get this straight. Make incoming projects have the authority and responsibility that they are missing today? Sounds a ton like my existing proposal. With some kitchen sink (the IPMC) added in. If incoming projects have the authority and responsibility that they lack have today, there is no IPMC. Why? The IPMC's role never should have been about approving membership or releases in the podling. It should be about making sure they are getting sufficient help from the ASF in the form of mentors, legal advice, best practices, community building, etc. Yes, every project needs that but not to the degree a project new to the ASF does. If the mentors go missing or have a situation change where they need to bow out then having an IPMC there to help find new mentors is a much better situation then them simply reporting they are short on mentors to the board. The basic difference here between what you have suggested and what I'm saying is that the VP, Incubator is not an individual trying to do that but a team. It also means that podlings are still not quite full-fledged TLPs but darn close in that the IPMC still may want reports solely so they can determine if any assistance is needed. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On 2/3/2012 9:01 PM, Franklin, Matthew B. wrote: Personally, I feel that walking in the door as a full PMC with authority could be just as problematic in the long run as not granting it once the community has demonstrated viability. I think that everyone here agrees. These would not be 'full PMC's... the ASF has a general 'set your own policies, hands off until it's broke' policy towards projects. Nobody is suggesting that an incoming 'project under incubation' would be free of such rules, policies or oversight. Where usual TLP's are free to set the most flexible policies that suit their participants, any project under incubation has a more stringent set of ComDev defined 'best practices' that they must and will follow. If as a full TLP they decide a tweak here or there help their community, it's up to the board to permit that. And generally, the board is flexibly permissive. But with one Champion not of the project itself, but of the ASF, and several additional mentors/overseers/ombudsmen, no incubating effort is going to enjoy the free reign that TLP's have. If only all projects had that sort of supervision, the foundation would be quite secure in knowing that all projects are running as non-factional, non-partisan and non-commercial efforts to create software for the public good. Good concerns to raise, but i think they are unfounded in light of the current proposal[s]. Bill - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
