Re: A proposal to move away from Jira-centric development

[Mick Semb Wever]

On 17 August 2016 at 03:47, Benedict Elliott Smith 
wrote:

> What this project really needs, and the board is chomping at the bit about,
> is diversity.  The fact is, right now DataStax does 95% of the substantive
> development on the project, and so they make all the decisions.  As such,
> their internal community outweighs the Apache community.  I will emphasise
> clearly for my ex-colleagues, I'm not making any value judgement about
> this, just clarifying the crux of the discussion that everyone seems to be
> dancing around.
>


Thanks for that Benedict, it was well written and is an important issue.
And straight off the bat I interpret it without any negative implications
to DataStax.

Of course it is going to be difficult with so many of the community are
employees within one company.

Back to the issue I've always been a big fan of how discussions were kept
in JIRA, and always seen it as a significant addition to the Apache Way
(specifically CS50 in the Maturity Model). But it seems the times have
moved on and one specific "dev" mailing list is now being seen as
under-utilised.

http://community.apache.org/apache-way/apache-project-
maturity-model.html#consensus-building

There has been a number of tickets and decisions made along the way that
could have come out (early) onto the dev ML. For example sometimes
ideas/tickets come out appearing that they have already been
rubber-stamped. If outsiders can't find that early discussion around ideas
they can too easily presume the sinister, that DataStax is running the show
behind the scenes. That's no good for DataStax and it's no good for the
Cassandra. Personally I'm tired of having to defend both DataStax and the
Cassandra community when it boils down to silly misunderstandings like
this.

Efforts like those numbered by Jeremiah would be greatly appreciated.
It makes sense because if all we do is simply shuffling and duplicating
information around between two persistent transparent searchable channels
then we don't achieve much beyond breaking context and threads. When I read
CS50 it's not about the dev ML being the Apache Way while discussions on
tickets are not. It's that the community needs to identify all the really
important decisions early on and: deciding that the dev ML is the
'project's main communications channel'; raise them there. Just generally
increasing traffic to the dev ML is going to be a distraction to that goal.

~mck

Re: A proposal to move away from Jira-centric development

[Jeremy Hanna]

I think a separate mailing list for just ticket creation would be nice as well. 
 I think that’s what many of us filter down the commits@ list to.  That doesn’t 
have to happen in place of the proposed change but would make it easier for 
people to follow new issue creation.  From there I go to and follow/comment 
on/etc. issues I’m interested in.

> On Aug 16, 2016, at 4:06 PM, Eric Evans  wrote:
> 
> On Mon, Aug 15, 2016 at 9:22 AM, Jonathan Ellis  wrote:
> 
> [ ... ]
> 
>> 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.
> 
> TL;DR +1
> 
> I think there are actually a couple of related, but disjoint issues here.
> 
> IMO, a JIRA should be the source of truth for an issue, a way to track
> any on-going efforts, and a historical account after-the-fact.
> Regardless of where you think discussions should take place, I would
> argue there is room for improvement here; Many of our JIRAs (I would
> argue the most interesting ones!), are very difficult to make use of
> for either of these cases (current status, or after-the-fact).  Some
> curation (as someone else pointed out in this thread), could go a long
> way.  Retitling and/or revising the description as the scope of a
> ticket evolves, or posting a summary or current status in the
> description body would be ways for people who are up to speed on an
> issue, to spend a few minutes making it valuable to others.  So would
> summarizing discussions that take place elsewhere.
> 
> The other issue is discoverability and/or inclusivity.  If the only
> way to keep abreast of what is happening is to follow the fire-hose of
> all JIRA updates, then contribution is going to be limited to those
> with the bandwidth.  If you work on Cassandra full-time, this probably
> doesn't seem like a big deal, but if your time is limited, then it can
> create quite a barrier (and I've been on both sides of this with
> Cassandra).  So moving serious discussions to the mailing list is also
> a sort of curation, since it creates a venue free of all the
> minutiae/noise.
> 
> My personal opinion is also that it's far easier to manage a given
> volume with email, and that the discussions are easier to follow (the
> interface is better at representing the ontology, for example), but
> from what I can gather, not everyone agrees so YMMV.
> 
> Cheers,
> 
> -- 
> Eric Evans
> john.eric.ev...@gmail.com

Re: A proposal to move away from Jira-centric development

[Eric Evans]

On Mon, Aug 15, 2016 at 9:22 AM, Jonathan Ellis  wrote:

[ ... ]

> 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.

TL;DR +1

I think there are actually a couple of related, but disjoint issues here.

IMO, a JIRA should be the source of truth for an issue, a way to track
any on-going efforts, and a historical account after-the-fact.
Regardless of where you think discussions should take place, I would
argue there is room for improvement here; Many of our JIRAs (I would
argue the most interesting ones!), are very difficult to make use of
for either of these cases (current status, or after-the-fact).  Some
curation (as someone else pointed out in this thread), could go a long
way.  Retitling and/or revising the description as the scope of a
ticket evolves, or posting a summary or current status in the
description body would be ways for people who are up to speed on an
issue, to spend a few minutes making it valuable to others.  So would
summarizing discussions that take place elsewhere.

The other issue is discoverability and/or inclusivity.  If the only
way to keep abreast of what is happening is to follow the fire-hose of
all JIRA updates, then contribution is going to be limited to those
with the bandwidth.  If you work on Cassandra full-time, this probably
doesn't seem like a big deal, but if your time is limited, then it can
create quite a barrier (and I've been on both sides of this with
Cassandra).  So moving serious discussions to the mailing list is also
a sort of curation, since it creates a venue free of all the
minutiae/noise.

My personal opinion is also that it's far easier to manage a given
volume with email, and that the discussions are easier to follow (the
interface is better at representing the ontology, for example), but
from what I can gather, not everyone agrees so YMMV.

Cheers,

-- 
Eric Evans
john.eric.ev...@gmail.com

Re: A proposal to move away from Jira-centric development

[Eric Evans]

On Tue, Aug 16, 2016 at 3:09 PM, Benedict Elliott Smith
 wrote:
> This is a great example of email's inadequacies, as this innocuous (to me) 
> little textual
> act resulted instead in *different* quagmire, while the first potential 
> quagmire is still in
> play!
>
> Email is a minefield, and textual interactions can be exhausting.  So
> people tap out without fully expressing themselves, to retain their life
> and sanity.

My apologies, it wasn't my intention to drag you into a quagmire.  You
had indicated a reluctance to discuss a particular topic, and
attributed it to email.  Personally, I think that this is a) a
conversation worth having, and b) one that others have been reluctant
to engage in.  My intention was to understand the reluctance, and if
possible, encourage you (and others) to try.

Cheers,

-- 
Eric Evans
john.eric.ev...@gmail.com

Re: A proposal to move away from Jira-centric development

[Benedict Elliott Smith]

Like many difficult problems, it is easier to point them out than to
suggest improvements.  Anyway, I wasn't proposing we change the mechanisms
of communication, just excusing my simplification of (my view of) the
problem to avoid ending up in a quagmire on that topic.  This is a great
example of email's inadequacies, as this innocuous (to me) little textual
act resulted instead in *different* quagmire, while the first potential
quagmire is still in play!

Email is a minefield, and textual interactions can be exhausting.  So
people tap out without fully expressing themselves, to retain their life
and sanity.



On 16 August 2016 at 20:49, Eric Evans  wrote:

> On Tue, Aug 16, 2016 at 2:38 PM, Benedict Elliott Smith
>  wrote:
> > I think all complex, nuanced and especially emotive topics are
> challenging
> > to discuss over textual media, due to things like the attention span of
> > your readers, the difficulties in structuring your text, and especially
> the
> > hoops that have to be jumped through to minimise the potential for
> > misinterpretation, as well as correcting the inevitable
> misinterpretations
> > that happen anyway.
>
> Fair enough, I suppose, but some of these things are also difficult
> face to face.  Most people who collaborate over the Internet with
> people from different backgrounds in different timezones, etc, learn
> to adjust accordingly.  And, the asynchronicity of email is often a
> feature in this regard, giving people the opportunity to more
> carefully consider what they've read, and to be more deliberate in
> their response.
>
> I guess what I should have asked is, if not email, then how?
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>

Re: A proposal to move away from Jira-centric development

[Eric Evans]

On Tue, Aug 16, 2016 at 2:38 PM, Benedict Elliott Smith
 wrote:
> I think all complex, nuanced and especially emotive topics are challenging
> to discuss over textual media, due to things like the attention span of
> your readers, the difficulties in structuring your text, and especially the
> hoops that have to be jumped through to minimise the potential for
> misinterpretation, as well as correcting the inevitable misinterpretations
> that happen anyway.

Fair enough, I suppose, but some of these things are also difficult
face to face.  Most people who collaborate over the Internet with
people from different backgrounds in different timezones, etc, learn
to adjust accordingly.  And, the asynchronicity of email is often a
feature in this regard, giving people the opportunity to more
carefully consider what they've read, and to be more deliberate in
their response.

I guess what I should have asked is, if not email, then how?


-- 
Eric Evans
john.eric.ev...@gmail.com

Re: A proposal to move away from Jira-centric development

[Benedict Elliott Smith]

I think all complex, nuanced and especially emotive topics are challenging
to discuss over textual media, due to things like the attention span of
your readers, the difficulties in structuring your text, and especially the
hoops that have to be jumped through to minimise the potential for
misinterpretation, as well as correcting the inevitable misinterpretations
that happen anyway.  But that's a major side track we shouldn't deviate
down.

On 16 August 2016 at 20:28, Eric Evans  wrote:

> On Tue, Aug 16, 2016 at 1:34 PM, Benedict Elliott Smith
>  wrote:
> > This topic is complex, and fully exploring all of the detail would be
> onerous over email.
>
> Out of curiosity, why; What makes this topic so difficult to discuss over
> email?
>
> > DataStax, in my opinion, consciously tries to be a good citizen.
> However there
> > are emergent properties of a system with this imbalance that are not
> conscious,
> > and are suboptimal, and it is not unreasonable for the Apache apparatus
> to
> > try to "rectify" the imbalance.  I personally support that *in
> principle*, but I think
> > they're not going about it brilliantly right now.  I also doubt the
> success of any
> > such endeavour, given how difficult the problem is.
>
> This.  A good first step in my opinion would be for us all to simply
> recognize this.  An imbalance of this nature is not good for the
> project, full stop.  No malice needs to be attributed, no effigies
> burned, and it shouldn't be viewed as squaring up against those we
> know and respect who are employed by Datastax.
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>

Re: A proposal to move away from Jira-centric development

[Eric Evans]

On Tue, Aug 16, 2016 at 1:34 PM, Benedict Elliott Smith
 wrote:
> This topic is complex, and fully exploring all of the detail would be onerous 
> over email.

Out of curiosity, why; What makes this topic so difficult to discuss over email?

> DataStax, in my opinion, consciously tries to be a good citizen.  However 
> there
> are emergent properties of a system with this imbalance that are not 
> conscious,
> and are suboptimal, and it is not unreasonable for the Apache apparatus to
> try to "rectify" the imbalance.  I personally support that *in principle*, 
> but I think
> they're not going about it brilliantly right now.  I also doubt the success 
> of any
> such endeavour, given how difficult the problem is.

This.  A good first step in my opinion would be for us all to simply
recognize this.  An imbalance of this nature is not good for the
project, full stop.  No malice needs to be attributed, no effigies
burned, and it shouldn't be viewed as squaring up against those we
know and respect who are employed by Datastax.


-- 
Eric Evans
john.eric.ev...@gmail.com

Re: A proposal to move away from Jira-centric development

[Nate McCall]

+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  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
>
>

Re: A proposal to move away from Jira-centric development

[Benedict Elliott Smith]

This was very much not my intention to imply.  I thought I had crafted the
email carefully to not imply that at all.  This topic is complex, and fully
exploring all of the detail would be onerous over email.  DataStax, in my
opinion, consciously tries to be a good citizen.  However there are
emergent properties of a system with this imbalance that are not conscious,
and are suboptimal, and it is not unreasonable for the Apache apparatus to
try to "rectify" the imbalance.  I personally support that *in principle*,
but I think they're not going about it brilliantly right now.  I also doubt
the success of any such endeavour, given how difficult the problem is.

I do, however, think the project could improve how welcoming it is.  Both
in the areas Jon mentions, but also in how much effort is put into
mentoring newcomers and responding to technical questions.  The project is
far from *unwelcoming, *but mentoring is (very) costly, and when success at
your dayjob is measured in the code you contribute, this clearly takes
priority.

I don't know how to change that - again, as far as conscious actions are
concerned, I have personally witnessed DataStax try to put more effort into
this, as well as trying to drum up new external contributors through
bootcamps.  But these efforts have had limited success.

On 16 August 2016 at 19:04, Dave Brosius  wrote:

> While i agree with this generally, it's misleading.
>
> It comes across like Datastax is dictating and excluding others from
> participating, or perhaps discouraging others or whatever.
>
> The truth is, whenever someone comes along who is independent, and
> interested in developing Apache Cassandra, they are welcomed, and do
> participate, and do develop, and soon after become Datastax employees.
> Not always of course, but a common pattern. It only makes sense for
> Datastax to hire people who are interested in and capable of developing
> Apache Cassandra. But the truth is a whole lot less sinister than the
> inference.
>
> --dave
> [not associated with Datastax]
>
>
>
> On 2016-08-16 13:47, Benedict Elliott Smith wrote:
>
>> This is a much more useful focusing of the discussion, in my opinion.  It
>> seemed to me that city hall was focusing on a very narrow definition of
>> project health.
>>
>> I would be the first to say the project need to improve here, but doing so
>> will be challenging;  I'm not sure anyone really knows how to go about it.
>> Which is why we end up in these local minima of discussions about the
>> minutiae of JIRA replication.
>>
>> What this project really needs, and the board is chomping at the bit
>> about,
>> is diversity.  The fact is, right now DataStax does 95% of the substantive
>> development on the project, and so they make all the decisions.  As such,
>> their internal community outweighs the Apache community.  I will emphasise
>> clearly for my ex-colleagues, I'm not making any value judgement about
>> this, just clarifying the crux of the discussion that everyone seems to be
>> dancing around.
>>
>> The question is, what can be done about it?  The project needs a lot of
>> new
>> highly productive and independent contributors who are capable of
>> meaningfully shaping project direction.  The problem is we don't know how
>> to achieve that.
>>
>>
>>
>> On 16 August 2016 at 17:24, Dennis E. Hamilton 
>> wrote:
>>
>>
>>>
>>> > -Original Message-
>>> > From: Eric Stevens [mailto:migh...@gmail.com]
>>> > Sent: Tuesday, August 16, 2016 06:10
>>> > To: dev@cassandra.apache.org
>>> > Subject: Re: A proposal to move away from Jira-centric development
>>> >
>>> > I agree with Benedict that we really shouldn't be getting into a
>>> > legalese
>>> > debate on this subject, however "it didn't happen" has been brought up
>>> > as a
>>> > hammer in this conversation multiple times, and I think it's important
>>> > that
>>> > we put it to rest.  It's pretty clear cut that projects are free to
>>> > disregard this advice.  "It didn't happen" is a motto, not a rule.
>>> [orcmid]
>>>
>>> <http://community.apache.org/apache-way/apache-project-matur
>>> ity-model.html
>>> >
>>>
>>> Please read them all, but especially the sections on Community, Consensus
>>> Building, and Independence.
>>>
>>> Apache projects are expected to govern themselves, PMCs are responsible
>>> for it, and PMC Chairs (officers of the foundation) are accountable to
&

Re: A proposal to move away from Jira-centric development

[Jonathan Haddad]

I don't know about everyone else, but a big deterrent in contributing code
to Cassandra for me (over the last 4 years or so) is the massive amount of
ramp up that needs to happen in order to get started working on something
meaningful.  This comes in a variety of forms - understanding how test
failures aren't actually failures (being corrected now), lack of comments
(for example:
https://github.com/PaytmLabs/cassandra/blob/master/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java),
out of date wiki (now semi retired but still a source of misinformation),
and class names that don't make sense.  Historically there has been a
massive amount of tribal knowledge required to contribute in a significant
way.  Going through JIRA history and asking people who wrote the feature is
the only way to find out what is supposed to be going on.  Let's not forget
the fact that it's a distributed database, so add to all the above issues
the fact that getting this thing right at all is a miraculous achievement.
In order to get more people contributing to the project there needs to be a
significant effort in making it more approachable.

I suspect that as the project continues to move faster, it'll become ever
harder for new contributors to join unless they are paid to work on
Cassandra full time.  Very few people are deploying Tick Tock releases on
purpose - 1 bug fix release doesn't exactly scream reassurance, sorry - so
the folks that are going to scratch their own itch by fixing bugs and
eventually contributing features they need is likely going to drop over
time.  This leaves full time paid positions such as those employed by
DataStax as the logical place to go if you are interested in working on
Cassandra.


On Tue, Aug 16, 2016 at 10:47 AM Benedict Elliott Smith 
wrote:

> This is a much more useful focusing of the discussion, in my opinion.  It
> seemed to me that city hall was focusing on a very narrow definition of
> project health.
>
> I would be the first to say the project need to improve here, but doing so
> will be challenging;  I'm not sure anyone really knows how to go about it.
> Which is why we end up in these local minima of discussions about the
> minutiae of JIRA replication.
>
> What this project really needs, and the board is chomping at the bit about,
> is diversity.  The fact is, right now DataStax does 95% of the substantive
> development on the project, and so they make all the decisions.  As such,
> their internal community outweighs the Apache community.  I will emphasise
> clearly for my ex-colleagues, I'm not making any value judgement about
> this, just clarifying the crux of the discussion that everyone seems to be
> dancing around.
>
> The question is, what can be done about it?  The project needs a lot of new
> highly productive and independent contributors who are capable of
> meaningfully shaping project direction.  The problem is we don't know how
> to achieve that.
>
>
>
> On 16 August 2016 at 17:24, Dennis E. Hamilton 
> wrote:
>
> >
> >
> > > -Original Message-----
> > > From: Eric Stevens [mailto:migh...@gmail.com]
> > > Sent: Tuesday, August 16, 2016 06:10
> > > To: dev@cassandra.apache.org
> > > Subject: Re: A proposal to move away from Jira-centric development
> > >
> > > I agree with Benedict that we really shouldn't be getting into a
> > > legalese
> > > debate on this subject, however "it didn't happen" has been brought up
> > > as a
> > > hammer in this conversation multiple times, and I think it's important
> > > that
> > > we put it to rest.  It's pretty clear cut that projects are free to
> > > disregard this advice.  "It didn't happen" is a motto, not a rule.
> > [orcmid]
> >
> > <
> http://community.apache.org/apache-way/apache-project-maturity-model.html
> > >
> >
> > Please read them all, but especially the sections on Community, Consensus
> > Building, and Independence.
> >
> > Apache projects are expected to govern themselves, PMCs are responsible
> > for it, and PMC Chairs (officers of the foundation) are accountable to
> the
> > Board on how the project is striving toward maturity.
> >
> > On occasion, deviations are so notable that there is objection.  It is
> not
> > that folks run around policing the projects.  But there are occasions
> where
> > there are concerns that a project has gone astray.
> >
> > One maturity factor that might not be emphasized enough is
> > Sustainability.  It is about the transparency of project conduct, the
> > inclusiveness of operation and visibility, and the ways 

Re: A proposal to move away from Jira-centric development

[Dave Brosius]

While i agree with this generally, it's misleading.

It comes across like Datastax is dictating and excluding others from 
participating, or perhaps discouraging others or whatever.


The truth is, whenever someone comes along who is independent, and 
interested in developing Apache Cassandra, they are welcomed, and do 
participate, and do develop, and soon after become Datastax 
employees. Not always of course, but a common pattern. It only makes 
sense for Datastax to hire people who are interested in and capable of 
developing Apache Cassandra. But the truth is a whole lot less sinister 
than the inference.


--dave
[not associated with Datastax]


On 2016-08-16 13:47, Benedict Elliott Smith wrote:
This is a much more useful focusing of the discussion, in my opinion.  
It

seemed to me that city hall was focusing on a very narrow definition of
project health.

I would be the first to say the project need to improve here, but doing 
so
will be challenging;  I'm not sure anyone really knows how to go about 
it.

Which is why we end up in these local minima of discussions about the
minutiae of JIRA replication.

What this project really needs, and the board is chomping at the bit 
about,
is diversity.  The fact is, right now DataStax does 95% of the 
substantive
development on the project, and so they make all the decisions.  As 
such,
their internal community outweighs the Apache community.  I will 
emphasise

clearly for my ex-colleagues, I'm not making any value judgement about
this, just clarifying the crux of the discussion that everyone seems to 
be

dancing around.

The question is, what can be done about it?  The project needs a lot of 
new

highly productive and independent contributors who are capable of
meaningfully shaping project direction.  The problem is we don't know 
how

to achieve that.



On 16 August 2016 at 17:24, Dennis E. Hamilton 


wrote:




> -Original Message-
> From: Eric Stevens [mailto:migh...@gmail.com]
> Sent: Tuesday, August 16, 2016 06:10
> To: dev@cassandra.apache.org
> Subject: Re: A proposal to move away from Jira-centric development
>
> I agree with Benedict that we really shouldn't be getting into a
> legalese
> debate on this subject, however "it didn't happen" has been brought up
> as a
> hammer in this conversation multiple times, and I think it's important
> that
> we put it to rest.  It's pretty clear cut that projects are free to
> disregard this advice.  "It didn't happen" is a motto, not a rule.
[orcmid]

<http://community.apache.org/apache-way/apache-project-maturity-model.html
>

Please read them all, but especially the sections on Community, 
Consensus

Building, and Independence.

Apache projects are expected to govern themselves, PMCs are 
responsible
for it, and PMC Chairs (officers of the foundation) are accountable to 
the

Board on how the project is striving toward maturity.

On occasion, deviations are so notable that there is objection.  It is 
not
that folks run around policing the projects.  But there are occasions 
where

there are concerns that a project has gone astray.

One maturity factor that might not be emphasized enough is
Sustainability.  It is about the transparency of project conduct, the
inclusiveness of operation and visibility, and the ways that growth 
and
turnover are accommodated.  Since we are looking at mottos, "community 
over

code" comes to mind.

Project freedom is a bit like the freedom to drive at 100mph on an
arterial highway.  Occassionally, the infraction becomes worthy of
attention and even a road block and spike strips.

While individual preferences are being discussed here, and I agree it 
is
more pertinent than top-posting versus bottom-posting, what is lacking 
is a
broad discussion on community.  Not incumbents and the 
karma-privileged,

but the overall community and how one sustains a thriving project that
strives for maturity.

Folks who are concerned about managing the mail stream and choosing 
what
matters to them might want to discuss ways of operating lists in 
support of
those concerns.  There are positions here and not enough questions 
about
what might be workable inside of the practices and policies that are 
the

waters Apache projects swim in.

 - Dennis

>
> Per ASF newbie FAQ referenced by someone else earlier [1]:
>
> > The section on ASF Mottos is especially useful as a reminder of the
> way
> things are in most ASF projects. This section includes such gems as:
> > * Put community before code.
> > * Let they that do the work make the decisions.
> > * If it didn't happen on a mailing list, it didn't happen.
> > * Don't feed the trolls.
>
> This is presented as a general guideline and not a hard rule, and as
> Benedict points out even this is preceded by a guideline suggesting that
> dev

Re: A proposal to move away from Jira-centric development

[Benedict Elliott Smith]

This is a much more useful focusing of the discussion, in my opinion.  It
seemed to me that city hall was focusing on a very narrow definition of
project health.

I would be the first to say the project need to improve here, but doing so
will be challenging;  I'm not sure anyone really knows how to go about it.
Which is why we end up in these local minima of discussions about the
minutiae of JIRA replication.

What this project really needs, and the board is chomping at the bit about,
is diversity.  The fact is, right now DataStax does 95% of the substantive
development on the project, and so they make all the decisions.  As such,
their internal community outweighs the Apache community.  I will emphasise
clearly for my ex-colleagues, I'm not making any value judgement about
this, just clarifying the crux of the discussion that everyone seems to be
dancing around.

The question is, what can be done about it?  The project needs a lot of new
highly productive and independent contributors who are capable of
meaningfully shaping project direction.  The problem is we don't know how
to achieve that.



On 16 August 2016 at 17:24, Dennis E. Hamilton 
wrote:

>
>
> > -Original Message-
> > From: Eric Stevens [mailto:migh...@gmail.com]
> > Sent: Tuesday, August 16, 2016 06:10
> > To: dev@cassandra.apache.org
> > Subject: Re: A proposal to move away from Jira-centric development
> >
> > I agree with Benedict that we really shouldn't be getting into a
> > legalese
> > debate on this subject, however "it didn't happen" has been brought up
> > as a
> > hammer in this conversation multiple times, and I think it's important
> > that
> > we put it to rest.  It's pretty clear cut that projects are free to
> > disregard this advice.  "It didn't happen" is a motto, not a rule.
> [orcmid]
>
> <http://community.apache.org/apache-way/apache-project-maturity-model.html
> >
>
> Please read them all, but especially the sections on Community, Consensus
> Building, and Independence.
>
> Apache projects are expected to govern themselves, PMCs are responsible
> for it, and PMC Chairs (officers of the foundation) are accountable to the
> Board on how the project is striving toward maturity.
>
> On occasion, deviations are so notable that there is objection.  It is not
> that folks run around policing the projects.  But there are occasions where
> there are concerns that a project has gone astray.
>
> One maturity factor that might not be emphasized enough is
> Sustainability.  It is about the transparency of project conduct, the
> inclusiveness of operation and visibility, and the ways that growth and
> turnover are accommodated.  Since we are looking at mottos, "community over
> code" comes to mind.
>
> Project freedom is a bit like the freedom to drive at 100mph on an
> arterial highway.  Occassionally, the infraction becomes worthy of
> attention and even a road block and spike strips.
>
> While individual preferences are being discussed here, and I agree it is
> more pertinent than top-posting versus bottom-posting, what is lacking is a
> broad discussion on community.  Not incumbents and the karma-privileged,
> but the overall community and how one sustains a thriving project that
> strives for maturity.
>
> Folks who are concerned about managing the mail stream and choosing what
> matters to them might want to discuss ways of operating lists in support of
> those concerns.  There are positions here and not enough questions about
> what might be workable inside of the practices and policies that are the
> waters Apache projects swim in.
>
>  - Dennis
>
> >
> > Per ASF newbie FAQ referenced by someone else earlier [1]:
> >
> > > The section on ASF Mottos is especially useful as a reminder of the
> > way
> > things are in most ASF projects. This section includes such gems as:
> > > * Put community before code.
> > > * Let they that do the work make the decisions.
> > > * If it didn't happen on a mailing list, it didn't happen.
> > > * Don't feed the trolls.
> >
> > This is presented as a general guideline and not a hard rule, and as
> > Benedict points out even this is preceded by a guideline suggesting that
> > developers are free to seek alternatives.
> [orcmid]
>
> The alternatives must fit within the overall principles, however.  Not
> deviate from or weaken them.  This is not an opening for arbitrary conduct.
>
> If a major exception is required, it is up to the project to deliberate on
> the matter, agree on the desired exception and its justification, and take
> it to an appropriate venue for rati

Re: A proposal to move away from Jira-centric development

[Dave Brosius]

+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  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

Re: A proposal to move away from Jira-centric development

[Jeremiah D Jordan]

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  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

RE: A proposal to move away from Jira-centric development

[Dennis E. Hamilton]

> -Original Message-
> From: Eric Stevens [mailto:migh...@gmail.com]
> Sent: Tuesday, August 16, 2016 06:10
> To: dev@cassandra.apache.org
> Subject: Re: A proposal to move away from Jira-centric development
> 
> I agree with Benedict that we really shouldn't be getting into a
> legalese
> debate on this subject, however "it didn't happen" has been brought up
> as a
> hammer in this conversation multiple times, and I think it's important
> that
> we put it to rest.  It's pretty clear cut that projects are free to
> disregard this advice.  "It didn't happen" is a motto, not a rule.
[orcmid] 

<http://community.apache.org/apache-way/apache-project-maturity-model.html>

Please read them all, but especially the sections on Community, Consensus 
Building, and Independence.

Apache projects are expected to govern themselves, PMCs are responsible for it, 
and PMC Chairs (officers of the foundation) are accountable to the Board on how 
the project is striving toward maturity.  

On occasion, deviations are so notable that there is objection.  It is not that 
folks run around policing the projects.  But there are occasions where there 
are concerns that a project has gone astray.  

One maturity factor that might not be emphasized enough is Sustainability.  It 
is about the transparency of project conduct, the inclusiveness of operation 
and visibility, and the ways that growth and turnover are accommodated.  Since 
we are looking at mottos, "community over code" comes to mind.  

Project freedom is a bit like the freedom to drive at 100mph on an arterial 
highway.  Occassionally, the infraction becomes worthy of attention and even a 
road block and spike strips.

While individual preferences are being discussed here, and I agree it is more 
pertinent than top-posting versus bottom-posting, what is lacking is a broad 
discussion on community.  Not incumbents and the karma-privileged, but the 
overall community and how one sustains a thriving project that strives for 
maturity.

Folks who are concerned about managing the mail stream and choosing what 
matters to them might want to discuss ways of operating lists in support of 
those concerns.  There are positions here and not enough questions about what 
might be workable inside of the practices and policies that are the waters 
Apache projects swim in.

 - Dennis
 
> 
> Per ASF newbie FAQ referenced by someone else earlier [1]:
> 
> > The section on ASF Mottos is especially useful as a reminder of the
> way
> things are in most ASF projects. This section includes such gems as:
> > * Put community before code.
> > * Let they that do the work make the decisions.
> > * If it didn't happen on a mailing list, it didn't happen.
> > * Don't feed the trolls.
> 
> This is presented as a general guideline and not a hard rule, and as
> Benedict points out even this is preceded by a guideline suggesting that
> developers are free to seek alternatives.
[orcmid] 

The alternatives must fit within the overall principles, however.  Not deviate 
from or weaken them.  This is not an opening for arbitrary conduct.

If a major exception is required, it is up to the project to deliberate on the 
matter, agree on the desired exception and its justification, and take it to an 
appropriate venue for ratification.  

(It is useful to keep in mind that exceptions are not precedents for others to 
cherry-pick.)

It is also the case that the PMC and, indeed the Chair (although consensus is 
always better), can set policies for the project.  They must be explicit and 
documented and available to all.

It would be really great to stop fighting city hall and, instead, start an 
inquiry into how the principles behind those practices are to be accomplished 
in the project's way of operating.

> 
> Now since this is just a reference to the Incubator code of conduct's
> list
> of mottos (again, not ASF policy), which best source I could find [2],
> mirrors the newbie FAQ, but provides the additional insight that the
> objective of the motto is transparency.  The spirit of this motto is not
> meant to dictate a technology choice, but merely to indicate that
> discussions should happen in open spaces where all are able to
> participate.  The motto was authored in a time when "the lists" was the
> only real option.
> 
> Jira absolutely meets the design goal of that motto, if that's the
> direction the community chooses, and it's clear from both sources that
> individual communities (they that do the work) are free to find the path
> here that's best for them.
> 
> [1]
> https://community.apache.org/newbiefaq.html#NewbieFAQ-
> IsthereaCodeofConductforApacheprojects
> ?
> [2] *https://wiki.apache.org/incubator/CodeOfConduct#A

Re: A proposal to move away from Jira-centric development

[Eric Stevens]

I agree with Benedict that we really shouldn't be getting into a legalese
debate on this subject, however "it didn't happen" has been brought up as a
hammer in this conversation multiple times, and I think it's important that
we put it to rest.  It's pretty clear cut that projects are free to
disregard this advice.  "It didn't happen" is a motto, not a rule.

Per ASF newbie FAQ referenced by someone else earlier [1]:

> The section on ASF Mottos is especially useful as a reminder of the way
things are in most ASF projects. This section includes such gems as:
> * Put community before code.
> * Let they that do the work make the decisions.
> * If it didn't happen on a mailing list, it didn't happen.
> * Don't feed the trolls.

This is presented as a general guideline and not a hard rule, and as
Benedict points out even this is preceded by a guideline suggesting that
developers are free to seek alternatives.

Now since this is just a reference to the Incubator code of conduct's list
of mottos (again, not ASF policy), which best source I could find [2],
mirrors the newbie FAQ, but provides the additional insight that the
objective of the motto is transparency.  The spirit of this motto is not
meant to dictate a technology choice, but merely to indicate that
discussions should happen in open spaces where all are able to
participate.  The motto was authored in a time when "the lists" was the
only real option.

Jira absolutely meets the design goal of that motto, if that's the
direction the community chooses, and it's clear from both sources that
individual communities (they that do the work) are free to find the path
here that's best for them.

[1]
https://community.apache.org/newbiefaq.html#NewbieFAQ-IsthereaCodeofConductforApacheprojects
?
[2] *https://wiki.apache.org/incubator/CodeOfConduct#ASF_Mottos
*

On Tue, Aug 16, 2016 at 5:57 AM James Carman 
wrote:

> On Mon, Aug 15, 2016 at 10:23 AM Jonathan Ellis  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.
> >
> >
> +1!  I think it's important to point out here that nobody is proposing that
> folks have to send an email like:
>
> "I was thinking of naming my variable 'foo' here, what do you guys think?"
>
> However, discussions and decisions that have an impact on Cassandra and its
> direction/architecture (not an all-inclusive list here and we should use
> reason to decide) should happen on the mailing list.  The idea here is
> inclusiveness.  We want everyone in the community to have a chance to
> contribute to these discussions.
>

Re: A proposal to move away from Jira-centric development

[James Carman]

On Mon, Aug 15, 2016 at 10:23 AM Jonathan Ellis  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.
>
>
+1!  I think it's important to point out here that nobody is proposing that
folks have to send an email like:

"I was thinking of naming my variable 'foo' here, what do you guys think?"

However, discussions and decisions that have an impact on Cassandra and its
direction/architecture (not an all-inclusive list here and we should use
reason to decide) should happen on the mailing list.  The idea here is
inclusiveness.  We want everyone in the community to have a chance to
contribute to these discussions.

Re: A proposal to move away from Jira-centric development

[Benedict Elliott Smith]

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  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  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 

Re: A proposal to move away from Jira-centric development

[James Carman]

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  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  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 wil

Re: A proposal to move away from Jira-centric development

[Eric Stevens]

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  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  wrote:
>
> > On Mon, Aug 15, 2016 at 6:18 PM, Josh McKenzie 
> > 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, 

Re: A proposal to move away from Jira-centric development

[Jonathan Ellis]

... 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  wrote:

> On Mon, Aug 15, 2016 at 6:18 PM, Josh McKenzie 
> 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

Re: A proposal to move away from Jira-centric development

[Jonathan Ellis]

On Mon, Aug 15, 2016 at 6:18 PM, Josh McKenzie  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

Re: A proposal to move away from Jira-centric development

[Josh McKenzie]

2 thoughts:

1: I'd hate to see our daily test email getting lost in a flood of jira
ticket opening / commenting on trivial day-to-day work. I already have
email filters for those from the JIRA feed and, while I could also set up
filters on this list, that's an extra burden to participation for new
contributors in my opinion and doesn't add any value over the current
project workflow.

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.

I'm personally not in favor of having all discussion for tickets hit the
dev mailing list as we essentially already have a list for that, however I
do believe we should make better use of our dev list.

On Mon, Aug 15, 2016 at 6:09 PM, Nate McCall  wrote:

> > 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.
> >
>
> So the goal is to mitigate some of the (in most cases necessary) noise that
> bloated CASSANDRA-8844? (There are others, but this is a good example.)
>
>
> > 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.
> >
>
> In the case of CASSANDRA-8844, if Tupshin posted his summary here first,
> would this have streamlined some of the discussion? Again, if Josh had
> circled back around on the ML with some of his findings during
> implementation as opposed to Jira, would this be more clear to understand
> the ongoing development? (I'm not sure myself, just raising these for
> thinking about).
>
> There are some good points made on the concerns of traffic and
> fragmentation, so to refocus this discussion, we seem to have some general
> agreement on:
> 1. large contributions/design ideas would make sense to 'announce' on the
> ML (this will inherently inspire some level of discussion)
> 2. linking back to relevant ML announcements from Jira is a good practice
>
> I feel like starting here would be a good first step towards higher
> engagement on the ML w/o blowing up the traffic and potentially doing a bit
> of streamlining on our biggest issues.
>
> Thoughts?
>
> -Nate
>

Re: A proposal to move away from Jira-centric development

[Nate McCall]

> 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.
>

So the goal is to mitigate some of the (in most cases necessary) noise that
bloated CASSANDRA-8844? (There are others, but this is a good example.)


> 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.
>

In the case of CASSANDRA-8844, if Tupshin posted his summary here first,
would this have streamlined some of the discussion? Again, if Josh had
circled back around on the ML with some of his findings during
implementation as opposed to Jira, would this be more clear to understand
the ongoing development? (I'm not sure myself, just raising these for
thinking about).

There are some good points made on the concerns of traffic and
fragmentation, so to refocus this discussion, we seem to have some general
agreement on:
1. large contributions/design ideas would make sense to 'announce' on the
ML (this will inherently inspire some level of discussion)
2. linking back to relevant ML announcements from Jira is a good practice

I feel like starting here would be a good first step towards higher
engagement on the ML w/o blowing up the traffic and potentially doing a bit
of streamlining on our biggest issues.

Thoughts?

-Nate

Re: A proposal to move away from Jira-centric development

[Michael Kjellman]

+1

Sent from my iPhone

On Aug 15, 2016, at 6:48 PM, Brandon Williams 
mailto:dri...@gmail.com>> wrote:

So will I, if that happens, which has never happened in the last ~7 years.

On Mon, Aug 15, 2016 at 4:27 PM, Jeff Jirsa 
mailto:jeff.ji...@crowdstrike.com>>
wrote:


On 8/15/16, 2:15 PM, "Marvin Humphrey" 
mailto:mar...@apache.org>> wrote:

Julian Hyde, who made the proposal, is active in the Apache Incubator ...
  I propose that when a JIRA is created, we send an email to both dev@
and
  issues@. This will be an extra 40 emails per month on the dev list.
I am
  really cautious about increasing the number of messages on the dev
list,
  because I think high-volume lists discourage part-time contributors,
but I
  think this change is worthwhile. It will make people aware of
  conversations that are happening and if it helps to channel
conversations
  onto JIRA cases it could possibly even REDUCE the volume on the dev
list.


That's a useful example. However, that's a project with 30-40 issues per
month (1300 over its lifetime) - Cassandra is sitting at 244 in the past 30
days, 12000 over its lifetime.

I think a lot of us part-time contributors appreciate efforts to increase
visibility and certainly welcome growing the project by making it easier to
recruit and retain more contributors, but is the noise of 10 more new email
threads per day going to get into the "high volume lists discourage
part-time contributors" range Julian discussed?

I'm a part time contributor. If this list gets ~10 threads per day with
2-3 replies each, I'm going to have to start filtering it out of necessity
(because I can't keep up with that volume).

Re: A proposal to move away from Jira-centric development

[Brandon Williams]

So will I, if that happens, which has never happened in the last ~7 years.

On Mon, Aug 15, 2016 at 4:27 PM, Jeff Jirsa 
wrote:

>
> On 8/15/16, 2:15 PM, "Marvin Humphrey"  wrote:
>
> > Julian Hyde, who made the proposal, is active in the Apache Incubator …
> >I propose that when a JIRA is created, we send an email to both dev@
> and
> >issues@. This will be an extra 40 emails per month on the dev list.
> I am
> >really cautious about increasing the number of messages on the dev
> list,
> >because I think high-volume lists discourage part-time contributors,
> but I
> >think this change is worthwhile. It will make people aware of
> >conversations that are happening and if it helps to channel
> conversations
> >onto JIRA cases it could possibly even REDUCE the volume on the dev
> list.
> >
>
> That’s a useful example. However, that’s a project with 30-40 issues per
> month (1300 over its lifetime) – Cassandra is sitting at 244 in the past 30
> days, 12000 over its lifetime.
>
> I think a lot of us part-time contributors appreciate efforts to increase
> visibility and certainly welcome growing the project by making it easier to
> recruit and retain more contributors, but is the noise of 10 more new email
> threads per day going to get into the “high volume lists discourage
> part-time contributors” range Julian discussed?
>
> I’m a part time contributor. If this list gets ~10 threads per day with
> 2-3 replies each, I’m going to have to start filtering it out of necessity
> (because I can’t keep up with that volume).
>
>
>
>

Re: A proposal to move away from Jira-centric development

[Jeff Jirsa]

On 8/15/16, 2:15 PM, "Marvin Humphrey"  wrote:

> Julian Hyde, who made the proposal, is active in the Apache Incubator … 
>I propose that when a JIRA is created, we send an email to both dev@ and
>issues@. This will be an extra 40 emails per month on the dev list. I am
>really cautious about increasing the number of messages on the dev list,
>because I think high-volume lists discourage part-time contributors, but I
>think this change is worthwhile. It will make people aware of
>conversations that are happening and if it helps to channel conversations
>onto JIRA cases it could possibly even REDUCE the volume on the dev list.
>

That’s a useful example. However, that’s a project with 30-40 issues per month 
(1300 over its lifetime) – Cassandra is sitting at 244 in the past 30 days, 
12000 over its lifetime.

I think a lot of us part-time contributors appreciate efforts to increase 
visibility and certainly welcome growing the project by making it easier to 
recruit and retain more contributors, but is the noise of 10 more new email 
threads per day going to get into the “high volume lists discourage part-time 
contributors” range Julian discussed? 

I’m a part time contributor. If this list gets ~10 threads per day with 2-3 
replies each, I’m going to have to start filtering it out of necessity (because 
I can’t keep up with that volume). 





smime.p7s
Description: S/MIME cryptographic signature

Re: A proposal to move away from Jira-centric development

[Marvin Humphrey]

On 2016-08-15 11:34 (-0700), Jason Brown  wrote: 

> Can you give a few examples of other healthy Apache projects which you feel
> would be good example? Note: I'm not trying to bait the conversation, but
> am genuinely interested in what other successful projects do.

The Apache Calcite project, which has had issues@ broken out as a separate
list, chose to start sending notifications on JIRA issue *creation* (only!) to
the dev list last March.

Julian Hyde, who made the proposal, is active in the Apache Incubator and has
served as Mentor for several incubating projects, so he's dealt with this
issue several times.

https://s.apache.org/w9OM

I propose that when a JIRA is created, we send an email to both dev@ and
issues@. This will be an extra 40 emails per month on the dev list. I am
really cautious about increasing the number of messages on the dev list,
because I think high-volume lists discourage part-time contributors, but I
think this change is worthwhile. It will make people aware of
conversations that are happening and if it helps to channel conversations
onto JIRA cases it could possibly even REDUCE the volume on the dev list.

You may also be interested in the advice that new podlings receive when they
hit the Incubator:

http://wiki.apache.org/incubator/MailingListOptions

Marvin Humphrey

Re: A proposal to move away from Jira-centric development

[Robert Stupp]

I am +1 on separating JIRA changes into a new issues@ ML and to have mail to 
start a design discussion in JIRA on the dev@ ML.

FWIW, I’m coding for many many years and have seen a lot of attempts to 
organise discussions within businesses and in public. Most of these discussions 
were made on mailing lists, which was *the tool* to work with these days. But 
emails were never and still are not a definitely reliable medium - emails 
sometimes get lost or massively delayed on the transport - which is the nature 
of emails - emails are not instant messaging nor necessarily arrive in order. 
But having an common, consistent and ordered view to a discussion is important 
IMO. JIRA provides this view as a tool made to track issues. Mean - JIRAs are 
dynamic, have a state and such. Emails don’t. You can see whether an issue is 
e.g. closed - but you can’t instantly see whether an email discussion is 
“closed”.
When I started to contribute to Apache Cassandra, I really liked the use of 
JIRA because it made it much easier to get into tickets/topics that are 
interesting and are still active (why should a newbie read a whole discussion 
about something that’s already done or obsolete to find something interesting?).
Nowadays, I look at the tickets updated in commits@ but go to JIRA to see the 
whole picture. Additionally, I’ve got a dashboard setup for my needs - but 
that’s probably only advantageous for frequent contributors or committers.
IMO, JIRA is the medium with the best signal-noise-ratio - you can filter/watch 
individual JIRAs. But for mailing lists it’s always all or nothing.

—
Robert Stupp
@snazy

> On 16 Aug 2016, at 06:19, Ken Hancock  wrote:
> 
> On Mon, Aug 15, 2016 at 3:57 PM, Dave Lester  wrote:
> 
>> Interesting, thanks for pointing out this distinction.
>> 
>> Perhaps breaking out issues from the commits list would help make it
>> easier for folks to subscribe in the future? At least within the Apache
>> Mesos and Apache Aurora projects, we’ve seen more people subscribe to
>> issues@ lists than commits@ lists.
>> 
> 
> I was unaware of the commits mailing list and subscribed, but created
> filters to delete comments/updates and only keep Created/Resolved. Is that
> essentially what the issues@ list is for Mesos?

Re: A proposal to move away from Jira-centric development

[Ken Hancock]

On Mon, Aug 15, 2016 at 3:57 PM, Dave Lester  wrote:

> Interesting, thanks for pointing out this distinction.
>
> Perhaps breaking out issues from the commits list would help make it
> easier for folks to subscribe in the future? At least within the Apache
> Mesos and Apache Aurora projects, we’ve seen more people subscribe to
> issues@ lists than commits@ lists.
>

I was unaware of the commits mailing list and subscribed, but created
filters to delete comments/updates and only keep Created/Resolved. Is that
essentially what the issues@ list is for Mesos?

Re: A proposal to move away from Jira-centric development

[Dave Lester]

Interesting, thanks for pointing out this distinction.

Perhaps breaking out issues from the commits list would help make it easier for 
folks to subscribe in the future? At least within the Apache Mesos and Apache 
Aurora projects, we’ve seen more people subscribe to issues@ lists than 
commits@ lists.

FWIW, the Cassandra commits@ list does have a heathy following already — a 
subscriber number greater than those that contributed code to Apache Cassandra. 
For those with Apache ids, mailing list subscriber metrics are browsable using 
the Reporter tool: https://reporter.apache.org/ 

Dave

> On Aug 15, 2016, at 12:14 PM, Benedict Elliott Smith  
> wrote:
> 
> By this definition the Cassandra project is already compliant? There's a
> commits@ mailing list that behaves just as you describe.
> 
> I'd personally like to see some reform with how these things work, but
> mostly because commits@ is rarely going to be subscribed to by anybody who
> isn't working full time on the project, as it's painfully noisy. I would
> hate for dev@ to become similarly noisy though.
> 
> On Monday, 15 August 2016, Dave Lester  > wrote:
> 
>> For all Apache projects, mailing lists are the source of truth. See: "If
>> it didn't happen on a mailing list, it didn't happen."
>> https://community.apache.org/newbiefaq.html#is-there-a- 
>> 
>> code-of-conduct-for-apache-projects > 
>> newbiefaq.html#is-there-a-code-of-conduct-for-apache-projects>
>> 
>> In response to Jason’s question, here are two things I’ve seen work well
>> in the Apache Mesos community:
>> 
>> 1. I’d suggest setting up an iss...@cassandra.apache.org 
>>  
>> mailing list which posts all changes to JIRA tickets (comments, issue
>> reassignments, status changes). This could be subscribed to like any other
>> mailing list, and while this list would be high volume it increases
>> transparency of what’s happening across the project.
>> 
>> For Apache Mesos, we have a issues@mesos list:
>> https://lists.apache.org/list.html?iss...@mesos.apache.org 
>>  <
>> https://lists.apache.org/list.html?iss...@mesos.apache.org 
>> > for this
>> purpose. It can be hugely valuable for keeping tabs on what’s happening in
>> the project. If there’s interest in creating this for Cassandra, here’s a
>> link to the original INFRA ticket as a reference:
>> https://issues.apache.org/jira/browse/INFRA-7971 
>>  <
>> https://issues.apache.org/jira/browse/INFRA-7971 
>> >
>> 
>> 2. Apache Mesos has formalized process of design documents / feature
>> development, to encourage community discussion prior to being committed —
>> this discussion takes place on the mailing list and often has less to do
>> with the merits of a particular patch as much as it does on an overall
>> design, its relationship to dependencies, its usage, or larger issues about
>> the direction of a feature. These discussions belong on the mailing list.
>> 
>> To keep these discussions / design documents connected to JIRA we attach
>> links to JIRA issues. For example: https://cwiki.apache.org/ 
>> 
>> confluence/display/MESOS/Design+docs+--+Shared+Links <
>> https://cwiki.apache.org/confluence/display/MESOS/
>> Design+docs+--+Shared+Links>. The design doc approach is more of a
>> formalization of what Jonathan originally proposed.
>> 
>> Dave
>> 
>>> On Aug 15, 2016, at 11:34 AM, Jason Brown > > wrote:
>>> 
>>> Chris,
>>> 
>>> Can you give a few examples of other healthy Apache projects which you
>> feel
>>> would be good example? Note: I'm not trying to bait the conversation, but
>>> am genuinely interested in what other successful projects do.
>>> 
>>> Thanks
>>> 
>>> Jason
>>> 
>>> On Monday, August 15, 2016, Chris Mattmann > > wrote:
>>> 
 s/dev list followers//
 
 That’s (one of) the disconnect(s). It’s not *you the emboldened,
>> powerful
 PMC*
 and then everyone else.
 
 
 On 8/15/16, 11:25 AM, "Jeremy Hanna" > 
 > wrote:
 
   Regarding high level linking, if I’m in irc or slack or hipchat or a
 mailing list thread, it’s easy to reference a Jira ID and chat programs
>> can
 link to it and bots can bring up various details.  I don’t think a hash
>> id
 for a mailing list is as simple or memorable.
 
   A feature of a mailing list thread is that it can go in different
 directions easily.  The burden is that it will be harder to follow in
>> the
 future if you’re trying to sort out implementation details.  So for high
 level discussion, the mailing list is great.  When getting down to the

Re: A proposal to move away from Jira-centric development

[Benedict Elliott Smith]

By this definition the Cassandra project is already compliant? There's a
commits@ mailing list that behaves just as you describe.

I'd personally like to see some reform with how these things work, but
mostly because commits@ is rarely going to be subscribed to by anybody who
isn't working full time on the project, as it's painfully noisy. I would
hate for dev@ to become similarly noisy though.

On Monday, 15 August 2016, Dave Lester  wrote:

> For all Apache projects, mailing lists are the source of truth. See: "If
> it didn't happen on a mailing list, it didn't happen."
> https://community.apache.org/newbiefaq.html#is-there-a-
> code-of-conduct-for-apache-projects  newbiefaq.html#is-there-a-code-of-conduct-for-apache-projects>
>
> In response to Jason’s question, here are two things I’ve seen work well
> in the Apache Mesos community:
>
> 1. I’d suggest setting up an iss...@cassandra.apache.org 
> mailing list which posts all changes to JIRA tickets (comments, issue
> reassignments, status changes). This could be subscribed to like any other
> mailing list, and while this list would be high volume it increases
> transparency of what’s happening across the project.
>
> For Apache Mesos, we have a issues@mesos list:
> https://lists.apache.org/list.html?iss...@mesos.apache.org <
> https://lists.apache.org/list.html?iss...@mesos.apache.org> for this
> purpose. It can be hugely valuable for keeping tabs on what’s happening in
> the project. If there’s interest in creating this for Cassandra, here’s a
> link to the original INFRA ticket as a reference:
> https://issues.apache.org/jira/browse/INFRA-7971 <
> https://issues.apache.org/jira/browse/INFRA-7971>
>
> 2. Apache Mesos has formalized process of design documents / feature
> development, to encourage community discussion prior to being committed —
> this discussion takes place on the mailing list and often has less to do
> with the merits of a particular patch as much as it does on an overall
> design, its relationship to dependencies, its usage, or larger issues about
> the direction of a feature. These discussions belong on the mailing list.
>
> To keep these discussions / design documents connected to JIRA we attach
> links to JIRA issues. For example: https://cwiki.apache.org/
> confluence/display/MESOS/Design+docs+--+Shared+Links <
> https://cwiki.apache.org/confluence/display/MESOS/
> Design+docs+--+Shared+Links>. The design doc approach is more of a
> formalization of what Jonathan originally proposed.
>
> Dave
>
> > On Aug 15, 2016, at 11:34 AM, Jason Brown  > wrote:
> >
> > Chris,
> >
> > Can you give a few examples of other healthy Apache projects which you
> feel
> > would be good example? Note: I'm not trying to bait the conversation, but
> > am genuinely interested in what other successful projects do.
> >
> > Thanks
> >
> > Jason
> >
> > On Monday, August 15, 2016, Chris Mattmann  > wrote:
> >
> >> s/dev list followers//
> >>
> >> That’s (one of) the disconnect(s). It’s not *you the emboldened,
> powerful
> >> PMC*
> >> and then everyone else.
> >>
> >>
> >> On 8/15/16, 11:25 AM, "Jeremy Hanna"  
> >> > wrote:
> >>
> >>Regarding high level linking, if I’m in irc or slack or hipchat or a
> >> mailing list thread, it’s easy to reference a Jira ID and chat programs
> can
> >> link to it and bots can bring up various details.  I don’t think a hash
> id
> >> for a mailing list is as simple or memorable.
> >>
> >>A feature of a mailing list thread is that it can go in different
> >> directions easily.  The burden is that it will be harder to follow in
> the
> >> future if you’re trying to sort out implementation details.  So for high
> >> level discussion, the mailing list is great.  When getting down to the
> >> actual work and discussion about that focused work, that’s where a tool
> >> like Jira comes in.  Then it is reference-able in the changes.txt and
> other
> >> things.
> >>
> >>I think the approach proposed by Jonathan is a nice way to keep dev
> >> list followers informed but keeping ticket details focused.
> >>
> >>> On Aug 15, 2016, at 1:12 PM, Chris Mattmann  
> >> > wrote:
> >>>
> >>> How is it harder to point someone to mail?
> >>>
> >>> Have you seen lists.apache.org?
> >>>
> >>> Specifically:
> >>> https://lists.apache.org/list.html?dev@cassandra.apache.org
> >>>
> >>>
> >>>
> >>> On 8/15/16, 10:08 AM, "Jeremiah D Jordan"  
> >> > wrote:
> >>>
> >>>   I like keeping things in JIRA because then everything is in one
> >> place, and it is easy to refer someone to it in the future.
> >>>   But I agree that JIRA tickets with a bunch of design discussion
> >> and POC’s and such in them can get pretty long and convoluted.
> >>>
> >>>   I don’t really like the idea of moving all of that discussion to
> >> email which makes it has harder to point someone to it.  Maybe a better
> >> idea would be to have a “design/POC” JIRA and an “implementation” JIRA.
> >> That way we could still keep things in J

Re: A proposal to move away from Jira-centric development

[Jeremiah D Jordan]

> 1. I’d suggest setting up an iss...@cassandra.apache.org mailing list which 
> posts all changes to JIRA tickets (comments, issue reassignments, status 
> changes). This could be subscribed to like any other mailing list, and while 
> this list would be high volume it increases transparency of what’s happening 
> across the project.

For anyone who wants to follow that stream for Apache Cassandra we have 
commits@ setup for this.  
https://lists.apache.org/list.html?comm...@cassandra.apache.org 


> On Aug 15, 2016, at 2:06 PM, Dave Lester  wrote:
> 
> For all Apache projects, mailing lists are the source of truth. See: "If it 
> didn't happen on a mailing list, it didn't happen." 
> https://community.apache.org/newbiefaq.html#is-there-a-code-of-conduct-for-apache-projects
>  
> 
> 
> In response to Jason’s question, here are two things I’ve seen work well in 
> the Apache Mesos community:
> 
> 1. I’d suggest setting up an iss...@cassandra.apache.org mailing list which 
> posts all changes to JIRA tickets (comments, issue reassignments, status 
> changes). This could be subscribed to like any other mailing list, and while 
> this list would be high volume it increases transparency of what’s happening 
> across the project.
> 
> For Apache Mesos, we have a issues@mesos list: 
> https://lists.apache.org/list.html?iss...@mesos.apache.org 
>  for this 
> purpose. It can be hugely valuable for keeping tabs on what’s happening in 
> the project. If there’s interest in creating this for Cassandra, here’s a 
> link to the original INFRA ticket as a reference: 
> https://issues.apache.org/jira/browse/INFRA-7971 
> 
> 
> 2. Apache Mesos has formalized process of design documents / feature 
> development, to encourage community discussion prior to being committed — 
> this discussion takes place on the mailing list and often has less to do with 
> the merits of a particular patch as much as it does on an overall design, its 
> relationship to dependencies, its usage, or larger issues about the direction 
> of a feature. These discussions belong on the mailing list.
> 
> To keep these discussions / design documents connected to JIRA we attach 
> links to JIRA issues. For example: 
> https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links 
> .
>  The design doc approach is more of a formalization of what Jonathan 
> originally proposed.
> 
> Dave
> 
>> On Aug 15, 2016, at 11:34 AM, Jason Brown  wrote:
>> 
>> Chris,
>> 
>> Can you give a few examples of other healthy Apache projects which you feel
>> would be good example? Note: I'm not trying to bait the conversation, but
>> am genuinely interested in what other successful projects do.
>> 
>> Thanks
>> 
>> Jason
>> 
>> On Monday, August 15, 2016, Chris Mattmann  wrote:
>> 
>>> s/dev list followers//
>>> 
>>> That’s (one of) the disconnect(s). It’s not *you the emboldened, powerful
>>> PMC*
>>> and then everyone else.
>>> 
>>> 
>>> On 8/15/16, 11:25 AM, "Jeremy Hanna" >> > wrote:
>>> 
>>>   Regarding high level linking, if I’m in irc or slack or hipchat or a
>>> mailing list thread, it’s easy to reference a Jira ID and chat programs can
>>> link to it and bots can bring up various details.  I don’t think a hash id
>>> for a mailing list is as simple or memorable.
>>> 
>>>   A feature of a mailing list thread is that it can go in different
>>> directions easily.  The burden is that it will be harder to follow in the
>>> future if you’re trying to sort out implementation details.  So for high
>>> level discussion, the mailing list is great.  When getting down to the
>>> actual work and discussion about that focused work, that’s where a tool
>>> like Jira comes in.  Then it is reference-able in the changes.txt and other
>>> things.
>>> 
>>>   I think the approach proposed by Jonathan is a nice way to keep dev
>>> list followers informed but keeping ticket details focused.
>>> 
 On Aug 15, 2016, at 1:12 PM, Chris Mattmann >> > wrote:
 
 How is it harder to point someone to mail?
 
 Have you seen lists.apache.org?
 
 Specifically:
 https://lists.apache.org/list.html?dev@cassandra.apache.org
 
 
 
 On 8/15/16, 10:08 AM, "Jeremiah D Jordan" >> > wrote:
 
  I like keeping things in JIRA because then everything is in one
>>> place, and it is easy to refer someone to it in the future.
  But I agree that JIRA tickets with a bunch of design discussion
>>> and POC’s and such in them can get pretty long and convoluted.
 
  I don’t really like the idea of moving all of that discussion to
>>> email which makes it has harder to point someone to it.  Maybe a

Re: A proposal to move away from Jira-centric development

[Michael Shuler]

On 08/15/2016 01:12 PM, Chris Mattmann wrote:
> How is it harder to point someone to mail?

Mailing lists can be simple to join and converse. Like some other folks,
I'm on a large number of lists and get massive amounts of mail.
Extremely busy mailing lists need user-level care for them to be
functional for the flow of conversation and proper thread archiving.

> Have you seen lists.apache.org?
> 
> Specifically:
> https://lists.apache.org/list.html?dev@cassandra.apache.org

Since signal vs noise is part of the conversation here, I just wish to
point out my observation that this particular thread has some pretty
severe readability issues, and this thread is tiny in comparison to the
multi-100's of messages on some list threads. Here's this thread in the
archive:

https://lists.apache.org/thread.html/a6e6c9303779cb095ab14c3b4d66436a3771f076e8dbd9970eca46fe@%3Cdev.cassandra.apache.org%3E

Chris, it appears that your mail client, Microsoft-MacOutlook, does some
very odd indentation/munging on reply text, so Pony Mail cannot properly
collapse the text you are replying to. This also propagates to some of
the other user's replies to your messages. The result is a thread
archive that contains a large amount of "wall of text" appearance,
making it difficult to pick out and follow the actual conversation
taking place. Please, fix your mail client.

-- 
Kind regards,
Michael

Re: A proposal to move away from Jira-centric development

[Dave Lester]

For all Apache projects, mailing lists are the source of truth. See: "If it 
didn't happen on a mailing list, it didn't happen." 
https://community.apache.org/newbiefaq.html#is-there-a-code-of-conduct-for-apache-projects
 


In response to Jason’s question, here are two things I’ve seen work well in the 
Apache Mesos community:

1. I’d suggest setting up an iss...@cassandra.apache.org mailing list which 
posts all changes to JIRA tickets (comments, issue reassignments, status 
changes). This could be subscribed to like any other mailing list, and while 
this list would be high volume it increases transparency of what’s happening 
across the project.

For Apache Mesos, we have a issues@mesos list: 
https://lists.apache.org/list.html?iss...@mesos.apache.org 
 for this purpose. 
It can be hugely valuable for keeping tabs on what’s happening in the project. 
If there’s interest in creating this for Cassandra, here’s a link to the 
original INFRA ticket as a reference: 
https://issues.apache.org/jira/browse/INFRA-7971 


2. Apache Mesos has formalized process of design documents / feature 
development, to encourage community discussion prior to being committed — this 
discussion takes place on the mailing list and often has less to do with the 
merits of a particular patch as much as it does on an overall design, its 
relationship to dependencies, its usage, or larger issues about the direction 
of a feature. These discussions belong on the mailing list.

To keep these discussions / design documents connected to JIRA we attach links 
to JIRA issues. For example: 
https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links 
.
 The design doc approach is more of a formalization of what Jonathan originally 
proposed.

Dave

> On Aug 15, 2016, at 11:34 AM, Jason Brown  wrote:
> 
> Chris,
> 
> Can you give a few examples of other healthy Apache projects which you feel
> would be good example? Note: I'm not trying to bait the conversation, but
> am genuinely interested in what other successful projects do.
> 
> Thanks
> 
> Jason
> 
> On Monday, August 15, 2016, Chris Mattmann  wrote:
> 
>> s/dev list followers//
>> 
>> That’s (one of) the disconnect(s). It’s not *you the emboldened, powerful
>> PMC*
>> and then everyone else.
>> 
>> 
>> On 8/15/16, 11:25 AM, "Jeremy Hanna" > > wrote:
>> 
>>Regarding high level linking, if I’m in irc or slack or hipchat or a
>> mailing list thread, it’s easy to reference a Jira ID and chat programs can
>> link to it and bots can bring up various details.  I don’t think a hash id
>> for a mailing list is as simple or memorable.
>> 
>>A feature of a mailing list thread is that it can go in different
>> directions easily.  The burden is that it will be harder to follow in the
>> future if you’re trying to sort out implementation details.  So for high
>> level discussion, the mailing list is great.  When getting down to the
>> actual work and discussion about that focused work, that’s where a tool
>> like Jira comes in.  Then it is reference-able in the changes.txt and other
>> things.
>> 
>>I think the approach proposed by Jonathan is a nice way to keep dev
>> list followers informed but keeping ticket details focused.
>> 
>>> On Aug 15, 2016, at 1:12 PM, Chris Mattmann > > wrote:
>>> 
>>> How is it harder to point someone to mail?
>>> 
>>> Have you seen lists.apache.org?
>>> 
>>> Specifically:
>>> https://lists.apache.org/list.html?dev@cassandra.apache.org
>>> 
>>> 
>>> 
>>> On 8/15/16, 10:08 AM, "Jeremiah D Jordan" > > wrote:
>>> 
>>>   I like keeping things in JIRA because then everything is in one
>> place, and it is easy to refer someone to it in the future.
>>>   But I agree that JIRA tickets with a bunch of design discussion
>> and POC’s and such in them can get pretty long and convoluted.
>>> 
>>>   I don’t really like the idea of moving all of that discussion to
>> email which makes it has harder to point someone to it.  Maybe a better
>> idea would be to have a “design/POC” JIRA and an “implementation” JIRA.
>> That way we could still keep things in JIRA, but the final decision would
>> be kept “clean”.
>>> 
>>>   Though it would be nice if people would send an email to the dev
>> list when proposing “design” JIRA’s, as not everyone has time to follow
>> every JIRA ever made to see that a new design JIRA was created that they
>> might be interested in participating on.
>>> 
>>>   My 2c.
>>> 
>>>   -Jeremiah
>>> 
>>> 
 On Aug 15, 2016, at 9:22 AM, Jonathan Ellis > > 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

Re: A proposal to move away from Jira-centric development

[Jeff Jirsa]

+1 (nonbinding) to at least announcing major architectural improvements on dev 
email. 

I don’t know that it’s going to help encourage more contributors like Chris 
suggests, but it seems like at worst it won’t hurt, and certainly should help 
make people aware of Jiras that would otherwise slip by unnoticed. 
 

On 8/15/16, 7:22 AM, "Jonathan Ellis"  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, 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.datastax.com&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=sw6DH_A1qpHeVAQNIUqFE0MwHlAsEAfFgqpciRBV2JY&s=bo665yjr_ozrH_nDYzW1afy_N8N3JJ_TTPaB2rkghYM&e=
> 
>@spyced


smime.p7s
Description: S/MIME cryptographic signature

Re: A proposal to move away from Jira-centric development

[Russell Bradberry]

The Apache Software Foundation is *not* a democracy, it is a meritocracy. This 
means that only those appointed to the ASF board/PMC, actually have any right 
to vote or have a say in anything. People are added to the PMC/Board based on 
their perceived knowledge/merit/performance. Mr. Mattmann is just a 
representative of the governing body.


On 8/15/16, 2:37 PM, "San Luoji"  wrote:

> That’s not optional. If you are an ASF project, mailing lists are the
source of truth. Period.

Since when dictatorship becomes part of the culture in Apache Cassandra
community?

dic·ta·tor·ship
dikˈtādərˌSHip,ˈdiktādərˌSHip/
*noun*

   1. government by a dictator.
   "forty years of dictatorship"
   synonyms: absolute rule, undemocratic rule, despotism
   

   , tyranny
   

   , autocracy
   

   , autarchy
   

   ,authoritarianism, totalitarianism, fascism
   

   ; More

   

   


   

   - a country governed by a dictator.
  plural noun: *dictatorships*
  synonyms: absolute rule, undemocratic rule, despotism
  

  , tyranny
  

  , autocracy
  

  , autarchy
  

  ,authoritarianism, totalitarianism, fascism
  

  ; More

  

  


  

  - absolute authority in any sphere.


On Mon, Aug 15, 2016 at 12:03 PM, Chris Mattmann 
wrote:

> I’m sorry but you are massively confused if you believe that the ASF
> mailing lists
> aren’t the source of truth. They are. That’s not optional. If you are an
> ASF project,
> mailing lists are the source of truth. Period.
>
> On 8/15/16, 11:01 AM, "Michael Kjellman" 
> wrote:
>
> I'm a big fan of mailing lists, but google makes issues very findable
> for new people to the project as JIRA gets indexed. They won't be able to
> find the same thing on an email they didn't get -- because they weren't in
> the project in the first place.
>
> Mailing lists are good for broad discussion or bringing specific
> issues to the attention of the broader community. It should never be the
> source of truth.
>
> best,
> kjellman
>
> Sent from my iPhone
>
> On Aug 15, 2016, at 2:57 PM, Chris Mattmann  > wrote:
>
> Realize it’s not just about committers and PMC members that are
> *already*
> on the PMC or that are developing the project. It’s about how to
> engage the
> *entire* community including those that are not yet on the committer 
or
> PMC roster. That is the future (and current) lifeblood of the project.
> The mailing
> list aren’t just an unfortunate necessity of being an Apache project.
> They *are*
> the lifeblood of the Apache project.
>
>
>
> On 8/15/16, 10:44 AM, "Brandon Williams"  dri...@gmail.com>> wrote:
>
>I too, use this method quite a bit, almost every single day.
>
>On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita <
> mor.y...@gmail.com> wrote:
>
> As an active committer, the most important thing for me is to be able
> to *look up* design 

Re: A proposal to move away from Jira-centric development

[San Luoji]

> That’s not optional. If you are an ASF project, mailing lists are the
source of truth. Period.

Since when dictatorship becomes part of the culture in Apache Cassandra
community?

dic·ta·tor·ship
dikˈtādərˌSHip,ˈdiktādərˌSHip/
*noun*

   1. government by a dictator.
   "forty years of dictatorship"
   synonyms: absolute rule, undemocratic rule, despotism
   

   , tyranny
   

   , autocracy
   

   , autarchy
   

   ,authoritarianism, totalitarianism, fascism
   

   ; More

   

   


   

   - a country governed by a dictator.
  plural noun: *dictatorships*
  synonyms: absolute rule, undemocratic rule, despotism
  

  , tyranny
  

  , autocracy
  

  , autarchy
  

  ,authoritarianism, totalitarianism, fascism
  

  ; More

  

  


  

  - absolute authority in any sphere.


On Mon, Aug 15, 2016 at 12:03 PM, Chris Mattmann 
wrote:

> I’m sorry but you are massively confused if you believe that the ASF
> mailing lists
> aren’t the source of truth. They are. That’s not optional. If you are an
> ASF project,
> mailing lists are the source of truth. Period.
>
> On 8/15/16, 11:01 AM, "Michael Kjellman" 
> wrote:
>
> I'm a big fan of mailing lists, but google makes issues very findable
> for new people to the project as JIRA gets indexed. They won't be able to
> find the same thing on an email they didn't get -- because they weren't in
> the project in the first place.
>
> Mailing lists are good for broad discussion or bringing specific
> issues to the attention of the broader community. It should never be the
> source of truth.
>
> best,
> kjellman
>
> Sent from my iPhone
>
> On Aug 15, 2016, at 2:57 PM, Chris Mattmann  > wrote:
>
> Realize it’s not just about committers and PMC members that are
> *already*
> on the PMC or that are developing the project. It’s about how to
> engage the
> *entire* community including those that are not yet on the committer or
> PMC roster. That is the future (and current) lifeblood of the project.
> The mailing
> list aren’t just an unfortunate necessity of being an Apache project.
> They *are*
> the lifeblood of the Apache project.
>
>
>
> On 8/15/16, 10:44 AM, "Brandon Williams"  dri...@gmail.com>> wrote:
>
>I too, use this method quite a bit, almost every single day.
>
>On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita <
> mor.y...@gmail.com> wrote:
>
> As an active committer, the most important thing for me is to be able
> to *look up* design discussion and decision easily later.
>
> I often look up the git history or CHANGES.txt for changes that I'm
> interested in, then look up JIRA by following JIRA ticket number
> written to the comment or text.
> If we move to dev mailing list, I would request to post permalink to
> that thread posted to JIRA, which I think is just one extra step that
> isn't necessary if we simply use JIRA.
>
> So, I'm +1 to just post JIRA link to dev list.
>
>
> On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann  >
> wrote:
> This is a good outward flow of info to the dev list. However, there
> needs to be
> inward flow too – having the convo on the dev list will be a good start
> to that.
> I hope to see more

Re: A proposal to move away from Jira-centric development

[Jason Brown]

Chris,

Can you give a few examples of other healthy Apache projects which you feel
would be good example? Note: I'm not trying to bait the conversation, but
am genuinely interested in what other successful projects do.

Thanks

Jason

On Monday, August 15, 2016, Chris Mattmann  wrote:

> s/dev list followers//
>
> That’s (one of) the disconnect(s). It’s not *you the emboldened, powerful
> PMC*
> and then everyone else.
>
>
> On 8/15/16, 11:25 AM, "Jeremy Hanna"  > wrote:
>
> Regarding high level linking, if I’m in irc or slack or hipchat or a
> mailing list thread, it’s easy to reference a Jira ID and chat programs can
> link to it and bots can bring up various details.  I don’t think a hash id
> for a mailing list is as simple or memorable.
>
> A feature of a mailing list thread is that it can go in different
> directions easily.  The burden is that it will be harder to follow in the
> future if you’re trying to sort out implementation details.  So for high
> level discussion, the mailing list is great.  When getting down to the
> actual work and discussion about that focused work, that’s where a tool
> like Jira comes in.  Then it is reference-able in the changes.txt and other
> things.
>
> I think the approach proposed by Jonathan is a nice way to keep dev
> list followers informed but keeping ticket details focused.
>
> > On Aug 15, 2016, at 1:12 PM, Chris Mattmann  > wrote:
> >
> > How is it harder to point someone to mail?
> >
> > Have you seen lists.apache.org?
> >
> > Specifically:
> > https://lists.apache.org/list.html?dev@cassandra.apache.org
> >
> >
> >
> > On 8/15/16, 10:08 AM, "Jeremiah D Jordan"  > wrote:
> >
> >I like keeping things in JIRA because then everything is in one
> place, and it is easy to refer someone to it in the future.
> >But I agree that JIRA tickets with a bunch of design discussion
> and POC’s and such in them can get pretty long and convoluted.
> >
> >I don’t really like the idea of moving all of that discussion to
> email which makes it has harder to point someone to it.  Maybe a better
> idea would be to have a “design/POC” JIRA and an “implementation” JIRA.
> That way we could still keep things in JIRA, but the final decision would
> be kept “clean”.
> >
> >Though it would be nice if people would send an email to the dev
> list when proposing “design” JIRA’s, as not everyone has time to follow
> every JIRA ever made to see that a new design JIRA was created that they
> might be interested in participating on.
> >
> >My 2c.
> >
> >-Jeremiah
> >
> >
> >> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  > 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
> >
> >
> >
> >
>
>
>
>
>

Re: A proposal to move away from Jira-centric development

[Jeremy Hanna]

I’m not a committer or PMC member.  I’m a dev list follower and contributor.  
I’ve been working with different apache projects for years.  I often don’t 
follow or filter the asf lists because I’m only interested in individual 
tickets.  I often don’t care how the decision was made, though that may be 
important for auditing purposes for a project.  I care that it’s been 
implemented and having an easy way to link to it if I want to give others an 
easy way to watch or vote for the feature.  Also I’ve found the lists as a pain 
because if I want to contribute something to a discussion I have to join the 
list.  I often don’t want to join a list about project X.  I just care insofar 
as it relates to what I want.  So I have my universal Jira account and I can 
watch or vote for or comment on tickets.  Within the Apache ecosystem, that’s 
much simpler than having to follow a list per project.

> On Aug 15, 2016, at 1:27 PM, Chris Mattmann  wrote:
> 
> s/dev list followers//
> 
> That’s (one of) the disconnect(s). It’s not *you the emboldened, powerful 
> PMC* 
> and then everyone else.
> 
> 
> On 8/15/16, 11:25 AM, "Jeremy Hanna"  wrote:
> 
>Regarding high level linking, if I’m in irc or slack or hipchat or a 
> mailing list thread, it’s easy to reference a Jira ID and chat programs can 
> link to it and bots can bring up various details.  I don’t think a hash id 
> for a mailing list is as simple or memorable.
> 
>A feature of a mailing list thread is that it can go in different 
> directions easily.  The burden is that it will be harder to follow in the 
> future if you’re trying to sort out implementation details.  So for high 
> level discussion, the mailing list is great.  When getting down to the actual 
> work and discussion about that focused work, that’s where a tool like Jira 
> comes in.  Then it is reference-able in the changes.txt and other things.
> 
>I think the approach proposed by Jonathan is a nice way to keep dev list 
> followers informed but keeping ticket details focused.
> 
>> On Aug 15, 2016, at 1:12 PM, Chris Mattmann  wrote:
>> 
>> How is it harder to point someone to mail?
>> 
>> Have you seen lists.apache.org?
>> 
>> Specifically:
>> https://lists.apache.org/list.html?dev@cassandra.apache.org
>> 
>> 
>> 
>> On 8/15/16, 10:08 AM, "Jeremiah D Jordan"  wrote:
>> 
>>   I like keeping things in JIRA because then everything is in one place, and 
>> it is easy to refer someone to it in the future.
>>   But I agree that JIRA tickets with a bunch of design discussion and POC’s 
>> and such in them can get pretty long and convoluted.
>> 
>>   I don’t really like the idea of moving all of that discussion to email 
>> which makes it has harder to point someone to it.  Maybe a better idea would 
>> be to have a “design/POC” JIRA and an “implementation” JIRA.  That way we 
>> could still keep things in JIRA, but the final decision would be kept 
>> “clean”.
>> 
>>   Though it would be nice if people would send an email to the dev list when 
>> proposing “design” JIRA’s, as not everyone has time to follow every JIRA 
>> ever made to see that a new design JIRA was created that they might be 
>> interested in participating on.
>> 
>>   My 2c.
>> 
>>   -Jeremiah
>> 
>> 
>>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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
>> 
>> 
>> 
>> 
> 
> 
> 
> 

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

s/dev list followers//

That’s (one of) the disconnect(s). It’s not *you the emboldened, powerful PMC* 
and then everyone else.


On 8/15/16, 11:25 AM, "Jeremy Hanna"  wrote:

Regarding high level linking, if I’m in irc or slack or hipchat or a 
mailing list thread, it’s easy to reference a Jira ID and chat programs can 
link to it and bots can bring up various details.  I don’t think a hash id for 
a mailing list is as simple or memorable.

A feature of a mailing list thread is that it can go in different 
directions easily.  The burden is that it will be harder to follow in the 
future if you’re trying to sort out implementation details.  So for high level 
discussion, the mailing list is great.  When getting down to the actual work 
and discussion about that focused work, that’s where a tool like Jira comes in. 
 Then it is reference-able in the changes.txt and other things.

I think the approach proposed by Jonathan is a nice way to keep dev list 
followers informed but keeping ticket details focused.

> On Aug 15, 2016, at 1:12 PM, Chris Mattmann  wrote:
> 
> How is it harder to point someone to mail?
> 
> Have you seen lists.apache.org?
> 
> Specifically:
> https://lists.apache.org/list.html?dev@cassandra.apache.org
> 
> 
> 
> On 8/15/16, 10:08 AM, "Jeremiah D Jordan"  
wrote:
> 
>I like keeping things in JIRA because then everything is in one place, 
and it is easy to refer someone to it in the future.
>But I agree that JIRA tickets with a bunch of design discussion and 
POC’s and such in them can get pretty long and convoluted.
> 
>I don’t really like the idea of moving all of that discussion to email 
which makes it has harder to point someone to it.  Maybe a better idea would be 
to have a “design/POC” JIRA and an “implementation” JIRA.  That way we could 
still keep things in JIRA, but the final decision would be kept “clean”.
> 
>Though it would be nice if people would send an email to the dev list 
when proposing “design” JIRA’s, as not everyone has time to follow every JIRA 
ever made to see that a new design JIRA was created that they might be 
interested in participating on.
> 
>My 2c.
> 
>-Jeremiah
> 
> 
>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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
> 
> 
> 
> 

Re: A proposal to move away from Jira-centric development

[Jeremy Hanna]

Regarding high level linking, if I’m in irc or slack or hipchat or a mailing 
list thread, it’s easy to reference a Jira ID and chat programs can link to it 
and bots can bring up various details.  I don’t think a hash id for a mailing 
list is as simple or memorable.

A feature of a mailing list thread is that it can go in different directions 
easily.  The burden is that it will be harder to follow in the future if you’re 
trying to sort out implementation details.  So for high level discussion, the 
mailing list is great.  When getting down to the actual work and discussion 
about that focused work, that’s where a tool like Jira comes in.  Then it is 
reference-able in the changes.txt and other things.

I think the approach proposed by Jonathan is a nice way to keep dev list 
followers informed but keeping ticket details focused.

> On Aug 15, 2016, at 1:12 PM, Chris Mattmann  wrote:
> 
> How is it harder to point someone to mail?
> 
> Have you seen lists.apache.org?
> 
> Specifically:
> https://lists.apache.org/list.html?dev@cassandra.apache.org
> 
> 
> 
> On 8/15/16, 10:08 AM, "Jeremiah D Jordan"  wrote:
> 
>I like keeping things in JIRA because then everything is in one place, and 
> it is easy to refer someone to it in the future.
>But I agree that JIRA tickets with a bunch of design discussion and POC’s 
> and such in them can get pretty long and convoluted.
> 
>I don’t really like the idea of moving all of that discussion to email 
> which makes it has harder to point someone to it.  Maybe a better idea would 
> be to have a “design/POC” JIRA and an “implementation” JIRA.  That way we 
> could still keep things in JIRA, but the final decision would be kept “clean”.
> 
>Though it would be nice if people would send an email to the dev list when 
> proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
> made to see that a new design JIRA was created that they might be interested 
> in participating on.
> 
>My 2c.
> 
>-Jeremiah
> 
> 
>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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
> 
> 
> 
> 

Re: A proposal to move away from Jira-centric development

[J. D. Jordan]

From my interactions with people who are not actively involved I think it is 
much easier for them to follow a JIRA link and then start being involved in the 
discussion than it is to get a link to the mail archive and then figure out how 
to get in on the discussion.

People who aren't used to mailing lists don't "get them". Most people 
understand getting an account on a website and posting there, as it's like 
Facebook but for Software discussions.

> On Aug 15, 2016, at 1:12 PM, Chris Mattmann  wrote:
> 
> How is it harder to point someone to mail?
> 
> Have you seen lists.apache.org?
> 
> Specifically:
> https://lists.apache.org/list.html?dev@cassandra.apache.org
> 
> 
> 
> On 8/15/16, 10:08 AM, "Jeremiah D Jordan"  wrote:
> 
>I like keeping things in JIRA because then everything is in one place, and 
> it is easy to refer someone to it in the future.
>But I agree that JIRA tickets with a bunch of design discussion and POC’s 
> and such in them can get pretty long and convoluted.
> 
>I don’t really like the idea of moving all of that discussion to email 
> which makes it has harder to point someone to it.  Maybe a better idea would 
> be to have a “design/POC” JIRA and an “implementation” JIRA.  That way we 
> could still keep things in JIRA, but the final decision would be kept “clean”.
> 
>Though it would be nice if people would send an email to the dev list when 
> proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
> made to see that a new design JIRA was created that they might be interested 
> in participating on.
> 
>My 2c.
> 
>-Jeremiah
> 
> 
>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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
> 
> 
> 
> 

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

How is it harder to point someone to mail?

Have you seen lists.apache.org?

Specifically:
https://lists.apache.org/list.html?dev@cassandra.apache.org



On 8/15/16, 10:08 AM, "Jeremiah D Jordan"  wrote:

I like keeping things in JIRA because then everything is in one place, and 
it is easy to refer someone to it in the future.
But I agree that JIRA tickets with a bunch of design discussion and POC’s 
and such in them can get pretty long and convoluted.

I don’t really like the idea of moving all of that discussion to email 
which makes it has harder to point someone to it.  Maybe a better idea would be 
to have a “design/POC” JIRA and an “implementation” JIRA.  That way we could 
still keep things in JIRA, but the final decision would be kept “clean”.

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.

My 2c.

-Jeremiah


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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

Re: A proposal to move away from Jira-centric development

[Anuj Wadehra]

Hi,
I think tracking things in a tool would be better than having mailing 
lists+JIRA. To make feature JIRAs easier to comprehend, we can close every JIRA 
discussion with an attached Design proposal (mandatory). Once design is frozen 
and complete, one can start with the implementation. 
Not sure about JIRA customizations possible.It would be good if we could 
customize JIRA tickets to keep discussions isolated from approved design 
(within single JIRA ticket).
I personally find it tough to go through long JIRA discussions, just to 
understand the final design concluded for a problem/feature.
Discussing initial thoughts about pain areas,improvements etc can be done on 
the dev mailing list. 
ThanksAnuj


 
 
  On Mon, 15 Aug, 2016 at 7:52 PM, Jonathan Ellis 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
  

Re: A proposal to move away from Jira-centric development

[Michael Kjellman]

I get 2500+ emails a day and I don't filter dev as I like to stay engaged. If 
this list becomes too noisy everyone will just filter it into a black hole. Sad.

Sent from my iPhone

On Aug 15, 2016, at 3:05 PM, Russell Bradberry 
mailto:rbradbe...@gmail.com>> wrote:

So then what was the point of Ellis’s proposal, and this discussion, if there 
was never a choice in the matter in the first place?


On 8/15/16, 2:03 PM, "Chris Mattmann" 
mailto:mattm...@apache.org>> wrote:

   I’m sorry but you are massively confused if you believe that the ASF mailing 
lists
   aren’t the source of truth. They are. That’s not optional. If you are an ASF 
project,
   mailing lists are the source of truth. Period.

   On 8/15/16, 11:01 AM, "Michael Kjellman" 
mailto:mkjell...@internalcircle.com>> wrote:

   I'm a big fan of mailing lists, but google makes issues very findable 
for new people to the project as JIRA gets indexed. They won't be able to find 
the same thing on an email they didn't get -- because they weren't in the 
project in the first place.

   Mailing lists are good for broad discussion or bringing specific issues 
to the attention of the broader community. It should never be the source of 
truth.

   best,
   kjellman

   Sent from my iPhone

   On Aug 15, 2016, at 2:57 PM, Chris Mattmann 
mailto:mattm...@apache.org>> 
wrote:

   Realize it’s not just about committers and PMC members that are *already*
   on the PMC or that are developing the project. It’s about how to engage 
the
   *entire* community including those that are not yet on the committer or
   PMC roster. That is the future (and current) lifeblood of the project. 
The mailing
   list aren’t just an unfortunate necessity of being an Apache project. 
They *are*
   the lifeblood of the Apache project.



   On 8/15/16, 10:44 AM, "Brandon Williams" 
mailto:dri...@gmail.com>> wrote:

  I too, use this method quite a bit, almost every single day.

  On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita 
mailto:mor.y...@gmail.com>> 
wrote:

   As an active committer, the most important thing for me is to be able
   to *look up* design discussion and decision easily later.

   I often look up the git history or CHANGES.txt for changes that I'm
   interested in, then look up JIRA by following JIRA ticket number
   written to the comment or text.
   If we move to dev mailing list, I would request to post permalink to
   that thread posted to JIRA, which I think is just one extra step that
   isn't necessary if we simply use JIRA.

   So, I'm +1 to just post JIRA link to dev list.


   On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann 
mailto:mattm...@apache.org>>
   wrote:
   This is a good outward flow of info to the dev list. However, there
   needs to be
   inward flow too – having the convo on the dev list will be a good start
   to that.
   I hope to see more inclusivity here.



   On 8/15/16, 10:26 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>> 
wrote:

  Well, if you read carefully what Jeremiah and I have just proposed,
   it wouldn’t be an issue.

  The notable major changes would start off on dev@ (think, a
   summary, a link to the JIRA, and maybe an attached spec doc).

  No need to follow the JIRA feed. Watch dev@ for those announcements
   and start watching the invidual JIRA tickets if interested.

  This creates the least amount of noise: you miss nothing important,
   and at the same time you won’t be receiving mail from
  dev@ for each individual comment - including those on proposals you
   don’t care about.

  We aren’t doing it currently, but we could, and probably should.

  --
  AY

  On 15 August 2016 at 18:22:36, Chris Mattmann 
(mattm...@apache.org)
   wrote:

  Discussion belongs on the dev list. Putting discussion in JIRA, is
   fine, but realize,
  there is a lot of noise in that signal and people may or may not be
   watching
  the JIRA list. In fact, I don’t see JIRA sent to the dev list at all
   so you are basically
  forking the conversation to a high noise list by putting it all in
   JIRA.





  On 8/15/16, 10:11 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>>
   wrote:

  I too feel like it would be sufficient to announce those major JIRAs
   on the dev@ list, but keep all discussion itself to JIRA, where it
   belongs.

  You don’t need to follow every ticket this way, just subscribe to
   dev@ and then start watching the select major JIRAs you care about.

  --
  A

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

I don’t want to put words into Jonathan’s mouth, but my guess is that he’s 
trying
to strike a balance between Apache Cassandra’s almost exclusive use of JIRA and
like nil conversation on the dev@ list, with an incremental way to *get there* 
in terms of moving the project to actually use the dev list for discussion.

This isn’t an effort to kill JIRA. JIRA is fine as a *tool*. But, it is by no 
means the
ground truth for the project. The ground truth is, always has been, and will 
continue in the future to be, the mailing list. Project decisions are made on 
the mailing list.

Normally this is an easy concept for new projects to grok as they come through
the Incubator, and as they become Apache projects. Sometimes, projects need
to be instructed that this is the case. We have seen it many times before. 
However,
there seems to be a fundamental disconnect here in Apache Cassandra between
the project being mentored in the Apache way, versus “the way you have been
doing it for so long”. Just because that’s the way it’s been going on for so 
long, 
doesn’t mean it’s the correct way here at the ASF.



On 8/15/16, 11:05 AM, "Russell Bradberry"  wrote:

So then what was the point of Ellis’s proposal, and this discussion, if 
there was never a choice in the matter in the first place?


On 8/15/16, 2:03 PM, "Chris Mattmann"  wrote:

I’m sorry but you are massively confused if you believe that the ASF 
mailing lists
aren’t the source of truth. They are. That’s not optional. If you are 
an ASF project,
mailing lists are the source of truth. Period.

On 8/15/16, 11:01 AM, "Michael Kjellman"  
wrote:

I'm a big fan of mailing lists, but google makes issues very 
findable for new people to the project as JIRA gets indexed. They won't be able 
to find the same thing on an email they didn't get -- because they weren't in 
the project in the first place.

Mailing lists are good for broad discussion or bringing specific 
issues to the attention of the broader community. It should never be the source 
of truth.

best,
kjellman

Sent from my iPhone

On Aug 15, 2016, at 2:57 PM, Chris Mattmann 
mailto:mattm...@apache.org>> wrote:

Realize it’s not just about committers and PMC members that are 
*already*
on the PMC or that are developing the project. It’s about how to 
engage the
*entire* community including those that are not yet on the 
committer or
PMC roster. That is the future (and current) lifeblood of the 
project. The mailing
list aren’t just an unfortunate necessity of being an Apache 
project. They *are*
the lifeblood of the Apache project.



On 8/15/16, 10:44 AM, "Brandon Williams" 
mailto:dri...@gmail.com>> wrote:

   I too, use this method quite a bit, almost every single day.

   On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita 
mailto:mor.y...@gmail.com>> wrote:

As an active committer, the most important thing for me is to be 
able
to *look up* design discussion and decision easily later.

I often look up the git history or CHANGES.txt for changes that I'm
interested in, then look up JIRA by following JIRA ticket number
written to the comment or text.
If we move to dev mailing list, I would request to post permalink to
that thread posted to JIRA, which I think is just one extra step 
that
isn't necessary if we simply use JIRA.

So, I'm +1 to just post JIRA link to dev list.


On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann 
mailto:mattm...@apache.org>>
wrote:
This is a good outward flow of info to the dev list. However, there
needs to be
inward flow too – having the convo on the dev list will be a good 
start
to that.
I hope to see more inclusivity here.



On 8/15/16, 10:26 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>> wrote:

   Well, if you read carefully what Jeremiah and I have just 
proposed,
it wouldn’t be an issue.

   The notable major changes would start off on dev@ (think, a
summary, a link to the JIRA, and maybe an attached spec doc).

   No need to follow the JIRA feed. Watch dev@ for those 
announcements
and start watching the invidual JIRA tickets if interested.

   This creates the least amount of noise: you miss nothing 
important,
and at the same time you won’t be receiving mail from
  

Re: A proposal to move away from Jira-centric development

[Russell Bradberry]

So then what was the point of Ellis’s proposal, and this discussion, if there 
was never a choice in the matter in the first place?


On 8/15/16, 2:03 PM, "Chris Mattmann"  wrote:

I’m sorry but you are massively confused if you believe that the ASF 
mailing lists
aren’t the source of truth. They are. That’s not optional. If you are an 
ASF project,
mailing lists are the source of truth. Period.

On 8/15/16, 11:01 AM, "Michael Kjellman"  
wrote:

I'm a big fan of mailing lists, but google makes issues very findable 
for new people to the project as JIRA gets indexed. They won't be able to find 
the same thing on an email they didn't get -- because they weren't in the 
project in the first place.

Mailing lists are good for broad discussion or bringing specific issues 
to the attention of the broader community. It should never be the source of 
truth.

best,
kjellman

Sent from my iPhone

On Aug 15, 2016, at 2:57 PM, Chris Mattmann 
mailto:mattm...@apache.org>> wrote:

Realize it’s not just about committers and PMC members that are 
*already*
on the PMC or that are developing the project. It’s about how to engage 
the
*entire* community including those that are not yet on the committer or
PMC roster. That is the future (and current) lifeblood of the project. 
The mailing
list aren’t just an unfortunate necessity of being an Apache project. 
They *are*
the lifeblood of the Apache project.



On 8/15/16, 10:44 AM, "Brandon Williams" 
mailto:dri...@gmail.com>> wrote:

   I too, use this method quite a bit, almost every single day.

   On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita 
mailto:mor.y...@gmail.com>> wrote:

As an active committer, the most important thing for me is to be able
to *look up* design discussion and decision easily later.

I often look up the git history or CHANGES.txt for changes that I'm
interested in, then look up JIRA by following JIRA ticket number
written to the comment or text.
If we move to dev mailing list, I would request to post permalink to
that thread posted to JIRA, which I think is just one extra step that
isn't necessary if we simply use JIRA.

So, I'm +1 to just post JIRA link to dev list.


On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann 
mailto:mattm...@apache.org>>
wrote:
This is a good outward flow of info to the dev list. However, there
needs to be
inward flow too – having the convo on the dev list will be a good start
to that.
I hope to see more inclusivity here.



On 8/15/16, 10:26 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>> wrote:

   Well, if you read carefully what Jeremiah and I have just proposed,
it wouldn’t be an issue.

   The notable major changes would start off on dev@ (think, a
summary, a link to the JIRA, and maybe an attached spec doc).

   No need to follow the JIRA feed. Watch dev@ for those announcements
and start watching the invidual JIRA tickets if interested.

   This creates the least amount of noise: you miss nothing important,
and at the same time you won’t be receiving mail from
   dev@ for each individual comment - including those on proposals you
don’t care about.

   We aren’t doing it currently, but we could, and probably should.

   --
   AY

   On 15 August 2016 at 18:22:36, Chris Mattmann 
(mattm...@apache.org)
wrote:

   Discussion belongs on the dev list. Putting discussion in JIRA, is
fine, but realize,
   there is a lot of noise in that signal and people may or may not be
watching
   the JIRA list. In fact, I don’t see JIRA sent to the dev list at all
so you are basically
   forking the conversation to a high noise list by putting it all in
JIRA.





   On 8/15/16, 10:11 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>>
wrote:

   I too feel like it would be sufficient to announce those major JIRAs
on the dev@ list, but keep all discussion itself to JIRA, where it
belongs.

   You don’t need to follow every ticket this way, just subscribe to
dev@ and then start watching the select major JIRAs you care about.

   --
   AY

   On 15 August 2016 at 18:08:20, Jeremiah D Jordan (
jeremiah.jor...@gmail.com) wrote:

   I like ke

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

I’m sorry but you are massively confused if you believe that the ASF mailing 
lists
aren’t the source of truth. They are. That’s not optional. If you are an ASF 
project,
mailing lists are the source of truth. Period.

On 8/15/16, 11:01 AM, "Michael Kjellman"  wrote:

I'm a big fan of mailing lists, but google makes issues very findable for 
new people to the project as JIRA gets indexed. They won't be able to find the 
same thing on an email they didn't get -- because they weren't in the project 
in the first place.

Mailing lists are good for broad discussion or bringing specific issues to 
the attention of the broader community. It should never be the source of truth.

best,
kjellman

Sent from my iPhone

On Aug 15, 2016, at 2:57 PM, Chris Mattmann 
mailto:mattm...@apache.org>> wrote:

Realize it’s not just about committers and PMC members that are *already*
on the PMC or that are developing the project. It’s about how to engage the
*entire* community including those that are not yet on the committer or
PMC roster. That is the future (and current) lifeblood of the project. The 
mailing
list aren’t just an unfortunate necessity of being an Apache project. They 
*are*
the lifeblood of the Apache project.



On 8/15/16, 10:44 AM, "Brandon Williams" 
mailto:dri...@gmail.com>> wrote:

   I too, use this method quite a bit, almost every single day.

   On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita 
mailto:mor.y...@gmail.com>> wrote:

As an active committer, the most important thing for me is to be able
to *look up* design discussion and decision easily later.

I often look up the git history or CHANGES.txt for changes that I'm
interested in, then look up JIRA by following JIRA ticket number
written to the comment or text.
If we move to dev mailing list, I would request to post permalink to
that thread posted to JIRA, which I think is just one extra step that
isn't necessary if we simply use JIRA.

So, I'm +1 to just post JIRA link to dev list.


On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann 
mailto:mattm...@apache.org>>
wrote:
This is a good outward flow of info to the dev list. However, there
needs to be
inward flow too – having the convo on the dev list will be a good start
to that.
I hope to see more inclusivity here.



On 8/15/16, 10:26 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>> wrote:

   Well, if you read carefully what Jeremiah and I have just proposed,
it wouldn’t be an issue.

   The notable major changes would start off on dev@ (think, a
summary, a link to the JIRA, and maybe an attached spec doc).

   No need to follow the JIRA feed. Watch dev@ for those announcements
and start watching the invidual JIRA tickets if interested.

   This creates the least amount of noise: you miss nothing important,
and at the same time you won’t be receiving mail from
   dev@ for each individual comment - including those on proposals you
don’t care about.

   We aren’t doing it currently, but we could, and probably should.

   --
   AY

   On 15 August 2016 at 18:22:36, Chris Mattmann 
(mattm...@apache.org)
wrote:

   Discussion belongs on the dev list. Putting discussion in JIRA, is
fine, but realize,
   there is a lot of noise in that signal and people may or may not be
watching
   the JIRA list. In fact, I don’t see JIRA sent to the dev list at all
so you are basically
   forking the conversation to a high noise list by putting it all in
JIRA.





   On 8/15/16, 10:11 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>>
wrote:

   I too feel like it would be sufficient to announce those major JIRAs
on the dev@ list, but keep all discussion itself to JIRA, where it
belongs.

   You don’t need to follow every ticket this way, just subscribe to
dev@ and then start watching the select major JIRAs you care about.

   --
   AY

   On 15 August 2016 at 18:08:20, Jeremiah D Jordan (
jeremiah.jor...@gmail.com) wrote:

   I like keeping things in JIRA because then everything is in one
place, and it is easy to refer someone to it in the future.
   But I agree that JIRA tickets with a bunch of design discussion and
POC’s and such in them can get pretty long and convoluted.

   I don’t really like the idea of moving all of that discussion to
email which makes it has harder to point someone to it. Maybe a better idea
would be to have a “design/POC” JIRA and an “implementation” JIRA. That way
we could still keep things in JIRA, but the final decision would be kept
“clean”.

   Though it would be nice i

Re: A proposal to move away from Jira-centric development

[Michael Kjellman]

I'm a big fan of mailing lists, but google makes issues very findable for new 
people to the project as JIRA gets indexed. They won't be able to find the same 
thing on an email they didn't get -- because they weren't in the project in the 
first place.

Mailing lists are good for broad discussion or bringing specific issues to the 
attention of the broader community. It should never be the source of truth.

best,
kjellman

Sent from my iPhone

On Aug 15, 2016, at 2:57 PM, Chris Mattmann 
mailto:mattm...@apache.org>> wrote:

Realize it’s not just about committers and PMC members that are *already*
on the PMC or that are developing the project. It’s about how to engage the
*entire* community including those that are not yet on the committer or
PMC roster. That is the future (and current) lifeblood of the project. The 
mailing
list aren’t just an unfortunate necessity of being an Apache project. They *are*
the lifeblood of the Apache project.



On 8/15/16, 10:44 AM, "Brandon Williams" 
mailto:dri...@gmail.com>> wrote:

   I too, use this method quite a bit, almost every single day.

   On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita 
mailto:mor.y...@gmail.com>> wrote:

As an active committer, the most important thing for me is to be able
to *look up* design discussion and decision easily later.

I often look up the git history or CHANGES.txt for changes that I'm
interested in, then look up JIRA by following JIRA ticket number
written to the comment or text.
If we move to dev mailing list, I would request to post permalink to
that thread posted to JIRA, which I think is just one extra step that
isn't necessary if we simply use JIRA.

So, I'm +1 to just post JIRA link to dev list.


On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann 
mailto:mattm...@apache.org>>
wrote:
This is a good outward flow of info to the dev list. However, there
needs to be
inward flow too – having the convo on the dev list will be a good start
to that.
I hope to see more inclusivity here.



On 8/15/16, 10:26 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>> wrote:

   Well, if you read carefully what Jeremiah and I have just proposed,
it wouldn’t be an issue.

   The notable major changes would start off on dev@ (think, a
summary, a link to the JIRA, and maybe an attached spec doc).

   No need to follow the JIRA feed. Watch dev@ for those announcements
and start watching the invidual JIRA tickets if interested.

   This creates the least amount of noise: you miss nothing important,
and at the same time you won’t be receiving mail from
   dev@ for each individual comment - including those on proposals you
don’t care about.

   We aren’t doing it currently, but we could, and probably should.

   --
   AY

   On 15 August 2016 at 18:22:36, Chris Mattmann 
(mattm...@apache.org)
wrote:

   Discussion belongs on the dev list. Putting discussion in JIRA, is
fine, but realize,
   there is a lot of noise in that signal and people may or may not be
watching
   the JIRA list. In fact, I don’t see JIRA sent to the dev list at all
so you are basically
   forking the conversation to a high noise list by putting it all in
JIRA.





   On 8/15/16, 10:11 AM, "Aleksey Yeschenko" 
mailto:alek...@apache.org>>
wrote:

   I too feel like it would be sufficient to announce those major JIRAs
on the dev@ list, but keep all discussion itself to JIRA, where it
belongs.

   You don’t need to follow every ticket this way, just subscribe to
dev@ and then start watching the select major JIRAs you care about.

   --
   AY

   On 15 August 2016 at 18:08:20, Jeremiah D Jordan (
jeremiah.jor...@gmail.com) wrote:

   I like keeping things in JIRA because then everything is in one
place, and it is easy to refer someone to it in the future.
   But I agree that JIRA tickets with a bunch of design discussion and
POC’s and such in them can get pretty long and convoluted.

   I don’t really like the idea of moving all of that discussion to
email which makes it has harder to point someone to it. Maybe a better idea
would be to have a “design/POC” JIRA and an “implementation” JIRA. That way
we could still keep things in JIRA, but the final decision would be kept
“clean”.

   Though it would be nice if people would send an email to the dev
list when proposing “design” JIRA’s, as not everyone has time to follow
every JIRA ever made to see that a new design JIRA was created that they
might be interested in participating on.

   My 2c.

   -Jeremiah


On Aug 15, 2016, at 9:22 AM, Jonathan Ellis 
mailto: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

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

Realize it’s not just about committers and PMC members that are *already* 
on the PMC or that are developing the project. It’s about how to engage the
*entire* community including those that are not yet on the committer or
PMC roster. That is the future (and current) lifeblood of the project. The 
mailing
list aren’t just an unfortunate necessity of being an Apache project. They *are*
the lifeblood of the Apache project.



On 8/15/16, 10:44 AM, "Brandon Williams"  wrote:

I too, use this method quite a bit, almost every single day.

On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita  wrote:

> As an active committer, the most important thing for me is to be able
> to *look up* design discussion and decision easily later.
>
> I often look up the git history or CHANGES.txt for changes that I'm
> interested in, then look up JIRA by following JIRA ticket number
> written to the comment or text.
> If we move to dev mailing list, I would request to post permalink to
> that thread posted to JIRA, which I think is just one extra step that
> isn't necessary if we simply use JIRA.
>
> So, I'm +1 to just post JIRA link to dev list.
>
>
> On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann 
> wrote:
> > This is a good outward flow of info to the dev list. However, there
> needs to be
> > inward flow too – having the convo on the dev list will be a good start
> to that.
> > I hope to see more inclusivity here.
> >
> >
> >
> > On 8/15/16, 10:26 AM, "Aleksey Yeschenko"  wrote:
> >
> > Well, if you read carefully what Jeremiah and I have just proposed,
> it wouldn’t be an issue.
> >
> > The notable major changes would start off on dev@ (think, a
> summary, a link to the JIRA, and maybe an attached spec doc).
> >
> > No need to follow the JIRA feed. Watch dev@ for those announcements
> and start watching the invidual JIRA tickets if interested.
> >
> > This creates the least amount of noise: you miss nothing important,
> and at the same time you won’t be receiving mail from
> > dev@ for each individual comment - including those on proposals you
> don’t care about.
> >
> > We aren’t doing it currently, but we could, and probably should.
> >
> > --
> > AY
> >
> > On 15 August 2016 at 18:22:36, Chris Mattmann (mattm...@apache.org)
> wrote:
> >
> > Discussion belongs on the dev list. Putting discussion in JIRA, is
> fine, but realize,
> > there is a lot of noise in that signal and people may or may not be
> watching
> > the JIRA list. In fact, I don’t see JIRA sent to the dev list at all
> so you are basically
> > forking the conversation to a high noise list by putting it all in
> JIRA.
> >
> >
> >
> >
> >
> > On 8/15/16, 10:11 AM, "Aleksey Yeschenko" 
> wrote:
> >
> > I too feel like it would be sufficient to announce those major JIRAs
> on the dev@ list, but keep all discussion itself to JIRA, where it
> belongs.
> >
> > You don’t need to follow every ticket this way, just subscribe to
> dev@ and then start watching the select major JIRAs you care about.
> >
> > --
> > AY
> >
> > On 15 August 2016 at 18:08:20, Jeremiah D Jordan (
> jeremiah.jor...@gmail.com) wrote:
> >
> > I like keeping things in JIRA because then everything is in one
> place, and it is easy to refer someone to it in the future.
> > But I agree that JIRA tickets with a bunch of design discussion and
> POC’s and such in them can get pretty long and convoluted.
> >
> > I don’t really like the idea of moving all of that discussion to
> email which makes it has harder to point someone to it. Maybe a better 
idea
> would be to have a “design/POC” JIRA and an “implementation” JIRA. That 
way
> we could still keep things in JIRA, but the final decision would be kept
> “clean”.
> >
> > Though it would be nice if people would send an email to the dev
> list when proposing “design” JIRA’s, as not everyone has time to follow
> every JIRA ever made to see that a new design JIRA was created that they
> might be interested in participating on.
> >
> > My 2c.
> >
> > -Jeremiah
> >
> >
> > > On Aug 15, 2016, at 9:22 AM, Jonathan Ellis 
> 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 o

Re: A proposal to move away from Jira-centric development

[Jeremy Hanna]

Jiras are a lot easier to follow as they are focused on a single item of work 
and it comes with an id that is a lot easier to reference and remember.  If 
there is a high level discussion on the list, that’s fine.  A link to that 
initial discussion can be referenced in the Jira.  As already mentioned, 
narrowing down the discussion on the list before going to a Jira seems 
reasonable.

> On Aug 15, 2016, at 12:27 PM, Jeremiah D Jordan  
> wrote:
> 
>> In fact, I don’t see JIRA sent to the dev list at all so you are basically
>> forking the conversation to a high noise list by putting it all in JIRA.
> 
> This is why I proposed we send a link to the design lira’s to the dev list.
> 
>> Putting discussion in JIRA, is fine, but realize,
>> there is a lot of noise in that signal and people may or may not be watching
> 
> I don’t see how a JIRA dedicated to a specific issue is “high noise” ?  That 
> single JIRA is much lower noise, it only has conversations around that 
> specific ticket.  All conversations happening on the dev list at once seems 
> much “higher noise” to me.
> 
> -Jeremiah
> 
>> On Aug 15, 2016, at 12:22 PM, Chris Mattmann  wrote:
>> 
>> Discussion belongs on the dev list. Putting discussion in JIRA, is fine, but 
>> realize,
>> there is a lot of noise in that signal and people may or may not be watching
>> the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so you 
>> are basically
>> forking the conversation to a high noise list by putting it all in JIRA.
>> 
>> 
>> 
>> 
>> 
>> On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:
>> 
>>   I too feel like it would be sufficient to announce those major JIRAs on 
>> the dev@ list, but keep all discussion itself to JIRA, where it belongs.
>> 
>>   You don’t need to follow every ticket this way, just subscribe to dev@ and 
>> then start watching the select major JIRAs you care about.
>> 
>>   -- 
>>   AY
>> 
>>   On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
>> (jeremiah.jor...@gmail.com) wrote:
>> 
>>   I like keeping things in JIRA because then everything is in one place, and 
>> it is easy to refer someone to it in the future.  
>>   But I agree that JIRA tickets with a bunch of design discussion and POC’s 
>> and such in them can get pretty long and convoluted.  
>> 
>>   I don’t really like the idea of moving all of that discussion to email 
>> which makes it has harder to point someone to it. Maybe a better idea would 
>> be to have a “design/POC” JIRA and an “implementation” JIRA. That way we 
>> could still keep things in JIRA, but the final decision would be kept 
>> “clean”.  
>> 
>>   Though it would be nice if people would send an email to the dev list when 
>> proposing “design” JIRA’s, as not everyone has time to follow every JIRA 
>> ever made to see that a new design JIRA was created that they might be 
>> interested in participating on.  
>> 
>>   My 2c.  
>> 
>>   -Jeremiah  
>> 
>> 
>>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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  
>> 
>> 
>> 
>> 
> 

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

It depends on the environment, right? It may not be friendly to folks who:

1. Don’t have an Apache account yet
2. Aren’t familiar with cross linking or specific terms in Apache Cassandra, or
with other JIRA issues

I have taught CS at the graduate academic level for many years, and have been at
NASA JPL for 16+ years, and I can tell you that most newcomers to software 
development
and to participating in open source tend to have trouble with SE tools and 
systems
to start with. There is a “startup cost” to do so. You reap much benefits in 
the end, but
realize that during that time you may have lost the contributor.

Famous quote from prior ASF Director Board member Henri Yandell from Amazon - 
words that I live by:

Projects begin by thinking they're in the software engineering business; after 
a while they realize they're in the recruiting business.
More committers, consensus driving, flatter committer/PMC ratios; all of these 
are tools in our #1 business of recruitment.

https://twitter.com/flamefew/statuses/36352411593351168
https://twitter.com/flamefew/statuses/36352484263858176

Some thoughts..



On 8/15/16, 10:34 AM, "Russell Bradberry"  wrote:

I would also like to add, that for posterity’s sake, JIRA is much more 
friendly.  People want to understand the reasoning behind the changes that have 
been made.  Like why did we default to G1GC?  These are all kept in the 
discussions on the JIRA tickets that implemented the features. Navigating 
through endless emails in the dev list and making sense of it is extremely 
tedious and very difficult to get the full picture around the decisions being 
made.





On 8/15/16, 1:27 PM, "Jeremiah D Jordan"  wrote:

>  In fact, I don’t see JIRA sent to the dev list at all so you are 
basically
> forking the conversation to a high noise list by putting it all in 
JIRA.

This is why I proposed we send a link to the design lira’s to the dev 
list.

> Putting discussion in JIRA, is fine, but realize,
> there is a lot of noise in that signal and people may or may not be 
watching

I don’t see how a JIRA dedicated to a specific issue is “high noise” ?  
That single JIRA is much lower noise, it only has conversations around that 
specific ticket.  All conversations happening on the dev list at once seems 
much “higher noise” to me.

-Jeremiah

> On Aug 15, 2016, at 12:22 PM, Chris Mattmann  
wrote:
> 
> Discussion belongs on the dev list. Putting discussion in JIRA, is 
fine, but realize,
> there is a lot of noise in that signal and people may or may not be 
watching
> the JIRA list. In fact, I don’t see JIRA sent to the dev list at all 
so you are basically
> forking the conversation to a high noise list by putting it all in 
JIRA.
> 
> 
> 
> 
> 
> On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:
> 
>I too feel like it would be sufficient to announce those major 
JIRAs on the dev@ list, but keep all discussion itself to JIRA, where it 
belongs.
> 
>You don’t need to follow every ticket this way, just subscribe to 
dev@ and then start watching the select major JIRAs you care about.
> 
>-- 
>AY
> 
>On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
(jeremiah.jor...@gmail.com) wrote:
> 
>I like keeping things in JIRA because then everything is in one 
place, and it is easy to refer someone to it in the future.  
>But I agree that JIRA tickets with a bunch of design discussion 
and POC’s and such in them can get pretty long and convoluted.  
> 
>I don’t really like the idea of moving all of that discussion to 
email which makes it has harder to point someone to it. Maybe a better idea 
would be to have a “design/POC” JIRA and an “implementation” JIRA. That way we 
could still keep things in JIRA, but the final decision would be kept “clean”.  
> 
>Though it would be nice if people would send an email to the dev 
list when proposing “design” JIRA’s, as not everyone has time to follow every 
JIRA ever made to see that a new design JIRA was created that they might be 
interested in participating on.  
> 
>My 2c.  
> 
>-Jeremiah  
> 
> 
>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  
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  
>>

Re: A proposal to move away from Jira-centric development

[Brandon Williams]

I too, use this method quite a bit, almost every single day.

On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita  wrote:

> As an active committer, the most important thing for me is to be able
> to *look up* design discussion and decision easily later.
>
> I often look up the git history or CHANGES.txt for changes that I'm
> interested in, then look up JIRA by following JIRA ticket number
> written to the comment or text.
> If we move to dev mailing list, I would request to post permalink to
> that thread posted to JIRA, which I think is just one extra step that
> isn't necessary if we simply use JIRA.
>
> So, I'm +1 to just post JIRA link to dev list.
>
>
> On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann 
> wrote:
> > This is a good outward flow of info to the dev list. However, there
> needs to be
> > inward flow too – having the convo on the dev list will be a good start
> to that.
> > I hope to see more inclusivity here.
> >
> >
> >
> > On 8/15/16, 10:26 AM, "Aleksey Yeschenko"  wrote:
> >
> > Well, if you read carefully what Jeremiah and I have just proposed,
> it wouldn’t be an issue.
> >
> > The notable major changes would start off on dev@ (think, a
> summary, a link to the JIRA, and maybe an attached spec doc).
> >
> > No need to follow the JIRA feed. Watch dev@ for those announcements
> and start watching the invidual JIRA tickets if interested.
> >
> > This creates the least amount of noise: you miss nothing important,
> and at the same time you won’t be receiving mail from
> > dev@ for each individual comment - including those on proposals you
> don’t care about.
> >
> > We aren’t doing it currently, but we could, and probably should.
> >
> > --
> > AY
> >
> > On 15 August 2016 at 18:22:36, Chris Mattmann (mattm...@apache.org)
> wrote:
> >
> > Discussion belongs on the dev list. Putting discussion in JIRA, is
> fine, but realize,
> > there is a lot of noise in that signal and people may or may not be
> watching
> > the JIRA list. In fact, I don’t see JIRA sent to the dev list at all
> so you are basically
> > forking the conversation to a high noise list by putting it all in
> JIRA.
> >
> >
> >
> >
> >
> > On 8/15/16, 10:11 AM, "Aleksey Yeschenko" 
> wrote:
> >
> > I too feel like it would be sufficient to announce those major JIRAs
> on the dev@ list, but keep all discussion itself to JIRA, where it
> belongs.
> >
> > You don’t need to follow every ticket this way, just subscribe to
> dev@ and then start watching the select major JIRAs you care about.
> >
> > --
> > AY
> >
> > On 15 August 2016 at 18:08:20, Jeremiah D Jordan (
> jeremiah.jor...@gmail.com) wrote:
> >
> > I like keeping things in JIRA because then everything is in one
> place, and it is easy to refer someone to it in the future.
> > But I agree that JIRA tickets with a bunch of design discussion and
> POC’s and such in them can get pretty long and convoluted.
> >
> > I don’t really like the idea of moving all of that discussion to
> email which makes it has harder to point someone to it. Maybe a better idea
> would be to have a “design/POC” JIRA and an “implementation” JIRA. That way
> we could still keep things in JIRA, but the final decision would be kept
> “clean”.
> >
> > Though it would be nice if people would send an email to the dev
> list when proposing “design” JIRA’s, as not everyone has time to follow
> every JIRA ever made to see that a new design JIRA was created that they
> might be interested in participating on.
> >
> > My 2c.
> >
> > -Jeremiah
> >
> >
> > > On Aug 15, 2016, at 9:22 AM, Jonathan Ellis 
> 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
> > 

Re: A proposal to move away from Jira-centric development

[Yuki Morishita]

As an active committer, the most important thing for me is to be able
to *look up* design discussion and decision easily later.

I often look up the git history or CHANGES.txt for changes that I'm
interested in, then look up JIRA by following JIRA ticket number
written to the comment or text.
If we move to dev mailing list, I would request to post permalink to
that thread posted to JIRA, which I think is just one extra step that
isn't necessary if we simply use JIRA.

So, I'm +1 to just post JIRA link to dev list.


On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann  wrote:
> This is a good outward flow of info to the dev list. However, there needs to 
> be
> inward flow too – having the convo on the dev list will be a good start to 
> that.
> I hope to see more inclusivity here.
>
>
>
> On 8/15/16, 10:26 AM, "Aleksey Yeschenko"  wrote:
>
> Well, if you read carefully what Jeremiah and I have just proposed, it 
> wouldn’t be an issue.
>
> The notable major changes would start off on dev@ (think, a summary, a 
> link to the JIRA, and maybe an attached spec doc).
>
> No need to follow the JIRA feed. Watch dev@ for those announcements and 
> start watching the invidual JIRA tickets if interested.
>
> This creates the least amount of noise: you miss nothing important, and 
> at the same time you won’t be receiving mail from
> dev@ for each individual comment - including those on proposals you don’t 
> care about.
>
> We aren’t doing it currently, but we could, and probably should.
>
> --
> AY
>
> On 15 August 2016 at 18:22:36, Chris Mattmann (mattm...@apache.org) wrote:
>
> Discussion belongs on the dev list. Putting discussion in JIRA, is fine, 
> but realize,
> there is a lot of noise in that signal and people may or may not be 
> watching
> the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so 
> you are basically
> forking the conversation to a high noise list by putting it all in JIRA.
>
>
>
>
>
> On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:
>
> I too feel like it would be sufficient to announce those major JIRAs on 
> the dev@ list, but keep all discussion itself to JIRA, where it belongs.
>
> You don’t need to follow every ticket this way, just subscribe to dev@ 
> and then start watching the select major JIRAs you care about.
>
> --
> AY
>
> On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
> (jeremiah.jor...@gmail.com) wrote:
>
> I like keeping things in JIRA because then everything is in one place, 
> and it is easy to refer someone to it in the future.
> But I agree that JIRA tickets with a bunch of design discussion and POC’s 
> and such in them can get pretty long and convoluted.
>
> I don’t really like the idea of moving all of that discussion to email 
> which makes it has harder to point someone to it. Maybe a better idea would 
> be to have a “design/POC” JIRA and an “implementation” JIRA. That way we 
> could still keep things in JIRA, but the final decision would be kept “clean”.
>
> Though it would be nice if people would send an email to the dev list 
> when proposing “design” JIRA’s, as not everyone has time to follow every JIRA 
> ever made to see that a new design JIRA was created that they might be 
> interested in participating on.
>
> My 2c.
>
> -Jeremiah
>
>
> > On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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
>
>
>
>
>
>
>



-- 
Yuki Morishita
 t:yukim (http://twitter.com/yukim)

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

This is a good outward flow of info to the dev list. However, there needs to be
inward flow too – having the convo on the dev list will be a good start to that.
I hope to see more inclusivity here.



On 8/15/16, 10:26 AM, "Aleksey Yeschenko"  wrote:

Well, if you read carefully what Jeremiah and I have just proposed, it 
wouldn’t be an issue.

The notable major changes would start off on dev@ (think, a summary, a link 
to the JIRA, and maybe an attached spec doc).

No need to follow the JIRA feed. Watch dev@ for those announcements and 
start watching the invidual JIRA tickets if interested.

This creates the least amount of noise: you miss nothing important, and at 
the same time you won’t be receiving mail from
dev@ for each individual comment - including those on proposals you don’t 
care about.

We aren’t doing it currently, but we could, and probably should.

-- 
AY

On 15 August 2016 at 18:22:36, Chris Mattmann (mattm...@apache.org) wrote:

Discussion belongs on the dev list. Putting discussion in JIRA, is fine, 
but realize,  
there is a lot of noise in that signal and people may or may not be 
watching  
the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so you 
are basically  
forking the conversation to a high noise list by putting it all in JIRA.  





On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:  

I too feel like it would be sufficient to announce those major JIRAs on the 
dev@ list, but keep all discussion itself to JIRA, where it belongs.  

You don’t need to follow every ticket this way, just subscribe to dev@ and 
then start watching the select major JIRAs you care about.  

--  
AY  

On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
(jeremiah.jor...@gmail.com) wrote:  

I like keeping things in JIRA because then everything is in one place, and 
it is easy to refer someone to it in the future.  
But I agree that JIRA tickets with a bunch of design discussion and POC’s 
and such in them can get pretty long and convoluted.  

I don’t really like the idea of moving all of that discussion to email 
which makes it has harder to point someone to it. Maybe a better idea would be 
to have a “design/POC” JIRA and an “implementation” JIRA. That way we could 
still keep things in JIRA, but the final decision would be kept “clean”.  

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.  

My 2c.  

-Jeremiah  


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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  

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

On 8/15/16, 10:27 AM, "Jeremiah D Jordan"  wrote:

>  In fact, I don’t see JIRA sent to the dev list at all so you are 
basically
> forking the conversation to a high noise list by putting it all in JIRA.

This is why I proposed we send a link to the design lira’s to the dev list.

Sure, except I didn’t read that mail yet. Give me more than a few minutes to 
catch up. I saw Aleksey’s email, so I replied to it.

> Putting discussion in JIRA, is fine, but realize,
> there is a lot of noise in that signal and people may or may not be 
watching

I don’t see how a JIRA dedicated to a specific issue is “high noise” ?  
That single JIRA is much lower noise, it only has conversations around that 
specific ticket.  All conversations happening on the dev list at once seems 
much “higher noise” to me.

I never said that. I said that JIRA itself has high noise around it’s signal. 
You get
an email with links at the top, and you get dates, times, and a whole 
surrounding
envelope email that you have to dig through to find the actual conversation. 
Then,
to reply to it, I’ve got to click to an external site out of my mail browser, 
then possibly
log in, and then interact there.

The point being that it’s not as straight forward as simply email. Realize, 
that you
are trying to capture the minimum viable interaction and to try and be the most
inclusive for your dev community. Having convos on the dev list is part of that.

JIRA is a great tool for what it does – but it should not be the minimum entry 
point
for a (healthy) project. Sure you can cite X, Y, Z projects that do it. In most 
cases,
I can cite eventual community issues with doing that and a lot of pain/work to 
use
it correctly.

Chris


-Jeremiah

> On Aug 15, 2016, at 12:22 PM, Chris Mattmann  wrote:
> 
> Discussion belongs on the dev list. Putting discussion in JIRA, is fine, 
but realize,
> there is a lot of noise in that signal and people may or may not be 
watching
> the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so 
you are basically
> forking the conversation to a high noise list by putting it all in JIRA.
> 
> 
> 
> 
> 
> On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:
> 
>I too feel like it would be sufficient to announce those major JIRAs 
on the dev@ list, but keep all discussion itself to JIRA, where it belongs.
> 
>You don’t need to follow every ticket this way, just subscribe to dev@ 
and then start watching the select major JIRAs you care about.
> 
>-- 
>AY
> 
>On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
(jeremiah.jor...@gmail.com) wrote:
> 
>I like keeping things in JIRA because then everything is in one place, 
and it is easy to refer someone to it in the future.  
>But I agree that JIRA tickets with a bunch of design discussion and 
POC’s and such in them can get pretty long and convoluted.  
> 
>I don’t really like the idea of moving all of that discussion to email 
which makes it has harder to point someone to it. Maybe a better idea would be 
to have a “design/POC” JIRA and an “implementation” JIRA. That way we could 
still keep things in JIRA, but the final decision would be kept “clean”.  
> 
>Though it would be nice if people would send an email to the dev list 
when proposing “design” JIRA’s, as not everyone has time to follow every JIRA 
ever made to see that a new design JIRA was created that they might be 
interested in participating on.  
> 
>My 2c.  
> 
>-Jeremiah  
> 
> 
>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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.data

Re: A proposal to move away from Jira-centric development

[Russell Bradberry]

I would also like to add, that for posterity’s sake, JIRA is much more 
friendly.  People want to understand the reasoning behind the changes that have 
been made.  Like why did we default to G1GC?  These are all kept in the 
discussions on the JIRA tickets that implemented the features. Navigating 
through endless emails in the dev list and making sense of it is extremely 
tedious and very difficult to get the full picture around the decisions being 
made.





On 8/15/16, 1:27 PM, "Jeremiah D Jordan"  wrote:

>  In fact, I don’t see JIRA sent to the dev list at all so you are 
basically
> forking the conversation to a high noise list by putting it all in JIRA.

This is why I proposed we send a link to the design lira’s to the dev list.

> Putting discussion in JIRA, is fine, but realize,
> there is a lot of noise in that signal and people may or may not be 
watching

I don’t see how a JIRA dedicated to a specific issue is “high noise” ?  
That single JIRA is much lower noise, it only has conversations around that 
specific ticket.  All conversations happening on the dev list at once seems 
much “higher noise” to me.

-Jeremiah

> On Aug 15, 2016, at 12:22 PM, Chris Mattmann  wrote:
> 
> Discussion belongs on the dev list. Putting discussion in JIRA, is fine, 
but realize,
> there is a lot of noise in that signal and people may or may not be 
watching
> the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so 
you are basically
> forking the conversation to a high noise list by putting it all in JIRA.
> 
> 
> 
> 
> 
> On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:
> 
>I too feel like it would be sufficient to announce those major JIRAs 
on the dev@ list, but keep all discussion itself to JIRA, where it belongs.
> 
>You don’t need to follow every ticket this way, just subscribe to dev@ 
and then start watching the select major JIRAs you care about.
> 
>-- 
>AY
> 
>On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
(jeremiah.jor...@gmail.com) wrote:
> 
>I like keeping things in JIRA because then everything is in one place, 
and it is easy to refer someone to it in the future.  
>But I agree that JIRA tickets with a bunch of design discussion and 
POC’s and such in them can get pretty long and convoluted.  
> 
>I don’t really like the idea of moving all of that discussion to email 
which makes it has harder to point someone to it. Maybe a better idea would be 
to have a “design/POC” JIRA and an “implementation” JIRA. That way we could 
still keep things in JIRA, but the final decision would be kept “clean”.  
> 
>Though it would be nice if people would send an email to the dev list 
when proposing “design” JIRA’s, as not everyone has time to follow every JIRA 
ever made to see that a new design JIRA was created that they might be 
interested in participating on.  
> 
>My 2c.  
> 
>-Jeremiah  
> 
> 
>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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  
> 
> 
> 
> 

Re: A proposal to move away from Jira-centric development

[Jeremiah D Jordan]

>  In fact, I don’t see JIRA sent to the dev list at all so you are basically
> forking the conversation to a high noise list by putting it all in JIRA.

This is why I proposed we send a link to the design lira’s to the dev list.

> Putting discussion in JIRA, is fine, but realize,
> there is a lot of noise in that signal and people may or may not be watching

I don’t see how a JIRA dedicated to a specific issue is “high noise” ?  That 
single JIRA is much lower noise, it only has conversations around that specific 
ticket.  All conversations happening on the dev list at once seems much “higher 
noise” to me.

-Jeremiah

> On Aug 15, 2016, at 12:22 PM, Chris Mattmann  wrote:
> 
> Discussion belongs on the dev list. Putting discussion in JIRA, is fine, but 
> realize,
> there is a lot of noise in that signal and people may or may not be watching
> the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so you 
> are basically
> forking the conversation to a high noise list by putting it all in JIRA.
> 
> 
> 
> 
> 
> On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:
> 
>I too feel like it would be sufficient to announce those major JIRAs on 
> the dev@ list, but keep all discussion itself to JIRA, where it belongs.
> 
>You don’t need to follow every ticket this way, just subscribe to dev@ and 
> then start watching the select major JIRAs you care about.
> 
>-- 
>AY
> 
>On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
> (jeremiah.jor...@gmail.com) wrote:
> 
>I like keeping things in JIRA because then everything is in one place, and 
> it is easy to refer someone to it in the future.  
>But I agree that JIRA tickets with a bunch of design discussion and POC’s 
> and such in them can get pretty long and convoluted.  
> 
>I don’t really like the idea of moving all of that discussion to email 
> which makes it has harder to point someone to it. Maybe a better idea would 
> be to have a “design/POC” JIRA and an “implementation” JIRA. That way we 
> could still keep things in JIRA, but the final decision would be kept 
> “clean”.  
> 
>Though it would be nice if people would send an email to the dev list when 
> proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
> made to see that a new design JIRA was created that they might be interested 
> in participating on.  
> 
>My 2c.  
> 
>-Jeremiah  
> 
> 
>> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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  
> 
> 
> 
> 

Re: A proposal to move away from Jira-centric development

[Aleksey Yeschenko]

Well, if you read carefully what Jeremiah and I have just proposed, it wouldn’t 
be an issue.

The notable major changes would start off on dev@ (think, a summary, a link to 
the JIRA, and maybe an attached spec doc).

No need to follow the JIRA feed. Watch dev@ for those announcements and start 
watching the invidual JIRA tickets if interested.

This creates the least amount of noise: you miss nothing important, and at the 
same time you won’t be receiving mail from
dev@ for each individual comment - including those on proposals you don’t care 
about.

We aren’t doing it currently, but we could, and probably should.

-- 
AY

On 15 August 2016 at 18:22:36, Chris Mattmann (mattm...@apache.org) wrote:

Discussion belongs on the dev list. Putting discussion in JIRA, is fine, but 
realize,  
there is a lot of noise in that signal and people may or may not be watching  
the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so you are 
basically  
forking the conversation to a high noise list by putting it all in JIRA.  





On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:  

I too feel like it would be sufficient to announce those major JIRAs on the 
dev@ list, but keep all discussion itself to JIRA, where it belongs.  

You don’t need to follow every ticket this way, just subscribe to dev@ and then 
start watching the select major JIRAs you care about.  

--  
AY  

On 15 August 2016 at 18:08:20, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:  

I like keeping things in JIRA because then everything is in one place, and it 
is easy to refer someone to it in the future.  
But I agree that JIRA tickets with a bunch of design discussion and POC’s and 
such in them can get pretty long and convoluted.  

I don’t really like the idea of moving all of that discussion to email which 
makes it has harder to point someone to it. Maybe a better idea would be to 
have a “design/POC” JIRA and an “implementation” JIRA. That way we could still 
keep things in JIRA, but the final decision would be kept “clean”.  

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.  

My 2c.  

-Jeremiah  


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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  

Re: A proposal to move away from Jira-centric development

[Chris Mattmann]

Discussion belongs on the dev list. Putting discussion in JIRA, is fine, but 
realize,
there is a lot of noise in that signal and people may or may not be watching
the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so you are 
basically
forking the conversation to a high noise list by putting it all in JIRA.





On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:

I too feel like it would be sufficient to announce those major JIRAs on the 
dev@ list, but keep all discussion itself to JIRA, where it belongs.

You don’t need to follow every ticket this way, just subscribe to dev@ and 
then start watching the select major JIRAs you care about.

-- 
AY

On 15 August 2016 at 18:08:20, Jeremiah D Jordan 
(jeremiah.jor...@gmail.com) wrote:

I like keeping things in JIRA because then everything is in one place, and 
it is easy to refer someone to it in the future.  
But I agree that JIRA tickets with a bunch of design discussion and POC’s 
and such in them can get pretty long and convoluted.  

I don’t really like the idea of moving all of that discussion to email 
which makes it has harder to point someone to it. Maybe a better idea would be 
to have a “design/POC” JIRA and an “implementation” JIRA. That way we could 
still keep things in JIRA, but the final decision would be kept “clean”.  

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.  

My 2c.  

-Jeremiah  


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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  

Re: A proposal to move away from Jira-centric development

[sankalp kohli]

+1
We should do this for large contributions. Also we should link the dev
discussion thread in the JIRA for reference.

On Mon, Aug 15, 2016 at 10:08 AM, Jeremiah D Jordan <
jeremiah.jor...@gmail.com> wrote:

> I like keeping things in JIRA because then everything is in one place, and
> it is easy to refer someone to it in the future.
> But I agree that JIRA tickets with a bunch of design discussion and POC’s
> and such in them can get pretty long and convoluted.
>
> I don’t really like the idea of moving all of that discussion to email
> which makes it has harder to point someone to it.  Maybe a better idea
> would be to have a “design/POC” JIRA and an “implementation” JIRA.  That
> way we could still keep things in JIRA, but the final decision would be
> kept “clean”.
>
> Though it would be nice if people would send an email to the dev list when
> proposing “design” JIRA’s, as not everyone has time to follow every JIRA
> ever made to see that a new design JIRA was created that they might be
> interested in participating on.
>
> My 2c.
>
> -Jeremiah
>
>
> > On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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
>
>

Re: A proposal to move away from Jira-centric development

[Aleksey Yeschenko]

I too feel like it would be sufficient to announce those major JIRAs on the 
dev@ list, but keep all discussion itself to JIRA, where it belongs.

You don’t need to follow every ticket this way, just subscribe to dev@ and then 
start watching the select major JIRAs you care about.

-- 
AY

On 15 August 2016 at 18:08:20, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

I like keeping things in JIRA because then everything is in one place, and it 
is easy to refer someone to it in the future.  
But I agree that JIRA tickets with a bunch of design discussion and POC’s and 
such in them can get pretty long and convoluted.  

I don’t really like the idea of moving all of that discussion to email which 
makes it has harder to point someone to it. Maybe a better idea would be to 
have a “design/POC” JIRA and an “implementation” JIRA. That way we could still 
keep things in JIRA, but the final decision would be kept “clean”.  

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.  

My 2c.  

-Jeremiah  


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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  

Re: A proposal to move away from Jira-centric development

[Jeremiah D Jordan]

I like keeping things in JIRA because then everything is in one place, and it 
is easy to refer someone to it in the future.
But I agree that JIRA tickets with a bunch of design discussion and POC’s and 
such in them can get pretty long and convoluted.

I don’t really like the idea of moving all of that discussion to email which 
makes it has harder to point someone to it.  Maybe a better idea would be to 
have a “design/POC” JIRA and an “implementation” JIRA.  That way we could still 
keep things in JIRA, but the final decision would be kept “clean”.

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.

My 2c.

-Jeremiah


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  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

Re: A proposal to move away from Jira-centric development

[Jonathan Haddad]

(non binding) +1

On Mon, Aug 15, 2016 at 7:23 AM Jonathan Ellis  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
>