Thanks everyone for the quick initial feedback! I’m going to aggregate my responses here, to try and avoid too much fragmentation of discussion; we’ll see how sensible this is.
===Labels=== I’m not irreconcilably against keeping labels, I just think on balance it’s better to remove them. I spent a while looking at the existing labels, and they entirely paper over inadequacies we have currently. I think labels have been a crutch we’ve used to avoid better hygiene. An alternative route might be to support labels, and (e.g.) bi-annually promote any useful ones to the schema, and clear the rest? 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. ===Priorities=== You may be right that the High priority is not necessary, but I think it is useful for members of the project to flag tickets they plan to prioritise. The intention was for this to simply indicate that some _contributor_ values this ticket above others, and probably intends to address it within the next year. I would be OK with having only (Wish), Low, Normal and Urgent though. What do other people think? ===Josh (remainder)=== 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. They should be expected to understand the problem and systems well enough to provide an initial assessment of the priority, severity, complexity, affected components and bug/change category. These can of course be revised, but we benefit from a first assessment for monitoring the outstanding work - right now we’re really bad at managing the work outstanding unless it was filed by a committer. FWIW, and in conjunction with the above conversation on priorities, I would propose only contributors are permitted to edit the JIRA once it is created, and that non-contributors file a ticket without being able to set Priority, since this is something for the project to manage, and only causes conflict when users feel empowered to stipulate this. ===Mandatory Platform, Version, etc=== As above with Triage, the plan is for essentially no information to be required on creation, but on transition to Open. The proposal as it stands suggests removing the Environment field, since is was poorly maintained. This was intended to capture the reporter’s platform, if any. Perhaps we could instead make it required only on ticket creation? For Platform, we haven’t made it required because it was to mark those issues that _exclusively_ affect these platforms. Perhaps it would make sense to introduce an ‘All’ flag, which would permit us to make this required on ‘Patch Available'? 'Since Version' is already required on transition to ‘Patch Available’ when the assignee should have enough context to answer the question. > On 26 Nov 2018, at 15:05, Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote: > > Regarding labels, I am personally a fan of both - the mapping of commonly > used labels to things like components, features, tools, etc. as well as > keeping labels for newer and more arbitrary groupings. I’ve tried to > maintain certain labels like virtual-tables, lcs, lwt, fqltool, etc because > there are new things (e.g. fqltool and virtual tables) that we don’t > immediately make into components and it's really nice to group them to see > where there might be stability or feature specific (thinking virtual tables) > items. I agree that arbitrary and misspelled labels make things a bit noisy > but as long as we strive to use the components/features and do some periodic > upkeep of labels. By periodic upkeep I mean, converting new labels into > components or what have you. Beyond new features or arbitrary groupings, it > might have been nice to have had ngcc labeled tickets to see how that’s > contributed to the project over time or some other similar event. > > In summary, I really like the mapping but I also really like the way that > labels can still be of value. Also, if we strive to keep the components > field up to date, there’s really no harm in having the labels. > > </2cents> > > Jeremy > >> On Nov 26, 2018, at 8:33 AM, 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 >
