RE: Labels created

You can add more than one label, so in the case of functions,  I planned on tagging both Feature and XQFO. That would obviate the need for the Function label.

From: Reece Dunn <msclrhd@googlemail.com>
Sent: Wednesday, September 14, 2022 1:28 PM
To: Norm Tovey-Walsh <norm@saxonica.com>
Cc: public-xslt-40@w3.org
Subject: Re: Labels created


EXTERNAL
On Wed, 14 Sept 2022 at 14:48, Norm Tovey-Walsh <norm@saxonica.com<mailto: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