Stability and team autonomy

[ehuss]

This issue is a fork from rust-lang/rustfmt#4228 (comment) regarding some changes to rustfmt.

The high-level questions are:

• What kind of autonomy does each dev-tools team have?
• What kind of process should each team follow?
• What kind of changes require soliciting community feedback (via processes like RFC or FCP, etc.)?
• What are the stability requirements of Rust tooling?
• What kind of criteria is used for making changes in stable vs nightly (unstable)?

AFAIK, the RFC guidance only discusses language changes, but not tooling changes. Rustfmt has its own formatting RFCs, but that doesn't help with guidance on other changes.

Should we:

• write down guidelines (similar to these) for when an RFC is required?
• write down guidelines and requirements of tool stability? (Including deprecation/removal process, etc.)

I personally think that Rust tools have had a culture initiated by the early developers of maintaining a high standard of backwards-compatibility. I think this is in some ways influenced by the Rust language and library teams having extremely high standards for backwards compatibility. But I don't think that has ever been written down as a requirement or guideline for the tools teams. It might also be worthwhile to explore if different tools might have different requirements for stability and backwards-compatibility.

cc @calebcartwright @killercup @Manishearth @fitzgen @kinnison @GuillaumeGomez @oli-obk @Xanewok

[calebcartwright]

cc @topecongiro

[Manishearth]

cc @nrc as ex-lead of devtools

So I'll admit that we never wrote this down anywhere, and it might be worth doing so.

The general model of the devtools team is, to me, similar to the model of the core team -- it's a "devolved governance" model where most powers are delegated to the subteams, but some important things "bubble up", especially things affecting other teams or stability. For example, the language team decided to make editions happen, but it's a large enough thing that core (and many other teams) were involved in that decisionmaking process at various points.

As much as possible it is encouraged for teams to carve out what is explicitly their "jurisdiction" via RFCs. See, for example, the Clippy RFC, which defines what is considered a breaking change, what changes require an RFC, and what changes the clippy team is empowered to make without much of an issue. This doesn't mean that anything not in these RFCs is out of scope, but it does mean some major changes may necessitate wider review.

But with or without such an RFC, subteams are trusted to do minor stuff on their own, and bring major issues to the attention of the larger team and/or the larger community.

Rustfmt does have such an RFC, mentioned in that issue: it has one that establishes a separate decisionmaking process for fmt changes, and one that specifies what is and isn't a breaking change (among other things).

I think a good litmus for what is considered "major" is: are there other teams that are stakeholders here? For rust-lang/rustfmt#4228 (comment) it is both the cargo team (whose stability is affected) and a little bit the release team (which tends to care about stability).

In general, stability issues are perhaps the most "major" of any kind of issue because they have such huge user impact. If you're changing how stability works in practice, it's probably important to get wider review and/or community input. The Rust project has always had a strong stance on stability.

Tool stability is absolutely underdefined: Individual tools (like rustfmt and clippy) both have RFCs that specifies what stability means for them, but we don't have a unifying concept to fall back on here, just intuition. Furthermore, the rustfmt RFC is from before rustup component add rustfmt became the default, and that's somewhat reflected in it. It might be due for an update.

As a team if you feel that there are some things that may be considered breaking or "major" but you don't want them to be, you should write an RFC establishing that. For example, clippy does not bother with stability in a world of deny(warnings) (otherwise we could never add lints), nor does it guarantee that all lints will always exist (only that non-deny-warnings code referring to lints by names will always compile).

I think an easy process for the devtools team to adopt is:

• tool subteams are largely autonomous
• if a tool is planning anything major -- a major feature, something that may be considered a breaking change, or something that otherwise drastically changes the experience, the subteam is strongly encouraged to bring it up in the devtools team meeting (lmk if you'd like a calendar invite) or at least email it to the list (tools@rlo) . They are also encouraged to do this if there are complicated interactions with another tool.
• Tool subteams are strongly encouraged to use RFCs for really major things so that the community may provide input. If you're unsure, bring it up to the umbrella devtools team and see what they think.
• Tools subteams are encouraged to write an RFC that establishes:
  • What decisions are up to the team
  • What decisions are up to the community process
  • What is considered stable
• Other devtools team members may request a tool team to hold off on a change and request an RFC or at least an rfcbot FCP vote on the issue. If this happens the devtools team will discuss it to come to consensus on whether or not that's necessary. If it is, the subteam should open the RFC or trigger the FCP and try to garner input from the community, and eventually vote on it alongside the umbrella devtools team (not all subteams have rfcbot set up, let me know if you need this).

The last point ideally does not ever need to be invoked, but can be in cases like this where a different team member (whose tool interfaces with the tool being changed) has a different idea of the severity of the situation, it can be helpful to have an easy process that slows stuff down till people have a chance to discuss.

Thoughts?

[calebcartwright]

Thank you so much @Manishearth! I found that really helpful.

As always I defer all things rustfmt to @topecongiro, but I do have some questions and thoughts:

• Are other dev tools managing their RFC process in-repo, or in https://github.com/rust-lang/rfcs or some other external repo?

• IIUC, new lints with clippy do not inherently require an RFC, but the clippy team uses discretion for certain types of changes and could potentially utilize an RFC-like process for a topic that's big/contentious enough?

• Furthermore, the rustfmt RFC is from before rustup component add rustfmt became the default, and that's somewhat reflected in it. It might be due for an update

  I agree. That RFC did a great job laying everything out going into the initial release, but there's probably a couple items that could use clarification and/or reconsideration now that it's been a couple years.

• if a tool is planning anything major -- a major feature, something that may be considered a breaking change, or something that otherwise drastically changes the experience, the subteam is strongly encouraged to bring it up in the devtools team meeting (lmk if you'd like a calendar invite) or at least email it to the list (tools@rlo) . They are also encouraged to do this if there are complicated interactions with another tool.

  gotcha, so whenever we have anything on the rustfmt side that we feel may fall into this bucket, we should bubble it up to the dev tools team via one of those channels. there's a handful of such items already (like what we should about the fact that users can use unstable opts on stable today 😬)

[Manishearth]

* Are other dev tools managing their RFC process in-repo, or in https://github.com/rust-lang/rfcs or some other external repo?

I believe everyone does rfcs on the RFCs repo, and occasionally does in-repo FCPs. But it's good that rustfmt has a separate style rfc process.

* IIUC, new lints with clippy do not inherently require an RFC, but the clippy team uses discretion for certain types of changes and could potentially utilize an RFC-like process for a topic that's big/contentious enough?

Correct

[calebcartwright]

I'm wondering if this can now be closed. Between this thread, conversations in other channels, the charter goals for all teams/wg's for this year, etc. it feels like the original questions have been covered and artifacts will be produced that will cover them.

I know that I've certainly got a much better understanding now of the structure and modes of operation, and how/where to surface up rustfmt items.

[Manishearth]

Yeah, makes sense!