Unfortunately when rulebooks are consulted to shape this kind of discussion, their ambiguity begins to show. What does it mean for something "to happen" on a mailing list? It must be a loose interpretation, because clearly many things do not "happen" on the mailing list, such as all of the code development and commits to the codebase, as well as an infinitude of micro decisions made by the implementor. These things clearly happen though.
It's also worth pointing out the *prior* rule, which presumably takes precedence: "Let they that do the work make the decisions." By this rule perhaps we shouldn't even discuss on the mailing list as we may be encroaching on their right to decide. Now, this is all further clouded by the fact that we're quoting the Newbie FAQs. In other places different snappy phrases are used: "Everything -- but *everything*-- inside the Apache world occurs *or is reflected* in email" (emphasis mine) "If it isn't in my email, it didn't happen." These are from the more official sounding "committer guide" and both indicate commits@ receiving all JIRA comments means those comments "happen" - although I don't know who the speaker in the second quote is, so perhaps it has to end up in a very specific inbox. Anyway, the point is: *let's not get into legalistic discussions when we don't even have legalese.* These rules are referred to as "mottos," "codes," "FAQs" - they are guidelines, so should be interpreted with generosity. But even if they are not, it seems the suggestion of noncompliance is a stretch. So let's just try to agree what the best policy is. On 16 August 2016 at 11:44, James Carman <ja...@carmanconsulting.com> wrote: > 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 > > > > > >
