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 <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 <javascript:;> > 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 > <javascript:;>> 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 > <javascript:;>> 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:;> > >> <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:;> > >> <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:;> > >> <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:;> > >> <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 > >
