My personal preference is to remove labels, but I don't see it as a huge issue if they stay.
1. A 2. prefer to remove (I suppose I'm a -.1?) 3. +1 4. +1 5. No preference 6. +1 On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID <jay.zhu...@yahoo.com.invalid> wrote: > 1: Component. (A) Multi-select > 2: Labels: leave alone +1 > 3: No workflow changes for first/second review: +1 > 4: Priorities Including High: -1 > 5: Mandatory Platform and Feature: +1 > 6: Remove Environment field: +1 > > On Wednesday, December 5, 2018, 2:58:21 AM PST, Benedict Elliott Smith > <bened...@apache.org> wrote: > > Thanks for the feedback and further questions. I’m sure there will be > more, particularly around permissions and roles, so it’s good to get some > of these other discussions moving. > > No doubt we’ll do a second poll once the first one concludes. Please, > everyone, keep your first poll answers coming! > > > On 5 Dec 2018, at 09:50, Sylvain Lebresne <lebre...@gmail.com> wrote: > > > > Thanks for all those that contributed to the proposal, and specifically > to > > Benedict for leading the discussion. > > > > On the general proposal, I suspect there is a few details we may have to > > tweak going forward, but hard to be sure before trying and as I do think > > it's progress, I'm personally happy to move forward with this. But for > the > > sake of discussions, a minor remarks that I don't think have been > mentioned > > above: > > - at least the platform and feature fields will be moving targets (the > > features hopefully more so than the platform, but new java version gets > > release regularly for instance). Do we know technically if we can get > those > > easily updated without requiring an infra JIRA ticket? > > This is actually a really good question. I had assumed this would be > treated much like Component, Version, etc > > However, I was wrong: > > https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311 > < > https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311 > > > > There are some possible workarounds, but none of them seem great. There’s > a plugin, but not sure if Infra would be OK with this: > https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview > < > https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview > > > > This is potentially a real blocker for these two fields. > > So, for feature an alternative is to merge Feature/[Feature] into > Component. This would implicitly make it non-mandatory, however. This > could potentially be fixed with a custom field validator, but this might > need a plugin. > > For Platform, I don’t have a good alternative idea right now. This is > something that is best curated, but definitely needs to be easily updated. > > > > - I'd personally probably remove the condition of being "jira > contributor" > > to move tickets out of triage. Being a "jira contributor" is a pretty > > arbitrary in practice. Anyone that ever asked has been added, no question > > asked, but it can actually be annoying to get added if no-one that knows > > how to do it is around. So if, as I assume, the goal is to ensure that > > fields are properly fielded, I don't think it will help much, and so I > > suspect it would just be an annoyance to new, not-yet-"jira contributor" > > users that are willing to fill all the required fields seriously (but > will > > see their ticket stuck in triage until they either get added, or some > other > > random user flip the switch). And why assume people will mis-field > stuffs? > > So I'd vote for just letting anyone transition out of triage as long as > all > > required field are there. Side-note: fwiw, I'd very much be in favor of > > removing the "jira contributor" concept for the reasons exposed above: I > > never felt it was anything else than an hindrance. > > I realise we have no real barrier to becoming a contributor, and that many > of these permissions are going to have limited impact. But I think a > really easy to jump gate can still be helpful, and I don’t recall > contributors overstepping their role. But this isn’t a critical point, and > it would be great to hear other’s opinions. > > > - Once we have 'complexity' and 'severity', I'm not entirely sure what > > 'priority' really means in a voluntary-based project? Is it the > gut-feeling > > for how useful the ticket is of whomever triage the ticket? If that, > > outside of not being convinced of the value, I'd argue that 1) it doesn't > > make sense for bugs and 2) it's sufficiently imprecise that it's imo > worth > > keeping it simple, something like low/normal/high ought to be enough. If > > it's not that, then what is it, cause it's genuinely not immediately > > obvious to me? > > Well, if nothing else Priority is the thing I sort my outstanding work by, > and for this reason I have a preference for it being present for all ticket > types. But I do see your point. > > In particular, Urgent probably is something we’re only likely to use for > critical bugs. It’s possible we could even automatically populate this for > a Bug type, and potentially not show this option for non-bugs. But I > suspect we would need something like the ScriptRunner plugin for this. > > In my view Priority is essentially Low or Normal (or Urgent if critical > bug) on initial filing. But a High priority can be set by a contributor > who particularly values the ticket, for their own work prioritisation. > Wish is a priority to make room for the Wish ticket type we are removing, > and for those occasional requests that come in that have no realistic > timeline for being addressed. > > > > > > And with that, my poll results: > > 1:A > > 2:+1 > > 3:+1 > > 4:Don't mind > > 5:Don't mind > > -- > > Sylvain > > > > > > On Tue, Dec 4, 2018 at 8:12 PM 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: Option A: Wish, Low, Normal, High, Urgent; Option B: > >> Wish, Low, Normal, Urgent > >> - 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> 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>). 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 > >>> > >>> ––– > >>> > >>> 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>) 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 > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
