Re: [DISCUSS] Mentor neutrality policy

[Ted Dunning]

On Mon, Oct 12, 2015 at 4:02 PM, P. Taylor Goetz  wrote:

> Mentors are, by definition, either:
>
> A) ASF Members
> B) someone who has shown enough understanding of the Apache Way to be
> invited to the IPMC (and should at least be considered for membership,
> IMHO).
>

In at least one case, a mentor has been BOTH of these.

(I'm looking at you Taylor)

Re: [DISCUSS] Mentor neutrality policy

[P. Taylor Goetz]

Mentors are, by definition, either:

A) ASF Members
B) someone who has shown enough understanding of the Apache Way to be invited 
to the IPMC (and should at least be considered for membership, IMHO).

I would think that in either case, they should know how/when/why to check their 
corporate affiliation hat at the door.

If someone can't, or won't, then maybe they should not be an ASF/IPMC member.

I would likely not be able to mentor many projects under the proposed policy.

-1

-Taylor

> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  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

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sun, Oct 11, 2015 at 02:45PM, Pierre Smits wrote:
> Producing good code is a community effort. When it comes down to just the
> mentors fix that themselves, there is something wrong with the community of
> the podling.
> 
> This discussion is not about what participants do with their mentor hat on
> in the podling. I expect we all appreciate what mentors do within the
> podling and how they help out with explanation when a podling is discussed
> in this ML. The discussion is about people wearing two (or more) hats while
> mentoring a podling.
> 
> And yes, the ASF should be wary of mentors pushing their podling toward
> graduation beyond their mentor role. Do the mentors fear podling failure
> (not graduating) so much, that they need a control on both the internal
> process of the podling (e.g. regarding graduation) and the process at IPMC
> level?

At this point, this is all a hearsay. Supporters of the proposal are making an
assumption nearing the base-less accusation of someone putting their
employment or financial affiliation in front of that of Foundation.

It is suboptimal, lacking the implementation mechanism, and finally smells bad
to impose a blanket policy without real ground, but just because "not doing
something isn't a option".

Cos

> Was the whole evalution process not intended to ensure that eyes of others
> than those with a vested interest (and yes graduation success can be regard
> as such) look and decide on the aspects of community diversity/project
> independence/code risk of the podling?
> 
> 
> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
> On Sun, Oct 11, 2015 at 11:48 AM, Mark Struberg  wrote:
> 
> > -1
> >
> > Mentors who have no interest (financially or purely technical doesn’t
> > matter in the end) will not find enough time to _really_ look into the
> > projects health.
> >
> > Be honest with yourself: how much do you look into the code if you are not
> > working on it yourself? How could you then detect that code is
> > bulk-imported from another project (I‚ve even seen LGPLed code slip in).
> > And this doesn’t happen because people want us something bad. They often
> > simply don’t know how much the ASF cares about code provenance and legal
> > things. That’s an important part in the mentor work. And you cannot do this
> > if you are only somehow loosely checking the project every other month.
> >
> > Or do you fear a mentor will push through his own ‚baby‘ with knowingly
> > ignoring ASF rules?
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 09.10.2015 um 17:07 schrieb Daniel Gruno :
> > >
> > > 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
> >
> >


signature.asc
Description: Digital signature

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sun, Oct 11, 2015 at 06:52PM, Reto Gmür wrote:
> On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
> wrote:
> 
> > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno  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.
> >
> > I'm very strongly -1 on this for two reasons. One fundamental
> > and one operational. Fundamentally, this goes against a core
> > ASF principle that we all collaborate here as individuals by
> > checking our corporate affiliation at the door.
> 
> 
> I think it's naive to think that just because the members are individual
> and corporate affiliations don't formally play a role there is no influence
> by the employer. When I'm paid by a company or government agency to work on
> an apache project I don't have an effective protection against the
> directives of my employer. Maybe if I refuse to follow an employer's
> instruction to write some code for an Apache project of which I'm committer
> I could not be fired without notice, maybe I could write the patch and say
> on the list that I wrote this patch for my employer but that as an
> individual PMC member I vote against it (did something like this ever
> happen?), whichever way I'm likely to act against my financial interest.
> 
> In medical journals the author's are also writing in their own name, yet
> they must declare all competing interests. Following your logic such as
> declaration would be unnecessary if the journal says somewhere that authors
> leave their affiliation at the door.

That's a straw-man argument.

Unlike people writing for the medical journals who're working for the, sadly,
the most regulated industry ever and making millions if their research happen
to be acknowledged as promising, even when harmful, Apache contributors are
_individual volunteers_ developing the software for public consumption. And
you _have_ to leave your affiliation elsewhere when you're wearing your Apache
hat. Hence your affiliation is of no relevance here.

Cos

> > IOW, we are explicitly granting our members and committers the trust
> > required to make sure they do the right thing while they themselves (or
> > their employees) can significantly benefit (financially and otherwise) from
> > the projects.
> >
> 
> Even if we trust our commiters that they do not commit a hidden back door
> on behalf of the spy agency they work for, the conflict of interest can be
> much more subtle. The company has a deadline and a release of an apache
> project before that deadline would come in very handy, will you scrutinize
> the notice files at the risk of finding something that delays the release?
> 
> If a main customer of my consulting firm is the main promoter of the XY
> file format, will I by neutral in choosing the best file format for the
> Apache Project I'm involved in? I probably really believe that XY is the
> way to go, but is should be an Apache rule that I declare that I have some
> financial ties to it.
> 
> 
> >
> > This is what makes ASF unique and anything that goes even slightly
> > in the direction of reducing this level of trust will have me up in arms
> > (regardless of whether it is related to Incubator or not).
> >
> > Operationally, this is extremely tricky to enforce. I speak here
> > from experience of somebody who has to be appreciative of the same
> > set of issues while consulting for companies and yet working for my
> > current employer. Even in a corporate world (where stakes are much
> > higher from legal perspective) this typically gets handled by trusting
> > the individual to do the right thing and disclose any potential conflict
> > of interest (financial or otherwise).
> >
> 
> We would not have to ask people for their tax declaration, a self
> declaration of any potentially competing interest would do.
> 
> Cheers,
> Reto


signature.asc
Description: Digital signature

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

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  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/
> > > +++

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

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  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 
> > Reply-To: "general@incubator.apache.org" 
> > Date: Friday, October 9, 2015 at 5:14 PM
> > To: "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 
> wrote:
> > >>
> > >> Hi Incubator folks,
> > >>
> > >> I would like to 

Re: [DISCUSS] Mentor neutrality policy

[Ted Dunning]

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 
> Reply-To: "general@incubator.apache.org" 
> Date: Friday, October 9, 2015 at 5:14 PM
> To: "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  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:
> >>

Re: [DISCUSS] Mentor neutrality policy

[Jim Jagielski]

But it is basically *core* to who and what we are.

> On Oct 12, 2015, at 10:52 AM, Marko Rodriguez  wrote:
> 
> Hi,
> 
>> We hope and trust mentors to wear their hats well.
> 
> This quote from a colleague of mine has always stuck with me:
> 
>   "Hope is not a strategy."
> 
> Take care,
> Marko.
> 
> http://markorodriguez.com
> 
> 
>> 
>>> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  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
>> 
> 
> 
> -
> 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

Re: [DISCUSS] Mentor neutrality policy

[Marko Rodriguez]

Hi,

> We hope and trust mentors to wear their hats well.

This quote from a colleague of mine has always stuck with me:

"Hope is not a strategy."

Take care,
Marko.

http://markorodriguez.com


> 
>> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  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
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Jim Jagielski]

I understand your concern but, at present, I don't see it
being an issue nor something that we need worry about.

We hope and trust mentors to wear their hats well.

> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  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

Re: [DISCUSS] Mentor neutrality policy

[Reto Gmür]

That work under the assumption that all Jane has to deliver is a working
software. If the company is also interested in increasing its reputation by
allowing their marketing department to say thing like "We initiated the
Apache Foobar project", or "Apache OpenOffice natively supports our file
format" things become a bit more nuanced. Joining an existing community
might be more efficient code wise but less efficient marketing wise.

To bring a real example I was myself involved in: the incubation of Apache
Stanbol. Apache Stanbol comes out of a European Union funded research and
innovation project where multiple companies and research institutions where
involved. Graduating before the end of the funding period was clearly in
the interest of the project partners as this clearly was a success to
report at the final review meeting. On the other hand it might have been
better to wait till after the end of the funding period to decide on
graduation as this would have allowed to see which part of the code are
still maintained even without the funding. Without the financial/reputation
interest arising from the ongoing funded research the comparative
motivation of having the actually needed code in sustainable communities
would have been greater.

Cheers,
Reto



On Sun, Oct 11, 2015 at 10:29 PM, Ross Gardler 
wrote:

> I blogged on this topic some time ago - basically it is my opinion that if
> I am a good employee I would never try to contribute code to an Apache
> project that is not beneficial to the broader community. Such an action
> would be detrimental to her employers business. Consequently, there is no
> conflict between employer needs and community needs an ASF project.
>
> Here's a relevant excerpt:
>
> "Jane is paid to deliver results for her employer. If Jane finds that the
> best route to delivery is through community led open source she ought to
> fight for the survival of that community at all costs. It is in her
> interests to do so, both for her community reputation (employability beyond
> her current role) and for her employers satisfaction (employability in her
> current role). If Jane blows her community reputation she loses her ability
> to deliver for her employer as well as her ability to seek alternative
> employment relating to that community’s activities. A double whammy."
>
> Full blog at
> http://www.computerworlduk.com/blogs/apache-asserts/apache-openoffice-can-i-depend-on-software-built-by-volunteers--3570412/
>
> -Original Message-
> From: Reto Gmür [mailto:r...@apache.org]
> Sent: Sunday, October 11, 2015 9:53 AM
> To: general 
> Subject: Re: [DISCUSS] Mentor neutrality policy
>
> On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
> wrote:
>
> > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno 
> 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.
> >
> > I'm very strongly -1 on this for two reasons. One fundamental and one
> > operational. Fundamentally, this goes against a core ASF principle
> > that we all collaborate here as individuals by checking our corporate
> > affiliation at the door.
>
>
> I think it's naive to think that just because the members are individual
> and corporate affiliations don't formally play a role there is no influence
> by the employer. When I'm paid by a company or government agency to work on
> an apache project I don't have an effective protection against the
> directives of my employer. Maybe if I refuse to follow an employer's
> instruction to write some code for an Apache project of which I'm committer
> I could not be fired without notice, maybe I could write the patch and say
> on the list that I wrote this patch for my employer but that as an
> individual PMC member I vote against it (did something like this ever
> happen?), whichever way I'm likely to act against my financial interest.
>
> In medical journals the author's are also writing in their own name, yet
> they must declare all competing interests. Following your logic such as
> declaration would be unnecessary if the journal says somewhere that authors
> leave their affiliation at the door.
>
>
>
> > IOW, we are explicitly granting our members and committers the trust
> > required to make sure they do the right thing while they themselves
> > (or their employees) can significantly benefit (financially and
> > otherwise) from the projects.
> >
>
> Even if we trust our commiters that they do not commit a hidden back door
> on behalf 

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

I said *better* not *more*

-Original Message-
From: Alan D. Cabrera [mailto:l...@toolazydogs.com] 
Sent: Sunday, October 11, 2015 2:34 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentor neutrality policy


> On Oct 9, 2015, at 8:36 AM, Ross Gardler  wrote:
> 
> Personally I would focus more on better oversight of podling and mentor 
> activity. The goal is to catch the occasional problem case rather than put 
> restrictions in place. I'm not sure how to do that though. I and others have 
> made many suggestions over the years. They can be found here 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwiki.apache.org%2fincubator%2fIncubatorIssues2013&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c4cfeaa7504884d70efa608d2d283c20b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XT5hhkPTaOjf68%2bBLa3fV7bfz9zWJSDvmoR8YQXkjcY%3d
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwiki.apache.org%2fincubator%2fIncubatorIssues2013&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c4cfeaa7504884d70efa608d2d283c20b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XT5hhkPTaOjf68%2bBLa3fV7bfz9zWJSDvmoR8YQXkjcY%3d>
>  (you might want to add your proposal there).

Even more oversight?  We already have a role that provides oversight of the 
shepherds who provide oversight of the mentors who provide oversight of the 
podling.  Spreading responsibility for getting something done is a sure way to 
make sure that it does not get done.  Just my 2 cents.


Regards,
Alan


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Nikita Ivanov]

+100 on what Ross said. Couldn't said it better (read his blog).
--
Nikita Ivanov


On Sun, Oct 11, 2015 at 1:29 PM, Ross Gardler 
wrote:

> I blogged on this topic some time ago - basically it is my opinion that if
> I am a good employee I would never try to contribute code to an Apache
> project that is not beneficial to the broader community. Such an action
> would be detrimental to her employers business. Consequently, there is no
> conflict between employer needs and community needs an ASF project.
>
> Here's a relevant excerpt:
>
> "Jane is paid to deliver results for her employer. If Jane finds that the
> best route to delivery is through community led open source she ought to
> fight for the survival of that community at all costs. It is in her
> interests to do so, both for her community reputation (employability beyond
> her current role) and for her employers satisfaction (employability in her
> current role). If Jane blows her community reputation she loses her ability
> to deliver for her employer as well as her ability to seek alternative
> employment relating to that community’s activities. A double whammy."
>
> Full blog at
> http://www.computerworlduk.com/blogs/apache-asserts/apache-openoffice-can-i-depend-on-software-built-by-volunteers--3570412/
>
> -Original Message-
> From: Reto Gmür [mailto:r...@apache.org]
> Sent: Sunday, October 11, 2015 9:53 AM
> To: general 
> Subject: Re: [DISCUSS] Mentor neutrality policy
>
> On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
> wrote:
>
> > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno 
> 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.
> >
> > I'm very strongly -1 on this for two reasons. One fundamental and one
> > operational. Fundamentally, this goes against a core ASF principle
> > that we all collaborate here as individuals by checking our corporate
> > affiliation at the door.
>
>
> I think it's naive to think that just because the members are individual
> and corporate affiliations don't formally play a role there is no influence
> by the employer. When I'm paid by a company or government agency to work on
> an apache project I don't have an effective protection against the
> directives of my employer. Maybe if I refuse to follow an employer's
> instruction to write some code for an Apache project of which I'm committer
> I could not be fired without notice, maybe I could write the patch and say
> on the list that I wrote this patch for my employer but that as an
> individual PMC member I vote against it (did something like this ever
> happen?), whichever way I'm likely to act against my financial interest.
>
> In medical journals the author's are also writing in their own name, yet
> they must declare all competing interests. Following your logic such as
> declaration would be unnecessary if the journal says somewhere that authors
> leave their affiliation at the door.
>
>
>
> > IOW, we are explicitly granting our members and committers the trust
> > required to make sure they do the right thing while they themselves
> > (or their employees) can significantly benefit (financially and
> > otherwise) from the projects.
> >
>
> Even if we trust our commiters that they do not commit a hidden back door
> on behalf of the spy agency they work for, the conflict of interest can be
> much more subtle. The company has a deadline and a release of an apache
> project before that deadline would come in very handy, will you scrutinize
> the notice files at the risk of finding something that delays the release?
>
> If a main customer of my consulting firm is the main promoter of the XY
> file format, will I by neutral in choosing the best file format for the
> Apache Project I'm involved in? I probably really believe that XY is the
> way to go, but is should be an Apache rule that I declare that I have some
> financial ties to it.
>
>
> >
> > This is what makes ASF unique and anything that goes even slightly in
> > the direction of reducing this level of trust will have me up in arms
> > (regardless of whether it is related to Incubator or not).
> >
> > Operationally, this is extremely tricky to enforce. I speak here from
> > experience of somebody who has to be appreciative of the same set of
> > issues while consulting for companies and yet working for my current
> > employer. Even in a corporate world (where stakes are much higher from
> > legal perspective) this typically gets handled by trusting the
> > individual to do the right thing and disclose any potential conflict
> > of interest (financial or otherwise).
> >
>
> We would not have to ask people for their tax declaration, a self
> declaration of any potentially competing interest would do.
>
> Cheers,
> Reto
>

Re: [DISCUSS] Mentor neutrality policy

[Shane Curcuru]

Daniel Gruno wrote on 10/9/15 3:18 PM:
> On 10/09/2015 08:02 PM, Sam Ruby wrote:
>> On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
>>  wrote:
>>> Hi,
>>>
>>> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
 ...Furthermore, I would like to see this extended to votes on graduating or
 retiring podlings,..
>>>
>>> IMO this is where independence is important. We could require that 3
>>> "organizationally independent" IPMC members review each podling before
>>> graduating or retiring. Those people do not need to be project
>>> mentors.
>>
>> I much prefer a formulation of "3 independent" over "no financial
>> ties", and would prefer such a criteria be considered whenever the
>> impulse arises to ensure that NO involved individual has a vested
>> interest.
... snip...

For me, the point is that as a whole organization we truly have the
documented oversight of a sufficient number and variety of Mentors to
provide independent oversight.

The details are indeed tricky to work out.  I personally don't mind if
some mentors casting binding votes are tied to the project (and that
indeed does make for more engaged mentors). But we definitely need some
mentors from other employers or organizations or something to also have
a more robust assurance of an independent view.

- Shane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Alan D. Cabrera]

> On Oct 9, 2015, at 12:18 PM, Daniel Gruno  wrote:
> 
> I would imagine no one would object to a policy that says you cannot
> have a binding vote if you have a financial interest in graduating a
> podling,

I would.  People on the IPMC and ASF are supposed to be trustworthy out of the 
gate.

If you have specific problems with specific mentors then bring it up w/ the 
IPMC or IPMC VP privately.  Let’s not spray even more rules and bureaucracy 
into the Incubator.


Regards,
Alan

Re: [DISCUSS] Mentor neutrality policy

[Alan D. Cabrera]

> On Oct 9, 2015, at 11:02 AM, Sam Ruby  wrote:
> 
> On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
>  wrote:
>> Hi,
>> 
>> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
>>> ...Furthermore, I would like to see this extended to votes on graduating or
>>> retiring podlings,..
>> 
>> IMO this is where independence is important. We could require that 3
>> "organizationally independent" IPMC members review each podling before
>> graduating or retiring. Those people do not need to be project
>> mentors.
> 
> I much prefer a formulation of "3 independent" over "no financial
> ties", and would prefer such a criteria be considered whenever the
> impulse arises to ensure that NO involved individual has a vested
> interest.
> 
> I'll go further and say that financial interests are but one way in
> which individuals have a vested interest in the success of a project,
> and echoing a statement by Ross -- having a vested interest is not a
> bad thing.
> 
> Finally, I would prefer a model whereby those that have achieved ASF
> member status are given the benefit of the doubt in matters involving
> a group vote when it comes to their ability to separate their ASF role
> from their relationship with their employee.  Nothing wrong with still
> requiring 3 completely independent votes, but having a rule that
> excludes participation by those that have demonstrated their merit as
> ASF members just seems wrong.


IMO, adding more policy of this sort does not address the core concerns that 
Daniel details in his proposal, i.e. MIA mentors.  Let’s not rush to add more 
bureaucracy and rules.


Regards,
Alan


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Alan D. Cabrera]

I’m -1 on on this.  The whole premise of the ASF is that it is a meritocracy 
and that volunteers at various “levels” of the organization have attained their 
status because they are trustworthy.  Without this premise, the ASF falls apart.

Finally, it’s not clear to me that this addresses the problem of MIA mentors.  
If they were supposedly tied in some manner to the incubation and graduation of 
a podling,  then they are definitely active during its incubation; I have no 
problem with that because in my book, they are trustworthy.

I’ve made proposals to solve the problems listed below, the causes of which 
are, imo, volunteerism and a free ride into a project and its PMC.  My proposal 
was after 3 missed votes, the mentor is automatically removed with simple 
no-fuss reinstatement procedures should the mentor wish to redeem themselves.  
Mentors cannot stay with the podling when it graduates.


Regards,
Alan

> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  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
> 

Re: [DISCUSS] Mentor neutrality policy

[Alan D. Cabrera]

> On Oct 9, 2015, at 8:36 AM, Ross Gardler  wrote:
> 
> Personally I would focus more on better oversight of podling and mentor 
> activity. The goal is to catch the occasional problem case rather than put 
> restrictions in place. I'm not sure how to do that though. I and others have 
> made many suggestions over the years. They can be found here 
> http://wiki.apache.org/incubator/IncubatorIssues2013 
>  (you might want to add 
> your proposal there).

Even more oversight?  We already have a role that provides oversight of the 
shepherds who provide oversight of the mentors who provide oversight of the 
podling.  Spreading responsibility for getting something done is a sure way to 
make sure that it does not get done.  Just my 2 cents.


Regards,
Alan

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

I blogged on this topic some time ago - basically it is my opinion that if I am 
a good employee I would never try to contribute code to an Apache project that 
is not beneficial to the broader community. Such an action would be detrimental 
to her employers business. Consequently, there is no conflict between employer 
needs and community needs an ASF project. 

Here's a relevant excerpt:

"Jane is paid to deliver results for her employer. If Jane finds that the best 
route to delivery is through community led open source she ought to fight for 
the survival of that community at all costs. It is in her interests to do so, 
both for her community reputation (employability beyond her current role) and 
for her employers satisfaction (employability in her current role). If Jane 
blows her community reputation she loses her ability to deliver for her 
employer as well as her ability to seek alternative employment relating to that 
community’s activities. A double whammy."

Full blog at 
http://www.computerworlduk.com/blogs/apache-asserts/apache-openoffice-can-i-depend-on-software-built-by-volunteers--3570412/

-Original Message-
From: Reto Gmür [mailto:r...@apache.org] 
Sent: Sunday, October 11, 2015 9:53 AM
To: general 
Subject: Re: [DISCUSS] Mentor neutrality policy

On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
wrote:

> On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno  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.
>
> I'm very strongly -1 on this for two reasons. One fundamental and one 
> operational. Fundamentally, this goes against a core ASF principle 
> that we all collaborate here as individuals by checking our corporate 
> affiliation at the door.


I think it's naive to think that just because the members are individual and 
corporate affiliations don't formally play a role there is no influence by the 
employer. When I'm paid by a company or government agency to work on an apache 
project I don't have an effective protection against the directives of my 
employer. Maybe if I refuse to follow an employer's instruction to write some 
code for an Apache project of which I'm committer I could not be fired without 
notice, maybe I could write the patch and say on the list that I wrote this 
patch for my employer but that as an individual PMC member I vote against it 
(did something like this ever happen?), whichever way I'm likely to act against 
my financial interest.

In medical journals the author's are also writing in their own name, yet they 
must declare all competing interests. Following your logic such as declaration 
would be unnecessary if the journal says somewhere that authors leave their 
affiliation at the door.



> IOW, we are explicitly granting our members and committers the trust 
> required to make sure they do the right thing while they themselves 
> (or their employees) can significantly benefit (financially and 
> otherwise) from the projects.
>

Even if we trust our commiters that they do not commit a hidden back door on 
behalf of the spy agency they work for, the conflict of interest can be much 
more subtle. The company has a deadline and a release of an apache project 
before that deadline would come in very handy, will you scrutinize the notice 
files at the risk of finding something that delays the release?

If a main customer of my consulting firm is the main promoter of the XY file 
format, will I by neutral in choosing the best file format for the Apache 
Project I'm involved in? I probably really believe that XY is the way to go, 
but is should be an Apache rule that I declare that I have some financial ties 
to it.


>
> This is what makes ASF unique and anything that goes even slightly in 
> the direction of reducing this level of trust will have me up in arms 
> (regardless of whether it is related to Incubator or not).
>
> Operationally, this is extremely tricky to enforce. I speak here from 
> experience of somebody who has to be appreciative of the same set of 
> issues while consulting for companies and yet working for my current 
> employer. Even in a corporate world (where stakes are much higher from 
> legal perspective) this typically gets handled by trusting the 
> individual to do the right thing and disclose any potential conflict 
> of interest (financial or otherwise).
>

We would not have to ask people for their tax declaration, a self declaration 
of any potentially competing interest would do.

Cheers,
Reto

Re: [DISCUSS] Mentor neutrality policy

[Ralph Goers]

Is there something else going on that I am not aware of?  Is someone using 
undue influence where they shouldn’t be? 

On the Legal list dealing with hypothetical situations is continually avoided. 
While a code of conduct for mentors might make sense, penalizing mentors who 
are trying to educate and really help a new project seen heavy handed.

Without a real use case I think this whole discussion is a solution looking for 
a problem and should be tabled.

Ralph


> On Oct 11, 2015, at 6:47 AM, Daniel Gruno  wrote:
> 
> On 10/11/2015 03:44 PM, John D. Ament wrote:
>> On Sun, Oct 11, 2015 at 9:36 AM Daniel Gruno  wrote:
>> 
>>> On 10/11/2015 03:34 PM, Mark Struberg wrote:
 
> Am 11.10.2015 um 14:45 schrieb Pierre Smits :
> 
> Producing good code is a community effort. When it comes down to just
>>> the
> mentors fix that themselves, there is something wrong with the
>>> community of
> the podling.
 
 I never questioned that.
 
 But the proposal sounds that a mentor _must not_ contribute to the
>>> project itself but just mentor it.
 And I personally question if this is efficient and we would get enough
>>> mentors in that case.
>>> 
>>> The proposal was changed to address that concern. see
>>> <56181303.7000...@apache.org>
>>> 
>> 
>> And how does one access this?
>> 
> 
> Sorry, I just posted the Message ID. It can be found on the
> mail-archives or through our Pony Mail PoC site at
> https://pony-poc.apache.org/thread.html/87bfb7d68294f0872f524b5418f5369a388b3128ff00d53b25df07f0@118307@%3Cgeneral.incubator.apache.org%3E
>  
> 
> 
> With regards,
> Daniel.
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
> 
> For additional commands, e-mail: general-h...@incubator.apache.org 
> 

Re: [DISCUSS] Mentor neutrality policy

[Reto Gmür]

On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
wrote:

> On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno  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.
>
> I'm very strongly -1 on this for two reasons. One fundamental
> and one operational. Fundamentally, this goes against a core
> ASF principle that we all collaborate here as individuals by
> checking our corporate affiliation at the door.


I think it's naive to think that just because the members are individual
and corporate affiliations don't formally play a role there is no influence
by the employer. When I'm paid by a company or government agency to work on
an apache project I don't have an effective protection against the
directives of my employer. Maybe if I refuse to follow an employer's
instruction to write some code for an Apache project of which I'm committer
I could not be fired without notice, maybe I could write the patch and say
on the list that I wrote this patch for my employer but that as an
individual PMC member I vote against it (did something like this ever
happen?), whichever way I'm likely to act against my financial interest.

In medical journals the author's are also writing in their own name, yet
they must declare all competing interests. Following your logic such as
declaration would be unnecessary if the journal says somewhere that authors
leave their affiliation at the door.



> IOW, we are explicitly granting our members and committers the trust
> required to make sure they do the right thing while they themselves (or
> their employees) can significantly benefit (financially and otherwise) from
> the projects.
>

Even if we trust our commiters that they do not commit a hidden back door
on behalf of the spy agency they work for, the conflict of interest can be
much more subtle. The company has a deadline and a release of an apache
project before that deadline would come in very handy, will you scrutinize
the notice files at the risk of finding something that delays the release?

If a main customer of my consulting firm is the main promoter of the XY
file format, will I by neutral in choosing the best file format for the
Apache Project I'm involved in? I probably really believe that XY is the
way to go, but is should be an Apache rule that I declare that I have some
financial ties to it.


>
> This is what makes ASF unique and anything that goes even slightly
> in the direction of reducing this level of trust will have me up in arms
> (regardless of whether it is related to Incubator or not).
>
> Operationally, this is extremely tricky to enforce. I speak here
> from experience of somebody who has to be appreciative of the same
> set of issues while consulting for companies and yet working for my
> current employer. Even in a corporate world (where stakes are much
> higher from legal perspective) this typically gets handled by trusting
> the individual to do the right thing and disclose any potential conflict
> of interest (financial or otherwise).
>

We would not have to ask people for their tax declaration, a self
declaration of any potentially competing interest would do.

Cheers,
Reto

Re: [DISCUSS] Mentor neutrality policy

[Niall Pemberton]

I'm -1 on this.

We have people working for companies who have a vested interest probably on
most PMC's at Apache and why should we have a different set of rules for
the Incubator PMC than any other PMC? If there is a specific concerns that
an individual is acting against the ASF's best interest, then raise it -
but don't lets prevent those who have put in the effort from having a vote.
That goes against the do-ocracy culture here.

Niall



On Fri, Oct 9, 2015 at 4:07 PM, Daniel Gruno  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
>
>

Re: [DISCUSS] Mentor neutrality policy

[John D. Ament]

On Sun, Oct 11, 2015 at 9:47 AM Daniel Gruno  wrote:

> On 10/11/2015 03:44 PM, John D. Ament wrote:
> > On Sun, Oct 11, 2015 at 9:36 AM Daniel Gruno 
> wrote:
> >
> >> On 10/11/2015 03:34 PM, Mark Struberg wrote:
> >>>
>  Am 11.10.2015 um 14:45 schrieb Pierre Smits :
> 
>  Producing good code is a community effort. When it comes down to just
> >> the
>  mentors fix that themselves, there is something wrong with the
> >> community of
>  the podling.
> >>>
> >>> I never questioned that.
> >>>
> >>> But the proposal sounds that a mentor _must not_ contribute to the
> >> project itself but just mentor it.
> >>> And I personally question if this is efficient and we would get enough
> >> mentors in that case.
> >>
> >> The proposal was changed to address that concern. see
> >> <56181303.7000...@apache.org>
> >>
> >
> > And how does one access this?
> >
>
> Sorry, I just posted the Message ID. It can be found on the
> mail-archives or through our Pony Mail PoC site at
>
> https://pony-poc.apache.org/thread.html/87bfb7d68294f0872f524b5418f5369a388b3128ff00d53b25df07f0@118307@%3Cgeneral.incubator.apache.org%3E


Sorry, I was hoping that the message id would provide some context as to
what triggered the original email.  FWIW I did try mail search, but didn't
work.

I'll kind of echo some of the sentiments here (as well as the note on the
other list), but where is this coming from exactly? I've seen a gist with
apache id's and numbers next to them.

Is it a general feeling that graduating podlings are being too reliant on
mentors post graduation?


>
>
> With regards,
> Daniel.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

On 10/11/2015 03:44 PM, John D. Ament wrote:
> On Sun, Oct 11, 2015 at 9:36 AM Daniel Gruno  wrote:
> 
>> On 10/11/2015 03:34 PM, Mark Struberg wrote:
>>>
 Am 11.10.2015 um 14:45 schrieb Pierre Smits :

 Producing good code is a community effort. When it comes down to just
>> the
 mentors fix that themselves, there is something wrong with the
>> community of
 the podling.
>>>
>>> I never questioned that.
>>>
>>> But the proposal sounds that a mentor _must not_ contribute to the
>> project itself but just mentor it.
>>> And I personally question if this is efficient and we would get enough
>> mentors in that case.
>>
>> The proposal was changed to address that concern. see
>> <56181303.7000...@apache.org>
>>
> 
> And how does one access this?
> 

Sorry, I just posted the Message ID. It can be found on the
mail-archives or through our Pony Mail PoC site at
https://pony-poc.apache.org/thread.html/87bfb7d68294f0872f524b5418f5369a388b3128ff00d53b25df07f0@118307@%3Cgeneral.incubator.apache.org%3E

With regards,
Daniel.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[John D. Ament]

On Sun, Oct 11, 2015 at 9:36 AM Daniel Gruno  wrote:

> On 10/11/2015 03:34 PM, Mark Struberg wrote:
> >
> >> Am 11.10.2015 um 14:45 schrieb Pierre Smits :
> >>
> >> Producing good code is a community effort. When it comes down to just
> the
> >> mentors fix that themselves, there is something wrong with the
> community of
> >> the podling.
> >
> > I never questioned that.
> >
> > But the proposal sounds that a mentor _must not_ contribute to the
> project itself but just mentor it.
> > And I personally question if this is efficient and we would get enough
> mentors in that case.
>
> The proposal was changed to address that concern. see
> <56181303.7000...@apache.org>
>

And how does one access this?


>
> With regards,
> Daniel.
>
> >
> > LieGrue,
> > strub
> > -
> > 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
>
>

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

On 10/11/2015 03:34 PM, Mark Struberg wrote:
> 
>> Am 11.10.2015 um 14:45 schrieb Pierre Smits :
>>
>> Producing good code is a community effort. When it comes down to just the
>> mentors fix that themselves, there is something wrong with the community of
>> the podling.
> 
> I never questioned that. 
> 
> But the proposal sounds that a mentor _must not_ contribute to the project 
> itself but just mentor it.
> And I personally question if this is efficient and we would get enough 
> mentors in that case. 

The proposal was changed to address that concern. see
<56181303.7000...@apache.org>

With regards,
Daniel.

> 
> LieGrue,
> strub
> -
> 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

Re: [DISCUSS] Mentor neutrality policy

[Mark Struberg]

> Am 11.10.2015 um 14:45 schrieb Pierre Smits :
> 
> Producing good code is a community effort. When it comes down to just the
> mentors fix that themselves, there is something wrong with the community of
> the podling.

I never questioned that. 

But the proposal sounds that a mentor _must not_ contribute to the project 
itself but just mentor it.
And I personally question if this is efficient and we would get enough mentors 
in that case. 

LieGrue,
strub
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

Producing good code is a community effort. When it comes down to just the
mentors fix that themselves, there is something wrong with the community of
the podling.

This discussion is not about what participants do with their mentor hat on
in the podling. I expect we all appreciate what mentors do within the
podling and how they help out with explanation when a podling is discussed
in this ML. The discussion is about people wearing two (or more) hats while
mentoring a podling.

And yes, the ASF should be wary of mentors pushing their podling toward
graduation beyond their mentor role. Do the mentors fear podling failure
(not graduating) so much, that they need a control on both the internal
process of the podling (e.g. regarding graduation) and the process at IPMC
level?

Was the whole evalution process not intended to ensure that eyes of others
than those with a vested interest (and yes graduation success can be regard
as such) look and decide on the aspects of community diversity/project
independence/code risk of the podling?


Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Sun, Oct 11, 2015 at 11:48 AM, Mark Struberg  wrote:

> -1
>
> Mentors who have no interest (financially or purely technical doesn’t
> matter in the end) will not find enough time to _really_ look into the
> projects health.
>
> Be honest with yourself: how much do you look into the code if you are not
> working on it yourself? How could you then detect that code is
> bulk-imported from another project (I‚ve even seen LGPLed code slip in).
> And this doesn’t happen because people want us something bad. They often
> simply don’t know how much the ASF cares about code provenance and legal
> things. That’s an important part in the mentor work. And you cannot do this
> if you are only somehow loosely checking the project every other month.
>
> Or do you fear a mentor will push through his own ‚baby‘ with knowingly
> ignoring ASF rules?
>
>
> LieGrue,
> strub
>
>
>
> > Am 09.10.2015 um 17:07 schrieb Daniel Gruno :
> >
> > 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
>
>

Re: [DISCUSS] Mentor neutrality policy

[Mark Struberg]

-1

Mentors who have no interest (financially or purely technical doesn’t matter in 
the end) will not find enough time to _really_ look into the projects health.

Be honest with yourself: how much do you look into the code if you are not 
working on it yourself? How could you then detect that code is bulk-imported 
from another project (I‚ve even seen LGPLed code slip in). And this doesn’t 
happen because people want us something bad. They often simply don’t know how 
much the ASF cares about code provenance and legal things. That’s an important 
part in the mentor work. And you cannot do this if you are only somehow loosely 
checking the project every other month.

Or do you fear a mentor will push through his own ‚baby‘ with knowingly 
ignoring ASF rules?


LieGrue,
strub



> Am 09.10.2015 um 17:07 schrieb Daniel Gruno :
> 
> 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

Re: [DISCUSS] Mentor neutrality policy

[Stefan Reich]

This is all SO insane! Sounds like a war program.

Cheers from JavaX - we now have auto-migrating programs.

Stefan
Am 09.10.2015 17:07 schrieb "Daniel Gruno" :

> 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
>
>

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sat, Oct 10, 2015 at 09:05PM, Branko Čibej wrote:
> On 10.10.2015 20:11, Konstantin Boudnik wrote:
> > On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote:
> >> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
> >>> We should address perceived, and certainly provable, instances of
> >>> corruption at the Foundation directly, rather than prescribe policy that
> >>> seeks to prevent future instances as if there is a precedent (but there
> >>> isn't one here... at least one not spoken aloud, right?).
> >> We shouldn't need to have publicly available cases of wrong-doings to
> >> say "no wrong-doings please". We hold our politicians to this standard
> >> where I come from - it's called the Arm's Length Principle, and it's
> >> worked very well.
> > But we aren't dealing with politicians here, who are by definition are the
> > scam of the earth. So, let's not even get there, please.
> 
> "Scam of the Earth" ... one of the better puns I ran into recently. :)

And indeed they are, as they are scamming everyone into a believe that they
are here to solve "issues" for the rest of dumb-us. I am glad that pun hasn't
gone lost ;)

Cos

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

Hi Chris,
As explained later in this thread, my choice of words in the initial
proposal weren't the best suited. I fully agree that Sam's suggestion is
better (as often happens when you propose something and solicit
feedback), and as such, I have proposed a changed text (sent yesterday
to this list) and would like some feedback on that instead, if possible.
I believe that addresses the concerns of many people.

I don't believe that having an interest in the project should prevent
you from working with it (imagine if that applied to committers ;), but
I still do believe that recommendation and the final review of a podling
should be carried out by someone with an arm's length distance from the
podling. I also believe we could improve on how the incubator operates
and perhaps separate such podling reviews from mentorship itself, but I
fully realize that it's not something we can simply magically change
with a few lines of text in a document.

With regards,
Daniel.

On 10/10/2015 04:49 PM, Mattmann, Chris A (3980) 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 
> Reply-To: "general@incubator.apache.org" 
> Date: Friday, October 9, 2015 at 5:14 PM
> To: "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  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 th

Re: [DISCUSS] Mentor neutrality policy

[Branko Čibej]

On 10.10.2015 14:05, Pierre Smits wrote:
> Since we're conducting ASF politics here, you're asserting that you're
> corrupt, anti-social and a nutcase?
> And the rest of privileged contributors of the ASF as well?

Are you deliberately misunderstanding what I wrote? If not, I suggest
you go and read it again, it's just a couple sentences after all.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Branko Čibej]

On 10.10.2015 20:11, Konstantin Boudnik wrote:
> On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote:
>> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
>>> We should address perceived, and certainly provable, instances of
>>> corruption at the Foundation directly, rather than prescribe policy that
>>> seeks to prevent future instances as if there is a precedent (but there
>>> isn't one here... at least one not spoken aloud, right?).
>> We shouldn't need to have publicly available cases of wrong-doings to
>> say "no wrong-doings please". We hold our politicians to this standard
>> where I come from - it's called the Arm's Length Principle, and it's
>> worked very well.
> But we aren't dealing with politicians here, who are by definition are the
> scam of the earth. So, let's not even get there, please.

"Scam of the Earth" ... one of the better puns I ran into recently. :)

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

Big +1

If you don't mind a personal anecdote, in fact at work I was recently
pointedly asked how the pay is over at the Foundation. (Smile)


On Saturday, October 10, 2015, Patrick Hunt  wrote:

> 10x to what Chris said, put much better than I could.
>
> We all wear multiple hats, can't tell you the number of times I've worn my
> Apache hat in the office, in some cases to my own detriment there. If I
> weren't associated with the project at Apache that representation would be
> missing. So really it cuts both ways.
>
> Patrick
>
>
> 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 >
> > 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  > 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 ar

Re: [DISCUSS] Mentor neutrality policy

[Patrick Hunt]

10x to what Chris said, put much better than I could.

We all wear multiple hats, can't tell you the number of times I've worn my
Apache hat in the office, in some cases to my own detriment there. If I
weren't associated with the project at Apache that representation would be
missing. So really it cuts both ways.

Patrick


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 
> Reply-To: "general@incubator.apache.org" 
> Date: Friday, October 9, 2015 at 5:14 PM
> To: "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  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
> >
>
>

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote:
> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
> > We should address perceived, and certainly provable, instances of
> > corruption at the Foundation directly, rather than prescribe policy that
> > seeks to prevent future instances as if there is a precedent (but there
> > isn't one here... at least one not spoken aloud, right?).
> 
> We shouldn't need to have publicly available cases of wrong-doings to
> say "no wrong-doings please". We hold our politicians to this standard
> where I come from - it's called the Arm's Length Principle, and it's
> worked very well.

But we aren't dealing with politicians here, who are by definition are the
scam of the earth. So, let's not even get there, please.

Cos

> >> A mentor must not be financially tied to the project or its incubation
> > status.
> > 
> > Aside from deviating greatly from treating mentors and all other persons as
> > individuals, for verification purposes this would require a level of
> > intrusive financial reporting that we don't remotely approach today and to
> > which most members would probably object.
> 
> I'm not suggesting we start auditing people. As later clarified, I am
> suggesting people recuse themselves from voting if they (or others?)
> feel that they have economic or other corporate interests that may cloud
> either their judgment or their perceived judgment. The reason I said
> 'mentors' here is because the mentor role, as it currently is, is a mix
> of attorney, judge, jury and executioner in the podlings. If we were to
> separate this and mentors were solely in charge of _mentoring_, the
> issue would be more moot.
> 
> > 
> >> A mentor must not have a vested interest in incubating, graduating or
> > dismantling a podling that goes beyond the general Apache mission
> > 
> > None of this is well defined.
> 
> Agreed, I picked the wrong word to use here. I prefer Sam's revisement,
> as stated earlier.
> 
> With regards,
> Daniel.
> 
> > 
> >> If you are a in the original community behind the project, you cannot
> > mentor it nor vote for/against it.
> > 
> > ​This diminishes the pool of available mentors and in particular those
> > probably most vested in the success of the podling.​
> > 
> > 
> > 
> > 
> > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  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
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Mattmann, Chris A (3980)]

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 
Reply-To: "general@incubator.apache.org" 
Date: Friday, October 9, 2015 at 5:14 PM
To: "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  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
>

Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

Since we're conducting ASF politics here, you're asserting that you're
corrupt, anti-social and a nutcase?
And the rest of privileged contributors of the ASF as well?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

Re: [DISCUSS] Mentor neutrality policy

[Branko Čibej]

On 10.10.2015 09:06, Daniel Gruno wrote:
> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
>> We should address perceived, and certainly provable, instances of
>> corruption at the Foundation directly, rather than prescribe policy that
>> seeks to prevent future instances as if there is a precedent (but there
>> isn't one here... at least one not spoken aloud, right?).
> We shouldn't need to have publicly available cases of wrong-doings to
> say "no wrong-doings please". We hold our politicians to this standard
> where I come from - it's called the Arm's Length Principle, and it's
> worked very well.

But the grounds for implementing such a policy are the thousands of
years of history with millions of examples of politicians being
narcissistic, corrupt, anti-social nutcases.

How many examples of corrupt, anti-social nutcases can you count amongst
ASF members or IPMC members, that would justify your proposal?

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Roman Shaposhnik]

On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno  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.

I'm very strongly -1 on this for two reasons. One fundamental
and one operational. Fundamentally, this goes against a core
ASF principle that we all collaborate here as individuals by
checking our corporate affiliation at the door. IOW, we are explicitly
granting our members and committers the trust required to make
sure they do the right thing while they themselves (or their employees)
can significantly benefit (financially and otherwise) from the projects.

This is what makes ASF unique and anything that goes even slightly
in the direction of reducing this level of trust will have me up in arms
(regardless of whether it is related to Incubator or not).

Operationally, this is extremely tricky to enforce. I speak here
from experience of somebody who has to be appreciative of the same
set of issues while consulting for companies and yet working for my
current employer. Even in a corporate world (where stakes are much
higher from legal perspective) this typically gets handled by trusting
the individual to do the right thing and disclose any potential conflict
of interest (financial or otherwise).

> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission

Why? As a mentor I have as much vested interest in making sure
my podling graduates as a teacher has in seeing that a student
is successful. Why is this a problem?

> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)

Very strongly -1. See above.

> - 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.

Very strongly -1. See above.

> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.

Why? What problem is it solving?

> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.

I think you're solving a wrong problem here. The biggest problem I see with
IPMC (and its relationship to the board) is a fundamental lack of  mentor's
accountability TO THE PODLING (and as a consequence a lack of general
accountability of the podlings to the board).

IOW, our biggest problem is NOT scheming, corporate shilling mentors. Our
problem is some mentors who are AWOL most of the time and then just +1
during graduation.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Andrea Pescetti]

On 10/10/2015 Daniel Gruno wrote:

I'm not suggesting we start auditing people. As later clarified, I am
suggesting people recuse themselves from voting if they (or others?)
feel that they have economic or other corporate interests that may cloud
either their judgment or their perceived judgment.


Wouldn't it be enough to ask mentors to disclose their interests rather 
than prohibiting them to participate in activities?


If the IPMC is properly informed, then it may add mentors or discuss 
with the existing mentors, or simply use more scrutiny on the project, 
to avoid unwanted situations.


If the above sounds naive it might be due to the fact that I have no 
experience (as far as I know) with podlings that had the issues 
described by Daniel. But I agree with Daniel's principles.


Regards,
  Andrea.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

On 10/10/2015 07:51 AM, Andrew Purtell wrote:
> We should address perceived, and certainly provable, instances of
> corruption at the Foundation directly, rather than prescribe policy that
> seeks to prevent future instances as if there is a precedent (but there
> isn't one here... at least one not spoken aloud, right?).

We shouldn't need to have publicly available cases of wrong-doings to
say "no wrong-doings please". We hold our politicians to this standard
where I come from - it's called the Arm's Length Principle, and it's
worked very well.

> 
>> A mentor must not be financially tied to the project or its incubation
> status.
> 
> Aside from deviating greatly from treating mentors and all other persons as
> individuals, for verification purposes this would require a level of
> intrusive financial reporting that we don't remotely approach today and to
> which most members would probably object.

I'm not suggesting we start auditing people. As later clarified, I am
suggesting people recuse themselves from voting if they (or others?)
feel that they have economic or other corporate interests that may cloud
either their judgment or their perceived judgment. The reason I said
'mentors' here is because the mentor role, as it currently is, is a mix
of attorney, judge, jury and executioner in the podlings. If we were to
separate this and mentors were solely in charge of _mentoring_, the
issue would be more moot.

> 
>> A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> 
> None of this is well defined.

Agreed, I picked the wrong word to use here. I prefer Sam's revisement,
as stated earlier.

With regards,
Daniel.

> 
>> If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> ​This diminishes the pool of available mentors and in particular those
> probably most vested in the success of the podling.​
> 
> 
> 
> 
> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  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

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

We should address perceived, and certainly provable, instances of
corruption at the Foundation directly, rather than prescribe policy that
seeks to prevent future instances as if there is a precedent (but there
isn't one here... at least one not spoken aloud, right?).

> A mentor must not be financially tied to the project or its incubation
status.

Aside from deviating greatly from treating mentors and all other persons as
individuals, for verification purposes this would require a level of
intrusive financial reporting that we don't remotely approach today and to
which most members would probably object.

> A mentor must not have a vested interest in incubating, graduating or
dismantling a podling that goes beyond the general Apache mission

None of this is well defined.

> If you are a in the original community behind the project, you cannot
mentor it nor vote for/against it.

​This diminishes the pool of available mentors and in particular those
probably most vested in the success of the podling.​




On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  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
>
>


-- 
Best regards,

   - Andy

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

Re: [DISCUSS] Mentor neutrality policy

[Mattmann, Chris A (3980)]

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  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

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sat, Oct 10, 2015 at 01:29AM, Pierre Smits wrote:
> What are you referring to, Konstantin?

I am referring to the progressives of the world and all "policy frameworks"
they are so readily unleashing on everybody because they have an urge to
meddle. I am very much agree with Chris and Ross on immorality of the
guilt-by-association policy.

Cos

> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
> On Sat, Oct 10, 2015 at 1:31 AM, Konstantin Boudnik  wrote:
> 
> > On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> > > Does there always have to be an actual problem before we can propose a
> > > policy? must we always be reactive instead of proactive?
> >
> > "We can't just stay on a side and wait, we should do something!" - sounds
> > all
> > too familiar, eh?
> >
> > > Yes, I am in a way implying that some mentors are, perhaps, not neutral
> > > in their work. I will not back it up with specific names or contexts, as
> > > I don't want to take a trip to lawsuit town for things I cannot back up
> > > with publicly available information.
> > >
> > > I don't find this to be uncivil accusations - can you outline a specific
> > > segment that you find uncivil? I am proposing a set of basic rules -
> > > which is naturally up for discussion and improvement - that would
> > > potentially alleviate us from having some nasty discussions - whether
> > > they be public or private - about the neutrality and honesty of
> > > recommendations, and hopefully ensure we have a more leveled playing
> > > field in the incubator.
> > >
> > > I'll stop here, as my eyesight is playing a trick on me today and not
> > > allowing me to see what I type.
> > >
> > > With regards,
> > > Daniel.
> > >
> > > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > > > What problem does this solve?
> > > >
> > > > This proposal lacks context. It implies that mentors are not neutral,
> > > > and that they are motivated by interests not shared by the ASF. But it
> > > > does not outline the merits of that belief, neither does it specify
> > > > how this proposal would address them. Instead of allowing those
> > > > definitions to float, this discussion would be more productive if it
> > > > were about some concrete problems for which there is evidence. Yet
> > > > another thread of rude responses to uncivil accusations is
> > > > unproductive, even if it is an IPMC tradition. -C
> > > >
> > > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> > 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
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.o

Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

What are you referring to, Konstantin?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Sat, Oct 10, 2015 at 1:31 AM, Konstantin Boudnik  wrote:

> On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> > Does there always have to be an actual problem before we can propose a
> > policy? must we always be reactive instead of proactive?
>
> "We can't just stay on a side and wait, we should do something!" - sounds
> all
> too familiar, eh?
>
> > Yes, I am in a way implying that some mentors are, perhaps, not neutral
> > in their work. I will not back it up with specific names or contexts, as
> > I don't want to take a trip to lawsuit town for things I cannot back up
> > with publicly available information.
> >
> > I don't find this to be uncivil accusations - can you outline a specific
> > segment that you find uncivil? I am proposing a set of basic rules -
> > which is naturally up for discussion and improvement - that would
> > potentially alleviate us from having some nasty discussions - whether
> > they be public or private - about the neutrality and honesty of
> > recommendations, and hopefully ensure we have a more leveled playing
> > field in the incubator.
> >
> > I'll stop here, as my eyesight is playing a trick on me today and not
> > allowing me to see what I type.
> >
> > With regards,
> > Daniel.
> >
> > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > > What problem does this solve?
> > >
> > > This proposal lacks context. It implies that mentors are not neutral,
> > > and that they are motivated by interests not shared by the ASF. But it
> > > does not outline the merits of that belief, neither does it specify
> > > how this proposal would address them. Instead of allowing those
> > > definitions to float, this discussion would be more productive if it
> > > were about some concrete problems for which there is evidence. Yet
> > > another thread of rude responses to uncivil accusations is
> > > unproductive, even if it is an IPMC tradition. -C
> > >
> > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> 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
> > >
> >
> >
> > -
> > 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
>
>

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> Does there always have to be an actual problem before we can propose a
> policy? must we always be reactive instead of proactive?

"We can't just stay on a side and wait, we should do something!" - sounds all
too familiar, eh?

> Yes, I am in a way implying that some mentors are, perhaps, not neutral
> in their work. I will not back it up with specific names or contexts, as
> I don't want to take a trip to lawsuit town for things I cannot back up
> with publicly available information.
> 
> I don't find this to be uncivil accusations - can you outline a specific
> segment that you find uncivil? I am proposing a set of basic rules -
> which is naturally up for discussion and improvement - that would
> potentially alleviate us from having some nasty discussions - whether
> they be public or private - about the neutrality and honesty of
> recommendations, and hopefully ensure we have a more leveled playing
> field in the incubator.
> 
> I'll stop here, as my eyesight is playing a trick on me today and not
> allowing me to see what I type.
> 
> With regards,
> Daniel.
> 
> On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > What problem does this solve?
> > 
> > This proposal lacks context. It implies that mentors are not neutral,
> > and that they are motivated by interests not shared by the ASF. But it
> > does not outline the merits of that belief, neither does it specify
> > how this proposal would address them. Instead of allowing those
> > definitions to float, this discussion would be more productive if it
> > were about some concrete problems for which there is evidence. Yet
> > another thread of rude responses to uncivil accusations is
> > unproductive, even if it is an IPMC tradition. -C
> > 
> > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  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
> > 
> 
> 
> -
> 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

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Fri, Oct 09, 2015 at 11:38AM, Greg Trasuk wrote:
> Hi Daniel:
> 
> Discussion intertwined below…
> 
> Cheers,
> 
> Greg Trasuk
> 
> > On Oct 9, 2015, at 11:07 AM, Daniel Gruno  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.
> 
> This requirement would seem to be against the idea that we participate in
> Apache as individuals, rather than as employees/representatives of some
> company.  If there is a case where a member appears to be representing their

I'd even go as far as saying this requirement asserts that mentors aren't
capable of separating their employment/advisement affiliation from their
individual contribution to the ASF. If it were indeed a case it should be
dealt with on a case-per-case basis, instead of putting a round of the
red-tape on everything single member of IPMC.

Cos

> company’s interest rather than the Foundation’s interest, shouldn’t that be
> dealt with in itself?
> 
> > - A mentor must not have a vested interest in incubating, graduating or
> > dismantling a podling that goes beyond the general Apache mission
> 
> Could you elaborate on “beyond the general Apache mission”?  You probably 
> have some concrete examples in mind, and I’m sure we don’t want to start 
> dissecting those examples rather than your overall suggestion, but 
> personally, I’m not sure what you mean.
> 
> > - A mentor must not be affiliated with the entity granting the code
> > (company or original project community)
> > 
> 
> That suggestion would seem to preclude a knowledgable insider who happens to 
> be an Apache member from helping out with incubating a project.  Which seems 
> kind of inefficient.
> 
> > 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
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Fri, Oct 9, 2015 at 11:31 PM, Ross Gardler 
wrote:

> No. Meaning that starting from a place of no-trust in an environment where
> trust is critical is wrong.
>
> Ross
>
> -Original Message-
> From: Pierre Smits [mailto:pierre.sm...@gmail.com]
> Sent: Friday, October 9, 2015 2:26 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Mentor neutrality policy
>
> Meaning: proactively trying to doing the right thing, trying to define
> boundaries before wrongdoing happens, is wrong?
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foem.ofbizci.net%2foci-2%2f&data=01%7c01%7cRoss.Gardler%40microsoft.com%7ce3df44d6e18b409c180c08d2d0f042cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jTO4UHTjBVDxUGUNMAPv5ocD5hBmTU0Xj9xM1PTNWEk%3d
>
> On Fri, Oct 9, 2015 at 10:51 PM, Chris Douglas 
> wrote:
>
> > Daniel-
> >
> > If you have these concerns about mentors, a TLP proposal, or even an
> > active TLP substantiated only by private information: notify the board
> > via board-private@. That's why it's there.
> >
> > The proposal accuses mentors of selling influence, and acting contrary
> > to the foundation's interest. That is by definition a problem to which
> > we react, with proof of guilt. "Proactively" treating volunteers as
> > suspect demands that mentors prove their innocence. Assuming guilt is
> > not "proactive," but uncivil and immoral.
> >
> > There are also practical objections. Every IPMC member has a binding
> > vote on decisions made by the incubator, period. IPMC members may
> > voluntarily recuse themselves, but a policy that suppresses the votes
> > of "suspicious" groups is invalid.
> >
> > The TLP resolution is only recommended by the IPMC. Anything achieved
> > by this proposal is better implemented by the board considering that
> > recommendation in context- including evidence provided privately- and
> > rejecting improper proposals with actionable feedback to the PPMC. -C
> >
> > On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno 
> > wrote:
> > > Does there always have to be an actual problem before we can propose
> > > a policy? must we always be reactive instead of proactive?
> > >
> > > Yes, I am in a way implying that some mentors are, perhaps, not
> > > neutral in their work. I will not back it up with specific names or
> > > contexts, as I don't want to take a trip to lawsuit town for things
> > > I cannot back up with publicly available information.
> > >
> > > I don't find this to be uncivil accusations - can you outline a
> > > specific segment that you find uncivil? I am proposing a set of
> > > basic rules - which is naturally up for discussion and improvement -
> > > that would potentially alleviate us from having some nasty
> > > discussions - whether they be public or private - about the
> > > neutrality and honesty of recommendations, and hopefully ensure we
> > > have a more leveled playing field in the incubator.
> > >
> > > I'll stop here, as my eyesight is playing a trick on me today and
> > > not allowing me to see what I type.
> > >
> > > With regards,
> > > Daniel.
> > >
> > > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > >> What problem does this solve?
> > >>
> > >> This proposal lacks context. It implies that mentors are not
> > >> neutral, and that they are motivated by interests not shared by the
> > >> ASF. But it does not outline the merits of that belief, neither
> > >> does it specify how this proposal would address them. Instead of
> > >> allowing those definitions to float, this discussion would be more
> > >> productive if it were about some concrete problems for which there
> > >> is evidence. Yet another thread of rude responses to uncivil
> > >> accusations is unproductive, even if it is an IPMC tradition. -C
> > >>
> > >> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> > 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.
> >

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

No. Meaning that starting from a place of no-trust in an environment where 
trust is critical is wrong.

Ross

-Original Message-
From: Pierre Smits [mailto:pierre.sm...@gmail.com] 
Sent: Friday, October 9, 2015 2:26 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentor neutrality policy

Meaning: proactively trying to doing the right thing, trying to define 
boundaries before wrongdoing happens, is wrong?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foem.ofbizci.net%2foci-2%2f&data=01%7c01%7cRoss.Gardler%40microsoft.com%7ce3df44d6e18b409c180c08d2d0f042cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jTO4UHTjBVDxUGUNMAPv5ocD5hBmTU0Xj9xM1PTNWEk%3d

On Fri, Oct 9, 2015 at 10:51 PM, Chris Douglas  wrote:

> Daniel-
>
> If you have these concerns about mentors, a TLP proposal, or even an 
> active TLP substantiated only by private information: notify the board 
> via board-private@. That's why it's there.
>
> The proposal accuses mentors of selling influence, and acting contrary 
> to the foundation's interest. That is by definition a problem to which 
> we react, with proof of guilt. "Proactively" treating volunteers as 
> suspect demands that mentors prove their innocence. Assuming guilt is 
> not "proactive," but uncivil and immoral.
>
> There are also practical objections. Every IPMC member has a binding 
> vote on decisions made by the incubator, period. IPMC members may 
> voluntarily recuse themselves, but a policy that suppresses the votes 
> of "suspicious" groups is invalid.
>
> The TLP resolution is only recommended by the IPMC. Anything achieved 
> by this proposal is better implemented by the board considering that 
> recommendation in context- including evidence provided privately- and 
> rejecting improper proposals with actionable feedback to the PPMC. -C
>
> On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno 
> wrote:
> > Does there always have to be an actual problem before we can propose 
> > a policy? must we always be reactive instead of proactive?
> >
> > Yes, I am in a way implying that some mentors are, perhaps, not 
> > neutral in their work. I will not back it up with specific names or 
> > contexts, as I don't want to take a trip to lawsuit town for things 
> > I cannot back up with publicly available information.
> >
> > I don't find this to be uncivil accusations - can you outline a 
> > specific segment that you find uncivil? I am proposing a set of 
> > basic rules - which is naturally up for discussion and improvement - 
> > that would potentially alleviate us from having some nasty 
> > discussions - whether they be public or private - about the 
> > neutrality and honesty of recommendations, and hopefully ensure we 
> > have a more leveled playing field in the incubator.
> >
> > I'll stop here, as my eyesight is playing a trick on me today and 
> > not allowing me to see what I type.
> >
> > With regards,
> > Daniel.
> >
> > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> >> What problem does this solve?
> >>
> >> This proposal lacks context. It implies that mentors are not 
> >> neutral, and that they are motivated by interests not shared by the 
> >> ASF. But it does not outline the merits of that belief, neither 
> >> does it specify how this proposal would address them. Instead of 
> >> allowing those definitions to float, this discussion would be more 
> >> productive if it were about some concrete problems for which there 
> >> is evidence. Yet another thread of rude responses to uncivil 
> >> accusations is unproductive, even if it is an IPMC tradition. -C
> >>
> >> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> 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 
> >>> (apar

Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

Meaning: proactively trying to doing the right thing, trying to define
boundaries before wrongdoing happens, is wrong?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Fri, Oct 9, 2015 at 10:51 PM, Chris Douglas  wrote:

> Daniel-
>
> If you have these concerns about mentors, a TLP proposal, or even an
> active TLP substantiated only by private information: notify the board
> via board-private@. That's why it's there.
>
> The proposal accuses mentors of selling influence, and acting contrary
> to the foundation's interest. That is by definition a problem to which
> we react, with proof of guilt. "Proactively" treating volunteers as
> suspect demands that mentors prove their innocence. Assuming guilt is
> not "proactive," but uncivil and immoral.
>
> There are also practical objections. Every IPMC member has a binding
> vote on decisions made by the incubator, period. IPMC members may
> voluntarily recuse themselves, but a policy that suppresses the votes
> of "suspicious" groups is invalid.
>
> The TLP resolution is only recommended by the IPMC. Anything achieved
> by this proposal is better implemented by the board considering that
> recommendation in context- including evidence provided privately- and
> rejecting improper proposals with actionable feedback to the PPMC. -C
>
> On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno 
> wrote:
> > Does there always have to be an actual problem before we can propose a
> > policy? must we always be reactive instead of proactive?
> >
> > Yes, I am in a way implying that some mentors are, perhaps, not neutral
> > in their work. I will not back it up with specific names or contexts, as
> > I don't want to take a trip to lawsuit town for things I cannot back up
> > with publicly available information.
> >
> > I don't find this to be uncivil accusations - can you outline a specific
> > segment that you find uncivil? I am proposing a set of basic rules -
> > which is naturally up for discussion and improvement - that would
> > potentially alleviate us from having some nasty discussions - whether
> > they be public or private - about the neutrality and honesty of
> > recommendations, and hopefully ensure we have a more leveled playing
> > field in the incubator.
> >
> > I'll stop here, as my eyesight is playing a trick on me today and not
> > allowing me to see what I type.
> >
> > With regards,
> > Daniel.
> >
> > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> >> What problem does this solve?
> >>
> >> This proposal lacks context. It implies that mentors are not neutral,
> >> and that they are motivated by interests not shared by the ASF. But it
> >> does not outline the merits of that belief, neither does it specify
> >> how this proposal would address them. Instead of allowing those
> >> definitions to float, this discussion would be more productive if it
> >> were about some concrete problems for which there is evidence. Yet
> >> another thread of rude responses to uncivil accusations is
> >> unproductive, even if it is an IPMC tradition. -C
> >>
> >> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> 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.apach

Re: [DISCUSS] Mentor neutrality policy

[Chris Douglas]

Daniel-

If you have these concerns about mentors, a TLP proposal, or even an
active TLP substantiated only by private information: notify the board
via board-private@. That's why it's there.

The proposal accuses mentors of selling influence, and acting contrary
to the foundation's interest. That is by definition a problem to which
we react, with proof of guilt. "Proactively" treating volunteers as
suspect demands that mentors prove their innocence. Assuming guilt is
not "proactive," but uncivil and immoral.

There are also practical objections. Every IPMC member has a binding
vote on decisions made by the incubator, period. IPMC members may
voluntarily recuse themselves, but a policy that suppresses the votes
of "suspicious" groups is invalid.

The TLP resolution is only recommended by the IPMC. Anything achieved
by this proposal is better implemented by the board considering that
recommendation in context- including evidence provided privately- and
rejecting improper proposals with actionable feedback to the PPMC. -C

On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno  wrote:
> Does there always have to be an actual problem before we can propose a
> policy? must we always be reactive instead of proactive?
>
> Yes, I am in a way implying that some mentors are, perhaps, not neutral
> in their work. I will not back it up with specific names or contexts, as
> I don't want to take a trip to lawsuit town for things I cannot back up
> with publicly available information.
>
> I don't find this to be uncivil accusations - can you outline a specific
> segment that you find uncivil? I am proposing a set of basic rules -
> which is naturally up for discussion and improvement - that would
> potentially alleviate us from having some nasty discussions - whether
> they be public or private - about the neutrality and honesty of
> recommendations, and hopefully ensure we have a more leveled playing
> field in the incubator.
>
> I'll stop here, as my eyesight is playing a trick on me today and not
> allowing me to see what I type.
>
> With regards,
> Daniel.
>
> On 10/09/2015 08:03 PM, Chris Douglas wrote:
>> What problem does this solve?
>>
>> This proposal lacks context. It implies that mentors are not neutral,
>> and that they are motivated by interests not shared by the ASF. But it
>> does not outline the merits of that belief, neither does it specify
>> how this proposal would address them. Instead of allowing those
>> definitions to float, this discussion would be more productive if it
>> were about some concrete problems for which there is evidence. Yet
>> another thread of rude responses to uncivil accusations is
>> unproductive, even if it is an IPMC tradition. -C
>>
>> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  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
>>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, 

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

On 10/09/2015 08:02 PM, Sam Ruby wrote:
> On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
>  wrote:
>> Hi,
>>
>> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
>>> ...Furthermore, I would like to see this extended to votes on graduating or
>>> retiring podlings,..
>>
>> IMO this is where independence is important. We could require that 3
>> "organizationally independent" IPMC members review each podling before
>> graduating or retiring. Those people do not need to be project
>> mentors.
> 
> I much prefer a formulation of "3 independent" over "no financial
> ties", and would prefer such a criteria be considered whenever the
> impulse arises to ensure that NO involved individual has a vested
> interest.
> 
> I'll go further and say that financial interests are but one way in
> which individuals have a vested interest in the success of a project,
> and echoing a statement by Ross -- having a vested interest is not a
> bad thing.

Perhaps my initial suggestion needs some modification to the wording.
People with a vested interest (for a certain definition of the term) is
in itself not a bad thing when it comes to mentoring, but it can become
tricky when it comes to giving recommendations to the IPMC about how to
proceed from a neutral standpoint. That is what I aimed to have us work on.

I would imagine no one would object to a policy that says you cannot
have a binding vote if you have a financial interest in graduating a
podling, but my real point is we should leave the decision making to
those who are truly neutral, much as we let a judge and/or a neutral
jury decide if we're guilty or not in a legal case.

Perhaps we could change it to:

- Binding votes on incubation, graduation and/or retirement are only
valid when given by members of the IPMC who are independent from the
podling in question. Mentors are free to recommend such actions, but
cannot cast a vote themselves.

WDYT?

With regards,
Daniel.


> 
> Finally, I would prefer a model whereby those that have achieved ASF
> member status are given the benefit of the doubt in matters involving
> a group vote when it comes to their ability to separate their ASF role
> from their relationship with their employee.  Nothing wrong with still
> requiring 3 completely independent votes, but having a rule that
> excludes participation by those that have demonstrated their merit as
> ASF members just seems wrong.
> 
> - Sam Ruby
> 
> -
> 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

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

Does there always have to be an actual problem before we can propose a
policy? must we always be reactive instead of proactive?

Yes, I am in a way implying that some mentors are, perhaps, not neutral
in their work. I will not back it up with specific names or contexts, as
I don't want to take a trip to lawsuit town for things I cannot back up
with publicly available information.

I don't find this to be uncivil accusations - can you outline a specific
segment that you find uncivil? I am proposing a set of basic rules -
which is naturally up for discussion and improvement - that would
potentially alleviate us from having some nasty discussions - whether
they be public or private - about the neutrality and honesty of
recommendations, and hopefully ensure we have a more leveled playing
field in the incubator.

I'll stop here, as my eyesight is playing a trick on me today and not
allowing me to see what I type.

With regards,
Daniel.

On 10/09/2015 08:03 PM, Chris Douglas wrote:
> What problem does this solve?
> 
> This proposal lacks context. It implies that mentors are not neutral,
> and that they are motivated by interests not shared by the ASF. But it
> does not outline the merits of that belief, neither does it specify
> how this proposal would address them. Instead of allowing those
> definitions to float, this discussion would be more productive if it
> were about some concrete problems for which there is evidence. Yet
> another thread of rude responses to uncivil accusations is
> unproductive, even if it is an IPMC tradition. -C
> 
> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  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
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Chris Douglas]

What problem does this solve?

This proposal lacks context. It implies that mentors are not neutral,
and that they are motivated by interests not shared by the ASF. But it
does not outline the merits of that belief, neither does it specify
how this proposal would address them. Instead of allowing those
definitions to float, this discussion would be more productive if it
were about some concrete problems for which there is evidence. Yet
another thread of rude responses to uncivil accusations is
unproductive, even if it is an IPMC tradition. -C

On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  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

Re: [DISCUSS] Mentor neutrality policy

[Sam Ruby]

On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
>> ...Furthermore, I would like to see this extended to votes on graduating or
>> retiring podlings,..
>
> IMO this is where independence is important. We could require that 3
> "organizationally independent" IPMC members review each podling before
> graduating or retiring. Those people do not need to be project
> mentors.

I much prefer a formulation of "3 independent" over "no financial
ties", and would prefer such a criteria be considered whenever the
impulse arises to ensure that NO involved individual has a vested
interest.

I'll go further and say that financial interests are but one way in
which individuals have a vested interest in the success of a project,
and echoing a statement by Ross -- having a vested interest is not a
bad thing.

Finally, I would prefer a model whereby those that have achieved ASF
member status are given the benefit of the doubt in matters involving
a group vote when it comes to their ability to separate their ASF role
from their relationship with their employee.  Nothing wrong with still
requiring 3 completely independent votes, but having a rule that
excludes participation by those that have demonstrated their merit as
ASF members just seems wrong.

- Sam Ruby

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Bertrand Delacretaz]

Hi,

On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
> ...Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings,..

IMO this is where independence is important. We could require that 3
"organizationally independent" IPMC members review each podling before
graduating or retiring. Those people do not need to be project
mentors.

Having a written report from this graduating evaluation would be good,
for example something based on our maturity model [1]. Also useful for
the board to decide whether to accept graduation or ask for more
details.

Apart from that, if an organization donates code via incubation it can
IMO actually be beneficial to have one or two mentors who are familiar
with the project and its initial community.

So maybe define some independence criteria for mentors, but IMO mostly
require that independence for whoever reviews and recommends the
podling for graduation or retirement. Currently we mostly equate
mentors with this "graduation review team" but that might not be the
best way to do it.

-Bertrand

[1] http://community.apache.org/apache-way/apache-project-maturity-model.html

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Shane Curcuru]

Daniel Gruno wrote on 10/9/15 11:07 AM:
> 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.
> 

This ties directly into the concept of independent project governance:

  http://community.apache.org/projectIndependence.html

It's really hard to feel confident that each of our soon-to-graduate
podlings is truly operating as an independent project in some cases.

Question: has everyone here read that essay?  Does everyone here agree
that project independence as described in general terms there is a
requirement of every TLP?  Do people think that this concept is clear to
every Apache PMC?

The fact that we are the "Switzerland of software" - a vendor-neutral
place where everyone could be comfortable collaborating, and we ensure
all of our governance is truly independent of commercial influence or
the influence of our various employers - is probably the hardest issue
we face in the big picture.  I sometimes wonder if we all are on the
same page with that point.

It's clear that the details of any changes here need discussion, and our
general rule of having at least three mentors (presumably, not all of
whom are at the same employer) goes a long way to helping.

But if you think about conflict of interest laws and procedures in the
world of corporate software - or really, any sort of business - the ASF
is the far outlier in trusting and assuming that we are all individuals
wearing our appropriate Apache hat.  That's a good thing, and it's part
of what makes the ASF special - but we also need to remember that the
rest of the world does not always understand our almost laissez-faire
way of treating everyone as an individual unaffected by their outside
affiliations.

- Shane

> 
> 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

Re: [DISCUSS] Mentor neutrality policy

[Greg Trasuk]

Hi Daniel:

Discussion intertwined below…

Cheers,

Greg Trasuk

> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  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.

This requirement would seem to be against the idea that we participate in 
Apache as individuals, rather than as employees/representatives of some 
company.  If there is a case where a member appears to be representing their 
company’s interest rather than the Foundation’s interest, shouldn’t that be 
dealt with in itself?

> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission

Could you elaborate on “beyond the general Apache mission”?  You probably have 
some concrete examples in mind, and I’m sure we don’t want to start dissecting 
those examples rather than your overall suggestion, but personally, I’m not 
sure what you mean.

> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 

That suggestion would seem to preclude a knowledgable insider who happens to be 
an Apache member from helping out with incubating a project.  Which seems kind 
of inefficient.

> 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

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

I'm not sure about this.

In the past I've argued that we need mentors who *do* have a personal interest. 
Those are the ones least likely to be absent during incubation.

I do agree that mentors must act in a neutral way. I would hope that if this 
were not the case then someone would speak up. I accept that it would be 
awkward to do so but concerns need not be raised in a "person Foo is not acting 
in a neutral way" in most cases it would always be possible to say "the project 
is not acting in a neutral way".  

Furthermore, how do we evaluate "vested interest". If someone agrees to mentor 
a project that is from a team in a different part of their company do they have 
a vested interest? Speaking personally I have more interest in the success of 
our partners than I do in some unrelated parts of my employers business. Does 
that mean I should not be allowed to mentor projects from my partners too? 
While I can hide behind a "big company blindness" case others have no such 
option. What if they are from a SME who does not have that luxury, how do we 
enforce this proposal fairly?

I'd like to think that if the ASF is the right place for a project in which 
someone has a vested interest then they will want that project to operate as an 
Apache project. By definition that means that the mentor must act impartially 
if they are to achieve their goals.

Personally I would focus more on better oversight of podling and mentor 
activity. The goal is to catch the occasional problem case rather than put 
restrictions in place. I'm not sure how to do that though. I and others have 
made many suggestions over the years. They can be found here 
http://wiki.apache.org/incubator/IncubatorIssues2013 (you might want to add 
your proposal there).

Ross

-Original Message-
From: Daniel Gruno [mailto:humbed...@apache.org] 
Sent: Friday, October 9, 2015 8:07 AM
To: general@incubator.apache.org
Subject: [DISCUSS] Mentor neutrality policy

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

Re: [DISCUSS] Mentor neutrality policy

[Julian Hyde]

It seems to me that the negatives of your proposed policy outweigh the 
positives.

Presumably the goal is to prevent mentors from making biased decisions due to 
conflicts of interest. There are other approaches to solving CoI, such as 
declaring conflicts of interest and, Apache’s current approach, to trust 
mentors to “wear multiple hats”.

A more pressing problem, in my opinion, is absentee mentors. Your proposed 
changes would make that problem a good deal worse, by eliminating from the pool 
of possible mentors those people who have the most knowledge about the subject 
area and motivation to help the project succeed.

I suggest that we look at “conflict of interest” as a whole, ascertain whether 
it is a significant problem and if so, consider other solutions to it.

Julian

 
> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  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