Hi, Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged.
1. E, D, C, B, A 2. B, C, A 3. A 4. -.5 Ariel On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote: > Hi, > > Sorry I was just slow on the uptake as to what auto-populate meant RE #2. > > 1. -1, while restricting editing on certain fields or issues that people > did not submit themselves is OK I don't think it's reasonable to block > edits to subject, or description on issues a user has submitted. > > Do we actually have a problem that needs solving with restricting edits? > I feel like we aren't being harmed right now by the current power people > are wielding? > > 2. B, C, A > > 3. A > > 4. -.5, I really don't see Wish as something other then a synonym for > low priority. Only -.5 because I don't think it's that harmful either. > > Ariel > > On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote: > > On 10 Dec 2018, at 16:21, Ariel Weisberg <ar...@weisberg.ws> wrote: > > > > > > Hi, > > > > > > RE #1, does this mean if you submit a ticket and you are not a > > > contributor you can't modify any of the fields including description or > > > adding/removing attachments? > > > > Attachment operations have their own permissions, like comments. > > Description would be prohibited though. I don’t see this as a major > > problem, really; it is generally much more useful to add comments. If > > we particularly want to make a subset of fields editable there is a > > workaround, though I’m not sure anybody would have the patience to > > implement it: > > https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html > > > > <https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html> > > > > > RE #2, while bugs don't necessarily have a priority it's helpful to have > > > it sort logically with other issue types on that field. Seems like > > > ideally what we want to preserve is a useful sort order without having to > > > populate the field manually. > > > > Do you have a suggestion that achieves this besides auto-populating (if > > that’s even possible)? More than happy to add suggestions to the list. > > > > > RE #4, Do we need to keep wish at all? > > > > I’m unclear on what you’re asking? I included exactly this question, > > directly in response to your opinion that it should not be kept. If you > > have more to add to your earlier view, please feel free to share it. > > > > > Not voting yet just because I'm not sure on some. > > > > > > Ariel > > > > > > On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote: > > >> New questions. This is the last round, before I call a proper vote on > > >> the modified proposal (so we can take a mandate to Infra to modify our > > >> JIRA workflows). > > >> > > >> Thanks again to everyone following and contributing to this discussion. > > >> I’m not sure any of these remaining questions are critical, but for the > > >> best democratic outcome it’s probably worth running them through the > > >> same process. I also forgot to include (1) on the prior vote. > > >> > > >> 1. Limit edits to JIRA ‘contributor’ role: +1/-1 > > >> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) > > >> leave it. Please rank. > > >> 3. Top priority: (A) Urgent; (B) Blocker. See here for my explanation > > >> of why I chose Urgent > > >> <https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E > > >> > > >> <https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E>>. > > >> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1 > > >> > > >> For 2, if we cannot remove it, we can make it non-editable and default > > >> to Normal; for auto-populate I propose using Severity (Low->Low, Normal- > > >>> Normal, Critical->Urgent). No guarantees entirely on what we can > > >> achieve, so a ranked choice would be ideal. > > >> > > >> I have avoided splitting out another vote on the Platform field, since > > >> everyone was largely meh on the question of mandatoriness; it won by > > >> only a slim margin, because everyone was +/- 0, and nobody responded to > > >> back Ariel’s dissenting view. > > >> > > >> My votes are: > > >> 1: +1 > > >> 2: B,C,A > > >> 3: A > > >> 4: +0.5 > > >> > > >> > > >> For tracking, the new consensus from the prior vote is: > > >> 1: A (+10) > > >> 2: +9 -0.1 > > >> 3: +10 > > >> 4: +6 -2 (=+4) > > >> 5: +2; a lot of meh. > > >> 6: +9 > > >> > > >> > > >> > > >>> On 7 Dec 2018, at 17:52, Ariel Weisberg <ar...@weisberg.ws> wrote: > > >>> > > >>> Hi, > > >>> > > >>> Late but. > > >>> > > >>> 1. A > > >>> 2. +1 > > >>> 3. +1 > > >>> 4. -1 > > >>> 5. -0 > > >>> 6. +1 > > >>> > > >>> RE 4, I think blocker is an important priority. High and urgent mean > > >>> the same thing to me. Wish is fine, but that is too similar to low if > > >>> you ask me. My ideal would be low, medium, high, blocker. Medium feels > > >>> weird, but it's a real thing, it's not high priority and we really want > > >>> it done, but it's not low enough that we might skip it/not get to it > > >>> anytime soon. > > >>> > > >>> RE 5. I don't think I have ever used the environment field or used the > > >>> contents populated in it. Doesn't mean someone else hasn't, but in > > >>> terms of making the easy things easy it seems like making it required > > >>> isn't so high value? I don't populate it myself usually I put it in the > > >>> description or the subject without thinking. > > >>> > > >>> It seems like the purpose of a field is to make it indexable and > > >>> possibly structured. How often do we search or require structure on > > >>> this field? > > >>> > > >>> Ariel > > >>> > > >>> On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith 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 > > >>>> > > >>> > > >>> --------------------------------------------------------------------- > > >>> 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 > > > <mailto:dev-unsubscr...@cassandra.apache.org> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > <mailto: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
