On 2/1/2012 5:11 PM, Mattmann, Chris A (388J) wrote: > > On Feb 1, 2012, at 2:25 PM, William A. Rowe Jr. wrote: >> >> I'd modify your proposal just a smidge. Keep an Incubator VP with a very >> small >> operational committee just to help move the podling through the entire >> process >> of wrangling the necessary proposal, votes and board resolutions. Some >> amount >> of process documentation would remain under that VP and their committee. > > I think this modification adds overhead that I think we have already. ComDev > can provide this guidance and I think that's what the natural purpose for it > is.
Simply, there needs to be someone (backed by a committee with specific individual responsibilities, if that person likes) to shepherd state changes into a board resolutions, ensure they hit the board agenda, maintain what we call the 'incubation web site' today, and answer inquiries about 'how do we go about X?' You can suggest that the directors, members and site-dev people take on all of those tasks, but we know that randomly distributed responsibilities don't work out so well. That's why there is now a collection of these VP roles at the ASF. >> Take "VP, Project Incubation" out of the role of judging incoming or >> graduating >> projects. Leave general@ for the process of submitting a proposal to come in >> as an incubating podling or leave by way of graduation, the attic, or >> graveyard >> (full purge in the rare case of questionable IP provenience). >> >> Make every podling a proper PMC to include its mentors. Make a choice >> between >> including all listed initial contributors, or instead, have the mentors >> promote >> the actual contributors given time and merit, based on a well thought out and >> somewhat predictable flowchart. >> >> Have ComDev drive the effort to ensure all projects are nurtured by finding >> new >> mentorship of old, graduated projects as well as incubating projects who had >> lost >> their mentors. This might avoid some cases of the board imposing a full PMC >> reset >> on established projects. >> >> Most importantly, have the voting by the full membership on general@ to >> recommend >> to the board accepting a podling or graduating a podling to a TLP. > > If the full membership is making the recommendation then i see no need for a > VP > Incubator and I think it should be disbanded. However, I agree with your > statements > above and think they jive with my proposal. I view this more as giving the members the opportunity to raise questions and issues of how a particular project proposal would fit here, which is what they do anyways. This only makes it more formal. You keep the VP simply as the record keeper and executor of the decisions on general@. >> Why? Given >> the example of the hotly contested AOO podling, if the membership >> (represented >> by Incubator PMC members) did not ultimately have the discussion that was >> held, >> and if the board had 'imposed' accepting AOO on the foundation, it would have >> done internal harm. Now maybe only 50 of the members care to review >> proposals >> and cast such votes. That's OK, they are still representative of the >> membership. >> If a member wants to gripe on the member's private list, they can be gently >> but >> emphatically nudged to take their concerns to the general@ discussion of the >> proposed project. > > Yes yes yes. Perfect. That's right. Let the membership VOTE for the proposal > and then recommend to the board. That's a great idea. And I guess that would > mean that general@ stays around. I could live with that so long as the VP > Incubator and the IPMC is discharged. As I said, I think they have more than > served their purpose. Well, the scope of general@ shrinks dramatically, although it can continue to be a place for a recently approved project to holler "help, we need more help!". You might view the VP as overlapping the Champion. But do we want every one of the Champions to have to be intimately familiar with the form of the board resolutions, or consolidate some of the book-keeping? 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. I don't see this working without an appointed coordinator. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
