Add an LLM policy for rust-lang/rust

[jyn514]

Rendered

View all comments

FCP link

Summary

This document establishes a policy for how LLMs can be used when contributing to rust-lang/rust. Subtrees, submodules, and dependencies from crates.io are not in scope. Other repositories in the rust-lang organization are not in scope.

This policy is intended to live in Forge as a living document, not as a dead RFC. It will be linked from CONTRIBUTING.md in rust-lang/rust as well as from the rustc- and std-dev-guides.

Ethical issues

See this thread.

Moderation guidelines

This PR is preceded by an enormous amount of discussion on Zulip. Almost every conceivable angle has been discussed to death; there have been upwards of 3000 messages, not even counting discussion on GitHub. We initially doubted whether we could reach consensus at all.

Therefore, we ask to bound the scope of this PR specifically to the policy itself. In particular, we mark several topics as out of scope below. We still consider these topics to be important, we simply do not believe this is the right place to discuss them.

So, the following are considered off topic for this PR specifically:

• Long-term social or economic impact of LLMs
• The environmental impact of LLMs
• Anything to do with the copyright status of LLM output. We have gotten initial confirmation from US lawyers that LLM output likely doesn't cause issues under US law. We still need to confirm this with EU lawyers and in other parts of the world.
• Moral judgements about people who use LLMs

We have asked the moderation team to help us enforce these rules. For an extended rationale, please see this comment.

Feedback guidelines

We are aware that parts of this policy will make some people very unhappy. As you are reading, we ask you to consider the following.

• Can you think of a concrete improvement to the policy that addresses your concern? Consider:
  • Whether your change will make the policy harder to moderate
  • Whether your change will make it harder to come to a consensus
• Does your concern need to be addressed before merging or can it be addressed in a follow-up?
  • Keep in mind the cost of not creating a policy.

If your concern is for yourself or for your team

• What are the specific parts of your workflow that will be disrupted?
  • In particular we are only interested in workflows involving rust-lang/rust. Other repositories are not affected by this policy and are therefore not in scope.
• Can you live with the disruption? Is it worth blocking the policy over?

---

Previous versions of this document were discussed on Zulip, and we have made edits in responses to suggestions there.

Motivation

• Many people find LLM-generated code and writing deeply unpleasant to read or review.
• Many people find LLMs to be a significant aid to learning and discovery.
• rust-lang/rust is currently dealing with a deluge of low-effort "slop" PRs primarily authored by LLMs.
  • Having a policy makes these easier to moderate, without having to take every single instance on a case-by-case basis.

This policy is not intended as a debate over whether LLMs are a good or bad idea, nor over the long-term impact of LLMs. It is only intended to set out the future policy of rust-lang/rust itself.

Drawbacks

• This bans some valid usages of LLMs. We intentionally err on the side of banning too much rather than too little in order to make the policy easy to understand and moderate.
• This intentionally does not address the moral, social, and environmental impacts of LLMs. These topics have been extensively discussed on Zulip without reaching consensus, but this policy is relevant regardless of the outcome of these discussions.
• This intentionally does not attempt to set a project-wide policy. We have attempted to come to a consensus for upwards of a month without significant progress. We are cutting our losses so we can have something rather than adhoc moderation decisions.
• This intentionally does not apply to subtrees of rust-lang/rust. We don't have the same moderation issues there, so we don't have time pressure to set a policy in the same way.

Rationale and alternatives

