You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Benedict Elliott Smith <be...@apache.org> on 2018/12/04 19:12:28 UTC
Re: JIRA Workflow Proposals
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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Marcus Eriksson <ma...@apache.org>.
1. D C B A E
2. B C A
3. A
4. -0.5, leaning towards remove but don't really care
On Tue, Dec 11, 2018 at 06:42:09PM +0000, Aleksey Yeshchenko wrote:
> 1. C, D, A, B, E
> 2. B, C, A
> 3. A
> 4. Meh
>
> > On 11 Dec 2018, at 16:28, Benedict Elliott Smith <be...@apache.org> wrote:
> >
> > Just to re-summarise the questions for people:
> >
> > 1. (A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today
> > 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
> >
> > With my answers (again, sorry):
> >
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> >
> >> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org> wrote:
> >>
> >> It looks like we have a multiplicity of views on permissions, so perhaps we should complicate this particular vote with all of the possible options that have been raised so far (including one off-list). Sorry everyone for the confusion.
> >>
> >> (A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today
> >>
> >> * Today apparently ‘Anyone’ can perform this operation
> >>
> >> A ranked vote, please. This makes my votes:
> >>
> >> 1: A B C D E
> >> 2: B C A
> >> 3: A
> >> 4: +0.5
> >>
> >>
> >>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID> wrote:
> >>>
> >>> I agree with this. I generally am on the side of freedom and responsibility. Limiting edits to certain fields turns people off. Something I want to very much avoid if we can.
> >>>
> >>> Dinesh
> >>>
> >>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <mu...@gmail.com> wrote:
> >>>>
> >>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
> >>>> <be...@apache.org> 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>
> >>>>>
> >>>>
> >>>> That would be disappointing. Descriptions with broken or no formatting
> >>>> aren't rare (say, command output without code formatting). And every
> >>>> now and then the description might need to be updated. For example, in
> >>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
> >>>> paper had rotted, but I managed to find a new one, so I could edit it
> >>>> in. If such a change had to be posted as a comment, it might easily
> >>>> get lost in some of the more active issues.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
Thanks. I’ll respond inline with the thinking around the original proposal.
> On 5 Dec 2018, at 20:26, Stefan Podkowinski <sp...@apache.org> wrote:
>
> Thanks Benedict and everyone involved putting up the proposal! It really
> deserves some more feedback and I realize that I'm a bit late for that
> and probably missed a good deal of the conversation so far. I'd still
> like to share some of my notes that I've taken while reading through it,
> for the sake of discussion.
>
>
> Priority:
> Blocker and critical seem to be more useful to me, compared to "urgent",
> which is not clear about what's being urgent to whom and probably be
> picked from a personal perspective. Blockers are useful for identifying
> issues that need to be solved before creating an imminent release.
> Critical should be used for patches important enough for releases that
> are maintained on "critical bug fixes only" basis. It's not strictly
> used that way, but "urgent" doesn't address this.
Urgent was intended specifically to replace both Blocker and Critical. Anything “Urgent” probably needs to block release and probably accelerate release once committed.
We don’t really distinguish between Critical and Blocker right now, and I’m not sure we need to. Perhaps others have input?
> Complexity:
> Possibly inappropriate for some type of issues, simply not known yet, or
> impossible to tell. I'd not add it and keep using labels for that if we
> have to highlight outliers, like lhf.
This is explicitly only for the Bug issue type.
> Discovered by:
> Neat idea, would be very interesting to analyze that.
>
> Bug category:
> More complex bugs will probably fall into multiple categories. Choices
> are hard to answer without the description. Do we really need this as a
> mandatory field for new bug reports, which may not have been even
> analyzed yet. What would you pick e.g. when reporting a broken test on CI?
The Triage state is intended to handle this. You only migrate to Open when you have enough information to complete this.
I’m also not convinced there is actually much overlap? The only ones I can think of, there’s a clear attribution.
In your example, the following item from the Correctness list:
Test Failure
A test is broken - if this turns out to be a legitimate bug, it should transition to the bug's category once diagnosed
> Component:
> I'd prefer not having to have subcategories or multi-select values. It's
> too inflexible (why would any hint issues necessarily be consistency
> issues?).
The category doesn’t imply there’s a consistency problem, they just categorise the components. A consistency problem would be denoted in the bug category.
For this specific example, Hints are most easily grouped along with the set of features we use to distribute data around the cluster, which has been loosely named consistency in this proposal. It doesn’t follow that a problem with any one of these systems entails a failure of consistency?
If you have a better name proposal, I’m all ears. But trust me, it’s a hard problem, and took a surprising amount of time to come up with this proposal. Loosely grouping items should make the more complete list more manageable than a giant grab-bag, so that people become familiar with the groupings, and don’t need to remember the naming of every item. Conversely, the present day setup of loose groupings only leads to a lot of misunderstandings about what was meant by those groups.
>
> Features:
> Distinction of features/components isn't really clear to me. At least
> crosscuts like observability should be there, instead of components.
> It's still useful, as it's general enough, easy to answer and
> insightful. I'd reduce the component list a bit and make this an
> optional follow up selection after features.
The idea was primarily for things that were both cross-sectional and difficult to group together. Observability could probably go in Features, sure. I don’t really have a strong opinion on that.
> Remove 'Reproduced in':
> We should have a field that allows the user to report the used Cassandra
> version for an issue.
Why not a comment or the description? This field is not searchable, and it usually gets reported in the description today. Usage of this field is very patchy, and of not great utility IMO. Perhaps others have an opinion?
> As for workflow changes, I don't have a real opinion on that yet and
> like to give this some more thoughts. But the suggested review status
> changes are something I'd definitely like to see happening.
>
>
> On 04.12.18 20:12, 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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by Stefan Podkowinski <sp...@apache.org>.
Thanks Benedict and everyone involved putting up the proposal! It really
deserves some more feedback and I realize that I'm a bit late for that
and probably missed a good deal of the conversation so far. I'd still
like to share some of my notes that I've taken while reading through it,
for the sake of discussion.
Priority:
Blocker and critical seem to be more useful to me, compared to "urgent",
which is not clear about what's being urgent to whom and probably be
picked from a personal perspective. Blockers are useful for identifying
issues that need to be solved before creating an imminent release.
Critical should be used for patches important enough for releases that
are maintained on "critical bug fixes only" basis. It's not strictly
used that way, but "urgent" doesn't address this.
Complexity:
Possibly inappropriate for some type of issues, simply not known yet, or
impossible to tell. I'd not add it and keep using labels for that if we
have to highlight outliers, like lhf.
Discovered by:
Neat idea, would be very interesting to analyze that.
Bug category:
More complex bugs will probably fall into multiple categories. Choices
are hard to answer without the description. Do we really need this as a
mandatory field for new bug reports, which may not have been even
analyzed yet. What would you pick e.g. when reporting a broken test on CI?
Component:
I'd prefer not having to have subcategories or multi-select values. It's
too inflexible (why would any hint issues necessarily be consistency
issues?).
Features:
Distinction of features/components isn't really clear to me. At least
crosscuts like observability should be there, instead of components.
It's still useful, as it's general enough, easy to answer and
insightful. I'd reduce the component list a bit and make this an
optional follow up selection after features.
Remove 'Reproduced in':
We should have a field that allows the user to report the used Cassandra
version for an issue.
As for workflow changes, I don't have a real opinion on that yet and
like to give this some more thoughts. But the suggested review status
changes are something I'd definitely like to see happening.
On 04.12.18 20:12, 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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
I see. Thanks for clarifying; I was confused by beginning with “RE 5" but discussing Environment.
Bear in mind we’re not only replacing Environment with the Platform field, but also a number of labels that were searchable and indicated environment/platform information. Labels such as ‘Windows' (and ‘windows’), Java11, Debian, EC2,…
Clearly some people want to capture this information in a way that is more usable, though admittedly this is not super common. Still, it seems preferable to both support this natively in the schema, and try to curate a more accurate and consistent representation. That is, again, if possible.
If somebody else would like to back this dissent, though, I can separate out Platform in the next poll.
> On 7 Dec 2018, at 18:39, Ariel Weisberg <ar...@weisberg.ws> wrote:
>
> Hi,
>
> I think I managed to not get confused. I evaluatec the two separately. I don't like or use environment both in terms of populating the field and searching on it. That information could go in the description and be just as useful to me personally.
>
> I have no problem with an optional platform field that is an improvement on environment in that it is more structured and searchable. My bar for optional fields is low. I guess I'm not convinced I want either though? If other people find it useful then because they search on it then yes we should do a better more structured version.
>
> 5 groups feature impact and platform. It's platform I think is less useful? I am +1 on feature impacts as we have impact on things like CCM and drivers that we need to keep track of and I do forget them at times.
>
> Ariel
>
> On Fri, Dec 7, 2018, at 1:17 PM, Benedict Elliott Smith wrote:
>>
>>
>>> On 7 Dec 2018, at 17:52, Ariel Weisberg <ar...@weisberg.ws> wrote:
>>>
>>> Hi,
>>>
>>> Late but.
>>
>> No harm in them continuing to roll in, I’m just cognisant of needing to
>> annoy everyone with a second poll, so no point perpetuating it past a
>> likely unassailable consensus.
>>
>>>
>>> 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.
>>
>> It seems like people have really strong (and divergent) opinions about
>> Priority!
>>
>> So, to begin: I don’t think Medium is any different to Normal, in the
>> proposal? Except Normal is, well, more accurate I think? It is the
>> default priority, and should be used unless strong reasons otherwise.
>>
>> As for Blocker vs Urgent, I obviously disagree (but not super strongly):
>> Urgent conveys more information IMO. Blocker only says we cannot
>> release without this. Urgent also says we must release with this, and
>> ASAP. The meaning of a priority is anyway distinct from its name, and
>> the meaning of Urgent is described in the proposal to make this clear.
>> But, it’s easy to add a quick poll item for the top priority name. Any
>> other suggestions, besides Urgent and Blocker?
>>
>> Of course, if we remove Priority from the Bug type, I agree with others
>> that the top level priority ceases to mean anything, and there probably
>> shouldn’t be one.
>>
>> Wish will already be included in the next poll.
>>
>>> 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?
>>
>> Are you conflating this with Q6? The environment field was not
>> discussed, only the potential Platform field, which we _hope_ to make a
>> multi-select list. This would make the information quite useful for
>> reporting and searching.
>>
>> Environment is being removed because it is unstructured and poorly used,
>> and it looks like you have voted in favour of this?
>>
>> If Platform cannot be made into an editable multi-select list, we will
>> probably not make it mandatory. Here we’re trying to gauge an ideal end
>> state - some things may need revisiting if JIRA does not play ball,
>> though that should not affect many items.
>>
>>>
>>> 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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by Ariel Weisberg <ar...@weisberg.ws>.
Hi,
I think I managed to not get confused. I evaluatec the two separately. I don't like or use environment both in terms of populating the field and searching on it. That information could go in the description and be just as useful to me personally.
I have no problem with an optional platform field that is an improvement on environment in that it is more structured and searchable. My bar for optional fields is low. I guess I'm not convinced I want either though? If other people find it useful then because they search on it then yes we should do a better more structured version.
5 groups feature impact and platform. It's platform I think is less useful? I am +1 on feature impacts as we have impact on things like CCM and drivers that we need to keep track of and I do forget them at times.
Ariel
On Fri, Dec 7, 2018, at 1:17 PM, Benedict Elliott Smith wrote:
>
>
> > On 7 Dec 2018, at 17:52, Ariel Weisberg <ar...@weisberg.ws> wrote:
> >
> > Hi,
> >
> > Late but.
>
> No harm in them continuing to roll in, I’m just cognisant of needing to
> annoy everyone with a second poll, so no point perpetuating it past a
> likely unassailable consensus.
>
> >
> > 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.
>
> It seems like people have really strong (and divergent) opinions about
> Priority!
>
> So, to begin: I don’t think Medium is any different to Normal, in the
> proposal? Except Normal is, well, more accurate I think? It is the
> default priority, and should be used unless strong reasons otherwise.
>
> As for Blocker vs Urgent, I obviously disagree (but not super strongly):
> Urgent conveys more information IMO. Blocker only says we cannot
> release without this. Urgent also says we must release with this, and
> ASAP. The meaning of a priority is anyway distinct from its name, and
> the meaning of Urgent is described in the proposal to make this clear.
> But, it’s easy to add a quick poll item for the top priority name. Any
> other suggestions, besides Urgent and Blocker?
>
> Of course, if we remove Priority from the Bug type, I agree with others
> that the top level priority ceases to mean anything, and there probably
> shouldn’t be one.
>
> Wish will already be included in the next poll.
>
> > 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?
>
> Are you conflating this with Q6? The environment field was not
> discussed, only the potential Platform field, which we _hope_ to make a
> multi-select list. This would make the information quite useful for
> reporting and searching.
>
> Environment is being removed because it is unstructured and poorly used,
> and it looks like you have voted in favour of this?
>
> If Platform cannot be made into an editable multi-select list, we will
> probably not make it mandatory. Here we’re trying to gauge an ideal end
> state - some things may need revisiting if JIRA does not play ball,
> though that should not affect many items.
>
> >
> > 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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
> >>>>>> benedict@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 <ko...@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 <jm...@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 <
> >>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
The “Impact” field idea sounds like a good potential follow-up discussion. I’d prefer not to complicate this process when we’re seemingly nearing consensus, particularly as I’m not personally sure what form such a field would take. But it would be a relatively small modification, if you want to come up with a proposal when we’ve finished modifying JIRA with whatever consensus we reach here. Does that sound reasonable?
Similarly, the CIP process is something I think we need to drive a separate discussion on, similar to this one. It’s a huge rabbit hole that could easily derail this discussion.
> On 9 Dec 2018, at 03:03, Mick Semb Wever <mc...@apache.org> wrote:
>
>
>
>> Of course, if we remove Priority from the Bug type, I agree with others
>> that the top level priority ceases to mean anything, and there probably
>> shouldn’t be one.
>
>
> Benedict, another idea, and this might be for down the road, is to have "Severity" or bug types and "Impact" on non-bug types. Removing everywhere the need for a subjective Priority field. Such an "Impact" field would permit more descriptive values for improvements and features. We can also add some documentation as to what qualifies for the different values to both Severity and Impact.
>
> And on the topic of Feature types, what are people's thoughts on the "Cassandra improvement Proposal" written up at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>
> If we agree on this then can we have a (mandatory) field on Feature for the CIP? If people are entering requests for new Features then shouldn't they also be willing to do some homework and write up a CIP?
>
> regards,
> Mick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Mick Semb Wever <mc...@apache.org>.
> Of course, if we remove Priority from the Bug type, I agree with others
> that the top level priority ceases to mean anything, and there probably
> shouldn’t be one.
Benedict, another idea, and this might be for down the road, is to have "Severity" or bug types and "Impact" on non-bug types. Removing everywhere the need for a subjective Priority field. Such an "Impact" field would permit more descriptive values for improvements and features. We can also add some documentation as to what qualifies for the different values to both Severity and Impact.
And on the topic of Feature types, what are people's thoughts on the "Cassandra improvement Proposal" written up at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
If we agree on this then can we have a (mandatory) field on Feature for the CIP? If people are entering requests for new Features then shouldn't they also be willing to do some homework and write up a CIP?
regards,
Mick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
> On 7 Dec 2018, at 17:52, Ariel Weisberg <ar...@weisberg.ws> wrote:
>
> Hi,
>
> Late but.
No harm in them continuing to roll in, I’m just cognisant of needing to annoy everyone with a second poll, so no point perpetuating it past a likely unassailable consensus.
>
> 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.
It seems like people have really strong (and divergent) opinions about Priority!
So, to begin: I don’t think Medium is any different to Normal, in the proposal? Except Normal is, well, more accurate I think? It is the default priority, and should be used unless strong reasons otherwise.
As for Blocker vs Urgent, I obviously disagree (but not super strongly): Urgent conveys more information IMO. Blocker only says we cannot release without this. Urgent also says we must release with this, and ASAP. The meaning of a priority is anyway distinct from its name, and the meaning of Urgent is described in the proposal to make this clear. But, it’s easy to add a quick poll item for the top priority name. Any other suggestions, besides Urgent and Blocker?
Of course, if we remove Priority from the Bug type, I agree with others that the top level priority ceases to mean anything, and there probably shouldn’t be one.
Wish will already be included in the next poll.
> 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?
Are you conflating this with Q6? The environment field was not discussed, only the potential Platform field, which we _hope_ to make a multi-select list. This would make the information quite useful for reporting and searching.
Environment is being removed because it is unstructured and poorly used, and it looks like you have voted in favour of this?
If Platform cannot be made into an editable multi-select list, we will probably not make it mandatory. Here we’re trying to gauge an ideal end state - some things may need revisiting if JIRA does not play ball, though that should not affect many items.
>
> 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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by andre wilkinson <an...@me.com.INVALID>.
Sounds great Benedict, its a start for me as again I look forward to communicating with everyone and helping out, I know I will learn a little something just from seeing work flow and studying up on what ever task is presented in front of me.
> On Dec 12, 2018, at 10:14 AM, Benedict Elliott Smith <be...@apache.org> wrote:
>
> 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.
Re: JIRA Workflow Proposals
Posted by Sylvain Lebresne <le...@gmail.com>.
On Wed, Dec 12, 2018 at 7:14 PM Benedict Elliott Smith <be...@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 (
> benedict@apache.org<mailto:benedict@apache.org <be...@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 <be...@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 <jm...@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 <
> benedict@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 <jm...@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 <
>
> benedict@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 <ko...@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 <jm...@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 <
>
> benedict@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org
> <de...@cassandra.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org
> <de...@cassandra.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org
> <de...@cassandra.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org
> <de...@cassandra.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org> <
> mailto:dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org>>
> For additional commands, e-mail: dev-help@cassandra.apache.org
> <de...@cassandra.apache.org> <mailto:dev-help@cassandra.apache.org
> <de...@cassandra.apache.org>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org
> <de...@cassandra.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> <de...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org
> <de...@cassandra.apache.org>
>
>
>
Re: JIRA Workflow Proposals
Posted by "jay.zhuang@yahoo.com.INVALID" <ja...@yahoo.com.INVALID>.
My two cents:
1. C, D, E, B, A2. A, B, C3. A4. -1
On Wednesday, December 12, 2018, 10:14:25 AM PST, Benedict Elliott Smith <be...@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).
Thanks everyone who has voted on either poll!
Results so far:2. [B C A] x6 [A B C] x13. A x74. +1 -2
For 1, we have:D C B A ED C B A ED C B E AD C E B AA D E B CA B C D EE D C B AC 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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
benedict@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 <ko...@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 <jm...@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 <
benedict@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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org>
For additional commands, e-mail: dev-help@cassandra.apache.org <ma...@cassandra.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
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).
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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>>>>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org>
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org <ma...@cassandra.apache.org>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by Ariel Weisberg <ar...@weisberg.ws>.
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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
> > >>>>>>>> benedict@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 <ko...@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 <jm...@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 <
> > >>>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
> > >>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> ---------------------------------------------------------------------
> > >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org>
> > > For additional commands, e-mail: dev-help@cassandra.apache.org <ma...@cassandra.apache.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by andre wilkinson <an...@me.com.INVALID>.
Hey Benedict,
Thank you.
In that case
A D E B C
> On Dec 11, 2018, at 12:37 PM, Benedict Elliott Smith <be...@apache.org> wrote:
>
> Hi Andre,
>
> It’s ranked vote, i.e. for each question, what is your preference order for the outcome?
>
> So, for question 1, the possible outcomes are:
>
> (A) Only contributors may edit or transition issues;
> (B) Only contributors may transition issues;
> (C) Only Jira-users may transition issues;
> (D) (C)+Remove contributor role entirely;
> (E) Leave permission as they are today
>
> Sylvain’s vote was D C E B A, meaning he prefers option D first, option C second, option E third, etc.
>
> There are multiple ranked voting <https://en.wikipedia.org/wiki/Ranked_voting> schemes, but unless anyone objects I will resolve the answers with instant-runoff voting <https://en.wikipedia.org/wiki/Instant-runoff_voting>, which is equivalent to single transferable voting <https://en.wikipedia.org/wiki/Single_transferable_vote> when there is only a single outcome, as there is here.
>
>
>> On 11 Dec 2018, at 20:25, andre wilkinson <an...@me.com.INVALID> wrote:
>>
>> Hey everyone,
>> Im just trying to keep up but I don’t think everyone needs permissions just contributors im trying to understand the letter voting system so I could better be of service to the community. Sorry if I sound naive.
>>
>>> On Dec 11, 2018, at 12:12 PM, Sylvain Lebresne <le...@gmail.com> wrote:
>>>
>>> 1: D C E B A (with a particularly strong feeling against A)
>>> 2: A B C
>>> 3: A (but don't mind much overall)
>>> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
>>> type really)
>>> --
>>> Sylvain
>>>
>>>
>>> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
>>> <al...@apple.com.invalid> wrote:
>>>
>>>> 1. C, D, A, B, E
>>>> 2. B, C, A
>>>> 3. A
>>>> 4. Meh
>>>>
>>>>> On 11 Dec 2018, at 16:28, Benedict Elliott Smith <be...@apache.org>
>>>> wrote:
>>>>>
>>>>> Just to re-summarise the questions for people:
>>>>>
>>>>> 1. (A) Only contributors may edit or transition issues; (B) Only
>>>> contributors may transition issues; (C) Only Jira-users may transition
>>>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>>>> they are today
>>>>> 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
>>>>>
>>>>> With my answers (again, sorry):
>>>>>
>>>>> 1: A B C D E
>>>>> 2: B C A
>>>>> 3: A
>>>>> 4: +0.5
>>>>>
>>>>>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org>
>>>> wrote:
>>>>>>
>>>>>> It looks like we have a multiplicity of views on permissions, so
>>>> perhaps we should complicate this particular vote with all of the possible
>>>> options that have been raised so far (including one off-list). Sorry
>>>> everyone for the confusion.
>>>>>>
>>>>>> (A) Only contributors may edit or transition issues; (B) Only
>>>> contributors may transition issues; (C) Only Jira-users may transition
>>>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>>>> they are today
>>>>>>
>>>>>> * Today apparently ‘Anyone’ can perform this operation
>>>>>>
>>>>>> A ranked vote, please. This makes my votes:
>>>>>>
>>>>>> 1: A B C D E
>>>>>> 2: B C A
>>>>>> 3: A
>>>>>> 4: +0.5
>>>>>>
>>>>>>
>>>>>>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID>
>>>> wrote:
>>>>>>>
>>>>>>> I agree with this. I generally am on the side of freedom and
>>>> responsibility. Limiting edits to certain fields turns people off.
>>>> Something I want to very much avoid if we can.
>>>>>>>
>>>>>>> Dinesh
>>>>>>>
>>>>>>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>>>> murukesh.mohanan@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>>>>>> <be...@apache.org> 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
>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> That would be disappointing. Descriptions with broken or no formatting
>>>>>>>> aren't rare (say, command output without code formatting). And every
>>>>>>>> now and then the description might need to be updated. For example, in
>>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
>>>> the
>>>>>>>> paper had rotted, but I managed to find a new one, so I could edit it
>>>>>>>> in. If such a change had to be posted as a comment, it might easily
>>>>>>>> get lost in some of the more active issues.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
Hi Andre,
It’s ranked vote, i.e. for each question, what is your preference order for the outcome?
So, for question 1, the possible outcomes are:
(A) Only contributors may edit or transition issues;
(B) Only contributors may transition issues;
(C) Only Jira-users may transition issues;
(D) (C)+Remove contributor role entirely;
(E) Leave permission as they are today
Sylvain’s vote was D C E B A, meaning he prefers option D first, option C second, option E third, etc.
There are multiple ranked voting <https://en.wikipedia.org/wiki/Ranked_voting> schemes, but unless anyone objects I will resolve the answers with instant-runoff voting <https://en.wikipedia.org/wiki/Instant-runoff_voting>, which is equivalent to single transferable voting <https://en.wikipedia.org/wiki/Single_transferable_vote> when there is only a single outcome, as there is here.
> On 11 Dec 2018, at 20:25, andre wilkinson <an...@me.com.INVALID> wrote:
>
> Hey everyone,
> Im just trying to keep up but I don’t think everyone needs permissions just contributors im trying to understand the letter voting system so I could better be of service to the community. Sorry if I sound naive.
>
>> On Dec 11, 2018, at 12:12 PM, Sylvain Lebresne <le...@gmail.com> wrote:
>>
>> 1: D C E B A (with a particularly strong feeling against A)
>> 2: A B C
>> 3: A (but don't mind much overall)
>> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
>> type really)
>> --
>> Sylvain
>>
>>
>> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
>> <al...@apple.com.invalid> wrote:
>>
>>> 1. C, D, A, B, E
>>> 2. B, C, A
>>> 3. A
>>> 4. Meh
>>>
>>>> On 11 Dec 2018, at 16:28, Benedict Elliott Smith <be...@apache.org>
>>> wrote:
>>>>
>>>> Just to re-summarise the questions for people:
>>>>
>>>> 1. (A) Only contributors may edit or transition issues; (B) Only
>>> contributors may transition issues; (C) Only Jira-users may transition
>>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>>> they are today
>>>> 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
>>>>
>>>> With my answers (again, sorry):
>>>>
>>>> 1: A B C D E
>>>> 2: B C A
>>>> 3: A
>>>> 4: +0.5
>>>>
>>>>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org>
>>> wrote:
>>>>>
>>>>> It looks like we have a multiplicity of views on permissions, so
>>> perhaps we should complicate this particular vote with all of the possible
>>> options that have been raised so far (including one off-list). Sorry
>>> everyone for the confusion.
>>>>>
>>>>> (A) Only contributors may edit or transition issues; (B) Only
>>> contributors may transition issues; (C) Only Jira-users may transition
>>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>>> they are today
>>>>>
>>>>> * Today apparently ‘Anyone’ can perform this operation
>>>>>
>>>>> A ranked vote, please. This makes my votes:
>>>>>
>>>>> 1: A B C D E
>>>>> 2: B C A
>>>>> 3: A
>>>>> 4: +0.5
>>>>>
>>>>>
>>>>>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID>
>>> wrote:
>>>>>>
>>>>>> I agree with this. I generally am on the side of freedom and
>>> responsibility. Limiting edits to certain fields turns people off.
>>> Something I want to very much avoid if we can.
>>>>>>
>>>>>> Dinesh
>>>>>>
>>>>>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>>> murukesh.mohanan@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>>>>> <be...@apache.org> 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
>>>>
>>>>>>>>
>>>>>>>
>>>>>>> That would be disappointing. Descriptions with broken or no formatting
>>>>>>> aren't rare (say, command output without code formatting). And every
>>>>>>> now and then the description might need to be updated. For example, in
>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
>>> the
>>>>>>> paper had rotted, but I managed to find a new one, so I could edit it
>>>>>>> in. If such a change had to be posted as a comment, it might easily
>>>>>>> get lost in some of the more active issues.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by andre wilkinson <an...@me.com.INVALID>.
Hey everyone,
Im just trying to keep up but I don’t think everyone needs permissions just contributors im trying to understand the letter voting system so I could better be of service to the community. Sorry if I sound naive.
> On Dec 11, 2018, at 12:12 PM, Sylvain Lebresne <le...@gmail.com> wrote:
>
> 1: D C E B A (with a particularly strong feeling against A)
> 2: A B C
> 3: A (but don't mind much overall)
> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
> type really)
> --
> Sylvain
>
>
> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
> <al...@apple.com.invalid> wrote:
>
>> 1. C, D, A, B, E
>> 2. B, C, A
>> 3. A
>> 4. Meh
>>
>>> On 11 Dec 2018, at 16:28, Benedict Elliott Smith <be...@apache.org>
>> wrote:
>>>
>>> Just to re-summarise the questions for people:
>>>
>>> 1. (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>> 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
>>>
>>> With my answers (again, sorry):
>>>
>>> 1: A B C D E
>>> 2: B C A
>>> 3: A
>>> 4: +0.5
>>>
>>>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org>
>> wrote:
>>>>
>>>> It looks like we have a multiplicity of views on permissions, so
>> perhaps we should complicate this particular vote with all of the possible
>> options that have been raised so far (including one off-list). Sorry
>> everyone for the confusion.
>>>>
>>>> (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>>>
>>>> * Today apparently ‘Anyone’ can perform this operation
>>>>
>>>> A ranked vote, please. This makes my votes:
>>>>
>>>> 1: A B C D E
>>>> 2: B C A
>>>> 3: A
>>>> 4: +0.5
>>>>
>>>>
>>>>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID>
>> wrote:
>>>>>
>>>>> I agree with this. I generally am on the side of freedom and
>> responsibility. Limiting edits to certain fields turns people off.
>> Something I want to very much avoid if we can.
>>>>>
>>>>> Dinesh
>>>>>
>>>>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>> murukesh.mohanan@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>>>> <be...@apache.org> 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
>>>
>>>>>>>
>>>>>>
>>>>>> That would be disappointing. Descriptions with broken or no formatting
>>>>>> aren't rare (say, command output without code formatting). And every
>>>>>> now and then the description might need to be updated. For example, in
>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
>> the
>>>>>> paper had rotted, but I managed to find a new one, so I could edit it
>>>>>> in. If such a change had to be posted as a comment, it might easily
>>>>>> get lost in some of the more active issues.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
Thanks. To clarify, a negative result for Q4 had intended to be interpreted as the elimination of ‘Wish’ entirely; nobody has indicated any love for the Wish issue type as yet, so not replacing it would mean it disappears. That is, unless there are several strong sentiments otherwise.
It sounds like you may have meant to indicate -1, but not sure.
> On 11 Dec 2018, at 20:12, Sylvain Lebresne <le...@gmail.com> wrote:
>
> 1: D C E B A (with a particularly strong feeling against A)
> 2: A B C
> 3: A (but don't mind much overall)
> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
> type really)
> --
> Sylvain
>
>
> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
> <al...@apple.com.invalid> wrote:
>
>> 1. C, D, A, B, E
>> 2. B, C, A
>> 3. A
>> 4. Meh
>>
>>> On 11 Dec 2018, at 16:28, Benedict Elliott Smith <be...@apache.org>
>> wrote:
>>>
>>> Just to re-summarise the questions for people:
>>>
>>> 1. (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>> 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
>>>
>>> With my answers (again, sorry):
>>>
>>> 1: A B C D E
>>> 2: B C A
>>> 3: A
>>> 4: +0.5
>>>
>>>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org>
>> wrote:
>>>>
>>>> It looks like we have a multiplicity of views on permissions, so
>> perhaps we should complicate this particular vote with all of the possible
>> options that have been raised so far (including one off-list). Sorry
>> everyone for the confusion.
>>>>
>>>> (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>>>
>>>> * Today apparently ‘Anyone’ can perform this operation
>>>>
>>>> A ranked vote, please. This makes my votes:
>>>>
>>>> 1: A B C D E
>>>> 2: B C A
>>>> 3: A
>>>> 4: +0.5
>>>>
>>>>
>>>>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID>
>> wrote:
>>>>>
>>>>> I agree with this. I generally am on the side of freedom and
>> responsibility. Limiting edits to certain fields turns people off.
>> Something I want to very much avoid if we can.
>>>>>
>>>>> Dinesh
>>>>>
>>>>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>> murukesh.mohanan@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>>>> <be...@apache.org> 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
>>>
>>>>>>>
>>>>>>
>>>>>> That would be disappointing. Descriptions with broken or no formatting
>>>>>> aren't rare (say, command output without code formatting). And every
>>>>>> now and then the description might need to be updated. For example, in
>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
>> the
>>>>>> paper had rotted, but I managed to find a new one, so I could edit it
>>>>>> in. If such a change had to be posted as a comment, it might easily
>>>>>> get lost in some of the more active issues.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Sylvain Lebresne <le...@gmail.com>.
1: D C E B A (with a particularly strong feeling against A)
2: A B C
3: A (but don't mind much overall)
4: Don't mind (I neither particularly like 'wish' as a priority or issue
type really)
--
Sylvain
On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
<al...@apple.com.invalid> wrote:
> 1. C, D, A, B, E
> 2. B, C, A
> 3. A
> 4. Meh
>
> > On 11 Dec 2018, at 16:28, Benedict Elliott Smith <be...@apache.org>
> wrote:
> >
> > Just to re-summarise the questions for people:
> >
> > 1. (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> > 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
> >
> > With my answers (again, sorry):
> >
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> >
> >> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org>
> wrote:
> >>
> >> It looks like we have a multiplicity of views on permissions, so
> perhaps we should complicate this particular vote with all of the possible
> options that have been raised so far (including one off-list). Sorry
> everyone for the confusion.
> >>
> >> (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> >>
> >> * Today apparently ‘Anyone’ can perform this operation
> >>
> >> A ranked vote, please. This makes my votes:
> >>
> >> 1: A B C D E
> >> 2: B C A
> >> 3: A
> >> 4: +0.5
> >>
> >>
> >>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID>
> wrote:
> >>>
> >>> I agree with this. I generally am on the side of freedom and
> responsibility. Limiting edits to certain fields turns people off.
> Something I want to very much avoid if we can.
> >>>
> >>> Dinesh
> >>>
> >>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
> murukesh.mohanan@gmail.com> wrote:
> >>>>
> >>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
> >>>> <be...@apache.org> 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
> >
> >>>>>
> >>>>
> >>>> That would be disappointing. Descriptions with broken or no formatting
> >>>> aren't rare (say, command output without code formatting). And every
> >>>> now and then the description might need to be updated. For example, in
> >>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
> the
> >>>> paper had rotted, but I managed to find a new one, so I could edit it
> >>>> in. If such a change had to be posted as a comment, it might easily
> >>>> get lost in some of the more active issues.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: JIRA Workflow Proposals
Posted by Aleksey Yeshchenko <al...@apple.com.INVALID>.
1. C, D, A, B, E
2. B, C, A
3. A
4. Meh
> On 11 Dec 2018, at 16:28, Benedict Elliott Smith <be...@apache.org> wrote:
>
> Just to re-summarise the questions for people:
>
> 1. (A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today
> 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
>
> With my answers (again, sorry):
>
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
>
>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org> wrote:
>>
>> It looks like we have a multiplicity of views on permissions, so perhaps we should complicate this particular vote with all of the possible options that have been raised so far (including one off-list). Sorry everyone for the confusion.
>>
>> (A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today
>>
>> * Today apparently ‘Anyone’ can perform this operation
>>
>> A ranked vote, please. This makes my votes:
>>
>> 1: A B C D E
>> 2: B C A
>> 3: A
>> 4: +0.5
>>
>>
>>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID> wrote:
>>>
>>> I agree with this. I generally am on the side of freedom and responsibility. Limiting edits to certain fields turns people off. Something I want to very much avoid if we can.
>>>
>>> Dinesh
>>>
>>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <mu...@gmail.com> wrote:
>>>>
>>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>> <be...@apache.org> 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>
>>>>>
>>>>
>>>> That would be disappointing. Descriptions with broken or no formatting
>>>> aren't rare (say, command output without code formatting). And every
>>>> now and then the description might need to be updated. For example, in
>>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>>>> paper had rotted, but I managed to find a new one, so I could edit it
>>>> in. If such a change had to be posted as a comment, it might easily
>>>> get lost in some of the more active issues.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Sam Tunnicliffe <sa...@beobal.com>.
1: D C B A E
2: B C A
3: A
4: -1 (get rid of Wish entirely)
Thanks,
Sam
> On 11 Dec 2018, at 22:01, Joseph Lynch <jo...@gmail.com> wrote:
>
> Just my 2c
>
> 1. D C B E A
> 2. B, C, A
> 3. A
> 4. +0.5
>
> -Joey
>
> On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith <be...@apache.org>
> wrote:
>
>> Just to re-summarise the questions for people:
>>
>> 1. (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>> 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
>>
>> With my answers (again, sorry):
>>
>> 1: A B C D E
>> 2: B C A
>> 3: A
>> 4: +0.5
>>
>>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org>
>> wrote:
>>>
>>> It looks like we have a multiplicity of views on permissions, so perhaps
>> we should complicate this particular vote with all of the possible options
>> that have been raised so far (including one off-list). Sorry everyone for
>> the confusion.
>>>
>>> (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>>
>>> * Today apparently ‘Anyone’ can perform this operation
>>>
>>> A ranked vote, please. This makes my votes:
>>>
>>> 1: A B C D E
>>> 2: B C A
>>> 3: A
>>> 4: +0.5
>>>
>>>
>>>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID>
>> wrote:
>>>>
>>>> I agree with this. I generally am on the side of freedom and
>> responsibility. Limiting edits to certain fields turns people off.
>> Something I want to very much avoid if we can.
>>>>
>>>> Dinesh
>>>>
>>>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>> murukesh.mohanan@gmail.com> wrote:
>>>>>
>>>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>>> <be...@apache.org> 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
>>>
>>>>>>
>>>>>
>>>>> That would be disappointing. Descriptions with broken or no formatting
>>>>> aren't rare (say, command output without code formatting). And every
>>>>> now and then the description might need to be updated. For example, in
>>>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>>>>> paper had rotted, but I managed to find a new one, so I could edit it
>>>>> in. If such a change had to be posted as a comment, it might easily
>>>>> get lost in some of the more active issues.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Joseph Lynch <jo...@gmail.com>.
Just my 2c
1. D C B E A
2. B, C, A
3. A
4. +0.5
-Joey
On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith <be...@apache.org>
wrote:
> Just to re-summarise the questions for people:
>
> 1. (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> 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
>
> With my answers (again, sorry):
>
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
>
> > On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org>
> wrote:
> >
> > It looks like we have a multiplicity of views on permissions, so perhaps
> we should complicate this particular vote with all of the possible options
> that have been raised so far (including one off-list). Sorry everyone for
> the confusion.
> >
> > (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> >
> > * Today apparently ‘Anyone’ can perform this operation
> >
> > A ranked vote, please. This makes my votes:
> >
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> >
> >
> >> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID>
> wrote:
> >>
> >> I agree with this. I generally am on the side of freedom and
> responsibility. Limiting edits to certain fields turns people off.
> Something I want to very much avoid if we can.
> >>
> >> Dinesh
> >>
> >>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
> murukesh.mohanan@gmail.com> wrote:
> >>>
> >>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
> >>> <be...@apache.org> 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
> >
> >>>>
> >>>
> >>> That would be disappointing. Descriptions with broken or no formatting
> >>> aren't rare (say, command output without code formatting). And every
> >>> now and then the description might need to be updated. For example, in
> >>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
> >>> paper had rotted, but I managed to find a new one, so I could edit it
> >>> in. If such a change had to be posted as a comment, it might easily
> >>> get lost in some of the more active issues.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
>
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
Just to re-summarise the questions for people:
1. (A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today
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
With my answers (again, sorry):
1: A B C D E
2: B C A
3: A
4: +0.5
> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <be...@apache.org> wrote:
>
> It looks like we have a multiplicity of views on permissions, so perhaps we should complicate this particular vote with all of the possible options that have been raised so far (including one off-list). Sorry everyone for the confusion.
>
> (A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today
>
> * Today apparently ‘Anyone’ can perform this operation
>
> A ranked vote, please. This makes my votes:
>
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
>
>
>> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID> wrote:
>>
>> I agree with this. I generally am on the side of freedom and responsibility. Limiting edits to certain fields turns people off. Something I want to very much avoid if we can.
>>
>> Dinesh
>>
>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <mu...@gmail.com> wrote:
>>>
>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>> <be...@apache.org> 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>
>>>>
>>>
>>> That would be disappointing. Descriptions with broken or no formatting
>>> aren't rare (say, command output without code formatting). And every
>>> now and then the description might need to be updated. For example, in
>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>>> paper had rotted, but I managed to find a new one, so I could edit it
>>> in. If such a change had to be posted as a comment, it might easily
>>> get lost in some of the more active issues.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
It looks like we have a multiplicity of views on permissions, so perhaps we should complicate this particular vote with all of the possible options that have been raised so far (including one off-list). Sorry everyone for the confusion.
(A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today
* Today apparently ‘Anyone’ can perform this operation
A ranked vote, please. This makes my votes:
1: A B C D E
2: B C A
3: A
4: +0.5
> On 11 Dec 2018, at 05:51, Dinesh Joshi <di...@yahoo.com.INVALID> wrote:
>
> I agree with this. I generally am on the side of freedom and responsibility. Limiting edits to certain fields turns people off. Something I want to very much avoid if we can.
>
> Dinesh
>
>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <mu...@gmail.com> wrote:
>>
>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>> <be...@apache.org> 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>
>>>
>>
>> That would be disappointing. Descriptions with broken or no formatting
>> aren't rare (say, command output without code formatting). And every
>> now and then the description might need to be updated. For example, in
>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>> paper had rotted, but I managed to find a new one, so I could edit it
>> in. If such a change had to be posted as a comment, it might easily
>> get lost in some of the more active issues.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Dinesh Joshi <di...@yahoo.com.INVALID>.
I agree with this. I generally am on the side of freedom and responsibility. Limiting edits to certain fields turns people off. Something I want to very much avoid if we can.
Dinesh
> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <mu...@gmail.com> wrote:
>
> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
> <be...@apache.org> 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>
>>
>
> That would be disappointing. Descriptions with broken or no formatting
> aren't rare (say, command output without code formatting). And every
> now and then the description might need to be updated. For example, in
> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
> paper had rotted, but I managed to find a new one, so I could edit it
> in. If such a change had to be posted as a comment, it might easily
> get lost in some of the more active issues.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Murukesh Mohanan <mu...@gmail.com>.
On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
<be...@apache.org> 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>
>
That would be disappointing. Descriptions with broken or no formatting
aren't rare (say, command output without code formatting). And every
now and then the description might need to be updated. For example, in
https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
paper had rotted, but I managed to find a new one, so I could edit it
in. If such a change had to be posted as a comment, it might easily
get lost in some of the more active issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Ariel Weisberg <ar...@weisberg.ws>.
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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
> >>>>>>>> benedict@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 <ko...@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 <jm...@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 <
> >>>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org>
> > For additional commands, e-mail: dev-help@cassandra.apache.org <ma...@cassandra.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org <ma...@cassandra.apache.org>
Re: JIRA Workflow Proposals
Posted by Ariel Weisberg <ar...@weisberg.ws>.
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?
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.
RE #4, Do we need to keep wish at all?
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>.
> 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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
> >>>>>> benedict@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 <ko...@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 <jm...@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 <
> >>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
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>.
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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
>
>> 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
>>
>
> 1: A
> 2: +1
> 3: +1
> 4: 0
> 5: +0
> 6: +1
>
>
> If bugs have an objective Severity field then why bother with (a subjective) Priority field?
>
> The Priority field makes sense in the commercial world, but for an open source project? Arn't tickets either an itch to scratch for someone, or not? I might have thought labels were better for "Urgent" and "Wish". No strong opinions though, just my two cents.
Well, I had hoped for a world in which labels would cease to exist. Particularly because discovery with labels is almost impossible - we have almost 500 of them, so good luck guessing which one somebody used (or _should_ use). I can now see the argument for keeping them (so people with a specific need can use them), but for regular project functionality I continue to think they’re a bad fit.
I’ll be sure anyway to add items to poll #2, on using Priority for the Bug issue type, and for the Wish priority. Thanks.
>
> regards,
> Mick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Mick Semb Wever <mc...@apache.org>.
> 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
>
1: A
2: +1
3: +1
4: 0
5: +0
6: +1
If bugs have an objective Severity field then why bother with (a subjective) Priority field?
The Priority field makes sense in the commercial world, but for an open source project? Arn't tickets either an itch to scratch for someone, or not? I might have thought labels were better for "Urgent" and "Wish". No strong opinions though, just my two cents.
regards,
Mick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Blake Eggleston <be...@apple.com>.
1: A
2: +1
3: +1
4: +1
5: +1
6: +1
> On Dec 4, 2018, at 11:19 AM, Benedict Elliott Smith <be...@apache.org> wrote:
>
> Sorry, 4. Is inconsistent. First instance should be.
>
>> - 4. Priorities: Keep ‘High' priority
>
>
>> On 4 Dec 2018, at 19:12, Benedict Elliott Smith <benedict@apache.org <ma...@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 <scott@paradoxica.net <ma...@paradoxica.net> <mailto:scott@paradoxica.net <ma...@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> <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> <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 (benedict@apache.org <ma...@apache.org> <mailto:benedict@apache.org <ma...@apache.org>><mailto:benedict@apache.org <ma...@apache.org> <mailto:benedict@apache.org <ma...@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 <benedict@apache.org <ma...@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 <jmckenzie@apache.org <ma...@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 <benedict@apache.org <ma...@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 <jmckenzie@apache.org <ma...@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 <
>>>>>> benedict@apache.org <ma...@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 <kohlisankalp@gmail.com <ma...@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 <jmckenzie@apache.org <ma...@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 <
>>>>>>>> benedict@apache.org <ma...@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>
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>
>>>>>> 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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org> <mailto:dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org>>
>> For additional commands, e-mail: dev-help@cassandra.apache.org <ma...@cassandra.apache.org> <mailto:dev-help@cassandra.apache.org <ma...@cassandra.apache.org>>
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
Sorry, 4. Is inconsistent. First instance should be.
> - 4. Priorities: Keep ‘High' priority
> On 4 Dec 2018, at 19:12, Benedict Elliott Smith <be...@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 <scott@paradoxica.net <ma...@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 (benedict@apache.org <ma...@apache.org><mailto:benedict@apache.org <ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
>>>>> benedict@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 <ko...@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 <jm...@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 <
>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org <ma...@cassandra.apache.org>
> For additional commands, e-mail: dev-help@cassandra.apache.org <ma...@cassandra.apache.org>
Re: JIRA Workflow Proposals
Posted by Joshua McKenzie <jm...@apache.org>.
1: A
2: +1
3: +1
4: +1
5: Meh. +0
6: +1
On Wed, Dec 5, 2018 at 2:57 PM Jonathan Haddad <jo...@jonhaddad.com> wrote:
> 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.zhuang@yahoo.com.INVALID
> <ja...@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
> > <be...@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 <le...@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 <
> > benedict@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 (
> > >> benedict@apache.org<ma...@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 <
> benedict@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 <jm...@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 <
> > >> benedict@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 <jm...@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 <
> > >>>>>> benedict@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 <
> kohlisankalp@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 <
> > >> jmckenzie@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 <
> > >>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
> > >>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>
> > >>
> >
>
>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>
Re: JIRA Workflow Proposals
Posted by Jonathan Haddad <jo...@jonhaddad.com>.
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.zhuang@yahoo.com.INVALID
<ja...@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
> <be...@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 <le...@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 <
> benedict@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 (
> >> benedict@apache.org<ma...@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 <benedict@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 <jm...@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 <
> >> benedict@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 <jm...@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 <
> >>>>>> benedict@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 <ko...@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 <
> >> jmckenzie@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 <
> >>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
>
--
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
Thanks everyone for your feedback so far! I think we have a pretty strong consensus for the first questions. I will follow-up later with a new poll; hopefully this will be the last round, so if you have any more questions that haven’t been aired, please do bring them up now.
1: A (+9)
2: +8 -0.1
3: +9
4: +6 -1
5: +2; a lot of meh. (This may be defunct given the problems Sylvain raised, anyway, but we will have to negotiate that with Infra once we have a clear mandate to bring to them)
6: +8
Obviously, feel free to keep your poll answers coming, in case you think the balance will tip. But at this point I’m happy to pre-emptively call it.
> On 6 Dec 2018, at 13:55, Sam Tunnicliffe <sa...@beobal.com> wrote:
>
> 1: A
> 2: +1
> 3: +1
> 4: +1
> 5: +0
> 6: +1
>
> On the question of keeping the contributors-only restriction on moving from Triage->Open, I tend to agree with Benedict that a low barrier can be useful in deterring bogus transitions (accidental or malicious) which keeps the general noise down. I’m thinking of the current situation where tickets are routinely marked "Ready To Commit” and which contributors have to spend time/energy watching for and fixing. That said, that only requires hitting a button not potentially filling out a bunch of fields so maybe we can afford to be permissive in the first instance here and tighten things up if it becomes a problem.
>
>
>> On 6 Dec 2018, at 08:16, Sylvain Lebresne <le...@gmail.com> wrote:
>>
>> Not much to add really, but just to close the loop, responses inline.
>>
>> On Wed, Dec 5, 2018 at 11:58 AM Benedict Elliott Smith <benedict@apache.org <ma...@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 <le...@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.
>>>
>>
>> That's what I feared, and that sucks. And I'm coming short as well of a
>> good alternative that don't require plugins.
>> That said, if push comes to shove, if we just make them free-form but
>> mandatory to get out of triage (with "all" and "none" being explicitly ok
>> values), and have a bit of documentation, there is still a good change
>> we'll get meaningful information out of this. Better than what we have at
>> least.
>>
>>
>>>> - 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.
>>>
>>
>> Yeah, curious to see how other feel. That said, to be clear, I'm not really
>> feeling any strong on this. I'd just prefer trusting people by default to
>> do the right thing, especially when the "JIRA contributor" barrier is so
>> low/largely meaningless, and save ourselves the trouble of having to add
>> people to the "JIRA contributor" list (which, unless something changed, is
>> a tiny bit annoying). Knowing that we can always change the rule to be
>> stricter if people get it wrong too often. But anyway, not super important,
>> just a minor preference of mine.
>>
>>
>>>> - 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.
>>>
>>
>> Fair enough. I really don't mind keeping priority as long as we make clear
>> what it means (and don't mean).
>>
>>
>>>
>>>>
>>>> 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 <
>>> benedict@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 (
>>>>> benedict@apache.org<ma...@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 <benedict@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 <jm...@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 <
>>>>> benedict@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 <jm...@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 <
>>>>>>>>> benedict@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 <ko...@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 <
>>>>> jmckenzie@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 <
>>>>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>
Re: JIRA Workflow Proposals
Posted by Sam Tunnicliffe <sa...@beobal.com>.
1: A
2: +1
3: +1
4: +1
5: +0
6: +1
On the question of keeping the contributors-only restriction on moving from Triage->Open, I tend to agree with Benedict that a low barrier can be useful in deterring bogus transitions (accidental or malicious) which keeps the general noise down. I’m thinking of the current situation where tickets are routinely marked "Ready To Commit” and which contributors have to spend time/energy watching for and fixing. That said, that only requires hitting a button not potentially filling out a bunch of fields so maybe we can afford to be permissive in the first instance here and tighten things up if it becomes a problem.
> On 6 Dec 2018, at 08:16, Sylvain Lebresne <le...@gmail.com> wrote:
>
> Not much to add really, but just to close the loop, responses inline.
>
> On Wed, Dec 5, 2018 at 11:58 AM Benedict Elliott Smith <benedict@apache.org <ma...@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 <le...@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.
>>
>
> That's what I feared, and that sucks. And I'm coming short as well of a
> good alternative that don't require plugins.
> That said, if push comes to shove, if we just make them free-form but
> mandatory to get out of triage (with "all" and "none" being explicitly ok
> values), and have a bit of documentation, there is still a good change
> we'll get meaningful information out of this. Better than what we have at
> least.
>
>
>>> - 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.
>>
>
> Yeah, curious to see how other feel. That said, to be clear, I'm not really
> feeling any strong on this. I'd just prefer trusting people by default to
> do the right thing, especially when the "JIRA contributor" barrier is so
> low/largely meaningless, and save ourselves the trouble of having to add
> people to the "JIRA contributor" list (which, unless something changed, is
> a tiny bit annoying). Knowing that we can always change the rule to be
> stricter if people get it wrong too often. But anyway, not super important,
> just a minor preference of mine.
>
>
>>> - 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.
>>
>
> Fair enough. I really don't mind keeping priority as long as we make clear
> what it means (and don't mean).
>
>
>>
>>>
>>> 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 <
>> benedict@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 (
>>>> benedict@apache.org<ma...@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 <benedict@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 <jm...@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 <
>>>> benedict@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 <jm...@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 <
>>>>>>>> benedict@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 <ko...@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 <
>>>> jmckenzie@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 <
>>>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by "jay.zhuang@yahoo.com.INVALID" <ja...@yahoo.com.INVALID>.
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 <be...@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 <le...@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 <be...@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 (
>> benedict@apache.org<ma...@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 <be...@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 <jm...@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 <
>> benedict@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 <jm...@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 <
>>>>>> benedict@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 <ko...@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 <
>> jmckenzie@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 <
>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
Re: JIRA Workflow Proposals
Posted by Sylvain Lebresne <le...@gmail.com>.
Not much to add really, but just to close the loop, responses inline.
On Wed, Dec 5, 2018 at 11:58 AM Benedict Elliott Smith <be...@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 <le...@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.
>
That's what I feared, and that sucks. And I'm coming short as well of a
good alternative that don't require plugins.
That said, if push comes to shove, if we just make them free-form but
mandatory to get out of triage (with "all" and "none" being explicitly ok
values), and have a bit of documentation, there is still a good change
we'll get meaningful information out of this. Better than what we have at
least.
> > - 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.
>
Yeah, curious to see how other feel. That said, to be clear, I'm not really
feeling any strong on this. I'd just prefer trusting people by default to
do the right thing, especially when the "JIRA contributor" barrier is so
low/largely meaningless, and save ourselves the trouble of having to add
people to the "JIRA contributor" list (which, unless something changed, is
a tiny bit annoying). Knowing that we can always change the rule to be
stricter if people get it wrong too often. But anyway, not super important,
just a minor preference of mine.
> > - 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.
>
Fair enough. I really don't mind keeping priority as long as we make clear
what it means (and don't mean).
>
> >
> > 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 <
> benedict@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 (
> >> benedict@apache.org<ma...@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 <benedict@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 <jm...@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 <
> >> benedict@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 <jm...@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 <
> >>>>>> benedict@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 <ko...@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 <
> >> jmckenzie@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 <
> >>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
>
>
Re: JIRA Workflow Proposals
Posted by Benedict Elliott Smith <be...@apache.org>.
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 <le...@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 <be...@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 (
>> benedict@apache.org<ma...@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 <be...@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 <jm...@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 <
>> benedict@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 <jm...@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 <
>>>>>> benedict@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 <ko...@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 <
>> jmckenzie@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 <
>>>>>>>> benedict@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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
Re: JIRA Workflow Proposals
Posted by Sylvain Lebresne <le...@gmail.com>.
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?
- 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.
- 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?
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 <be...@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 (
> benedict@apache.org<ma...@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 <be...@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 <jm...@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 <
> benedict@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 <jm...@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 <
> >>>> benedict@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 <ko...@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 <
> jmckenzie@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 <
> >>>>>> benedict@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-unsubscribe@cassandra.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: JIRA Workflow Proposals
Posted by Ariel Weisberg <ar...@weisberg.ws>.
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 (benedict@apache.org<ma...@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 <be...@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 <jm...@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 <be...@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 <jm...@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 <
> >>>> benedict@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 <ko...@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 <jm...@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 <
> >>>>>> benedict@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-unsubscribe@cassandra.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: JIRA Workflow Proposals
Posted by Nate McCall <zz...@gmail.com>.
> 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
>
1: A
2: +1
3: +1
4: +1
5: +0
6: +1
(Appreciate the good discussion here as well - thx everyone!)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org