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.
When we look at an RFC, we're typically deciding between one of the following outcomes:
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.
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:
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. (For larger project groups, we can make a dedicated repo and an entry in the Rust team repo.)
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.
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:
If you like, you are welcome to attend backlog bonanza meetings. They are open for anyone and take place during our design meeting 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.
Alternatively, if you have ideas you'd like to float, please feel free to open a project proposal.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。