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
I worry in this case that the focus may, for some,
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
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
Just as one additional data point:
http://community.apache.org/newcommitter.html is the Apache Community
Development Project's guidelines.
I agree with Sebastian.
The criteria should look not only at Quantity but at the Quality of work as
This page for Apache committer criteria describes the criteria pretty well.
- *A history of sustained contribution to the project.
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
On Fri, Aug 4, 2017 at 1:04 PM, 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
> > committers, then we could probably be able to get more committers
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
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
> 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
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
FYI here is the comitter checklist from Apache Mesos
which I mainly adopted from
On Fri, Aug 4, 2017 at 8:14 AM, Madan Jampani
> There is a middle ground here. Instead of saying
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
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
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
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
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.
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
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.
On Thu, Aug 3, 2017 at 09:44 Mu Li wrote:
> It seems that this thread didn't show
Mail list logo