mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sandeep krishnamurthy <sandeep.krishn...@gmail.com>
Subject Re: Suggestions on how to increase community involvement on Apache MXNet incubating?
Date Fri, 05 Jan 2018 04:38:47 GMT
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 <tqchen@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 <markus@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message