GitHub service disruption

[Marco de Abreu]

Hello,

FYI, GitHub is currently having a service disruption which results in their
databases not acting consistent. For me, this impaired creating issues and
pull requests - they have been created with a proper ID, but they are not
available with a subsequent request. This might also impair the CI system
since we rely on GitHub.

More information available at https://status.github.com/messages

Best regards,
Marco

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Qing Lan]

+1
Let's have a reviewer list somewhere with a certain format: such as C++, Gluon, 
Scala/Java based on language or some other category. etc. In the future, label 
bot would automatically assign reviewers based on this kind of documentation.

Thanks,
Qing

On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:

+1
I also suggest add reviewer list link to the PR template, so that
developers can easily request review from those reviewers.
On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen  wrote:
>
> I was suggesting something more concrete:
>
> - Add a Reviewers section to
> https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md to
> list a list of Reviewers.
> - This is a "pesudo role", but holds weight as committers should 
highly
> value their reviews during the PR process.
> - The committers/PMC could actively look for good contributors and 
nominate
> them as Reviewer.
> - Contributors are encouraged to seek reviews from the list of reviewers.
> - The committers should actively solicit code reviews from the reviewers
> when reviewing PRs and take their reviews into serious consideration.
>
> - PMCs should actively look for new committers in the current Reviewers
>- Notably, the history reviews plus contribution likely will provide a
> good indication on whether the person can uphold the quality standard of
> the codebase, and provide helpful feedbacks(which is the trait that needed
> from committer to merge code)
>
> Tianqi
>
>
> On Sun, Oct 21, 2018 at 5:13 PM Steffen Rochel 
> wrote:
>
> > +1
> > With the release announcement for MXNet 1.3 all contributors incl. code
> > reviewers have been recognized. I suggest all future release 
announcements
> > should include such recognition. Are you suggesting to highlight most
> > active reviewers in release announcement or regularly (e.g. monthly),
> > specifically from non-committers?
> >
> > On Sun, Oct 21, 2018 at 10:11 AM Tianqi Chen  wrote:
> >
> > > Also re another email-thread(I sent out one with my institutional 
email
> > > which get blocked initially, so this one was a bit duplication of 
that).
> > I
> > > think it should really be the job of committers to recognize potential
> > > reviewers, github also makes it easier to do so, e.g.
> > >
> > >
> > 
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93&q=reviewed-by%3Apiiswrong
> > >
> > > Tianqi
> > >
> > > On Fri, Oct 19, 2018 at 12:05 PM Carin Meier 
> > wrote:
> > >
> > > > +1 Great idea. Adding a name to the contributor list is a good idea.
> > > Also,
> > > > I've found that thanking the person for the review on the PR is 
another
> > > way
> > > > to express gratitude for their time and effort.
> > > >
> > > > On Fri, Oct 19, 2018 at 2:51 PM Tianqi Chen  
wrote:
> > > >
> > > > > Dear MXNet Community:
> > > > >
> > > > > There is a great discussion going on in terms of lowering the 
barrier
> > > of
> > > > > entries and encourage more contribution to the project.  One of 
the
> > > > general
> > > > > goals is to encourage a broader pool of contributions. I want to 
make
> > > the
> > > > > following proposal:
> > > > >
> > > > > Besides Committers and PMC, let us also recognize Reviewers in the
> > > > > community.  This is a "pseudo role" as there is no such official 
role
> > > in
> > > > > Apache. But I want to explore the possibility of recognizing 
active
> > > > > reviewers for example, by adding a list of names in the 
contributor
> > > list.
> > > > > In general, I find it is really helpful to have more code reviews.
> > > > > Recognizing good reviewers early enables us to find committer
> > > candidates,
> > > > > and encourage them to contribute and understand what is the bar of
> > code
> > > > > quality that is required to merge the code.
> > > > >
> > > > > This can provide the community with more evidence when recruiting 
new
> > > > > committers. After all the write access of committership is about 
to
> > the
> > > > > code and understand the consequence of the responsibility -- 
which is
> > > > > usually can be found in high-quality review history.
> > > > >
> > > > > Please let me know what you think.
> > > > >
> > > > > Tianqi
> > > > >
> > > >
> > >
> >



-- 
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

I want to clarify that this would not prevent Amazon contributors from
being nominated. Nor it would prevent collaboration between Amazon
employees. A good thing about Apache is that everything is recorded and
presented to the entire community, this includes the dev list,
github review/commit history, documentation, wiki.

Specifically to Amazon contributors, there are non-Amazon PMCs can watch
these evidence and bring these contributors on board -- and I am very
certain this would be the case. If the problem that there are too few
non-Amazon PMCs, then it wouldn't hurt to try to get more on board, and
then get them in the term to nominate PMC contributors.

One of the key criteria of graduation for an Apache Project is that it
should not be controlled by a single entity, I think to be able to execute
this guideline is exactly a good test to check if we pass that bar.

Tianqi

On Sun, Oct 21, 2018 at 9:19 PM Naveen Swamy  wrote:

> this suggestion looks like it is putting the onus on contributors to
> collaborate with contributors outside their org to get nominated to be
> committer or a PMC of this project.
> Every organization has its own business goals, on the way to meet their
> objectives if their employees happen to be great contributors to this
> project, I would expect PMC members(wearing their Apache hat) to recognize
> them and give them a greater role in the project.
> I would assume the responsibility of increasing the diversity is solely
> upon the PMC members, the PMC should look ways to evangelize the project,
> mentor new contributors, nominate and make them a part of the project's
> journey.
> I do agree that we have to increase the diversity and suggest to explore
> different ways( for example collaborate with other successful Open source
> projects to get their members excited about MXNet).
>
> Guideline or not, I cannot agree to this in principle.
> -1
>
>
> On Sun, Oct 21, 2018 at 8:22 PM Tianqi Chen 
> wrote:
>
> > >
> > >  Many potential committers and
> > > PMC won’t interact with the non-Amazonians at all (since there are so
> > few),
> > > so they’d be relegated to obscurity and hopelessness by default.
> > >
> >
> > If potential contributors do not comes from Amazon, then the Amazonian
> PMC
> > can nominate them :)  If the potential contributors does comes from
> Amazon,
> > then it is not a bad thing to interact with bigger part of the
> community. I
> > can expect that as more non-Amazonian contributors get nonimated, this
> > would make the process more healthy.
> >
> > Like neural networks, any guideline can be played in adverserial fashion
> > (e.g. in the case of the gray areas). I think having a goodwill to push
> the
> > guideline will understandably make people to work together.
> >
> > Afterall, this is an Apache project that should goes beyond a single
> > company
> >
> > Tianqi
> >
> > >
> > >
> > >
> > > On Sun, Oct 21, 2018 at 5:06 PM Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > Hi Tianqi -
> > > > +1 . I like the idea to grow diversity at the project and encourage
> > > > communication beyond people sitting next to each other. I also
> support
> > > the
> > > > way you described as guideline, not has a hard rule. I think it is
> > > > important we focus on merit and contributions when evaluating nominee
> > for
> > > > committer and PPMC.
> > > >
> > > > Carin started a draft document for revised criteria for committer and
> > > PPMC
> > > > membership
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > >.
> > > > I suggest to contribute, provide feedback and suggestion including
> your
> > > > proposal.
> > > >
> > > > Steffen
> > > >
> > > > On Sun, Oct 21, 2018 at 10:22 AM Tianqi Chen 
> > wrote:
> > > >
> > > > > Dear MXNet Community:
> > > > >
> > > > > There has been a great discussion going on in terms of
> > > > > PMC/Committer Criteria.  As a community move forward, it is
> important
> > > to
> > > > > make the community inclusive to everyone and encourage folks to
> work
> > > > > together.
> > > > >
> > > > > I want to propose the following proposal courtesy: when a PMC
> > proposes
> > > a
> > > > > committer/PMC member, for courtesy of the community, she/he should
> > only
> > > > > propose a person from a different organization(company).
> > > > >
> > > > > The idea behind that is that the Apache project goes beyond a
> single
> > > > > organization, it is important to recognize others, including those
> > > from a
> > > > > different organization in the community, and get your merit being
> > > > > recognized by others.
> > > > >
> > > > > Admittedly, this would also give more "power" to the PMC members
> from
> > > > > minority organizations -- which I think is a good thing. This might
> > > also
> > > > > encourage everyone to work together and talk to folks who are
> beyond
> > > your
> > > > > next door
> > > >

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

I want to clarify that this would not prevent Amazon contributors from
being nominated. Nor it would prevent collaboration between Amazon
employees. A good thing about Apache is that everything is recorded and
presented to the entire community, this includes the dev list,
github review/commit history, documentation, wiki.

Specifically to Amazon contributors, there are non-Amazon PMCs can watch
these evidence and bring these contributors on board -- and I am very
certain this would be the case. If the problem that there are too few
non-Amazon PMCs, then it wouldn't hurt to try to get more on board, and
then get them in the term to nominate PMC contributors.

One of the key criteria of graduation for an Apache Project is that it
should not be controlled by a single entity. I think that whether we can
execute this guideline is exactly a good test to check if we pass that bar.

On Sun, Oct 21, 2018 at 9:19 PM Naveen Swamy  wrote:

> this suggestion looks like it is putting the onus on contributors to
> collaborate with contributors outside their org to get nominated to be
> committer or a PMC of this project.
> Every organization has its own business goals, on the way to meet their
> objectives if their employees happen to be great contributors to this
> project, I would expect PMC members(wearing their Apache hat) to recognize
> them and give them a greater role in the project.
> I would assume the responsibility of increasing the diversity is solely
> upon the PMC members, the PMC should look ways to evangelize the project,
> mentor new contributors, nominate and make them a part of the project's
> journey.
> I do agree that we have to increase the diversity and suggest to explore
> different ways( for example collaborate with other successful Open source
> projects to get their members excited about MXNet).
>
> Guideline or not, I cannot agree to this in principle.
> -1
>
>
> On Sun, Oct 21, 2018 at 8:22 PM Tianqi Chen 
> wrote:
>
> > >
> > >  Many potential committers and
> > > PMC won’t interact with the non-Amazonians at all (since there are so
> > few),
> > > so they’d be relegated to obscurity and hopelessness by default.
> > >
> >
> > If potential contributors do not comes from Amazon, then the Amazonian
> PMC
> > can nominate them :)  If the potential contributors does comes from
> Amazon,
> > then it is not a bad thing to interact with bigger part of the
> community. I
> > can expect that as more non-Amazonian contributors get nonimated, this
> > would make the process more healthy.
> >
> > Like neural networks, any guideline can be played in adverserial fashion
> > (e.g. in the case of the gray areas). I think having a goodwill to push
> the
> > guideline will understandably make people to work together.
> >
> > Afterall, this is an Apache project that should goes beyond a single
> > company
> >
> > Tianqi
> >
> > >
> > >
> > >
> > > On Sun, Oct 21, 2018 at 5:06 PM Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > Hi Tianqi -
> > > > +1 . I like the idea to grow diversity at the project and encourage
> > > > communication beyond people sitting next to each other. I also
> support
> > > the
> > > > way you described as guideline, not has a hard rule. I think it is
> > > > important we focus on merit and contributions when evaluating nominee
> > for
> > > > committer and PPMC.
> > > >
> > > > Carin started a draft document for revised criteria for committer and
> > > PPMC
> > > > membership
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > >.
> > > > I suggest to contribute, provide feedback and suggestion including
> your
> > > > proposal.
> > > >
> > > > Steffen
> > > >
> > > > On Sun, Oct 21, 2018 at 10:22 AM Tianqi Chen 
> > wrote:
> > > >
> > > > > Dear MXNet Community:
> > > > >
> > > > > There has been a great discussion going on in terms of
> > > > > PMC/Committer Criteria.  As a community move forward, it is
> important
> > > to
> > > > > make the community inclusive to everyone and encourage folks to
> work
> > > > > together.
> > > > >
> > > > > I want to propose the following proposal courtesy: when a PMC
> > proposes
> > > a
> > > > > committer/PMC member, for courtesy of the community, she/he should
> > only
> > > > > propose a person from a different organization(company).
> > > > >
> > > > > The idea behind that is that the Apache project goes beyond a
> single
> > > > > organization, it is important to recognize others, including those
> > > from a
> > > > > different organization in the community, and get your merit being
> > > > > recognized by others.
> > > > >
> > > > > Admittedly, this would also give more "power" to the PMC members
> from
> > > > > minority organizations -- which I think is a good thing. This might
> > > also
> > > > > encourage everyone to work together and talk to folks who are
> beyond
> > > your
> > > > > next door
> > > > >

Re: Apache MXNet (incubating) Python Docker Images

[kellen sunderland]

Hey Sergio, I think it's mostly to keep the Dockerfile size down by
matching the system python package.  Of course people can extend the image
and use python 3.6 / 3.7.  I think we should follow this up with an update
to the new Ubuntu LTS version as a base docker image at which point it
would use python 3.6.

On Fri, Oct 19, 2018 at 6:41 AM Sergio Fernández  wrote:

> Python 2.7 reaches End of Life by the end on 2019.Take that into account.
>
> About Python 3.x, why not having 3.6 docker images? I know 3.7 is not yet
> supposed by MXNet. But starting with 3 5 doesn't make much sense for me
>
> On Wed, Oct 17, 2018, 11:52 Meghna Baijal 
> wrote:
>
> > Hi All,
> >
> > I am currently in the process of updating the python docker images for
> > Apache MXNet such that they are built on top of the pip binaries.
> > Until now these were built to use python 2.7 but with an upcoming PR I am
> > also adding python 3.5 docker images. I would like to know the
> community’s
> > preference on whether I should keep the *Python 2.7 Docker image as the
> > default or should I move to Python 3.5 as the default version*?
> >
> > [1] The new python2 dockerfiles and build script can be found here.
> > <
> >
> https://github.com/apache/incubator-mxnet/tree/master/docker/docker-python
> > >
> > [2] The PR for python3 images is in progress and is here.
> > 
> >
> > Thanks,
> > Meghna Baijal
> >
>

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Anirudh]

-1. I dont see the need for additional level of hierarchy. I totally am for
recognizing good code reviewers. We can recognize this by making them
committers. Being a good reviewer should be sufficient to become a
committer in my opinion. (Assuming that there is a seperation between PPMC
and committers).

Anirudh

On Mon, Oct 22, 2018 at 8:28 AM Qing Lan  wrote:

> +1
> Let's have a reviewer list somewhere with a certain format: such as C++,
> Gluon, Scala/Java based on language or some other category. etc. In the
> future, label bot would automatically assign reviewers based on this kind
> of documentation.
>
> Thanks,
> Qing
>
> On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
>
> +1
> I also suggest add reviewer list link to the PR template, so that
> developers can easily request review from those reviewers.
> On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen  wrote:
> >
> > I was suggesting something more concrete:
> >
> > - Add a Reviewers section to
> >
> https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md to
> > list a list of Reviewers.
> > - This is a "pesudo role", but holds weight as committers should
> highly
> > value their reviews during the PR process.
> > - The committers/PMC could actively look for good contributors and
> nominate
> > them as Reviewer.
> > - Contributors are encouraged to seek reviews from the list of
> reviewers.
> > - The committers should actively solicit code reviews from the
> reviewers
> > when reviewing PRs and take their reviews into serious consideration.
> >
> > - PMCs should actively look for new committers in the current
> Reviewers
> >- Notably, the history reviews plus contribution likely will
> provide a
> > good indication on whether the person can uphold the quality
> standard of
> > the codebase, and provide helpful feedbacks(which is the trait that
> needed
> > from committer to merge code)
> >
> > Tianqi
> >
> >
> > On Sun, Oct 21, 2018 at 5:13 PM Steffen Rochel <
> steffenroc...@gmail.com>
> > wrote:
> >
> > > +1
> > > With the release announcement for MXNet 1.3 all contributors incl.
> code
> > > reviewers have been recognized. I suggest all future release
> announcements
> > > should include such recognition. Are you suggesting to highlight
> most
> > > active reviewers in release announcement or regularly (e.g.
> monthly),
> > > specifically from non-committers?
> > >
> > > On Sun, Oct 21, 2018 at 10:11 AM Tianqi Chen 
> wrote:
> > >
> > > > Also re another email-thread(I sent out one with my
> institutional email
> > > > which get blocked initially, so this one was a bit duplication
> of that).
> > > I
> > > > think it should really be the job of committers to recognize
> potential
> > > > reviewers, github also makes it easier to do so, e.g.
> > > >
> > > >
> > >
> https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93&q=reviewed-by%3Apiiswrong
> > > >
> > > > Tianqi
> > > >
> > > > On Fri, Oct 19, 2018 at 12:05 PM Carin Meier <
> carinme...@gmail.com>
> > > wrote:
> > > >
> > > > > +1 Great idea. Adding a name to the contributor list is a good
> idea.
> > > > Also,
> > > > > I've found that thanking the person for the review on the PR
> is another
> > > > way
> > > > > to express gratitude for their time and effort.
> > > > >
> > > > > On Fri, Oct 19, 2018 at 2:51 PM Tianqi Chen 
> wrote:
> > > > >
> > > > > > Dear MXNet Community:
> > > > > >
> > > > > > There is a great discussion going on in terms of lowering
> the barrier
> > > > of
> > > > > > entries and encourage more contribution to the project.  One
> of the
> > > > > general
> > > > > > goals is to encourage a broader pool of contributions. I
> want to make
> > > > the
> > > > > > following proposal:
> > > > > >
> > > > > > Besides Committers and PMC, let us also recognize Reviewers
> in the
> > > > > > community.  This is a "pseudo role" as there is no such
> official role
> > > > in
> > > > > > Apache. But I want to explore the possibility of recognizing
> active
> > > > > > reviewers for example, by adding a list of names in the
> contributor
> > > > list.
> > > > > > In general, I find it is really helpful to have more code
> reviews.
> > > > > > Recognizing good reviewers early enables us to find committer
> > > > candidates,
> > > > > > and encourage them to contribute and understand what is the
> bar of
> > > code
> > > > > > quality that is required to merge the code.
> > > > > >
> > > > > > This can provide the community with more evidence when
> recruiting new
> > > > > > committers. After all the write access of committership is
> about to
> > > the
> > > > > > code and understand the consequence of the resp

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

The situation most projects are facing(including us), is lack of code
reviews. Code reviews are the most important part of the project, and
high-quality reviews are extremely time-consuming, maybe as much as so
as the code itself. Usually, it is only committers do the code reviews, the
code reviews from committers are important, as they are the serve as
the gate-keeper of the quality of the code.  In my experience, I
usually find the reviews from non-committer super helpful, and they
help the committer to catch problems that are otherwise overlooked.

However, it is very hard to get contributors to do code reviews unless we
solicit them. It is definitely harder than getting code contributions.  The
Reviewer mechanism could provide a way to do so. We can recognize
contributors, bring them as reviewers and encourage them to do the code
reviews by explicitly soliciting. The reviewers can learn from the
committer reviews,
which serves as a role model for what is being expected. Naturally, this
likely helps us find more good reviewers and bought them committer.

Cheers
Tianqi

On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:

> -1. I dont see the need for additional level of hierarchy. I totally am for
> recognizing good code reviewers. We can recognize this by making them
> committers. Being a good reviewer should be sufficient to become a
> committer in my opinion. (Assuming that there is a seperation between PPMC
> and committers).
>
> Anirudh
>
> On Mon, Oct 22, 2018 at 8:28 AM Qing Lan  wrote:
>
> > +1
> > Let's have a reviewer list somewhere with a certain format: such as C++,
> > Gluon, Scala/Java based on language or some other category. etc. In the
> > future, label bot would automatically assign reviewers based on this kind
> > of documentation.
> >
> > Thanks,
> > Qing
> >
> > On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
> >
> > +1
> > I also suggest add reviewer list link to the PR template, so that
> > developers can easily request review from those reviewers.
> > On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen 
> wrote:
> > >
> > > I was suggesting something more concrete:
> > >
> > > - Add a Reviewers section to
> > >
> > https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md to
> > > list a list of Reviewers.
> > > - This is a "pesudo role", but holds weight as committers
> should
> > highly
> > > value their reviews during the PR process.
> > > - The committers/PMC could actively look for good contributors and
> > nominate
> > > them as Reviewer.
> > > - Contributors are encouraged to seek reviews from the list of
> > reviewers.
> > > - The committers should actively solicit code reviews from the
> > reviewers
> > > when reviewing PRs and take their reviews into serious
> consideration.
> > >
> > > - PMCs should actively look for new committers in the current
> > Reviewers
> > >- Notably, the history reviews plus contribution likely will
> > provide a
> > > good indication on whether the person can uphold the quality
> > standard of
> > > the codebase, and provide helpful feedbacks(which is the trait that
> > needed
> > > from committer to merge code)
> > >
> > > Tianqi
> > >
> > >
> > > On Sun, Oct 21, 2018 at 5:13 PM Steffen Rochel <
> > steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > > With the release announcement for MXNet 1.3 all contributors
> incl.
> > code
> > > > reviewers have been recognized. I suggest all future release
> > announcements
> > > > should include such recognition. Are you suggesting to highlight
> > most
> > > > active reviewers in release announcement or regularly (e.g.
> > monthly),
> > > > specifically from non-committers?
> > > >
> > > > On Sun, Oct 21, 2018 at 10:11 AM Tianqi Chen 
> > wrote:
> > > >
> > > > > Also re another email-thread(I sent out one with my
> > institutional email
> > > > > which get blocked initially, so this one was a bit duplication
> > of that).
> > > > I
> > > > > think it should really be the job of committers to recognize
> > potential
> > > > > reviewers, github also makes it easier to do so, e.g.
> > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93&q=reviewed-by%3Apiiswrong
> > > > >
> > > > > Tianqi
> > > > >
> > > > > On Fri, Oct 19, 2018 at 12:05 PM Carin Meier <
> > carinme...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > +1 Great idea. Adding a name to the contributor list is a
> good
> > idea.
> > > > > Also,
> > > > > > I've found that thanking the person for the review on the PR
> > is another
> > > > > way
> > > > > > to express gratitude for their time and effort.
> > > > > >
> > > > > > On Fri, Oct 19, 2018 at 2:51 PM Tianqi Chen <
> tqc...@apache.org>
> > wrote:
> > > > > >
> > > > > > > Dear MXNet Commu

Re: [DISCUSS] - Revisions to Committer Criteria

[Carin Meier]

Thanks Steffen helping draft up the proposal for Committer and PPMC
guidelines.

Please everyone review and provide feedback
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+(incubating)+Committer+and+PPMC+Member+Proposal
.

I plan to start a vote on this Friday if the discussions/revisions are
complete.

- Carin

On Fri, Oct 19, 2018 at 12:03 PM Carin Meier  wrote:

> Great!
>
> I started a rough draft for collaboration at
> https://cwiki.apache.org/confluence/display/MXNET/Become+a+Committer+Proposal
> .
>
> Everyone feel free to enhance and provide feedback.
>
> - Carin
>
> On Fri, Oct 19, 2018 at 10:55 AM Steffen Rochel 
> wrote:
>
>> +1, great suggestion, thanks Carin!
>> I'm willing to collaborate to create a draft proposal.
>> Steffen
>>
>> On Fri, Oct 19, 2018 at 5:35 AM Carin Meier  wrote:
>>
>> > Background:
>> >
>> > There is a desire to increase the committer pool and grow the community.
>> > This thread is to discuss the possibility of revision the current
>> committer
>> > criteria in light of the following goals:
>> >
>> > - Make it easier to newcomers to be committers
>> > - Recognize non-code contributions as paths to committership
>> > - Open the door to separating levels of committer and PMC (discussed in
>> > another thread)
>> >
>> > Current State:
>> >
>> > The current committer criteria is here
>> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>> as
>> > is modeled after the Hadoop committer criteria
>> > https://hadoop.apache.org/committer_criteria.html
>> >
>> > Proposal:
>> >
>> > Model the MXNet path to committership and PMC after the Apache Beam
>> project
>> > https://beam.apache.org/contribute/become-a-committer/
>> >
>> > Short quote from page:
>> >   =
>> > An Apache Beam committer…
>> > <
>> >
>> https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
>> > >
>> >
>> >- Takes many forms
>> ><
>> > https://beam.apache.org/contribute/become-a-committer/#takes-many-forms
>> >
>> >- Knows, upholds, and reinforces the Apache Software Foundation code
>> of
>> >conduct
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-apache-software-foundation-code-of-conduct
>> > >
>> >- Knows, upholds, and reinforces the responsibilities of an Apache
>> >Software Foundation committer
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-responsibilities-of-an-apache-software-foundation-committer
>> > >
>> >- Knows, upholds, and reinforces the Beam community’s practices
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
>> > >
>> >- =
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
>> > >
>> >
>> >
>> > I believe if we merge our current committer criteria with this model it
>> > will open  the path to committership to a wider pool, acknowledge that
>> > there are multiple paths, and reinforce the ASF values and
>> > responsibilities.
>> >
>> > The Beam model does not explicitly address a PMC level but we could add
>> it
>> > in in the same spirit of reinforcing the ASF responsibilities and
>> values of
>> > this level.
>> >
>> > Looking forward to feedback about this possible direction. If the
>> community
>> > is interested looking more into this direction I would be happy to
>> create
>> > of first draft of something more concrete to look at - (or if someone
>> else
>> > wants to take a crack at it too that would be great)
>> >
>> > - Carin
>> >
>>
>

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Chris Olivier]

Are there any other major Apache projects which have this designation?  I
am always continually suspicious of efforts to reinvent Apache rules from
other non-Apache projects, when Apache projects have historically been
quite successful within the Apache platform.  In fact, operating outside of
Apache norms is already a major problem as everyone knows.  We are only
just now splitting Committer/PMC into two separate groups. Splitting into
three seems a bit much at this juncture unless there's some good precedents.




On Mon, Oct 22, 2018 at 2:17 PM Tianqi Chen  wrote:

> The situation most projects are facing(including us), is lack of code
> reviews. Code reviews are the most important part of the project, and
> high-quality reviews are extremely time-consuming, maybe as much as so
> as the code itself. Usually, it is only committers do the code reviews, the
> code reviews from committers are important, as they are the serve as
> the gate-keeper of the quality of the code.  In my experience, I
> usually find the reviews from non-committer super helpful, and they
> help the committer to catch problems that are otherwise overlooked.
>
> However, it is very hard to get contributors to do code reviews unless we
> solicit them. It is definitely harder than getting code contributions.  The
> Reviewer mechanism could provide a way to do so. We can recognize
> contributors, bring them as reviewers and encourage them to do the code
> reviews by explicitly soliciting. The reviewers can learn from the
> committer reviews,
> which serves as a role model for what is being expected. Naturally, this
> likely helps us find more good reviewers and bought them committer.
>
> Cheers
> Tianqi
>
> On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:
>
> > -1. I dont see the need for additional level of hierarchy. I totally am
> for
> > recognizing good code reviewers. We can recognize this by making them
> > committers. Being a good reviewer should be sufficient to become a
> > committer in my opinion. (Assuming that there is a seperation between
> PPMC
> > and committers).
> >
> > Anirudh
> >
> > On Mon, Oct 22, 2018 at 8:28 AM Qing Lan  wrote:
> >
> > > +1
> > > Let's have a reviewer list somewhere with a certain format: such as
> C++,
> > > Gluon, Scala/Java based on language or some other category. etc. In the
> > > future, label bot would automatically assign reviewers based on this
> kind
> > > of documentation.
> > >
> > > Thanks,
> > > Qing
> > >
> > > On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
> > >
> > > +1
> > > I also suggest add reviewer list link to the PR template, so that
> > > developers can easily request review from those reviewers.
> > > On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen 
> > wrote:
> > > >
> > > > I was suggesting something more concrete:
> > > >
> > > > - Add a Reviewers section to
> > > >
> > > https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md
> to
> > > > list a list of Reviewers.
> > > > - This is a "pesudo role", but holds weight as committers
> > should
> > > highly
> > > > value their reviews during the PR process.
> > > > - The committers/PMC could actively look for good contributors
> and
> > > nominate
> > > > them as Reviewer.
> > > > - Contributors are encouraged to seek reviews from the list of
> > > reviewers.
> > > > - The committers should actively solicit code reviews from the
> > > reviewers
> > > > when reviewing PRs and take their reviews into serious
> > consideration.
> > > >
> > > > - PMCs should actively look for new committers in the current
> > > Reviewers
> > > >- Notably, the history reviews plus contribution likely will
> > > provide a
> > > > good indication on whether the person can uphold the quality
> > > standard of
> > > > the codebase, and provide helpful feedbacks(which is the trait
> that
> > > needed
> > > > from committer to merge code)
> > > >
> > > > Tianqi
> > > >
> > > >
> > > > On Sun, Oct 21, 2018 at 5:13 PM Steffen Rochel <
> > > steffenroc...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > > With the release announcement for MXNet 1.3 all contributors
> > incl.
> > > code
> > > > > reviewers have been recognized. I suggest all future release
> > > announcements
> > > > > should include such recognition. Are you suggesting to
> highlight
> > > most
> > > > > active reviewers in release announcement or regularly (e.g.
> > > monthly),
> > > > > specifically from non-committers?
> > > > >
> > > > > On Sun, Oct 21, 2018 at 10:11 AM Tianqi Chen <
> tqc...@apache.org>
> > > wrote:
> > > > >
> > > > > > Also re another email-thread(I sent out one with my
> > > institutional email
> > > > > > which get blocked initially, so this one was a bit
> duplication
> > > of that).
> > > > > I
> > > > > > think it should really be the job of committers to recognize
> > 

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

