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" <rbradbe...@gmail.com> 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" <jeremiah.jor...@gmail.com> 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 <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" <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 <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 > > > >