• We could create a project-wide policy, rather than scoping it to rust-lang/rust. This has the advantage that everyone knows what the policy is everywhere, and that it's easy to make things part of the mono-repo at a later date. It has the disadvantage that we think it is nigh-impossible to get everyone to agree. There are also reasons for teams to have different policies; for example, the standard for correctness is much higher within the compiler than within Clippy.
• We could have different standards for people in the Rust project than for new contributors. That would make moderation much easier, and allow us to experiment with additional LLM use. However, it reinforces existing power structures, creates more of a gap between authors and reviewers, and feels "unfriendly" to new contributors.
• We could have a more lenient policy that allows "responsible and appropriate" use of LLMs. This raises the question of what "responsible and appropriate" means. The usual suggestion is "self-review, and judging the change by the same standard as any other change"; but this neglects the reputational and social harm of work that "feels" LLM generated. It also makes our moderation policy much harder to understand, and increases the likelihood of re-litigating each moderation decision.
• We could have a more strict policy that removes the threshold of originality condition. This has the advantage that our policy becomes easier to moderate and understand. It has the disadvantage that it becomes easy for people to intend to follow the policy, but be put in a position where their only choices are to either discard the PR altogether, rewrite it from scratch, or tell "white lies" about whether an LLM was involved.
• We could have a more strict policy that bans LLMs altogether. It seems unlikely we will be able to agree on this, and we believe attempting it will cause many people to leave the project.
• We could have no policy at all. This avoids banning valid use cases; avoids implicitly legitimizing the use of LLMs by setting a policy; and saves all of us a great deal of time and effort. However, it greatly increases the baseline level of distrust within the project; makes review assignment even more of a dice roll than it is already; wastes a great deal of contributor and moderator time dealing with LLM-authored PRs on a case-by-case basis; and gives no guidance for people who really do want to use an LLM in a responsible way.

Prior art

This prior art section is taken almost entirely from Jane Lusby's summary of her research, although we have taken the liberty of moving the Rust project's prior art to the top. We thank her for her help.

Rust

• Moderation team's spam policy
• Compiler team's "burdensome PRs" policy

Other organizations

These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly.

• full ban
  • postmarketOS - also explicitly bans encouraging others to use AI for solving problems related to postmarketOS - multi point ethics based rational with citations included
  • zig
    • philosophical, cites Profession (novella)
    • rooted in concerns around the construction and origins of original thought
  • servo
    • more pragmatic, directly lists concerns around ai, fairly concise
  • qemu
    • pragmatic, focuses on copyright and licensing concerns
    • explicitly allows AI for exploring api, debugging, and other non generative assistance, other policies do not explicitly ban this or mention it in any way
  • forgejo
    • bans AI for review, code, documentation, and communication
    • mentions "legal uncertainties" as a motivating factor
    • explicitly excludes machine translation
• allowed with supervision, human is ultimately responsible
  • scipy
    • strict attribution policy including name of model
  • llvm
  • blender
  • linux kernel
    • quite concise but otherwise seems the same as many in this category
  • mesa
    • framed as a contribution policy not an AI policy, AI is listed as a tool that can be used but emphasizes same requirements that author must understand the code they contribute, seems to leave room for partial understanding from new contributors.

      Understand the code you write at least well enough to be able to explain why your changes are beneficial to the project.

  • firefox
  • ghostty
    • pro-AI but views "bad users" as the source of issues with it and the only reason for what ghostty considers a "strict AI policy"
  • fedora
    • clearly inspired and is cited by many of the above, but is definitely framed more pro-ai than the derived policies tend to be
• curl
  • does not explicitly require humans understand contributions, otherwise policy is similar to above policies
• linux foundation
  • encourages usage, focuses on legal liability, mentions that tooling exists to help automate managing legal liability, does not mention specific tools
• In progress
  • NixOS
    • How do we deal with AI-generated issues? NixOS/nixpkgs#410741

Unresolved questions

See the "Moderation guidelines" and "Drawbacks" section for a list of topics that are out of scope.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Fallback group: @Mark-Simulacrum, internal-sites
• @Mark-Simulacrum, internal-sites expanded to Mark-Simulacrum, Urgau, ehuss, jieyouxu
• Random selection from Mark-Simulacrum, Urgau, ehuss, jieyouxu

[jyn514]

@rustbot label T-libs T-compiler T-rustdoc T-bootstrap

[jieyouxu]

I really like this version, and thanks a ton for working on it. Specifically:

• It doesn't try to dump entire walls of text, which is unfortunately a good way to be sure nobody reads it. Instead, it gives you concrete examples, and a guiding rule-of-thumb for uncovered scenarios, and acknowledges upfront that it surely cannot be exhaustive.
• I also like where it points out the nuance and recognizes the uncertainties.
• I like that it covers both "producers" and "consumers" (with nuance that reviewers can also technically use LLMs in ways that are frustrating to the PR authors!)

I left a few suggestions / nits, but even without them this is still a very good start IMO.

(Will not leave an explicit approval until we establish wider consensus, which likely will take the form of 4-team joint FCP.)

View changes since this review

[ChayimFriedman2]

The links to Zulip are project-private, FWIW.

[jyn514]

The links to Zulip are project-private, FWIW.

I'm aware. This PR is targeted towards Rust project members moreso than the broad community.

[davidtwco]

I'm happy with this as an initial policy for the rust-lang/rust repository.

View changes since this review

[walterhpearce]

I wanted to raise a point specifically around using a PR label instead of something like a Co-Authored By: or other commit message.

With a PR title, the provenance of LLM contributions is going to get lost outside github, and not exist in the git history. For automation or searching of LLM attribution, we will be reliant on utilizing the GitHub API for filtering PRs which were labeled, and then cross-referencing that with git commits. Other projects have specifically gone with the git commit addition because the LLM provenance of commits exists within the history. It remains clear what code was submitted by an LLM. The label approach will not make this clear outside the GitHub UI.

Additionally, the Co-Authored-By or similiar commit additions also generally include the model name, for further attribution. the label excludes that.

View changes since the review

[jyn514]

one possibility here is to have a bot that automatically edits the label into the PR description. then bors will automatically pick it up in the merge commit, and we can filter it through the git history that way.

my only concern here is around brigading, i worry that people outside the project will — in a year, two, three years from now — go through the history to harass people. at least on PRs we're able to lock the thread, i don't think github has any kind of moderation controls on commits themselves, even though it lets people comment.

putting this only on the bors merge commit makes me feel a little better about things, since it naturally directs people to the pr but ... idk. it kinda worries me that putting this in the commit is so permanent. we can't remove these without rewriting history for the whole main branch.

[jyn514]

let me ask: what's your goal with establishing provenance like this?

[walterhpearce]

There are a few scenarios I'd find it useful; one is immediate information and answering questions, and another is more threat-model based on future possibilities I feel uncomfortable painting ourselves into a corner for.

I think for answering basic questions like:

• "what is the entirety of code changes conducted by LLM in this project?"
• "What models are being used in our project?"
• "What code was committed by a specific model found to be problematic?"

Given the experimental allowances here, we are making it prohibitively difficult to answer any meaningful questions about the experiment with objective data. I assume during the term of the experiment, we want to be able to answer questions like what models were used, how each model performed, what areas they seemed to excel or struggle in, etc. We can still distill this from the PRs alone; however, that information will be non-uniform and ad-hoc, making it an entirely manual exercise in gathering data. I worry we are limiting ourselves to subjective results and/or excessive work for answering anything like that as the experiment progresses.

Looking into the future, we can threat model around potential circumstances where we need this information. I can iterate here if desired, but the main burning concern I have for an actionable, and likely, future need is: What if a model is deemed problematic, and we need to remove all contributions by it? I could see a government, or the project, making this kind of call in the near future (ex: the US government bans a model, or the project wants to ban a racist model, or a model is found to be maliciously manipulated). I think we need a built-in mechanism to respond to that.

As written, this document strictly lets us identify what PRs had an LLM involved - we can't tangible answer any of the above without entirely manual and social mechanisms (Filter ai-assisted, contact the author, ask what models they used, ask what code was written by the LLM, etc)

[jyn514]

What if a model is deemed problematic, and we need to remove all contributions by it?

I simply do not think this is realistic. This is on-par with "What if we want to switch the license and everyone but a single contributor agrees, how can we rip out their code?" Code doesn't work like that. Changes are built on top of each other; rewriting the change "as-if" a previous change had never existed is usually tantamount to a full rewrite.

[joshtriplett]

I don't think we need to tag each commit. I do think we should arrange something in the bors merge message, to make data gathering easier as part of the LLM experiment.

[kennytm]

IANAL but I don't think the legality of authorship is implied by bots (LLM or not) using the Co-Authored-By:/Author: field, just like no one questioned the commits "authored" by bors or dependabot.

That said, I think Co-Authored-By: should not be enforced. Besides being ad-like, these LLM Co-Authored-By: in the wild mostly comes from Claude Code and Copilot only. Other tools like Codex or Antigravity don't do commit attribution trailer (unless given custom instructions), so for auditing use you'll by-default miss half of the picture. Plus, tools like Copilot and Cursor and OpenCode attribute Co-Authored-By: to the tools themselves despite actually calling someone else's model, making it even less useful to answer "What models are being used in our project?".

I don't think we need to tag each commit. I do think we should arrange something in the bors merge message, to make data gathering easier as part of the LLM experiment.

If the disclosure is written in the PR description it will be automatically included in the merge commit. In such case a git log --grep or other text analysis tool should be enough for auditing.

But this means this guideline needs to specify that the disclosure must be placed within the PR description rather than a separate comment. 🤔

[walterhpearce]

But this means this guideline needs to specify that the disclosure must be placed within the PR description rather than a separate comment. 🤔

I agree. The core of this is that we are framing this as an experiment to see how the policy and LLMs perform for code contributions, with no way to attribute what was used during the experiment.

I don't think we need to tag each commit. I do think we should arrange something in the bors merge message, to make data gathering easier as part of the LLM experiment.

I'd find this compromise at least meeting our needs for data gathering. At a much less extreme level, I really just want to be able to see what code was written by what model during this experiment - anecdotal feedback from the users is also useful; but I think the future opportunity to see how specific models perform objectively is going to be a data point we want out of this experiment. Having this somewhere machine-readable (either github API or the git log) is an acceptable compromise.

[joshtriplett]

The model is useful, but personally the thing I see as most critical is recording whether a merge was of LLM-assisted code at all.

[apiraino]

but I think the future opportunity to see how specific models perform objectively is going to be a data point we want out of this experiment

Paraphrasing, in other words you're saying (IIUC): "if a bug or a vuln is introduced by an LLM, I want to be able to know if the culprit commit was LLM assisted or was it entirely a human error". I feel that in practice such a goal is hard to grasp. If we wanted real code accountability for this or other similar scenarios, there are other tools or regulatory frameworks for that (which I am not personally familiar with, but do I know they exist)

(and I agree with the previous comments that at the current stage it would in practice just turn out unwillingly into free adverstisement).

[jyn514]

Currently having conversations with jyn514, jackh726, and Amanieu, to resolve the open concerns (one filed before the lock, one not yet filed because of the lock). I intend to invest substantial time this week into addressing these concerns; I'm not just going to let the block sit there.

on @joshtriplett's behest, I'd like to say: we think we have a path forward here, but I'm too busy this week to write it up. I'll try to write something down by next Friday.

[tmandry]

Speaking as a compiler team member, I would be very uncomfortable binding the team with a policy that cannot be changed/removed except with a lack of concerns from any teams that ratified the policy.

Even a lack of concerns within the compiler team is difficult to overcome for a decision with any kind of controversy, and this topic is guaranteed to have that. The compiler team is large, and there was some recent discussion about whether MCPs bias us for inaction. For purely technical matters I think they are okay, but for policy matters like this they are not a good fit.

If the text bakes in "lack of concerns", it effectively cements a bias for inaction, which I think would be a mistake. It would be better to defer to the teams' lightweight policy making processes to the extent they have them, building in a fallback option for when they do not.

Finally, the part that the text leaves unclear is whether a team is allowed to withdraw without the agreement of the other teams. I think the answer is certainly yes, and the text should be explicit about it.

View changes since the review

[clarfonthey]

I don't think that a lack of coordination between the involved teams is really possible with a policy that binds so tightly to a shared repo. Just considering the standard library and the compiler, for example, I don't think it's really possible to have standards for review and merging that drift too far apart considering the fact that changes to one has massive effects on the other, even excluding changes that touch both.

Perhaps rustdoc could potentially be the one team that successfully removes themselves from the repo and starts being managed as a subtree, but in terms of compiler and libs, I don't really see a lack of coordination being possible.

---

Also re: "lack of concerns," while it is not public yet, libs has plans to ensure an explicit override for concerns on ACPs being overridable by an FCP, so that the process degrades into an FCP in case of controversy, but remains relatively frictionless when there's no controversy. I think this is a fair way to handle this.

[tmandry]

I don't think that a lack of coordination between the involved teams is really possible with a policy that binds so tightly to a shared repo.

If that's true then we should accept that the council can change the policy, because one of the council's main functions is to allow for cross-team coordination of shared resources.

The point I am making is the same reason the council was given this purpose: This kind of coordination is difficult and functionally becomes impossible, given the size of the project, when any team member can object. If this policy is accepted, it only proves my point: The heroic effort that @jyn514 went to, the length of this thread, the length of the internal threads leading up to it, the lengthy conversations to resolve concerns, the toxic communication... no one wants to go through that again.

Requiring a "lack of objections" for changes will effectively cement this policy in its current form for all time. Or at least until it becomes very obviously harmful, which IMO is too late.

libs has plans to ensure an explicit override for concerns on ACPs being overridable by an FCP

This doesn't address my point about concerns being a veto.

[clarfonthey]

The point here is that concerns are only a soft veto: they convert an extremely quick, loose process into a stricter one determined by a smaller subset of people. If someone has a completely uncontroversial change, it will be accepted with effectively no friction, but if something is controversial, it falls back to something which requires more consensus. Technically, concerns are still a unilateral veto in the FCP process, but ultimately, there is going to be a point where some subset of people must make a decision, and that's not really avoidable.

I think that the LC is not necessarily the right solution here because it ironically has too little representation of the people involved; libs and compiler are only two members of the LC, and by normal FCP rules, this means their votes can technically be overridden by the rest of the LC. While we still have the unilateral veto process for normal FCPs by adding concerns, the point stands that the LC is meant to represent the entire project, whereas the rust-lang/rust repo is explicitly not the entire project, even though it's "the main part" of it.

(I would still disagree with that framing, honestly, but I could understand if people thought of it that way. Many crucial parts of the project are not inside it, or only subtrees of it.)

I think it would be a very fair point to include the moderation team in the discussion, since well, moderation ultimately has to deal with the consequences of it. Although I don't think that giving the same group of people control over everything in the project is a good idea, and we already have gone over this across several discussions. It not only harms the project by centralising decisionmaking on the same handful of people, but it also harms said people by giving them more work than they can reasonably handle.

I think that we should really be refining the FCP, MCP, ACP, etc. processes instead of just using those processes with the LC instead.

[steffahn]

I would start by taking the claim that “we can evolve it as we gain more experience working with LLMs” – as explicitly called out in the policy – at face value.

---

I personally do believe there’s a very high chance that a change to this document - following the documented procedure - will entail significantly less effort than this initial ratification process. Indeed we shouldn’t need to go through all that again what went into it this time.

---

Especially if one team (or a subset of teams) wanted to add or adjust a rule in ways that should really exclusively affect their “part” of the repository, then it would be weird IMO that a concern from a member of a different team could be seriously upheld as a strong veto against such a change. I think concern means concern, not veto.

