Re: Labels created

On Wed, 14 Sept 2022 at 18:35, Edward Porter <Edward.Porter@sas.com> wrote:

> 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.
>

I was thinking of cases like https://github.com/qt4cg/qtspecs/issues/36
that define syntax in addition to functions, as well as cases where XQFO
rules (e.g. operators, casting/conversion) are proposed. There's also the
case where a function can be defined in XSLT for that specifically.

Kind regards,
Reece


>
>
> *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> 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
>
>