1: A 2: +1 3: +1 4: +1 5: +0 6: +1 On the question of keeping the contributors-only restriction on moving from Triage->Open, I tend to agree with Benedict that a low barrier can be useful in deterring bogus transitions (accidental or malicious) which keeps the general noise down. I’m thinking of the current situation where tickets are routinely marked "Ready To Commit” and which contributors have to spend time/energy watching for and fixing. That said, that only requires hitting a button not potentially filling out a bunch of fields so maybe we can afford to be permissive in the first instance here and tighten things up if it becomes a problem.
> On 6 Dec 2018, at 08:16, Sylvain Lebresne <lebre...@gmail.com> wrote: > > Not much to add really, but just to close the loop, responses inline. > > On Wed, Dec 5, 2018 at 11:58 AM Benedict Elliott Smith <bened...@apache.org > <mailto:bened...@apache.org>> > wrote: > >> Thanks for the feedback and further questions. I’m sure there will be >> more, particularly around permissions and roles, so it’s good to get some >> of these other discussions moving. >> >> No doubt we’ll do a second poll once the first one concludes. Please, >> everyone, keep your first poll answers coming! >> >>> On 5 Dec 2018, at 09:50, Sylvain Lebresne <lebre...@gmail.com> wrote: >>> >>> Thanks for all those that contributed to the proposal, and specifically >> to >>> Benedict for leading the discussion. >>> >>> On the general proposal, I suspect there is a few details we may have to >>> tweak going forward, but hard to be sure before trying and as I do think >>> it's progress, I'm personally happy to move forward with this. But for >> the >>> sake of discussions, a minor remarks that I don't think have been >> mentioned >>> above: >>> - at least the platform and feature fields will be moving targets (the >>> features hopefully more so than the platform, but new java version gets >>> release regularly for instance). Do we know technically if we can get >> those >>> easily updated without requiring an infra JIRA ticket? >> >> This is actually a really good question. I had assumed this would be >> treated much like Component, Version, etc >> >> However, I was wrong: >> >> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311 >> < >> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311 >>> >> >> There are some possible workarounds, but none of them seem great. There’s >> a plugin, but not sure if Infra would be OK with this: >> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview >> < >> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview >>> >> >> This is potentially a real blocker for these two fields. >> >> So, for feature an alternative is to merge Feature/[Feature] into >> Component. This would implicitly make it non-mandatory, however. This >> could potentially be fixed with a custom field validator, but this might >> need a plugin. >> >> For Platform, I don’t have a good alternative idea right now. This is >> something that is best curated, but definitely needs to be easily updated. >> > > That's what I feared, and that sucks. And I'm coming short as well of a > good alternative that don't require plugins. > That said, if push comes to shove, if we just make them free-form but > mandatory to get out of triage (with "all" and "none" being explicitly ok > values), and have a bit of documentation, there is still a good change > we'll get meaningful information out of this. Better than what we have at > least. > > >>> - I'd personally probably remove the condition of being "jira >> contributor" >>> to move tickets out of triage. Being a "jira contributor" is a pretty >>> arbitrary in practice. Anyone that ever asked has been added, no question >>> asked, but it can actually be annoying to get added if no-one that knows >>> how to do it is around. So if, as I assume, the goal is to ensure that >>> fields are properly fielded, I don't think it will help much, and so I >>> suspect it would just be an annoyance to new, not-yet-"jira contributor" >>> users that are willing to fill all the required fields seriously (but >> will >>> see their ticket stuck in triage until they either get added, or some >> other >>> random user flip the switch). And why assume people will mis-field >> stuffs? >>> So I'd vote for just letting anyone transition out of triage as long as >> all >>> required field are there. Side-note: fwiw, I'd very much be in favor of >>> removing the "jira contributor" concept for the reasons exposed above: I >>> never felt it was anything else than an hindrance. >> >> I realise we have no real barrier to becoming a contributor, and that many >> of these permissions are going to have limited impact. But I think a >> really easy to jump gate can still be helpful, and I don’t recall >> contributors overstepping their role. But this isn’t a critical point, and >> it would be great to hear other’s opinions. >> > > Yeah, curious to see how other feel. That said, to be clear, I'm not really > feeling any strong on this. I'd just prefer trusting people by default to > do the right thing, especially when the "JIRA contributor" barrier is so > low/largely meaningless, and save ourselves the trouble of having to add > people to the "JIRA contributor" list (which, unless something changed, is > a tiny bit annoying). Knowing that we can always change the rule to be > stricter if people get it wrong too often. But anyway, not super important, > just a minor preference of mine. > > >>> - Once we have 'complexity' and 'severity', I'm not entirely sure what >>> 'priority' really means in a voluntary-based project? Is it the >> gut-feeling >>> for how useful the ticket is of whomever triage the ticket? If that, >>> outside of not being convinced of the value, I'd argue that 1) it doesn't >>> make sense for bugs and 2) it's sufficiently imprecise that it's imo >> worth >>> keeping it simple, something like low/normal/high ought to be enough. If >>> it's not that, then what is it, cause it's genuinely not immediately >>> obvious to me? >> >> Well, if nothing else Priority is the thing I sort my outstanding work by, >> and for this reason I have a preference for it being present for all ticket >> types. But I do see your point. >> >> In particular, Urgent probably is something we’re only likely to use for >> critical bugs. It’s possible we could even automatically populate this for >> a Bug type, and potentially not show this option for non-bugs. But I >> suspect we would need something like the ScriptRunner plugin for this. >> >> In my view Priority is essentially Low or Normal (or Urgent if critical >> bug) on initial filing. But a High priority can be set by a contributor >> who particularly values the ticket, for their own work prioritisation. >> Wish is a priority to make room for the Wish ticket type we are removing, >> and for those occasional requests that come in that have no realistic >> timeline for being addressed. >> > > Fair enough. I really don't mind keeping priority as long as we make clear > what it means (and don't mean). > > >> >>> >>> And with that, my poll results: >>> 1:A >>> 2:+1 >>> 3:+1 >>> 4:Don't mind >>> 5:Don't mind >>> -- >>> Sylvain >>> >>> >>> On Tue, Dec 4, 2018 at 8:12 PM Benedict Elliott Smith < >> bened...@apache.org> >>> wrote: >>> >>>> Ok, so after an initial flurry everyone has lost interest :) >>>> >>>> I think we should take a quick poll (not a vote), on people’s positions >> on >>>> the questions raised so far. If people could try to take the time to >> stake >>>> a +1/-1, or A/B, for each item, that would be really great. This poll >> will >>>> not be the end of discussions, but will (hopefully) at least draw a line >>>> under the current open questions. >>>> >>>> I will start with some verbiage, then summarise with options for >> everyone >>>> to respond to. You can scroll to the summary immediately if you like. >>>> >>>> - 1. Component: Multi-select or Cascading-select (i.e. only one >> component >>>> possible per ticket, but neater UX) >>>> - 2. Labels: rather than litigate people’s positions, I propose we do >> the >>>> least controversial thing, which is to simply leave labels intact, and >> only >>>> supplement them with the new schema information. We can later revisit >> if >>>> we decide it’s getting messy. >>>> - 3. "First review completed; second review ongoing": I don’t think we >>>> need to complicate the process; if there are two reviews in flight, the >>>> first reviewer can simply comment that they are done when ready, and the >>>> second reviewer can move the status once they are done. If the first >>>> reviewer wants substantive changes, they can move the status to "Change >>>> Request” before the other reviewer completes, if they like. Everyone >>>> involved can probably negotiate this fairly well, but we can introduce >> some >>>> specific guidance on how to conduct yourself here in a follow-up. >>>> - 4. Priorities: Option A: Wish, Low, Normal, High, Urgent; Option B: >>>> Wish, Low, Normal, Urgent >>>> - 5. Mandatory Platform and Feature. Make mandatory by introducing new >>>> “All” and “None” (respectively) options, so always possible to select an >>>> option. >>>> - 6. Environment field: Remove? >>>> >>>> I think this captures everything that has been brought up so far, except >>>> for the suggestion to make "Since Version” a “Version” - but that needs >>>> more discussion, as I don’t think there’s a clear alternative proposal >> yet. >>>> >>>> Summary: >>>> >>>> 1: Component. (A) Multi-select; (B) Cascading-select >>>> 2: Labels: leave alone +1/-1 >>>> 3: No workflow changes for first/second review: +1/-1 >>>> 4: Priorities: Including High +1/-1 >>>> 5: Mandatory Platform and Feature: +1/-1 >>>> 6: Remove Environment field: +1/-1 >>>> >>>> I will begin. >>>> >>>> 1: A >>>> 2: +1 >>>> 3: +1 >>>> 4: +1 >>>> 5: Don’t mind >>>> 6: +1 >>>> >>>> >>>> >>>> >>>>> On 29 Nov 2018, at 22:04, Scott Andreas <sc...@paradoxica.net> wrote: >>>>> >>>>> If I read Josh’s reply right, I think the suggestion is to periodically >>>> review active labels and promote those that are demonstrably useful to >>>> components (cf. folksonomy -> taxonomy< >>>> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I >>>> hadn’t read the reply as indicating that labels should be zero’d out >>>> periodically. In any case, I agree that reviewing active labels and >>>> re-evaluating our taxonomy from time to time sounds great; I don’t think >>>> I’d zero them, though. >>>>> >>>>> Responding to a few comments: >>>>> >>>>> ––– >>>>> >>>>> – To Joey’s question about issues languishing in Triage: I like the >> idea >>>> of an SLO for the “triage” state. I am happy to commit time and >> resources >>>> to triaging newly-reported issues, and to JIRA pruning/gardening in >>>> general. I spent part of the weekend before last adding components to a >> few >>>> hundred open issues and preparing the Confluence reports mentioned in >> the >>>> other thread. It was calming. We can also figure out how to rotate / >> share >>>> this responsibility. >>>>> >>>>> – Labels discussion: If we adopt a more structured component hierarchy >>>> to treat as our primary method of organization, keep labels around for >>>> people to use as they’d like (e.g., for custom JQL queries useful to >> their >>>> workflows), and periodically promote those that are widely useful, I >> think >>>> that sounds like a fine outcome. >>>>> >>>>> – On Sankalp’s question of issue reporter / new contributor burden: I >>>> actually think the pruning of fields on the “new issue form” makes >>>> reporting issues easier and ensures that information we need is >> captured. >>>> Having the triage step will also provide a nice task queue for screening >>>> bugs, and ensures a contributor’s taken a look + screened appropriately >>>> (rather than support requests immediately being marked >> “Critical/Blocker” >>>> and assigned a fix version by the reporter). >>>>> >>>>> – On Sankalp’s question of the non-committer’s workflow during first >>>> pass of review, I think that’s covered here: >>>> >> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow >>>>> >>>>> ––– >>>>> >>>>> I also want to step back and thank Benedict and Kurt for all of their >>>> analysis and information architecture work behind this proposal. >> "Workflow >>>> and bug tracker hygiene” can be a thankless endeavor; I want to make >> sure >>>> this one’s not. Thank you both! >>>>> >>>>> If we’re nearing consensus on “keeping labels, and considering them for >>>> promotion to components periodically,” are there other items we need to >>>> resolve before we generally feel good about the changes? >>>>> >>>>> – Scott >>>>> >>>>> >>>>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith ( >>>> bened...@apache.org<mailto:bened...@apache.org>) wrote: >>>>> >>>>> Hmm. On re-reading your earlier email, I realise I may have anyway >>>> gotten confused about your suggestion. >>>>> >>>>> Are you suggesting we periodically clear any new labels, once we have >>>> replacements, and only leave the old ones that exist today and haven’t >> been >>>> categorised? >>>>> >>>>> >>>>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith <bened...@apache.org >>> >>>> wrote: >>>>>> >>>>>> Do we maintain a list of prior rejects? Revisit any that have >> increased >>>> in usage since last? >>>>>> >>>>>> Probably we’re bike shedding this one thing too closely. I would be >>>> happy with removing it, periodically cleaning it, or leaving it intact. >>>> Mining it for schema changes, or telling people to ask. >>>>>> >>>>>> But I fear it will all begin to go to pot again after this effort >>>> wanes, and my life has only one JIRA cleanup effort to call upon. >>>>>> >>>>>> >>>>>>> On 26 Nov 2018, at 18:24, Joshua McKenzie <jmcken...@apache.org> >>>> wrote: >>>>>>> >>>>>>> I'm thinking something like "Every 6 months, we query on labels with >>>> count >>>>>>>> = 4 and consider promoting those. Anything < that only shows if >>>> people are >>>>>>> specifically looking for it." >>>>>>> >>>>>>> Taking count of occurrence of a label as a proxy for the potential >>>> value in >>>>>>> promoting it to something hardened isn't without flaws, but it's also >>>> not >>>>>>> awful IMO. >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith < >>>> bened...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>>> Is there harm in leaving them in, aside from psychologically to all >>>> of us >>>>>>>>> knowing they're there? =/ >>>>>>>> >>>>>>>> It would at least make it easier to triage the ‘new' ones and >> promote >>>>>>>> them. The pain of actually categorising the labels was high, and >> doing >>>>>>>> that every time would mean it never happens (though maybe there are >>>> ways to >>>>>>>> work around this). I also think there’s value in shedding noisy >> data, >>>> in >>>>>>>> an active process to promote good hygiene. >>>>>>>> >>>>>>>> But who said our state of mind isn’t also important :) >>>>>>>> >>>>>>>> This isn’t something I’ll fight hard for, though, I can see it’s at >>>> least >>>>>>>> partially a preference for cleanliness. Interested to see what >> others >>>>>>>> think. >>>>>>>> >>>>>>>>> On 26 Nov 2018, at 17:28, Joshua McKenzie <jmcken...@apache.org> >>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> An alternative route might be to support labels, and (e.g.) >>>> bi-annually >>>>>>>>>> promote any useful ones to the schema, and clear the rest? >>>>>>>>> >>>>>>>>> +1 to promoting, probably should case-by-case the clearing (but >>>> mostly >>>>>>>> just >>>>>>>>> clear) >>>>>>>>> >>>>>>>>> The present labels are much too painful to clean up. I categorised >>>> the >>>>>>>> top >>>>>>>>>> 100 or so, and will migrate them (there’s a CSV embedded in the >>>> proposal >>>>>>>>>> you can look at). The rest have < 5 occurrences, so I cannot see >>>> what >>>>>>>>>> value they really provide us. >>>>>>>>> >>>>>>>>> Is there harm in leaving them in, aside from psychologically to all >>>> of us >>>>>>>>> knowing they're there? =/ >>>>>>>>> >>>>>>>>> I _think_ several of your concerns are addressed by the new Triage >>>> state. >>>>>>>>>> The idea is for users to create a ticket without any field >>>> requirements. >>>>>>>>>> Contributors should liaise with the user to understand the >> problem, >>>> and >>>>>>>>>> transition it to Open. >>>>>>>>> >>>>>>>>> Shit, my bad, totally missed / didn't grok that. That makes a lot >>>> more >>>>>>>>> sense. >>>>>>>>> >>>>>>>>> On Mon, Nov 26, 2018 at 11:58 AM Benedict Elliott Smith < >>>>>>>> bened...@apache.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry, I failed to respond to point (2) in the aggregate email. >>>>>>>>>> >>>>>>>>>> I’m not sure it’s worth complicating the flow for this scenario, >> as >>>> the >>>>>>>>>> ticket can simply return to ‘Patch Available’. But, I’m really >>>> unsure >>>>>>>> of >>>>>>>>>> the best option here. Does anyone else have any strong opinions / >>>>>>>> thoughts? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 26 Nov 2018, at 14:33, Sankalp Kohli <kohlisank...@gmail.com> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I have following initial comments on the proposal. >>>>>>>>>>> 1. Creating a JIRA should have few fields mandatory like >> platform, >>>>>>>>>> version, etc. We want to put less burden on someone creating a >>>> ticket >>>>>>>> but I >>>>>>>>>> feel these are required for opening bugs. >>>>>>>>>>> >>>>>>>>>>> 2. What is the flow when a non committer does the first pass of >>>> review? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie < >>>> jmcken...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 1) Removal of labels: one of the strengths of the current model >> is >>>>>>>>>>>> flexibility for groupings of concepts to arise from a >>>> user-perspective >>>>>>>>>>>> (lhf, etc). Calcifying the label concepts into components, >>>> categories, >>>>>>>>>> etc. >>>>>>>>>>>> is a strict loss of functionality for users to express and >>>> categorize >>>>>>>>>> their >>>>>>>>>>>> concerns with the project. This feels like an over-correction to >>>> our >>>>>>>>>>>> current lack of discipline cleaning up one-off labels. >>>>>>>> Counter-proposal: >>>>>>>>>>>> >>>>>>>>>>>> 1. We beef up the categories and components as proposed and >>>> migrate >>>>>>>>>>>> labels to those >>>>>>>>>>>> 2. We remove the one-off labels that aren't adding value, >>>> considering >>>>>>>>>>>> aggregating similar labels >>>>>>>>>>>> 3. We leave the "labels" field intact, perhaps with a bit of >>>> guidance >>>>>>>>>> on >>>>>>>>>>>> how to effectively use it >>>>>>>>>>>> >>>>>>>>>>>> 2) Required fields on transition: assuming these are required >> upon >>>>>>>>>> *issue >>>>>>>>>>>> creation*, that's placing a significant burden on a user that's >>>> seen >>>>>>>>>>>> something and wants to open a ticket about it, but isn't sure if >>>> it's >>>>>>>> a >>>>>>>>>>>> "Semantic Failure" or a "Consistency Failure", for instance. If >>>> this >>>>>>>> is, >>>>>>>>>>>> instead, a field required for transition to other ticket states >>>> by the >>>>>>>>>>>> developer working on it, I think that makes sense. >>>>>>>>>>>> >>>>>>>>>>>> 3) Priority Changes: to be blunt, this looks like shuffling >>>> chairs on >>>>>>>>>> the >>>>>>>>>>>> deck of the titanic on this one - in my experience, most users >>>> aren't >>>>>>>>>> going >>>>>>>>>>>> to set the priority on tickets when they open them (hence >> default >>>> == >>>>>>>>>> major >>>>>>>>>>>> and most tickets are opened as major), so this is something that >>>> will >>>>>>>> be >>>>>>>>>>>> either a) left alone so as not to offend those for whom the >>>> priority >>>>>>>> is >>>>>>>>>>>> *actually* major or consistent with the default, or b) changed >> by >>>> the >>>>>>>>>> dev >>>>>>>>>>>> anyway and the added signal from a new "High vs. Urgent" >>>> distinction >>>>>>>> and >>>>>>>>>>>> communication of developer intent to engage with a ticket is >>>> something >>>>>>>>>>>> that'll be lost on most users that are just reporting >> something. I >>>>>>>> don't >>>>>>>>>>>> have a meaningful counter-proposal at this point as the current >>>>>>>> problem >>>>>>>>>> is >>>>>>>>>>>> more about UX on this field than the signal / noise on the field >>>>>>>> itself >>>>>>>>>> IMO. >>>>>>>>>>>> >>>>>>>>>>>> A meta question about the "What and Why" of what we're trying to >>>>>>>>>> accomplish >>>>>>>>>>>> here: it sounds like what you're looking at is: >>>>>>>>>>>> >>>>>>>>>>>> 1. to capture more information >>>>>>>>>>>> 2. simplify the data entry >>>>>>>>>>>> 3. nudge people towards more complete and accurate data entry >>>>>>>>>>>> 4. our ability as a project to measure release quality over time >>>> and >>>>>>>>>>>> identify when Cassandra is ready for (or due a) release. >>>>>>>>>>>> >>>>>>>>>>>> The proposal in its current form makes certain strong inroads in >>>> all >>>>>>>> of >>>>>>>>>>>> those 4 metrics, but I think the major thing missing is the UX >> of >>>> what >>>>>>>>>>>> we're thinking about changing: >>>>>>>>>>>> >>>>>>>>>>>> 1. Making it easy for / reduce friction for users to report bugs >>>> and >>>>>>>>>>>> requests into the project JIRA (easy to do things right, hard to >>>> do >>>>>>>>>> things >>>>>>>>>>>> wrong) (current proposal is a +1 on "do things right", though >> I'd >>>>>>>> argue >>>>>>>>>>>> against it being *easy*) >>>>>>>>>>>> 2. Asking from the users what they can provide about their >>>> experience >>>>>>>>>>>> and issues and no more >>>>>>>>>>>> >>>>>>>>>>>> Philosophically, are we trying to make it easier for people that >>>> are >>>>>>>>>> paid >>>>>>>>>>>> FT to work on C*, are we trying to make things easier for >> *users* >>>> of >>>>>>>> C*, >>>>>>>>>>>> both, neither? Who are we targeting here w/these project changes >>>> and >>>>>>>>>> what >>>>>>>>>>>> of their issues / problems are we trying to improve? >>>>>>>>>>>> >>>>>>>>>>>> And lastly: the TLC and management of the JIRA aspects of this >>>> project >>>>>>>>>> have >>>>>>>>>>>> *definitely* languished (not pointing any fingers here, I'm *at >>>> least* >>>>>>>>>> as >>>>>>>>>>>> guilty as anyone on this :) ) - so a big thanks to you and >>>> whomever >>>>>>>>>> you've >>>>>>>>>>>> collaborate with in getting this conversation started! >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith < >>>>>>>>>> bened...@apache.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> We’ve concluded our efforts to produce a proposal for changes >> to >>>> the >>>>>>>>>> JIRA >>>>>>>>>>>>> workflow, and they can be found here: >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>> >> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals >>>>>>>>>>>>> < >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>> >> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I hope there will be broad consensus, but I’m sure it won’t be >>>> plain >>>>>>>>>>>>> sailing. It would be great to get a discussion going around the >>>>>>>>>> proposal, >>>>>>>>>>>>> so please take some time to read and respond if you think >> you’ll >>>>>>>> have a >>>>>>>>>>>>> strong opinion on this topic. >>>>>>>>>>>>> >>>>>>>>>>>>> There remains an undecided question in our initial proposal, >>>> that is >>>>>>>>>>>>> highlighted in the wiki. Specifically, there was no seemingly >>>>>>>>>> objective >>>>>>>>>>>>> winner for the suggested changes to Component (though I have a >>>>>>>>>> preference, >>>>>>>>>>>>> that I will express in the ensuing discussion). >>>>>>>>>>>>> >>>>>>>>>>>>> Other contentious issues may be: >>>>>>>>>>>>> - The removal of ‘labels’ - which is very noisy, the vast >>>> majority of >>>>>>>>>>>>> which provide no value, and we expect can be superseded by >> other >>>>>>>>>> suggestions >>>>>>>>>>>>> - The introduction of required fields for certain transitions, >>>> some >>>>>>>> of >>>>>>>>>>>>> which are new (complexity, severity, bug/feature category) >>>>>>>>>>>>> - The introduction of some new transitions (Triage, Review in >>>>>>>> Progress, >>>>>>>>>>>>> Change Requested) >>>>>>>>>>>>> >>>>>>>>>>>>> Look forward to hearing your thoughts! >>>>>>>>>>> >>>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
