> On Mar 26, 2015, at 8:54 AM, Marvin Humphrey <mar...@rectangular.com> wrote: > > 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.)
As someone who has to work under the constant drone of CI machinery, I appreciate the community chatter of this list. I prefer not to see Jiras on this list. With that said, it would be *super awesome* if we had a weekly report that container stats on JIra issues and maybe a top ten Jira issues that were voted on but not assigned. Regards, Alan
