From 54b4aef475dda256a27c8e317eaeaa9126f2101a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 16 Oct 2020 00:59:24 -0400 Subject: [PATCH 1/4] backlog bonanza post --- .../inside-rust/2020-10-15-Backlog-Bonanza.md | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 posts/inside-rust/2020-10-15-Backlog-Bonanza.md diff --git a/posts/inside-rust/2020-10-15-Backlog-Bonanza.md b/posts/inside-rust/2020-10-15-Backlog-Bonanza.md new file mode 100644 index 000000000..adff17808 --- /dev/null +++ b/posts/inside-rust/2020-10-15-Backlog-Bonanza.md @@ -0,0 +1,107 @@ +--- +layout: post +title: "Lang team Backlog Bonanza and Project Proposals" +author: Nicholas Matsakis +team: the lang team +--- + +A month or two back, the lang team embarked on a new initiative that +we call the "Backlog Bonanza". The idea is simple: we are holding a +series of meetings in which we go through every pending RFC, one by +one, and try to reach some sort of determination about what to do with +it. Once we've finished that, we can start in on categorizing other +forms of backlog, such as tracking issues. + +### Possible outcomes for each RFC + +When we look at an RFC, we're typically deciding between one of the following outcomes: + +* **Close** the RFC, if we think that this problem is a good fit for the moment. +* Close, but **suggest a [project proposal]**, if we think that the we might like to see the problem solved, but we aren't sure if the RFC has the design right, or we're not sure who would be a good liaison. +* **Merge** the RFC, if we think the RFC basically nailed it and we have a lang team liaison in mind. + +[project proposal]: https://lang-team.rust-lang.org/proposing_a_project.html + +### Wait, what is a project proposal? + +I'm so glad you asked! The lang team is experimenting with a new +process for extending the language. Instead of starting out by writing +an RFC, the idea is to start with a **[project proposal]**. This is a +lightweight description that you do by [opening an issue] on the +[lang-team repository] using the "Project proposal" template. That +will create an issue and a corresponding stream on Zulip. + +[lang-team repository]: https://github.com/rust-lang/lang-team/ +[opening an issue]: https://github.com/rust-lang/lang-team/issues/new/choose + +In our [weekly triage meetings], we go over each new project proposal +and try to provide feedback. Project proposals generally result in one +of a few possible outcomes: + +* **Close**, if we feel like the idea isn't a good fit right now. +* **Suggest implementing**, if we feel like the idea is simple or obvious enough that an RFC isn't really needed. In that case, folks can just write a PR and we can use the fcp process to approve the PR. +* **Charter a project group**, if we feel like the idea is good, but we'd like to see the design spelled out. To do this, there has to be some lang-team liaison who wants to help see it through (though that liaison doesn't have to be a member of the team; [serving as a liaison is a good way to get more involved in the lang team][path]). + +[weekly triage meetings]: https://lang-team.rust-lang.org/meetings.html +[path]: https://blog.rust-lang.org/inside-rust/2020/07/09/lang-team-path-to-membership.html + +### Chartering a project group + +A "project group" is basically just a group of people working together +completing some idea. Project groups are often pretty small, just 1 or 2 +people, though they can get significantly larger. + +Creating a smaller project group is meant to be lightweight. We +basically convert the project proposal into a charter that states the +general goals and create an associated zulip stream where folks can +chat. Each project also gets a tracking issue that shows up on +our [lang team project board]. + +[recent example]: https://github.com/rust-lang/lang-team/tree/master/projects/declarative-macro-repetition-counts +[Rust team repo]: https://github.com/rust-lang/team +[lang team project board]: https://github.com/rust-lang/lang-team/projects/2 + +In the early stages of an idea, project groups work to draft an +RFC. This RFC is then taken to the lang-team for feedback. Once the +lang-team is basically happy on the direction things are going, we'll +encourage the group to open the RFC on the main RFC repository, where +it'll get feedback from a broader audience. + +Once the RFC is **accepted**, the hope is that project groups stick +around. If desired, the same folks can try to implement the feature +(in collaboration with the compiler team) or we can find new people. +But this way, as those people try to implement, they'll become a part +of the same group that was designing the feature so that we can +iterate more readily. The same logic applies to the other aspects of +shipping a feature, most notably writing documentation. + +### Tracking projects: the lang team project board + +I mentioned the [lang team project board] off-hand in the previous +paragraph. This is our attempt to track the ongoing efforts. It breaks +down the various projects into stages, with the things that are closest +to shipping coming first: + +* **Stabilization** -- projects that we are ready to stabilize, or in + the process of stabilizing. +* **Evaluation** -- projects that are fully implemented but where we are + seeking feedback on how well the design works. +* **Implementation** -- projects that are currently working on implementation + (and sometimes concurrent design iteration). +* **Pending RFC** -- projects with an RFC that is pending public comment +* **Design** -- projects actively iterating towards an RFC +* **Shortlisted** -- project ideas that we might want to take up once we + find a suitable liaison or people have enough bandwidth + +### Ways to get involved + +If you like, you are welcome to attend backlog bonanza meetings. They +are open for anyone and take place during our [design meeting slot] +most weeks. We haven't setup a very good process for announcing our +design meeting schedule, though, that's something that we need to get +better at. + +[design meeting]: https://lang-team.rust-lang.org/meetings.html + +Alternatively, if you have ideas you'd like to float, please feel free +to open a [project proposal]. From 44d6f3e53eaecb3128d176e990ed61c13a37935a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 16 Oct 2020 12:29:27 -0400 Subject: [PATCH 2/4] rephrase first bullet --- posts/inside-rust/2020-10-15-Backlog-Bonanza.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/posts/inside-rust/2020-10-15-Backlog-Bonanza.md b/posts/inside-rust/2020-10-15-Backlog-Bonanza.md index adff17808..2ecc2c63c 100644 --- a/posts/inside-rust/2020-10-15-Backlog-Bonanza.md +++ b/posts/inside-rust/2020-10-15-Backlog-Bonanza.md @@ -16,7 +16,7 @@ forms of backlog, such as tracking issues. When we look at an RFC, we're typically deciding between one of the following outcomes: -* **Close** the RFC, if we think that this problem is a good fit for the moment. +* **Close** the RFC, if the problem doesn't seem like high priority at the moment, or the solution seems quite far from what we would want. * Close, but **suggest a [project proposal]**, if we think that the we might like to see the problem solved, but we aren't sure if the RFC has the design right, or we're not sure who would be a good liaison. * **Merge** the RFC, if we think the RFC basically nailed it and we have a lang team liaison in mind. From 3bf9cf2fc545116ef30aa381b97e2c96e66805c1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 16 Oct 2020 12:31:57 -0400 Subject: [PATCH 3/4] rename blog post --- ...020-10-15-Backlog-Bonanza.md => 2020-10-16-Backlog-Bonanza.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename posts/inside-rust/{2020-10-15-Backlog-Bonanza.md => 2020-10-16-Backlog-Bonanza.md} (100%) diff --git a/posts/inside-rust/2020-10-15-Backlog-Bonanza.md b/posts/inside-rust/2020-10-16-Backlog-Bonanza.md similarity index 100% rename from posts/inside-rust/2020-10-15-Backlog-Bonanza.md rename to posts/inside-rust/2020-10-16-Backlog-Bonanza.md From f010032345d2dcc68e11b7f02783d0b7a799aaa8 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 16 Oct 2020 12:33:26 -0400 Subject: [PATCH 4/4] mention that we can up to dedicated repo for larger efforts --- posts/inside-rust/2020-10-16-Backlog-Bonanza.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/posts/inside-rust/2020-10-16-Backlog-Bonanza.md b/posts/inside-rust/2020-10-16-Backlog-Bonanza.md index 2ecc2c63c..8d211baa5 100644 --- a/posts/inside-rust/2020-10-16-Backlog-Bonanza.md +++ b/posts/inside-rust/2020-10-16-Backlog-Bonanza.md @@ -54,8 +54,9 @@ people, though they can get significantly larger. Creating a smaller project group is meant to be lightweight. We basically convert the project proposal into a charter that states the general goals and create an associated zulip stream where folks can -chat. Each project also gets a tracking issue that shows up on -our [lang team project board]. +chat. Each project also gets a tracking issue that shows up on our +[lang team project board]. (For larger project groups, we can make a +dedicated repo and an entry in the [Rust team repo].) [recent example]: https://github.com/rust-lang/lang-team/tree/master/projects/declarative-macro-repetition-counts [Rust team repo]: https://github.com/rust-lang/team