Merge rationale and open question answers into proposals (#461)

In support of #426. There's still a little bit of surrounding framework that expects these decision files, but I'm trying to split out changes.

Note I'm dropping affirming/abstaining, as well as the accepted date -- I'd be happy to copy-paste decisions into comments on PRs if it'd be helpful, but I thought maybe we could drop those from the repo given they aren't asked for in on new proposals. If we change our minds, we can always look at git history too.

proposals/p0029.md

@@ -159,3 +159,12 @@ Disadvantages:
 -   Requires a custom presubmit on GitHub that checks linearity of a PR.
 -   The disadvantages of the fork and merge strategy regarding the complexity of
     history remain, but to a smaller degree, since non-linearity is restricted.
+
+## Rationale
+
+-   Easy to follow single source of truth will help foster an open and inclusive
+    community.
+-   Review requirements and focus on small, incremental changes match well
+    established engineering practices for ensuring the project and codebase
+    scale up both in size and time dimensions.
+-   Linear history seems easier for humans to reason about.

proposals/p0029_decision.md

@@ -1,32 +0,0 @@
-# Decision for: Linear, rebase, and pull-request GitHub workflow
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-06-30
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [gribozavr](https://github.com/gribozavr)
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Rationale
-
--   Easy to follow single source of truth will help foster an open and inclusive
-    community.
--   Review requirements and focus on small, incremental changes match well
-    established engineering practices for ensuring the project and codebase
-    scale up both in size and time dimensions.
--   Linear history seems easier for humans to reason about.

proposals/p0042.md

@@ -133,3 +133,22 @@ Disadvantages:
         understood the code is or may move it to be inconsistent with the wider
         codebase.
     -   Avoiding these two things are some of the primary goals of code review.
+
+## Rationale
+
+This proposal contains the right goals for the code review process in light of
+our project goals, and the proposal is well-tailored to achieve them.
+Specifically:
+
+-   Ensure high quality of code, documentation, and other artifacts. We consider
+    these all "code reviews" regardless of whether the final artifact is "code"
+    in a technical sense.
+-   Encourage broad participation and contribution to the community through code
+    reviews.
+-   Ensure code reviews are inclusive, respectful, and welcoming.
+-   Have clear, discoverable, and mechanically enforced (where possible) rules
+    for who can, who should, and who must review any particular change.
+
+We want pre-commit rather than post-commit review, and we want all changes to go
+through review. These guidelines are consistent with standard code review best
+practice, including what’s described in the cited sources.

proposals/p0042_decision.md

@@ -1,46 +0,0 @@
-# Decision for: Create code review guidelines
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-08-03
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [josh11b](https://github.com/josh11b)
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Open questions
-
-There were no open questions.
-
-## Rationale
-
-This proposal contains the right goals for the code review process in light of
-our project goals, and the proposal is well-tailored to achieve them.
-Specifically:
-
--   Ensure high quality of code, documentation, and other artifacts. We consider
-    these all "code reviews" regardless of whether the final artifact is "code"
-    in a technical sense.
--   Encourage broad participation and contribution to the community through code
-    reviews.
--   Ensure code reviews are inclusive, respectful, and welcoming.
--   Have clear, discoverable, and mechanically enforced (where possible) rules
-    for who can, who should, and who must review any particular change.
-
-We want pre-commit rather than post-commit review, and we want all changes to go
-through review. These guidelines are consistent with standard code review best
-practice, including what’s described in the cited sources.

proposals/p0044.md

@@ -63,6 +63,18 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Markdown editing](#markdown-editing)
         -   [StackEdit](#stackedit)
     -   [GitHub Markdown syntax highlighting](#github-markdown-syntax-highlighting)
+-   [Rationale](#rationale)
+    -   [Rationale for using a GitHub markdown-centric flow](#rationale-for-using-a-github-markdown-centric-flow)
+    -   [Rationale for not requiring tracking issues](#rationale-for-not-requiring-tracking-issues)
+    -   [Rationale for not committing proposals that are declined or deferred](#rationale-for-not-committing-proposals-that-are-declined-or-deferred)
+    -   [Rationale for committing a proposal to the repository it affects](#rationale-for-committing-a-proposal-to-the-repository-it-affects)
+    -   [Rationale for pushing high-level comments to GitHub](#rationale-for-pushing-high-level-comments-to-github)
+    -   [Open questions](#open-questions)
+        -   [Do we use a Google Docs-centric or GitHub Markdown-centric flow?](#do-we-use-a-google-docs-centric-or-github-markdown-centric-flow)
+        -   [Where should proposals be stored in GitHub?](#where-should-proposals-be-stored-in-github)
+        -   [Should we push comments to focus on GitHub?](#should-we-push-comments-to-focus-on-github)
+        -   [Should there be a tracking issue?](#should-there-be-a-tracking-issue)
+        -   [Should declined/deferred proposals be committed?](#should-declineddeferred-proposals-be-committed)
 
 <!-- tocstop -->
 
@@ -889,3 +901,105 @@ Note we can't take advantage of this until Carbon is public. We may be able to
 find a language with sufficiently similar syntax to
 [override the language](https://github.com/github/linguist/#overrides) and get
 reasonable highlighting.
+
+## Rationale
+
+During the decision process, several of the individual rationales were
+influenced by the idea that one could view the proposal process in one of two
+ways:
+
+1.  A PR-centric model. The review team is trying to achieve consensus around a
+    PR as a whole. The PR may (and often will) implement the proposed changes.
+    The proposal as essentially a description of the changes.
+
+2.  A proposal-centric model. The review team is trying to achieve consensus
+    around a proposal. The PR may show a preview of the implementation, but it
+    is purely informative.
+
+If one favors a PR-centric model, this steers one away from committing proposals
+that are not accepted, towards committing proposals to the affected repository,
+etc. In general, the PR-centric model was favored.
+
+### Rationale for using a GitHub markdown-centric flow
+
+-   The GitHub markdown-centric flow makes the on-ramp as smooth as possible for
+    external contributors.
+    -   This positions the project to maximize the ease of engaging with and
+        gaining contributions from the wider industry.
+-   The final documents must be in markdown form, so it is best if contributors
+    have the option to stay in markdown for the whole process. This is
+    significantly less complex than something that converts between formats:
+
+    -   Less to learn
+    -   Fewer steps in the process
+    -   No outdated versions in the old format left behind
+
+-   The technical flow seems on balance better than the Google Docs-based
+    workflow. The proposal does a really good job explaining advantages and
+    disadvantages. In summary, the Google Docs-centric workflow has a lot of
+    disadvantages that make it difficult to work with proposals over the long
+    term.
+
+### Rationale for not requiring tracking issues
+
+There were several members who had no strong preference on this issue. The
+consensus was that until there is a compelling reason to require tracking
+issues, the process is more light-weight without them.
+
+### Rationale for not committing proposals that are declined or deferred
+
+-   This approach seems simpler.
+-   When a proposal PR includes the changes put forth in the proposal
+    (PR-centric model), the declined PR might need to be considerably
+    changed--and might lose context--in order to be committed.
+-   The community will put a lot of work into developing, discussing, and making
+    a decision on a proposal. There may be valuable insight in rejected
+    proposals, so it makes sense to archive them. However, as noted, committing
+    the PR will not always be possible with reasonable effort if not working in
+    a proposal-centric model, as the proposal text may not stand on its own.
+-   While we may discover issues with this approach, it is better to try this
+    way, see if any issues can be rectified, and propose changes as necessary.
+
+### Rationale for committing a proposal to the repository it affects
+
+-   This keeps the proposal close to the repository, and therefore, the
+    community, that it affects.
+-   It facilitates autonomy of (future) review teams responsible for a
+    particular aspect of Carbon. For example, a reference implementation team
+    responsible for the carbon-toolchain repository.
+-   It simplifies the common case and makes it easier to find how each
+    repository evolves over time.
+
+### Rationale for pushing high-level comments to GitHub
+
+While opinions were not as strong, reasons given for perferring comments in
+GitHub:
+
+-   This flow will maximize the alignment with “normal” GitHub development flow.
+    -   This both improves pulling external/new people into the flow, and will
+        reduce the number of flows they need to learn/remember/tool for.
+-   We will get ecosystem benefits as this flow continues to be optimized by
+    GitHub and those using it.
+
+### Open questions
+
+#### Do we use a Google Docs-centric or GitHub Markdown-centric flow?
+
+**Decision:** Use GitHub Markdown-centric flow.
+
+#### Where should proposals be stored in GitHub?
+
+**Decision:** Store proposals in the repository they affect.
+
+#### Should we push comments to focus on GitHub?
+
+**Decision:** Push high-level comments to GitHub, rather than focusing these
+discussions in Discourse.
+
+#### Should there be a tracking issue?
+
+**Decision:** Don't require tracking issues.
+
+#### Should declined/deferred proposals be committed?
+
+**Decision:** Do not commit declined/deferred proposals.

proposals/p0044_decision.md

@@ -1,125 +0,0 @@
-# Decision for: Proposal Tracking
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-06-02
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Open questions
-
-### Do we use a Google Docs-centric or GitHub Markdown-centric flow?
-
-**Decision:** Use GitHub Markdown-centric flow.
-
-### Where should proposals be stored in GitHub?
-
-**Decision:** Store proposals in the repository they affect.
-
-### Should we push comments to focus on GitHub?
-
-**Decision:** Push high-level comments to GitHub, rather than focusing these
-discussions in Discourse.
-
-### Should there be a tracking issue?
-
-**Decision:** Don't require tracking issues.
-
-### Should declined/deferred proposals be committed?
-
-**Decision:** Do not commit declined/deferred proposals.
-
-## Rationale
-
-During the decision process, several of the individual rationales were
-influenced by the idea that one could view the proposal process in one of two
-ways:
-
-1.  A PR-centric model. The review team is trying to achieve consensus around a
-    PR as a whole. The PR may (and often will) implement the proposed changes.
-    The proposal as essentially a description of the changes.
-
-2.  A proposal-centric model. The review team is trying to achieve consensus
-    around a proposal. The PR may show a preview of the implementation, but it
-    is purely informative.
-
-If one favors a PR-centric model, this steers one away from committing proposals
-that are not accepted, towards committing proposals to the affected repository,
-etc. In general, the PR-centric model was favored.
-
-### Rationale for using a GitHub markdown-centric flow
-
--   The GitHub markdown-centric flow makes the on-ramp as smooth as possible for
-    external contributors.
-    -   This positions the project to maximize the ease of engaging with and
-        gaining contributions from the wider industry.
--   The final documents must be in markdown form, so it is best if contributors
-    have the option to stay in markdown for the whole process. This is
-    significantly less complex than something that converts between formats:
-
-    -   Less to learn
-    -   Fewer steps in the process
-    -   No outdated versions in the old format left behind
-
--   The technical flow seems on balance better than the Google Docs-based
-    workflow. The proposal does a really good job explaining advantages and
-    disadvantages. In summary, the Google Docs-centric workflow has a lot of
-    disadvantages that make it difficult to work with proposals over the long
-    term.
-
-### Rationale for not requiring tracking issues
-
-There were several members who had no strong preference on this issue. The
-consensus was that until there is a compelling reason to require tracking
-issues, the process is more light-weight without them.
-
-### Rationale for not committing proposals that are declined or deferred
-
--   This approach seems simpler.
--   When a proposal PR includes the changes put forth in the proposal
-    (PR-centric model), the declined PR might need to be considerably
-    changed--and might lose context--in order to be committed.
--   The community will put a lot of work into developing, discussing, and making
-    a decision on a proposal. There may be valuable insight in rejected
-    proposals, so it makes sense to archive them. However, as noted, committing
-    the PR will not always be possible with reasonable effort if not working in
-    a proposal-centric model, as the proposal text may not stand on its own.
--   While we may discover issues with this approach, it is better to try this
-    way, see if any issues can be rectified, and propose changes as necessary.
-
-### Rationale for committing a proposal to the repository it affects
-
--   This keeps the proposal close to the repository, and therefore, the
-    community, that it affects.
--   It facilitates autonomy of (future) review teams responsible for a
-    particular aspect of Carbon. For example, a reference implementation team
-    responsible for the carbon-toolchain repository.
--   It simplifies the common case and makes it easier to find how each
-    repository evolves over time.
-
-### Rationale for pushing high-level comments to GitHub
-
-While opinions were not as strong, reasons given for perferring comments in
-GitHub:
-
--   This flow will maximize the alignment with “normal” GitHub development flow.
-    -   This both improves pulling external/new people into the flow, and will
-        reduce the number of flows they need to learn/remember/tool for.
--   We will get ecosystem benefits as this flow continues to be optimized by
-    GitHub and those using it.

proposals/p0051.md

@@ -23,6 +23,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Completely remove the community priority from this document](#completely-remove-the-community-priority-from-this-document)
         -   [Add project goals to the priority list](#add-project-goals-to-the-priority-list)
         -   [Merge project goals and language goals](#merge-project-goals-and-language-goals)
+-   [Rationale](#rationale)
+    -   [Open questions](#open-questions)
 
 <!-- tocstop -->
 
@@ -210,3 +212,30 @@ Disadvantages:
 
 -   Previous setup raised objections over why the community goal wasn't part of
     the priority list.
+
+## Rationale
+
+A concrete set of goals is essential to ensure that contributors to the Carbon
+project are working in the same direction, and as a guide for what constitutes
+progress in every aspect of the project. It is important to have a coherent,
+agreed-upon vision and direction for a programming language, as a social
+contract between people who work on it and people who use it. The goals listed
+have been iterated on for many months by many parties.
+
+These goals reflect not only the kind of community and language that the core
+team would like to build, but also the kind of community and language that a
+large population of C++ users have been asking for from C++ itself. As a
+consequence, this particular set of goals seems like an important direction in
+which to experiment with a candidate future for C++ itself. By doing so, it will
+address a specific group of C++ users.
+
+While there may be some uncertainty about resolving conflicts between goals,
+particularly migratability and C++ interoperability, the core team feels that
+they are generally in alignment in this regard. The priority among goals can be
+revised as needed based on the experience of using it in practice.
+
+### Open questions
+
+There were no open questions. GitHub issue
+[106](https://github.com/carbon-language/carbon-lang/issues/106) contains points
+to be considered and, if necessary, resolved in a subsequent proposal.

proposals/p0051_decision.md

@@ -1,50 +0,0 @@
-# Decision for: Goals for Carbon
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-07-14
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
-
-## Open questions
-
-There were no open questions. GitHub issue
-[106](https://github.com/carbon-language/carbon-lang/issues/106) contains points
-to be considered and, if necessary, resolved in a subsequent proposal.
-
-## Rationale
-
-A concrete set of goals is essential to ensure that contributors to the Carbon
-project are working in the same direction, and as a guide for what constitutes
-progress in every aspect of the project. It is important to have a coherent,
-agreed-upon vision and direction for a programming language, as a social
-contract between people who work on it and people who use it. The goals listed
-have been iterated on for many months by many parties.
-
-These goals reflect not only the kind of community and language that the core
-team would like to build, but also the kind of community and language that a
-large population of C++ users have been asking for from C++ itself. As a
-consequence, this particular set of goals seems like an important direction in
-which to experiment with a candidate future for C++ itself. By doing so, it will
-address a specific group of C++ users.
-
-While there may be some uncertainty about resolving conflicts between goals,
-particularly migratability and C++ interoperability, the core team feels that
-they are generally in alignment in this regard. The priority among goals can be
-revised as needed based on the experience of using it in practice.

proposals/p0063.md

@@ -16,6 +16,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Background](#background)
 -   [Proposal](#proposal)
 -   [Alternatives considered](#alternatives-considered)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -36,3 +37,36 @@ See /docs/project/going_public.md.
 
 We have also considered going public immediately. We believe the noted criteria
 are important to address before proceeding.
+
+## Rationale
+
+"An open, inclusive process for Carbon changes" requires us to make the decision
+to go public in a clear and unsurprising way, with criteria that are written
+down.
+
+Going public too early introduces risks to the long-term evolution and
+maintenance of the language by increasing the costs of the community members
+developing it.
+
+Ensuring that Carbon meets its functional goals, especially that of
+interoperability and migration, will inherently require large scale
+experimentation that is infeasible to do without becoming public at some point.
+
+The core team is aligned on the core policy decisions, which are:
+
+-   The decision to go public will go through the usual proposal process.
+-   The structure of the proposal gives the things that we are looking for prior
+    to going public.
+-   We expect to delay announcing to the extent we can.
+-   We do not expect that to be so late that everything is done and we are ready
+    to ship. That is, we are not going to wait until version 1.0 is ready.
+    -   We don't expect this to be so late that Carbon is no longer an
+        experiment.
+
+Changes to the text and wording that align with these items should be submitted
+as code reviews. The core team members chandlerc and zygloid will both approve
+each code review.
+
+An example change that would be covered by a code review: there will be no
+automatic going public just because the criteria are met -- it will be a
+decision of the core team.

proposals/p0063_decision.md

@@ -1,60 +0,0 @@
-# Decision for: Criteria for Carbon to go public
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-11-03
-
-Affirming:
-
--   [chandlerc](https://github.com/chandlerc)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [austern](https://github.com/austern)
--   [geoffromer](https://github.com/geoffromer)
-
-## Open questions
-
-None.
-
-## Rationale
-
-"An open, inclusive process for Carbon changes" requires us to make the decision
-to go public in a clear and unsurprising way, with criteria that are written
-down.
-
-Going public too early introduces risks to the long-term evolution and
-maintenance of the language by increasing the costs of the community members
-developing it.
-
-Ensuring that Carbon meets its functional goals, especially that of
-interoperability and migration, will inherently require large scale
-experimentation that is infeasible to do without becoming public at some point.
-
-The core team is aligned on the core policy decisions, which are:
-
--   The decision to go public will go through the usual proposal process.
--   The structure of the proposal gives the things that we are looking for prior
-    to going public.
--   We expect to delay announcing to the extent we can.
--   We do not expect that to be so late that everything is done and we are ready
-    to ship. That is, we are not going to wait until version 1.0 is ready.
-    -   We don't expect this to be so late that Carbon is no longer an
-        experiment.
-
-Changes to the text and wording that align with these items should be submitted
-as code reviews. The core team members chandlerc and zygloid will both approve
-each code review.
-
-An example change that would be covered by a code review: there will be no
-automatic going public just because the criteria are met -- it will be a
-decision of the core team.

proposals/p0074.md

@@ -20,6 +20,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Alternatives considered](#alternatives-considered)
     -   [Alternative 1](#alternative-1)
     -   [Alternative 2](#alternative-2)
+-   [Rationale](#rationale)
+    -   [Open questions](#open-questions)
+        -   [Do we want to add the proposal to the core team meeting agenda when the deadline for comments is announced, or when the deadline is reached?](#do-we-want-to-add-the-proposal-to-the-core-team-meeting-agenda-when-the-deadline-for-comments-is-announced-or-when-the-deadline-is-reached)
 
 <!-- tocstop -->
 
@@ -94,3 +97,21 @@ meetings, as the deciders would have less time to get their decisions in. It has
 the potential to reduce the velocity of decisions if it results in decisions
 happening later than they would with an earlier meeting date (decision
 deadline).
+
+## Rationale
+
+-   This directly supports our community goals: not everybody is in a position
+    to respond to events with less than a day of latency, so longer lead times
+    before deadlines will help enable them to participate.
+    -   Longer lead time makes it more likely that we'll get substantive
+        comments.
+-   The answer to the open question doesn't strongly matter, and there is a
+    preference for leaving it to the review managers' discretion rather than
+    having the core team decide.
+
+### Open questions
+
+#### Do we want to add the proposal to the core team meeting agenda when the deadline for comments is announced, or when the deadline is reached?
+
+The core team is okay with available options, and treating this as a bikeshed
+that can be resolved by review managers as part of doc changes.

proposals/p0074_decision.md

@@ -1,41 +0,0 @@
-# Decision for: Change comment/decision timelines in proposal process
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-06-02
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
-
-## Open questions
-
-### Do we want to add the proposal to the core team meeting agenda when the deadline for comments is announced, or when the deadline is reached?
-
-The core team is okay with available options, and treating this as a bikeshed
-that can be resolved by review managers as part of doc changes.
-
-## Rationale
-
--   This directly supports our community goals: not everybody is in a position
-    to respond to events with less than a day of latency, so longer lead times
-    before deadlines will help enable them to participate.
-    -   Longer lead time makes it more likely that we'll get substantive
-        comments.
--   The answer to the open question doesn't strongly matter, and there is a
-    preference for leaving it to the review managers' discretion rather than
-    having the core team decide.

proposals/p0083.md

@@ -20,6 +20,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Single-file design overview](#single-file-design-overview)
     -   [No in-progress design overview](#no-in-progress-design-overview)
     -   [No overview of designs](#no-overview-of-designs)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -155,3 +156,33 @@ Disadvantages:
     -   There's disagreement about whether the text of README.md offers any
         utility:
         [comment thread](https://github.com/carbon-language/carbon-lang/pull/83/files/25437de9e61b3a15e8ddde67b6297f1795922355..97da855dbe6023930e02473af46abea03af991e7#r444487049)
+
+## Rationale
+
+This proposal provides some much-needed context for a lot of our discussions and
+deliberations about Carbon. Having a skeleton in place for the language design
+is an important step forward. We can't make language design decisions in a
+vacuum -- we need a "blurry outline" of the big picture before we can start
+filling in the details of any particular area. We need to establish a common
+frame of reference regarding the overall shape of the language, so that we can
+parallelize the in-depth design work.
+
+That means that, by necessity, this proposal suggests lots of concrete design
+decisions that have not yet had sufficient analysis for us to affirm them. There
+is a shared understanding that we are not committing to any of those decisions,
+only to the broad picture painted by the combination of those decisions, and
+that all such decisions need to be revisited by another proposal before we
+consider them to be agreed on. There is a substantial risk of anchoring how we
+think about Carbon -- we’ll just have to do our best to avoid taking this doc as
+a given when evaluating subsequent proposals. Those propopsals must justify a
+direction that agrees with this doc as much as one that does not agree with it.
+
+This doc sets the stage for increasingly incremental steps towards a complete
+design. Establishing a structure for the design is especially helpful as it will
+show how things do or do not connect across the language.
+
+Adopting this largely work-in-progress overview in order to see the structure of
+things, while still needing to resolve the specifics in each area, will directly
+help reinforce our goal of language evolution over time. This will help us learn
+how to effectively iterate, and how to compensate and overcome the risks of
+anchoring, change aversion, and other challenges.

proposals/p0083_decision.md

@@ -1,57 +0,0 @@
-# Decision for: An incomplete, early, and in-progress overview of the language design
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-07-28
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
-
-## Open questions
-
-There were no open questions.
-
-## Rationale
-
-This proposal provides some much-needed context for a lot of our discussions and
-deliberations about Carbon. Having a skeleton in place for the language design
-is an important step forward. We can't make language design decisions in a
-vacuum -- we need a "blurry outline" of the big picture before we can start
-filling in the details of any particular area. We need to establish a common
-frame of reference regarding the overall shape of the language, so that we can
-parallelize the in-depth design work.
-
-That means that, by necessity, this proposal suggests lots of concrete design
-decisions that have not yet had sufficient analysis for us to affirm them. There
-is a shared understanding that we are not committing to any of those decisions,
-only to the broad picture painted by the combination of those decisions, and
-that all such decisions need to be revisited by another proposal before we
-consider them to be agreed on. There is a substantial risk of anchoring how we
-think about Carbon -- we’ll just have to do our best to avoid taking this doc as
-a given when evaluating subsequent proposals. Those propopsals must justify a
-direction that agrees with this doc as much as one that does not agree with it.
-
-This doc sets the stage for increasingly incremental steps towards a complete
-design. Establishing a structure for the design is especially helpful as it will
-show how things do or do not connect across the language.
-
-Adopting this largely work-in-progress overview in order to see the structure of
-things, while still needing to resolve the specifics in each area, will directly
-help reinforce our goal of language evolution over time. This will help us learn
-how to effectively iterate, and how to compensate and overcome the risks of
-anchoring, change aversion, and other challenges.

proposals/p0107.md

@@ -19,6 +19,10 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Should we switch to a library-oriented structure that's package-agnostic?](#should-we-switch-to-a-library-oriented-structure-thats-package-agnostic)
     -   [Should there be a tight association between file paths and packages/libraries?](#should-there-be-a-tight-association-between-file-paths-and-packageslibraries)
 -   [Justification](#justification)
+-   [Rationale](#rationale)
+    -   [Open questions](#open-questions)
+        -   [Should we switch to a library-oriented structure that's package-agnostic?](#should-we-switch-to-a-library-oriented-structure-thats-package-agnostic-1)
+        -   [Should there be a tight association between file paths and packages/libraries?](#should-there-be-a-tight-association-between-file-paths-and-packageslibraries-1)
 
 <!-- tocstop -->
 
@@ -151,3 +155,42 @@ The end result of taking both alternatives would be that:
 
     -   The syntax of `import` should enable extending imports for use in
         interoperability code.
+
+## Rationale
+
+This proposal provides an organizational structure that seems both workable and
+aligns well with Carbon's goals:
+
+-   Distinct and required top-level namespace -- "package"s from the proposal --
+    both matches software best practices for long-term evolution, and avoids
+    complex and user-confusing corner cases.
+-   Providing a fine-grained import structure as provided by the "library"
+    concept supports scalable build system implementations while ensuring
+    explicit dependencies.
+-   The structured namespace facilities provide a clear mechanism to migrate
+    existing hierarchical naming structures in C++ code.
+
+### Open questions
+
+#### Should we switch to a library-oriented structure that's package-agnostic?
+
+-   **Decision:** No.
+-   **Rationale:** While this would simplify the overall set of constructs
+    needed, removing the concept of a global namespace remained desirable and
+    would require re-introducing much of the complexity around top-level
+    namespaces. Overall, the simplification trade-off didn't seem significantly
+    better.
+
+#### Should there be a tight association between file paths and packages/libraries?
+
+-   **Decision:** Yes, for the API files in libraries. Specifically, the library
+    name should still be written in the source, but it should be checked to
+    match -- after some platform-specific translation -- against the path.
+-   **Note:** Sufficient restrictions to result in a portable and simple
+    translation on different filesystems should be imposed, but the Core team
+    was happy for these restrictions to be developed as part of implementation
+    work.
+-   **Rationale:** This will improve usability and readability for users by
+    making it obvious how to find the files that are being imported. Similarly,
+    this will improve tooling by increasing the ease with which tools can find
+    imported APIs.

proposals/p0107_decision.md

@@ -1,62 +0,0 @@
-# Decision for: Code and name organization
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-10-06
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [josh11b](https://github.com/josh11b)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [noncombatant](https://github.com/noncombatant)
-
-## Open questions
-
-### Should we switch to a library-oriented structure that's package-agnostic?
-
--   **Decision:** No.
--   **Rationale:** While this would simplify the overall set of constructs
-    needed, removing the concept of a global namespace remained desirable and
-    would require re-introducing much of the complexity around top-level
-    namespaces. Overall, the simplification trade-off didn't seem significantly
-    better.
-
-## Should there be a tight association between file paths and packages/libraries?
-
--   **Decision:** Yes, for the API files in libraries. Specifically, the library
-    name should still be written in the source, but it should be checked to
-    match -- after some platform-specific translation -- against the path.
--   **Note:** Sufficient restrictions to result in a portable and simple
-    translation on different filesystems should be imposed, but the Core team
-    was happy for these restrictions to be developed as part of implementation
-    work.
--   **Rationale:** This will improve usability and readability for users by
-    making it obvious how to find the files that are being imported. Similarly,
-    this will improve tooling by increasing the ease with which tools can find
-    imported APIs.
-
-## Rationale
-
-This proposal provides an organizational structure that seems both workable and
-aligns well with Carbon's goals:
-
--   Distinct and required top-level namespace -- "package"s from the proposal --
-    both matches software best practices for long-term evolution, and avoids
-    complex and user-confusing corner cases.
--   Providing a fine-grained import structure as provided by the "library"
-    concept supports scalable build system implementations while ensuring
-    explicit dependencies.
--   The structured namespace facilities provide a clear mechanism to migrate
-    existing hierarchical naming structures in C++ code.

proposals/p0113.md

@@ -24,6 +24,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Place `*` and `&` with the variable in pointer declarations](#place--and--with-the-variable-in-pointer-declarations)
         -   [Place `const` after the type](#place-const-after-the-type)
     -   [Use the LLVM coding standards](#use-the-llvm-coding-standards)
+-   [Rationale](#rationale-1)
 
 <!-- tocstop -->
 
@@ -194,3 +195,17 @@ Disadvantages:
 -   LLVM has not yet adopted C++17 due to existing users who still need C++14.
     However, Carbon has no such need to constrain its version of C++ and can
     effectively adopt and use more modern C++ versions.
+
+## Rationale
+
+A common, established style guide will allow us to focus on the more important
+aspects of coding and code review. Once we're familiar with the rules, their
+consistent application will result in a more readable codebase, and rules that
+can largely be automated by clang-format will result in a more efficient
+development process.
+
+This particular ruleset attempts to align with our expected lexical rules for
+the Carbon language (for example, comment syntax and capitalization rules),
+which will also mean that we can use a largely consistent style between the
+aspects of the toolchain implemented in C++ and the aspects implemented in
+Carbon.

proposals/p0113_decision.md

@@ -1,37 +0,0 @@
-# Decision for: Add a C++ style guide
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-10-27
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [noncombatant](https://github.com/noncombatant)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [tituswinters](https://github.com/tituswinters)
-
-## Rationale
-
-A common, established style guide will allow us to focus on the more important
-aspects of coding and code review. Once we're familiar with the rules, their
-consistent application will result in a more readable codebase, and rules that
-can largely be automated by clang-format will result in a more efficient
-development process.
-
-This particular ruleset attempts to align with our expected lexical rules for
-the Carbon language (for example, comment syntax and capitalization rules),
-which will also mean that we can use a largely consistent style between the
-aspects of the toolchain implemented in C++ and the aspects implemented in
-Carbon.

proposals/p0120.md

@@ -17,6 +17,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Justification](#justification)
 -   [Alternatives considered](#alternatives-considered)
     -   [Use a principle to address performance of idiomatic code](#use-a-principle-to-address-performance-of-idiomatic-code)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -73,3 +74,12 @@ A principle is another way of addressing non-obvious conclusions based on goals.
 However, performance of idiomatic code seems quick to state, and not worth
 splitting off to a separate doc. I believe the cost-benefit favors keeping it in
 the goals doc.
+
+## Rationale
+
+This addresses a number of rough edges and small missing pieces in the original
+proposal, providing useful clarification. This follow up is expected as part of
+the launch and iterate process we use to keep our velocity up.
+
+User-facing documentation and speed-by-default should be first-order priorities
+for Carbon.

proposals/p0120_decision.md

@@ -1,33 +0,0 @@
-# Decision for: Add idiomatic code performance and developer-facing docs to goals
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-08-17
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-## Open questions
-
-None.
-
-## Rationale
-
-This addresses a number of rough edges and small missing pieces in the original
-proposal, providing useful clarification. This follow up is expected as part of
-the launch and iterate process we use to keep our velocity up.
-
-User-facing documentation and speed-by-default should be first-order priorities
-for Carbon.

proposals/p0142.md

@@ -25,6 +25,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Character encoding](#character-encoding-1)
     -   [Byte order marks](#byte-order-marks)
     -   [Normalization forms](#normalization-forms)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -331,3 +332,16 @@ Con:
     ends with a code point sequence that is a prefix of a decomposition of
     another code point, otherwise different normalizations of the same source
     file could tokenize differently.
+
+## Rationale
+
+We need to specify the source file encoding in order to move on to higher-level
+lexical issues, and the proposal generally gives sound rationales for the
+specific choices it makes. UTF-8 and Unicode Annex 31 are non-controversial
+choices for a new language in 2020. The proposal provides a good rationale for
+requiring NFC.
+
+We support treating homoglyphs and confusability as out of scope. We favor of
+accepting of a wide range of scripts to start, in order to be welcoming to as
+wide a community as possible, assuming that underhanded code concerns can be
+adequately addressed outside of the compiler proper.

proposals/p0142_decision.md

@@ -1,36 +0,0 @@
-# Decision for: Unicode source files
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-10-13
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Rationale
-
-We need to specify the source file encoding in order to move on to higher-level
-lexical issues, and the proposal generally gives sound rationales for the
-specific choices it makes. UTF-8 and Unicode Annex 31 are non-controversial
-choices for a new language in 2020. The proposal provides a good rationale for
-requiring NFC.
-
-We support treating homoglyphs and confusability as out of scope. We favor of
-accepting of a wide range of scripts to start, in order to be welcoming to as
-wide a community as possible, assuming that underhanded code concerns can be
-adequately addressed outside of the compiler proper.

proposals/p0143.md

@@ -28,6 +28,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Case sensitivity](#case-sensitivity)
     -   [Real number syntax](#real-number-syntax)
     -   [Digit separator syntax](#digit-separator-syntax)
+-   [Rationale](#rationale)
+    -   [Painter rationale](#painter-rationale)
+    -   [Open questions](#open-questions)
 
 <!-- tocstop -->
 
@@ -576,3 +579,43 @@ Pro:
 Con:
 
 -   Harms the readability of long literals.
+
+## Rationale
+
+The proposal provides a syntax that is sufficiently close to that used both by
+C++ and many other languages to be very familiar. However, it selects a
+reasonably minimal subset of the syntaxes. This minimal approach provides
+benefits directly in line with both the simplicity and readability goals of
+Carbon:
+
+-   Reduces unnecessary choices for programmers.
+-   Simplifies the syntax rules of the language.
+-   Improves consistency of written Carbon code.
+
+That said, it still provides sufficient variations to address important use
+cases for the goal of not leaving room for a lower level language:
+
+-   Hexadecimal and binary integer literals.
+-   Scientific notation floating point literals.
+-   Hexadecimal (scientific) floating point literals.
+
+### Painter rationale
+
+The primary aesthetic benefit of `'` to the painter is consistency with C++.
+However, its rare usage in C++ at this point reduces this advantage to a very
+small one, while there is broad convergence amongst other languages around `_`.
+The choice here has no risk of significant meaning or building up patterns of
+reading for users that might be disrupted by the change, and so it seems
+reasonable to simply converge with other languages to end up in the less
+surprising and more conventional syntax space.
+
+### Open questions
+
+Placement restrictions of digit separators:
+
+-   The core team had consensus for the proposed restricted placement rules.
+
+Use `_` or `'` as the digit separator character:
+
+-   The core team deferred this decision to the painter.
+-   The painter selected `_`.

proposals/p0143_decision.md

@@ -1,63 +0,0 @@
-# Decision for: Numeric literals
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-09-15
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Open questions
-
-Placement restrictions of digit separators:
-
--   The core team had consensus for the proposed restricted placement rules.
-
-Use `_` or `'` as the digit separator character:
-
--   The core team deferred this decision to the painter.
--   The painter selected `_`.
-
-## Rationale
-
-The proposal provides a syntax that is sufficiently close to that used both by
-C++ and many other languages to be very familiar. However, it selects a
-reasonably minimal subset of the syntaxes. This minimal approach provides
-benefits directly in line with both the simplicity and readability goals of
-Carbon:
-
--   Reduces unnecessary choices for programmers.
--   Simplifies the syntax rules of the language.
--   Improves consistency of written Carbon code.
-
-That said, it still provides sufficient variations to address important use
-cases for the goal of not leaving room for a lower level language:
-
--   Hexadecimal and binary integer literals.
--   Scientific notation floating point literals.
--   Hexadecimal (scientific) floating point literals.
-
-### Painter rationale
-
-The primary aesthetic benefit of `'` to the painter is consistency with C++.
-However, its rare usage in C++ at this point reduces this advantage to a very
-small one, while there is broad convergence amongst other languages around `_`.
-The choice here has no risk of significant meaning or building up patterns of
-reading for users that might be disrupted by the change, and so it seems
-reasonable to simply converge with other languages to end up in the less
-surprising and more conventional syntax space.

proposals/p0149.md

@@ -21,6 +21,10 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Microsoft writing style guide](#microsoft-writing-style-guide)
     -   [Word lists](#word-lists)
 -   [Alternatives considered](#alternatives-considered)
+-   [Rationale](#rationale)
+    -   [Painter rationale](#painter-rationale)
+    -   [Open questions](#open-questions)
+        -   [Which style guide?](#which-style-guide)
 
 <!-- tocstop -->
 
@@ -305,3 +309,31 @@ vs.
 Various offline resources like the Chicago Manual of Style may be helpful to
 some, but require a subscription or physical copy, and so are less useful as
 canonical resources for contributors.
+
+## Rationale
+
+The core team reached consensus that there should be a style guide, but did not
+have a strong preference between the Google style guide and the Microsoft style
+guide. One advantage of the Microsoft style guide is that it is less
+Google-centric, which could contribute somewhat to our community goal. Given the
+level of experience of the core team members with these style guides, it is not
+clear that a well-informed decision could be made. As such, the core team
+decided to leave the decision of the specific style guide up to the Painter.
+
+### Painter rationale
+
+Given the lack of a high level reason to pick one over the other, the painter
+looked at the available tooling for linting against the two options and spoke
+with people who have written substantial developer documentation against both
+style guides. There was no persuasive reason to change from the Google
+documentation style guide at this time. Specific ambiguities or problems with
+that style guide should instead be addressed, if necessary at all, with
+Carbon-specific local rule.
+
+### Open questions
+
+#### Which style guide?
+
+The core team decided to let the Painter choose the style guide to be used. The
+painter selected to continue using the Google documentation markdown style
+guide.

proposals/p0149_decision.md

@@ -1,51 +0,0 @@
-# Decision for: Change markdown style guide
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-09-22
-
-Affirming:
-
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [austern](https://github.com/austern)
--   [josh11b](https://github.com/josh11b)
--   [gribozavr](https://github.com/gribozavr)
-
-## Open questions
-
-### Which style guide?
-
-The core team decided to let the Painter choose the style guide to be used. The
-painter selected to continue using the Google documentation markdown style
-guide.
-
-## Rationale
-
-The core team reached consensus that there should be a style guide, but did not
-have a strong preference between the Google style guide and the Microsoft style
-guide. One advantage of the Microsoft style guide is that it is less
-Google-centric, which could contribute somewhat to our community goal. Given the
-level of experience of the core team members with these style guides, it is not
-clear that a well-informed decision could be made. As such, the core team
-decided to leave the decision of the specific style guide up to the Painter.
-
-### Painter rationale
-
-Given the lack of a high level reason to pick one over the other, the painter
-looked at the available tooling for linting against the two options and spoke
-with people who have written substantial developer documentation against both
-style guides. There was no persuasive reason to change from the Google
-documentation style guide at this time. Specific ambiguities or problems with
-that style guide should instead be addressed, if necessary at all, with
-Carbon-specific local rule.

proposals/p0157.md

@@ -36,6 +36,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Indexing by type](#indexing-by-type)
     -   [Pattern matching proxies](#pattern-matching-proxies)
     -   [Pattern functions](#pattern-functions)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -1057,3 +1058,32 @@ However, this approach also carries some substantial drawbacks:
 
 These issues, especially the overall complexity of this approach, leads me to
 recommend against adopting it.
+
+## Rationale
+
+This proposal gives us solid ground on which to continue developing features
+that rely on sum types and pattern matching thereof. The approach taken seems
+plausible, and while there's a good chance that we will revise it significantly
+before we finish our first pass over the complete Carbon design (for example, by
+switching to pattern matching proxies or by supporting mutation of matched
+elements), we don't think it will anchor us too much on this one particular
+direction.
+
+With regard to Carbon's goals:
+
+-   Performance: while the approach taken herein potentially has some
+    performance cost for a common operation that is likely to appear in
+    performance-critical code (requiring an indirect call and the generation of
+    continuations for user-defined pattern matching), such cost should be
+    practically removable by inlining. We'll need to take care to ensure this
+    abstraction penalty is reliably removed in common cases, but this seems
+    sufficiently feasible to be worth attempting.
+-   Evolution: software evolution is supported by allowing user-defined pattern
+    matching to specify (by way of the presence/absence of operator default)
+    whether the set of patterns is intended to be extended in the future.
+-   Ergonomics: custom pattern matching for user-defined types promotes language
+    consistency and removes boilerplate
+
+Note: At the decision meeting, it was stated that geoffromer will update the
+proposal to add a rationale to address austern's questions about the layered
+approach.

proposals/p0157_decision.md

@@ -1,56 +0,0 @@
-# Decision for: Design direction for sum types
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2021-02-02
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Open questions
-
-None
-
-## Rationale
-
-This proposal gives us solid ground on which to continue developing features
-that rely on sum types and pattern matching thereof. The approach taken seems
-plausible, and while there's a good chance that we will revise it significantly
-before we finish our first pass over the complete Carbon design (for example, by
-switching to pattern matching proxies or by supporting mutation of matched
-elements), we don't think it will anchor us too much on this one particular
-direction.
-
-With regard to Carbon's goals:
-
--   Performance: while the approach taken herein potentially has some
-    performance cost for a common operation that is likely to appear in
-    performance-critical code (requiring an indirect call and the generation of
-    continuations for user-defined pattern matching), such cost should be
-    practically removable by inlining. We'll need to take care to ensure this
-    abstraction penalty is reliably removed in common cases, but this seems
-    sufficiently feasible to be worth attempting.
--   Evolution: software evolution is supported by allowing user-defined pattern
-    matching to specify (by way of the presence/absence of operator default)
-    whether the set of patterns is intended to be extended in the future.
--   Ergonomics: custom pattern matching for user-defined types promotes language
-    consistency and removes boilerplate
-
-Note: At the decision meeting, it was stated that geoffromer will update the
-proposal to add a rationale to address austern's questions about the layered
-approach.

proposals/p0162.md

@@ -27,6 +27,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Abstract Syntax for Statements](#abstract-syntax-for-statements)
         -   [Abstract Syntax for Declarations](#abstract-syntax-for-declarations)
 -   [Alternatives considered](#alternatives-considered)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -514,3 +515,25 @@ of types results from an expression in a context that expects a type, the type
 system will convert the tuple to a tuple type. An alternative approach has been
 discussed in which tuple types have a distinct syntax, such as
 `Tuple(Int, Bool)`.
+
+## Rationale
+
+Using code to validate our specification is a really promising direction, and
+this proposal seems like a good starting point. A reference implementation
+that's simple enough to be part of the design iteration process should help us
+move faster, by quickly uncovering the places where our specifications are
+ambiguous, syntactically or semantically unsound, or don't give the behavior we
+expect. In other words, it will help us keep ourselves honest, even at the
+proposal stage, which will help us avoid wasting time and effort implementing
+designs that turn out to be unworkable.
+
+This can be considered as sort of a counterpart to
+[In-progress design overview #83](p0083.md), in that the design specifics are
+being approved in order to bootstrap the specification process. We aren't
+necessarily adopting the specific syntax and semantics expressed by this
+proposal, and those choices will need to be presented and justified from scratch
+by future proposals.
+
+This decision is deferring the implementation to code review. The specific
+tooling used to implement the syntax checker, such as Bison, is a detail which
+may be changed, now or later, without requiring a proposal for core team review.

proposals/p0162_decision.md

@@ -1,45 +0,0 @@
-# Decision for: Basic Syntax #162
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-11-10
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [noncombatant](https://github.com/noncombatant)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [tituswinters](https://github.com/tituswinters)
-
-## Rationale
-
-Using code to validate our specification is a really promising direction, and
-this proposal seems like a good starting point. A reference implementation
-that's simple enough to be part of the design iteration process should help us
-move faster, by quickly uncovering the places where our specifications are
-ambiguous, syntactically or semantically unsound, or don't give the behavior we
-expect. In other words, it will help us keep ourselves honest, even at the
-proposal stage, which will help us avoid wasting time and effort implementing
-designs that turn out to be unworkable.
-
-This can be considered as sort of a counterpart to
-[In-progress design overview #83](p0083.md), in that the design specifics are
-being approved in order to bootstrap the specification process. We aren't
-necessarily adopting the specific syntax and semantics expressed by this
-proposal, and those choices will need to be presented and justified from scratch
-by future proposals.
-
-This decision is deferring the implementation to code review. The specific
-tooling used to implement the syntax checker, such as Bison, is a detail which
-may be changed, now or later, without requiring a proposal for core team review.

proposals/p0175.md

@@ -43,6 +43,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Carbon type inheritance from non-pure interface C++ types](#carbon-type-inheritance-from-non-pure-interface-c-types)
     -   [CRTP support](#crtp-support)
     -   [Object lifetimes](#object-lifetimes)
+-   [Rationale](#rationale)
+    -   [Open questions](#open-questions)
 
 <!-- tocstop -->
 
@@ -452,3 +454,28 @@ into unsafe Carbon code, requiring developers to learn new coding patterns.
 More analysis should be done on object lifetimes and potential Carbon designs
 for it before deciding how to treat object lifetimes in the scope of
 interoperability.
+
+## Rationale
+
+The core team agrees with the mapping of the proposed interoperability goals to
+the overall Carbon goals as rationale.
+
+Embedding of C++ bridge code inside Carbon code is inspired in part by
+experience with CUDA and SYCL, where users provided feedback that these were
+preferred over alternatives such as OpenCL due to the ability to embed bridge
+code and device kernels in the same source file as host C++ code. It also
+matches the approach of bridging between C++ and C where bridge code is often
+embedded as `extern "C"` within C++ source files.
+
+The non-goals seem appropriately motivated by the non-interoperability
+priorities, without undermining the effectiveness of the interoperability as a
+whole.
+
+We agree with ensuring some level of C interoperability in order to effectively
+interoperate with both some parts of the C++ ecosystem that rely on the C ABI as
+well as all other languages which target C-based interoperability.
+
+### Open questions
+
+All open questions in the document are intended to be answered later after we
+have more experience.

proposals/p0175_decision.md

@@ -1,48 +0,0 @@
-# Decision for: C++ interoperability goals
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-11-24
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Open questions
-
-All open questions in the document are intended to be answered later after we
-have more experience.
-
-## Rationale
-
-The core team agrees with the mapping of the proposed interoperability goals to
-the overall Carbon goals as rationale.
-
-Embedding of C++ bridge code inside Carbon code is inspired in part by
-experience with CUDA and SYCL, where users provided feedback that these were
-preferred over alternatives such as OpenCL due to the ability to embed bridge
-code and device kernels in the same source file as host C++ code. It also
-matches the approach of bridging between C++ and C where bridge code is often
-embedded as `extern "C"` within C++ source files.
-
-The non-goals seem appropriately motivated by the non-interoperability
-priorities, without undermining the effectiveness of the interoperability as a
-whole.
-
-We agree with ensuring some level of C interoperability in order to effectively
-interoperate with both some parts of the C++ ecosystem that rely on the C ABI as
-well as all other languages which target C-based interoperability.

proposals/p0179.md

@@ -16,6 +16,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Background](#background)
 -   [Proposal](#proposal)
     -   [Scope](#scope)
+-   [Rationale](#rationale)
+    -   [Open questions](#open-questions)
+        -   [Should the name of the team be "toolchain team" or "implementation team"?](#should-the-name-of-the-team-be-toolchain-team-or-implementation-team)
 
 <!-- tocstop -->
 
@@ -51,3 +54,18 @@ _project_ infrastructure covered by the
 delineation between these, and if in doubt or there is disagreement, it should
 be escalated to the [core team](/docs/project/groups.md#core-team) rather than
 spending too much time defining precisely disjoint scopes.
+
+## Rationale
+
+Carbon's goals include providing a reference implementation and tooling.
+Delivering this complex software requires a dedicated team, vision, leadership,
+and a degree of autonomy.
+
+### Open questions
+
+#### Should the name of the team be "toolchain team" or "implementation team"?
+
+Some core team members expressed a preference for "implementation team", none
+expressed a preference for "toolchain team", all were fine either way. As
+gribozavr noted, and everyone at the review meeting agreed, the team should be
+free to choose its own name.

proposals/p0179_decision.md

@@ -1,38 +0,0 @@
-# Decision for: Create a toolchain team
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2020-12-08
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [noncombatant](https://github.com/noncombatant)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [tituswinters](https://github.com/tituswinters)
-
-## Open questions
-
-### Should the name of the team be "toolchain team" or "implementation team"?
-
-Some core team members expressed a preference for "implementation team", none
-expressed a preference for "toolchain team", all were fine either way. As
-gribozavr noted, and everyone at the review meeting agreed, the team should be
-free to choose its own name.
-
-## Rationale
-
-Carbon's goals include providing a reference implementation and tooling.
-Delivering this complex software requires a dedicated team, vision, leadership,
-and a degree of autonomy.

proposals/p0196.md

@@ -16,6 +16,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Background](#background)
 -   [Proposal](#proposal)
 -   [Open question: probabilistic checks in the hardened build mode](#open-question-probabilistic-checks-in-the-hardened-build-mode)
+-   [Rationale](#rationale)
+    -   [Open questions](#open-questions)
+        -   [Does the core team believe that we should put a cap on how much performance should be sacrificed for safety, putting more emphasis on probabilistic methods that would allow more attacks through?](#does-the-core-team-believe-that-we-should-put-a-cap-on-how-much-performance-should-be-sacrificed-for-safety-putting-more-emphasis-on-probabilistic-methods-that-would-allow-more-attacks-through)
 
 <!-- tocstop -->
 
@@ -63,3 +66,43 @@ The CPU and RAM cost of MarkUs is significant, even by comparison with other
 techniques, and costs will add up as more safety is added. 93% is a reasonably
 high detection rate for an performance-efficient, probabilistic technique. Would
 the core team expect to use MTE instead MarkUs in hardened builds?
+
+## Rationale
+
+Most of Carbon's goals can be addressed in a somewhat piecemeal fashion. For
+example, there's probably no need for our designs for generics and for sum types
+to coordinate how they address performance or readability. Safety, on the other
+hand, is much more cross-cutting, and so it's important for us to approach it
+consistently across the whole language. This proposal gives us a common
+vocabulary for discussing safety, establishes some well-motivated common
+principles, and provides an overall strategy based on those principles, all of
+which will be essential to achieving that consistency.
+
+This proposal gives a solid basis for thinking about safety in future proposals.
+The pragmatic choice to focus on the security aspects of safety seems
+well-aligned with Carbon's goals. In particular, a more idealistic approach to
+safety, in which every language construct has bounded behavior, would be likely
+to result in safety being prioritized over performance. By instead considering
+safety largely from the perspective of security vulnerabilities, and accepting
+that there will be cases where the pragmatic choice is hardening rather than
+static or dynamic checks, we can focus on delivering practical safety without
+being overly distracted from other goals.
+
+It is critical that Carbon use build modes to enable writing
+performance-optimized code (much like C++ today) that can still be built and
+deployed at reasonable engineering cost with strong guarantees around memory
+safety for the purposes of security. We think this proposal provides that
+foundation.
+
+Note: The decision by the core team included a request to clarify the wording on
+build modes as described in
+[chandlerc's post](https://forums.carbon-lang.dev/t/request-for-decision-language-level-safety-strategy/196/6)
+on the decision thread.
+
+### Open questions
+
+#### Does the core team believe that we should put a cap on how much performance should be sacrificed for safety, putting more emphasis on probabilistic methods that would allow more attacks through?
+
+There is no cap at this point. Where possible, static checking should be used.
+In practice, there will be some who will not use the safest option until the
+cost gets low enough.

proposals/p0196_decision.md

@@ -1,63 +0,0 @@
-# Decision for: Language-level safety strategy
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2021-02-02
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [tituswinters](https://github.com/tituswinters)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
-
-## Open questions
-
-### Does the core team believe that we should put a cap on how much performance should be sacrificed for safety, putting more emphasis on probabilistic methods that would allow more attacks through?
-
-There is no cap at this point. Where possible, static checking should be used.
-In practice, there will be some who will not use the safest option until the
-cost gets low enough.
-
-## Rationale
-
-Most of Carbon's goals can be addressed in a somewhat piecemeal fashion. For
-example, there's probably no need for our designs for generics and for sum types
-to coordinate how they address performance or readability. Safety, on the other
-hand, is much more cross-cutting, and so it's important for us to approach it
-consistently across the whole language. This proposal gives us a common
-vocabulary for discussing safety, establishes some well-motivated common
-principles, and provides an overall strategy based on those principles, all of
-which will be essential to achieving that consistency.
-
-This proposal gives a solid basis for thinking about safety in future proposals.
-The pragmatic choice to focus on the security aspects of safety seems
-well-aligned with Carbon's goals. In particular, a more idealistic approach to
-safety, in which every language construct has bounded behavior, would be likely
-to result in safety being prioritized over performance. By instead considering
-safety largely from the perspective of security vulnerabilities, and accepting
-that there will be cases where the pragmatic choice is hardening rather than
-static or dynamic checks, we can focus on delivering practical safety without
-being overly distracted from other goals.
-
-It is critical that Carbon use build modes to enable writing
-performance-optimized code (much like C++ today) that can still be built and
-deployed at reasonable engineering cost with strong guarantees around memory
-safety for the purposes of security. We think this proposal provides that
-foundation.
-
-Note: The decision by the core team included a request to clarify the wording on
-build modes as described in
-[chandlerc's post](https://forums.carbon-lang.dev/t/request-for-decision-language-level-safety-strategy/196/6)
-on the decision thread.

proposals/p0198.md

@@ -31,6 +31,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Block comments](#block-comments-2)
     -   [Documentation comments](#documentation-comments)
     -   [Code folding comments](#code-folding-comments)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -467,3 +468,17 @@ additional effort. However, we could consider introducing a specific Carbon
 syntax for region comments, in order to encourage a common representation across
 code editors. Such support is not covered by this proposal, but could be handled
 by a new form of comment.
+
+## Rationale
+
+-   Some comment syntax is necessary to support software evolution, readable and
+    understandable code, and many other goals of Carbon.
+-   A single, simple, and consistent comment style supports Carbon's goal of
+    easy to read and understand code, and fast development tools.
+-   The experiment of restricting comments to be the only non-whitespace text on
+    a line supports Carbon's goal of software evolution.
+-   The careful open lexical space left supports Carbon's goal of language
+    evolution.
+-   The use of `//` as the primary syntax marking comments supports
+    interoperability with C++-trained programmers and codebases by avoiding
+    unnecessary and unhelpful churn of comment syntax.

proposals/p0198_decision.md

@@ -1,37 +0,0 @@
-# Decision for: Comments
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2021-02-19
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Rationale
-
--   Some comment syntax is necessary to support software evolution, readable and
-    understandable code, and many other goals of Carbon.
--   A single, simple, and consistent comment style supports Carbon's goal of
-    easy to read and understand code, and fast development tools.
--   The experiment of restricting comments to be the only non-whitespace text on
-    a line supports Carbon's goal of software evolution.
--   The careful open lexical space left supports Carbon's goal of language
-    evolution.
--   The use of `//` as the primary syntax marking comments supports
-    interoperability with C++-trained programmers and codebases by avoiding
-    unnecessary and unhelpful churn of comment syntax.

proposals/p0199.md

@@ -30,6 +30,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Trailing whitespace](#trailing-whitespace)
         -   [Line separators](#line-separators)
     -   [Internal whitespace](#internal-whitespace)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -721,3 +722,34 @@ characters harm the readability of the program, and we would like to encourage
 the use of `\t` escapes instead in situations where they are available, even if
 this means that the more verbose form `\#t` needs to be used in raw string
 literals.
+
+## Rationale
+
+This proposal supports the goal of making Carbon code
+[easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write),
+by ensuring that essentially every kind of string content can be represented in
+a Carbon string literal, in a way that is natural, toolable, and easy to read:
+
+-   Multi-line strings are supported by multi-line string literals, and the
+    rules for stripping leading indentation enhance readability by allowing
+    those literals to avoid visually disrupting the indentation structure of the
+    code.
+-   Strings that make extensive use of `\` and `"` are supported by raw string
+    literals.
+-   Treating raw versus ordinary and single-line versus multi-line as orthogonal
+    allows Carbon to support all 4 combinations while keeping the language
+    simple.
+-   The handling of `\#` within raw string literals makes it possible to use
+    escape sequences within raw string literals when necessary, for example to
+    embed arbitrary byte values or Unicode data. This ensures that the
+    programmer is never prevented from using a raw string literal, or forced to
+    assemble a single logical string by concatenating ordinary and raw literals
+    (with the negligible and fixable exception of strings like
+    `"\\################"`, as noted in the proposal).
+-   "File type indicators" make it easier for tooling to understand the contents
+    of literals, in order to provide features such as syntax highlighting,
+    automated formatting, and potentially even certain kinds of static analysis,
+    for code that's embedded in string literals.
+-   Support for non-Unicode strings by way of `\x` ensures "support for software
+    outside the primary use case".
+-   Avoids unnecessary invention, following Rust and particularly Swift.

proposals/p0199_decision.md

@@ -1,54 +0,0 @@
-# Decision for: String literals
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2021-02-23
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [noncombatant](https://github.com/noncombatant)
--   [tituswinters](https://github.com/tituswinters)
-
-## Rationale
-
-This proposal supports the goal of making Carbon code
-[easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write),
-by ensuring that essentially every kind of string content can be represented in
-a Carbon string literal, in a way that is natural, toolable, and easy to read:
-
--   Multi-line strings are supported by multi-line string literals, and the
-    rules for stripping leading indentation enhance readability by allowing
-    those literals to avoid visually disrupting the indentation structure of the
-    code.
--   Strings that make extensive use of `\` and `"` are supported by raw string
-    literals.
--   Treating raw versus ordinary and single-line versus multi-line as orthogonal
-    allows Carbon to support all 4 combinations while keeping the language
-    simple.
--   The handling of `\#` within raw string literals makes it possible to use
-    escape sequences within raw string literals when necessary, for example to
-    embed arbitrary byte values or Unicode data. This ensures that the
-    programmer is never prevented from using a raw string literal, or forced to
-    assemble a single logical string by concatenating ordinary and raw literals
-    (with the negligible and fixable exception of strings like
-    `"\\################"`, as noted in the proposal).
--   "File type indicators" make it easier for tooling to understand the contents
-    of literals, in order to provide features such as syntax highlighting,
-    automated formatting, and potentially even certain kinds of static analysis,
-    for code that's embedded in string literals.
--   Support for non-Unicode strings by way of `\x` ensures "support for software
-    outside the primary use case".
--   Avoids unnecessary invention, following Rust and particularly Swift.

proposals/p0253.md

@@ -187,3 +187,28 @@ encompass the broader ecosystem of the language:
 -   Teaching and training material.
 -   Package management.
 -   Etc.
+
+## Rationale
+
+By its nature, we're not sure a planning document like this can directly advance
+Carbon's goals, but we think this roadmap does a good job of keeping us focused
+on the work that will help us generate concrete evidence as to whether Carbon is
+likely to successfully achieve those goals (and help us figure out how to
+course-correct if it's not). Increasing the representation of non-Googlers on
+the core team is an important indicator (as well as enabler) of building an
+"open and inclusive community", not to mention of having a broad enough user
+base to succeed, and the example ports, demo implementation, and executable
+semantics will help us concretely evaluate how well Carbon is meeting all of its
+language goals.
+
+In addition, as the proposal argues, concrete evidence that Carbon can succeed
+will indirectly help Carbon make faster progress, by motivating further
+investment in the project. Some aspects of the roadmap will also help accelerate
+Carbon's development in more direct ways. In particular, the executable
+semantics implementation should enable Carbon contributors to rapidly prototype
+potential new features, which will help us identify and solve more problems at
+an earlier stage, and have higher confidence in the proposals we adopt.
+
+While rapid progress is not an explicit goal of the Carbon project, Carbon can't
+meet any of its other goals until it exists in a usable form, and the longer it
+takes to reach that point, the less likely it is to reach it at all.

proposals/p0253_decision.md

@@ -1,48 +0,0 @@
-# Decision for: Proposed Carbon roadmap for 2021
-
-<!--
-Part of the Carbon Language project, under the Apache License v2.0 with LLVM
-Exceptions. See /LICENSE for license information.
-SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
--->
-
-Proposal accepted on 2021-03-09
-
-Affirming:
-
--   [austern](https://github.com/austern)
--   [chandlerc](https://github.com/chandlerc)
--   [geoffromer](https://github.com/geoffromer)
--   [gribozavr](https://github.com/gribozavr)
--   [josh11b](https://github.com/josh11b)
--   [noncombatant](https://github.com/noncombatant)
--   [zygoloid](https://github.com/zygoloid)
-
-Abstaining:
-
--   [tituswinters](https://github.com/tituswinters)
-
-## Rationale
-
-By its nature, we're not sure a planning document like this can directly advance
-Carbon's goals, but we think this roadmap does a good job of keeping us focused
-on the work that will help us generate concrete evidence as to whether Carbon is
-likely to successfully achieve those goals (and help us figure out how to
-course-correct if it's not). Increasing the representation of non-Googlers on
-the core team is an important indicator (as well as enabler) of building an
-"open and inclusive community", not to mention of having a broad enough user
-base to succeed, and the example ports, demo implementation, and executable
-semantics will help us concretely evaluate how well Carbon is meeting all of its
-language goals.
-
-In addition, as the proposal argues, concrete evidence that Carbon can succeed
-will indirectly help Carbon make faster progress, by motivating further
-investment in the project. Some aspects of the roadmap will also help accelerate
-Carbon's development in more direct ways. In particular, the executable
-semantics implementation should enable Carbon contributors to rapidly prototype
-potential new features, which will help us identify and solve more problems at
-an earlier stage, and have higher confidence in the proposals we adopt.
-
-While rapid progress is not an explicit goal of the Carbon project, Carbon can't
-meet any of its other goals until it exists in a usable form, and the longer it
-takes to reach that point, the less likely it is to reach it at all.

proposals/p0285.md

@@ -25,6 +25,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Alternatives considered](#alternatives-considered)
     -   [No parentheses](#no-parentheses)
     -   [Require braces](#require-braces)
+-   [Rationale](#rationale)
 
 <!-- tocstop -->
 
@@ -239,3 +240,14 @@ Disadvantages:
 
 The benefits of this are debatable, and it should be examined by an advocate in
 a focused proposal. For now, we should match C++'s decision.
+
+## Rationale
+
+This proposal focuses on an uncontroversial piece that we are going to carry
+from C++, as a baseline for future Carbon evolution. It serves our migration
+goals (especially "Familiarity for experienced C++ developers with a gentle
+learning curve") by avoiding unnecessary deviation from C++, and instead
+focusing on subsetting the C++ feature. While we expect this feature to evolve
+somewhat, the changes we're likely to want can easily be applied incrementally,
+and this is a fine starting point that anchors us on favoring syntax familiar to
+C++ developers.