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

Reply via email to