+1 (non-binding) Thanks Jeremiah. This is moving us in the right direction.
On Wed, Aug 17, 2016 at 5:31 AM, Jeremiah D Jordan < jeremiah.jor...@gmail.com> wrote: > 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 > >
