Re: Call for Ideas and Approaches to Community Building

[Sheng Zha]

First, I echo a lot with Steffen’s points on educating users on the usage of 
MXNet and DL, and my team at my day job takes it as its mission. Just to name a 
few related efforts: d2l.ai (a whole book on deep learning with mxnet), the 
numerous tutorials in GluonCV, GluonNLP, DGL toolkits, the public course on 
introduction to deep learning at UC Berkeley by Mu Li and Alex Smola.

Recognizing non-code contribution has also been one of the recent focus of the 
PPMC. In fact, Aston Zhang, who made significant contribution to the community 
by looking after the user forum and writing the d2l book, has just joined us as 
a committer of our community. Kuo Ding, also known as chinakook, the maintainer 
of the Awesome-MXNet list and advocate of MXNet in various social media, has 
also just accepted our invite to become a committer. PPMC will definitely be on 
the watch for more.

In addition, as PPMC member, I’m also interested in other ways to help 
technical contributors to become familiar with the code base. I hope to grow 
the pool of competencies in the committer group in various areas, by helping 
interested community members. A larger pool of competencies makes better 
experience for all contributors in the form of meaningful technical feedbacks 
and code reviews. In my case, I spend half of my time on Github reviewing code, 
and also participating in a wide range of design reviews. I’ve been encouraging 
my committer peers to do the same. From the perspective of an experienced 
committer, I think growth in the pool of technical competencies is sorely 
needed, and I’m definitely interested in manageable ways to reach more people 
and help those with the drive to grow with the community.

Towards meet-ups and hangouts, I have mixed feeling. On one hand, meeting other 
MXNetters is exciting and I’d definitely like to indulge. On the other hand, 
meet-ups tend to make it impossible, or at least time-consuming for people who 
didn’t attend to digest. By spending the same time on carefully writing answers 
to issues, I could easily have helped 10x more people across space and time. 
Meet-ups also encourage off-list decision-making which is a bit concerning to 
me too. These are my personal takes and I thought I should be candid about this 
so that people who do attend can be more conscious about taking the 
conversations back to the list.

In terms of nomination outside one’s own organization, my impression is that 
this comes from the desire of growing the diversity in the community, 
specifically in terms of the day job. So the “organization” refers specifically 
to day job employer. From my perspective, I think all nomination should be 
encouraged, and the day job of a community member doesn’t affect the merit one 
has earned. That said, given that we strive to grow an open and transparent 
community, a community member whose impact is limited only to one’s day job is 
a red flag. The failure to leave any impression outside of the same 
organization is likely a symptom of relying too much on private-channel 
communication or making decision outside the community. If such case arises, I 
think PPMC members can be trusted to recognize it as a problem.

-sz

> On Mar 6, 2019, at 10:03 PM, Steffen Rochel  wrote:
> 
> Thanks Carin to start the discussion on this important topic.
> My suggestions:
> 1) get more involved educating the public about MXNet and how to use for
> DL. Carin's Can You GAN?  is a
> great example and there are many others. Meetups are another good way (DL
> with MXNet 
> has now 10 local chapters with 1842 members in 8 countries, but there are
> still a lot of "white" areas). Recognize contributors like Cosmin
>  and Lai
> 
> .
> 2) Recognize non-code contributors like all the people answering questions
> at the various discussion forums.
> 3) invite people to contribute - github repo has zero issues labelled "Help
> Wanted", 21 out of 993 open issues are labelled as "Good First Issues".
> Recognize people who go through the effort of classification of issues and
> mentor the new contributors
> 4) talk to the "drive by contributors" i.e. people who contribute once and
> then disappear. What is preventing them to contribute more then once?
> 5) be more active communicating and cross-promoting events related to MXNet
> through announcements on dev@, discussion forum and re-tweets.
> 
> I agree with Tianqi on "One approach toward building a more diverse
> community is to acknowledge the fact that we want to encourage interactions
> in the Apache way beyond our physical cycle." However, I disagree with his
> suggestion regarding "One principle to toward that is to encourage PMC
> members only nominate committers from other organizations" 

