Re: Formalize Committer Proposal and Application Procedure

2017-08-15 Thread Madan Jampani
Chris,

The document (template) was just a guide and not everything in it is
necessary to make a good nomination. Just having links to accepted PRs and
optionally pointers to any additional supporting material is all that is
needed. We can simplify the template if that serves to make this easy. The
general requirements are outlined in the wiki.

Thanks
Madan

On Fri, Aug 11, 2017 at 11:20 AM, Chris Olivier 
wrote:

> My $0.02:
>
> I think it's neat to have a nice doc with summaries and whatnot.
>
> That being said, I am not sure that I would want to do something different
> from all of the other Apache projects.   Apache has shown that their method
> is successful.
>
> I worry in this case that the focus may, for some, become how pretty (or
> even possibly misleading) the document is, rather than actually clicking
> and inspecting the work done.  I know that someone pointed out that it is
> too tedious to click the links, but isn't the work what this is all about?
>
> Some people have great talents for writing these sorts of documents -- I
> don't know that this means they are a good contributor or not.
>
> In addition, since this is a global initiative, some worthy contributors
> may struggle with English...
>
>
>
> -Chris
>
>
> On Fri, Aug 11, 2017 at 11:03 AM, Madan Jampani 
> wrote:
>
> > All, I captured the comments and general feedback that emerged from this
> > discussion into a set of guidelines for when someone can become a
> committer
> > and what record of contributions they need to have to strengthen their
> > case. It also has a link to a nomination template Tianqi created for a
> > specific user (@eric-haibin-lin) as an example.
> >
> > Here is the wiki link:
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >
> > I'd request the members to review it and provide feedback so that we can
> > settle on a set of formal guidelines.
> >
> > Madan.
> >
> > On Fri, Aug 11, 2017 at 5:43 AM, Isabel Drost-Fromm 
> > wrote:
> >
> > > On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote:
> > > > The criteria should look not only at Quantity but at the Quality of
> > work
> > > as
> > > > well.
> > >
> > > Just as one additional data point:
> > >
> > > http://community.apache.org/newcommitter.html is the Apache Community
> > > Development Project's guidelines.
> > >
> > > For other tasks than coding see also here:
> > > http://community.apache.org/committers/#assisting-with-
> > > project-management-and-marketing
> > >
> > >
> > > https://community.apache.org/apache-way/apache-project-
> > > maturity-model.html#community for more on
> > > the maturity model's take on community.
> > >
> > >
> > > One thing to keep in mind: All successful OSS projects I came across at
> > > some
> > > point had to deal with topics that were very far away from writing
> actual
> > > code.
> > > In your committer guidelines you can make a conscious choice to
> > explicitly
> > > mention that those tasks will be rewarded as well - which in turn might
> > > lead to
> > > people who won't necessarily contribute code (either due to legal
> > > constraints or
> > > simply lack of interest or skills) to take these tasks up for you.
> > >
> > > I remember seeing discussions on whether to turn
> non-coding-contributors
> > > into
> > > committers recently, but my search-foo has left me, I don't find the
> > > thread in
> > > question anymore :/
> > >
> > > Isabel
> > >
> > >
> > >
> > > --
> > > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh
> > (most
> > > likely involving some kind of mobile connection only.)
> > >
> >
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-11 Thread Chris Olivier
My $0.02:

I think it's neat to have a nice doc with summaries and whatnot.

That being said, I am not sure that I would want to do something different
from all of the other Apache projects.   Apache has shown that their method
is successful.

I worry in this case that the focus may, for some, become how pretty (or
even possibly misleading) the document is, rather than actually clicking
and inspecting the work done.  I know that someone pointed out that it is
too tedious to click the links, but isn't the work what this is all about?

Some people have great talents for writing these sorts of documents -- I
don't know that this means they are a good contributor or not.

In addition, since this is a global initiative, some worthy contributors
may struggle with English...



-Chris


On Fri, Aug 11, 2017 at 11:03 AM, Madan Jampani 
wrote:

