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

Policy: How to deal with undecided rules? #30

Open
ehuss opened this issue Mar 1, 2024 · 0 comments
Open

Policy: How to deal with undecided rules? #30

ehuss opened this issue Mar 1, 2024 · 0 comments
Labels
C-meta Category: Meta discussion about the repository itself. We should refine each use of the policy label

Comments

@ehuss
Copy link
Contributor

ehuss commented Mar 1, 2024

There will likely be many cases where the language team (or other teams) have not decided on how a particular part of the language should work, and we (the spec authors) know that there is ambiguity. How should we handle that?

I think waiting for a response from the lang team (or other teams) could significantly slow things down, and make it difficult to make progress.

Should the spec specifically mention things that are not yet resolved? Should we just not mention them at all, and track those via GitHub issues?

@JoelMarcey JoelMarcey added the C-meta Category: Meta discussion about the repository itself. We should refine each use of the policy label label Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-meta Category: Meta discussion about the repository itself. We should refine each use of the policy label
Development

No branches or pull requests

2 participants