Update Blog policy

src/platforms/blogs.md

@@ -4,7 +4,7 @@
 
 The Rust project maintains two blogs.
 The “main blog” ([blog.rust-lang.org](https://blog.rust-lang.org/index.html))
-and a “team blog”
+and a “inside Rust blog”
 ([blog.rust-lang.org/inside-rust](https://blog.rust-lang.org/inside-rust/)).
 This document provides the guidelines for what it takes to write
 a post for each of those blogs, as well as how to propose a post and to choose which blog is most
@@ -18,7 +18,7 @@ Ultimately, there are three options:
 - The main Rust blog
     - Suitable when your audience is “all Rust users or potential users”
     - Written from an “official position”, even if signed by an individual
-- The team Rust blog
+- The inside Rust blog
     - Suitable when your audience is “all Rust contributors or potential contributors”
     - Written from an “official position”, even if signed by an individual
 - Your own personal blog
@@ -42,10 +42,10 @@ describing an exciting project, but again in a way that represents the project a
 Manish Goregaokar’s report on [Fearless Concurrency in Firefox
 Quantum](https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html)).
 
-To decide between the main blog and the team blog, the question to ask yourself is **who is the
+To decide between the main blog and the inside Rust blog, the question to ask yourself is **who is the
 audience** for your post. Posts on the main blog should be targeting **all** Rust users or
 potential users — they tend to be lighter on technical detail, and written without requiring as
-much context. Posts on the team blog can assume a lot more context and familiarity with Rust.
+much context. Posts on the inside Rust blog can assume a lot more context and familiarity with Rust.
 
 ## Writing for the Main Rust blog
 
@@ -55,10 +55,6 @@ Post proposals describing exciting developments from within the Rust org are wel
 posts that describe exciting applications of Rust. We do not generally do “promotional
 cross-posting” with other projects, however.
 
-If you would like to propose a blog post for the main blog,
-please reach out to a [Leadership Council member](https://www.rust-lang.org/governance/teams/leadership-council).
-It is not suggested to just open PRs against the main Rust blog that add posts without first discussing it with a Leadership Council member.
-
 ### Release note blog posts
 
 One special case are the regular release note posts that accompany every Rust release. These are
@@ -79,15 +75,62 @@ Before publishing a release post, it goes through a drafting process:
 
 [1.39.0]: https://github.com/rust-lang/rust/milestone/66?closed=1
 
-## Team Rust blogs
+## Inside Rust blogs
 
-Teams can generally decide for themselves what to write on the team Rust blog.
+Teams can generally decide for themselves what to write on the inside Rust blog.
 
-Typical subjects for team Rust blog posts include:
+Typical subjects for inside Rust blog posts include:
 
 - New initiatives and calls for participation
 - Updates and status reports from ongoing work
 - Design notes
 
-To propose a blog post for the team blog of a particular team, reach out to the team lead or some
-other team representative.
+## Approval process
+
+For both the inside Rust and main blogs, we require an approval from:
+
+* Any team lead (top level or not)
+* Any leadership council member
+* Rust Foundation project director
+
+These are primarily the members of the
+[inside-rust-reviewers](https://github.com/rust-lang/team/blob/master/teams/inside-rust-reviewers.toml)
+marker team[^1]. Note that this applies to *both* the main and inside Rust blogs
+(renaming will happen at some later point).
+
+[^1]: Release team members are also included there for release blog purposes,
+  but aren't considered eligible approvers for any random post at this time.
+
+This approval should evaluate:
+
+* Is the tone and content of the post appropriate for the official venue?
+  * For example, we should avoid negative commentary about other ecosystems/languages.
+* Is it clear on whose behalf the post is written?
+  * This may not just be the by-line, but also the langauge used. If the post
+    takes official positions on behalf of the Rust Project as a whole, please
+    make sure at least one member of the leadership council signs off on it. If the
+    post is taking positions on behalf of a team, then that team should be in
+    agreement with the content.
+
+In general, it's a good idea to make sure someone (not necessarily the approver
+above) has proofread the post, but we generally prioritize unblocking posting
+over perfect content for the blog. Note that the above generally does *NOT*
+require that this person is a member of the team you're posting on behalf,
+though they should be aware of the post.
+
+### Getting a review
+
+Triagebot will automatically assign a leadership council representative to each
+new blog PR. That representative is who you should ping if you're not getting a
+review promptly, but you may get a faster review from asking team lead(s) for
+their review as well. In other words, we recommend escalating to your team
+lead(s), then pinging your team's leadership council representative, and
+finally the assigned reviewer.
+
+The assigned reviewer is ultimately responsible for making sure a review
+happens.
+
+Typically you should expect at least ~1 week of latency on initial review.
+Re-review for any final edits or a final merge button press can usually be
+promptly driven -- find a member of the group above available when you need to
+merge the post.