> All, I captured the comments and general feedback that emerged from this
> discussion into a set of guidelines for when someone can become a committer
> and what record of contributions they need to have to strengthen their
> case. It also has a link to a nomination template Tianqi created for a
> specific user (@eric-haibin-lin) as an example.
>
> Here is the wiki link:
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>
> I'd request the members to review it and provide feedback so that we can
> settle on a set of formal guidelines.
>
> Madan.
>
> On Fri, Aug 11, 2017 at 5:43 AM, Isabel Drost-Fromm 
> wrote:
>
> > On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote:
> > > The criteria should look not only at Quantity but at the Quality of
> work
> > as
> > > well.
> >
> > Just as one additional data point:
> >
> > http://community.apache.org/newcommitter.html is the Apache Community
> > Development Project's guidelines.
> >
> > For other tasks than coding see also here:
> > http://community.apache.org/committers/#assisting-with-
> > project-management-and-marketing
> >
> >
> > https://community.apache.org/apache-way/apache-project-
> > maturity-model.html#community for more on
> > the maturity model's take on community.
> >
> >
> > One thing to keep in mind: All successful OSS projects I came across at
> > some
> > point had to deal with topics that were very far away from writing actual
> > code.
> > In your committer guidelines you can make a conscious choice to
> explicitly
> > mention that those tasks will be rewarded as well - which in turn might
> > lead to
> > people who won't necessarily contribute code (either due to legal
> > constraints or
> > simply lack of interest or skills) to take these tasks up for you.
> >
> > I remember seeing discussions on whether to turn non-coding-contributors
> > into
> > committers recently, but my search-foo has left me, I don't find the
> > thread in
> > question anymore :/
> >
> > Isabel
> >
> >
> >
> > --
> > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh
> (most
> > likely involving some kind of mobile connection only.)
> >
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-11 Thread Madan Jampani
All, I captured the comments and general feedback that emerged from this
discussion into a set of guidelines for when someone can become a committer
and what record of contributions they need to have to strengthen their
case. It also has a link to a nomination template Tianqi created for a
specific user (@eric-haibin-lin) as an example.

Here is the wiki link:
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer

I'd request the members to review it and provide feedback so that we can
settle on a set of formal guidelines.

Madan.

On Fri, Aug 11, 2017 at 5:43 AM, Isabel Drost-Fromm 
wrote:

> On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote:
> > The criteria should look not only at Quantity but at the Quality of work
> as
> > well.
>
> Just as one additional data point:
>
> http://community.apache.org/newcommitter.html is the Apache Community
> Development Project's guidelines.
>
> For other tasks than coding see also here:
> http://community.apache.org/committers/#assisting-with-
> project-management-and-marketing
>
>
> https://community.apache.org/apache-way/apache-project-
> maturity-model.html#community for more on
> the maturity model's take on community.
>
>
> One thing to keep in mind: All successful OSS projects I came across at
> some
> point had to deal with topics that were very far away from writing actual
> code.
> In your committer guidelines you can make a conscious choice to explicitly
> mention that those tasks will be rewarded as well - which in turn might
> lead to
> people who won't necessarily contribute code (either due to legal
> constraints or
> simply lack of interest or skills) to take these tasks up for you.
>
> I remember seeing discussions on whether to turn non-coding-contributors
> into
> committers recently, but my search-foo has left me, I don't find the
> thread in
> question anymore :/
>
> Isabel
>
>
>
> --
> Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most
> likely involving some kind of mobile connection only.)
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-11 Thread Isabel Drost-Fromm
On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote:
> The criteria should look not only at Quantity but at the Quality of work as
> well.

Just as one additional data point:

http://community.apache.org/newcommitter.html is the Apache Community 
Development Project's guidelines.

For other tasks than coding see also here:
http://community.apache.org/committers/#assisting-with-project-management-and-marketing


https://community.apache.org/apache-way/apache-project-maturity-model.html#community
 for more on
the maturity model's take on community.


One thing to keep in mind: All successful OSS projects I came across at some
point had to deal with topics that were very far away from writing actual code.
In your committer guidelines you can make a conscious choice to explicitly
mention that those tasks will be rewarded as well - which in turn might lead to
people who won't necessarily contribute code (either due to legal constraints or
simply lack of interest or skills) to take these tasks up for you.

I remember seeing discussions on whether to turn non-coding-contributors into
committers recently, but my search-foo has left me, I don't find the thread in
question anymore :/

Isabel



-- 
Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most 
likely involving some kind of mobile connection only.)


Re: Formalize Committer Proposal and Application Procedure

2017-08-10 Thread Bhavin Thaker
I agree with Sebastian.

The criteria should look not only at Quantity but at the Quality of work as
well.

This page for Apache committer criteria describes the criteria pretty well.

https://hadoop.apache.org/committer_criteria.html


   - *A history of sustained contribution to the project. This is a way for
   a contributor to demonstrate their expertise in an area, and thus their
   ability to help review and commit contributions by others in that same
   area. Sustained contribution is also a way of demonstrating commitment to
   the project, essentially that someone will continue contributing even after
   they become a committer.*
   - *High-quality contributions. As experienced contributors, committers
   set an example for others in the project, and help inculcate a culture of
   high-quality contributions. For code contributions, this means clean,
   documented code which includes unit tests if appropriate and passes
   precommit checks. For reviews, this means thorough, actionable feedback,
   and a +1 vote (even non-binding) only when there is a high degree of
   confidence in the change.*
   - *Community involvement. Contributors are always expected to be polite,
   constructive, and respectful of others during community interactions.
   Disagreement can (and will) happen over technical issues, but the
   discussion should remain friendly and focused on technical merits.
   Committers also have the additional responsibility of mentoring newer
   contributors, as well as helping to grow the community through actions like
   responding to emails on the user and dev list.*


I would add another point that the committer should have the backbone to
say no to contributions that do NOT meet the high quality bar but yet
mentor the contributor in reaching that high bar. This is difficult to
quantify but is a quality that is expected to be demonstrated in various
conversations of the person being nominated to be the committer.

Bhavin Thaker.

On Wed, Aug 9, 2017 at 11:03 PM, Sebastian  wrote:

>
> Another thing might be that having too many committers makes it less
>> valuable to
>> become a committer and therefore discourage new people.
>>
>
> In my experience, quite the opposite is true: Having many committers is
> beneficial for a project and makes life easier for everybody. There's more
> eyes to look at code contributions, more people answer questions and it
> also makes it easier for other committers to take time outs from the
> project (which might be necessary if they change jobs, have kids, etc)
>
> I think the important thing to look at is not the number of committers,
> but the culture and processes in a project.
>
> Best,
> Sebastian
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-10 Thread Sebastian



Another thing might be that having too many committers makes it less valuable to
become a committer and therefore discourage new people.


In my experience, quite the opposite is true: Having many committers is 
beneficial for a project and makes life easier for everybody. There's 
more eyes to look at code contributions, more people answer questions 
and it also makes it easier for other committers to take time outs from 
the project (which might be necessary if they change jobs, have kids, etc)


I think the important thing to look at is not the number of committers, 
but the culture and processes in a project.


Best,
Sebastian


Re: Formalize Committer Proposal and Application Procedure

2017-08-09 Thread Chiyuan Zhang
On Fri, Aug 4, 2017 at 1:04 PM, Isabel Drost-Fromm 
wrote:

> On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote:
> > Suppose we lower the standard or completely remove the formal standard
> for
> > committers, then we could probably be able to get more committers from
> the
> > first type. But that might not necessarily be good to us
>
> Can you elaborate your reasoning here? (I'm not implying that I agree or
> disagree with you, I just want to understand where this fear is coming
> from.)
>
>
I think this depends on what committers could do (writing permission to the
repo? voting in decisions for the direction of the projects? etc.). Another
thing might be that having too many committers makes it less valuable to
become a committer and therefore discourage new people.


>
> > having people that could either contribute relatively important
> components
> > or provide longer term commitment to the project. But on the other hand,
> > having a standard for committers do not (I hope) discourage the first
> type
> > of contributors to contribute PRs.
>
> Let me tell you a little campfire story: Back in the old days of Mahout we
> implicitly had a relatively high bar for becoming a committer. People
> thought
> that in order to become committer they would have to contribute substantial
> patches, often full new algorithm implementations.
>
> What the project really needed were a lot of work polishing, optimising,
> cleaning, making easier to use, documenting etc.
>
> Due to the perception of requiring substantial contributions to get the
> reward of becoming committer however we never received much of the latter.
>

Yes, I totally agree that open source project survival really needs
continuous contributions from the committee and many maintenance and
polishing work. I would like to re-state that I support having a *clear*
policy or guideline for becoming committers, not necessarily one with very
high bar that requires substantial contributions. I think if we are able to
control the guidelines to a reasonable level and easy to follow and get
started, then this might even encourage new users to contribute.

chiyuan


>
>
> Lesson learnt for me: The way you setup your reward systems greatly
> influences which kind of help your project will receive.
>
>
> Isabel
>
> --
> Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most
> likely involving some kind of mobile connection only.)
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-08 Thread Tianqi Chen
We totally understand the apache way of doing things and the projects has
always been welcoming users as contributors from days of DMLC.  This
happens in MXNet, as well as other project, for example XGBoost (
https://github.com/dmlc/xgboost) , another project that originated from
DMLC have most of its committers recruited from user of the project(who
contributed heavily).

So we are all for being welcoming in terms of contributions, without
lock-down access of the code. This is actually exactly the reason why we
want to formalize this process. A new comitter should not be nominated
because he/she simply knows more PMCs, or he/she is in the "inner circle"
of the community. The nomination should be purely based on the
 contributions, supported by facts and statistics. Sometimes I get
complains about from contributors who say why this person is get
committer-ship while my contribution is more significant.  Having a public
standard makes this transparent and fair to all users who are contributing,
and encourages them to hold up to the standard.

Finally, the fact that such practice carries out in other successful Apache
projects(e.g. Mesos) put weights in this as well.

Tianqi


On Tue, Aug 8, 2017 at 1:12 PM, Isabel Drost-Fromm 
wrote:

>
>
> Am 4. August 2017 13:27:16 MESZ schrieb Chiyuan Zhang :
> >1. There are some people who contribute to MXNet due to something else
> >(e.g. he used MXNet in his project and would like to contribute back
> >examples, or bug fix, or new operators, etc.)
>
> Many Apache projects are building software where end users are developers,
> not unlike what happens at mxnet I suppose.
>
> Now from what I've seen a common pattern for successfully recruiting new
> committers, growing and diversifying communities is a scratch your own itch
> approach: I know of several ppl who came to an Apache project as mere
> users, who started fixing things they needed fixed and who became
> committers to projects before they knew what was happening to them. In my
> experience those are the people who turned into project members who stayed
> longer than anyone else, they had a vested interest in staying. Often over
> time these people turned into Foundation members, helping out in various
> ways, e.g. mentoring new projects entering through the incubator.
>
> From my experience, my advise would be to treat everyone on any of your
> lists as potential committer. Instead of trying to protect the project from
> evil by locking down access try to establish a project vision and
> contributing guidelines that make it easy to get involved in the right way
> - whatever that means for mxnet, community over code is core to how the
> foundation works because at the end of the day your project lives and dies
> with ppl being interested in spending time on it (or not).
>
> That shouldn't imply that it's not a good idea to write down how to become
> a committer, you'll get that question often soon enough and will get tired
> answering it ;)
>
>
> Hope this helps,
> Isabel
>
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-08 Thread Isabel Drost-Fromm


Am 4. August 2017 13:27:16 MESZ schrieb Chiyuan Zhang :
>1. There are some people who contribute to MXNet due to something else
>(e.g. he used MXNet in his project and would like to contribute back
>examples, or bug fix, or new operators, etc.)

Many Apache projects are building software where end users are developers, not 
unlike what happens at mxnet I suppose.

Now from what I've seen a common pattern for successfully recruiting new 
committers, growing and diversifying communities is a scratch your own itch 
approach: I know of several ppl who came to an Apache project as mere users, 
who started fixing things they needed fixed and who became committers to 
projects before they knew what was happening to them. In my experience those 
are the people who turned into project members who stayed longer than anyone 
else, they had a vested interest in staying. Often over time these people 
turned into Foundation members, helping out in various ways, e.g. mentoring new 
projects entering through the incubator.

From my experience, my advise would be to treat everyone on any of your lists 
as potential committer. Instead of trying to protect the project from evil by 
locking down access try to establish a project vision and contributing 
guidelines that make it easy to get involved in the right way - whatever that 
means for mxnet, community over code is core to how the foundation works 
because at the end of the day your project lives and dies with ppl being 
interested in spending time on it (or not).

That shouldn't imply that it's not a good idea to write down how to become a 
committer, you'll get that question often soon enough and will get tired 
answering it ;)


Hope this helps,
Isabel



-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Tianqi Chen
>
> Could you provide an example that provides a likely (imaginary if you'd
> like) candidate? Mu's a pretty bad example for a new committer :) From the
> attached doc I walk away thinking that I need to contribute for 2 years
> before I can become a committer.


For example, I think https://github.com/eric-haibin-lin meets this
standard, given his recent contribution to the sparse modules of mxnet and
his continuous effort on pushing this module.

Tianqi


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Tianqi Chen
My experience from the existing open-source project we have is that the
developers are willing to contribute back as long as the software they use
are hold up to a standard.

I do not meant to say that the contributions of the language,
documentations and others do not count as contributions to the project, but
substantial contributions of these (e.g. maintaining the documentation and
tutorials for half a year and contributed materials) are needed to become
comitter.

Have a clear public standard will actually encourage people to hold up to
that standard, and makes the comittership more valuable, thus providing
incentives for developers who are interested to put good effort into it.

Tianqi

On Fri, Aug 4, 2017 at 5:04 AM, Isabel Drost-Fromm 
wrote:

> On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote:
> > Suppose we lower the standard or completely remove the formal standard
> for
> > committers, then we could probably be able to get more committers from
> the
> > first type. But that might not necessarily be good to us
>
> Can you elaborate your reasoning here? (I'm not implying that I agree or
> disagree with you, I just want to understand where this fear is coming
> from.)
>
>
> > having people that could either contribute relatively important
> components
> > or provide longer term commitment to the project. But on the other hand,
> > having a standard for committers do not (I hope) discourage the first
> type
> > of contributors to contribute PRs.
>
> Let me tell you a little campfire story: Back in the old days of Mahout we
> implicitly had a relatively high bar for becoming a committer. People
> thought
> that in order to become committer they would have to contribute substantial
> patches, often full new algorithm implementations.
>
> What the project really needed were a lot of work polishing, optimising,
> cleaning, making easier to use, documenting etc.
>
> Due to the perception of requiring substantial contributions to get the
> reward of becoming committer however we never received much of the latter.
>
>
> Lesson learnt for me: The way you setup your reward systems greatly
> influences which kind of help your project will receive.
>
>
> Isabel
>
> --
> Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most
> likely involving some kind of mobile connection only.)
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Tianqi Chen
FYI here is the comitter checklist from Apache Mesos
http://mesos.apache.org/documentation/latest/committer-candidate-checklist/
which I mainly adopted from

Tianqi

On Fri, Aug 4, 2017 at 8:14 AM, Madan Jampani 
wrote:

> There is a middle ground here. Instead of saying someone either has full
> committer privileges or zero, an alternative is to have scope of ownership
> start small and localized to modules or source folders where their primary
> contributions currently lie. For example, there are folks who contributed
> full languages bindings, or very good examples/tutorials.
>
> Over time, depending on the scope and complexity of their contributions
> they can be nominated to have their commit privileges broadened or even
> become core committers. Core committers have full commit privileges.
>
> Irrespective of whether some one is committer or not, we should all be
> using the PR process and opening up contributions for review/feedback.
>
> Madan
>
>
>
> On Fri, Aug 4, 2017 at 5:04 AM, Isabel Drost-Fromm 
> wrote:
>
> > On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote:
> > > Suppose we lower the standard or completely remove the formal standard
> > for
> > > committers, then we could probably be able to get more committers from
> > the
> > > first type. But that might not necessarily be good to us
> >
> > Can you elaborate your reasoning here? (I'm not implying that I agree or
> > disagree with you, I just want to understand where this fear is coming
> > from.)
> >
> >
> > > having people that could either contribute relatively important
> > components
> > > or provide longer term commitment to the project. But on the other
> hand,
> > > having a standard for committers do not (I hope) discourage the first
> > type
> > > of contributors to contribute PRs.
> >
> > Let me tell you a little campfire story: Back in the old days of Mahout
> we
> > implicitly had a relatively high bar for becoming a committer. People
> > thought
> > that in order to become committer they would have to contribute
> substantial
> > patches, often full new algorithm implementations.
> >
> > What the project really needed were a lot of work polishing, optimising,
> > cleaning, making easier to use, documenting etc.
> >
> > Due to the perception of requiring substantial contributions to get the
> > reward of becoming committer however we never received much of the
> latter.
> >
> >
> > Lesson learnt for me: The way you setup your reward systems greatly
> > influences which kind of help your project will receive.
> >
> >
> > Isabel
> >
> > --
> > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh
> (most
> > likely involving some kind of mobile connection only.)
> >
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Madan Jampani
There is a middle ground here. Instead of saying someone either has full
committer privileges or zero, an alternative is to have scope of ownership
start small and localized to modules or source folders where their primary
contributions currently lie. For example, there are folks who contributed
full languages bindings, or very good examples/tutorials.

