New hr labels

[plehegar]

Latest iteration. No -satisfied yet

[r12a]

Need to also change '-tracking' to '-tracker'.

[xfq]

Preview link: https://raw.githack.com/w3c/w3c.github.io/new-hr-labels/issue-metadata.html

[r12a]

Here's my analysis of whether or not a -resolved label is needed, in addition to the -needs-resolution label.

Permutations where needs-resolution label has been applied to an issue:

Group repo: Status
WG: open
HG: closed

Need to check status in HG repo (Closed), and ignore label in WG repo. If HG status not checked, ie. someone just looking at WG repo, this is misleading. The -satisfied label was intended to address this kind of situation by removing the -needs-resolution label in the WG repo.

Group repo: Status
WG: open
HG: open

Checking either repo will indicate unresolved issues.

Group repo: Status
WG: closed
HG: open

Need to check status in HG repo (open), and ignore status of WG repo. This is also misleading if only looking at the WG repo. It could be made less so if the HG changed the -needs-resolution label to -resolved consistently

Group repo: Status
WG: closed
HG: closed

Checking either repo will indicate that the issue is resolved.

Summary When it comes to checking for unresolved issues using a tool prior to a transition, the above has the following implications: if the open/closed status of WG and HG repos is the same, you can simply scan either open issues list for -needs-resolution labels. If, however, one differs from the other, it’s necessary to check the HG repo to find out whether the HG is satisfied; there is no real need to scan the WG repo.

For such automatic scanning to work against the HG repo (where there are -needs-resolution labels for many specs), there needs to be a clear and unambiguous link between the issues in the WG and HG repositories. That probably means tagging each issue in the HG repo using the short-name for each spec reviewed. We mostly do that already, but in some cases we have collapsed more than one closely related and short spec under a single label (eg. uievents also covers uievent-key). It’s probably not a lot of work to separate those.

It may, however, be necessary to indicate the version of the spec (eg. css-writing-modes-3), since it’s only a particular version that is heading for a transition. We have so far avoided that in our HG repo, because we don’t want to track so many labels, and we want a search for, say, writing-modes issues to return all related issues, regardless of versions or how they are moved between versions. We have three options here:

1. continue not to label by version, in which case after getting a list of relevant issues the person doing the transition will need to check whether the issue is version appropriate by looking at the link. However, the HG would need to ensure still that there is a link to the spec for every issue, and change that link if the version changes and the comment is still relevant. Probably not a lot of work, but something that needs to be done.
2. use labels for every version. Again, we’d need to maintain the labels carefully as versions change: for example, old comments that are still relevant to writing-modes-3 would need to have their links updated, as would issues that have been postponed from writing-modes-3 to writing-modes-4 (while level 3 is the current version). In many cases, it may not be clear what the future version would be, or even if there will be one.
3. have two labels for each issue: one for the generic short-name, the other for the versioned short-name. This offers benefits for both purposes, but has the disadvantages of the alternative approaches, while also increasing the number of labels in use.

It should be noted that the versioning is on likely to be important in a very small number of cases. Unless the HG is reviewing both spec versions at the same time, it is likely that the HG will apply a recyle label to the issue and close it in their repo: then re-open only when the new version comes up for review.

There are also implications for the people working on the specification, if the HG doesn’t replace the -needs-resolution label with -resolved - either in open or closed list - in the WG repo, because the only reliable way to check what still needs attention from the pov of the HG is to check the HG's repo.

For example, some WGs close an issue as soon as they think they have an idea how to fix it – long before the edits are made and checked by the HG. If the WG loses sight of the issue but forgets to fix it, they may not realise that the resolution is still outstanding until a check is done during the transition. Similarly, if the HG is satisfied about an issue before it is closed by the WG (perhaps because the issue includes other things) the -needs-resolution tag is misleading.

This was why the -resolved tag was proposed: if the HG applied this consistently while closing issues in its own repo, it would always be possible to get a reliable list of unresolved items from the WG repo (including both open and closed issues). However, the risks for this approach include:

1. the HG may forget to update the WG repo
2. someone in the WG may apply the label, even though the description says that only the HG should do so.

Another small inconvenience of using the -resolved label is that the HG will want to track whether an issue was a review comment (as opposed to a tracker issue, or one of the other types of issue raised in the tracking repo), whether or not the issue was closed. It's slightly easier to do that by searching for needs-resolution labels than by searching for needs-resolution and/or 'resolved'.

Conclusion

Continue for now with just the -needs-resolution issue. The key indicator for whether an issue needs attention is that it hasn't been closed in the HG repo and has that label.

To check for outstanding HG issues prior to a transition, or as part of a WG's work, the only reliable location to check is the HG repo. (It may be useful to remind WGs of this.)

If someone is automatically compiling a list of outstanding HG issues prior to a transition, they may need to look briefly at the list of returned issues to ascertain whether it is for the appropriate version of the spec.

To facilitate automatic checking, we need to ensure that shortnames are used consistently for currently open issues in the HG repo.

[r12a]

I'm now going to start converting the comment and tracking labels to needs-resolution and tracker, respectively in the i18n-activity repo and the associated tools.

[r12a]

Btw, the word 'Affect' should be 'Affects' in most locations in the PR.

[plehegar]

ok, let's merge this PR and, if we want to revisit -resolved, let's open a separate issue