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

Omer's suggestion makes sense to me

| -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 02 July 2019 07:05 | To: ghc-devs | 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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 , 2 Tem 2019 Sal, 16:58 tarihinde şunu yazdı:

Matthew Pickering 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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Simon Peyton Jones via ghc-devs 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