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

meta-issue: what href should one use to refer to RFC's? #360

Closed
pnkfelix opened this issue Oct 7, 2014 · 4 comments · Fixed by #367
Closed

meta-issue: what href should one use to refer to RFC's? #360

pnkfelix opened this issue Oct 7, 2014 · 4 comments · Fixed by #367

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Oct 7, 2014

When I want to write a link to an RFC in a blog post (or in an issue in a repository of Rust code, or in the rust-lang/rust repo, etc), it is not clear if I should link to the issue number for the PR for that RFC, or to the RFC document itself.

The main problem here, to my mind, is that neither of the two options above is obviously correct, at least not until an RFC has reached the "complete" stage. Here is why:

  • The PR for an RFC will often link to the document that lives in the original author's branch. That branch may be deleted once the RFC is accepted.
  • The link to the RFC document itself is not stable, because the RFC moves from the author's branch into "active", and then from "active" to "complete".

(I am not entirely certain what the active/complete directory structure is buying us, to be honest.)

So: What href's should I be using right now? And also, should we perhaps change out conventions here to make one of the above choices "obviously right"? Note that either choice can work, given the appropriate conventions; for example, if we update the description in the PR to always point to a rendered "current' document (i.e. when it goes from "active" to "complete", then you also update the PR description), then the first bullet would be fine. Likewise, if we got rid of the "active"/"complete" directory structure, then the second bullet would be fine.

@pnkfelix
Copy link
Member Author

pnkfelix commented Oct 7, 2014

Here is our thoughts on how to resolve this:

We will update RFC process to:

  1. use one subdirectory instead of encoding the active/complete distinction in the subdirectory structure
  2. Put the list of active RFCs into the README.md (near the top presumably)
  3. use the original PR numbers for RFC numbers, instead of assigning them sequentially.

Discussion from weekly meeting: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-10-07.md#how-to-link-to-rfcs

@blaenk
Copy link
Contributor

blaenk commented Oct 9, 2014

The link to the RFC document itself is not stable, because the RFC moves from the author's branch into "active", and then from "active" to "complete".

I've linked to the RFC document and used the RFC document number to refer to it. I hadn't considered this before.

I agree with #3. Naming the RFC after the PR is more consistent and predictable. After all, an RFC that wasn't approved was still a request for comments.

@nodakai
Copy link

nodakai commented Nov 21, 2014

What was the rule for updating an RFC after it's merged to rust-lang/rfc ? Will it be updated only for filling out the indexing data and such, or making typographical changes? My understanding is that the PR page only links to the forked RFC repo and doesn't necessarily guide us to the latest version of the RFC text.

@nodakai
Copy link

nodakai commented Nov 21, 2014

Can you also update https://github.com/rust-lang/rfcs#the-rfc-life-cycle on removal of the "complete" folder? I'm new to the RFC process and got confused about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants