Suggestions on how to increase community involvement on Apache MXNet incubating?

[Bhavin Thaker <bh...@gmail.com>]

Hi Team,

Do you have any suggestions on how to increase community involvement and
contributions including code additions/changes, bug-fixes/enhancements,
documentation updates, tutorials, increased adoption, answering questions
on Stackoverflow/discuss.mxnet.io, etc.?

While I have asked multiple questions in the one question above, I am
looking for more ideas or thoughts.

Cheers,
Bhavin Thaker.

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[sandeep krishnamurthy <sa...@gmail.com>]

As mentioned by others, it is very important for the community to know what
is happening, roadmap, low hanging bug fix or feature development.
Along with that, it is hard and time-consuming to get a basic high-level
understanding of various components, architecture and packages of MXNet.

My 2 cent suggestion - Most scalable and useful way of achieving above
objective would be a "set of video lectures on Youtube". We can have couple
of videos to cover topics such as - Introduction to MXNet Architecture and
components, Setting up MXNet on Mac with CLion or PyCharm for Python, Code
walkthrough with usecase - For example: Operator end to end debug trace
walk through.

These videos can be used as resources for developers to play, follow and
get things up and running.

Videos are not a replacement for presence in university lectures,
presentations at conferences. However, videos can be scalable way of
achieving the purpose of getting many people to setup and start seeing code
of MXNet.

Suggestions?

Thanks,
Sandeep

On Thu, Jan 4, 2018 at 10:59 AM, Tianqi Chen <tq...@cs.washington.edu>
wrote:

> I think the main point being raised is an easy way to know what is
> happening and proposals.
>
> Github has quite a lot of nice features with respect to this:
>
>  - Issues make perfect sense in terms of discussing a single-point of
> feature/bug and get feedback from anyone who can comment, additionally
> being linked to pull request.
>  - Issues are less useful for long-term roadmaps and discussions, there is
> a feature called project(which is like trello) can be used for such things.
>
> One problem we had in before is that roadmap issues get down the list
> quickly and get deprecated by time without being closed. Aggressively close
> issues and link them from a place that never sink, like project or wiki
> might solve this issue.
>
>
> Additionally, the dev mail list seems to serve a purpose to get to
> developers, which can contain
> - The discussion of major design points, before they actually being landed
> on road-map
> - general questions to raise people's attention to the certain issue being
> progressed
>
> Tianqi
>
> On Thu, Jan 4, 2018 at 10:08 AM, Marco de Abreu <
> marco.g.abreu@googlemail.com> wrote:
>
> > Hello Markus,
> >
> > first of all, very good points!
> >
> > Regarding (1): In my opinion, we should always have some time of chat as
> > this is the most convenient way for users and contributors to ask a quick
> > question. I agree that proper discussions should be held on dev@, but
> > sometimes a quick discussion in a chat is way more effective than writing
> > dozens of emails - also, there might be some people who don't want to
> write
> > an email to a mailing list just to ask a question that can be answered
> > within 10 seconds. So instead I'd propose that we agree on one chat
> > platforms for informal discussions and requests and that everything else
> > gets put on dev@.
> >
> > -Marco
> >
> > On Thu, Jan 4, 2018 at 6:51 PM, Markus Weimer <ma...@weimo.de> wrote:
> >
> > > I really like most of what has been said, and the below might be a bit
> > of a
> > > repeat, but through a different lens.
> > >
> > > One key aspect to consider when thinking about participation in OSS
> > > projects is the journey a contributor makes, which starts before even
> > using
> > > the software. Each of the steps of the journey is only traversed by a
> > > minuscule number of people, so it is a good idea to have as many people
> > as
> > > possible lined up at the beginning of the process :) A quick guestimate
> > of
> > > the journey for a future contributor looks something like this:
> > >
> > > 1) They have to know off the project, which can be addressed by
> > > conferences, talks at universities and such.
> > > 2) They have to want to become users. This is really difficult to make
> > > happen externally :)
> > > 3) They have to be successful in their first use. Tutorials help with
> > that,
> > > and I think mxnet is doing a fantastic job there with the Gluon book.
> > > 4) They need to be able to "lurk" among other users: There needs to be
> a
> > > place where the users of the software come together and chat, complain
> > and
> > > help. Specifically, there should be *one* such place. The exact
> > mechanisms
> > > can differ, but I found that email lists still serve this use case
> well,
> > as
> > > they are sticky: Once subscribed, people stay informed :)
> > >
> > > If we get people to this stage, we can be proud: We just gained
> > > contributors: They are helping each other out, advocate for the project
> > and
> > > all. Now, the next step is for them to contribute to the code in
> addition
> > > to the community:
> > >
> > > 5) They have to know how to contribute, e.g. a bug report. And that
> first
> > > time they do it needs to be encouraging for future contributions.
> > > 6) They need to be able to observe the work as it happens, e.g. by
> > lurking
> > > on the mailing list. This gives context on what the community thinks
> > about,
> > > how it makes decisions, ... . Just like in RL, observing a community
> > gives
> > > confidence on how to engage with it.
> > > 7) When they start thinking about contributing, the process to do so
> > needs
> > > to be clear. If step 6) worked, this doesn't even have to be very
> formal.
> > >
> > > Certainly, there are steps and hurdles that I forgot. There is a reason
> > > whole PhD theses are written about participation in OSS. But thinking
> > down
> > > the lines of the journey should help us identify actions to be taken.
> > >
> > > With that descriptive stuff being said, allow me to be prescriptive
> with
> > > some ideas:
> > >
> > > (1) Drop all communications channels besides the dev list.This greatly
> > > simplifies lurking. My $DAY_JOB doesn't give me a chance to really
> follow
> > > slack, for instance. But I read every email on this list.
> > > (2) For those of you collocated in the same institution: Force yourself
> > to
> > > not talk about mxnet in the office or at lunch. Pretend not to be in
> the
> > > same room or even on the same continent. Move all discussions onto the
> > > list. This makes lurking easier, and, in my experience, improves the
> > > quality of the technical discussions.
> > > (3) Decide on one way for users to discuss among each other. Most
> Apache
> > > projects use email lists for it as well. Which, granted, is pretty old
> > > school.
> > >
> > > Thanks for reading this far, I did not have enough time to write less
> :)
> > >
> > > Markus
> > >
> > >
> > >
> > > On Thu, Jan 4, 2018 at 5:22 AM, Pedro Larroy <
> > pedro.larroy.lists@gmail.com
> > > >
> > > wrote:
> > >
> > > > Agreed with Chris and Jeff. Googling for MXNet roadmap is
> > > > enlightening. Also the communication channels are disperse.
> > > > I would remove suggesting "Ask questions" in issues in the README.md
> > > > because this encourages inflation of issues that are just questions.
> > > >
> > > > We should link to the slack channel or discuss or mailing list in the
> > > > README and be clear on how to use those communication channels.
> > > >
> > > > More visibility on epics / roadmap in something like Trello? Roadmap
> > > > tagged issues right not don't seem to be really maintained.
> > > >
> > > > Explicitly asking in a TODO file or in the README or the Wiki on how
> > > > other people can contribute.
> > > > Having a list of "low hanging fruit" issues for newcomers to pick and
> > > > get familiar contributing to the project.
> > > > Making a blog post about how to contribute to MXNet, can be as simple
> > > > as how to use CLion to contribute to the project and send a patch...
> > > >
> > > > Just my thoughts.
> > > >
> > > > Pedro.
> > > >
> > > > On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier <cjolivier01@gmail.com
> >
> > > > wrote:
> > > > > I suggest more transparency in the development process and
> > requirement
> > > > > definitions and grooming.
> > > > >
> > > > > Backlog wish-list on public wiki, which link to public JIRA epics
> or
> > > > > stories, where people outside of Amazon can edit/comment on the
> items
> > > or
> > > > > add items themselves.
> > > > >
> > > > >
> > > > > On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <
> > bhavinthaker@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> Hi Team,
> > > > >>
> > > > >> Do you have any suggestions on how to increase community
> involvement
> > > and
> > > > >> contributions including code additions/changes,
> > > bug-fixes/enhancements,
> > > > >> documentation updates, tutorials, increased adoption, answering
> > > > questions
> > > > >> on Stackoverflow/discuss.mxnet.io, etc.?
> > > > >>
> > > > >> While I have asked multiple questions in the one question above, I
> > am
> > > > >> looking for more ideas or thoughts.
> > > > >>
> > > > >> Cheers,
> > > > >> Bhavin Thaker.
> > > > >>
> > > >
> > >
> >
>



-- 
Sandeep Krishnamurthy

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Tianqi Chen <tq...@cs.washington.edu>]

I think the main point being raised is an easy way to know what is
happening and proposals.

Github has quite a lot of nice features with respect to this:

 - Issues make perfect sense in terms of discussing a single-point of
feature/bug and get feedback from anyone who can comment, additionally
being linked to pull request.
 - Issues are less useful for long-term roadmaps and discussions, there is
a feature called project(which is like trello) can be used for such things.

One problem we had in before is that roadmap issues get down the list
quickly and get deprecated by time without being closed. Aggressively close
issues and link them from a place that never sink, like project or wiki
might solve this issue.


Additionally, the dev mail list seems to serve a purpose to get to
developers, which can contain
- The discussion of major design points, before they actually being landed
on road-map
- general questions to raise people's attention to the certain issue being
progressed

Tianqi

On Thu, Jan 4, 2018 at 10:08 AM, Marco de Abreu <
marco.g.abreu@googlemail.com> wrote:

> Hello Markus,
>
> first of all, very good points!
>
> Regarding (1): In my opinion, we should always have some time of chat as
> this is the most convenient way for users and contributors to ask a quick
> question. I agree that proper discussions should be held on dev@, but
> sometimes a quick discussion in a chat is way more effective than writing
> dozens of emails - also, there might be some people who don't want to write
> an email to a mailing list just to ask a question that can be answered
> within 10 seconds. So instead I'd propose that we agree on one chat
> platforms for informal discussions and requests and that everything else
> gets put on dev@.
>
> -Marco
>
> On Thu, Jan 4, 2018 at 6:51 PM, Markus Weimer <ma...@weimo.de> wrote:
>
> > I really like most of what has been said, and the below might be a bit
> of a
> > repeat, but through a different lens.
> >
> > One key aspect to consider when thinking about participation in OSS
> > projects is the journey a contributor makes, which starts before even
> using
> > the software. Each of the steps of the journey is only traversed by a
> > minuscule number of people, so it is a good idea to have as many people
> as
> > possible lined up at the beginning of the process :) A quick guestimate
> of
> > the journey for a future contributor looks something like this:
> >
> > 1) They have to know off the project, which can be addressed by
> > conferences, talks at universities and such.
> > 2) They have to want to become users. This is really difficult to make
> > happen externally :)
> > 3) They have to be successful in their first use. Tutorials help with
> that,
> > and I think mxnet is doing a fantastic job there with the Gluon book.
> > 4) They need to be able to "lurk" among other users: There needs to be a
> > place where the users of the software come together and chat, complain
> and
> > help. Specifically, there should be *one* such place. The exact
> mechanisms
> > can differ, but I found that email lists still serve this use case well,
> as
> > they are sticky: Once subscribed, people stay informed :)
> >
> > If we get people to this stage, we can be proud: We just gained
> > contributors: They are helping each other out, advocate for the project
> and
> > all. Now, the next step is for them to contribute to the code in addition
> > to the community:
> >
> > 5) They have to know how to contribute, e.g. a bug report. And that first
> > time they do it needs to be encouraging for future contributions.
> > 6) They need to be able to observe the work as it happens, e.g. by
> lurking
> > on the mailing list. This gives context on what the community thinks
> about,
> > how it makes decisions, ... . Just like in RL, observing a community
> gives
> > confidence on how to engage with it.
> > 7) When they start thinking about contributing, the process to do so
> needs
> > to be clear. If step 6) worked, this doesn't even have to be very formal.
> >
> > Certainly, there are steps and hurdles that I forgot. There is a reason
> > whole PhD theses are written about participation in OSS. But thinking
> down
> > the lines of the journey should help us identify actions to be taken.
> >
> > With that descriptive stuff being said, allow me to be prescriptive with
> > some ideas:
> >
> > (1) Drop all communications channels besides the dev list.This greatly
> > simplifies lurking. My $DAY_JOB doesn't give me a chance to really follow
> > slack, for instance. But I read every email on this list.
> > (2) For those of you collocated in the same institution: Force yourself
> to
> > not talk about mxnet in the office or at lunch. Pretend not to be in the
> > same room or even on the same continent. Move all discussions onto the
> > list. This makes lurking easier, and, in my experience, improves the
> > quality of the technical discussions.
> > (3) Decide on one way for users to discuss among each other. Most Apache
> > projects use email lists for it as well. Which, granted, is pretty old
> > school.
> >
> > Thanks for reading this far, I did not have enough time to write less :)
> >
> > Markus
> >
> >
> >
> > On Thu, Jan 4, 2018 at 5:22 AM, Pedro Larroy <
> pedro.larroy.lists@gmail.com
> > >
> > wrote:
> >
> > > Agreed with Chris and Jeff. Googling for MXNet roadmap is
> > > enlightening. Also the communication channels are disperse.
> > > I would remove suggesting "Ask questions" in issues in the README.md
> > > because this encourages inflation of issues that are just questions.
> > >
> > > We should link to the slack channel or discuss or mailing list in the
> > > README and be clear on how to use those communication channels.
> > >
> > > More visibility on epics / roadmap in something like Trello? Roadmap
> > > tagged issues right not don't seem to be really maintained.
> > >
> > > Explicitly asking in a TODO file or in the README or the Wiki on how
> > > other people can contribute.
> > > Having a list of "low hanging fruit" issues for newcomers to pick and
> > > get familiar contributing to the project.
> > > Making a blog post about how to contribute to MXNet, can be as simple
> > > as how to use CLion to contribute to the project and send a patch...
> > >
> > > Just my thoughts.
> > >
> > > Pedro.
> > >
> > > On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier <cj...@gmail.com>
> > > wrote:
> > > > I suggest more transparency in the development process and
> requirement
> > > > definitions and grooming.
> > > >
> > > > Backlog wish-list on public wiki, which link to public JIRA epics or
> > > > stories, where people outside of Amazon can edit/comment on the items
> > or
> > > > add items themselves.
> > > >
> > > >
> > > > On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <
> bhavinthaker@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Hi Team,
> > > >>
> > > >> Do you have any suggestions on how to increase community involvement
> > and
> > > >> contributions including code additions/changes,
> > bug-fixes/enhancements,
> > > >> documentation updates, tutorials, increased adoption, answering
> > > questions
> > > >> on Stackoverflow/discuss.mxnet.io, etc.?
> > > >>
> > > >> While I have asked multiple questions in the one question above, I
> am
> > > >> looking for more ideas or thoughts.
> > > >>
> > > >> Cheers,
> > > >> Bhavin Thaker.
> > > >>
> > >
> >
>

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Marco de Abreu <ma...@googlemail.com>]

Hello Markus,

first of all, very good points!

Regarding (1): In my opinion, we should always have some time of chat as
this is the most convenient way for users and contributors to ask a quick
question. I agree that proper discussions should be held on dev@, but
sometimes a quick discussion in a chat is way more effective than writing
dozens of emails - also, there might be some people who don't want to write
an email to a mailing list just to ask a question that can be answered
within 10 seconds. So instead I'd propose that we agree on one chat
platforms for informal discussions and requests and that everything else
gets put on dev@.

-Marco

On Thu, Jan 4, 2018 at 6:51 PM, Markus Weimer <ma...@weimo.de> wrote:

> I really like most of what has been said, and the below might be a bit of a
> repeat, but through a different lens.
>
> One key aspect to consider when thinking about participation in OSS
> projects is the journey a contributor makes, which starts before even using
> the software. Each of the steps of the journey is only traversed by a
> minuscule number of people, so it is a good idea to have as many people as
> possible lined up at the beginning of the process :) A quick guestimate of
> the journey for a future contributor looks something like this:
>
> 1) They have to know off the project, which can be addressed by
> conferences, talks at universities and such.
> 2) They have to want to become users. This is really difficult to make
> happen externally :)
> 3) They have to be successful in their first use. Tutorials help with that,
> and I think mxnet is doing a fantastic job there with the Gluon book.
> 4) They need to be able to "lurk" among other users: There needs to be a
> place where the users of the software come together and chat, complain and
> help. Specifically, there should be *one* such place. The exact mechanisms
> can differ, but I found that email lists still serve this use case well, as
> they are sticky: Once subscribed, people stay informed :)
>
> If we get people to this stage, we can be proud: We just gained
> contributors: They are helping each other out, advocate for the project and
> all. Now, the next step is for them to contribute to the code in addition
> to the community:
>
> 5) They have to know how to contribute, e.g. a bug report. And that first
> time they do it needs to be encouraging for future contributions.
> 6) They need to be able to observe the work as it happens, e.g. by lurking
> on the mailing list. This gives context on what the community thinks about,
> how it makes decisions, ... . Just like in RL, observing a community gives
> confidence on how to engage with it.
> 7) When they start thinking about contributing, the process to do so needs
> to be clear. If step 6) worked, this doesn't even have to be very formal.
>
> Certainly, there are steps and hurdles that I forgot. There is a reason
> whole PhD theses are written about participation in OSS. But thinking down
> the lines of the journey should help us identify actions to be taken.
>
> With that descriptive stuff being said, allow me to be prescriptive with
> some ideas:
>
> (1) Drop all communications channels besides the dev list.This greatly
> simplifies lurking. My $DAY_JOB doesn't give me a chance to really follow
> slack, for instance. But I read every email on this list.
> (2) For those of you collocated in the same institution: Force yourself to
> not talk about mxnet in the office or at lunch. Pretend not to be in the
> same room or even on the same continent. Move all discussions onto the
> list. This makes lurking easier, and, in my experience, improves the
> quality of the technical discussions.
> (3) Decide on one way for users to discuss among each other. Most Apache
> projects use email lists for it as well. Which, granted, is pretty old
> school.
>
> Thanks for reading this far, I did not have enough time to write less :)
>
> Markus
>
>
>
> On Thu, Jan 4, 2018 at 5:22 AM, Pedro Larroy <pedro.larroy.lists@gmail.com
> >
> wrote:
>
> > Agreed with Chris and Jeff. Googling for MXNet roadmap is
> > enlightening. Also the communication channels are disperse.
> > I would remove suggesting "Ask questions" in issues in the README.md
> > because this encourages inflation of issues that are just questions.
> >
> > We should link to the slack channel or discuss or mailing list in the
> > README and be clear on how to use those communication channels.
> >
> > More visibility on epics / roadmap in something like Trello? Roadmap
> > tagged issues right not don't seem to be really maintained.
> >
> > Explicitly asking in a TODO file or in the README or the Wiki on how
> > other people can contribute.
> > Having a list of "low hanging fruit" issues for newcomers to pick and
> > get familiar contributing to the project.
> > Making a blog post about how to contribute to MXNet, can be as simple
> > as how to use CLion to contribute to the project and send a patch...
> >
> > Just my thoughts.
> >
> > Pedro.
> >
> > On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier <cj...@gmail.com>
> > wrote:
> > > I suggest more transparency in the development process and requirement
> > > definitions and grooming.
> > >
> > > Backlog wish-list on public wiki, which link to public JIRA epics or
> > > stories, where people outside of Amazon can edit/comment on the items
> or
> > > add items themselves.
> > >
> > >
> > > On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <bhavinthaker@gmail.com
> >
> > > wrote:
> > >
> > >> Hi Team,
> > >>
> > >> Do you have any suggestions on how to increase community involvement
> and
> > >> contributions including code additions/changes,
> bug-fixes/enhancements,
> > >> documentation updates, tutorials, increased adoption, answering
> > questions
> > >> on Stackoverflow/discuss.mxnet.io, etc.?
> > >>
> > >> While I have asked multiple questions in the one question above, I am
> > >> looking for more ideas or thoughts.
> > >>
> > >> Cheers,
> > >> Bhavin Thaker.
> > >>
> >
>

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Markus Weimer <ma...@weimo.de>]

I really like most of what has been said, and the below might be a bit of a
repeat, but through a different lens.

One key aspect to consider when thinking about participation in OSS
projects is the journey a contributor makes, which starts before even using
the software. Each of the steps of the journey is only traversed by a
minuscule number of people, so it is a good idea to have as many people as
possible lined up at the beginning of the process :) A quick guestimate of
the journey for a future contributor looks something like this:

1) They have to know off the project, which can be addressed by
conferences, talks at universities and such.
2) They have to want to become users. This is really difficult to make
happen externally :)
3) They have to be successful in their first use. Tutorials help with that,
and I think mxnet is doing a fantastic job there with the Gluon book.
4) They need to be able to "lurk" among other users: There needs to be a
place where the users of the software come together and chat, complain and
help. Specifically, there should be *one* such place. The exact mechanisms
can differ, but I found that email lists still serve this use case well, as
they are sticky: Once subscribed, people stay informed :)

If we get people to this stage, we can be proud: We just gained
contributors: They are helping each other out, advocate for the project and
all. Now, the next step is for them to contribute to the code in addition
to the community:

5) They have to know how to contribute, e.g. a bug report. And that first
time they do it needs to be encouraging for future contributions.
6) They need to be able to observe the work as it happens, e.g. by lurking
on the mailing list. This gives context on what the community thinks about,
how it makes decisions, ... . Just like in RL, observing a community gives
confidence on how to engage with it.
7) When they start thinking about contributing, the process to do so needs
to be clear. If step 6) worked, this doesn't even have to be very formal.

Certainly, there are steps and hurdles that I forgot. There is a reason
whole PhD theses are written about participation in OSS. But thinking down
the lines of the journey should help us identify actions to be taken.

With that descriptive stuff being said, allow me to be prescriptive with
some ideas:

(1) Drop all communications channels besides the dev list.This greatly
simplifies lurking. My $DAY_JOB doesn't give me a chance to really follow
slack, for instance. But I read every email on this list.
(2) For those of you collocated in the same institution: Force yourself to
not talk about mxnet in the office or at lunch. Pretend not to be in the
same room or even on the same continent. Move all discussions onto the
list. This makes lurking easier, and, in my experience, improves the
quality of the technical discussions.
(3) Decide on one way for users to discuss among each other. Most Apache
projects use email lists for it as well. Which, granted, is pretty old
school.

Thanks for reading this far, I did not have enough time to write less :)

Markus



On Thu, Jan 4, 2018 at 5:22 AM, Pedro Larroy <pe...@gmail.com>
wrote:

> Agreed with Chris and Jeff. Googling for MXNet roadmap is
> enlightening. Also the communication channels are disperse.
> I would remove suggesting "Ask questions" in issues in the README.md
> because this encourages inflation of issues that are just questions.
>
> We should link to the slack channel or discuss or mailing list in the
> README and be clear on how to use those communication channels.
>
> More visibility on epics / roadmap in something like Trello? Roadmap
> tagged issues right not don't seem to be really maintained.
>
> Explicitly asking in a TODO file or in the README or the Wiki on how
> other people can contribute.
> Having a list of "low hanging fruit" issues for newcomers to pick and
> get familiar contributing to the project.
> Making a blog post about how to contribute to MXNet, can be as simple
> as how to use CLion to contribute to the project and send a patch...
>
> Just my thoughts.
>
> Pedro.
>
> On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier <cj...@gmail.com>
> wrote:
> > I suggest more transparency in the development process and requirement
> > definitions and grooming.
> >
> > Backlog wish-list on public wiki, which link to public JIRA epics or
> > stories, where people outside of Amazon can edit/comment on the items or
> > add items themselves.
> >
> >
> > On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <bh...@gmail.com>
> > wrote:
> >
> >> Hi Team,
> >>
> >> Do you have any suggestions on how to increase community involvement and
> >> contributions including code additions/changes, bug-fixes/enhancements,
> >> documentation updates, tutorials, increased adoption, answering
> questions
> >> on Stackoverflow/discuss.mxnet.io, etc.?
> >>
> >> While I have asked multiple questions in the one question above, I am
> >> looking for more ideas or thoughts.
> >>
> >> Cheers,
> >> Bhavin Thaker.
> >>
>

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Pedro Larroy <pe...@gmail.com>]

Agreed with Chris and Jeff. Googling for MXNet roadmap is
enlightening. Also the communication channels are disperse.
I would remove suggesting "Ask questions" in issues in the README.md
because this encourages inflation of issues that are just questions.

We should link to the slack channel or discuss or mailing list in the
README and be clear on how to use those communication channels.

More visibility on epics / roadmap in something like Trello? Roadmap
tagged issues right not don't seem to be really maintained.

Explicitly asking in a TODO file or in the README or the Wiki on how
other people can contribute.
Having a list of "low hanging fruit" issues for newcomers to pick and
get familiar contributing to the project.
Making a blog post about how to contribute to MXNet, can be as simple
as how to use CLion to contribute to the project and send a patch...

Just my thoughts.

Pedro.

On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier <cj...@gmail.com> wrote:
> I suggest more transparency in the development process and requirement
> definitions and grooming.
>
> Backlog wish-list on public wiki, which link to public JIRA epics or
> stories, where people outside of Amazon can edit/comment on the items or
> add items themselves.
>
>
> On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <bh...@gmail.com>
> wrote:
>
>> Hi Team,
>>
>> Do you have any suggestions on how to increase community involvement and
>> contributions including code additions/changes, bug-fixes/enhancements,
>> documentation updates, tutorials, increased adoption, answering questions
>> on Stackoverflow/discuss.mxnet.io, etc.?
>>
>> While I have asked multiple questions in the one question above, I am
>> looking for more ideas or thoughts.
>>
>> Cheers,
>> Bhavin Thaker.
>>

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Jeff Zemerick <jz...@apache.org>]

As a very fresh newcomer it is a bit unclear to me what communication
channels should be used for dev/user conversations. For instance, this
email address is not listed on the MXNet Community [1] page. I found the
email address on the Development Discussion [2] page through a Google
search (maybe I missed the link?). This email address and the Slack channel
seem to be low traffic. User discussions appear to be on
https://discuss.mxnet.io/. When I joined I expected to see more traffic on
this dev@ list.

Jeff


[1] https://mxnet.apache.org/community/index.html
[2] https://mxnet.incubator.apache.org/community/mxnet_channels.html


On Wed, Jan 3, 2018 at 5:24 PM, kellen sunderland <
kellen.sunderland@gmail.com> wrote:

> One suggestion might be to have a presence at more open source
> conferences.  We could also try to form partnerships with more
> organizations that traditionally contribute back to open source.
>
> On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier <cj...@gmail.com>
> wrote:
>
> > I suggest more transparency in the development process and requirement
> > definitions and grooming.
> >
> > Backlog wish-list on public wiki, which link to public JIRA epics or
> > stories, where people outside of Amazon can edit/comment on the items or
> > add items themselves.
> >
> >
> > On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <bh...@gmail.com>
> > wrote:
> >
> > > Hi Team,
> > >
> > > Do you have any suggestions on how to increase community involvement
> and
> > > contributions including code additions/changes, bug-fixes/enhancements,
> > > documentation updates, tutorials, increased adoption, answering
> questions
> > > on Stackoverflow/discuss.mxnet.io, etc.?
> > >
> > > While I have asked multiple questions in the one question above, I am
> > > looking for more ideas or thoughts.
> > >
> > > Cheers,
> > > Bhavin Thaker.
> > >
> >
>

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[kellen sunderland <ke...@gmail.com>]

One suggestion might be to have a presence at more open source
conferences.  We could also try to form partnerships with more
organizations that traditionally contribute back to open source.

On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier <cj...@gmail.com> wrote:

> I suggest more transparency in the development process and requirement
> definitions and grooming.
>
> Backlog wish-list on public wiki, which link to public JIRA epics or
> stories, where people outside of Amazon can edit/comment on the items or
> add items themselves.
>
>
> On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <bh...@gmail.com>
> wrote:
>
> > Hi Team,
> >
> > Do you have any suggestions on how to increase community involvement and
> > contributions including code additions/changes, bug-fixes/enhancements,
> > documentation updates, tutorials, increased adoption, answering questions
> > on Stackoverflow/discuss.mxnet.io, etc.?
> >
> > While I have asked multiple questions in the one question above, I am
> > looking for more ideas or thoughts.
> >
> > Cheers,
> > Bhavin Thaker.
> >
>

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Chris Olivier <cj...@gmail.com>]

I suggest more transparency in the development process and requirement
definitions and grooming.

Backlog wish-list on public wiki, which link to public JIRA epics or
stories, where people outside of Amazon can edit/comment on the items or
add items themselves.


On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker <bh...@gmail.com>
wrote:

> Hi Team,
>
> Do you have any suggestions on how to increase community involvement and
> contributions including code additions/changes, bug-fixes/enhancements,
> documentation updates, tutorials, increased adoption, answering questions
> on Stackoverflow/discuss.mxnet.io, etc.?
>
> While I have asked multiple questions in the one question above, I am
> looking for more ideas or thoughts.
>
> Cheers,
> Bhavin Thaker.
>