To be clear, we are not splitting the committers into reviewers, we are
recognizing an additional set of contributors who could become potential
committers and recognizing them as committers

Tianqi

On Mon, Oct 22, 2018 at 3:23 PM Chris Olivier  wrote:

> Are there any other major Apache projects which have this designation?  I
> am always continually suspicious of efforts to reinvent Apache rules from
> other non-Apache projects, when Apache projects have historically been
> quite successful within the Apache platform.  In fact, operating outside of
> Apache norms is already a major problem as everyone knows.  We are only
> just now splitting Committer/PMC into two separate groups. Splitting into
> three seems a bit much at this juncture unless there's some good
> precedents.
>
>
>
>
> On Mon, Oct 22, 2018 at 2:17 PM Tianqi Chen  wrote:
>
> > The situation most projects are facing(including us), is lack of code
> > reviews. Code reviews are the most important part of the project, and
> > high-quality reviews are extremely time-consuming, maybe as much as so
> > as the code itself. Usually, it is only committers do the code reviews,
> the
> > code reviews from committers are important, as they are the serve as
> > the gate-keeper of the quality of the code.  In my experience, I
> > usually find the reviews from non-committer super helpful, and they
> > help the committer to catch problems that are otherwise overlooked.
> >
> > However, it is very hard to get contributors to do code reviews unless we
> > solicit them. It is definitely harder than getting code contributions.
> The
> > Reviewer mechanism could provide a way to do so. We can recognize
> > contributors, bring them as reviewers and encourage them to do the code
> > reviews by explicitly soliciting. The reviewers can learn from the
> > committer reviews,
> > which serves as a role model for what is being expected. Naturally, this
> > likely helps us find more good reviewers and bought them committer.
> >
> > Cheers
> > Tianqi
> >
> > On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:
> >
> > > -1. I dont see the need for additional level of hierarchy. I totally am
> > for
> > > recognizing good code reviewers. We can recognize this by making them
> > > committers. Being a good reviewer should be sufficient to become a
> > > committer in my opinion. (Assuming that there is a seperation between
> > PPMC
> > > and committers).
> > >
> > > Anirudh
> > >
> > > On Mon, Oct 22, 2018 at 8:28 AM Qing Lan  wrote:
> > >
> > > > +1
> > > > Let's have a reviewer list somewhere with a certain format: such as
> > C++,
> > > > Gluon, Scala/Java based on language or some other category. etc. In
> the
> > > > future, label bot would automatically assign reviewers based on this
> > kind
> > > > of documentation.
> > > >
> > > > Thanks,
> > > > Qing
> > > >
> > > > On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
> > > >
> > > > +1
> > > > I also suggest add reviewer list link to the PR template, so that
> > > > developers can easily request review from those reviewers.
> > > > On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen 
> > > wrote:
> > > > >
> > > > > I was suggesting something more concrete:
> > > > >
> > > > > - Add a Reviewers section to
> > > > >
> > > >
> https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md
> > to
> > > > > list a list of Reviewers.
> > > > > - This is a "pesudo role", but holds weight as committers
> > > should
> > > > highly
> > > > > value their reviews during the PR process.
> > > > > - The committers/PMC could actively look for good contributors
> > and
> > > > nominate
> > > > > them as Reviewer.
> > > > > - Contributors are encouraged to seek reviews from the list of
> > > > reviewers.
> > > > > - The committers should actively solicit code reviews from the
> > > > reviewers
> > > > > when reviewing PRs and take their reviews into serious
> > > consideration.
> > > > >
> > > > > - PMCs should actively look for new committers in the current
> > > > Reviewers
> > > > >- Notably, the history reviews plus contribution likely will
> > > > provide a
> > > > > good indication on whether the person can uphold the quality
> > > > standard of
> > > > > the codebase, and provide helpful feedbacks(which is the trait
> > that
> > > > needed
> > > > > from committer to merge code)
> > > > >
> > > > > Tianqi
> > > > >
> > > > >
> > > > > On Sun, Oct 21, 2018 at 5:13 PM Steffen Rochel <
> > > > steffenroc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > > With the release announcement for MXNet 1.3 all contributors
> > > incl.
> > > > code
> > > > > > reviewers have been recognized. I suggest all future release
> > > > announcements
> > > > > > should include such recognition. Are you suggesting to
> > highlight
> > > > most
> > > > > > active reviewers in release announcement o

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Chris Olivier]

