Weight field in issues too fine grained?

Matthew Pickering matthewtpickering at gmail.com
Tue Jul 2 09:12:21 UTC 2019


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
<ghc-devs at haskell.org> wrote:
>
> Omer's suggestion makes sense to me
>
> |  -----Original Message-----
> |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ömer Sinan
> |  Agacan
> |  Sent: 02 July 2019 07:05
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  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&data=02%7C01%7Csimonpj%40microsoft.com%7Cdc6955690c0d48921a75
> |  08d6feb34b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369764433521776
> |  50&sdata=tbQhiSFrkZZIRMNt3nal3nO7im53pENC1%2F121kRWioo%3D&reserved
> |  =0
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cdc6955690c0d48921a7508d6
> |  feb34b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636976443352177650&a
> |  mp;sdata=ZMY2yF%2BkMwR0%2FCVwbIBh%2B5GKXcO%2FAK4QXXrnF7MWMFY%3D&reserv
> |  ed=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list