search

w3c / horizontal-issue-tracker

Tools and pages to track horizontal issues
https://www.w3.org/PM/horizontal/
MIT License
6 stars 4 forks source link

Manually downgraded issue auto-upgraded #16

Open samuelweiler opened 4 years ago

samuelweiler commented 4 years ago

See https://github.com/w3cping/tracking-issues/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 commented 4 years ago

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 commented 4 years ago

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.

  1. 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 commented 4 years ago

(side note, option 1 is implemented in https://github.com/w3c/horizontal-issue-tracker/commit/39bad095268e67c5d44d1dccc607cb74618f31dc )

samuelweiler commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

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

Change is at https://github.com/w3c/horizontal-issue-tracker/commit/576b323d1951525e7e036e7e471c6864728d43b8

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

samuelweiler commented 4 years ago

@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 commented 4 years ago

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