Skip to content
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

Document the council's internal decision making process #31

Open
ehuss opened this issue Aug 8, 2023 · 4 comments
Open

Document the council's internal decision making process #31

ehuss opened this issue Aug 8, 2023 · 4 comments
Assignees
Labels
S-active Status: Someone or some group is actively working on this.

Comments

@ehuss
Copy link
Contributor

ehuss commented Aug 8, 2023

Currently it isn't clear exactly how or where decisions are made, or how they are communicated.

https://hackmd.io/@rust-leadership-council/ByAlBiHon contains a draft of some ideas on how to go about this.

This particularly includes where and how async decisions are made and publicized.

The RFC also suggests:

Establishing and agreeing on processes for faster decision-making for simple one-off operational matters, such as responding to emails reaching out to the Project.

@ehuss ehuss added the S-active Status: Someone or some group is actively working on this. label Aug 8, 2023
@ehuss ehuss self-assigned this Aug 8, 2023
@traviscross
Copy link
Contributor

As this is marked as active but has not seen an update here for some time, I nominate to review this and to consider whether we should leave an update here about the status.

This should take five minutes.

@traviscross traviscross added the I-council-nominated This issue nominated for discussion in a meeting. label Nov 8, 2024
@ehuss
Copy link
Contributor Author

ehuss commented Nov 22, 2024

I plan to review and edit my original proposal, and post it to the leadership-council repo soonish.

@Mark-Simulacrum Mark-Simulacrum removed the I-council-nominated This issue nominated for discussion in a meeting. label Nov 22, 2024
@ehuss
Copy link
Contributor Author

ehuss commented Nov 22, 2024

cc #71
Also @eholk mentioned clarifying our usage of fcpbot for having 100% approval instead of N-2.

@traviscross
Copy link
Contributor

traviscross commented Nov 22, 2024

Thinking about it, I'd probably just propose that we adopt the normal rfcbot rule. The 10 day final comment period serves as a kind of unanimity check, as any member can raise a blocking concern during that time and thereby stop the FCP.

Following the normal process for the rest of the project here would make us more comprehensible to the rest of the project, and I don't see a strong reason for us to deviate in this instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-active Status: Someone or some group is actively working on this.
Projects
None yet
Development

No branches or pull requests

3 participants