On Wed, Dec 12, 2018 at 7:14 PM Benedict Elliott Smith <bened...@apache.org> wrote:
> Ok, so feel free to keep your votes coming, but we have a pretty clear > majority for everything except Wish - which presently stands at -1 (maybe > -2 if Sylvain updates his vote). > Yes, I did meant -1 on the wish issue if that can help. > > Thanks everyone who has voted on either poll! > > > Results so far: > 2. [B C A] x6 [A B C] x1 > 3. A x7 > 4. +1 -2 > > For 1, we have: > D C B A E > D C B A E > D C B E A > D C E B A > A D E B C > A B C D E > E D C B A > C D A B E > > Which currently leads to eliminating B, C and E first choice votes, > leading to a strong win for option D. > > I’ll leave it a few days to see if anymore votes roll in, but I don’t > anticipate a major shift in opinion. I will update the proposal with the > outcome, and call a formal vote on the final proposal in a few days. > > Thanks again everyone for participating in what I realise was not the most > exciting discussion. I’m glad everyone got a chance to air their opinions, > and that we managed to come to a decision that I hope we can all endorse. > > > On 12 Dec 2018, at 16:00, Ariel Weisberg <ar...@weisberg.ws> wrote: > > Hi, > > Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged. > > 1. E, D, C, B, A > > 2. B, C, A > > 3. A > > 4. -.5 > > Ariel > On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote: > > Hi, > > Sorry I was just slow on the uptake as to what auto-populate meant RE #2. > > 1. -1, while restricting editing on certain fields or issues that people > did not submit themselves is OK I don't think it's reasonable to block > edits to subject, or description on issues a user has submitted. > > Do we actually have a problem that needs solving with restricting edits? > I feel like we aren't being harmed right now by the current power people > are wielding? > > 2. B, C, A > > 3. A > > 4. -.5, I really don't see Wish as something other then a synonym for > low priority. Only -.5 because I don't think it's that harmful either. > > Ariel > > On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote: > > On 10 Dec 2018, at 16:21, Ariel Weisberg <ar...@weisberg.ws> wrote: > > > Hi, > > RE #1, does this mean if you submit a ticket and you are not a contributor > you can't modify any of the fields including description or adding/removing > attachments? > > > Attachment operations have their own permissions, like comments. > Description would be prohibited though. I don’t see this as a major > problem, really; it is generally much more useful to add comments. If > we particularly want to make a subset of fields editable there is a > workaround, though I’m not sure anybody would have the patience to > implement it: > > https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html > < > https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html > > > > RE #2, while bugs don't necessarily have a priority it's helpful to have > it sort logically with other issue types on that field. Seems like ideally > what we want to preserve is a useful sort order without having to populate > the field manually. > > > Do you have a suggestion that achieves this besides auto-populating (if > that’s even possible)? More than happy to add suggestions to the list. > > RE #4, Do we need to keep wish at all? > > > I’m unclear on what you’re asking? I included exactly this question, > directly in response to your opinion that it should not be kept. If you > have more to add to your earlier view, please feel free to share it. > > Not voting yet just because I'm not sure on some. > > Ariel > > On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote: > > New questions. This is the last round, before I call a proper vote on > the modified proposal (so we can take a mandate to Infra to modify our > JIRA workflows). > > Thanks again to everyone following and contributing to this discussion. > I’m not sure any of these remaining questions are critical, but for the > best democratic outcome it’s probably worth running them through the > same process. I also forgot to include (1) on the prior vote. > > 1. Limit edits to JIRA ‘contributor’ role: +1/-1 > 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) > leave it. Please rank. > 3. Top priority: (A) Urgent; (B) Blocker. See here for my explanation > of why I chose Urgent > < > https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E > < > https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E > >>. > 4. Priority keep ‘Wish’ (to replace issue type): +1/-1 > > For 2, if we cannot remove it, we can make it non-editable and default > to Normal; for auto-populate I propose using Severity (Low->Low, Normal- > > Normal, Critical->Urgent). No guarantees entirely on what we can > > achieve, so a ranked choice would be ideal. > > I have avoided splitting out another vote on the Platform field, since > everyone was largely meh on the question of mandatoriness; it won by > only a slim margin, because everyone was +/- 0, and nobody responded to > back Ariel’s dissenting view. > > My votes are: > 1: +1 > 2: B,C,A > 3: A > 4: +0.5 > > > For tracking, the new consensus from the prior vote is: > 1: A (+10) > 2: +9 -0.1 > 3: +10 > 4: +6 -2 (=+4) > 5: +2; a lot of meh. > 6: +9 > > > > On 7 Dec 2018, at 17:52, Ariel Weisberg <ar...@weisberg.ws> wrote: > > Hi, > > Late but. > > 1. A > 2. +1 > 3. +1 > 4. -1 > 5. -0 > 6. +1 > > RE 4, I think blocker is an important priority. High and urgent mean the > same thing to me. Wish is fine, but that is too similar to low if you ask > me. My ideal would be low, medium, high, blocker. Medium feels weird, but > it's a real thing, it's not high priority and we really want it done, but > it's not low enough that we might skip it/not get to it anytime soon. > > RE 5. I don't think I have ever used the environment field or used the > contents populated in it. Doesn't mean someone else hasn't, but in terms of > making the easy things easy it seems like making it required isn't so high > value? I don't populate it myself usually I put it in the description or > the subject without thinking. > > It seems like the purpose of a field is to make it indexable and possibly > structured. How often do we search or require structure on this field? > > Ariel > > On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith 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 <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 > <dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > <dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > <dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > <dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > <dev-unsubscr...@cassandra.apache.org> < > mailto:dev-unsubscr...@cassandra.apache.org > <dev-unsubscr...@cassandra.apache.org>> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org> <mailto:dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > <dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > <dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: dev-h...@cassandra.apache.org > <dev-h...@cassandra.apache.org> > > >
