Improve description of what belongs in a proposal document versus in the design

docs/project/design_style_guide.md

@@ -0,0 +1,90 @@
+# Language design 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
+-->
+
+<!-- toc -->
+
+## Table of contents
+
+-   [Background](#background)
+-   [General](#general)
+-   [Formatting](#formatting)
+-   [Document structure](#document-structure)
+    -   [Overview and detailed design](#overview-and-detailed-design)
+    -   [Alternatives considered](#alternatives-considered)
+    -   [References](#references)
+
+<!-- tocstop -->
+
+## Background
+
+The [language design](/docs/design) documentation in the Carbon project should
+use a consistent style and tone, and should read as if it were written by a
+single author. This document describes structural, stylistic, and formatting
+conventions for the language design, where they have been established.
+
+## General
+
+The language design documentation follows the
+[style conventions](https://carbon-lang.dev/CONTRIBUTING.html#google-docs-and-markdown)
+for Carbon documentation.
+
+## Formatting
+
+-   Links to issues and proposals should use the text `#nnnn`, where `nnnn` is
+    the issue number, and should link to the issue or pull request on GitHub,
+    not to the P-numbered proposal document in /docs/proposals.
+
+## Document structure
+
+Each document within the language design should be divided into the following
+sections, with suitable level-two (`##`) headings:
+
+-   **Table of contents** (auto-generated)
+-   **TODO** (optional)
+-   **Overview**
+-   Zero or more detailed design sections
+-   **Alternatives considered**
+-   **References**
+
+### Overview and detailed design
+
+The overview should describe the high-level concepts of this area of the design,
+following BLUF principles. Where the overview does not fully cover the detailed
+design, additional sections can be added as needed to more completely describe
+the design.
+
+The aim of these sections is to describe the design as it is, how this portion
+of the design fits into the overall design of Carbon, and how this part of the
+design can be used to solve programming problems. Rationale for this choice of
+design as compared to others should not be included.
+
+### Alternatives considered
+
+This section should provide bullet points briefly describing alternative designs
+that were considered, along with references to the proposals in which those
+designs were discussed. For example:
+
+-   Paint widgets from bottom to top
+    ([#999999](https://github.com/carbon-language/carbon-lang/pull/999999)).
+
+### References
+
+This section should provide bullet points linking to the following:
+
+-   External documents providing background on the topic or additional useful
+    information.
+-   Proposals that contributed to the design described in this document.
+
+For example:
+
+-   [Wikipedia example page](https://en.wikipedia.org/wiki/Wikipedia:Example)
+-   Proposal: widget painting
+    ([#999999](https://github.com/carbon-language/carbon-lang/pull/999999)).
+
+Links to related parts of the design should be included inline, where relevant,
+not in the references section.

docs/project/evolution.md

@@ -20,6 +20,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Carbon leads](#carbon-leads)
     -   [When to write a proposal](#when-to-write-a-proposal)
     -   [Proposal PRs](#proposal-prs)
+        -   [What goes in the proposal document](#what-goes-in-the-proposal-document)
         -   [Open questions](#open-questions)
     -   [Review and RFC on proposal PRs](#review-and-rfc-on-proposal-prs)
     -   [Blocking issues](#blocking-issues)
@@ -254,20 +255,44 @@ a pull request instead go through the full evolution process.
 A proposal PR should use the `proposal` label, have a descriptive title, and
 easily understood initial summary comment. Authors and leads are encouraged to
 edit both as necessary to ensure they give the best high-level understanding of
-the proposal possible. The proposals should then use the
-[template file](/proposals/template.md) to describe itself fully.
+the proposal possible.
+
+A proposal PR will include a "P-numbered" _proposal document_,
+`proposals/pNNNN.md`, where `NNNN` is the pull request number. This file should
+be based on the [proposal template file](/proposals/template.md).
 
 When writing a proposal, try to keep it brief and focused to maximize the
 community's engagement in it. Beyond the above structure, try to use
 [Inverted Pyramid](<https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)>)
 or [BLUF](<https://en.wikipedia.org/wiki/BLUF_(communication)>) writing style to
 help readers rapidly skim the material.
 
-Proposal PRs will often lead to related changes to the rest of the Carbon
-project. These changes may be added to the proposal PR itself, they may be done
-in other PRs that are referenced for context, or they may be stand-alone changes
-that are implemented through a series of future PRs to the rest of the project.
-All of these options are fine.
+#### What goes in the proposal document
+
+A proposal PR need not contain any changes beyond the proposal document. In this
+case, the changes to the rest of the Carbon project resulting from the proposal
+should be implemented through a series of future PRs to the rest of the project,
+and the proposal document should describe what is being proposed in enough
+detail to validate that those future PRs properly implement the proposed
+direction.
+
+As an alternative, the proposal PR can contain related changes to the Carbon
+project, such as updates to the design documentation. In this case, those
+changes form part of the proposal, and need not be additionally described in the
+proposal document beyond a mention in the "Proposal" section that such changes
+exist. For example:
+
+> \#\# Proposal
+>
+> See the proposed changes to the design documents.
+
+Readers of proposals are expected to consult the PR or the git commit that
+merged the PR in order to understand the proposed changes.
+
+Regardless of whether the proposed change is described in the proposal document
+or in the changes to the rest of the project, the proposal document should
+contain any relevant analysis of alternatives and a rationale for the proposal
+based on Carbon's goals.
 
 #### Open questions