Set up Prettier for formatting, and run files through it. (#7)

CONTRIBUTING.md replaces the mention of Google style guide (which isn't automated) with Prettier (which should do most of the hauling). The rest is the formatter.

.prettierrc

@@ -0,0 +1 @@
+proseWrap: "always"

CODE_OF_CONDUCT.md

@@ -11,13 +11,13 @@ commitment to psychological safety, and we want to ensure that doesn’t change
 we grow and evolve. To that end, we have a few ground rules that we ask all
 community members to adhere to:
 
-*   be welcoming,
-*   be friendly and patient,
-*   be considerate,
-*   be respectful,
-*   be careful in the words that you choose and be kind to others,
-*   when we disagree, try to understand why, and
-*   recognize when progress has stopped, and take a step back.
+- be welcoming,
+- be friendly and patient,
+- be considerate,
+- be respectful,
+- be careful in the words that you choose and be kind to others,
+- when we disagree, try to understand why, and
+- recognize when progress has stopped, and take a step back.
 
 This list isn't exhaustive. Rather, take it in the spirit in which it’s
 intended—a guide to make it easier to communicate and participate in the
@@ -41,68 +41,68 @@ violating the code of conduct, please report it to the
 More detailed guidance on how to participate effectively in our community
 spaces:
 
-*   **Be welcoming.** We strive to be a community that welcomes and supports
-    people of all backgrounds and identities. This includes, but is not limited
-    to, members of any race, ethnicity, culture, national origin, color,
-    immigration status, social and economic class, educational level, sex,
-    sexual orientation, gender identity and expression, physical appearance,
-    age, size, family status, relationship status, political belief, religion or
-    lack thereof, and mental and physical ability.
-
-*   **Be friendly and patient.** We want to encourage people to participate in
-    our community by keeping its atmosphere friendly and positive. This is
-    especially important because many of our communication tools on the Internet
-    are low-fidelity and make it difficult to understand each other. Be patient,
-    assume good intent, and stay supportive so that we can learn how to
-    collaborate effectively as a group.
-
-*   **Be considerate.** Your work will be used by other people, and you in turn
-    will depend on the work of others. Any decision you make will affect users
-    and colleagues, and you should take those consequences into account.
-    Remember that we’re a world-wide community, so you might not be
-    communicating in someone else’s primary language.
-
-*   **Be respectful.** Not all of us will agree all the time, but disagreement
-    is no excuse for poor behavior and poor manners. We might all experience
-    some frustration now and then, but we cannot allow that frustration to turn
-    into a personal attack. It’s important to remember that a community where
-    people feel uncomfortable or threatened is not a productive one. Members of
-    our community should be respectful when dealing with other members as well
-    as with people outside the Carbon community.
-
-*   **Be careful in the words that you choose and be kind to others.** Do not
-    insult or put down other participants. Harassment and other exclusionary
-    behaviors aren’t acceptable. This includes, but is not limited to:
-
-    *   Violent threats or language directed against another person.
-    *   Discriminatory jokes and language.
-    *   Posting sexually explicit or violent material.
-    *   Posting (or threatening to post) other people’s personally identifying
-        information ("doxing") without their explicit permission.
-    *   Personal insults, especially those using racist or sexist terms.
-    *   Unwelcome sexual attention.
-    *   Advocating for, or encouraging, any of the above behavior.
-    *   In general, if someone asks you to stop, then stop. Persisting after
-        being asked to stop is considered harassment.
-
-*   **When we disagree, try to understand why.** Disagreements, both social and
-    technical, happen all the time, and Carbon is no exception. It is important
-    that we resolve disagreements and differing views constructively. Remember
-    that we’re different. The strength of the project comes from its varied
-    community: people from a wide range of backgrounds. Different people have
-    different perspectives on issues. Being unable to understand why someone
-    holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is
-    human to err and blaming each other doesn’t get us anywhere. Instead, focus
-    on helping to resolve issues and learning from mistakes.
-
-*   **Recognize when progress has stopped, and take a step back.** Regardless of
-    whether you're trying to resolve a disagreement or anything else, think
-    about whether you're making progress. Sometimes messaging doesn't give time
-    to think about a situation fully, and repeating positions can make people
-    defensive. Step back for a few minutes or hours to think through the issue
-    before responding again. Consider pulling in another community member to
-    give a fresh perspective. Maybe meet over VC instead. Switching approaches
-    can help resume progress.
+- **Be welcoming.** We strive to be a community that welcomes and supports
+  people of all backgrounds and identities. This includes, but is not limited
+  to, members of any race, ethnicity, culture, national origin, color,
+  immigration status, social and economic class, educational level, sex, sexual
+  orientation, gender identity and expression, physical appearance, age, size,
+  family status, relationship status, political belief, religion or lack
+  thereof, and mental and physical ability.
+
+- **Be friendly and patient.** We want to encourage people to participate in our
+  community by keeping its atmosphere friendly and positive. This is especially
+  important because many of our communication tools on the Internet are
+  low-fidelity and make it difficult to understand each other. Be patient,
+  assume good intent, and stay supportive so that we can learn how to
+  collaborate effectively as a group.
+
+- **Be considerate.** Your work will be used by other people, and you in turn
+  will depend on the work of others. Any decision you make will affect users and
+  colleagues, and you should take those consequences into account. Remember that
+  we’re a world-wide community, so you might not be communicating in someone
+  else’s primary language.
+
+- **Be respectful.** Not all of us will agree all the time, but disagreement is
+  no excuse for poor behavior and poor manners. We might all experience some
+  frustration now and then, but we cannot allow that frustration to turn into a
+  personal attack. It’s important to remember that a community where people feel
+  uncomfortable or threatened is not a productive one. Members of our community
+  should be respectful when dealing with other members as well as with people
+  outside the Carbon community.
+
+- **Be careful in the words that you choose and be kind to others.** Do not
+  insult or put down other participants. Harassment and other exclusionary
+  behaviors aren’t acceptable. This includes, but is not limited to:
+
+  - Violent threats or language directed against another person.
+  - Discriminatory jokes and language.
+  - Posting sexually explicit or violent material.
+  - Posting (or threatening to post) other people’s personally identifying
+    information ("doxing") without their explicit permission.
+  - Personal insults, especially those using racist or sexist terms.
+  - Unwelcome sexual attention.
+  - Advocating for, or encouraging, any of the above behavior.
+  - In general, if someone asks you to stop, then stop. Persisting after being
+    asked to stop is considered harassment.
+
+- **When we disagree, try to understand why.** Disagreements, both social and
+  technical, happen all the time, and Carbon is no exception. It is important
+  that we resolve disagreements and differing views constructively. Remember
+  that we’re different. The strength of the project comes from its varied
+  community: people from a wide range of backgrounds. Different people have
+  different perspectives on issues. Being unable to understand why someone holds
+  a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to
+  err and blaming each other doesn’t get us anywhere. Instead, focus on helping
+  to resolve issues and learning from mistakes.
+
+- **Recognize when progress has stopped, and take a step back.** Regardless of
+  whether you're trying to resolve a disagreement or anything else, think about
+  whether you're making progress. Sometimes messaging doesn't give time to think
+  about a situation fully, and repeating positions can make people defensive.
+  Step back for a few minutes or hours to think through the issue before
+  responding again. Consider pulling in another community member to give a fresh
+  perspective. Maybe meet over VC instead. Switching approaches can help resume
+  progress.
 
 If you have questions, please feel free to ask on our Discourse Forum, Discord
 Chat, or contact any member of the conduct team directly.
@@ -143,15 +143,15 @@ Reports can be as formal or informal as needed for the situation at hand. If
 possible, please include as much information as you can. If you feel
 comfortable, please consider including:
 
-*   Your contact info (so we can get in touch with you if we need to follow up).
-*   Names (real, nicknames, or pseudonyms) of any individuals involved. If there
-    were other witnesses besides you, please try to include them as well.
-*   When and where the incident occurred. Please be as specific as possible.
-*   Your account of what occurred, including any private chat logs or email.
-*   Links for any public records, e.g., Discourse Forum links.
-*   Any extra context for the incident.
-*   If you believe this incident is ongoing.
-*   Any other information you believe we should have.
+- Your contact info (so we can get in touch with you if we need to follow up).
+- Names (real, nicknames, or pseudonyms) of any individuals involved. If there
+  were other witnesses besides you, please try to include them as well.
+- When and where the incident occurred. Please be as specific as possible.
+- Your account of what occurred, including any private chat logs or email.
+- Links for any public records, e.g., Discourse Forum links.
+- Any extra context for the incident.
+- If you believe this incident is ongoing.
+- Any other information you believe we should have.
 
 ## What happens after contacting the conduct team?
 
@@ -161,10 +161,10 @@ business day (and we will aim to respond much quicker than that).
 The conduct team will review the incident as soon as possible and try to
 determine:
 
-*   What happened and who was involved.
-*   Whether this event constitutes a code of conduct violation.
-*   Whether this is an ongoing situation, or if there is a threat to anyone’s
-    physical safety.
+- What happened and who was involved.
+- Whether this event constitutes a code of conduct violation.
+- Whether this is an ongoing situation, or if there is a threat to anyone’s
+  physical safety.
 
 If this is determined to be an ongoing incident or a threat to physical safety,
 the conduct team's immediate priority will be to protect everyone involved. This
@@ -178,10 +178,10 @@ perspectives.
 Once the conduct team has a complete account of the events they will make a
 decision as to how to respond. Responses may include:
 
-*   Nothing, if no violation occurred or it has already been appropriately
-    resolved.
-*   One or more [enforcement actions](#enforcement-actions).
-*   Involvement of relevant law enforcement if appropriate.
+- Nothing, if no violation occurred or it has already been appropriately
+  resolved.
+- One or more [enforcement actions](#enforcement-actions).
+- Involvement of relevant law enforcement if appropriate.
 
 If the situation is not resolved within one week, we’ll respond to the original
 reporter with an update and explanation.
@@ -225,30 +225,29 @@ violation of this Code of Conduct using these guidelines based on the behavior
 involved:
 
 1.  **Correction**
-    *   **Behavior:** Use of inappropriate language or other minor violations
-        the code of conduct.
-    *   **Action:** A private, written message providing clarity around the
-        nature of the violation and an explanation of why the behavior was
-        inappropriate. A public apology may be requested.
+    - **Behavior:** Use of inappropriate language or other minor violations the
+      code of conduct.
+    - **Action:** A private, written message providing clarity around the nature
+      of the violation and an explanation of why the behavior was inappropriate.
+      A public apology may be requested.
 1.  **Warning**
-    *   **Behavior:** A code of conduct violation through a single moderate
-        incident, or a series of minor violations.
-    *   **Action:** In addition to the correction action, a temporary
-        restriction barring interaction with the people involved for a specified
-        period of time, including unsolicited interaction with the conduct team.
-        Violating these terms may lead to a ban.
+    - **Behavior:** A code of conduct violation through a single moderate
+      incident, or a series of minor violations.
+    - **Action:** In addition to the correction action, a temporary restriction
+      barring interaction with the people involved for a specified period of
+      time, including unsolicited interaction with the conduct team. Violating
+      these terms may lead to a ban.
 1.  **Temporary ban**
-    *   **Behavior:** A serious violation of the code of conduct, including
-        sustained inappropriate behavior.
-    *   **Action:** In addition to the warning action, a temporary ban from use
-        of Carbon's community spaces for a specified period of time. External
-        channels (e.g., social media) should not be used to bypass these
-        restrictions during the temporary ban. Violating these terms may lead to
-        a permanent ban.
+    - **Behavior:** A serious violation of the code of conduct, including
+      sustained inappropriate behavior.
+    - **Action:** In addition to the warning action, a temporary ban from use of
+      Carbon's community spaces for a specified period of time. External
+      channels (e.g., social media) should not be used to bypass these
+      restrictions during the temporary ban. Violating these terms may lead to a
+      permanent ban.
 1.  **Permanent ban**
-    *   **Behavior:** Demonstrating a pattern of violation of the code of
-        conduct.
-    *   **Action:** A permanent ban from use of Carbon's community spaces.
+    - **Behavior:** Demonstrating a pattern of violation of the code of conduct.
+    - **Action:** A permanent ban from use of Carbon's community spaces.
 
 # Acknowledgements
 

CONTRIBUTING.md

@@ -12,11 +12,11 @@ free to ask on our Discourse Forums or Discord Chat.
 
 Everyone contributing to Carbon is expected to:
 
-*   Read and follow the [Code of Conduct](CODE_OF_CONDUCT.md). We expect
-    everyone in our community to be welcoming, helpful, and respectful.
-*   Ensure you have signed the
-    [Contributor License Agreement (CLA)](https://cla.developers.google.com/).
-    We need this to cover some legal bases.
+- Read and follow the [Code of Conduct](CODE_OF_CONDUCT.md). We expect everyone
+  in our community to be welcoming, helpful, and respectful.
+- Ensure you have signed the
+  [Contributor License Agreement (CLA)](https://cla.developers.google.com/). We
+  need this to cover some legal bases.
 
 We also encourage anyone interested in contributing to check out all the
 information here in our contributing guide, especially the
@@ -71,13 +71,13 @@ can accept them, we need you to cover some legal bases.
 
 Please fill out either the individual or corporate CLA.
 
-*   If you are an individual contributing to spec discussions or writing
-    original source code and you're sure you own the intellectual property, then
-    you'll need to sign an
-    [individual CLA](https://code.google.com/legal/individual-cla-v1.0.html).
-*   If you work for a company that wants to allow you to contribute your work,
-    then you'll need to sign a
-    [corporate CLA](https://code.google.com/legal/corporate-cla-v1.0.html).
+- If you are an individual contributing to spec discussions or writing original
+  source code and you're sure you own the intellectual property, then you'll
+  need to sign an
+  [individual CLA](https://code.google.com/legal/individual-cla-v1.0.html).
+- If you work for a company that wants to allow you to contribute your work,
+  then you'll need to sign a
+  [corporate CLA](https://code.google.com/legal/corporate-cla-v1.0.html).
 
 Follow either of the two links above to access the appropriate CLA and
 instructions for how to sign and return it. Once we receive it, we'll be able to
@@ -99,12 +99,12 @@ take ownership of providing a CLA.
 We use a few systems for collaboration which contributors should be aware of.
 Membership is currently invite-only.
 
-*   [GitHub](https://github.com/orgs/carbon-language): We use the
-    "carbon-language" organization for our repositories.
+- [GitHub](https://github.com/orgs/carbon-language): We use the
+  "carbon-language" organization for our repositories.
 
-*   [Google Drive](https://drive.google.com/corp/drive/folders/0ALTu5Y6kc39XUk9PVA):
-    We use this shared drive for all of our Google Docs, particularly proposal
-    drafts.
+- [Google Drive](https://drive.google.com/corp/drive/folders/0ALTu5Y6kc39XUk9PVA):
+  We use this shared drive for all of our Google Docs, particularly proposal
+  drafts.
 
 ## Contribution guidelines and standards
 
@@ -113,46 +113,44 @@ follow the Carbon documentation and coding styles.
 
 ### Guidelines and philosophy for contributions
 
-*   For **both** documentation and code:
-
-    *   When the Carbon team accepts new documentation or features, to Carbon,
-        by default they take on the maintenance burden. This means they'll weigh
-        the benefit of each contribution must be weighed against the cost of
-        maintaining it.
-    *   The appropriate [style](#style) is applied.
-    *   The [license](#license) is present in all contributions.
-
-*   For documentation:
-
-    *   All documentation is written for clarity and readability. Beyond fixing
-        spelling and grammar, this also means content is worded to be accessible
-        to a broad audience.
-    *   Substantive changes to Carbon follow the
-        [evolution process](docs/project/evolution.md). Pull requests are only
-        sent after the documentation changes have been accepted by the reviewing
-        team.
-    *   Typos or other minor fixes that don't change the meaning of a document
-        do not need formal review, and are often handled directly as a pull
-        request.
-
-*   For code:
-
-    *   New features should have a documented design that has been approved
-        through the [evolution process](docs/project/evolution.md). This
-        includes modifications to pre-existing designs.
-    *   Bug fixes and mechanical improvements don't need this.
-    *   All new features include unit tests, as they help to (a) document and
-        validate concrete usage of the feature and its edge cases, and (b) guard
-        against future breaking changes to lower the maintenance cost.
-    *   Bug fixes also generally include unit tests, because the presence of
-        bugs usually indicates insufficient test coverage.
-    *   Unit tests must pass with the changes.
-    *   If some tests fail for unrelated reasons, we wait until they're fixed
-        (it helps to contribute a fix!).
-    *   Code changes are made with API compatibility and evolvability in mind.
-        Reviewers will comment on any API compatibility issues.
-    *   Keep in mind that code contribution guidelines are incomplete while we
-        start work on Carbon, and may change later.
+- For **both** documentation and code:
+
+  - When the Carbon team accepts new documentation or features, to Carbon, by
+    default they take on the maintenance burden. This means they'll weigh the
+    benefit of each contribution must be weighed against the cost of maintaining
+    it.
+  - The appropriate [style](#style) is applied.
+  - The [license](#license) is present in all contributions.
+
+- For documentation:
+
+  - All documentation is written for clarity and readability. Beyond fixing
+    spelling and grammar, this also means content is worded to be accessible to
+    a broad audience.
+  - Substantive changes to Carbon follow the
+    [evolution process](docs/project/evolution.md). Pull requests are only sent
+    after the documentation changes have been accepted by the reviewing team.
+  - Typos or other minor fixes that don't change the meaning of a document do
+    not need formal review, and are often handled directly as a pull request.
+
+- For code:
+
+  - New features should have a documented design that has been approved through
+    the [evolution process](docs/project/evolution.md). This includes
+    modifications to pre-existing designs.
+  - Bug fixes and mechanical improvements don't need this.
+  - All new features include unit tests, as they help to (a) document and
+    validate concrete usage of the feature and its edge cases, and (b) guard
+    against future breaking changes to lower the maintenance cost.
+  - Bug fixes also generally include unit tests, because the presence of bugs
+    usually indicates insufficient test coverage.
+  - Unit tests must pass with the changes.
+  - If some tests fail for unrelated reasons, we wait until they're fixed (it
+    helps to contribute a fix!).
+  - Code changes are made with API compatibility and evolvability in mind.
+    Reviewers will comment on any API compatibility issues.
+  - Keep in mind that code contribution guidelines are incomplete while we start
+    work on Carbon, and may change later.
 
 # Style
 
@@ -161,13 +159,13 @@ follow the Carbon documentation and coding styles.
 Changes to Carbon documentation follow the
 [Google developer documentation style guide](https://developers.google.com/style).
 
-Markdown files additionally follow the
-[Google Markdown style guide](https://github.com/google/styleguide/blob/gh-pages/docguide/style.md).
+Markdown files should additionally use [Prettier](https://prettier.io/) for
+formatting.
 
 Other style points to be aware of are:
 
-*   Always say "Discourse Forum" and "Discord Chat" to avoid confusion between
-    systems.
+- Always say "Discourse Forum" and "Discord Chat" to avoid confusion between
+  systems.
 
 ## Other files
 

README.md

@@ -57,9 +57,9 @@ migration of large existing codebases. They are specifically designed to not
 require complete rewrites, new programming models, or building an entire new
 stack/ecosystem. However, there is no comparable option for C++ today:
 
-*   JavaScript → TypeScript
-*   Java → Kotlin
-*   C++ → **???**
+- JavaScript → TypeScript
+- Java → Kotlin
+- C++ → **???**
 
 Carbon explores what it would look like to fill this gap and align it with the
 above priorities.
@@ -75,12 +75,12 @@ It is important to understand that **this is a science experiment**, not a
 production effort. There are several initial questions that we want to explore
 and answer with this experiment:
 
-*   Can we deliver a design and implementation that is familiar and compelling
-    to C++ programmers and supports our goals?
-*   How seamless and effective can we make interoperability?
-*   How easy and scalable can we make migration?
-*   Will a significant segment of the ecosystem and industry adopt Carbon given
-    these tradeoffs?
+- Can we deliver a design and implementation that is familiar and compelling to
+  C++ programmers and supports our goals?
+- How seamless and effective can we make interoperability?
+- How easy and scalable can we make migration?
+- Will a significant segment of the ecosystem and industry adopt Carbon given
+  these tradeoffs?
 
 We are committed to learning the answers to these questions, but that may well
 not result in a production language. There is a very real chance that this
@@ -100,38 +100,37 @@ We hope that eventually Carbon will provide **significant advantages compared to
 today's C++**. Areas where we think we can most dramatically improve C++ for
 both software systems and developers are:
 
-*   A cohesive and principled language design, even when supporting advanced
-    features.
-*   Making common coding patterns safe by default whenever practical, with
-    affordable security mitigations available for any unsafety.
-    *   We will provide static checks for as many safety issues as we can by
-        default.
-    *   We will provide a spectrum of build modes with different trade-offs
-        between dynamic safety and performance. For example:
-        *   The default build mode will include as many dynamic safety checks as
-            we can while keeping the software's performance reasonable for
-            normal development, testing, and debugging.
-        *   Release builds will favor performance, with opt-in dynamic safety
-            checks and security mitigations for applications with higher
-            security requirements.
-    *   Over time, we also expect to both track and drive research into
-        increasing the degree of safety available without compromising our other
-        goals.
-*   Keeping our core language implementation simple, fast, and easily extended
-    in ways that will make all of our language tools better.
-*   Providing an effective, open, and inclusive language evolution process
-    aligned with our goals and priorities.
+- A cohesive and principled language design, even when supporting advanced
+  features.
+- Making common coding patterns safe by default whenever practical, with
+  affordable security mitigations available for any unsafety.
+  - We will provide static checks for as many safety issues as we can by
+    default.
+  - We will provide a spectrum of build modes with different trade-offs between
+    dynamic safety and performance. For example:
+    - The default build mode will include as many dynamic safety checks as we
+      can while keeping the software's performance reasonable for normal
+      development, testing, and debugging.
+    - Release builds will favor performance, with opt-in dynamic safety checks
+      and security mitigations for applications with higher security
+      requirements.
+  - Over time, we also expect to both track and drive research into increasing
+    the degree of safety available without compromising our other goals.
+- Keeping our core language implementation simple, fast, and easily extended in
+  ways that will make all of our language tools better.
+- Providing an effective, open, and inclusive language evolution process aligned
+  with our goals and priorities.
 
 Carbon will also aim to allow a single layer of a legacy C++ library stack to be
 migrated to Carbon, without migrating the code above or below. This will make it
 easier for developers to start using Carbon. Key features underpin Carbon's
 compatibility and interoperability with C++:
 
-*   The memory, execution, and threading model will be compatible with C++.
-*   Access to existing C++ types, interfaces, and even templates will be
-    provided as part of the core language.
-*   Carbon will be able to export types, interfaces, and templates for
-    consumption by C++.
+- The memory, execution, and threading model will be compatible with C++.
+- Access to existing C++ types, interfaces, and even templates will be provided
+  as part of the core language.
+- Carbon will be able to export types, interfaces, and templates for consumption
+  by C++.
 
 **However, Carbon's approach still requires a nearly complete re-engineering of
 the language as well as large-scale migration for users.** This is extremely
@@ -142,6 +141,6 @@ very high.
 
 Carbon's main repositories are:
 
-*   **carbon-lang** - Carbon language specification and documentation.
-*   **carbon-toolchain** - Carbon language toolchain and reference implementation.
-*   **carbon-proposals** - An archive of reviewed Carbon language proposals.
+- **carbon-lang** - Carbon language specification and documentation.
+- **carbon-toolchain** - Carbon language toolchain and reference implementation.
+- **carbon-proposals** - An archive of reviewed Carbon language proposals.

docs/project/commenting_guidelines.md

@@ -13,47 +13,45 @@ always try to keep feedback, even when critical, constructive and supportive.
 
 ## Guidelines
 
-*   **Comments should be specific about the issue.** They should include a
-    suggested action, and the expected result from that action. The more
-    specific a comment is, the easier it will be for the proposal author to
-    evaluate.
-
-    *   Objections to specific phrasing should suggest alternative phrasing.
-
-*   **Use Discourse Forums for long comments.** If a Google Doc comment would be
-    over two paragraphs, take it to the Discourse Forum topic. Doc comments are
-    good for quick, short feedback; detailed feedback is better shared on
-    Discourse Forums.
-
-    *   Use the forum topic created by the author, rather than creating a new
-        topic. It needs to be easy for authors and other reviewers to find
-        comments.
-    *   If your comment represents a significant change to the doc, include a
-        list of pros and cons. Even if the author disagrees with the change,
-        they can use those to document the alternative.
-
-*   **Be supportive in your criticism.** The author may be receiving many
-    comments, and we want to keep contributors motivated to respond.
-
-*   **Be thoughtful about interactions.** Keep the
-    [code of conduct](/CODE_OF_CONDUCT.md) in mind. Try to understand
-    disagreements, and if you can't make progress, step back and think about
-    other possible approaches.
-
-*   **Compliment the author when you're happy with a proposal.** Especially on
-    the Discourse Forum topics where others will see the feedback. This helps
-    all of us avoid _only_ focusing on how proposals should improve. We want to
-    balance that important feedback with explicit and positive feedback for all
-    the good aspects.
+- **Comments should be specific about the issue.** They should include a
+  suggested action, and the expected result from that action. The more specific
+  a comment is, the easier it will be for the proposal author to evaluate.
+
+  - Objections to specific phrasing should suggest alternative phrasing.
+
+- **Use Discourse Forums for long comments.** If a Google Doc comment would be
+  over two paragraphs, take it to the Discourse Forum topic. Doc comments are
+  good for quick, short feedback; detailed feedback is better shared on
+  Discourse Forums.
+
+  - Use the forum topic created by the author, rather than creating a new topic.
+    It needs to be easy for authors and other reviewers to find comments.
+  - If your comment represents a significant change to the doc, include a list
+    of pros and cons. Even if the author disagrees with the change, they can use
+    those to document the alternative.
+
+- **Be supportive in your criticism.** The author may be receiving many
+  comments, and we want to keep contributors motivated to respond.
+
+- **Be thoughtful about interactions.** Keep the
+  [code of conduct](/CODE_OF_CONDUCT.md) in mind. Try to understand
+  disagreements, and if you can't make progress, step back and think about other
+  possible approaches.
+
+- **Compliment the author when you're happy with a proposal.** Especially on the
+  Discourse Forum topics where others will see the feedback. This helps all of
+  us avoid _only_ focusing on how proposals should improve. We want to balance
+  that important feedback with explicit and positive feedback for all the good
+  aspects.
 
 When commenting on a proposal, some questions community members might want to
 address are:
 
-*   What is your evaluation of the proposal?
-*   Is the problem being addressed significant enough to warrant a change to
-    Carbon?
-*   Does this proposal fit with Carbon's
-    [goals, priorities, and principles](goals.md)?
-*   Are there alternative approaches that may be better suited to the problem?
-*   If you have used other languages or libraries with a similar feature, how
-    does the proposal compare?
+- What is your evaluation of the proposal?
+- Is the problem being addressed significant enough to warrant a change to
+  Carbon?
+- Does this proposal fit with Carbon's
+  [goals, priorities, and principles](goals.md)?
+- Are there alternative approaches that may be better suited to the problem?
+- If you have used other languages or libraries with a similar feature, how does
+  the proposal compare?

docs/project/consensus_decision_making.md

@@ -29,15 +29,15 @@ that may only be noticed by a minority.
 Team members have a fundamentally different role while working towards consensus
 on a decision than at other times on the project. They are expected to:
 
-*   Set aside personal advocacy and preferences, and focus on the best decision
-    for the project and community.
-*   Critically evaluate whether their concerns are severe enough to warrant
-    blocking.
-*   Focus on the information presented in a proposal, rather than adding new
-    information. If new information is needed, the request for it should be the
-    decision.
-*   Recognize their own biases and stand aside when unable to form an objective
-    position.
+- Set aside personal advocacy and preferences, and focus on the best decision
+  for the project and community.
+- Critically evaluate whether their concerns are severe enough to warrant
+  blocking.
+- Focus on the information presented in a proposal, rather than adding new
+  information. If new information is needed, the request for it should be the
+  decision.
+- Recognize their own biases and stand aside when unable to form an objective
+  position.
 
 More about consensus decision making may be found from
 "[On Conflict and Consensus](https://web.archive.org/web/20111026234752/http://www.ic.org/pnp/ocac/)",
@@ -47,24 +47,24 @@ and https://www.consensusdecisionmaking.org/.
 
 A formal decision consists of:
 
-*   The decision itself.
-*   A summary of the decision rationale.
-*   A summary of important discussion points.
+- The decision itself.
+- A summary of the decision rationale.
+- A summary of important discussion points.
 
 Here are some possible decisions with their meanings:
 
-*   **accepted**: Yes, we want this now.
-*   **declined**: No, we don't think this is the right direction for Carbon.
-*   **needs work**:
-    *   We need more information or data before we can decide if this is the
-        right direction.
-    *   We like the direction, but the proposal needs significant changes before
-        being accepted.
-*   **deferred**:
-    *   We like the direction, but it isn't our priority right now, so bring the
-        proposal back later.
-    *   We aren't sure about the direction, but it isn't our priority right now,
-        so bring it back later.
+- **accepted**: Yes, we want this now.
+- **declined**: No, we don't think this is the right direction for Carbon.
+- **needs work**:
+  - We need more information or data before we can decide if this is the right
+    direction.
+  - We like the direction, but the proposal needs significant changes before
+    being accepted.
+- **deferred**:
+  - We like the direction, but it isn't our priority right now, so bring the
+    proposal back later.
+  - We aren't sure about the direction, but it isn't our priority right now, so
+    bring it back later.
 
 When a proposal has open questions, the formal decision must include a decision
 for each open question. That may include filing GitHub issues to revisit the
@@ -116,8 +116,8 @@ and sub-items, with each agenda item resolving with a decision.
 
 As part of organizing a meeting, we will have two roles:
 
-*   A **moderator** who is responsible for ensuring discussion stays on track.
-*   A **note taker** who will record minutes for each meeting.
+- A **moderator** who is responsible for ensuring discussion stays on track.
+- A **note taker** who will record minutes for each meeting.
 
 Roles should be known before each meeting. These may or may not be staffed by
 reviewing team members; anybody taking a role should plan to be less involved in

docs/project/evolution.md

@@ -18,15 +18,14 @@ bounded timeframe.
 Our governance structure supports
 [consensus decision-making](consensus_decision_making.md):
 
-*   Community members write proposals.
-*   [Review managers](#review-managers) escort proposals through our consensus
-    decision process.
-*   A [core team](#core-team) makes consensus decisions about Carbon's
-    evolution.
-*   Three [arbiters](#arbiters) respond to escalations about lack of consensus,
-    making decisions through majority vote.
-*   One [painter](#painter) who, where a consensus exists that multiple
-    competing options are reasonable, decides between the provided options.
+- Community members write proposals.
+- [Review managers](#review-managers) escort proposals through our consensus
+  decision process.
+- A [core team](#core-team) makes consensus decisions about Carbon's evolution.
+- Three [arbiters](#arbiters) respond to escalations about lack of consensus,
+  making decisions through majority vote.
+- One [painter](#painter) who, where a consensus exists that multiple competing
+  options are reasonable, decides between the provided options.
 
 ## Evolution process
 
@@ -68,22 +67,21 @@ The process is:
 
 We use several tools to coordinate changes to Carbon:
 
-*   **Discourse Forum** topics will be used for the early idea discussion, any
-    deeper discussions, or more high-level and meta points.
-*   **Discord Chat** can be used for quick and real-time chats and Q&A.
-    *   If there are important technical points raised or addressed, they should
-        get summarized on a relevant Discourse Forum topic.
-*   **Google Docs** is used for writing and reviewing proposals. This
-    facilitates collaborative editing and easy commenting about wording issues.
-*   **Google Hangouts Meet** will be used for VC meetings, typically for
-    decisions.
-    *   Meetings should typically be summarized on a relevant Discourse Forum
-        topic.
-*   **Google Calendar** will be used to track team meeting and vacation times.
-*   **GitHub issues** track the proposal process and life cycle. These are only
-    used to track the process, and should not be used for discussion. All Google
-    Docs and Discourse Forum topics should be linked from the issue for easy
-    indexing.
+- **Discourse Forum** topics will be used for the early idea discussion, any
+  deeper discussions, or more high-level and meta points.
+- **Discord Chat** can be used for quick and real-time chats and Q&A.
+  - If there are important technical points raised or addressed, they should get
+    summarized on a relevant Discourse Forum topic.
+- **Google Docs** is used for writing and reviewing proposals. This facilitates
+  collaborative editing and easy commenting about wording issues.
+- **Google Hangouts Meet** will be used for VC meetings, typically for
+  decisions.
+  - Meetings should typically be summarized on a relevant Discourse Forum topic.
+- **Google Calendar** will be used to track team meeting and vacation times.
+- **GitHub issues** track the proposal process and life cycle. These are only
+  used to track the process, and should not be used for discussion. All Google
+  Docs and Discourse Forum topics should be linked from the issue for easy
+  indexing.
 
 ## Governance structure
 
@@ -102,8 +100,8 @@ team will still review participation.
 
 Our current review managers are:
 
-*   [jperkins@google.com](mailto:jperkins@google.com)
-*   [shummert@google.com](mailto:shummert@google.com)
+- [jperkins@google.com](mailto:jperkins@google.com)
+- [shummert@google.com](mailto:shummert@google.com)
 
 ### Core team
 
@@ -118,14 +116,14 @@ may be added when necessary to expand representation.
 
 Our current core team members are:
 
-*   austern@google.com
-*   chandlerc@google.com
-*   dmitrig@google.com
-*   gromer@google.com
-*   joshl@google.com
-*   palmer@google.com
-*   richardsmith@google.com
-*   titus@google.com
+- austern@google.com
+- chandlerc@google.com
+- dmitrig@google.com
+- gromer@google.com
+- joshl@google.com
+- palmer@google.com
+- richardsmith@google.com
+- titus@google.com
 
 **TODO**: We want this team to eventually include non-Googlers for a broader set
 of perspectives.
@@ -165,9 +163,9 @@ There should always be three arbiters.
 
 Our current arbiters are:
 
-*   chandlerc@google.com
-*   richardsmith@google.com
-*   titus@google.com
+- chandlerc@google.com
+- richardsmith@google.com
+- titus@google.com
 
 ### Painter
 
@@ -189,7 +187,7 @@ aesthetics reasonably consistent.
 
 The current painter is:
 
-*   [chandlerc@google.com](mailto:chandlerc@google.com)
+- [chandlerc@google.com](mailto:chandlerc@google.com)
 
 ### Adding and removing governance members
 
@@ -205,16 +203,16 @@ Any substantive change to Carbon (whether the language, project, infrastructure,
 or otherwise) should follow the evolution process. The meaning of "substantive"
 is subjective, but will generally include:
 
-*   Any semantic or syntactic language change that isn't fixing a bug.
-*   Major changes to project infrastructure (including additions and removals).
-*   Changes to the process itself.
-*   Rolling back a finalized decision (even if never executed).
+- Any semantic or syntactic language change that isn't fixing a bug.
+- Major changes to project infrastructure (including additions and removals).
+- Changes to the process itself.
+- Rolling back a finalized decision (even if never executed).
 
 Changes which generally will not require this process are:
 
-*   Fixing typos or bugs that don't change the meaning and/or intent.
-*   Rephrasing or refactoring documentation for easier reading.
-*   Minor infrastructure updates, improvements, setting changes, tweaks.
+- Fixing typos or bugs that don't change the meaning and/or intent.
+- Rephrasing or refactoring documentation for easier reading.
+- Minor infrastructure updates, improvements, setting changes, tweaks.
 
 If you're not sure whether to follow the process, please err on the side of
 following it. A team can always ask for a change to be made directly if they
@@ -236,23 +234,23 @@ efficient.
 
 ##### Actions
 
-*   **Author**: Create an `Evolution > Ideas` forum topic to discuss the issue
-    before writing the proposal.
-*   **Community**: Provide [constructive commentary](commenting_guidelines.md)
-    for ideas when feedback is solicited.
+- **Author**: Create an `Evolution > Ideas` forum topic to discuss the issue
+  before writing the proposal.
+- **Community**: Provide [constructive commentary](commenting_guidelines.md) for
+  ideas when feedback is solicited.
 
 #### Make a proposal
 
 The first part of making a proposal is to write up a Google Doc explaining,
 roughly in the following order:
 
-*   **Problem**: Information about the problem the proposal is trying to solve.
-*   **Background**: Background on the problem and information needed to
-    understand the proposed solution.
-*   **Proposal**: An overview of the solution.
-*   **Details**: Details of how the proposed solution should be implemented.
-*   **Alternatives**: Information about alternative solutions or details that
-    were considered and rejected.
+- **Problem**: Information about the problem the proposal is trying to solve.
+- **Background**: Background on the problem and information needed to understand
+  the proposed solution.
+- **Proposal**: An overview of the solution.
+- **Details**: Details of how the proposed solution should be implemented.
+- **Alternatives**: Information about alternative solutions or details that were
+  considered and rejected.
 
 We use a
 [template for proposals](https://docs.google.com/document/d/1sqEnIWWZKTrtMz2XgD7_RqvogwbI0tBQjAZIvOabQsw/template/preview)
@@ -269,8 +267,8 @@ proposals, and may be helpful when trying to find others with similar ideas.
 
 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
+[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.
 
 Where parts of a proposal may have several ways to address them, feel free to
@@ -285,13 +283,12 @@ Where the proposal makes a decision between multiple options, move them to the
 
 ##### Actions
 
-*   **Author**:
-    *   Write the proposal using
-        [the template](https://docs.google.com/document/d/1sqEnIWWZKTrtMz2XgD7_RqvogwbI0tBQjAZIvOabQsw/template/preview).
-        *   The template has additional items under "TODO: Initial proposal
-            setup".
-        *   Note that Google Doc and GitHub issue templates have the status set
-            to `WIP`.
+- **Author**:
+  - Write the proposal using
+    [the template](https://docs.google.com/document/d/1sqEnIWWZKTrtMz2XgD7_RqvogwbI0tBQjAZIvOabQsw/template/preview).
+    - The template has additional items under "TODO: Initial proposal setup".
+    - Note that Google Doc and GitHub issue templates have the status set to
+      `WIP`.
 
 #### (optional) Elicit early, high-level feedback on the proposal
 
@@ -301,11 +298,11 @@ favor the forum topic (vs Doc comments) for high-level discussion.
 
 ##### Actions
 
-*   **Author**: Update (or create if needed) the `Evolution > Ideas` forum topic
-    to advertise the proposal and elicit early, high-level feedback.
-    *   Add the topic's link to the GitHub issue.
-*   **Community**: Provide [constructive commentary](commenting_guidelines.md)
-    for ideas when feedback is solicited.
+- **Author**: Update (or create if needed) the `Evolution > Ideas` forum topic
+  to advertise the proposal and elicit early, high-level feedback.
+  - Add the topic's link to the GitHub issue.
+- **Community**: Provide [constructive commentary](commenting_guidelines.md) for
+  ideas when feedback is solicited.
 
 ### Solicit and address proposal feedback
 
@@ -321,12 +318,12 @@ discussion, as well as links to prior discussion topics.
 
 ##### Actions
 
-*   **Author**:
-    *   Set both the Google Doc status and GitHub issue status label to `RFC`.
-    *   Create an `Evolution > RFC` forum topic.
-        *   Summarize the discussion points, along with a link to the Google Doc
-            and GitHub issue.
-        *   Add the topic's link to the GitHub issue.
+- **Author**:
+  - Set both the Google Doc status and GitHub issue status label to `RFC`.
+  - Create an `Evolution > RFC` forum topic.
+    - Summarize the discussion points, along with a link to the Google Doc and
+      GitHub issue.
+    - Add the topic's link to the GitHub issue.
 
 #### Community and reviewing team comments on proposal
 
@@ -348,11 +345,11 @@ also be added where the author isn't confident about the best approach.
 
 ##### Actions
 
-*   **Author**:
-    *   Update the Doc and/or comment in the topic to address feedback.
-    *   Create GitHub issues for any open questions to be revisited later.
-*   **Reviewing team and community**: Provide
-    [constructive commentary](commenting_guidelines.md) for proposals.
+- **Author**:
+  - Update the Doc and/or comment in the topic to address feedback.
+  - Create GitHub issues for any open questions to be revisited later.
+- **Reviewing team and community**: Provide
+  [constructive commentary](commenting_guidelines.md) for proposals.
 
 #### (optional) Pause for a major revision
 
@@ -369,19 +366,20 @@ discussion points thus far (with links to those prior topics).
 
 ##### Actions
 
-*   **Author**:
-    *   Announce to the Discourse Forum topic that the proposal is undergoing
-        major revision.
-    *   Set both the Google Doc status and GitHub issue status label to `WIP`.
-*   **Reviewing team and community**: Refrain from commenting until the author
-    solicits feedback again.
+- **Author**:
+  - Announce to the Discourse Forum topic that the proposal is undergoing major
+    revision.
+  - Set both the Google Doc status and GitHub issue status label to `WIP`.
+- **Reviewing team and community**: Refrain from commenting until the author
+  solicits feedback again.
 
 #### Request a review manager
 
 Once discussion settles down and all comments have been resolved, the author
-should request a review manager by creating a `Evolution > Review manager
-requests` topic. A review manager should respond within a day or two. This may
-not be needed if a review manager has already taken ownership.
+should request a review manager by creating a
+`Evolution > Review manager requests` topic. A review manager should respond
+within a day or two. This may not be needed if a review manager has already
+taken ownership.
 
 The review manager is responsible for validating that the proposal is ready for
 the reviewing team to make a decision. They will ensure that at least a couple
@@ -393,15 +391,15 @@ the reviewing team will be asked to start making a decision after a day.
 
 ##### Actions
 
-*   **Author**:
-    *   Ensure all comments are resolved.
-    *   Create a `Evolution > Review manager requests` topic asking for a review
-        manager, providing a link to the proposal's Doc and GitHub issue.
-        *   Add the topic's link to the GitHub issue.
-*   **Review manager**:
-    *   Ask reviewing team members to review the proposal when needed.
-    *   Double-check that comment threads are addressed by the proposal.
-    *   Update the `Evolution > RFC` topic with a last call for comments.
+- **Author**:
+  - Ensure all comments are resolved.
+  - Create a `Evolution > Review manager requests` topic asking for a review
+    manager, providing a link to the proposal's Doc and GitHub issue.
+    - Add the topic's link to the GitHub issue.
+- **Review manager**:
+  - Ask reviewing team members to review the proposal when needed.
+  - Double-check that comment threads are addressed by the proposal.
+  - Update the `Evolution > RFC` topic with a last call for comments.
 
 ### Reviewing team makes a proposal decision
 
@@ -420,10 +418,10 @@ for major revision.
 
 ##### Actions
 
-*   **Author**:
-    [Transfer ownership](https://support.google.com/docs/answer/2494892) of the
-    proposal's Doc to the review manager.
-*   **Review manager**: Change all edit access on the proposal to comment-only.
+- **Author**:
+  [Transfer ownership](https://support.google.com/docs/answer/2494892) of the
+  proposal's Doc to the review manager.
+- **Review manager**: Change all edit access on the proposal to comment-only.
 
 #### Ask the reviewing team for a proposal decision
 
@@ -437,19 +435,19 @@ removed if a decision is made before the meeting.
 Team members should familiarize themselves with the proposal and related
 discussion. Try to respond to the Discourse Forum topic promptly with:
 
-*   A position (either affirming or objecting) is strongly preferred, although
-    standing aside is allowed.
-    *   Rationales for positions should be based on discussion on the proposal's
-        `Evolution > RFC` topic, and providing links helps write the decision.
-*   A request for more time to review materials, to make it clear the intent is
-    to participate in the decision.
-*   Discussion regarding positions or the decision itself.
-    *   The reviewing team will participate in the proposal community comment
-        period, so that substantive feedback can be incorporated by the author
-        prior to requesting a decision.
-*   A request to use the meeting for discussion.
-    *   All topics for discussion will be captured either in the agenda or as a
-        comment on the Doc, to ensure they're ready for the meeting.
+- A position (either affirming or objecting) is strongly preferred, although
+  standing aside is allowed.
+  - Rationales for positions should be based on discussion on the proposal's
+    `Evolution > RFC` topic, and providing links helps write the decision.
+- A request for more time to review materials, to make it clear the intent is to
+  participate in the decision.
+- Discussion regarding positions or the decision itself.
+  - The reviewing team will participate in the proposal community comment
+    period, so that substantive feedback can be incorporated by the author prior
+    to requesting a decision.
+- A request to use the meeting for discussion.
+  - All topics for discussion will be captured either in the agenda or as a
+    comment on the Doc, to ensure they're ready for the meeting.
 
 The review manager should monitor the forum topic for consensus. If a decision
 is made before the meeting, the item should be removed from the meeting agenda.
@@ -458,24 +456,23 @@ make decisions.
 
 ##### Actions
 
-*   **Author**:
-    *   Respond to comments.
-*   **Review manager:**
-    *   Set both the Google Doc status and GitHub issue status label to `needs
-        decision`.
-        *   In the Doc history, label the latest revision as `needs decision`
-    *   Create an `Evolution > Proposal decisions` topic for pre-meeting
-        discussion.
-    *   Tentatively add the decision to the meeting one week in advance (or four
-        working days, if longer), and use that meeting if necessary to reach
-        consensus.
-    *   Monitor the topic for a consensus decision.
-        *   If a consensus is reached, ensure there's enough information to
-            write a decision.
-*   **Every reviewing team member:**
-    *   Review the proposal again and make comments if needed.
-    *   Participate in reaching a consensus, or explicitly stand aside.
-    *   Offer justifications towards a decision.
+- **Author**:
+  - Respond to comments.
+- **Review manager:**
+  - Set both the Google Doc status and GitHub issue status label to
+    `needs decision`.
+    - In the Doc history, label the latest revision as `needs decision`
+  - Create an `Evolution > Proposal decisions` topic for pre-meeting discussion.
+  - Tentatively add the decision to the meeting one week in advance (or four
+    working days, if longer), and use that meeting if necessary to reach
+    consensus.
+  - Monitor the topic for a consensus decision.
+    - If a consensus is reached, ensure there's enough information to write a
+      decision.
+- **Every reviewing team member:**
+  - Review the proposal again and make comments if needed.
+  - Participate in reaching a consensus, or explicitly stand aside.
+  - Offer justifications towards a decision.
 
 #### (optional) Use the meeting to make a proposal decision
 
@@ -491,16 +488,16 @@ meeting, even if it is to defer the proposal. The review manager should verify
 they understand the decision, because they will be responsible for publishing
 it.
 
-*   **Author**: (optional) Consider attending the meeting to better understand
-    the proposal decision.
-*   **Review manager**:
-    *   Help identify a
-        [moderator and note taker](consensus_decision_making.md#roles) for the
-        meeting, possibly volunteering as note taker.
-    *   Ensure the meeting provides enough information to write a decision.
-*   **Reviewing team**:
-    *   Participate in reaching a consensus, or explicitly stand aside.
-    *   Offer justifications towards a decision.
+- **Author**: (optional) Consider attending the meeting to better understand the
+  proposal decision.
+- **Review manager**:
+  - Help identify a
+    [moderator and note taker](consensus_decision_making.md#roles) for the
+    meeting, possibly volunteering as note taker.
+  - Ensure the meeting provides enough information to write a decision.
+- **Reviewing team**:
+  - Participate in reaching a consensus, or explicitly stand aside.
+  - Offer justifications towards a decision.
 
 ### Finalize the proposal decision
 
@@ -520,25 +517,24 @@ author again. It's not necessary to switch ownership back.
 
 ##### Actions
 
-*   **Review manager**:
-    *   If the proposal needs more changes:
-        *   Grant the author edit access to the Doc again.
-        *   Set both the Google Doc status and GitHub issue status label to
-            `WIP`.
-    *   If the proposal is done changing:
-        *   Set both the Google Doc status and GitHub issue status label to
-            `<decision>`.
-    *   In the Doc history, label the latest revision as `<decision>`.
-    *   Write the
-        [formal decision](consensus_decision_making.md#formal-decision-content),
-        possibly with help from the reviewing team.
-        *   (optional): Create a GitHub issue for issues that should be
-            revisited in the future. Link to these from the main GitHub issue.
-    *   Create an `Evolution > Announcements` forum topic with the decision and
-        a summary of the rationale.
-        *   Add the topic's link to the GitHub issue.
-*   **Reviewing team**: Help draft any rationale needed by the review manager
-    for the decision.
+- **Review manager**:
+  - If the proposal needs more changes:
+    - Grant the author edit access to the Doc again.
+    - Set both the Google Doc status and GitHub issue status label to `WIP`.
+  - If the proposal is done changing:
+    - Set both the Google Doc status and GitHub issue status label to
+      `<decision>`.
+  - In the Doc history, label the latest revision as `<decision>`.
+  - Write the
+    [formal decision](consensus_decision_making.md#formal-decision-content),
+    possibly with help from the reviewing team.
+    - (optional): Create a GitHub issue for issues that should be revisited in
+      the future. Link to these from the main GitHub issue.
+  - Create an `Evolution > Announcements` forum topic with the decision and a
+    summary of the rationale.
+    - Add the topic's link to the GitHub issue.
+- **Reviewing team**: Help draft any rationale needed by the review manager for
+  the decision.
 
 #### Community comments on proposal decision
 
@@ -554,10 +550,10 @@ period should not be used to continue to debate decisions unless raising
 specific new information. When commenting, some questions you might want to
 address are:
 
-*   Is the decision clear in its conclusion?
-*   Does the decision explain its rationale well?
-*   Have concerns or alternatives been effectively understood, acknowledged, and
-    addressed to the extent possible?
+- Is the decision clear in its conclusion?
+- Does the decision explain its rationale well?
+- Have concerns or alternatives been effectively understood, acknowledged, and
+  addressed to the extent possible?
 
 If the decision is to approve the change, the author may start making changes
 described in the proposal which are easy to roll back before the decision review
@@ -570,13 +566,12 @@ are non-obvious.
 
 ##### Actions
 
-*   **Author:** (optional) Start making dependent changes which are easy to roll
-    back, and be prepared to roll back if needed.
-*   **Review manager:** Respond to comments and bring any significant issues to
-    the reviewing team's attention.
-*   **Community and reviewing team**: Provide
-    [constructive commentary](commenting_guidelines.md) for the proposal
-    decision.
+- **Author:** (optional) Start making dependent changes which are easy to roll
+  back, and be prepared to roll back if needed.
+- **Review manager:** Respond to comments and bring any significant issues to
+  the reviewing team's attention.
+- **Community and reviewing team**: Provide
+  [constructive commentary](commenting_guidelines.md) for the proposal decision.
 
 #### (optional) Rollback the decision
 
@@ -587,11 +582,11 @@ should be exceptional.
 
 ##### Actions
 
-*   **Author**: Roll back any dependent changes.
-*   **Reviewing team member**: State new, non-consensus position on `Evolution >
-    Decisions` forum topic.
-*   **Review manager**: Return to
-    [asking the reviewing team for a proposal decision](#ask-the-reviewing-team-for-a-proposal-decision).
+- **Author**: Roll back any dependent changes.
+- **Reviewing team member**: State new, non-consensus position on
+  `Evolution > Decisions` forum topic.
+- **Review manager**: Return to
+  [asking the reviewing team for a proposal decision](#ask-the-reviewing-team-for-a-proposal-decision).
 
 #### Execute on proposal decision
 
@@ -614,14 +609,13 @@ revisit the decision.
 
 ##### Actions
 
-*   **Review manager**:
-    *   Commit the proposal PDF to the GitHub decision repository.
-        *   Once committed, add a link to the PDF in the GitHub issue.
-    *   Move the Doc to the archive folder.
-    *   Update the `Evolution > Announcements` forum topic with the final
-        decision.
-    *   Close the GitHub issue.
-*   **Author**: Start making dependent changes to apply the proposal.
+- **Review manager**:
+  - Commit the proposal PDF to the GitHub decision repository.
+    - Once committed, add a link to the PDF in the GitHub issue.
+  - Move the Doc to the archive folder.
+  - Update the `Evolution > Announcements` forum topic with the final decision.
+  - Close the GitHub issue.
+- **Author**: Start making dependent changes to apply the proposal.
 
 ## Acknowledgements