Re: JIRA Workflow Proposals

On 2018/11/26 13:39:50, Benedict Elliott Smith 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 <

Re: JIRA Workflow Proposals

On Wed, Dec 12, 2018 at 7:14 PM Benedict Elliott Smith 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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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 +, 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 > > wrote: > > > > Just to re-summarise

Re: JIRA Workflow Proposals

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 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 > wrote: > >> Just to re-summarise

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

Hey Benedict, Thank you. In that case A D E B C > On Dec 11, 2018, at 12:37 PM, Benedict Elliott Smith > 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

Re: JIRA Workflow Proposals

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)

Re: JIRA Workflow Proposals

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 wrote: > > 1: D C

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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 wrote: > 1. C, D, A, B, E > 2. B, C, A >

Re: JIRA Workflow Proposals

1. C, D, A, B, E 2. B, C, A 3. A 4. Meh > On 11 Dec 2018, at 16:28, Benedict Elliott Smith 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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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)

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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 > wrote: > > On Tue, 11 Dec 2018 at 10:51, Benedict Elliott

Re: JIRA Workflow Proposals

On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith wrote: > > On 10 Dec 2018, at 16:21, Ariel Weisberg 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 > >

Re: JIRA Workflow Proposals

On 10 Dec 2018, at 16:21, Ariel Weisberg 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.

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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,

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

> 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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

> On 7 Dec 2018, at 17:52, Ariel Weisberg 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 >

Re: JIRA Workflow Proposals

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,

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

> >> 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:

Re: JIRA Workflow Proposals

> 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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

Thanks. I’ll respond inline with the thinking around the original proposal. > On 5 Dec 2018, at 20:26, Stefan Podkowinski 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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

> 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

Re: JIRA Workflow Proposals

1: A 2: +1 3: +1 4: +1 5: Meh. +0 6: +1 On Wed, Dec 5, 2018 at 2:57 PM Jonathan Haddad 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 > > > >

Re: JIRA Workflow Proposals

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.zhu...@yahoo.com.INVALID wrote: > 1: Component. (A) Multi-select > 2: Labels:

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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.

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

> 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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

Thanks Jo for the feedback too! I’ll keep my responses brief as there are already a lot of discussions in flight. > On 26 Nov 2018, at 16:24, Joseph Lynch wrote: > > Benedict, > > Thank you for putting this document together, I think something like this > will really improve the quality and

Re: JIRA Workflow Proposals

Thanks everyone for the quick initial feedback! I’m going to aggregate my responses here, to try and avoid too much fragmentation of discussion; we’ll see how sensible this is. ===Labels=== I’m not irreconcilably against keeping labels, I just think on balance it’s better to remove them. I

Re: JIRA Workflow Proposals

Benedict, Thank you for putting this document together, I think something like this will really improve the quality and usefulness of the Jira tickets! A few pieces of overall feedback on the proposal: * I agree with Jeremy and Joshua on keeping labels. Labels are the only way that contributors

Re: JIRA Workflow Proposals

Regarding labels, I am personally a fan of both - the mapping of commonly used labels to things like components, features, tools, etc. as well as keeping labels for newer and more arbitrary groupings. I’ve tried to maintain certain labels like virtual-tables, lcs, lwt, fqltool, etc because

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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