While all of these things are true, it's irrelevant. The ASF has a clear policy on this (the "it didn't happen" policy). Discussions and decisions about the project must be done on the mailing lists. You may disagree with the policy (as many have before you) and feel free to take it up with the powers that be, but until that policy changes, it's what we have to adhere to. The reason they chose mailing lists (IIUC) is that they are somewhat of a "least common denominator."
I would suggest, instead of sending an email to the dev@ list saying "hey folks, go to JIRA and look at stuff", that we do the opposite. Let's have the discussion on the mailing lists and in JIRA, we would link to the email threads for any supporting documentation about the ticket. On Mon, Aug 15, 2016 at 9:04 PM Eric Stevens <migh...@gmail.com> wrote: > There are a few strengths of discussion on the ticketing system over > mailing lists. Mailing lists were fundamentally designed in the 1970's and > early 1980's, and the state of the art from a user experience perspective > has barely advanced since then. > > * Mailing lists tend to end up with fragmented threads for large > discussions, subject changes, conversation restarts, topic forks, and > simple etiquette errors - all of which can make it very difficult to locate > the entire discussion related to a feature. There is no single source > that an interested party can study thoroughly to understand the entire > conversation, rather it's more of a scavenger hunt with no way to be > certain you've covered all the territory. 8844 for example would have > ended up being numerous parallel threads as people forked the conversation > to have side discussions or offer alternatives, there's no way such a > ticket would ever have simply been a single massive email thread with no > forks. > > * Mailing lists don't allow for selective subscription. If I find a ticket > interesting, I can watch the ticket and follow along. Conversely and more > importantly if I find it uninteresting I don't have to wade through that > discussion as it progresses. If I think I want to follow all tickets, that > should be possible too. Likewise if I want to watch tickets that involve > certain components, certain milestones, certain labels, or even certain > contributors, I can create a subscription for such, and get emails > accordingly. I can also subscribe to RSS feeds and add them to my news > reader if I prefer that approach better. A tremendous amount of control is > given to the user over what they want to see, and how they want to see it. > > * The concern that Chris voiced about having to open a web browser to > participate is actually not true unless Apache's Jira install is not well > configured. If you reply to an email notification from Jira it should > appear as a comment on the ticket. It shouldn't exclude anyone (even those > who want to participate but somehow can't be motivated to create an account > in the ticketing system, but who _could_ be bothered to figure out the > arcane mailing list subscription incantation). > > * Permalinking conversations is an important capability. It's possible > with a mailing list, but it's nontrivial, when you want to create that > permalink, you must first locate the discussion in the nonprimary interface > (the online archives), which involves a lot more effort. Historically > we've also seen existing "permalinks" become invalidated with mailing list > archive software is switched or upgraded. This leads to the next point: > > * One of the simple but hugely valuable features of Jira is the short > memorable ticket numbers. Several people in this thread have mentioned > 8844. Those who care about that conversation know that ID by heart. And > in casual conversation if you want to bring someone's attention to an > issue, you can mention it by ID without having to try to remember what the > original thread subject was so the other participant can also hopefully > remember and maybe locate it later. Write the number down on a napkin and > you _will_ find the issue, and know it's the right one, and not some > similar but unrelated conversation. > > * Ticketing systems can maintain a summarized version of the conversation > in the ticket's description as a shortcut for those who want to know the > current state without having to read potentially months of back history to > catch up (the event log model). Event logs are a great way to capture > changing state, but they're horridly inefficient if your only option is to > start from 0 and replay the entire log, particularly when a lot of the > contributors are as long winded as I am. > > On Mon, Aug 15, 2016 at 5:29 PM Jonathan Ellis <jbel...@gmail.com> wrote: > > > ... but it's important to note that if we take this approach, we need to > be > > careful not to just summarize the conclusion of the discussion, but also > > approaches that were examined and found to be unviable, and why. > Otherwise > > people looking at the ticket will have to cross reference back to a much > > harder-to-follow discussion on the list archives. > > > > On Mon, Aug 15, 2016 at 6:26 PM, Jonathan Ellis <jbel...@gmail.com> > wrote: > > > > > On Mon, Aug 15, 2016 at 6:18 PM, Josh McKenzie <jmcken...@apache.org> > > > wrote: > > > > > >> 2: 8844 would have been a great candidate for being discussed on the > > >> mailing list rather than on JIRA. While I made it a point to > front-load > > >> design, we still ran into some unforeseen consequences from the design > > >> that > > >> might have been prevented by more wide-spread discussion. In my > opinion, > > >> it > > >> would have made sense to have the initial discussion(s) take place on > > the > > >> mailing list until a design had settled out, worked that design and > the > > >> day-to-day back and forth on JIRA, then bringing it back to the > mailing > > >> list when we ran into the problems with the design. > > >> > > > > > > This is a good example of what I had in mind here. > > > > > > -- > > > Jonathan Ellis > > > Project Chair, Apache Cassandra > > > co-founder, http://www.datastax.com > > > @spyced > > > > > > > > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder, http://www.datastax.com > > @spyced > > >
