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
