rewrite compiler team documentation #804
Conversation
rustbot
added
the
S-waiting-on-review
I assume then there will be dead links. Which maybe should be handled in the |
Probably only if a redirection makes sense. |
IMO Any dead link this patch is creating (if any) would make sense to be redirected (didn't look closely into that yet) |
| - Adding a new lint | ||
| - Follow the language team's process and have the implementation PR reviewed by a member of the | ||
| compiler team |
There was a problem hiding this comment.
This makes the assumption that the lint is lang lint, but we have lint that are purely compiler matter (e.g. explicit_builtin_cfgs_in_flags). We should probably differentiate both type of lints.
The same applies for FCW and default lint level.
There was a problem hiding this comment.
That makes sense, I've taken a stab at making the distinction where a lint is under our purview and when it isn't
I focused a bit on these changes and I'm not yet fully sold about removing this content separation. Though the new version is very clear, will it be equally clear to the reader? And at the same time search engine friendly. Right now our MCP page is the first clear hit I see on DuckDuckGo (and google) Screenshot
just my .2 cents |
jieyouxu
added
T-compiler
davidtwco
force-pushed
the
update-compiler-team-docs
branch
2 times, most recently
from
90066ea to
7938880
Compare
|
I can look into adding redirects once we're happy with the content.
I think it is clearer to the reader, but if we wanted to try and solicit some feedback from team members who haven't looked at this yet, members of other teams, or just members of the community who might want to make a contribution and know what to do, then we can do that. |
| There are three mechanisms that the team can use to approve a proposal (not all approval mechanisms | ||
| are suitable for each method of making a proposal - see below): |
There was a problem hiding this comment.
Discussion: I find this subsection somewhat confusing, because I would've expected this to say something more like:
- r+ is for approving PRs (concrete changes)
- Seconding is for Major Change Proposals (MCP)
- FCP is for (1) RFCs or stabilization decisions that require T-compiler FCP sign-off, or (2) explicitly making a significant decision on a team-basis
Maybe I just find the "proposal" here somewhat overloaded (i.e. proposal as in a suggestion/idea, versus proposal as a concrete change i.e. PR, or proposal as in MCP/RFC)?
There was a problem hiding this comment.
I intend proposal to be used for anything you'd like to suggest changing - we have these three different ways of making that type of suggestion, and we have three different ways of signing-off. Some ways of signing-off are incompatible with some ways of making a suggestion. This means that it makes sense to approve an MCP with an FCP now, for example.
There was a problem hiding this comment.
Right. I'll leave this unresolved for the time being in case someone has better wording suggestions, but feel free to resolve if there's no better wording proposed :)
| It is desired that a compiler team member or working group has loose ownership over a crate so | ||
| that there are clear owners who are responsible for making sure that new versions are published and | ||
| that pull requests are reviewed. |
There was a problem hiding this comment.
Suggestion: also as "fallback maintainer" maybe
There was a problem hiding this comment.
I haven't added this, it sounds like "fallback maintenance" means something that I'm unfamiliar with?
There was a problem hiding this comment.
What I meant was sometimes we have crates that are primarily maintained by contributors who are not yet team members, but are important enough that the team probably wants to act as a fallback maintainer in case the primary maintainer(s) are unavailable for various reasons.
... Probably not too important and might be confusing to mention idk
| - Where possible, only active participants in the crate (or related working group) need be on the | ||
| triagebot rotation for the crate. |
There was a problem hiding this comment.
Question: I think this needs setting from team repo, and not even all existing crates generally under compiler fallback maintenance has this IIRC
davidtwco
force-pushed
the
update-compiler-team-docs
branch
from
7938880 to
b015136
Compare
cc @rust-lang/compiler
This is a rewrite/restructuring of all of our documentation in forge.rust-lang.org - I removed some content is removed because it was better suited to the dev guide, and shuffled around/updated most of the rest. I wasn't especially good at commit hygiene in this PR, so it's all a bit muddled together unfortunately.
Most notably, I've added a big section on what combination of RFC/MCP/FCP/r+ you need for any given change - which is something that we often find ambiguous. None of the decisions I've made in that section are necessarily final, just what I thought made sense - happy to adjust.
Rendered