The practical effect on me of this requirement would be that a) I couldn't have mentored Drill
b) I couldn't have mentored Zookeeper (assuming it were to come along now) c) I couldn't mentor Kylin (it affects Drill and MapR customers are considering using it) d) I couldn't mentor Calcite (same as Drill) e) I couldn't mentor Storm (MapR distributes it) f) I couldn't mentor Flink (I am co-writing a book that highlights it) g) I couldn't help with Zeppelin (our SE's use it for demos) h) I couldn't mentor Apex (MapR is a partner of DataTorrent) In fact, I can't think of any project that I have helped out that would be allowable under this policy. Take Julian Hyde and Taylor Goetz as additional examples. They wouldn't be able to help on any of the projects they have been helping on. So I *could* mentor Corinthia. Or some of the projects that I had never heard of and couldn't care less about. Well, that doesn't work because I don't care about those projects and I am not going to waste my time. I care about machine learning and big data and streaming and query languages. That is what drives my choice of work and what drives my choice of open source projects to contribute to. It also leads me to advocate for adoption of those projects at work and for driving some of the work I do into open source. On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) < chris.a.mattm...@jpl.nasa.gov> wrote: > So here’s my elaboration. > > The proposal below would have prevented me from ever helping > projects to the ASF and convincing them that it may be a good > home for them. I’ve always had financial ties to a project’s > Incubation status. In many cases, projects being at the ASF, > and my involvement in them has assisted my mission of doing > scientific research and helping win proposals and so forth for > NASA and other agencies. > > Further, I’ve many times been at the same institution in which > the project has originated from before the ASF. > > I think I’ve done a good job on the projects I’ve helped to > bring here and they have been successful too and have overall > benefitted the ASF. > > This rings to me very similar to Roy’s email circa 2012 I believe > in which in the Incubator we tried to force the diversity requirement > as a graduation requirement, and Roy succinctly explained that we > can’t punish e.g., a podling for having people all from the same > institution. That would punish that institution for hiring folks > for open source who work on code at the ASF. Diversity is always > a strong property of a podling as I feel it makes it more resilient > but it’s not a hard requirement. I feel the same thing in this thread. > > 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: jpluser <chris.a.mattm...@jpl.nasa.gov> > Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> > Date: Friday, October 9, 2015 at 5:14 PM > To: "general@incubator.apache.org" <general@incubator.apache.org> > Subject: Re: [DISCUSS] Mentor neutrality policy > > >I do not agree with this proposal I will elaborate more later > > > >Sent from my iPhone > > > >> On Oct 9, 2015, at 8:07 AM, Daniel Gruno <humbed...@apache.org> wrote: > >> > >> Hi Incubator folks, > >> > >> I would like to propose we adopt a mentor neutrality policy for > >> incubating podlings: > >> > >> - A mentor must not be financially tied to the project or its incubation > >> status. > >> - A mentor must not have a vested interest in incubating, graduating or > >> dismantling a podling that goes beyond the general Apache mission > >> - A mentor must not be affiliated with the entity granting the code > >> (company or original project community) > >> > >> Furthermore, I would like to see this extended to votes on graduating or > >> retiring podlings, so that only people with no organizational (aparty > >> from the ASF) or financial ties to the project (or the companies behind > >> it) can cast a binding vote on graduation or retirement. > >> > >> This would essentially mean: > >> > >> - If you work for a company (or are hired as consultant/advisor) that is > >> entering a project into incubation, you cannot mentor it nor vote > >> for/against its incubation, graduation or retirement. > >> - If you are a in the original community behind the project, you cannot > >> mentor it nor vote for/against it. > >> > >> I believe this would create a neutral mentorship whose sole mission is > >> to guide podlings with the interests of the ASF in mind. > >> > >> > >> Please do discuss this. If there is (mostly) positive feedback, I would > >> like to, at some point, have a vote on including this in the Incubator > >> policy. I realize this would cut down on the number of potential > >> mentors, and I would ask that more people step up to the challenge of > >> mentoring if adopted. > >> > >> With regards, > >> Daniel > >> > >> --------------------------------------------------------------------- > >> 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 > > > >
