Policy: Empower reviewers to reject burdensome PRs (original) (raw)

Reviewer time and effort are very precious and limited resources. However, there are Pull Requests (PRs) with certain qualities that place undue work on reviewers. We are proposing a policy that reviewers can use as justification for rejecting a PR without them having to excessively defend their position or relitigate the reasons for closing.

Motivation

In recent times, there are rather frequent contributions that are fully or partially produced by generative AI (e.g. LLMs and similar tools) which exhibit characteristics (see below) that make reviewing difficult or just a plain waste of time. While we've seen such PRs produced entirely by humans, generative AI tools have significantly lowered the effort to produce "plausibly-looking" contributions that are entirely inadmissible and in some cases against our Code of Conduct. This policy is thus drafted as a response to this problem, to avoid reviewers figuring out themselves how to respond.

PR characteristics that are red flags

PRs subject to this policy have characteristics such as (but not limited to):

Needlessly or overly verbose descriptions or interaction (even when used to overcome a language barrier).
Being not internally coherent or even self-contradictory. The code in the PR is plain wrong or not related to its stated purpose.
Demonstrated misunderstanding of important aspects of what the existing code being modified is doing, what the code added by the PR is doing, or the purpose of the change.

It is okay to not be fully confident in a proposed change, but this should be disclaimed on the PR itself.

Policy

To mitigate undue work when encountering such PRs, reviewers may choose to exercise one or more of the following options:

Ask the PR author to rework their PR to make it more easily reviewable.
Edit out verbose PR descriptions.
Reject (close) the PR.

Mentors or Reviewers

None specifically; compiler team.

Process

The main points of the Major Change Process are as follows:

File an issue describing the proposal.
A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
- Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.