Let's have a "documentation policy"?

The only semblance of Rust documentation policy/guidelines can be found in src/book/documentation.md, which I think should be moved elsewhere, perhaps to Style guidelines or own file. The chapter can remain in the book, but should only explain how stuff is done, not mandate policy (e.g. “The first line of a documentation comment should be a short summary of its functionality”).

One other thing: if we do create documentation policy/guidelines, should it be universal to Rust projects, or just the rust-lang/rust? I suggest we create “Documentation Guidelines”, either as a stand-alone document or as a chapter of “Style Guidelines” document, and have contributions to rust-lang/rust documentation follow those guidelines.

2 Likes

Not to be a downer, but there has been a great rush to institute new ‘policy’ lately, and it’s kind of grinding on me. Maybe we can focus on writing software for a while and not doing politics.

5 Likes

Would this be in the scope of the Community team?

This isn't strictly true, we have an accepted RFC: rfcs/text/0505-api-comment-conventions.md at master · rust-lang/rfcs · GitHub

Ideally, we'd come up with these guidelines, but until we have enough people doing lots of docs to make a documentaiton team, I don't think that it's worth it to do more. These kinds of RFCs are high, high, high effort.

Are you talking about the Stability discussions?

I actually forgot about that document, thanks.

Do we prefer plain or curly quotes in the text of the API documentation in Rust (rust-lang/rust itself)?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.