+1 I would like this.
On 2016-08-16 13:31, Jeremiah D Jordan 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
