On Thu, Mar 26, 2015 at 4:33 AM, Greg Stein <gst...@gmail.com> wrote:
> On Wed, Mar 25, 2015 at 5:38 PM, Marvin Humphrey <mar...@rectangular.com>
> wrote:
> ALL discussion should be on the dev@ list. Including "nitty gritty
> implementation". That should not be buried in a separate system.
>
> JIRA is for tracking issues. Not for discussion. The mailing list is for
> discussion.
There's a spectrum of "discussion". At one end we have:
Let's choose between Go and Rust for Steve v2.
At the other end we have:
Your patch has a typo. Please subscribe to the dev list so I can tell you
the line number.
> Until our JIRA traffic becomes burdensome (which it isn't), then splitting
> it to its own mailing list merely hides that information from the
> development community. Today, we barely see any JIRA traffic. Same reason
> we don't have a user@ mailing list ... there just isn't enough traffic to
> justify the separations.
Whether or not to shunt JIRA notifications to the dev list is a fundamental
choice that Apache projects make.
If notifications go to the dev list, eventually nearly all conversations will
happen in JIRA. This makes it harder to follow discussions via email because
the notifications are poorly formatted and often irrelevant, and a threshold
effect manifests where only people who are motivated enough to click through
to the JIRA web interface follow any given issue. The result is "siloed
development" where only people with JIRA accounts participate, most people
only follow the issues specifically relevant to them, and only core devs
follow everything.
In contrast, if JIRA notifications are shunted onto another list (e.g.
issues@, or commits@), all important decisions will have to happen via email
on the dev list, the threshold for participation is lowered, and the
signal-to-noise ratio of the dev list is markedly better.
(FWIW, I once approache Infra about adapting the global templates for JIRA
notifications to make them more email-client friendly, but the way they are
set up means that customized templates would complicate JIRA upgrades.)
Marvin Humphrey
