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

RFC: RFC process redux #6

Merged
merged 8 commits into from
Mar 13, 2014
Merged

RFC: RFC process redux #6

merged 8 commits into from
Mar 13, 2014

Conversation

brson
Copy link
Contributor

@brson brson commented Mar 12, 2014

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 #).

@brson brson mentioned this pull request Mar 12, 2014
@steveklabnik
Copy link
Member

Why open a new PR instead of just updating the text there?

@chris-morgan
Copy link
Member

@steveklabnik because GitHub doesn't permit that. (GitHub's pull requests are not really collaborative.)

@steveklabnik
Copy link
Member

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
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

@bstrie
Copy link
Contributor

bstrie commented Mar 12, 2014

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.

@bstrie
Copy link
Contributor

bstrie commented Mar 12, 2014

As far as language goes ("accepted"/"rejected"), here are the categories that PEP uses:

  • Meta
  • Informational
  • Accepted (not yet implemented)
  • Open (under consideration)
  • Finished (accepted and implemented)
  • Historical (Meta and Informational PEPs that have become obsolete)
  • Deferred
  • Abandoned, Withdrawn, and Rejected

@brson
Copy link
Contributor Author

brson commented Mar 13, 2014

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)
Copy link
Member

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.

Copy link
Contributor

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.

@alexcrichton
Copy link
Member

I think we should accept this, we can retroactively fill in old RFCs and change terminology.

@bstrie
Copy link
Contributor

bstrie commented Mar 13, 2014

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!

@pnkfelix
Copy link
Member

I thought having the template be RFC #0 (or 0000 I suppose) made some amount of sense.

@bstrie could you be convinced to change your vote to make this RFC #1 instead?

@huonw
Copy link
Member

huonw commented Mar 13, 2014

Do we need an RFC for choosing the number of this RFC RFC? ;P

@bstrie
Copy link
Contributor

bstrie commented Mar 13, 2014

@pnkfelix Good point, I abstain. :P

brson added a commit that referenced this pull request Mar 13, 2014
RFC: RFC process redux
@brson brson merged commit a260073 into rust-lang:master Mar 13, 2014
aturon added a commit that referenced this pull request Feb 5, 2015
Minor API tweaks here and there
alexcrichton added a commit that referenced this pull request Oct 25, 2016
withoutboats referenced this pull request in withoutboats/rfcs Jan 15, 2017
hadronized referenced this pull request in hadronized/rfcs Feb 10, 2017
withoutboats pushed a commit that referenced this pull request Apr 24, 2017
It is an error to incompatibly override an equivalence constraint.
@Centril Centril added A-meta Proposals about how we make proposals A-governance Proposals relating to how Rust is governed. labels Nov 23, 2018
epage pushed a commit to epage/rfcs that referenced this pull request Mar 29, 2022
Mark-Simulacrum pushed a commit that referenced this pull request Jun 15, 2023
Explicitly remove credential delegation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-governance Proposals relating to how Rust is governed. A-meta Proposals about how we make proposals
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants