Continuing this line of reasoning I won't be able to mentor _any_ of the projects I've mentored or still mentoring because of different levels of involvements either at my $dayjob or with the organizations that donated the code initially. Is this really an intent of the original proposal to prevent people from they care doing in the open-source? And based on what again?
Cos On Mon, Oct 12, 2015 at 11:14AM, Andrew Purtell wrote: > I would not have been able to mentor Phoenix should it have come along now. > At the time I was not employed by the originator of the project. Later I > chose to join them in part because they contributed the results of their > labor to Apache. My evaluation of how well a podling might be > functioning would not have been in any way different before or after I took > the job. > > > On Mon, Oct 12, 2015 at 10:13 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > > > 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 > > > > > > > > > > > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White)
signature.asc
Description: Digital signature
