doc: create LLM Review Policy

[danth]

This is a totally alternative idea to #2343, with similar goals.

I tried to design a process which does not add work in the happy case.

In particular, there is nothing new in the pull request template, and no extra labelling. At most we might want to add a link to the policy so people know it exists.

Suggestions to change the wording are of course welcome.

Closes #2178.

---

flowchart TD
    A[Pull request submitted]
    B[Checked by module maintainer]
    C[Checked by core maintainer]
    D[Module maintainer sends refusal]
    E[Core maintainer sends refusal]
    F[Core maintainer marks as draft]
    G[Core maintainer closes pull request]
    H[Core maintainer merges pull request]
    A --> B
    B -->|Review as normal| C
    B -->|Apply policy| D
    C -->|Review as normal| H
    C -->|Apply policy| E
    D --> F
    E --> F
    F -->|After a few weeks| G

Loading

---

• I certify that I have the right to submit this contribution under the MIT license
• Commit messages adhere to Stylix commit conventions
• Theming changes adhere to the Stylix style guide
• Changes have been tested locally
• Changes have been tested in testbeds
• Each commit in this PR is suitable for backport

[trueNAHO]

This is a totally alternative idea to #2343, with similar goals.

I tried to design a process which does not add work in the happy case.

In particular, there is nothing new in the pull request template, and no extra labelling. At most we might want to add a link to the policy so people know it exists.

The main reasoning behind the LLM-tiered labeling in #2343 is that knowing how much time is spent talking to LLMs far outweighs PR template and label bloat. Upon reconsideration, I prefer preserving the pristine state with an LLM notice to evaluate LLM disclosure honesty before adding the rigorous and mandatory LLM-tiered disclosure from #2343.

I suggest adding a friendly LLM disclosure reminder in #2438 as a start.

flowchart TD
    A[Pull request submitted]
    B[Checked by module maintainer]
    C[Checked by core maintainer]
    D[Module maintainer sends refusal]
    E[Core maintainer sends refusal]
    F[Core maintainer marks as draft]
    G[Core maintainer closes pull request]
    H[Core maintainer merges pull request]
    A --> B
    B -->|Review as normal| C
    B -->|Apply policy| D
    C -->|Review as normal| H
    C -->|Apply policy| E
    D --> F
    E --> F
    F -->|After a few weeks| G

Loading

I really like the introduction of a rejection policy.

Suggestions to change the wording are of course welcome.

IMHO, the proposed policy in this PR should not be restricted to low effort, automated, and LLM PRs. IMHO, the current response template is too harsh, even when used correctly.

I submitted a more general review policy in the writing style of /doc/src/backport_policy.md in #2437.

[danth]

IMHO, the proposed policy in this PR should not be restricted to low effort, automated, and LLM PRs.

It would be nice to have a general flowchart for rejection / approval similar to the one above.

I think it quite nicely shows who to ask for reviews, and who can press merge.

IMHO, the current response template is too harsh, even when used correctly.

In other projects, I've seen agents pick up on "good first issue" labels and open a pull request, without a human ever checking what was done.

When writing the template I was mainly thinking of those extreme cases, where the review would probably never even be seen by the supposed author.

It probably is too harsh for other cases. I'm not great at that kind of writing 😅

[trueNAHO]

IMHO, the proposed policy in this PR should not be restricted to low effort, automated, and LLM PRs.

It would be nice to have a general flowchart for rejection / approval similar to the one above.

I think it quite nicely shows who to ask for reviews, and who can press merge.

See my #2437 (comment) reply.

IMHO, the current response template is too harsh, even when used correctly.

In other projects, I've seen agents pick up on "good first issue" labels and open a pull request, without a human ever checking what was done.

When writing the template I was mainly thinking of those extreme cases, where the review would probably never even be seen by the supposed author.

It probably is too harsh for other cases.

I prefer the approach in #2437, as it entirely avoids this problem.

I'm not great at that kind of writing 😅

Succinct writing always takes time and is never easy, both for writting natural and machine language:

I would have written a shorter letter, but I did not have the time.

-- Blaise Pascal

-- #477 (comment)

[danth]

Let's go with #2437 instead.