Thanks everyone for your feedback so far! I think we have a pretty strong consensus for the first questions. I will follow-up later with a new poll; hopefully this will be the last round, so if you have any more questions that haven’t been aired, please do bring them up now.
1: A (+9) 2: +8 -0.1 3: +9 4: +6 -1 5: +2; a lot of meh. (This may be defunct given the problems Sylvain raised, anyway, but we will have to negotiate that with Infra once we have a clear mandate to bring to them) 6: +8 Obviously, feel free to keep your poll answers coming, in case you think the balance will tip. But at this point I’m happy to pre-emptively call it. > On 6 Dec 2018, at 13:55, Sam Tunnicliffe <s...@beobal.com> wrote: > > 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 >
