Weight field in issues too fine grained?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Weight field in issues too fine grained?

Ömer Sinan Ağacan
Hi,

One of the problems I'm having when triaging is that I think the "weight" field
for issues is currently too fine grained. The triage protocol[1] gives some idea
but it's still up to the person who's doing triaging to decide, for example,
between 7 vs. 10 for a runtime crash.

I think a better "weight" field would be what we had in trac: highest, high,
normal etc. that way we don't have to decide whether a runtime panic is 8 or 9
or 10, we'd just mark it as "highest".

Now if we had a lot of issues with weight 8, 9, 10 etc. perhaps we'd use the
weight field to prioritize, but in my experience we usually have very little
such issues and they all get fixed before the next release, so the distinction
between e.g. 8 vs. 9 is not useful or meaningful.

Is it possible to do switch to trac-style priority/weight field in Gitlab?
Anyone else think that this would be good?

Ömer

[1]: https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#triage-protocol
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Weight field in issues too fine grained?

Bryan Richter-2
On Tue, 2 Jul 2019, 9.05 Ömer Sinan Ağacan, <[hidden email]> wrote:

Is it possible to do switch to trac-style priority/weight field in Gitlab?
Anyone else think that this would be good?

Ömer

[1]: https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#triage-protocol

Hi Ömer,

Yes, it's possible to have precisely the same priority labels as in Trac. The feature for this is label prioritization [1].

Weight, in fact, is intended to be used as a measure of size or complexity [2]. But I suppose it could be used however one wants. :)

-Bryan



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Weight field in issues too fine grained?

GHC - devs mailing list
In reply to this post by Ömer Sinan Ağacan
Omer's suggestion makes sense to me

|  -----Original Message-----
|  From: ghc-devs <[hidden email]> On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 02 July 2019 07:05
|  To: ghc-devs <[hidden email]>
|  Subject: Weight field in issues too fine grained?
|  
|  Hi,
|  
|  One of the problems I'm having when triaging is that I think the "weight"
|  field for issues is currently too fine grained. The triage protocol[1]
|  gives some idea but it's still up to the person who's doing triaging to
|  decide, for example, between 7 vs. 10 for a runtime crash.
|  
|  I think a better "weight" field would be what we had in trac: highest,
|  high, normal etc. that way we don't have to decide whether a runtime panic
|  is 8 or 9 or 10, we'd just mark it as "highest".
|  
|  Now if we had a lot of issues with weight 8, 9, 10 etc. perhaps we'd use
|  the weight field to prioritize, but in my experience we usually have very
|  little such issues and they all get fixed before the next release, so the
|  distinction between e.g. 8 vs. 9 is not useful or meaningful.
|  
|  Is it possible to do switch to trac-style priority/weight field in Gitlab?
|  Anyone else think that this would be good?
|  
|  Ömer
|  
|  [1]:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
|  askell.org%2Fghc%2Fghc%2Fwikis%2Fgitlab%2Fissues%23triage-
|  protocol&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cdc6955690c0d48921a75
|  08d6feb34b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369764433521776
|  50&amp;sdata=tbQhiSFrkZZIRMNt3nal3nO7im53pENC1%2F121kRWioo%3D&amp;reserved
|  =0
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
|  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cdc6955690c0d48921a7508d6
|  feb34b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636976443352177650&a
|  mp;sdata=ZMY2yF%2BkMwR0%2FCVwbIBh%2B5GKXcO%2FAK4QXXrnF7MWMFY%3D&amp;reserv
|  ed=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Weight field in issues too fine grained?

Matthew Pickering
It isn't possible to change how the weight field works but as Bryan
points out we could use some of the more advanced label features.

A scoped label (https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium)
could be suitable for weight so that it is enforced that each issue
only has one weight.

Currently my understanding of weight is that

1. (Obviously) hIgh priority issues are marked as 10
2. (Obviously) low priority issues are marked as 3
3. Everything else is left as

Cheers,

Matt

On Tue, Jul 2, 2019 at 8:54 AM Simon Peyton Jones via ghc-devs
<[hidden email]> wrote:

