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