A discussion is a discussion, and in the case of MXNet I’d say a lot more high quality discussion has happened on GitHub than on dev@. Github issues have plenty of discussions before code change. The reason is simply because MXNet has longer history on Github than the existence of dev list, and long-term contributors tend to bring high quality discussion on dev@.
I don’t intend to flood the dev list with this vote. There are high quality discussions on the github that people on dev list can benefit from, and that’s the only intention for such change. The community feedback will help decide how to best integrate these two communication tools. However, some good solutions such as the “opt-in w/ github mention” that Qing has brought up will require exploration with apache infra team, which requires a vote to show the will of the community first. -sz > On Jul 18, 2018, at 8:16 AM, Indue <indhubhara...@gmail.com> wrote: > > Some mentors/contributors/committees feel that the amount of discussions in > dev list is too less given the amount of commits that happen and more > discussions need to happen in the dev list to grow the community. > > In response some committees feel discussions actually happen in GitHub PRs. > If the policy says "if it didn't happen in dev, it didn't happen", let's > forward all GitHub discussions to dev so those discussions would count. > That's the motivation for this vote. > > I think when people say there needs to be more discussions in the dev list, > I assume they mean the kind of discussions that happen *before* a PR is > created or even before someone starts working on anything. I don't think > people are asking an email for every activity on GitHub. The correct way to > address the problem would be for committees/contributors to stop > communicating in private channels (like Amazon or DMLC communication > channels) and do those discussions in the dev list instead. > > Indu > > > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher < > christopher.bar...@analog.com> wrote: > >> Can't people already subscribe to github notifications? I think it is safe >> to assume that developers are already smart enough to figure out how to do >> that if they want. What problem are you really trying to solve here? >> >> On 7/18/18, 4:49 AM, "Chris Olivier" <cjolivie...@gmail.com> wrote: >> >> -1. (changed from -0.9) >> >> seems more like a strategy (whether intentional or on accident) to >> *not* >> have design discussions on dev by flooding it with noise and then later >> claim it was discussed, even though you would have to sift through >> thousands of emails to find it. >> >> >> >> On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol <rahulhuil...@gmail.com >>> >> wrote: >> >>> I pulled up some more stats so we can make an informed decision. >>> >>> Here are some popular Apache projects and the number of emails to >> their >>> dev@ >>> list in the last 30 days >>> Apache Flink: 540 mails >>> Apache Spark: 249 mails >>> Apache Hive: 481 mails >>> Apache HBase: 300 mails >>> >>> Current dev list for MXNet: 348 mails >>> Current commits list for MXNet: 5329 mails >>> Making the proposed dev list for MXNet to be ~5677 mails. >>> >>> Sheng, even going by your comments that 1 of of those 4 mails are >> relevant >>> for dev@, that's still a really high number of emails. (130 email >> lists >>> doesn't say anything if we ignore the actual number of emails in >> those >>> lists, especially when the 131st sends these many mails :) ). People >> are >>> already talking about setting up filters here. Doesn't that defeat >> the >>> purpose by making people filter out the discussion on Github? People >> can >>> subscribe to commits@ if they find it more convenient to follow >> Github >>> activity over email rather than Github.com. >>> >>> We should strive to maintain dev@ as a place for high quality >> discussion. >>> It's upto the contributors to bring up something to dev@ if they >> believe >>> it >>> deserves a focused discussion in the community. That discussion may >> be >>> started by the person who proposes code changes, or a reviewer who >> believes >>> that a particular code change warrants further discussion. >>> >>> Regards, >>> Rahul >>> >> >> >>
