Up-streaming MXNet HIP Port

[Karnam, Srihari]

Dear All,


Please review the design for Up-Streaming MXNet HIP Port.


https://docs.google.com/document/d/1uGr1KPVDqDVUwnhM0vtmxkZZpE2Mf9slNF9e2IbwVj0/edit?usp=sharing


Regards,

Srihari Karnam

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

[Pedro Larroy]

Hi Steffen

I don't see that text in the proposal. I personally think the bar should be
the same for everyone independent of their affiliation, as per Apache ways
of working, and per ethical principles of equality and meritocracy,
otherwise we open the door to discrimination.

This old movie with de Niro and Cuba Gooding comes to mind:
https://en.wikipedia.org/wiki/Men_of_Honor

Pedro.

On Tue, Oct 23, 2018 at 5:15 PM Steffen Rochel 
wrote:

> Tianqi and Pedro - I suggested the following in
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
>  :
> In general, a nominee for PPMC will be evaluated based on the merit and
> contribution, independent of his affiliation. However, as an exception to
> improve the affiliation diversity within the PPMC, the PPMC might apply a
> higher bar for nominees affiliated with Amazon AWS.
>
> Please comment on the proposal (see thread "[DISCUSS] - Revisions to
> Committer Criteria).
>
> Steffen
>
> On Tue, Oct 23, 2018 at 7:09 AM Pedro Larroy  >
> wrote:
>
> > Hi
> >
> > Tianqi, there's a saying that the road to hell is paved with good
> > intentions. I think most of us here are enthusiastic about increasing
> > diversity of contributions to this project and are working actively
> towards
> > this. Having any kind of positive or negative discrimination seems to me
> > like it goes against what's listed on the Apache website, under the
> section
> > "Meritocracy". https://www.apache.org/foundation/how-it-works.html
> > Several
> > Amazonians have invested time, love and resources both inside and outside
> > working hours to this project. I don't think it's fair to them that their
> > contributions are not taken impartially irregardless of their current
> > employer, neither would be against a member of any other organization,
> sex,
> > condition etc.
> >
> > -1
> >
> > Pedro.
> >
> >
> >
> >
> > On Mon, Oct 22, 2018 at 6:02 PM Tianqi Chen  wrote:
> >
> > > 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 <
> tqc...@cs.washington.edu>
> > > > 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 

reminder - Go to start of banner Hangout October 24th 2018 8am and 5pm PDT

[Steffen Rochel]

Please see conf call information for 8am and 5pm PDT session and proposed
agenda below. Pleas note different conf call login between both session.
In case there is a problem again with conf call I will update slack and dev@
.

Steffen
Proposed Agenda:

   1. Introduction of participants
   2. Next Release discussion - Project Proposals for next MXNet Release
   

   3. ApacheCon update
   4. Community driven discussion
  1. MXNet Roadmap
  2. Discussion on dev@



*Meeting information 8am PDT session:*

1. Click to join the meeting:

https://chime.aws/7057233753

Meeting ID: 7057 23 3753

2. You can use your computer’s microphone and speakers, however, a headset
is recommended. Or, call in using your phone:

United States Toll-Free: +1 855-552-4463

Meeting PIN: 7057 23 3753


One-click Mobile Dial-in (United States (1)): +1 206-462-5569,,7057233753#

United States (1): +1 206-462-5569
International: https://chime.aws/dialinnumbers/

*Meeting information 5pm PDT session:*

1. Click to join the meeting:

https://chime.aws/9645786802


Meeting ID: 9645 78 6802

2. You can use your computer’s microphone and speakers, however, a headset
is recommended. Or, call in using your phone:

United States Toll-Free: +1 855-552-4463
Meeting PIN: 9645 78 6802

One-click Mobile Dial-in (United States (1)): +1 206-462-5569,,9645786802#

Re: [DISCUSS] - Revisions to Committer Criteria

[Steffen Rochel]

Carin - I got feedback on my proposal and made changes. I incorporated
Tianqi's suggesiton that we should strive to nominate committer/PPMC
candidates from outside ones own organization. It should not be considered
as a hard rule, but recommendation.

Steffen

On Mon, Oct 22, 2018 at 2:18 PM Carin Meier  wrote:

> 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

[Tianqi Chen]

>
>  To become a reviewer , he/she would have to have some
> history of code review in MXNet.


In contrary, we should to bring reviewers who have contributed to the repo,
but do not have code review history before, there is always a time gap
between someone who contributed something, to someone who would provide
active high-quality review feedbacks. The reviewer could be an useful
mechanism to encourage the contributors to do so

Tianqi


On Tue, Oct 23, 2018, 8:31 AM Tianqi Chen  wrote:
>
> > It is true that is a person is trusted to review code they should be
> > considered as a committer.
> >
> > On the other hand, it is also super valuable to solicit reviews from
> > contributors who have the potential to become committers. These code
> > reviews may not necessarily directly grant the merge of the code, they
> are
> > super helpful to the one who sends the patch, the committer who would
> merge
> > the code, and the reviewer(since they can learn from code review of
> > committers).
> >
> > There is always a process for a contributor to learn, and starting by
> > contributing code reviews is a good part. Potential committers don't
> simply
> > show up in the community. We need to find them, encourage them to
> > contribute and provide mentorship. I am proposing to recognize them and
> > list them as reviewers, so committers can solicit reviews and watch these
> > process. This would in general results in more reviews for each patch,
> and
> > more evidence to help us to find potential committers
> >
> > Tianqi
> >
> > On Tue, Oct 23, 2018 at 8:29 AM Tianqi Chen  wrote:
> >
> > > It is true that is a person is trusted to review code they should be
> > > considered as a reviewer.
> > >
> > > But what I am trying to say is that -- it is also super valuable to
> > > solicit reviews from contributors who have the potential to become
> > > committers. These code reviews may not necessarily directly grant the
> > merge
> > > of the code, they are super helpful to the one who sends the patch, the
> > > committer who would merge the code, and the reviewer(since they can
> learn
> > > from code review of committers).
> > >
> > > There is always a process for a contributor to learn, and starting by
> > > contributing code reviews is a good part. I am proposing to recognize
> > them
> > > and list them as reviewers, so committers can solicit reviews and watch
> > > these process. This would in general results in more reviews for each
> > > patch, and more evidence to help us to find potential committers
> > >
> > > Tianqi
> > >
> > > On Tue, Oct 23, 2018 at 7:08 AM Bob Paulin  wrote:
> > >
> > >> Generally if a person is trusted to review code they should be
> > >> considered as a committer.  Agree that having good reviewers are
> > >> important but the way most projects recognize those efforts is by
> making
> > >> them committers.
> > >>
> > >>
> > >> - Bob
> > >>
> > >>
> > >> On 10/22/2018 5: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.
> > >> 

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

[Anirudh]

Hi,

There is nothing stopping committers from soliciting reviews from
contributors. This is a good suggestion and committers should do this much
more often. I am assuming that the selection process for reviewers also
goes through PPMC. To become a reviewer , he/she would have to have some
history of code review in MXNet. Why not propose them for committer at this
point?

 On the one hand, we are trying to reduce bar to entry through PPMC
committers seperation while on the other hand we are growing this ladder of
hierarchy which somewhat dilutes the purpose of the separation between ppmc
and committer.

On Tue, Oct 23, 2018, 8:31 AM Tianqi Chen  wrote:

> It is true that is a person is trusted to review code they should be
> considered as a committer.
>
> On the other hand, it is also super valuable to solicit reviews from
> contributors who have the potential to become committers. These code
> reviews may not necessarily directly grant the merge of the code, they are
> super helpful to the one who sends the patch, the committer who would merge
> the code, and the reviewer(since they can learn from code review of
> committers).
>
> There is always a process for a contributor to learn, and starting by
> contributing code reviews is a good part. Potential committers don't simply
> show up in the community. We need to find them, encourage them to
> contribute and provide mentorship. I am proposing to recognize them and
> list them as reviewers, so committers can solicit reviews and watch these
> process. This would in general results in more reviews for each patch, and
> more evidence to help us to find potential committers
>
> Tianqi
>
> On Tue, Oct 23, 2018 at 8:29 AM Tianqi Chen  wrote:
>
> > It is true that is a person is trusted to review code they should be
> > considered as a reviewer.
> >
> > But what I am trying to say is that -- it is also super valuable to
> > solicit reviews from contributors who have the potential to become
> > committers. These code reviews may not necessarily directly grant the
> merge
> > of the code, they are super helpful to the one who sends the patch, the
> > committer who would merge the code, and the reviewer(since they can learn
> > from code review of committers).
> >
> > There is always a process for a contributor to learn, and starting by
> > contributing code reviews is a good part. I am proposing to recognize
> them
> > and list them as reviewers, so committers can solicit reviews and watch
> > these process. This would in general results in more reviews for each
> > patch, and more evidence to help us to find potential committers
> >
> > Tianqi
> >
> > On Tue, Oct 23, 2018 at 7:08 AM Bob Paulin  wrote:
> >
> >> Generally if a person is trusted to review code they should be
> >> considered as a committer.  Agree that having good reviewers are
> >> important but the way most projects recognize those efforts is by making
> >> them committers.
> >>
> >>
> >> - Bob
> >>
> >>
> >> On 10/22/2018 5: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 

Gluon CV v0.3 release post

[Adesoji Adeshina]

Community,

Please check out and share the post:
https://medium.com/apache-mxnet/gluoncv-0-3-a-new-horizon-564326364e16 for
v0.3 of gluon-cv, detailing improvements to existing implementations of
state of the art cv models. Particularly of note, is the accuracy
improvement for the ResNet family compared to the original reference papers
and to gluon-cv v0.2. In addition, several new state of the art models like
Yolo v3, DeepLab v3 and MaskRCNN with accuracy greater than or equal to
reference have been added.

Thanks to Zhi Zhang and Hao Jin for working to get the post published and
all gluon-cv contributors.

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

[Tianqi Chen]

It is true that is a person is trusted to review code they should be
considered as a committer.

On the other hand, it is also super valuable to solicit reviews from
contributors who have the potential to become committers. These code
reviews may not necessarily directly grant the merge of the code, they are
super helpful to the one who sends the patch, the committer who would merge
the code, and the reviewer(since they can learn from code review of
committers).

There is always a process for a contributor to learn, and starting by
contributing code reviews is a good part. Potential committers don't simply
show up in the community. We need to find them, encourage them to
contribute and provide mentorship. I am proposing to recognize them and
list them as reviewers, so committers can solicit reviews and watch these
process. This would in general results in more reviews for each patch, and
more evidence to help us to find potential committers

Tianqi

On Tue, Oct 23, 2018 at 8:29 AM Tianqi Chen  wrote:

> It is true that is a person is trusted to review code they should be
> considered as a reviewer.
>
> But what I am trying to say is that -- it is also super valuable to
> solicit reviews from contributors who have the potential to become
> committers. These code reviews may not necessarily directly grant the merge
> of the code, they are super helpful to the one who sends the patch, the
> committer who would merge the code, and the reviewer(since they can learn
> from code review of committers).
>
> There is always a process for a contributor to learn, and starting by
> contributing code reviews is a good part. I am proposing to recognize them
> and list them as reviewers, so committers can solicit reviews and watch
> these process. This would in general results in more reviews for each
> patch, and more evidence to help us to find potential committers
>
> Tianqi
>
> On Tue, Oct 23, 2018 at 7:08 AM Bob Paulin  wrote:
>
>> Generally if a person is trusted to review code they should be
>> considered as a committer.  Agree that having good reviewers are
>> important but the way most projects recognize those efforts is by making
>> them committers.
>>
>>
>> - Bob
>>
>>
>> On 10/22/2018 5: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 

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

[Tianqi Chen]

It is true that is a person is trusted to review code they should be
considered as a reviewer.

But what I am trying to say is that -- it is also super valuable to solicit
reviews from contributors who have the potential to become committers.
These code reviews may not necessarily directly grant the merge of the
code, they are super helpful to the one who sends the patch, the committer
who would merge the code, and the reviewer(since they can learn from code
review of committers).

There is always a process for a contributor to learn, and starting by
contributing code reviews is a good part. I am proposing to recognize them
and list them as reviewers, so committers can solicit reviews and watch
these process. This would in general results in more reviews for each
patch, and more evidence to help us to find potential committers

Tianqi

On Tue, Oct 23, 2018 at 7:08 AM Bob Paulin  wrote:

> Generally if a person is trusted to review code they should be
> considered as a committer.  Agree that having good reviewers are
> important but the way most projects recognize those efforts is by making
> them committers.
>
>
> - Bob
>
>
> On 10/22/2018 5: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 

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

[Chris Olivier]

It's not my intent to kill this (I just asked a question).  What are
mentors' input?

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 at 5:13 PM Steffen Rochel <
> > > > > steffenroc...@gmail.com>
> > > > >  

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

[Tianqi Chen]

Hi Pedro:
If any of the Amazonians have enough merit to get the committership.
The PMCs outside Amazon should recognize and bring them to the
committership -- This proposal is not about discriminating against anyone.
Please do note that this community is bigger than Amazon itself -- there
are Intel engineers, Googlers, University students, startup companies
employees, Apache members, and independent contributors. Admittedly their
contributions need to get recognized, and they do not sit next door to
another PMC member.

   I do not understand why we should be afraid of this proposal. If the
merit of contributions is good enough, any PMC, including non-Amazonians
should recognize and propose them to the committership, why does it have to
be an Amazonian PMC? Why not try get someone outside Amazon to do so. Try
to have a goodwill and to give it a spin.

On Tue, Oct 23, 2018 at 7:09 AM Pedro Larroy 
wrote:

> Hi
>
> Tianqi, there's a saying that the road to hell is paved with good
> intentions. I think most of us here are enthusiastic about increasing
> diversity of contributions to this project and are working actively towards
> this. Having any kind of positive or negative discrimination seems to me
> like it goes against what's listed on the Apache website, under the section
> "Meritocracy". https://www.apache.org/foundation/how-it-works.html
> Several
> Amazonians have invested time, love and resources both inside and outside
> working hours to this project. I don't think it's fair to them that their
> contributions are not taken impartially irregardless of their current
> employer, neither would be against a member of any other organization, sex,
> condition etc.
>
> -1
>
> Pedro.
>
>
>
>
> On Mon, Oct 22, 2018 at 6:02 PM Tianqi Chen  wrote:
>
> > 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 

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

[Tianqi Chen]

Hi Pedro:
If any of the Amazonians have enough merit to get the committership.
The PMCs outside Amazon should recognize and bring them to the
committership -- This proposal is not about discriminating against anyone.
Please do note that this community is bigger than Amazon itself -- there
are Intel engineers, Googlers, University students, startup companies
employees, Apache members, and independent contributors. Admittedly their
contributions need to get recognized, and they do not sit next door to
another PMC member.

   I do not understand why we should be afraid of this proposal. If the
merit of contributions is good enough, any PMC, including non-Amazonians
should recognize and propose them to the committership, why does it have to
be an Amazonian PMC? Why not try get someone outside Amazon to do so. Try
to have a goodwill and to give it a spin.

Tianqi

On Tue, Oct 23, 2018 at 7:09 AM Pedro Larroy 
wrote:

> Hi
>
> Tianqi, there's a saying that the road to hell is paved with good
> intentions. I think most of us here are enthusiastic about increasing
> diversity of contributions to this project and are working actively towards
> this. Having any kind of positive or negative discrimination seems to me
> like it goes against what's listed on the Apache website, under the section
> "Meritocracy". https://www.apache.org/foundation/how-it-works.html
> Several
> Amazonians have invested time, love and resources both inside and outside
> working hours to this project. I don't think it's fair to them that their
> contributions are not taken impartially irregardless of their current
> employer, neither would be against a member of any other organization, sex,
> condition etc.
>
> -1
>
> Pedro.
>
>
>
>
> On Mon, Oct 22, 2018 at 6:02 PM Tianqi Chen  wrote:
>
> > 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, 

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

[Steffen Rochel]

Tianqi and Pedro - I suggested the following in
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
 :
In general, a nominee for PPMC will be evaluated based on the merit and
contribution, independent of his affiliation. However, as an exception to
improve the affiliation diversity within the PPMC, the PPMC might apply a
higher bar for nominees affiliated with Amazon AWS.

Please comment on the proposal (see thread "[DISCUSS] - Revisions to
Committer Criteria).

Steffen

On Tue, Oct 23, 2018 at 7:09 AM Pedro Larroy 
wrote:

> Hi
>
> Tianqi, there's a saying that the road to hell is paved with good
> intentions. I think most of us here are enthusiastic about increasing
> diversity of contributions to this project and are working actively towards
> this. Having any kind of positive or negative discrimination seems to me
> like it goes against what's listed on the Apache website, under the section
> "Meritocracy". https://www.apache.org/foundation/how-it-works.html
> Several
> Amazonians have invested time, love and resources both inside and outside
> working hours to this project. I don't think it's fair to them that their
> contributions are not taken impartially irregardless of their current
> employer, neither would be against a member of any other organization, sex,
> condition etc.
>
> -1
>
> Pedro.
>
>
>
>
> On Mon, Oct 22, 2018 at 6:02 PM Tianqi Chen  wrote:
>
> > 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 

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

[Pedro Larroy]

Hi

Tianqi, there's a saying that the road to hell is paved with good
intentions. I think most of us here are enthusiastic about increasing
diversity of contributions to this project and are working actively towards
this. Having any kind of positive or negative discrimination seems to me
like it goes against what's listed on the Apache website, under the section
"Meritocracy". https://www.apache.org/foundation/how-it-works.html  Several
Amazonians have invested time, love and resources both inside and outside
working hours to this project. I don't think it's fair to them that their
contributions are not taken impartially irregardless of their current
employer, neither would be against a member of any other organization, sex,
condition etc.

-1

Pedro.




On Mon, Oct 22, 2018 at 6:02 PM Tianqi Chen  wrote:

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

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

[Bob Paulin]

Generally if a person is trusted to review code they should be
considered as a committer.  Agree that having good reviewers are
important but the way most projects recognize those efforts is by making
them committers.


- Bob


On 10/22/2018 5: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 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 

Re: Reproducing test failures on CI

[Anton Chernov]

Dear MXNet community,

Unfortunately, due to various reasons, we need to reschedule the demo to
next week's user group, to 30th of October.

Best regards,
Anton




вт, 16 окт. 2018 г. в 18:03, Pedro Larroy :

> These are two separate events. The London meetup is not related to Anton's
> original email.
>
> Regarding reproducing CI failures I would suggest that we create some easy
> to use scripts and templates to launch instances rather than lengthy
> documentation or materials. If the process is complex, automation is always
> better than lengthy instructions.
>
> It should be a couple of instructions to reproduce test failures locally or
> in EC2.
> I have a personal terraform file and scripts which I use to provision
> instances to do MXNet work in which does all the tedious configuration. I
> could polish them up a bit and create a PR. Another script would be needed
> to launch build & test easily as now with the complexity of the
> JenkinsFiles is too convoluted to reverse engineer for somebody not
> familiar with CI.
>
> There's this nice guide that Marco created:
> https://cwiki.apache.org/confluence/display/MXNET/Reproducing+test+results
>
> But seems not many people read it, also it doesn't solve provisioning the
> instance and installing the initial dependencies.
>
>
> Pedro.
>
> On Mon, Oct 15, 2018 at 8:58 PM Naveen Swamy  wrote:
>
> > Timur,
> > Here is a meetup Scheduled for 23rd October in London, where Pedro Larroy
> > will talk about Deep Learning using MXNet!
> >
> >
> >
> https://www.meetup.com/Deep-Learning-with-Apache-MXNet-London/events/255280739/
> >
> >
> > -Naveen
> >
> > On Mon, Oct 15, 2018 at 11:18 AM Anton Chernov 
> > wrote:
> >
> > > Sorry, Timur, I've missed that part.
> > >
> > > It will be during the regular user group meeting that is conducted in
> > > Berlin and is streamed via Chime. You can find more information on the
> > > wiki:
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+User+Groups+recurring+meetings
> > >
> > > Best
> > > Anton
> > >
> > >
> > > пн, 15 окт. 2018 г. в 18:45, Timur Shenkao :
> > >
> > > > Is it London meeting?
> > > > Or some other location?
> > > >
> > > > On Monday, October 15, 2018, Anton Chernov 
> > wrote:
> > > >
> > > > > Dear MXNet community,
> > > > >
> > > > > We've noticed that there has been some difficulties setting up
> > > > environments
> > > > > and reproducing test results from failed builds on the CI. We would
> > > like
> > > > to
> > > > > offer some help to the community on that and therefore helding a
> > small
> > > > live
> > > > > stream demo session during our User Group Meeting on the 23rd of
> > > October.
> > > > > We will be:
> > > > >
> > > > > * Reviewing a failure and make an initial guess on the cause
> > > > > * Setting up environment
> > > > > * Reproducing the build step from the CI
> > > > > * Reproducing a failure step
> > > > > * Making and submitting a fix back to the community
> > > > >
> > > > > Feel free to propose some additional topic for the streaming.
> > > > >
> > > > > Best regards
> > > > > Anton
> > > > >
> > > >
> > >
> >
>