hyperium / hyperium/hyper

Create a routine triage strategy

Open
#3,214 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-meta B-rfc
Dominant language
Rust
Stars
16.3k
Forks
1.8k
Avg merge
1d 22h
Merged PRs (30d)
14

Description

This is an action item of the COE on hyper's surprise CVE. We have a pile of issues and pull requests that don't get regularly reviewed, and new issues that take a while to get some eyes. It would be beneficial to setup some strategy to do. We can make a more welcoming experience, promptly fix problems, identify more serious issues, and mentor new contributors.

The resolution of this issue should be a pull request adding to the docs/ folder in this repo, outlining what the triage strategy is.

Note: anyone is encouraged to sign up a triager, to help us out.

Some questions to consider:

  • How often should "routine" be?
  • Should it be done synchronously?
  • How do we keep ourselves accountable to doing it?
  • How do we keep track of what has been triaged, and what next actions are for any issue or pull request?

Some possible options include:

  • Synchronous text meeting, such as in a Discord channel.
  • Synchronous video meeting.
  • Partial video, such as streaming a screen (like on Twitch or Discord), and others in text chat.
  • Async, having a few people do it at a convenient time for them during the week, and send a report somewhere (Discord?)

For keeping track, we could create a T- sets of labels, like T-needs-mvce, T-waiting-on-author, etc. We can come up with a specified amount of time for something to be sitting in a certain "triage" state, before moving to another, or being closed.

Triage process

These are just proposed things to do, so far:

  • Make sure new issues have all the needed info from the reporter. This would benefit from a checklist (https://github.com/hyperium/hyper/issues/3215).
  • Check if any issues waiting on author have received comments from them.
  • Consider tagging a collaborator (or a volunteer to mentor) that can fix it, or review if a PR.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the existing docs/ folder and the triager guidance in docs/MAINTAINERS.md, then use the listed questions and proposed process as the requirements to resolve. Done means a pull request adds a document under docs/ that clearly outlines the routine triage strategy.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.