Back to the topic at hand. First, let us establish that all of this stuff will be happening “on the mailing lists”, all JIRA updates are sent to commits@ with the reply-to set to dev@, so “JIRA” is still “on the list".
Now we just need to decide how we would like to best make use of these lists. I propose that we keep dev@ fairly low volume so that people don’t feel the need to filter it out of their inbox, and thus possibly miss important discussions. If someone cares so much about the name of the list where stuff happens, then I propose we make dev-announce@ and if that happens we can replace commits@ with dev@ below and dev@ with dev-announce@ and start forwarding some JIRA stuff to dev@… In order to keep dev@ low volume (but higher than it currently is, as it has mostly been “no volume” lately) I propose the following: Someone has a major feature that they would like to discuss. (Again this is just for major features, not every day bug fixes etc) 1. Make a JIRA for the thing you want to discuss (aka post the thing to commits@) 2. Post link to JIRA with a short description to dev@ 3. Have a discussion on the JIRA (aka commits@) about the new thing. 4. If there is some major change/question on the JIRA that people feel needs some extra discussion/involvement email dev@ with question and link back to the JIRA 5. Have more discussions on the JIRA (aka commits@) about the new thing. 6. If something else comes up go back too step 4. 7. During this process of decision making keep the “Title” and “Description” fields of the JIRA (aka commits@) up to date with what is actually happening in the ticket. 8. Once things settle down make sub tasks or follow on tickets for actually implementing things linked to the initial ticket. That would keep the dev@ list informed of what is going on in new feature proposals, and it will keep discussions on JIRA tickets where they are easily referenced and kept in one place, so it is easy to get to, and easy for. -Jeremiah > On Aug 15, 2016, at 9:22 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > > A long time ago, I was a proponent of keeping most development discussions > on Jira, where tickets can be self contained and the threadless nature > helps keep discussions from getting sidetracked. > > But Cassandra was a lot smaller then, and as we've grown it has become > necessary to separate out the signal (discussions of new features and major > changes) from the noise of routine bug reports. > > I propose that we take advantage of the dev list to perform that > separation. Major new features and architectural improvements should be > discussed first here, then when consensus on design is achieved, moved to > Jira for implementation and review. > > I think this will also help with the problem when the initial idea proves > to be unworkable and gets revised substantially later after much > discussion. It can be difficult to figure out what the conclusion was, as > review comments start to pile up afterwards. Having that discussion on the > list, and summarizing on Jira, would mitigate this. > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced
