> 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 <https://lists.apache.org/list.html?comm...@cassandra.apache.org> > On Aug 15, 2016, at 2:06 PM, Dave Lester <dave_les...@apple.com> 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 > > <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 > <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 <jasedbr...@gmail.com> 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 <mattm...@apache.org> wrote: >> >>> s/dev list followers/<your community>/ >>> >>> 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" <jeremy.hanna1...@gmail.com >>> <javascript:;>> 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 <mattm...@apache.org >>> <javascript:;>> 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" <jeremiah.jor...@gmail.com >>> <javascript:;>> 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 <jbel...@gmail.com >>> <javascript:;>> 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 >
