I plan to: 1. Ask the nifi community if they want to be experimental subjects. Can't expect IRB approval without it.
2. Write a proposal for the board to read. There are a number of details to worry over. Any suggestions about where to put it? There in no board wiki. Is there? 3. Submit a board resolution when I think there is a consensus. On Dec 30, 2014 12:24 PM, "Mattmann, Chris A (3980)" < chris.a.mattm...@jpl.nasa.gov> wrote: > Marvin, I completely agree with you - to sum it up - my take on your point > that Apache has a lot of information and guidelines for new podlings > that is somewhat inconsistently brought down to new generations and > those after them of incoming projects. Have a mentor that’s a stickler > for release candidates - you will see projects come out believing that > is the end-all be-all for Apache (“gah, Apache is the communist release > foundation!”). Have a mentor that is a stickler for diversity on incoming > projects, podlings will come out believing there is some rule that a > committee can’t have a majority of contributors from a single organization > (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have > a mentor that’s a stickler for adding anyone that drops by on the mailing > list that says hi (ahem..ducks) you’ll have podlings coming in and new > committees believing in low barriers to committership and PMCship. > > Regardless the above is the ethos of Apache and by and far, it will exist, > IPMC or not. There is no reason that the current f_active(IPMC) = [some > # less than 20] couldn’t simply still exist either in official committee > form (its own; or on the ComDev PMC), and continue to do the same thing. > It’s my belief that the genetic makeup of active IPMC members includes > a few mentors cut from each of the important incoming new project areas > that are important to pass down - legal, release review, community and > participation, etc - and that we should as best as possible try and > have a set of 3 that represents some nice representative cross section of > those skills for the new projects. > > Furthermore, there is nothing stopping anyone from: > > 1. Making ASF members out of anyone that’s part of that active IPMC > list that’s not already a member > 2. Having those ASF members vote in new board members that represent > their views and ethos (including themselves as new board members) > 3. Having those board members be part of checks and bounds to *care* > and review these projects part of our foundation > > Or some subset of the above. > > My point being - IPMC or not - the things you cite below as important > will still exist, since this foundation and its people will, hopefully > for the next 50+ years. > > 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: Marvin Humphrey <mar...@rectangular.com> > Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> > Date: Tuesday, December 30, 2014 at 8:03 AM > To: "general@incubator.apache.org" <general@incubator.apache.org> > Subject: Re: Running an experiment with pTLP > > >On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980) > ><chris.a.mattm...@jpl.nasa.gov> wrote: > >> The structure would still be there - my hypothesis is that the > >> mentors + the board will both uplift structure, and help to identify > >> (more quickly) situations like no report, lack of mentors, etc. > > > >I am skeptical that Apache policies will be applied evenly under such a > >regime. For example, release candidates routinely make it to the full > >IPMC > >vote with binary dependencies embedded in source. Regardless of intent, > >removing final review by the wider IPMC will have the effect of > >liberalizing > >the policy on bundled binary dependencies for those pTLPs who do not > >count any > >sticklers among their Mentors. > > > >Rather than change effective release policy for a minority through > >administrative laxity, the Board should grapple with the full > >implications of > >changing it explicitly for everyone. (Yes, that will turn a huge, gory > >fight > >considering liability, etc.) > > > >Atomizing the IPMC will also yield inconsistency in other areas where > >there is > >either confusion or honest disagreement among the Membership as to what > >our > >policies are, such as provenance documentation requirements for > >contributions > >arriving via Github, or whether PMC chairs are "special". > > > >Nevertheless, +1 to move forward with the "pTLP experiment" (whatever that > >means). Odds are that any given pTLP will work out OK, especially if they > >land one of our better Mentors. But when one messes up, maybe we'll get a > >clarifying post-mortem with the Board in the hot seat and the Incubator > >unavailable as a convenient scapegoat. > > > >No matter how much progress the Incubator makes, people will continue to > >hate > >on it because it's a teacher and front-line enforcer of contentious and > >frustratingly complex Foundation policies. I'm not sure that's a solvable > >problem, because it seems that The Apache Way inherently produces > >sprawling, > >incoherent policy and policy documentation. > > > >Marvin Humphrey > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >For additional commands, e-mail: general-h...@incubator.apache.org > > > >
