Proposal + decision can't be viewed at once

[dabrahams]

It's not great to look through the proposals and not have the resolution of the proposal visible in the document. The Swift process with revision numbers (for things that went through multiple reviews) and references to discussion threads is easier for me (example here: https://github.com/apple/swift-evolution/blob/main/proposals/0244-opaque-result-types.md). Can we consider a format like that?

[jonmeow]

Regarding the proposal header, generally we're trying to keep state in the PR itself. e.g., if you look at the top of #83, you'll find several links to discussion about the proposal. This is why the proposal doc has a link back to the PR, we're just using the PR as a nexus for links.

[dabrahams]

Let's see how that works out. I'm reviewing proposals in the repo. I look at https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0083.md, and want to know if that's been accepted. I am a new contributor to the project, so I don't know anything about these conventions. First I have to know that "it's in the PR", so I ask somewhere and eventually somebody tells me. I click the PR link and arrive at #83. Oh, but it's actually not in the PR; there's just a link to the announcement in the PR. So I follow that, and I have an answer. That's a lot of clicks and web page hopping.

IMO it's better if the things that represent the official artifacts produced by the design process (proposals + decisions) are in one document that links to all its supporting material.

[jonmeow]

While I understand new contributors may not know conventions, the README.md notes the directory structure, and more can always be added to explain to look at the PR to minimize confusion.

While I recognize you're familiar with Swift's processes, I will note our current template is similar to Rust. My impression has been our proposal processes are closer to theirs overall, even though Swift and Rust aren't all that different.

Yes there are more clicks this way, but it's also easier to maintain and update. GitHub also has built-in facilities to link PRs and issues, and there are other conveniences. We used to have a little more in the template and steadily stripped it out to use a PR as the single source of truth.