Re: MXNet Community Monthly Updates

[Junru Shao]

Hi Mu,

Thanks for proposing this! Strongly agree with the newsletter - this would
be the most economically efficient way to enhance community involvement.

In addition to the draft wiki pages, should we send posts like "Call for
newsletter articles" to dev@ list with some frequency? This could help
maximize the community awareness and help active community members get more
exposure - Community building is important.

Thanks,
Junru

On Wed, Mar 6, 2019 at 6:57 PM Chaitanya Bapat  wrote:

> Hello Mu,
>
> Thanks a lot for bringing this topic. I had thought about a Weekly Digest
> for MXNet (weekly newsletter) - which is on similar lines (can be made into
> Monthly if it sounds good).
>
> Here's the quip doc -
> https://chaitanya.quip.com/BT6RAcAigHM9/MXNet-Weekly-Digest
>
> I have talked about the Background, Motivation, Features and a mockup of
> Newsletter.
>
> Would love to hear our community's thoughts as well as yours on the same.
>
> Please find attached a snapshot of the Weekly digest I came up with.
>
> Thanks,
> Chai
>
>
>
>
> On Wed, 6 Mar 2019 at 19:59, Mu Li  wrote:
>
>> Dear Community,
>>
>> I propose to send a monthly summary to users to broadcast the recent
>> progresses in the community. It will not only include new features added
>> into MXNet, but also various community activities. Here is an example:
>>
>> Tutorials
>> - 10 new lectures teaching at UC Berkeley
>> - Video record for "Deploying with Java" at Java World 19
>> Computer Vision
>> - GluonCV 0.4 release supports pose estimation and improves 10 existing
>> models
>> - Insightface added a new model XY
>> NLP
>> - GluonNLP 0.5.1 release improves BERT training
>> New Projects
>> - A MXNet implementation for paper XY
>> MXNet
>> - Enhanced Java binding preview
>> - Numpy frontend reaches milestone 1
>> Incoming Events
>> - Meetup at Palto Alto on 4/2
>>
>> The publishing procedure is we first create a draft wiki page so everyone
>> will have a chance to review and add staffs. After that we will send it
>> through an email list.
>>
>> I'm considering to use a 3rd party service such as mailchimp.com so that
>> every user can subscribe it easily and we can do some marketing analysis
>> as
>> well. But I'm happy to re-use us...@mxnet.apache.org if it provides
>> simliar
>> functionalities.
>>
>> I'd like to hear your feedback for how to make the newletter more user
>> friendely.
>>
>> Best
>> Mu
>>
>
>
> --
> *Chaitanya Prakash Bapat*
> *+1 (973) 953-6299*
>
> [image: https://www.linkedin.com//in/chaibapat25]
> [image:
> https://www.facebook.com/chaibapat] 
> [image:
> https://twitter.com/ChaiBapchya] [image:
> https://www.linkedin.com//in/chaibapat25]
> 
>

Re: Call for Ideas and Approaches to Community Building

[Steffen Rochel]

Thanks Carin to start the discussion on this important topic.
My suggestions:
1) get more involved educating the public about MXNet and how to use for
DL. Carin's Can You GAN?  is a
great example and there are many others. Meetups are another good way (DL
with MXNet 
has now 10 local chapters with 1842 members in 8 countries, but there are
still a lot of "white" areas). Recognize contributors like Cosmin
 and Lai

.
2) Recognize non-code contributors like all the people answering questions
at the various discussion forums.
3) invite people to contribute - github repo has zero issues labelled "Help
Wanted", 21 out of 993 open issues are labelled as "Good First Issues".
Recognize people who go through the effort of classification of issues and
mentor the new contributors
4) talk to the "drive by contributors" i.e. people who contribute once and
then disappear. What is preventing them to contribute more then once?
5) be more active communicating and cross-promoting events related to MXNet
through announcements on dev@, discussion forum and re-tweets.

I agree with Tianqi on "One approach toward building a more diverse
community is to acknowledge the fact that we want to encourage interactions
in the Apache way beyond our physical cycle." However, I disagree with his
suggestion regarding "One principle to toward that is to encourage PMC
members only nominate committers from other organizations" for the
following reasons:
1. We had a long discussion about becoming committer and PPMC member and
voted about it in Oct/Nov 2018 - please see Wiki
.
This document (adopted by MXNet PPMC) calls out for PMC members to strive
to "mentor contributors to become eligible for consideration as
committer/PMC member". If somebody is making the effort to mentor a person
from any organization, then he should also have the right to propose such
contributor. This document, which was adopted just 5 month ago didn't
include the policy Tianqi proposed. Has something changed to substantiate
reopening the discussion? Every PMC member should support the community
development and have the right to propose any active contributor based on
merit as committer or PMC member.
2. It will be very difficult to define "other organizations". E.g. (1) Steven
Turner

is
actively promoting MXNet by organizing meetup in London and in his day job
works for AWS. (2) I recently moved from Amazon AI to Amazon Redshift and
as such have no involvement with MXNet as part of my day job, but I'm still
with Amazon. Are such situations considered being part of the same
organization or not? Does any non-Amazon PPMC member even know about the
contributions Steven (and other meetup and conference contributors) are
making?
3. MXNet has a number of active, multi-year code and non-code contributors
which are still not recognized as committer or PMC members. The PMC should
not make it harder to recognize such contributions with arbitrary rules and
rather actively mentoring such contributors to grow the community.

Best,
Steffen



On Wed, Mar 6, 2019 at 12:11 PM Isabel Drost-Fromm 
wrote:

>
>
> Am 6. März 2019 18:36:36 MEZ schrieb Aaron Markham <
> aaron.s.mark...@gmail.com>:
> >Having more creatives in the open source community, not just MXNet,
> >would
> >be great for diversity.
>
> .oO(And something that would be appreciated even at the foundation
> level...)
>
> Is there anything else that people can think of where help might be
> needed? Anything else where getting involved or following the project could
> be made easier?
>
>
> Isabel (who seriously hates auto correct on Android, see "corrections" in
> my last mail, sorry for those misspellings)
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: MXNet Community Monthly Updates

[Chaitanya Bapat]

Hello Mu,

Thanks a lot for bringing this topic. I had thought about a Weekly Digest
for MXNet (weekly newsletter) - which is on similar lines (can be made into
Monthly if it sounds good).

Here's the quip doc -
https://chaitanya.quip.com/BT6RAcAigHM9/MXNet-Weekly-Digest

I have talked about the Background, Motivation, Features and a mockup of
Newsletter.

Would love to hear our community's thoughts as well as yours on the same.

Please find attached a snapshot of the Weekly digest I came up with.

Thanks,
Chai




On Wed, 6 Mar 2019 at 19:59, Mu Li  wrote:

> Dear Community,
>
> I propose to send a monthly summary to users to broadcast the recent
> progresses in the community. It will not only include new features added
> into MXNet, but also various community activities. Here is an example:
>
> Tutorials
> - 10 new lectures teaching at UC Berkeley
> - Video record for "Deploying with Java" at Java World 19
> Computer Vision
> - GluonCV 0.4 release supports pose estimation and improves 10 existing
> models
> - Insightface added a new model XY
> NLP
> - GluonNLP 0.5.1 release improves BERT training
> New Projects
> - A MXNet implementation for paper XY
> MXNet
> - Enhanced Java binding preview
> - Numpy frontend reaches milestone 1
> Incoming Events
> - Meetup at Palto Alto on 4/2
>
> The publishing procedure is we first create a draft wiki page so everyone
> will have a chance to review and add staffs. After that we will send it
> through an email list.
>
> I'm considering to use a 3rd party service such as mailchimp.com so that
> every user can subscribe it easily and we can do some marketing analysis as
> well. But I'm happy to re-use us...@mxnet.apache.org if it provides
> simliar
> functionalities.
>
> I'd like to hear your feedback for how to make the newletter more user
> friendely.
>
> Best
> Mu
>


-- 
*Chaitanya Prakash Bapat*
*+1 (973) 953-6299*

[image: https://www.linkedin.com//in/chaibapat25]
[image: https://www.facebook.com/chaibapat]
[image:
https://twitter.com/ChaiBapchya] [image:
https://www.linkedin.com//in/chaibapat25]

MXNet Community Monthly Updates

[Mu Li]

Dear Community,

I propose to send a monthly summary to users to broadcast the recent
progresses in the community. It will not only include new features added
into MXNet, but also various community activities. Here is an example:

Tutorials
- 10 new lectures teaching at UC Berkeley
- Video record for "Deploying with Java" at Java World 19
Computer Vision
- GluonCV 0.4 release supports pose estimation and improves 10 existing
models
- Insightface added a new model XY
NLP
- GluonNLP 0.5.1 release improves BERT training
New Projects
- A MXNet implementation for paper XY
MXNet
- Enhanced Java binding preview
- Numpy frontend reaches milestone 1
Incoming Events
- Meetup at Palto Alto on 4/2

The publishing procedure is we first create a draft wiki page so everyone
will have a chance to review and add staffs. After that we will send it
through an email list.

I'm considering to use a 3rd party service such as mailchimp.com so that
every user can subscribe it easily and we can do some marketing analysis as
well. But I'm happy to re-use us...@mxnet.apache.org if it provides simliar
functionalities.

I'd like to hear your feedback for how to make the newletter more user
friendely.

Best
Mu

Re: Call for Ideas and Approaches to Community Building

[Isabel Drost-Fromm]

Am 6. März 2019 18:36:36 MEZ schrieb Aaron Markham :
>Having more creatives in the open source community, not just MXNet,
>would
>be great for diversity.

.oO(And something that would be appreciated even at the foundation level...)

Is there anything else that people can think of where help might be needed? 
Anything else where getting involved or following the project could be made 
easier?


Isabel (who seriously hates auto correct on Android, see "corrections" in my 
last mail, sorry for those misspellings)

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

Re: direction for documentation across various APIs that share common doc source

[Aaron Markham]

Mu,
Thanks for your response. I have some follow-up questions now. A lot actually.
Can you explain more about what ndarray_doc.py is doing? I see that
ndarray.register is calling it to do some transformations to
docstrings by injecting "float". This seems quite buried to me. Some
may have wondered tracing through the ndarray docs, "where does float
come from? It's not listed here in the docstring. Strange."
Is there a document that describes this pattern so other developers
know how to use it and what impact it has? Why am I not seeing the
pattern other than ndarray and symbol and only for float support? Why
doesn't symbol have a correlating symbol_doc.py? This makes me wonder
about the various issues I've seen where functions are properly
described, or at all, when Sphinx runs. Is this something that should
have been applied more widely, but has not? Wouldn't it make sense to
have the docs massaging processes centralized for maintenance and
clarity?

Aside from that, I'm still not seeing the path for solving the issue
with R and Scala and Java showing psuedocode or python code in their
examples by using `make doctest`. Maybe they're first steps to make
sure Python examples execute, but don't extend a solution to any other
language binding? That's fine if so, but I still want to keep
exploring what we do to facilitate good docs for the other bindings.
Are you perhaps suggesting that each language binding follow this
rewriting of the docstrings pattern that's in ndarray and symbol?

Can you look at this PR and provide feedback on a tangible example of
how to proceed? https://github.com/apache/incubator-mxnet/pull/14243



Vishaal & Anton, thanks for your feedback too. Flagging the code makes
a lot of sense as then it would be quite apparent what its intended
language is. Rerunning sphinx to rewrite the output could work, and
that assumes those packages have something specific and relevant to
inject. Unfortunately for R, Scala, and Java, that doesn't seem to be
the case as this point. Please correct me if I'm missing something
here.



Cheers,
Aaron

On Tue, Mar 5, 2019 at 9:44 AM Mu Li  wrote:
>
> The original design is putting psudo-code in cc files  (e.g. ndarray.cc
> )
> that are languange indepent, then having python codes in .py files (e.g.
> ndarray_doc.py
> ).
> However, we haven't define the psudo-code format so some codes in cc files
> look like python, and we didn't enable doctest so some py file codes cannot
> be executed.
>
> I suggest the following next steps:
>
> 1. follow tensorflow's psudo-code format, e.g.
> https://www.tensorflow.org/versions/r2.0/api_docs/python/tf/fill
> 2. enable doctest during building the doc (make doctest)
>
> On Mon, Mar 4, 2019 at 10:09 AM Vishaal Kapoor 
> wrote:
>
> > Hey Aaron and  Anton,
> >
> > One of MXNet's strengths over other frameworks is the plethora of language
> > bindings so having language specific examples is of importance. Perhaps
> > indicating that an example is Python code by using a "#python" header on
> > the example would make it clear.  Of course, for the important APIs,
> > docstrings for the most popular languages would be desired. Additionally,
> > making the holes clear would make it easier for users to contribute
> > documentation for their favorite languages.
> >
> > Vishaal
> >
> > On Mon, Mar 4, 2019 at 8:34 AM Anton Chernov  wrote:
> >
> > > Hi Aaron,
> > >
> > > Here is an idea: The main documentation is the one in .cc files. In
> > theory
> > > the language bindings should just override some stuff from it, like
> > > examples. If I understand correctly there is a sphinx script that
> > generates
> > > the documentation. If run it first for core src folder and then from a
> > > language binding folder it could use the -f, --force flag [1] to override
> > > the needed parts. That would allow to provide a 'default' version of the
> > > documentation, that could be adjusted where needed.
> > >
> > > Best
> > > Anton
> > >
> > > [1]
> > >
> > >
> > http://www.sphinx-doc.org/en/stable/man/sphinx-apidoc.html#sphinx-apidoc-manual-page
> > >
> > > вт, 26 февр. 2019 г. в 02:20, Aaron Markham :
> > >
> > > > Hi everyone,
> > > > A recent issue and pending PR has brought a thorny docs situation to
> > > > my attention again and I'd like to hear from the community on how to
> > > > proceed.
> > > > We currently get some of the docs for the Python API pulled out of .cc
> > > > files. Other APIs also get docs from there, or pull the Python docs to
> > > > autogenerate their docs. This presents some problems:
> > > > 1. (Some of) The code examples provided don't run when you copy and
> > > > paste them. [1]
> > > > 2. The code examples that show up in other APIs won't work as the code
> > > > is Python and for (many/complicated) statements the syntax can be
> > > > wrong.
> > > >

Re: Call for Ideas and Approaches to Community Building

[Aaron Markham]

I'd like to see if we can get designers involved. I noted that there are
some boot camps for UX and design. They pick up projects for class to
design a brand or a new site or service. Why not get them involved with
open source? Apache has a lot of projects with sites that could use help,
and ours, especially the new one could use help.

I think designers would benefit as they'd have a public portfolio piece
that they can reference plus they would get to learn all about the open
source tools and meet folks. Having worked on an open source project is
impressive, more so than designing a site or app that never launched.

Even small examples that are like mini apps could get a face lift. The docs
could even get help with graphics that explain how stuff works. People that
do data visualization could have a productive time working with ML as well.

Having more creatives in the open source community, not just MXNet, would
be great for diversity.

Cheers,
Aaron


On Wed, Mar 6, 2019, 07:10 Isabel Drost-Fromm  wrote:

>
>
> Am 2. März 2019 15:13:23 MEZ schrieb Carin Meier :
> >I wanted to kickoff a discussion about community building. There was an
> >excellent blog post from the Apache Beam Community on this
> >https://blogs.apache.org/comdev/entry/an-approach-to-community-building
>
> Needless to say I really love that blog post.
>
> Other than that there are a couple of question you might ask yourself as a
> community:
>
> How easy is it to patriciate as an outsider, how much communication is
> happening outside of dev@?
>
> How explicit are you about how inclusive you want to be? See also
> https://youtu.be/LgB1s3buccI
>
> How explicit are you about where you need help (including and beyond
> coding)?
>
> How explicit are you with downstream users that some of the inner workings
> of Apache projects are build around a scratch your own itch casual
> contributions that ideally should be rewarded the same way as full-time
> contributions (
> https://blogs.apache.org/foundation/entry/success-at-apache-for-love )?
>
> I think you want to enable as many ppl as possible - typically only ten
> percent of your users turn into contributor, of those only ten percent
> trend to be repeat contributors... at least in my experience.
>
> Just some ideas,
> Isabel
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Re: Call for Ideas and Approaches to Community Building

[Tianqi Chen]

It is important for a contribution to be visible publically, and being able
to get identifications from PMC members  that you do not interact daily is
a way to do that.

It also boils down to the trust, on whether fellow PMC members think it is
appropriate to entrust others to do the nomination. I personally would love
to collaborate with my fellow PMC members, and in the case that I was not
trusted, refrain from doing things

Anyway, as I said, I just want to share this way of positive community
building, and see what the community thinks

Tianqi

On Wed, Mar 6, 2019 at 12:15 PM Anirudh Acharya 
wrote:

> Having only non-organization PMC members nominate new committers could
> un-level the playing field.
> 1. Many times contributions might not require a contributor to have direct
> 1:1 discussion with PMC members outside his org.
> 2. It would give inordinate power/responsibility to the few non-Amazon
> active PMC members.
>
> Just my 2 cents.
>
>
> Thanks
> Anirudh
>
> On Wed, Mar 6, 2019 at 7:10 AM Isabel Drost-Fromm 
> wrote:
>
> >
> >
> > Am 2. März 2019 15:13:23 MEZ schrieb Carin Meier :
> > >I wanted to kickoff a discussion about community building. There was an
> > >excellent blog post from the Apache Beam Community on this
> > >https://blogs.apache.org/comdev/entry/an-approach-to-community-building
> >
> > Needless to say I really love that blog post.
> >
> > Other than that there are a couple of question you might ask yourself as
> a
> > community:
> >
> > How easy is it to patriciate as an outsider, how much communication is
> > happening outside of dev@?
> >
> > How explicit are you about how inclusive you want to be? See also
> > https://youtu.be/LgB1s3buccI
> >
> > How explicit are you about where you need help (including and beyond
> > coding)?
> >
> > How explicit are you with downstream users that some of the inner
> workings
> > of Apache projects are build around a scratch your own itch casual
> > contributions that ideally should be rewarded the same way as full-time
> > contributions (
> > https://blogs.apache.org/foundation/entry/success-at-apache-for-love )?
> >
> > I think you want to enable as many ppl as possible - typically only ten
> > percent of your users turn into contributor, of those only ten percent
> > trend to be repeat contributors... at least in my experience.
> >
> > Just some ideas,
> > Isabel
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >
>

Re: Call for Ideas and Approaches to Community Building

[Anirudh Acharya]

Having only non-organization PMC members nominate new committers could
un-level the playing field.
1. Many times contributions might not require a contributor to have direct
1:1 discussion with PMC members outside his org.
2. It would give inordinate power/responsibility to the few non-Amazon
active PMC members.

Just my 2 cents.


Thanks
Anirudh

On Wed, Mar 6, 2019 at 7:10 AM Isabel Drost-Fromm  wrote:

>
>
> Am 2. März 2019 15:13:23 MEZ schrieb Carin Meier :
> >I wanted to kickoff a discussion about community building. There was an
> >excellent blog post from the Apache Beam Community on this
> >https://blogs.apache.org/comdev/entry/an-approach-to-community-building
>
> Needless to say I really love that blog post.
>
> Other than that there are a couple of question you might ask yourself as a
> community:
>
> How easy is it to patriciate as an outsider, how much communication is
> happening outside of dev@?
>
> How explicit are you about how inclusive you want to be? See also
> https://youtu.be/LgB1s3buccI
>
> How explicit are you about where you need help (including and beyond
> coding)?
>
> How explicit are you with downstream users that some of the inner workings
> of Apache projects are build around a scratch your own itch casual
> contributions that ideally should be rewarded the same way as full-time
> contributions (
> https://blogs.apache.org/foundation/entry/success-at-apache-for-love )?
>
> I think you want to enable as many ppl as possible - typically only ten
> percent of your users turn into contributor, of those only ten percent
> trend to be repeat contributors... at least in my experience.
>
> Just some ideas,
> Isabel
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Re: Call for Ideas and Approaches to Community Building

[Isabel Drost-Fromm]

Am 2. März 2019 15:13:23 MEZ schrieb Carin Meier :
>I wanted to kickoff a discussion about community building. There was an
>excellent blog post from the Apache Beam Community on this
>https://blogs.apache.org/comdev/entry/an-approach-to-community-building

Needless to say I really love that blog post.

Other than that there are a couple of question you might ask yourself as a 
community:

How easy is it to patriciate as an outsider, how much communication is 
happening outside of dev@?

How explicit are you about how inclusive you want to be? See also 
https://youtu.be/LgB1s3buccI

How explicit are you about where you need help (including and beyond coding)?

How explicit are you with downstream users that some of the inner workings of 
Apache projects are build around a scratch your own itch casual contributions 
that ideally should be rewarded the same way as full-time contributions 
(https://blogs.apache.org/foundation/entry/success-at-apache-for-love )?

I think you want to enable as many ppl as possible - typically only ten percent 
of your users turn into contributor, of those only ten percent trend to be 
repeat contributors... at least in my experience.

Just some ideas,
Isabel
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Call for Ideas and Approaches to Community Building

[Tianqi Chen]

Thanks, Carin for bringing this topic up.

I have suggested this several times. But would like to do it again. One
approach toward building a more diverse community is to acknowledge the
fact that we want to encourage interactions in the Apache way beyond our
physical cycle.

One principle to toward that is to encourage PMC members only nominate
committers from other organizations, so it encourages interactions and
gives incentives overall for general participation. This way does not
prevent people from getting nominated (The PMC member who is non-colleague
will nominate the person with merit), and also encourage broad
participation (I can tell my fellows to participate in community discussion
because it is really up to other PMC members to propose them). Of course,
this requires some trust in the community toward positive community
building, which may or may not doable here. But nevertheless, I think it is
a good principle.

Tianqi

On Sat, Mar 2, 2019 at 9:13 AM Carin Meier  wrote:

> I wanted to kickoff a discussion about community building. There was an
> excellent blog post from the Apache Beam Community on this
> https://blogs.apache.org/comdev/entry/an-approach-to-community-building
>
> In it they wanted to improve their contributor/committer base in the
> following ways which resonate with our project as well, quoting from the
> article:
>
> 
> 1. We could use more committers to review all the code being contributed,
> in part due to recent departure of a few committers
>
> 2. We want our contributor-base (hence committer-base) to be more spread
> across companies and backgrounds. This is a core value of the Apache
> Software Foundation. In particular, the project's direction should not be
> dominated by any company, and the project should be able to survive the
> departure of a major contributor or all contributors from a particular
> employer. Eventually, we hope that our user base is active and diverse
> enough that this happens naturally. But we are not there yet, so instead we
> have to work hard to build our community around the software we already
> have.
> 
>
>
> They outlined some of the steps that they took to achieve positive results
> in the article, which I encourage everyone to read.
>
> Every community is different, however, so things that worked well in their
> community might not be as effective as in ours. I wanted to kick off a
> discussion for ideas that people had here on community building for MXNet.
>
> Ideas and thoughts on this are most welcome.
>
> - Carin
>