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