Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAJwFCa1D75idz5hsm-=KVkK2UaAG7AtM_nvo1vgB=R=VQD0Crg@mail.gmail.com>
References: <5617D82A.9040809@apache.org>
 <3EE5CBC1-6619-4B9A-83CE-391E2A9987DB@jpl.nasa.gov>
 <D23E728F.49687%chris.a.mattmann@jpl.nasa.gov>
 <CAJwFCa1D75idz5hsm-=KVkK2UaAG7AtM_nvo1vgB=R=VQD0Crg@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Mon, 12 Oct 2015 11:14:47 -0700
Message-ID: 
 <CA+RK=_A9FFC=aEavAVkpZ-3LO_B1WBjjpDG-7G05qaD0EEReQg@mail.gmail.com>
Subject: Re: [DISCUSS] Mentor neutrality policy
To: "general@incubator.apache.org" <general@incubator.apache.org>
Content-Type: multipart/alternative; boundary=001a11401a46564be10521ec501a

--001a11401a46564be10521ec501a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.dunning@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 b=
e
> 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 a=
m
> not going to waste my time.  I care about machine learning and big data a=
nd
> 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 drivi=
ng
> some of the work I do into open source.
>
>
>
> On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
>
> > So here=E2=80=99s 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=E2=80=99ve always had financial ties to a project=E2=
=80=99s
> > 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=E2=80=99ve many times been at the same institution in which
> > the project has originated from before the ASF.
> >
> > I think I=E2=80=99ve done a good job on the projects I=E2=80=99ve helpe=
d to
> > bring here and they have been successful too and have overall
> > benefitted the ASF.
> >
> > This rings to me very similar to Roy=E2=80=99s email circa 2012 I belie=
ve
> > in which in the Incubator we tried to force the diversity requirement
> > as a graduation requirement, and Roy succinctly explained that we
> > can=E2=80=99t punish e.g., a podling for having people all from the sam=
e
> > 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=E2=80=99s 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.mattmann@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.mattmann@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 <humbedooh@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 graduatin=
g
> or
> > >> retiring podlings, so that only people with no organizational (apart=
y
> > >> 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) tha=
t
> 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 Incubat=
or
> > >> 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 o=
f
> > >> mentoring if adopted.
> > >>
> > >> With regards,
> > >> Daniel
> > >>
> > >> --------------------------------------------------------------------=
-
> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> >
>


--=20
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

--001a11401a46564be10521ec501a--