Hey Ross, Thanks for taking the time to reply. Mine are inline below:
-----Original Message----- From: Ross Gardler <rgard...@opendirective.com> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> Date: Saturday, June 15, 2013 3:50 AM To: "general@incubator.apache.org" <general@incubator.apache.org> Subject: Re: [DISCUSS] Merits of pTLP idea >On 14 June 2013 18:11, Mattmann, Chris A (398J) ><chris.a.mattm...@jpl.nasa.gov> wrote: > >> 2. It's harder to discharge a pTLP rather than a podling >> >> Jim, Ross: It's going to be harder to pick up the pieces if pTLPs are >> unsuccessful, than >> it would be for a podling. > >I think that is a misrepresentation of what has been said. > >It's not about "picking up the pieces" it's about providing adequate >mentoring to give a project fighting chance. I guess you and I can agree to disagree that those two different cases don't end up the same result/Net effect -- which they do. >Picking up the pieces >should a project fail is easy. Preventing a project from unnecessarily >failure is less easy. > >I estimate I've worked with something like 50 new project teams over >the years. More than half of them outside the ASF. In my experience >the success or failure of a project (assuming a good engineering team >and a genuinely useful product) is less to do with the people doing >the development work and more to do with the guidance those smart >people get at key decision points relating to the open source model. And I'd estimate that I'd worked with at least that many if not more, both within and inside government, outside in academia, in private industry and others. Based on my experience it's actually more of an even distribution of both -- you can't succeed without the people doing the development work, and you can't succeed without those people being high caliber. Mentorship is key and you need high caliber there too, but I'd expect the balance to be 50/50. > >So it's not about "picking up the pieces" it's about spotting when the >process is failing early enough to fix it and then having the right >vehicle to provide support. In the majority of cases the mentoring >model we have is perfect. It works far more than it fails. When it >fails the problem is ISSUE 01 coupled with 03 (all other issues are >symptoms of those issues in my opinion). pTLP can help address this >but not, in my opinion, when coupled to your larger dismantling >proposal. Ross: pTLP is a *part* of my deconstruction proposal. Stop trying to act like I didn't suggest it -- steps 4/5 in my proposal. I suggested it. Nearly 2 years ago. Further as becomes clear below in your replies, you are also missing the part _where_I_am_agreeing_with_you_about_incremental_steps :) I keep saying my proposal is a series of steps that can be executed incrementally, but when taken together when the dust clears, you will have a dismantled "Incubator" -- not a dismantled "Incubation" process. The process rocks. The mentorship is as best as can be expected when it works. The collective whole of a decision making body of 170 people..doesn't. And it sucks. > >I want to explore pTLP as part of the existing incubation process, not >as a replacement for it. Precisely how that will work requires some >experimentation - hence the Stratos proposal. > >> 3. There isn't any benefit to implementing pTLPs >> Jim: I see no real benefit to implementing pTLPs. >> >> Chris: The benefits would immediately be that they don't have to go in >> front of a 170+ person >> committee to get a decision. > >Chris, podlings that don't hit ISSUE 01 (that's the majority) don't >have to go to the IPMC now. Why are you claiming they do? The process >is one of *notification* that a vote has been conducted not one of >review. If mentors allow the IPMC to get in the way that's a failing >of the mentors not the process. > >In the 18+ projects I've mentored at the ASF we have only ever once >had to request an IPMC member vote. Once. Even then it was painless >because we had a brilliant mentor who had already addressed all the >issues in the release (not me I hasten to add - thanks Ate). Sometimes >it has taken some robust protection of the podling here in the IPMC >lists (take a look at some of my posts relating to AOO for example), >but that's part of the job of a mentor in my opinion. Ross -- look what you just said. You said that one of the big successes you and your podlings have had over the years is keeping those podlings away from the IPMC. Shouldn't that suggest that there is something wrong with the IPMC? There is. I didn't say that there is something wrong with "Incubation" and "Mentors" I said IPMC. Note there is a key legal definition and difference. My proposal (pTLP being an incremental step in it) precisely calls out what you said above as an issue, see the heading titled: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal "Mentors encourage their podlings to operate autonomously" > >In my proposed experiment I want to take the advantages of the pTLP >(specifically it clearly defines the role of the mentors and >encourages faster empowerment of the podling committers and thus >reduces the potential for ISSUE 01 (mentor atrophy) coming into play >and thus ensuring ISSUE 03 (too many cooks) is no longer valid. I am >not interested in using the pTLP concept to solve problems that I do >not believe exist, like the one you discuss above. They do exist. pTLP helps to solve precisely one of the problems that I cited in my original proposal. What you are saying is not different -- you are simply trying out something I suggested nearly 2 years ago. +1. > >> Other benefits would also be in release VOTEs where those doing the >> releases could >> have their VOTEs be binding (which they will anyways) > >As a member of the foundation I only want people who have proven their >ability to do the appropriate due diligence on releases to take on >that responsibility. It takes time to understand both the process and >the need for it. > >This is not a trivial thing, it is the sole reason why the ASF is >trusted and thus why our software is so important. +1. Hence the oversight from 3 experienced ASF members. Let's talk about the makeup of those 3. I would expect in pTLPs that we should have 3 ASF members with the following makeup (YMMV, this came off the top of my head): 1 ASF member/release guru [side benefit: gets the Legal/IP side] 1 ASF member/ra ra/active guy [side benefits: makes sure VOTEs go through] 1 ASF member/shepherd to ComDev/GSoC, etc.: connection to other parts of the foundation > >Do not underestimate this. Whilst academic institutions can afford to >be somewhat lax in their management of IP (yes I have extensive >experience of this) as do I > large corporations with bank balances and >shareholders cannot. It would be irresponsible of the ASF membership >to allow any action which dilutes the the IP management processes. Right, I get that too. > As >a Member I will insist that the Board refrains from taking actions >such as automatically making podling "initial committers" full voting >PMC members (although I very much doubt I'll need to express this >opinion to the Board). > >> The board isn't responsible -- the pTLP ASF >> members are. > >That statement is only true where ISSUE 01 (mentor atrophy) does not >come into play. Agreed. >Regardless of whether you agree with this or >[..snip..] I do. > >I request that when we discuss the merits of the pTLP idea in the >context of Stratos we focus on the pTLP as a part of the existing >incubation project *not* as part of the dismantling proposal. Ross: pTLP *is part of my dismantling proposal*. Steps 4, 5 specifically. > >If someone else wants to argue for pTLP as part of the dismantling >then that's fine. But lets take incremental steps and not let this >discussion get bogged down by one perceived end position - we won't >progress if we take that route again. Once this experiment is complete >then we will have more data upon which to build the next step. That >step may be a step towards dismantling, at which point the argument >about whether ISSUE 01 is fixed or not will become relevant. Ross we're talking circles around each other. Summary: 1. I support pTLP as an incremental step -- I proposed pTLP in my proposal 2 years ago (step 4 and 5) 2. I support Stratos IPMC VOTE now. 3. I support Stratos moving to pTLP. In fact separately I'd like Open Climate Workbench to be considered the same and will put them up in addition to Stratos. 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