I think your last word you meant "reviewers", right?
yeah, this was also my understanding. A new "below-committer" level called
"reviewer".  So 3 levels now...

On Mon, Oct 22, 2018 at 3:50 PM Tianqi Chen  wrote:

> To be clear, we are not splitting the committers into reviewers, we are
> recognizing an additional set of contributors who could become potential
> committers and recognizing them as committers
>
> Tianqi
>
> On Mon, Oct 22, 2018 at 3:23 PM Chris Olivier 
> wrote:
>
> > Are there any other major Apache projects which have this designation?  I
> > am always continually suspicious of efforts to reinvent Apache rules from
> > other non-Apache projects, when Apache projects have historically been
> > quite successful within the Apache platform.  In fact, operating outside
> of
> > Apache norms is already a major problem as everyone knows.  We are only
> > just now splitting Committer/PMC into two separate groups. Splitting into
> > three seems a bit much at this juncture unless there's some good
> > precedents.
> >
> >
> >
> >
> > On Mon, Oct 22, 2018 at 2:17 PM Tianqi Chen  wrote:
> >
> > > The situation most projects are facing(including us), is lack of code
> > > reviews. Code reviews are the most important part of the project, and
> > > high-quality reviews are extremely time-consuming, maybe as much as so
> > > as the code itself. Usually, it is only committers do the code reviews,
> > the
> > > code reviews from committers are important, as they are the serve as
> > > the gate-keeper of the quality of the code.  In my experience, I
> > > usually find the reviews from non-committer super helpful, and they
> > > help the committer to catch problems that are otherwise overlooked.
> > >
> > > However, it is very hard to get contributors to do code reviews unless
> we
> > > solicit them. It is definitely harder than getting code contributions.
> > The
> > > Reviewer mechanism could provide a way to do so. We can recognize
> > > contributors, bring them as reviewers and encourage them to do the code
> > > reviews by explicitly soliciting. The reviewers can learn from the
> > > committer reviews,
> > > which serves as a role model for what is being expected. Naturally,
> this
> > > likely helps us find more good reviewers and bought them committer.
> > >
> > > Cheers
> > > Tianqi
> > >
> > > On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:
> > >
> > > > -1. I dont see the need for additional level of hierarchy. I totally
> am
> > > for
> > > > recognizing good code reviewers. We can recognize this by making them
> > > > committers. Being a good reviewer should be sufficient to become a
> > > > committer in my opinion. (Assuming that there is a seperation between
> > > PPMC
> > > > and committers).
> > > >
> > > > Anirudh
> > > >
> > > > On Mon, Oct 22, 2018 at 8:28 AM Qing Lan 
> wrote:
> > > >
> > > > > +1
> > > > > Let's have a reviewer list somewhere with a certain format: such as
> > > C++,
> > > > > Gluon, Scala/Java based on language or some other category. etc. In
> > the
> > > > > future, label bot would automatically assign reviewers based on
> this
> > > kind
> > > > > of documentation.
> > > > >
> > > > > Thanks,
> > > > > Qing
> > > > >
> > > > > On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
> > > > >
> > > > > +1
> > > > > I also suggest add reviewer list link to the PR template, so
> that
> > > > > developers can easily request review from those reviewers.
> > > > > On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen  >
> > > > wrote:
> > > > > >
> > > > > > I was suggesting something more concrete:
> > > > > >
> > > > > > - Add a Reviewers section to
> > > > > >
> > > > >
> > https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md
> > > to
> > > > > > list a list of Reviewers.
> > > > > > - This is a "pesudo role", but holds weight as committers
> > > > should
> > > > > highly
> > > > > > value their reviews during the PR process.
> > > > > > - The committers/PMC could actively look for good
> contributors
> > > and
> > > > > nominate
> > > > > > them as Reviewer.
> > > > > > - Contributors are encouraged to seek reviews from the list
> of
> > > > > reviewers.
> > > > > > - The committers should actively solicit code reviews from
> the
> > > > > reviewers
> > > > > > when reviewing PRs and take their reviews into serious
> > > > consideration.
> > > > > >
> > > > > > - PMCs should actively look for new committers in the current
> > > > > Reviewers
> > > > > >- Notably, the history reviews plus contribution likely
> will
> > > > > provide a
> > > > > > good indication on whether the person can uphold the quality
> > > > > standard of
> > > > > > the codebase, and provide helpful feedbacks(which is the
> trait
> > > that
> > > > > needed
> > > > > > from committer to merge code)
> > > > > >
> > > > > > Tianqi
> > > > > >
> > > > > >
> > > > > > On Sun, Oct 21, 2018