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.ab...@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 <mar...@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.li...@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 <cjolivie...@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 < > bhavintha...@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. > > > >> > > > > > >
