Thanks Benson - I would suggest using the Incubator wiki if you need one (but the point about there not being a Board wiki - interesting, would be nice to have one).
At the end of the day the resolution would look like a typical board resolution after Incubator graduation e.g., “Create Apache X”, so it would be summarized as you mention in point #3 below. Cheers and good luck. 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: Benson Margulies <bimargul...@gmail.com> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> Date: Tuesday, December 30, 2014 at 11:12 AM To: "general@incubator apache. org" <general@incubator.apache.org> Subject: Re: Running an experiment with pTLP >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 >> > >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
