Weight field in issues too fine grained?

[Simon Peyton Jones]

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