From 4fffea4a43f8a300e9ffe9d48be4def9fe1d3c6e Mon Sep 17 00:00:00 2001 From: Mark Rousskov Date: Sun, 11 May 2025 10:39:23 -0400 Subject: [PATCH] Update Blog policy --- src/platforms/blogs.md | 69 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 56 insertions(+), 13 deletions(-) diff --git a/src/platforms/blogs.md b/src/platforms/blogs.md index e826b70c8..fe1b891fe 100644 --- a/src/platforms/blogs.md +++ b/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.