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