Re: JIRA Workflow Proposals

[Blake Eggleston]

1: A
2: +1
3: +1
4: +1
5: +1
6: +1

> On Dec 4, 2018, at 11:19 AM, Benedict Elliott Smith  
> wrote:
> 
> Sorry, 4. Is inconsistent.  First instance should be.
> 
>> - 4. Priorities: Keep ‘High' priority
> 
> 
>> On 4 Dec 2018, at 19: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: 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 >>  >> >> 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>>  
>>> >> >>). 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” 

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Sorry, 4. Is inconsistent.  First instance should be.

> - 4. Priorities: Keep ‘High' priority


> On 4 Dec 2018, at 19: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: 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 > > 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> >). 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 

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

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  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). 
> 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