Manually downgraded issue auto-upgraded

[samuelweiler]

See w3cping/tracking-issues#89

And it happened six days later. I like automated tools, but a six day lag? Ick. (also, if we need to downgrade in both repos, that needs to be documented.)

[plehegar]

I fixed a bug yesterday and that's what caused it to act. With the change, it would have to be removed on both sides.

[plehegar]

btw, I think there are 2 options here:
1- if needs-resolution is on a spec issue, the horizontal issue is upgraded to needs-resolution. So one will need to remove the needs-resoltuion on both to downgrade them to "tracker" only.
2. Except if an horizontal issue is newly created, a "needs-resolution" label on a spec issue does not affect the corresponding horizontal issue. It's only when a needs-resolution is set on an horizontal issue that the corresponding spec issue will be automatically upgraded.

As of yesterday, the tool does #1 but happy to tweak as needed.

[plehegar]

(side note, option 1 is implemented in 39bad09 )

[samuelweiler]

Not sure what you're meaning with #2; might be the "except". I'm okay with having to downgrade both places, but we'll need to update docs to say that. (e.g. "needs-resolution is dominant; to remove it, it must be removed from both the tracking issue and the underlying issue")

[r12a]

I'm a little wary of automating this. The tooling reported a bunch of issues with mismatching labels a few days ago, and i manually synchronised them. However, in some cases i converted both labels to needs-resolution, but in other cases both went to tracker. It came down to a judgement call.

I suspect that it may be more useful to send automated mails out if a mismatch is detected.

Generally speaking, i think the HR repo labels should always be treated as authoritative. But if someone, changes a WG repo label, it may be better to advise the HR group of the discrepancy rather than automatically synchronise, because the tooling doesn't know whether the change was an incomplete action by an HR person, or an erroneous action by a WG person. In the latter case, the WG person needs to be told not to change the labels anyway, or they will do so again (either for this issue or for others).

[r12a]

If the change is made in the HR repo, it's presumably by someone who knows what they are doing, so maybe it is ok to automatically adjust the spec WG issue to match. However, if the status changes the HR group really needs to comment on the WG repo issue anyway, to indicate that they changed their mind, and in the case of elevation to needs-resolution, they ought to ensure that the desired resolution for the HR group is clearly stated.

[samuelweiler]

The way PLH rolled out the tool to PING implied that we no longer needed to manually create tracker issues (though there might be semantic value in doing so), and doing so has added hoops that I have not yet tried to explain to PING's chairs and participants. I'm bouncing between happiness with the rapid-prototyping approach here - where something was just thrown over the wall - and grumpiness that the semantics and workflow are still so very up in the air. I realize those feelings may be in conflict.

[r12a]

I don't know whether this back story is useful....

We asked PLH NOT to implement this for NEW issues, since the process we follow starts with the issue in the HR repo, and then creates a corresponding issue in the WG repo after the i18n WG has discussed it and approved it.

However, PLH's tooling makes a terrific difference when it comes to tracking issues where a spec WG person has added a *-tracker label to an issue in their repo. We no longer have to figure out that they did that (an error-prone and time-consuming task), and it does a good proportion of the donkey-work involved in creating a new tracker issue and populating it with the right tags, links, etc.

However, the tool isn't intelligent enough to do everything - which it why it adds a pending label.

I haven't seen non-i18n pending issues, but i imagine they come with some boilerplate text like:

Instructions:

    check for the following labels, then remove the PENDING label, then delete these instructions

    TRACKER & S:... should be there

    add ADVICE-REQUESTED if the WG-issue is specifically asking for i18n to advise/comment

    add NEEDS-ATTENTION if this is an important issue

(the i18n boilerplate is actually more complicated because we deal with our language enablement subsystem as well)

@samuelweiler does that look familiar.

[plehegar]

Bounced this issue with Richard, he indicated a preference for option 2 above, meaning:

• If there is a spec-issue but no hr issue, the tool will create the hr issue, matching the "needs-resoution" or "tracker" from the spec-issue

• If there is a spec-issue AND an hr issue, the tool will propagate the needs-resolution from the hr issue to the spec issue. If there is a needs-resolution on the spec issue but not the hr issue, the tool will only report the discrepancy (to me for now, but the idea is to send such report).

Seeing no preference one way or the other in this thread, I change the tool to do exactly that.

Change is at
576b323

I'll remove that code and clean up after two weeks or so just to make sure we're happy with it.

[samuelweiler]

@r12a, no that boilerplate does not look familiar.

@plehegar : that change does not quite address the case that sparked this issue. In that case, needs-resolution was removed (from the tracking issue). If we need to remove needs-resolution in both places, we need to change the docs to say that.

We also need to document the changes you're describing, one way or another. I've commented on the HOWTO pull request. If we still need to argue over semantics, I'd still like to get the updated docs out in the meantime.

[r12a]

@r12a, no that boilerplate does not look familiar.

That figures. It's one of the boilerplates i set up for raising new issues. I wasn't sure whether PLH had included that kind of information when rolling out the process to other groups. You can see what i mean if you try to open a new issue on the i18n db - in this case, the text comes from Create a tracker. When PLH's tool creates new tracker issues for i18n, it includes relevant bits of those instructions (because i asked him to do that for us). Some of the instructions are i18n specific.