>
> Omer's suggestion makes sense to me
>
> |  -----Original Message-----
> |  From: ghc-devs <[hidden email]> On Behalf Of Ömer Sinan
> |  Agacan
> |  Sent: 02 July 2019 07:05
> |  To: ghc-devs <[hidden email]>
> |  Subject: Weight field in issues too fine grained?
> |
> |  Hi,
> |
> |  One of the problems I'm having when triaging is that I think the "weight"
> |  field for issues is currently too fine grained. The triage protocol[1]
> |  gives some idea but it's still up to the person who's doing triaging to
> |  decide, for example, between 7 vs. 10 for a runtime crash.
> |
> |  I think a better "weight" field would be what we had in trac: highest,
> |  high, normal etc. that way we don't have to decide whether a runtime panic
> |  is 8 or 9 or 10, we'd just mark it as "highest".
> |
> |  Now if we had a lot of issues with weight 8, 9, 10 etc. perhaps we'd use
> |  the weight field to prioritize, but in my experience we usually have very
> |  little such issues and they all get fixed before the next release, so the
> |  distinction between e.g. 8 vs. 9 is not useful or meaningful.
> |
> |  Is it possible to do switch to trac-style priority/weight field in Gitlab?
> |  Anyone else think that this would be good?
> |
> |  Ömer
> |
> |  [1]:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> |  askell.org%2Fghc%2Fghc%2Fwikis%2Fgitlab%2Fissues%23triage-
> |  protocol&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cdc6955690c0d48921a75
> |  08d6feb34b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369764433521776
> |  50&amp;sdata=tbQhiSFrkZZIRMNt3nal3nO7im53pENC1%2F121kRWioo%3D&amp;reserved
> |  =0
> |  _______________________________________________
> |  ghc-devs mailing list
> |  [hidden email]
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cdc6955690c0d48921a7508d6
> |  feb34b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636976443352177650&a
> |  mp;sdata=ZMY2yF%2BkMwR0%2FCVwbIBh%2B5GKXcO%2FAK4QXXrnF7MWMFY%3D&amp;reserv
> |  ed=0
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Weight field in issues too fine grained?

Ben Gamari-2
Matthew Pickering <[hidden email]> writes:

> It isn't possible to change how the weight field works but as Bryan
> points out we could use some of the more advanced label features.
>
> A scoped label (https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium)
> could be suitable for weight so that it is enforced that each issue
> only has one weight.
>
> Currently my understanding of weight is that
>
> 1. (Obviously) hIgh priority issues are marked as 10
> 2. (Obviously) low priority issues are marked as 3
> 3. Everything else is left as
>
Right. I would suggest that we convert the weight field into two
(mutually exclusive) labels:

 * P::High would be category (1)
 * P::Low would be category (2)
 * No P::* label would imply categoy (3)

Does this sound reasonable to everyone? I could cobble together a script
to make this change in about 10 minutes if so.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Weight field in issues too fine grained?

Ömer Sinan Ağacan
I think we may want two different weights "high" and "highest".

- Highest: regressions, incorrect results, runtime panics/crashes. These are
  release blockers.
- High: other bugs

Other than that this sounds good to me.

I don't remember how many kinds of priorities we had in trac but IIRC it used to
work well, I think we can just copy the old priorities as labels.

Ömer

Ben Gamari <[hidden email]>, 2 Tem 2019 Sal, 16:58 tarihinde şunu yazdı:

>
> Matthew Pickering <[hidden email]> writes:
>
> > It isn't possible to change how the weight field works but as Bryan
> > points out we could use some of the more advanced label features.
> >
> > A scoped label (https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium)
> > could be suitable for weight so that it is enforced that each issue
> > only has one weight.
> >
> > Currently my understanding of weight is that
> >
> > 1. (Obviously) hIgh priority issues are marked as 10
> > 2. (Obviously) low priority issues are marked as 3
> > 3. Everything else is left as
> >
> Right. I would suggest that we convert the weight field into two
> (mutually exclusive) labels:
>
>  * P::High would be category (1)
>  * P::Low would be category (2)
>  * No P::* label would imply categoy (3)
>
> Does this sound reasonable to everyone? I could cobble together a script
> to make this change in about 10 minutes if so.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Weight field in issues too fine grained?

Ben Gamari-2
Ömer Sinan Ağacan <[hidden email]> writes:

> I think we may want two different weights "high" and "highest".
>
> - Highest: regressions, incorrect results, runtime panics/crashes. These are
>   release blockers.
> - High: other bugs
>
> Other than that this sounds good to me.
>
A fair point. Sounds fine to me.

> I don't remember how many kinds of priorities we had in trac but IIRC it used to
> work well, I think we can just copy the old priorities as labels.
>
Trac had lowest, low, normal, high, and highest, IIRC.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Weight field in issues too fine grained?

Ben Gamari-2
In reply to this post by Ben Gamari-2
Ben Gamari <[hidden email]> writes:

> Right. I would suggest that we convert the weight field into two
> (mutually exclusive) labels:
>
>  * P::High would be category (1)
>  * P::Low would be category (2)
>  * No P::* label would imply categoy (3)
>
> Does this sound reasonable to everyone? I could cobble together a script
> to make this change in about 10 minutes if so.

I have
I have posted this script here [1].

Cheers,

- Ben


[1] https://gitlab.haskell.org/bgamari/gitlab-migration/snippets/1457

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Weight field in issues too fine grained?

GHC - devs mailing list
Hang on.

| >  * P::High would be category (1)
| >  * P::Low would be category (2)
| >  * No P::* label would imply categoy (3)

Let's have P:High, P:Medium, P:Low, with no "P:" label meaning "no one has assigned it a priority yet".

It's very important to be able to distinguish "no one has assigned a priority" from "priority has been assigned as low".

Simon


| -----Original Message-----
| From: Ben Gamari <[hidden email]>
| Sent: 02 July 2019 17:13
| To: Matthew Pickering <[hidden email]>; Simon Peyton Jones
| <[hidden email]>
| Cc: ghc-devs <[hidden email]>
| Subject: Re: Weight field in issues too fine grained?
|
| Ben Gamari <[hidden email]> writes:
|
| > Right. I would suggest that we convert the weight field into two
| > (mutually exclusive) labels:
| >
| >  * P::High would be category (1)
| >  * P::Low would be category (2)
| >  * No P::* label would imply categoy (3)
| >
| > Does this sound reasonable to everyone? I could cobble together a
| > script to make this change in about 10 minutes if so.
|
| I have
| I have posted this script here [1].
|
| Cheers,
|
| - Ben
|
|
| [1] https://gitlab.haskell.org/bgamari/gitlab-migration/snippets/1457
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Weight field in issues too fine grained?

Ben Gamari-2
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> Hang on.
>
> | >  * P::High would be category (1)
> | >  * P::Low would be category (2)
> | >  * No P::* label would imply categoy (3)
>
> Let's have P:High, P:Medium, P:Low, with no "P:" label meaning "no one
> has assigned it a priority yet".
>
> It's very important to be able to distinguish "no one has assigned a
> priority" from "priority has been assigned as low".
>
The initial thought was that a ticket without the "needs triage" label
would have a valid priority. Consequently a ticket without "needs
triage" and no "P::*" label would have medium priority.

However, while writing this it does seem that this is a non-trivial
invariant that leaves a bit too much implicit. Perhaps an explicit
P::normal label is best. I'll update the script.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Weight field in issues too fine grained?

GHC - devs mailing list
Moreover, then we don't need "Needs triage".  Anything without a P: label needs triage!  Triage = assign a P: label.   Nice

Simon

| -----Original Message-----
| From: Ben Gamari <[hidden email]>
| Sent: 02 July 2019 18:03
| To: Simon Peyton Jones <[hidden email]>; Matthew Pickering
| <[hidden email]>
| Cc: ghc-devs <[hidden email]>
| Subject: RE: Weight field in issues too fine grained?
|
| Simon Peyton Jones via ghc-devs <[hidden email]> writes:
|
| > Hang on.
| >
| > | >  * P::High would be category (1)
| > | >  * P::Low would be category (2)
| > | >  * No P::* label would imply categoy (3)
| >
| > Let's have P:High, P:Medium, P:Low, with no "P:" label meaning "no one
| > has assigned it a priority yet".
| >
| > It's very important to be able to distinguish "no one has assigned a
| > priority" from "priority has been assigned as low".
| >
| The initial thought was that a ticket without the "needs triage" label
| would have a valid priority. Consequently a ticket without "needs triage"
| and no "P::*" label would have medium priority.
|
| However, while writing this it does seem that this is a non-trivial
| invariant that leaves a bit too much implicit. Perhaps an explicit
| P::normal label is best. I'll update the script.
|
| Cheers,
|
| - Ben
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs