- From: Reece Dunn <msclrhd@googlemail.com>
- Date: Wed, 14 Sep 2022 18:27:31 +0100
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAGdtn27JMT9qnbSy9XY9RS+JVUXC4tq_ek6=xWmy+84wi9+QZg@mail.gmail.com>
On Wed, 14 Sept 2022 at 14:48, Norm Tovey-Walsh <norm@saxonica.com> wrote: > I believe I have created the labels proposed. Let me know if you > disagree. > Thanks for doing this. I think it would be beneficial (having started to categorize the tickets) to have the additional categories: 1. Function -- "A change that introduces a new function". This mirrors the Feature label, and will allow us to identify proposals that add new functions in addition to features. -- Note: I've currently used the "Feature" label for these. 2. Clarification -- "An editorial change that addresses an issue with the way the spec is worded" -- Note that this is not specifically an Editorial (typo fix, etc.) change, nor is an Enhancement, as it is not seeking to extend the behaviour of the current specs (including the draft wording). This label covers things like spec questions (where wording is unclear or ambiguous), and spec issues/bugs. 3. Project -- "A request on the project, including the readme and stylesheets" Can you add those 3 labels, please? Can you add a "4.0" milestone, per the email that Christian Gruen sent out? Thanks. -- It may also be useful later to have a "Future" milestone for proposals that are deemed to be out of scope for this release, but that are not rejected. I'm not sure what priorities the issues should be, so have left assigning those. -- I think it's best to do that as a group. Q: Should we now remove the "[FO]" etc. tags from the start of the issues now that they are labelled with the corresponding spec ID? Kind regards, Reece > In case anyone is curious: > > + I made all the specification labels the same color because I think we > only expect to assign one to any given issue. > + I tried to make the P1/P2/P3 a gradient from red to yellow > + I attempted to apply a gradient over the issue classification as well, > though that’s a bit more arbitrary. > + Green for accepted and red for rejected seemed reasonable. > > If anyone finds the colors difficult to distinguish or lacking in > aesthetic value, feel free to propose alternatives. I don’t feel > strongly about them, but the random collection of colors suggested by > GitHub was an eye watering visual cacophany. > > Be seeing you, > norm > > -- > Norm Tovey-Walsh > Saxonica >
Received on Wednesday, 14 September 2022 17:27:56 UTC