-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: RFC process redux #6
Conversation
Why open a new PR instead of just updating the text there? |
@steveklabnik because GitHub doesn't permit that. (GitHub's pull requests are not really collaborative.) |
All you have to do is push to the branch, and it updates the PR. That includes, for example, you sending a PR to @brson 's branch with updated text. Anyway, this is very off-topic, sorry. |
@@ -0,0 +1,116 @@ | |||
- Start Date: 2014/03/24 |
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.
Shouldn't this be 2014/03/11?
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.
Yes.
On the one hand I think we should absolutely retain rejected RFCs in the archive, as that's what PEP does. However, I think PEP has a higher bar for inclusion in the first place, so it's possible that we could rethink this if we start to become inundated with low-quality RFCs. |
As far as language goes ("accepted"/"rejected"), here are the categories that PEP uses:
|
Do we need to change the terminology for RFC states and decide on whether to keep old RFCs before accepting this? |
@@ -1,3 +1,7 @@ | |||
- Start Date: (fill me in with today's date, YYY/MM/DD) |
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.
I have an extremely strong preference for YYYY-MM-DD
rather than YYYY/MM/DD
(or YYY/MM/DD
!). Let's go with the standardised date formats.
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.
Seconded. ISO 8601 uses dashes, let's not diverge.
I think we should accept this, we can retroactively fill in old RFCs and change terminology. |
Agreed, this is really sort of a meta-RFC since it doesn't serve as a specification for implementing anything (and as such we can freely modify it after-the-fact). I still vote for making this RFC #0! |
Do we need an RFC for choosing the number of this RFC RFC? ;P |
@pnkfelix Good point, I abstain. :P |
It is an error to incompatibly override an equivalence constraint.
Fix a couple of typos
Explicitly remove credential delegation
This updates #2 to incorporate feedback. I've stuck with sequential numbers and added an unresolved question about what to do with rejected RFCs. Also add three pieces of metadata to the template (start date, RFC PR #, Rust Issue #).