rust-lang / rust-lang/libs-team

Change ACP process to track unimplemented ACPs

Open
#547 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
178
Forks
28
Avg merge
15m
Merged PRs (30d)
1

Description

Currently, the ACP process works like this:

  1. An ACP is submitted proposing some API feature
  2. The ACP is reviewed in a team meeting or directly by a team member
  3. If rejected, the ACP is just closed
  4. If accepted, the ACP is closed after adding the ACP-accepted label

This process has no feedback on whether the API feature is actually implemented, which is problematic because there is no easy way for contributors to find ACPs to work on.

We propose to change the process to this instead:

  1. An ACP is submitted proposing some API feature
  2. The ACP is reviewed in a team meeting or directly by a team member
  3. If rejected, the ACP is closed after adding an ACP-rejected label
  4. If accepted, the ACP-accepted label is added
  5. Once implemented, the ACP is closed with a comment linking to the tracking issue

This allows someone to find accepted but unimplemented ACPs by searching for open issues with the ACP-accepted label.

Alternatives

One alternative is, instead of leaving the issue open, apply two labels when accepting it: ACP-accepted and unimplemented. When the ACP is implemented, the umimplemented label is removed.

This option may work better with triagebot. I'm not sure if we can set it up to allow just anyone to close issues, but we can set it up for anyone to change labels. It also requires less modification to existing tools, like the agenda-generator.

But it's less clean and less discoverable. Closing an issue typically means that no work is left to be done, but that isn't true for unimplemented ACPs.

What needs to change

  • Issue template: add some verbiage that describes what will be done when an ACP is accepted and what needs to be done once the API is implemented.
  • Agenda maker: modify to exclude issues labeled as ACP-accepted

Contributor guide

No contributing guide indexed for this repository

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

Start by locating the ACP issue template and agenda maker referenced in the issue, then inspect how ACP labels and open issues are currently handled. Update the template and agenda behavior so accepted, unimplemented ACPs remain discoverable and implemented ACPs can be closed with a tracking link; verify the workflow with representative ACP issues.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.