Re: MXNet project web page

2017-08-04 Thread Chris Mattmann
Check out this guide that shows how to conform to the Apache website
policies:

https://www.apache.org/foundation/marks/pmcs#introduction 

Cheers,
Chris


On 8/4/17, 11:20 AM, "Ly Nguyen"  wrote:

Hi Isabelle,

As Mu mentioned we are in the process of transferring our website to
http://mxnet.incubator.apache.org so nothing there is official. Thank you
for the note about the disclaimer about be an incubator though.

Is this the writing that we need to add?:

"Apache MXNet (incubating) is an effort undergoing incubation at The
Apache Software Foundation (ASF), sponsored by the name of Apache
Incubator PMC. Incubation is required of all newly accepted
projects until a further review indicates that the
infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF
projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate
that the project has yet to be fully endorsed by the ASF."

On Fri, Aug 4, 2017 at 9:32 AM, Mu Li  wrote:

> I suggest using the current logo on http://mxnet.io
>
> We on the way to transfer the website to http://mxnet.incubator.apache.org
>
>
> On Fri, Aug 4, 2017 at 2:35 AM, Isabel Drost-Fromm 
> wrote:
>
> > Hi,
> >
> > I'm currently in the process of creating a slide deck and wanted to use
> the
> > mxnet logo as part of that presentation.
> >
> > So I want ahead and opened
> >
> > http://mxnet.incubator.apache.org
> >
> > I found a directory listing including a test directory. Is that 
expected?
> >
> > Clicking on the "test" directory opened something that looked a whole 
lot
> > like a
> > lovely project page, except it didn't include the standard Apache
> incubator
> > branding disclaimer for podlings:
> >
> > http://incubator.apache.org/guides/branding.html#disclaimers
> >
> >
> > I checked the Github Repo of the project, the Logo there still includes
> > dmlc as
> > org and outside of the news list doesn't include any reference to the
> > project
> > being Apache mxnet (incubating).
> >
> > Thinking that maybe ppl are working on a new site/logo already I checked
> > the
> > issue tracker. All I found was a discussion that seems to have subsided
> 2.5
> > months ago: https://github.com/apache/incubator-mxnet/issues/6103
> >
> > So here I am wondering which logo to include :)
> >
> > Isabel
> >
> >
> >
>





Re: MXNet project web page

2017-08-04 Thread Ly Nguyen
Hi Isabelle,

As Mu mentioned we are in the process of transferring our website to
http://mxnet.incubator.apache.org so nothing there is official. Thank you
for the note about the disclaimer about be an incubator though.

Is this the writing that we need to add?:

"Apache MXNet (incubating) is an effort undergoing incubation at The
Apache Software Foundation (ASF), sponsored by the name of Apache
Incubator PMC. Incubation is required of all newly accepted
projects until a further review indicates that the
infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF
projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate
that the project has yet to be fully endorsed by the ASF."

On Fri, Aug 4, 2017 at 9:32 AM, Mu Li  wrote:

> I suggest using the current logo on http://mxnet.io
>
> We on the way to transfer the website to http://mxnet.incubator.apache.org
>
>
> On Fri, Aug 4, 2017 at 2:35 AM, Isabel Drost-Fromm 
> wrote:
>
> > Hi,
> >
> > I'm currently in the process of creating a slide deck and wanted to use
> the
> > mxnet logo as part of that presentation.
> >
> > So I want ahead and opened
> >
> > http://mxnet.incubator.apache.org
> >
> > I found a directory listing including a test directory. Is that expected?
> >
> > Clicking on the "test" directory opened something that looked a whole lot
> > like a
> > lovely project page, except it didn't include the standard Apache
> incubator
> > branding disclaimer for podlings:
> >
> > http://incubator.apache.org/guides/branding.html#disclaimers
> >
> >
> > I checked the Github Repo of the project, the Logo there still includes
> > dmlc as
> > org and outside of the news list doesn't include any reference to the
> > project
> > being Apache mxnet (incubating).
> >
> > Thinking that maybe ppl are working on a new site/logo already I checked
> > the
> > issue tracker. All I found was a discussion that seems to have subsided
> 2.5
> > months ago: https://github.com/apache/incubator-mxnet/issues/6103
> >
> > So here I am wondering which logo to include :)
> >
> > Isabel
> >
> >
> >
>


Re: MXNet project web page

2017-08-04 Thread Mu Li
I suggest using the current logo on http://mxnet.io

We on the way to transfer the website to http://mxnet.incubator.apache.org


On Fri, Aug 4, 2017 at 2:35 AM, Isabel Drost-Fromm 
wrote:

> Hi,
>
> I'm currently in the process of creating a slide deck and wanted to use the
> mxnet logo as part of that presentation.
>
> So I want ahead and opened
>
> http://mxnet.incubator.apache.org
>
> I found a directory listing including a test directory. Is that expected?
>
> Clicking on the "test" directory opened something that looked a whole lot
> like a
> lovely project page, except it didn't include the standard Apache incubator
> branding disclaimer for podlings:
>
> http://incubator.apache.org/guides/branding.html#disclaimers
>
>
> I checked the Github Repo of the project, the Logo there still includes
> dmlc as
> org and outside of the news list doesn't include any reference to the
> project
> being Apache mxnet (incubating).
>
> Thinking that maybe ppl are working on a new site/logo already I checked
> the
> issue tracker. All I found was a discussion that seems to have subsided 2.5
> months ago: https://github.com/apache/incubator-mxnet/issues/6103
>
> So here I am wondering which logo to include :)
>
> Isabel
>
>
>


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


MXNet project web page

2017-08-04 Thread Isabel Drost-Fromm
Hi,

I'm currently in the process of creating a slide deck and wanted to use the
mxnet logo as part of that presentation.

So I want ahead and opened

http://mxnet.incubator.apache.org

I found a directory listing including a test directory. Is that expected?

Clicking on the "test" directory opened something that looked a whole lot like a
lovely project page, except it didn't include the standard Apache incubator
branding disclaimer for podlings:

http://incubator.apache.org/guides/branding.html#disclaimers


I checked the Github Repo of the project, the Logo there still includes dmlc as
org and outside of the news list doesn't include any reference to the project
being Apache mxnet (incubating).

Thinking that maybe ppl are working on a new site/logo already I checked the
issue tracker. All I found was a discussion that seems to have subsided 2.5
months ago: https://github.com/apache/incubator-mxnet/issues/6103

So here I am wondering which logo to include :)

Isabel




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
>