Carbon: Proposal tracking

docs/project/commenting_guidelines.md

@@ -17,18 +17,19 @@ always try to keep feedback, even when critical, constructive and supportive.
   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.
+     - Objections to specific phrasing should suggest alternative phrasing.
+
+- **Use Discourse Forums for long comments.** GitHub is good for
+  short-to-moderate-sized comments. Discourse Forums is better for long,
+  detailed comments, particularly where multiple parties may get involved in
+  discussion.
+
+     - 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.

docs/project/consensus_decision_making.md

@@ -56,15 +56,15 @@ 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.
+     - 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.
+     - 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
@@ -103,9 +103,9 @@ items, meetings will not be held.
 Agenda items (e.g., proposals) should be added at least one week in advance (or
 four working days, if longer), so that members have time to review items added
 to the agenda. Sub-items (e.g., proposal discussion points) should be added at
-least one day before the meeting; every open Google Doc comment is implicitly a
-sub-item. Please feel free to add items to the agenda and remove them later if
-the agenda item is resolved over other communication forums.
+least one day before the meeting; every open GitHub pull request comment is
+implicitly a sub-item. Please feel free to add items to the agenda and remove
+them later if the agenda item is resolved over other communication forums.
 
 Team members are expected to prepare for the meeting by ensuring they're
 familiar with the proposal and related discussion. The meeting will not include