Add rustdoc team processes

[GuillaumeGomez]

cc @rust-lang/rustdoc

Rendered

[ehuss]

Can you also add the rustdoc team to triagebot.toml for this directory and give yourselves permissions in https://github.com/rust-lang/team/blob/HEAD/repos/rust-lang/rust-forge.toml?

[aDotInTheVoid]

Thanks for working on this! I'm very happy to see this written down.

[fmease]

(This PR will obviously need a T-rustdoc FCP to make it official once most things have been sufficiently fleshed out)

[Manishearth]

overall this seems pretty good!

[GuillaumeGomez]

(This PR will obviously need a T-rustdoc FCP to make it official once most things have been sufficiently fleshed out)

Absolutely!

[GuillaumeGomez]

I added the change in triagebot.toml as suggested by @ehuss.

I went through all comments.

@fmease: Hopefully I clarified that the rustdoc "groups" are not full-fledged teams and as such, to be part of them, you need to be a member of the rustdoc team.

[lolbinarycat]

a few nitpicks

[apiraino]

left a comment after a cursory read.

Great work @GuillaumeGomez !

[camelid]

Thanks, this looks great! I left a few comments about small clarifications, but the overall charter looks excellent.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @GuillaumeGomez, I wasn't able to add the final-comment-period label, please do so.

[lolbinarycat]

I think that we should have a section for what happens if you get assigned as a reviewer on a PR that you don't have the time or experience to review properly, such as if it's a large change to a sub-component you haven't worked with before. Having a policy for this would probably be quite helpful for any new team members.

[fmease]

I think that we should have a section for what happens if you get assigned as a reviewer on a PR that you don't have the time or experience to review properly, such as if it's a large change to a sub-component you haven't worked with before.

This is already covered. See src/rustdoc/reviews.md:

Review Policy

The rustdoc team follows the same review policy as the compiler team. Take a look at
their chapter about it.

which delegates to compiler/reviews.md which in turn states (excerpts):

Basic Reviewing Requirements

There are a number of requirements that need to be met in order for reviewing to
be effective:

• Reviewers must have a sufficient understanding of the code under review.
  […]
• Reviewers must have a good idea on whether they are the right person to approve the change.
  […]

(see linked documents for more details)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

psst @GuillaumeGomez, I wasn't able to add the finished-final-comment-period label, please do so.

[GuillaumeGomez]

Need approval from @apiraino and @notriddle since they requested changes to be able to merge. :)

[apiraino]

left 2 nits but otherwise LGTM 👍

[apiraino]

:rocket: emoji for me

[notriddle]

👍

[fmease]

The GH interface tells me that merging is still blocked because all comments must be resolved first.

I've therefore gone through all unresolved comments and checked if they've been addressed and if so marked them as resolved.

There's now a single comment left to be addressed, namely #852 (comment). It's only a minor issue that is relatively easy to resolve. Once that's done we can merge this :)