Can't you simply tell contributors to discuss changes on dev before submitting
a PR? Since the contribution guidelines don't tell developers to post to dev,
why would you expect them to do that?
Is there an easy way to just subscribe to PR notifications or will someone have
to write a filter to avoid spamming dev with all GitHub notifications? I think
that if dev gets too much traffic, then people with casual interest may find it
easier to unsubscribe than to set up filters. Once someone unsubscribes, they
probably won't be coming back soon, so you should be very careful with this.
I don't see why artificially increasing the traffic on dev will do anything to
grow the community in any case.
- C
On 7/18/18, 11:17 AM, "Indhu" <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
> >
>
>
>
