Sorry, 4. Is inconsistent. First instance should be. > - 4. Priorities: Keep ‘High' priority
> On 4 Dec 2018, at 19:12, 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: Keep ‘High' priority > - 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 >> <mailto: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 >> <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 >> >> <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><mailto: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 > <mailto:dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <mailto:dev-h...@cassandra.apache.org>
