Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

    Updating crates.io index
error: failed to select a version for the requirement `core-foundation-sys = "^0.7.1"`
  candidate versions found which didn't match: 0.8.0, 0.7.0, 0.6.2, ...
  location searched: crates.io index
required by package `core-foundation v0.7.1`
    ... which is depended on by `security-framework v0.4.4`
    ... which is depended on by `native-tls v0.2.4`
    ... which is depended on by `postgres-native-tls v0.3.0`
    ... which is depended on by `triagebot v0.1.0 (/home/dependabot/dependabot-updater/dependabot_tmp_dir

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

GitHub issues with < > in the title, such as rust-lang/rust#69163, emit html on the notifications page that contains raw angle brackets, which end up treated by the browser as html tags. We should emit these characters as < and > and similar for any other html characters that need escaping.

Undecided on whether the description given in add commands should be escaped or should allow html tags. I think I would lean toward ideally angle brackets in add commands should also get escaped.

This was noted by @Mark-Simulacrum in #14. If we don't do this it could probably end causing some issue.

As can we seen here https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Support.20const.20parameters.20in.20type.20dependent.20compiler-team.23304/near/202623737 notifications are being triggered twice. cc @Mark-Simulacrum

Essentially so that we prevent unsound, nominated labels being set by just anyone

Consider adopting some of the functionality of @rust-highfive into triagebot.

Things like:

• Greeting new contributors
• Heuristics based assignment of PRs to a random reviewer
• Reassigning PRs in response to r? @username

These are related to things triagebot already does.

Per discussion with @Mark-Simulacrum in the triagebot zulip stream I'm documenting my current workflow for managing active work items and notifications and what features I'd like to see out of triagebot.

Current Workflow

Currently I use github notifications beta to manage my notifications via the web ui, and I have email notifications completely turned off.

For me this is sufficient for keeping track of my notifications but it does not handle the following issues.

• Keeping track of current work items
• Prioritizing current work items
• Making my work queue / notifications queue public to other users on github

For tracking my work items I created a github project board in an otherwise empty repository that I use to track current issues/prs that I'm working on or want to work on. https://github.com/yaahc/prs/projects/1

This has the advantage of being public, and letting me track my current work items, but its painfully manual and its not visible / people rarely find their way to that page to see what I'm working on.

Ideal Workflow

Ideally for me I'd continue to use github notifications ui for all my notifications, but I'd like my current notifications to be made public for other users to consume, though I'd only want notifications from public repos to be visible, for me having the triage bot notifications page be a publicly visible copy of my current notifications would be idea.

For tracking work items I'm not particularly happy with the current state of my project board, mostly because of how manual it is, I often forget to put issues or prs into the board. Ideally a replacement via triagebot would support the following features.

• Track my currently in progress work
• Automatically add newly opened PRs and issues that are assigned to me to my work queue
• Automatically move closed PRs and issues to a done list or remove them from the board entirely
• Link this work queue in places for other contributors / users to find

To me it would be extra cool if all of this worked by integrating with my existing project board, though that's probably a bit of a pipe dream. The most important thing for me is an ordered list of work that is visible enough for other people to see and comment on, but that mostly manages itself so I don't have to constantly go out of my way to remember what I'm working on and add it to the list.

I sent "meta 6 something or other" to triagebot on Zulip and it correctly set the bullet text for that item, but in the process that item ended up at index 5 instead of remaining at 6 as I would expect.

Assuming someone else didn't run "as dtolnay move ..." at the same time. :)

Example shown here: rust-lang/rust#61266

Rustbot didn't do anything when I opened issue but when I copy-pasted the command to the comment it changed labels.

E.g. in an issue like rust-lang/rust#58427, I would like to tell the bot to auto-close an issue (potentially conditional on whether new comments are made).

This could look like: @thebot close 10 days.

I just tried to add an explanatory text after @rustbot claim but it seems the command parser doesn't accept this:

rust-lang/rust#56982 (comment)

Allowing this would bring triagebot in line with bors as well

rust-lang/rust#69387 did not seem to get into my notification queue. I suspect that either we're not listening on the appropriate webhook, or some other (similar) error caused this.

Does GitHub support this?

• https://developer.github.com/changes/2017-11-09-repository-transfer-api-preview/

https://discordapp.com/channels/442252698964721669/443148290352218115/624290071985782784

For the purpose of https://triagebot.infra.rust-lang.org/notifications, me doing an "r? @dtolnay" or mentioning rust-lang/libs should not appear as pinging myself.

See this comment for instance.

One of the cool UX things about dependabot is that it includes the help commands at the end of every response hidden under a summary, which lets you easily look at the available commands without leaving the github thread. It would be nice if triagebot also did this or something similar.

Example

This would:

• Create the label, with the relevant color for the category.
• Label the feature with the label.

Otherwise, it can be confusing since there's no indication of truncation.

Cc @Mark-Simulacrum

This issue has been assigned to @kellda via this comment.

I sent a "meta" command to triagebot on Zulip and got back:

Failed to query team API: could not get team data

Caused by:
0: error sending request for url (https://team-api.infra.rust-lang.org/v1/zulip-map.json): connection error: Connection reset by peer (os error 104)
1: connection error: Connection reset by peer (os error 104)
2: Connection reset by peer (os error 104)

I resent the same command ~5 seconds later and it worked. Maybe this needs some retry logic?

Example:

1. Comment by @user:

   @rustbot claim
    
   [some other text]
   

   Bot assigns @user (directly or indirectly) and edits original issue comment if needed.

2. @user edits their comment:

   @rustbot claim
   
   -[some other text]
   +[some different text]

   Bot unassigns @user (directly or indirectly) and edits original issue comment if needed, then assigns @user (directly or indirectly) and edits original issue comment if needed.

rust-lang/rust example

Perhaps the bot should not do anything in 2, if possible. Especially if the target user is already assigned.

As suggested in today's Prioritize WG meeting, being able to relabel issues from Zulip could be helpful, e.g. for prioritizing issues as per the prioritize-WG or labeling during meetings, without leaving the Zulip chat.

The command syntax could probably follow the existing @rustbot modify labels on GitHub, but may need to take an additional link-to-the-issue parameter, e.g. @rustbot modify labels for #XXXXX: .... If absent, it may look at the topic name and get the link from there (e.g. all topics names for I-prioritize issues have the link to the issue inside them).

This issue has been assigned to @LeSeulArtichaut via this comment.

A workflow I often run into is where someone has opened a PR, I've reviewed it, but before I merge I want to cc a group or individual to look over it, but I don't want to block merging the PR on their review if they're busy. It would be nice if you could say @rustbot merge 2 days to have rustbot merge automatically if there's been no review in the time given.

I got this in response to a move 12 1 command on Zulip:

Failed to parse movement, expected move <from> <to>: failed to get RDS cert

Caused by:
0: error sending request for url (https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem): connection closed before message completed
1: connection closed before message completed.

I tried the same command again and it worked.

Possibly same root cause as #332?

Right now we have rustbot ping everyone individually (cc @ghost) in a marker team, this isn't scable as GitHub mentions stop after 50 people. This might seem hard to reach but ICE-Breakers Cleanup Crew has 24 members and ICE-Breakers LLVM has 14 members. possible that we get more than 50 members, or if there are issues we want to tag multiple marker teams, we would easily hit the over 50 limit.

We could add logic to triagebot to only a select 50 people at a time, but then we'd need to have logic to ensure everyone gets an equal amount of notifications, and would add significant complexity. It would be simpler to have them as github teams. This also has the added benefit of the notification going into the team-mentions section in the new GitHub notifications rather than mention. Since these issues don't require that individuals specific attention rustbot should respect that and ping the team.

@pietroalbini mentioned in #3 reservations about granting marker team members with a GitHub Team since they would be granted "member" giving some kind of perceived authority. I don't think we should be applying any kind of authority to GitHub's structure. We already have members on GitHub that don't match with our current membership. rust-lang/team should be considered the normative structure of the Rust teams.

rust-lang/rust#69225 (comment)

Having to leave a @rustbot prioritize comment is less convenient than just applying I-prioritize along with the other labels, so it would be great if triagebot could notice the label being applied and do its magic (creating the Zulip stream, etc.)

Potential security breach. See /.github/workflows/ci.yml

More abstractly, we should have a list of "team required" labels (e.g., I-nominated, beta-nominated, S-waiting-on-team...) in the configuration for rust-lang/rust, as well as a "team label" list ("T-" and "WG-" maybe).

The bot would detect labels in the first list being added without an accompanying team label being added. There is a proposal of some sort of "if not added within 1 minute" or something, but I don't think that's easy to implement and probably best to just not do that since it adds complexity to the implementation (we have no timers today).

Highfive currently auto-assigns people to review PRs based (I believe) on some match between the directory where the changes occur and its JSON config containing assignees. It would be great if we could not implement auto-assignment in triagebot, but also make some improvements to the auto-assignment system.

Requirements

• Instead of using a JSON config, assignees should taken from data in rust-lang/team.

Potential Improvements

• On zulip there was a discussion around how to improve review latency, or at least the review experience. One proposed idea was place a limit how many open S-waiting-on-review PRs you as a rust-lang member could be assigned, and if all members of a team are assigned a new S-waiting-on-reviewer is given to the PR. Which would also allow us to properly communicate a team's current bandwidth.

Unresolved Questions

• How would people set their limit?
  • It would be easiest (I would guess) on the implementation side if this limit was also set in team, but team can take a some time to get a PR merged.
  • Because of the above I feel it would be better suited as a bot command on Zulip.
  • The solution could also be both, a user sets through a bot command which updates the team repo.

In serde-rs repos and my personal repos, usually when someone makes an issue or PR they don't ping my username. But I would still like to treat those as a notification because I am the one responsible.

It would be great to set via some config, whether local to the repo or global to the user or org, that says who wants to be notified on new issues/PRs.

Would be nice if we have @rustbot prioritize command that assigns I-prioritize label and also creates a new topic on Zulip's WG-prioritization stream requesting the working group to prioritize the in question issue.

Read more about the discussion about this feature request in this Zulip topic.

rust-lang/rust#69392 (comment) for example should not have pinged the release team.

We should be able to reuse parser code to make this happen.

If a regression-from-stable-to-beta label is added in the release week, label with T-compiler, T-release, I-nominated and ping the release and compiler teams.

Discussion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/cargo-bisect.20as.20a.20bot

I got a working prototype at https://github.com/bjorn3/cargo-bisect-rustc-bot. I will probably try to integrate it into triagebot next week.

As of today, the prioritize feature has 3 roles:

• when the @rustbot prioritize is used, label the issue with the prioritization label
• when certain labels are added, label the issue with the prioritization label
• when the prioritization label is added, create a conversation on Zulip

I would propose to split those 3 features. This will allow for more flexibility, e.g. to define multiple triggers for auto-labeling. This is needed for the automation the Prioritization WG would like to set up in the near future:

• Create a topic per stable/beta nominations, i-nominated and prs-waiting-on-team
• Create a topic per P-critical and P-high regressions

I propose to have configuration like:

[prioritize]
label = "I-prioritize"

[autolabel."I-prioritize"]
trigger_labels = ["regression-from-stable-to-stable", "regression-from-stable-to-beta", "regression-from-stable-to-nightly"]
exclude_labels = [
    "P-*",
    "T-infra",
    "T-release",
]

[notify-zulip."I-prioritize"]
zulip_stream = 227806
topic = "I-prioritize #{number} {title}"
message_on_add = "@**WG-prioritization** issue #{number} has been requested for prioritization."
message_on_remove = "Issue #{number}'s prioritization request has been removed."

cc @Mark-Simulacrum @spastorino

Dependabot couldn't resolve your project's dependencies as it couldn't access team.

You can grant Dependabot access to team by adding the repository here. We'll automatically close this issue and kick off another update run once permission is granted.

View the update logs.

When using the 'rustbot modify labels' command, the comment containing the command is essentially just noise. The GitHub UI already shows label changes in a more compact and readable format.

It would be useful for triagebot to auto-hide the comment containing the label command (assuming that the message has no other content).

According to isaacs/github#1480 (comment), this can be done through the GitHub GraphQL API.

When running through my list of notifications, it'd be nice if I could just type ack 1 versus acknowledge 1, since the second is a bit of a handful to type.

Maybe "Unknown command" could become "Unknown command, run help for more info".

Help command explains how the tool works, tells you about your notification page and explain the commands.

We might want to add the ability to define some label patterns as "exclusive", so that there can only be a single label matching a pattern on an issue.

For example, with S-* marked as exclusive a PR with the S-waiting-on-review will have S-blocked after someone types the command:

@rustbot modify labels: S-blocked

We've agreed on Zulip that is going to be great if we can have a way of pinging WG members (which are not part of rust-lang github org) using triagebot.

People is already able to sign up by themselves to WGs, just by sending a PR to the team repo on github. We would stick with that idea and encourage people to do so.

This issue is about being able to reach them out. We want a command like @rustbot icebreaker llvm that would add a github comment reaching out all the members of that working group with a text that looks like ...

Hey LLVM icebreakers! This bug has been identified as a good
"LLVM ice-breaking candidate". In case it's useful, here are some
[general instructions](link) for tackling these sorts of bugs. Maybe take a look?

cc @foo @bar @baz ...

Where, the first part of that text is a predefined text that's specific to the working group. Every working group has a very similar text but it's not exactly the same. Specifically the link to instructions is going to be different.

And then, in the cc part, the bot figures out the list of members it needs to mention.

Add a command:

@rustbot close

which will close the issue or PR.

Currently @rustbot expects the final . to terminate a modify labels command. Leaving out the . leads to a cryptic error message like rust-lang/rust#58208 (comment):

Error: Parsing label command in comment failed: ...-on-author|error: a label delta at >|...

The error message should be improved, or even better, treat the end-of-line as another terminator.

In rust-lang/rust#67590 I accidentally used @rustbot modify label: without s. I was confused why rustbot didn't add the labels until I noticed the missing s.

Currently the status labels for PRs are mostly manually updated by triagers, it would be nice if authors of PRs could more easily update the status when it's S-waiting-on-author when they believe they have completed the necessary changes.

Potential Solutions

• Detect when the author has requested a review using GitHub's request review feature and automatically update labels.
• Add some kind of @rustbot review command.

I think ideally we would have both, as @rustbot review is easy to teach, but more people are using GitHub's review features as it better integrates with GitHub notifications, and the @rustbot review command could be implemented so that it uses GitHub's request review feature.

See this comment.
Triagebot tried to edit the issue's description and assign them but it seems its work has failed.
It's nice for the bot to tell us what's happening, i.e. show an error message.

Instead of having to remember @rustbot ping icebreakers-cleanup-crew it would be great if we could add a memorable alias for the group so that I could e.g. write @rustbot ping cleanup. We would configure this by adding a list of aliases under a ping section.

Right now, the triagebot will create a zulip thread when a compiler-team MCP is opened, but it doesn't link to that zulip thread from the compiler-team issue. It would be great for it to leave a comment like

• Zulip thread
• Archive

where the archive points to https://zulip-archive.rust-lang.org/

I wanted to unassigned an issue I was assigned to in the past using @rustbot release-assignment but that doesn't work. For more info rust-lang/rust#57431 (comment)

I'd prefer if we assign the bot itself and post a comment saying that user is assigned.