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 <b...@smart-cactus.org>, 2 Tem 2019 Sal, 16:58 tarihinde şunu yazdı: > > Matthew Pickering <matthewtpicker...@gmail.com> 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
