search

rust-lang / triagebot

Automation/tooling for Rust spaces
https://triage.rust-lang.org
Apache License 2.0
170 stars 74 forks source link

Support GitHub's rendered label syntax #1633

Closed dtolnay closed 2 years ago

dtolnay commented 2 years ago

See https://github.blog/changelog/2022-02-03-reference-labels-in-markdown/.

@rustbot label https://github.com/rust-lang/triagebot/labels/T-libs https://github.com/rust-lang/triagebot/labels/help%20wanted

rustbot commented 2 years ago

Error: Parsing relabel command in comment failed: ...'abel https' | error: a label delta at >| '://github.'...

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

apiraino commented 2 years ago

A mild :-1: from me as it would add a bit of confusion to the github web UI (already quite crowded and deteriorating in quality). All in imho.

Mark-Simulacrum commented 2 years ago

@apiraino say more? I personally somewhat doubt folks using this (it seems hard to imagine coming up with the URL manually, and if you're copy/pasting it's still more text to copy/paste), but I don't think it makes things worse for triagebot to support it.

It does seem like a good idea to support the feature, since GitHub has added it, even if adding it would not have been my decision...

apiraino commented 2 years ago

I'm not fully convinced of the new UI that github suggests. It mixes up user action to the result of that action.

Current version: screenshot-20220703-021553

1) The user action of adding a label is not flashy (good) 2) The result is instead more prominent (gh adds a colored comment) and my eyes parsing that page jump immediately where I see the rendered labels to register that someone changed them.

New proposed UI from Github screenshot-20220703-025025

They both are rendered as widgets, at a glance it's slightly harder to tell the action from the result. How many times were these labels changed? When I scroll fast many issues (which I do) that adds to the visual noise.

It does seem like a good idea to support the feature, since GitHub has added it, even if adding it would not have been my decision

imo supporting every gh new feature is not mandatory. They throw things at us but it's up to us to choose what to adopt.

Mark-Simulacrum commented 2 years ago

imo supporting every gh new feature is not mandatory. They throw things at us but it's up to us to choose what to adopt.

I think this is true, but it's also true that if users happen to use this new format (which I expect to be rare) it's a little annoying for us to tell them not to. I think we're on the same page in terms of this not being a great feature on GitHub's side, though.

@dtolnay were you hoping to use this somewhere? Just wanted to implement it? Curious on the motivation on your side.

dtolnay commented 2 years ago

I would have used this but apiraino's explanation of the downsides is compelling. I did not consider that. Let's close this.

If the GitHub editor widget ever implements autocomplete for label names like it does for issue numbers and usernames (and they become URLs) then we may want to reconsider at that point, but I don't have any indication that is on the way.

Mark-Simulacrum commented 2 years ago

OK, sounds good. Should be pretty easy to reopen and land if GitHub lands autocomplete support.

apiraino commented 2 years ago

thanks for reconsidering this addition.