-
Notifications
You must be signed in to change notification settings - Fork 3
Bootstrap the RFC process #1
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
Conversation
This is not a terribly important or relevant question, but is it preferred to wrap markdown at .e.g. 80 characters or are long lines generally considered fine for markdown? |
- string handling in nix (https://github.com/nix-rust/nix/issues/221) | ||
- the future of nix, including crate organization (https://github.com/nix-rust/nix/issues/190) | ||
|
||
Implementing an RFC process will give us a clear place to discuss those changes. Just as importantly, there will be a clear document stating what is being proposed. This way one doesn't need to read an entire comment thread to find out what the actual proposal is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementing an RFC process will give us a clear place to discuss those changes. Just as importantly, there will be a clear document stating what is being proposed...
Simplified Wording:
The RFC process provides a place to both discuss and document major design decisions. This provides readers with both the final decision in a clean form and (if needed) the discussion that lead up to the ratification of the RFC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
simplified further and added :-)
Looks good to me overall. 👍 |
It's an artifact of my usual markdown setup for blogging. I have softwrapping at 72 characters. I'll hard wrap this at 80 because I think it makes more sense. |
|
||
## More process | ||
|
||
We could instead opt for a heaver process. It is most likely not warranted for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*heavier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Removed the unresolved question. I have a template file ready to push up after this is merged. @carllerche @utkarshkukreti @arcnmx any comments? |
I also added a field for a tracking issue as in Rust RFCs. I had omitted it for this one, but in general we might have tracking issues for implementation / refactoring work. |
Oh there is nothing in here about how we decide to accept an RFC. Hmmmmm. |
👍 |
I'm merging this assuming rough consensus for now. We can resolve how to accept later, but I want to get the basics down so we can start drafting some RFCs for string handling. |
Rendered