Create an LLM policy team

[oli-obk]

rust-lang/rust-forge#1040 has landed as a first version of a policy, but I get lots of ppl who are concerned this will be impossible to change in the future. It's obviously a policy many can live with right now, though I don't get the impression it makes anyone particularly happy.

I think there are a few problems with most of the approaches we have taken:

• global policies: council isn't really equipped to both discuss all the minutiae and make a decision, without also running into the worry about impossible-to-change policies
• lacking a policy, the policy is whatever mods decide ad-hoc, or what reviewers reject ad-hoc, causing lots of strife
• Add an LLM policy for rust-lang/rust rust-forge#1040 being a "too many cooks" situation combined with everyone being able to raise a concern basically turns this into a trivially deadlockable thing
• everything is evolving so fast, any policy will need adjusting over time, and we can't take 6 months for every change

So I'm proposing to create a council sub-team with the following charter:

• LC delegates the power to write and edit the rust-lang/rust LLM policy as well as the global default policy
• They run their own FCPs, LC does not directly influence their work
• all their FCPs must be unanimous, not N-2
• membership is handled by the leadership council
• edits to the charter is handled by the leadership council
• the team has to be small enough for productive discussion while also accurately representing stance of the project
  • the members of the committee should be able to represent the full range of views in the project
  • other project members should feel enabled to discuss their views and concerns with at least one of the members, trusting that member to accurately capture and consider their perspective. For this, members of the committee must have the capacity to engage with people in the project if they raise any thoughts or concerns
• The LLM policy team has the following membership structure
  • the team has at least 3 members which are selected by the council
  • the council is expected to select people who cover a wide variety of perspectives and who are trusted by as much of the project as possible
  • project members are expected to reach out to a council member or team lead in case they do not sufficiently trust anyone on the LLM policy team to accurately represent their perspective, ideally suggesting project members who do. These concerns should be taken seriously both when setting up the committee, but also over the course of its existence
• The members are chosen so that the committee can find its way to consensus despite disagreement, and to make changes in a timely fashion in response to project needs and the changing landscape. This is more important than perfection at any point during the evolution of the policies. The policies can be edited by this team and everything can be changed again, so we should not let the perfect be the enemy of the good, as long as we are reasonably balancing project needs.
• The LLM policy team can change the global LLM policy should strive to do so (and inform all affected team members for repos not covered by a repo-specific policy). Being able to easily change things should alleviate all the concerns about a policy being better than no policy as the policy can just be changed over time.
• Limitations on LLM policies the committee can set up:
  • private LLM use for informative purposes cannot be restricted
  • no one can be required to use an LLM to participate anywhere, every project contribution must be doable without an LLM and if LLM usage is the usual way, there must be documentation how to do it without
• The committee's first action will be to launch a survey of team member's views on LLMs and what policies they would prefer to see. This is input to their decision process, not a majority vote via survey.
• The committee is available for advice on repo specific policies by teams, but usually does not prescribe what teams should do. (Except for rust-lang/rust, which is our shared space, and in case 1040 lands before the committee creates a policy, the committee is in charge of evolving that policy)
  • Adding global policies that cannot be overridden by teams should be a rare thing, but where necessary can still be done via shared LLM policy team + mods + council FCP.
• meetings are open for listening in, but participation by non-team members must be solicited by team members. Similarly there will be a publicly readable Zulip stream, where for now no external comments are permitted (and technically restricted so only team members can post).

Deadlock avoidance and council oversight

• In case the committee is unable to reach a consensus internally, this should be raised to the council which is then expected to resolve this issue within 3 weeks (since there is a sync council meeting every two weeks, this should give enough buffer) by replacing some of its members

The initial membership will be

• @jackh726
• @davidtwco
• @jdonszelmann
• @PLeVasseur

[oli-obk]

@rfcbot fcp merge leadership-council

[rust-rfcbot]

@oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Kobzol
• @ehuss
• @joshtriplett
• @lqd
• @m-ou-se
• @oli-obk
• @traviscross

Concerns:

• feedback-and-time (Create an LLM policy team #308 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

Consensus in the committee and velocity of changes are more important than perfection. Since the policies can be edited easily by this team and everything can be changed again, landing something imperfect but clear is better than nothing, even if it's not balancing project needs yet

I would express some disagreement with the way this point is stated, and with the way it was stated in the Council meeting. I do not, in fact, think it's appropriate for the committee to ratify changes swinging one way and then changes swinging another way, rather than attempting to find balancing steps that we can live with at each step.

I also think "responsiveness of changes" would be clearer than "velocity of changes", since we don't want churn, we want hill-climbing and responsiveness to project needs and the rapidly changing landscape.

I would like to see this rephrased to something more like:

The ability for the committee to find its way to consensus despite disagreement, and to make changes in a timely fashion in response to project needs and the changing landscape, are more important than perfection. The policies can be edited easily by this team and everything can be changed again, so we should not let the perfect be the enemy of the good, as long as we are reasonably balancing project needs.

within 6 months the committee will launch a survey of team member's views on LLMs and what policies they would prefer to see. This is input to their decision process, not a majority vote via survey.

Nit: 6 months is an eternity in the current landscape. I don't think it'd be an unreasonable ask for a dedicated committee to stand up a survey within 3 months, at most, and I think it's important that we do so. This will take time, as survey design takes care and may itself be a point a reasonable committee may need to iterate towards consensus on, but it shouldn't take 6 months.

In case the committee is unable to reach a concensus internally, this should be raised to the council which is then expected to resolve this issue within 2 weeks (since there is a sync council meeting every two weeks) by replacing some of its members

Nit: s/within two weeks (since there is a sync council meeting every two weeks)/within the next two Council meetings/. Or, alternatively, "three weeks". Otherwise, I think we'll feel very rushed to find willing new committee members and get agreement on them, if such a matter is raised right before a Council meeting, since we'd then have to settle it before the next meeting can convene to meet a 2 week deadline.

Also, s/concensus/consensus/.

upon committee creation the committee closes all outstanding LLM policies (rust-lang/rust-forge#1040 and rust-lang/rfcs#3959 at time of writing) and ratifies a modified (by themselves, as they see fit) version of rust-lang/rust-forge#1040 within a month. Whatever the version is by then they ratify.

I don't believe we should preempt the current process. Rather, I think we should allow them to proceed in parallel. If the current proposed rust-lang/rust policy successfully reaches ratification, it should be enacted as policy for rust-lang/rust. Independently, the committee could ratify project-wide policy that complements or preempts that rust-lang/rust policy. But let's not throw a crowbar into the current policy process at the last minute, rather than allowing it to complete if it's going to complete.

(This is the only item I'd consider a blocker; otherwise, happy to check a box for this.)

the council is expected to select people who cover a wide variety of perspectives and who are trusted by as much of the project as possible

I would explicitly add, "and who are skilled at finding cruxes of disagreement and collaboratively finding a path to consensus". Because it's not enough to represent a wide variety of project perspectives; we also need people who can successfully iterate towards consensus with each other even when they initially disagree.

[Kobzol]

Regarding a Project-wide policy: I see that some projects and teams within the rust-lang org (e.g. crates.io or regex) are adopting their own AI policies, and as long as they are not trying to "speak for the whole Project" or say something egregious that would be heavily concerning to Project people outside those teams, in the sense of negatively affecting the workings of the Rust Toolchain, or the Project as a whole, or its future maintenance, I don't know if the Council, or other teams, should have that much say in that. This is how the distributed and autonomous nature of the Project works, so unless we want to add AI rules directly to the Code of Conduct, which I think is the only shared and unsurpassable barrier across the whole Project, I think that we should respect what the other teams are doing.

So I think that if we have a Project-wide policy, it should mostly serve only as a default, but should be overrideable by individual teams. But I don't think that we particularly need a Project-wide policy at the moment. I mean, if it was simple to create and ratify, then sure, it would be great, but we know it is incredibly difficult.

Therefore, I'm not sure if we need a separate team for the reason of figuring out a Project-wide policy. I'm also unsure whether delegating this work to a small set of people will work better than what we tried so far. Both in the sense of it still being very difficult to find agreement even within this small set of people, and also in the sense of assuming that Project members will be happy with a few people appointed by the Council will represent their wishes well.

What I do really want though is for rust-lang/rust to finally have some policy that would help rejecting low-quality AI contributions from non-Project members in a more blessed way, as I think that is the main use-case that started this whole thing and that is the most important part to have under a policy. I don't really care how exactly would that policy be created, as long as people who interact with that repository find it agreeable at least somehow, I'd just like to help make it happen somehow.

I still hope that it might be possible to land rust-lang/rust-forge#1040 by the painful thundering herd discussion & revisit FCP boxes mechanism, and that this should only concern people who mainly work with rust-lang/rust, and not everyone in the Project, which is something that I think was affecting the discussions negatively before.

But if you think that creating this team will indeed help move the policy along somehow, I'm happy to try that experiment and check my box.

[oli-obk]

Regarding a Project-wide policy: I see that some projects and teams within the rust-lang org (e.g. crates.io or regex) are adopting their own AI policies, and as long as they are not trying to "speak for the whole Project" or say something egregious that would be heavily concerning to Project people outside those teams, in the sense of negatively affecting the workings of the Rust Toolchain, or the Project as a whole, or its future maintenance, I don't know if the Council, or other teams, should have that much say in that. This is how the distributed and autonomous nature of the Project works, so unless we want to add AI rules directly to the Code of Conduct, which I think is the only shared and unsurpassable barrier across the whole Project, I think that we should respect what the other teams are doing.

Edited to reflect that. Repos without a policy follow the global policy and only rust-lang/rust is managed by the committee

[joshtriplett]

the committee is available for advice on repo specific policies by teams, but does not prescribe what teams should do.

I do not think, in practice, that modification will result in us having sufficient project-wide policy. I think it would be more appropriate for the committee to establish a policy that clearly states which parts of policy are global and which parts of policy are subject to modification by teams (whether arbitrarily, or within parameters). We should, in fact, sometimes set project-wide policy, and not just end up with a bunch of team-specific policies.

By way of just one example: many of our communication channels and other resources are also shared. Policies are not just about "repos".

[BurntSushi]

We should, in fact, sometimes set project-wide policy, and not just end up with a bunch of team-specific policies.

Are there other examples of policies that should be project wide? I'm already using LLMs to create new code in regex, but it looks like rust-lang/rust-forge#1040 would ban that? (EDIT: Ban it for rust-lang/rust, but I guess I'm asking if that would be an example of a policy you have in mind for generalizing across the entire project) I'm not sure if I'm reading it right. There are a lot of rules there.

For context, this is the policy I added to regex. I've been adding it to my other personal repos too. It has worked surprisingly well to stop the deluge of auto-generated PRs. And I now feel empowered to just close them when they do appear.

[oli-obk]

Are there other examples of policies that should be project wide?

Moderation is not overridable by teams.

Similarly I would expect the boundaries specified in the charter to apply to all team specific policies, too (e.g. all processes must be doable without an LLM)

[BurntSushi]

Are there other examples of policies that should be project wide?

Moderation is not overridable by teams.

Similarly I would expect the boundaries specified in the charter to apply to all team specific policies, too (e.g. all processes must be doable without an LLM)

Ah sorry, I meant examples of LLM policies in particular.

[oli-obk]

There is rust-lang/rfcs#3959 and there were attempts like #273 where the latter is similar to yours (modulo not explicitly welcoming LLM contribs, but just rejecting the obviously bad ones)