Over time, depending on the scope and complexity of their contributions
they can be nominated to have their commit privileges broadened or even
become core committers. Core committers have full commit privileges.

Irrespective of whether some one is committer or not, we should all be
using the PR process and opening up contributions for review/feedback.

Madan



On Fri, Aug 4, 2017 at 5:04 AM, Isabel Drost-Fromm 
wrote:

> On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote:
> > Suppose we lower the standard or completely remove the formal standard
> for
> > committers, then we could probably be able to get more committers from
> the
> > first type. But that might not necessarily be good to us
>
> Can you elaborate your reasoning here? (I'm not implying that I agree or
> disagree with you, I just want to understand where this fear is coming
> from.)
>
>
> > having people that could either contribute relatively important
> components
> > or provide longer term commitment to the project. But on the other hand,
> > having a standard for committers do not (I hope) discourage the first
> type
> > of contributors to contribute PRs.
>
> Let me tell you a little campfire story: Back in the old days of Mahout we
> implicitly had a relatively high bar for becoming a committer. People
> thought
> that in order to become committer they would have to contribute substantial
> patches, often full new algorithm implementations.
>
> What the project really needed were a lot of work polishing, optimising,
> cleaning, making easier to use, documenting etc.
>
> Due to the perception of requiring substantial contributions to get the
> reward of becoming committer however we never received much of the latter.
>
>
> Lesson learnt for me: The way you setup your reward systems greatly
> influences which kind of help your project will receive.
>
>
> Isabel
>
> --
> Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most
> likely involving some kind of mobile connection only.)
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Minjie Wang
There are trade-offs. On one side, a small group of "core" committers who
understands the whole picture makes the project move swiftly and safely. On
the other side, the reward of becoming committer is really important to
encourage more contributors. I think Tianqi's proposal gives a good
criterion of "core" committers. So I would like to see something like:
(1) Easy to become a committer as a reward of your contribution.
(2) Hard to be promoted as a "core" committer unless you're likely to
contribute to the project for a longer-term.
(Similar to Blizzard's game concept: "easy to learn and difficult to
master" :) )

Anyhow, I am not sure Apache's management allows this or not. From my bare
understanding, it seems to be quite flat and committer is the only viable
title? Or could we make this an implicit rule?

On Fri, Aug 4, 2017 at 8:04 AM, Isabel Drost-Fromm 
wrote:

> On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote:
> > Suppose we lower the standard or completely remove the formal standard
> for
> > committers, then we could probably be able to get more committers from
> the
> > first type. But that might not necessarily be good to us
>
> Can you elaborate your reasoning here? (I'm not implying that I agree or
> disagree with you, I just want to understand where this fear is coming
> from.)
>
>
> > having people that could either contribute relatively important
> components
> > or provide longer term commitment to the project. But on the other hand,
> > having a standard for committers do not (I hope) discourage the first
> type
> > of contributors to contribute PRs.
>
> Let me tell you a little campfire story: Back in the old days of Mahout we
> implicitly had a relatively high bar for becoming a committer. People
> thought
> that in order to become committer they would have to contribute substantial
> patches, often full new algorithm implementations.
>
> What the project really needed were a lot of work polishing, optimising,
> cleaning, making easier to use, documenting etc.
>
> Due to the perception of requiring substantial contributions to get the
> reward of becoming committer however we never received much of the latter.
>
>
> Lesson learnt for me: The way you setup your reward systems greatly
> influences which kind of help your project will receive.
>
>
> Isabel
>
> --
> Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most
> likely involving some kind of mobile connection only.)
>



-- 
Minjie Wang
*New York University | Computer Science*
715 Broadway, New York, NY, 10009


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Isabel Drost-Fromm
On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote:
> Suppose we lower the standard or completely remove the formal standard for
> committers, then we could probably be able to get more committers from the
> first type. But that might not necessarily be good to us

Can you elaborate your reasoning here? (I'm not implying that I agree or
disagree with you, I just want to understand where this fear is coming
from.)


> having people that could either contribute relatively important components
> or provide longer term commitment to the project. But on the other hand,
> having a standard for committers do not (I hope) discourage the first type
> of contributors to contribute PRs.

Let me tell you a little campfire story: Back in the old days of Mahout we
implicitly had a relatively high bar for becoming a committer. People thought
that in order to become committer they would have to contribute substantial
patches, often full new algorithm implementations.

What the project really needed were a lot of work polishing, optimising,
cleaning, making easier to use, documenting etc.

Due to the perception of requiring substantial contributions to get the
reward of becoming committer however we never received much of the latter.


Lesson learnt for me: The way you setup your reward systems greatly
influences which kind of help your project will receive.


Isabel

-- 
Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most 
likely involving some kind of mobile connection only.)


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Chiyuan Zhang
Hi all, just want to share my bits. I like the idea of formalizing the
committer proposal mechanism. The actual standard for what count as good
enough for a committer could be discussed.

I think the worrying of not being able to recruit new committers might not
be a serious problem. I am thinking about two types of people here

1. There are some people who contribute to MXNet due to something else
(e.g. he used MXNet in his project and would like to contribute back
examples, or bug fix, or new operators, etc.)

2. There are some people who is interested in MXNet development and would
like to work on it for a relatively long term (maintaining or developing)
or would like to work on a relatively major component.

My point is that for the first type of contributors, we might not need to
propose everyone of them as Apache committers (if I understand correctly,
everyone can submit a PR, even without committer permission, right?). On
the other hand, the second type of contributors are our main target for
committers, and I think for those people, having a more clear standard
(again the actual standard could be debatable) for committer would not be a
huge barrier.

Suppose we lower the standard or completely remove the formal standard for
committers, then we could probably be able to get more committers from the
first type. But that might not necessarily be good to us --- in terms of
having people that could either contribute relatively important components
or provide longer term commitment to the project. But on the other hand,
having a standard for committers do not (I hope) discourage the first type
of contributors to contribute PRs.

Best,
Chiyuan

On Fri, Aug 4, 2017 at 8:42 AM, Henri Yandell  wrote:

> I worry that it creates a high barrier to entry.
>
> It's a far more common pattern for a project to do poorly at recruiting new
> committers, than it is for one to recruit too many.
>
> Could you provide an example that provides a likely (imaginary if you'd
> like) candidate? Mu's a pretty bad example for a new committer :) From the
> attached doc I walk away thinking that I need to contribute for 2 years
> before I can become a committer.
>
> Hen
>
> On Thu, Aug 3, 2017 at 9:49 AM, Ziheng Jiang  wrote:
>
> > Forward my comment in private mail list:
> >
> > I agree that it would be nice to have some quantitative standards to
> > evaluate the candidates. Let's encourage the future candidates do this.
> >
> > - Ziheng
> >
> > On Thu, Aug 3, 2017 at 09:44 Mu Li  wrote:
> >
> > > It seems that this thread didn't show in the dev list.
> > >
> > > Totally agree that we should make the committer nomination more formal.
> > >
> > > -- Forwarded message --
> > > From: Tianqi Chen 
> > > Date: Wed, Aug 2, 2017 at 4:20 PM
> > > Subject: Formalize Committer Proposal and Application Procedure
> > > To: priv...@mxnet.incubator.apache.org
> > >
> > >
> > > Hi Guys:
> > >  As I mentioned in another thread, I personally think the current
> > > committer proposal and application process is too informal.
> > >  As MXNet grows larger and the community involves, I think it would
> > be
> > > very helpful to formalize the process and provide a clear standard for
> > what
> > > are we looking for in the comitter proposal process, and allow us to
> > > evaluate based on the concrete evidence listed in the application to
> > > promote the comitters.
> > >  This will setup a good standard for the contributors, as well as
> > > provide solid material to back our decisions. After did some search, I
> > > created this application template based on the committer application
> from
> > > Apache Mesos. I wrote it from the perspective of myself.
> > >  https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq
> > > DuhF9kQd53BB4iUxGn4M/edit?usp=sharing
> > >
> > >  I would recommend this to become the mandatory thing for the
> future
> > > committer nomination and voting, as well as the re-evaluation standard
> of
> > > current comitters when we graduate from the incubator project.
> > >
> > > Tianqi
> > >
> > --
> > Ziheng Jiang
> > Fudan University | Computer Science
> >
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Isabel Drost-Fromm
On Fri, Aug 04, 2017 at 12:42:12AM -0700, Henri Yandell wrote:
> I worry that it creates a high barrier to entry.

+1 from my side to that worry.


Isabel



Re: Formalize Committer Proposal and Application Procedure

2017-08-04 Thread Henri Yandell
I worry that it creates a high barrier to entry.

It's a far more common pattern for a project to do poorly at recruiting new
committers, than it is for one to recruit too many.

Could you provide an example that provides a likely (imaginary if you'd
like) candidate? Mu's a pretty bad example for a new committer :) From the
attached doc I walk away thinking that I need to contribute for 2 years
before I can become a committer.

Hen

On Thu, Aug 3, 2017 at 9:49 AM, Ziheng Jiang  wrote:

> Forward my comment in private mail list:
>
> I agree that it would be nice to have some quantitative standards to
> evaluate the candidates. Let's encourage the future candidates do this.
>
> - Ziheng
>
> On Thu, Aug 3, 2017 at 09:44 Mu Li  wrote:
>
> > It seems that this thread didn't show in the dev list.
> >
> > Totally agree that we should make the committer nomination more formal.
> >
> > -- Forwarded message --
> > From: Tianqi Chen 
> > Date: Wed, Aug 2, 2017 at 4:20 PM
> > Subject: Formalize Committer Proposal and Application Procedure
> > To: priv...@mxnet.incubator.apache.org
> >
> >
> > Hi Guys:
> >  As I mentioned in another thread, I personally think the current
> > committer proposal and application process is too informal.
> >  As MXNet grows larger and the community involves, I think it would
> be
> > very helpful to formalize the process and provide a clear standard for
> what
> > are we looking for in the comitter proposal process, and allow us to
> > evaluate based on the concrete evidence listed in the application to
> > promote the comitters.
> >  This will setup a good standard for the contributors, as well as
> > provide solid material to back our decisions. After did some search, I
> > created this application template based on the committer application from
> > Apache Mesos. I wrote it from the perspective of myself.
> >  https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq
> > DuhF9kQd53BB4iUxGn4M/edit?usp=sharing
> >
> >  I would recommend this to become the mandatory thing for the future
> > committer nomination and voting, as well as the re-evaluation standard of
> > current comitters when we graduate from the incubator project.
> >
> > Tianqi
> >
> --
> Ziheng Jiang
> Fudan University | Computer Science
>


Re: Formalize Committer Proposal and Application Procedure

2017-08-03 Thread Ziheng Jiang
Forward my comment in private mail list:

I agree that it would be nice to have some quantitative standards to
evaluate the candidates. Let's encourage the future candidates do this.

- Ziheng

On Thu, Aug 3, 2017 at 09:44 Mu Li  wrote:

> It seems that this thread didn't show in the dev list.
>
> Totally agree that we should make the committer nomination more formal.
>
> -- Forwarded message --
> From: Tianqi Chen 
> Date: Wed, Aug 2, 2017 at 4:20 PM
> Subject: Formalize Committer Proposal and Application Procedure
> To: priv...@mxnet.incubator.apache.org
>
>
> Hi Guys:
>  As I mentioned in another thread, I personally think the current
> committer proposal and application process is too informal.
>  As MXNet grows larger and the community involves, I think it would be
> very helpful to formalize the process and provide a clear standard for what
> are we looking for in the comitter proposal process, and allow us to
> evaluate based on the concrete evidence listed in the application to
> promote the comitters.
>  This will setup a good standard for the contributors, as well as
> provide solid material to back our decisions. After did some search, I
> created this application template based on the committer application from
> Apache Mesos. I wrote it from the perspective of myself.
>  https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq
> DuhF9kQd53BB4iUxGn4M/edit?usp=sharing
>
>  I would recommend this to become the mandatory thing for the future
> committer nomination and voting, as well as the re-evaluation standard of
> current comitters when we graduate from the incubator project.
>
> Tianqi
>
-- 
Ziheng Jiang
Fudan University | Computer Science