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