For example, if t-compiler decided to specifically allow some mechanism for experimentation even for (certain) soundness-critical areas – e.g. MIR building – I don’t see how such a change should really get valid concerns from t-libs, t-rustdoc, or t-bootstrap. (I'm not 100% sure about t-types.)

---

But if - despite all of this - it later really turns out to be way too hard to make perhaps small but still significant (i.e. “Major”) changes to the policy through concerns being (ab?)used as strong vetos, and/or communication around it actually becoming any similar in length and vigor to what’s happening for the initial policy, then… maybe that’s already coming close to

objective concern raised about active harm the policy is having on the reputation of Rust

Though I can see a point that – maybe it’s useful to explicitly give the council more options in this document itself besides full dissolution.

---

Maybe after

Major changes, such as adding a new rule or canceling an existing rule, require a successful MCP (2 approvals and no concerns) from each team that ratified the policy.

adding something like

If evolving this policy with the above mechanism proves unworkable, especially if a team end up significantly hindered in autonomously making decisions concerning its own purview, then these conditions for modification can be adjusted by a leadership council FCP.

could work?

---

Even without such a clause: Implicitly, the power of LC is effectively already much larger anyway, isn’t it? As far as I understand, they could - for instance - just decide that LLM policy decisions now get made by a new dedicated team, and the only formal requirements is a “should” clause in the leadership-council RFC of “The Council should favor working with teams on alternative strategies prior to shifting purviews”.¹
(The one thing that in turn “protects” teams from the council is of course the fact that all top level teams have a representative there.)

Footnotes

1. [-> This section of the RFC.]
   Even temporarily shifting purviews is explicitly allowed. ↩

[traviscross]

It's my view, in agreement with what @tmandry raised, that compiler cannot later be blocked from changing its own policies, for the code and processes that compiler owns exclusively, by objections from or lack of consent by members of sibling teams. I do not believe that it's within the power of a team to surrender (i.e., alienate) decision-making over its own policies in this way.

To the degree this policy would seek to prevent a team from later withdrawing from it without the consent of other teams, I'd consider that a council matter, falling under the council's chartered responsibility (under RFC 3392) of "coordinating Project-wide changes to teams, structures, or processes".

My suggestion would be for the policy to make clear that teams can withdraw of their own accord.

[jyn514]

If evolving this policy with the above mechanism proves unworkable, especially if a team end up significantly hindered in autonomously making decisions concerning its own purview, then these conditions for modification can be adjusted by a leadership council FCP.

I quite like this suggestion. I've added it.

[traviscross]

While that's an improvement, it still uncomfortably seeks to flip the default: a team wanting to withdraw needs to make a showing that evolving the policy has proved unworkable and attain an affirmative council consensus. I don't think a team can constrain its future self in this way in the first place. Without a council resolution, I would consider any implication in the policy that a team cannot withdraw to be void, regardless of its text. But such a void implication in the text would be confusing, in terms of governance, so I'd prefer we avoid that.

…especially if a team end up significantly hindered in autonomously making decisions concerning its own purview…

Separately, this is trivially true. If the policy seeks to prevent a team from autonomously setting policies concerning matters exclusively within its own purview (and from withdrawing from this policy in order to otherwise set them), then obviously, were that not void, the team's autonomous decision-making authority concerning its own purview would be significantly hindered.

[clarfonthey]

I still think that the repo is too deeply tied to multiple teams to really have agreements on procedure without co-operation, but perhaps maybe one of the solutions worth exploring (which would be entirely outside this policy, to be clear) might be having a team comprised of compiler, library, and similar team members whose specific focus is on curating the resources for contributors and reviewers. Right now, we do have those delegations, but they are still separated across multiple places, e.g.:

• rustc dev guide
• lang-docs
• bootstrap
• triage
• (no dedicated team for libs-docs, but if we separated out std dev guide, for example, that would also go here)

and maybe we should consider having a proper dedicated consensus mechanism here that isn't the LC, since the set of shareholders is technically unique. Plus, I think we should consider having more cross-functional teams that aren't just the LC, since spreading the workload across more people is going to make things a lot easier longer term. While the LC does cover completely-cross-project situations like funding and organising, I think that having them deal with "in the weeds" tasks like this one would probably be a poor use of their time. They can still act as a good temporary workaround, but I think we need a better solution, and that solution probably shouldn't be just one team unilaterally deciding to withdraw from cross-functional decisions that still affect other teams.

And also worth mentioning, it's totally fair for members of the LC to overlap with this team (as they already overlap with their own representative teams), just, the group role would be different here.

---

And to be clear about the concrete ask here: I think that the current workaround of the LC is acceptable, but that we could potentially formulate such a dedicated team/working group in charge of this that would replace their role here. I feel like implicitly, the LC can always step in if they absolutely have to, but we would like to avoid that in most cases just due to the fact that they have bigger things to deal with and don't want to centralise too much on them.

[steffahn]

@traviscross

a team wanting to withdraw needs to make a showing that evolving the policy has proved unworkable and attain an affirmative council consensus

That isn't the intended route at all though. On one hand, a team wanting to withdraw should not start with talking to LC; on the other hand, even the documented possibility of involving LC doesn't suggest it should ends with the LC consensus, either. The idea is for LC, merely to fix the procedures to then make your withdrawal possible in a subsequent step.

In more details… (expand/collapse)

If a team wants to withdraw they open a PR to change this document under the Major changes procedure. A team wanting to withdraw would anyway need to define what that withdrawal means for them; this is the way they do it.

Now I expect that such a PR will just go through that way! If the chosen form of "withdrawal"¹ is affecting only things that the team has exclusive purview over, there shouldn't really be any relevant concerns upheld by other teams against that intention, and it should also be straightforward to ask for the 2 approvals from each of the other teams for reaching the formal requirements. (You can't do without any formal requirement because withdrawal can come in so many forms that, ultimately, it's an arbitrary major change to this document. So someone of each team will should have time to double-check whether or not the changes actually affect their purviews.)

The same idea would apply for local rules deviations. The benefit over a withdrawal in such a case is that you can still document the new changed rules in the same document, no need to duplicate everything and have completely separate rulebooks.

So let's assume it doesn't work smoothly: you're on a team has opened a PR change to this policy to change rules that affect only your own team, you have consensus in your team, but the PR still somehow gets stuck waiting for approval or having concerns fom anoter team. Ideally you can understand the reason why it got stuck. If it's a shortcoming of the decision process that seems solvable, open a second PR with an improvement to the decision process for Major changes, which may help get it unstuck. Ask for the all-team MCP on that second PR. This doesn't go lead anywhere either? Then it's time to talk to leadership-council, there are two PRs that easily help you demonstrate the problem of how evolving this document has become unworkable (and LC can decide to merge the second PR for you)!

---

…especially if a team end up significantly hindered in autonomously making decisions concerning its own purview…

Separately, this is trivially true.

This is fully in line with my own interpretation, which I had shared further up in this thread:

Even without such a clause: Implicitly, the power of LC is effectively already much larger anyway, isn’t it? […]

I find the clause very useful nonetheless, since it does remind everyone explicitly about the fact that teams have the right to autonomously make decisions concerning their own respective purviews.

This is thus already more broad than a clarification only about, specifically, "withdrawals" being possible.²

The other thing that writing this down is supposed to achieve is to make making consensus in LC easier to achieve because LC members no longer have to debate why they should become involved if it's documented as an intended/agreed procedure.

---

Did a team give up powers then? I would agree with you, they could not possibly actually have given up decision powers over things that are exclusively in their purview.

Concretely… (expand/collapse)

let's, again, assume the process doesn't work smoothly. You want to withdraw (perhaps partially), and the PR that defines the modalities that team choses keeps being blocked by power outside of their control. What's next? In principle, at that point you could already decide to make the withdrawal de-facto effective unilaterally. Teams inherently hold the rights to decide on their purview. Feel free to tell people about the change; publish a local policy somewhere that's supposed to supersede this one in certain places you own; act on it in those places as far as actions/behavior from your team are concerned; definitely also reach out to moderators to inform us and get confirmation³ to you that we'll also already be moderating based on the new reality, regardless of the state of this document.

Afterwards, of course you should still keep trying to land some update for this document to make things better-documented again.

Footnotes

1. We do discuss "withdrawal" but for most teams here full withdrawal is impossible anyway, unless the team is able to get rid of all overlap in purviews with other teams. As long as there remains some shared areas of the rust-lang/rust repo, the team would need at least to partially stay involved with this policy. ↩

2. Adding in a withdrawal clause doesn't actually create any particularly actionable way to update the policy in case such a withdrawal is wanted. Or it might fail to protect another team from a shared space also being pulled out of this policy’s scope. ↩

3. mods might want to double-check that you have at least given the intended way a try at all, and that the new policy is documented somewhere, and clear in scope. Mods might also want to raise concerns ourselves if your new policy is expected to generate a lot more efforts for enforcement ↩

[joshtriplett]

we think we have a path forward here, but I'm too busy this week to write it up. I'll try to write something down by next Friday.

Confirmed, and thank you. I've drafted some policy tweaks to address my concerns, which @jyn514 and @jackh726 were both happy with; @jyn514 currently expects to have time to incorporate next week, and I expect to resolve all of my concerns and check my box once those tweaks are merged.

[joshtriplett]

Extensive thanks to @jyn514 both for a thoughtful policy and for carefully taking feedback into account.

Thank you as well to @jackh726 for detailed and nuanced conversations on where to draw boundaries, and for multiple inspired ideas on how to find well-balanced solutions.

@rfcbot resolved require-disclosure-even-for-draft-prs
(And the several other concerns that I didn't get around to raising because jyn addressed them at the same time as that one.)

@rfcbot reviewed

🚢

[steffahn]

I would also like to say thank you already to the incredible number people who have reviewed this policy and found it acceptable! 25 checked boxes already 🎁

(-> Convenience link to jump to the checkboxes without pressing "Load more" many many times <-)

Despite this progress, rfcbot will¹ actually treat this multi-team FCP proposal naively as a plain union of all members of all included teams, the final comment period will not start automatically unless N-2 boxes are checked in total.

This stands in contrast to the observation that each team taken separately - i.e. FCPing independently from each other - would have each already met the quorum (as we had manually tracked in this comment), and currently there are not any remaining concerns registered either.

To allow the final comment period to get start properly in spite of these technical limitations, I'd like to ask the 5 outstanding reviewers: please consider checking your boxes, too 🙏🏻! [we seem to still need at least 3 of you]"

Edit: Apparently this plea wasn't a desired approach to solve this, so nevermind the suggestion.

Footnotes

1. as far as I can tell; and I did double-check with the source code…

   …nonetheless, please correct me if I am wrong about this ↩

[jyn514]

@steffahn i would like to not ask people to check a box if they don't wish to. i believe Cargo's workaround for this is to have separate issues for each team with a separate FCP for each; i think that would work here.

[jyn514]

Since this is now effectively in FCP: I consider this policy "locked". I do not plan to make any additional changes until the PR is merged, unless someone on the FCP raises a concern that would prevent it from merging.

[jyn514]

(And the several other concerns that I didn't get around to raising because jyn addressed them at the same time as that one.)

I've had people ask me what changes were made, that this has the appearance of back-channeling. First, all changes to this PR are public. You can see the changes I made in response to Josh's comments here: https://github.com/rust-lang/rust-forge/pull/1040/changes/f716356205795cbca88af27f6bf4cc5908b6006e..f692c4786ae580c13751144c2b05e2f4a41e9007

The summary of those changes is:

• Add a "circuit breaker" policy that limits LLM PRs to at most half of all merged PRs.
• Disallow LLMs from attending meetings unless the members consent.
• Note explicitly that LLMs should not become a requirement to contribute, that they should be at most an optional tool.