Hey Greg, First off, thanks for commenting on this. My replies below:
On Feb 1, 2012, at 6:38 PM, Greg Stein wrote: > On Wed, Feb 1, 2012 at 21:22, Mattmann, Chris A (388J) > <chris.a.mattm...@jpl.nasa.gov> wrote: >> Hi Bill, >> >> On Feb 1, 2012, at 3:26 PM, William A. Rowe Jr. wrote: >> ... >>> VP Project Incubation >>> works with those Champions. Much like the foundation-wide security@a.o team >>> works with all the individual projects as a resource, but isn't responsible >>> for the oversight of individual project security defects. >> >> Yeah, I get what you're saying. You say the VP Incubator is a resource, but >> to me >> the role is the head of a committee that just adds extra burden and overhead >> to >> what should inherently be distributed and decentralized. >> >>> >>> I don't see this working without an appointed coordinator. >> >> >> I do :) just with the coordinating living within the project, just like TLPs, >> and that's the Champion/VP of the podling. > > This proposal creates a differentiation between "normal" TLPs and > "incubating" TLPs. I honestly didn't mean to do that, but I can see how it could be interpreted that way. I don't want to distinguish between them. Let's just say that they are projects like any other projects, with the following principles: 1. In the Incubator proposal used to run by the membership to create the project, at least 3 of the initial PMC members must be ASF members. 2. A proposed VP (or Champion either name is fine with me) should be identified as part of the submitted proposal. That is the PMC chair, until otherwise changed by board resolution just like any other project. > The incubating TLPs have extra restrictions on them > (branding, releases, etc), and they need extra tracking to determine > whether they are ready to graduate. This is true, but in reality they aren't extra restrictions they are simply specific brand guidance, given to any other TLP, along with the special Incubator stuff. > I can easily see a small group of > people maintaining that overall status and recommendation to graduate. > I can see this group shepherding the initial incubating-TLP resolution > to the Board. (a graduation resolution, if needed, could easily be > handled by the TLP itself by graduation time) I can see what you and Bill are saying too and it's not a blocker for me, but I'd urge you to consider the extra overhead that it would add, compared to the benefit of simply saying, the incoming project is simply any other ASF project, has the notion that those 3 ASF members that MUST be on the incoming project's PMC as identified in their proposal. And that those 3 ASF members could come from a collective set of what you guys are saying is this special, reduced IPMC like entity. I'm guessing that organically that's what would happen anyways. Only a small set of ASF members will volunteer to be on these incoming projects and help shepherd them in just the way it works today. > > Mailing lists need somebody to "own" them, too, or they end up in a > weird state. This new-fangled Incubator group would be the owner of > the general@ list where proposals come in and are discussed. Yeah I agree, but can't we say that ComDev "owns" general@incubator after my proposal is implemented? And yes, I forgot to specify this initially well didn't forget, I just didn't think of it, so thanks for you and Bill and for discussion to help flesh it out. I'd like to add that to my proposal. ComDev owns general@incubator. > > The VP of an incubating-TLP has ASF experience, but is otherwise "just > another peer on the PMC" and is the liaison with the Board. I'm not > sure that it makes sense to give them these "extra burden[s]" that > you're talking about. I think it's the same burdens that all VPs get, which is what the projects should be striving for from day 1. We always have this odd situation in the Incubator to date when a new project starts, especially with an elected chair that isn't used to interacting with the board. There's some knowledge that has to be gained, so outright even after graduation the podling has some learning to do under the existing method and so does its VP once it becomes TLP. Let's start that learning, day 1, and get them interacting and just call them regular projects. As Bill stated, before the Incubator, this is what you guys did anyways. I'm just saying let's go back to that in the ASF, WITH the added benefit that now the Incubator over its lifespan has delivered to us, the foundation: 1. a set of awesome guidelines, policies, procedures and documentation. Its new home will be ComDev. ComDev does that anyways like you said, and I agree with that. 2. a process, a great process that new projects coming into the ASF should follow to start operating as ASF TLPs, from the get go. 3. great knowledge and discussion forever archived fleshing out the boundary cases of many of the parts of our foundation. Thank you Incubator for this. That being said, with 1-3, some help from ComDev (which I think they aren't opposed to, but would be happy to cross post, or raise a new thread over there to make sure), and with the existing attitude of many of the IPMC members that care about bringing projects into the foundation (which includes a majority of board members who are also IPMC members, or at least read the Incubator MLs), I think we're fine. No need for the position anymore. Just another report to have to read as a board member, and someone to middle-man, when what the board ought to be doing is talking to the new project's VP, day 1. > Decentralization is good, but I concur with > Bill's analogy to security@ -- a group that helps to start and track > the incubation status of some of our TLPs. I hear what you guys are saying and if it's the only way to get some change around here I'll listen, but I just don't think it's needed. It's another meta- committee, with no purpose. The purpose and deliverables are here, and can go forward and be used. > > By the time a TLP is ready to graduate, they might be self-aware > enough to self-certify, but I'd be more comfortable with an Incubator > group doing the review and recommendation. Can't this just be the membership of the foundation? That's the Incubator group going forward. With 100+ IPMC members, and with the basic tenant today that any ASF member can simply be an IPMC member with an ACK and with 99% of the Incubator PMC being ASF members, I think that naturally follows. > > All this said, I can see an argument to combine this "Incubation" > function/operations with ComDev. Certainly, the latter will have all > the education resources. The question is whether the execution is > distinct or rolled into ComDev. +1, yep you and I are eye to eye on this (and I think on the above too, we're not far off, neither is Bill). We're nearing consensus. Churn a bit on the above and let me know what you think. Peace out. 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
