Release Team: Triage Assistance via Automation

The release team currently conducts does both issue and PR triage. As part of this, we’re also attempting to maintain the “State of Rust” view. Especially the State of Rust board is difficult to maintain with our current resources and methods, as it requires somewhat rare but relatively difficult investment by triagers.

My hope is to develop some form of automation – or at least “triage assistance” – that would enable us to more easily expand our current set of triagers.

I believe there’s two primary components to this.

The highest-order bit is a “triaged” label – though likely not actually a label – that could be set by anyone (not necessarily on the release team) doing triage. The idea here is that for the majority of issues, there’s no reason to visit them (unless there are direct comments) more than about once a month at most. Currently, there’s no good way without ‘touching’ the issue (e.g., label changes) to update the ‘visited’ date. That makes triage difficult, unless one always visits all issues – something that is pretty much not possible at this point.

The idea here is that there will be a central “board” of some kind – likely a website – that allows people to triage issues whether they’re part of the Rust teams or not. We might want some kind of permissions system, but it seems plausible that bad actors are somewhat unlikely.

The thought here is that instead of needing to grant people “write” access to rust-lang/rust in order for them to close/tag issues, we would give them the ability to do so from the website UI. I think basically close and label are all that’s needed.

We may want to consider some form of integration with rfcbot such that closing issues can be done via team consensus, but proposed by someone outside the team.

The second part of this, beyond this triaged/not yet triaged board, is a better way to maintain the State of Rust board. I think this will be helped by the triage board – we can have a separate one for tracking issues.


The general problem of increasing the amount or quality of triage to ensure discovery and surfacing of issues (and PRs) is one that the release team will be discussing at the upcoming all hands.

8 Likes

I have commonly been disappointed that I cannot apply area and category labels to issues I create to help cut down on the contributors workload. It sounds like this would allow me to do that via this website, but I wonder if it could be integrated more directly on github, maybe there could be some way to request rfcbot to apply specific labels when creating a new issue?

2 Likes

The Kubernetes repositories have a bot that allows anyone to modify the labels: https://github.com/kubernetes/kubectl/issues/305#issuecomment-424516986

1 Like

Beyond triage, I’d also like a way for PR authors to mark their PRs as “waiting on review”. I feel like “waiting on author” can’t really be trusted in its current state because it’s dependent on someone from triage noticing that the PR author has responded to comments.

2 Likes

CC @booyaa

Honestly, the way eeyorebot phrases it, it sounds like what could help the most is using a dedicated issue tracker software that has these kinds of features for triage rather than GitHub issues. (Of course, that can only help do much when you also care about PRs.)

We already have GitHub, internals.rlo, users.rlo, zulip, gitter, travis, appveyor, discord, IRC… and TBH, I’ve avoided almost all of them and stuck to internals and github. If possible, it would be nice to not add yet another service where information might be found; keeping everything in one place is nice to the extent that it is possible.

4 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.