-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluate improvements to the RFC system #23
Comments
These docs are very outdated and contains some misleading information. There are important things to resurrect at some point, which is something the Council should take on: * Definition of teams, and the structure of the Project in general: rust-lang/leadership-council#33 * Team charters, defining what each team's mission and responsibilities are: rust-lang/leadership-council#44 * Suggestions on moderation team processes should follow up with either the Council or https://github.com/rust-lang/moderation-team * Suggested decision making processes for teams: rust-lang/leadership-council#45 (and rust-lang/leadership-council#23 to some degree).
Comment from @yaahc on Zulip:
|
One concept that I would like to see iterated on more is that for large RFCs to start with a GitHub repo where individual issues and documents can be hashed out. The GitHub PR interface does not handle threading very well, and PRs with hundreds of comments are overwhelming and difficult to navigate. Some examples are https://github.com/Manishearth/namespacing-rfc and https://github.com/rust-lang/wg-cargo-std-aware. Similar to that, I think breaking down large RFCs into smaller decisions could help with making incremental progress. For example, starting with a statement of intent to tackle something, but not diving into the details too much. Then moving on to prototyping and experimenting, and collecting feedback. Then once things are approaching some steady state make a final proposal to stabilize. Perhaps there can be additional smaller steps added throughout this process. |
Brought up in https://rust-lang.zulipchat.com/#narrow/stream/392734-council/topic/Nominating.20issue.20for.20discussion, the current system does not handle small teams very well. rust-lang/rfcbot-rs#315 proposes to make an at least 2/3 requirement. Another suggestion in that thread is to allow it to be configurable by team. |
These docs are very outdated and contains some misleading information. There are important things to resurrect at some point, which is something the Council should take on: * Definition of teams, and the structure of the Project in general: rust-lang/leadership-council#33 * Team charters, defining what each team's mission and responsibilities are: rust-lang/leadership-council#44 * Suggestions on moderation team processes should follow up with either the Council or https://github.com/rust-lang/moderation-team * Suggested decision making processes for teams: rust-lang/leadership-council#45 (and rust-lang/leadership-council#23 to some degree).
Evaluate improvements to the RFC decision process, such as tracking and supporting multiple potential outcomes and changes in people's preferences without restarting decisions, and providing lighter-weight mechanisms for reversible decisions.
The RFC process itself can be grueling and stressful. Is there some way to improve that?
Should management of the RFC repo itself (like rust-lang/rfcs#3339) be the responsibility of the Leadership Council?
Should there be an issue tracker (see rust-lang/core-team#26)?
Currently @ehuss manages the RFC repo (such as tracking assignments, dealing with build and CI issues, etc.), just because they randomly decided to take on that responsibility. Should that be formalized? Can we find others to help?
I'm sure there are many other questions and concerns.
The text was updated successfully, but these errors were encountered: