diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8d37ae8e..c69bc894 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -62,11 +62,12 @@ If successful, it will modify `activities.json` with the new specification. Chec
 {
   "ciuName": "The short tagname from caniuse.com for the feature, if available",
   "description": "A textual description; often, the spec's abstract",
+  "id": "A fragment identifier for the positions table",
   "mozBugUrl": "The URL of the Mozilla bug tracking this specification, if available",
   "mozPosition": "under consideration",
   "mozPositionIssue": the number of the issue in this repo, if available,
   "mozPositionDetail": "more information about Mozilla's position",
-  "org": one of ['IETF', 'W3C', 'WHATWG', 'Ecma', 'Other'],
+  "org": one of ['IETF', 'W3C', 'WHATWG', 'Ecma', 'Unicode', 'Proposal', 'Other'],
   "title": "The spec's title",
   "url": "The canonical URL for the most recent version of the spec"
 }
@@ -86,6 +87,8 @@ assessment.
 
 ## Discussing Mozilla's Position on a Web Specification
 
+### For the Broader Community
+
 We welcome discussion members of the wider Mozilla community -- including the public -- but ask
 that it be on-topic, and that it follow [Mozilla's Community Participation
 Guidelines](https://www.mozilla.org/about/governance/policies/participation/).
@@ -103,3 +106,47 @@ issue or a specific comment.
 If an issue becomes overwhelmed by excessive advocacy, comments might be deleted, and the
 issue might be locked.
 
+### For Mozilla's Subject-Matter Experts
+
+The purpose of this repository is to help
+Mozilla's technical leaders reach a consensus position
+about new Web features being proposed.
+Therefore, you might be asked for your opinion
+on specifications where you are one of the experts within the Mozilla community,
+or feel like you have valuable contributions to make
+to issues on other specifications even where you haven't explicitly been asked to do so.
+
+The goal of the discussions in this repository is
+to figure out what we think about a proposal or specification.
+The key factors to consider are:
+
+* how useful we think the proposed feature is likely to be (or how important the use case it's trying to address is), relative to the likely costs to users (e.g., security or privacy risks), developers (e.g., increased complexity and cognitive load), and implementers (cost of implementing it and maintaining that implementation)
+* whether there are any critical problems we see in the current proposal that we should try to get fixed (e.g., around security, privacy, or ability to implement across multiple browser engines)
+
+It's useful to discuss these in the relevant issue in this repository.
+
+At the same time,
+we should avoid doing things to move
+discussions that should happen in the standards body's normal discussion mechanisms
+from happening instead in the standards-positions issue.
+When it makes sense to do so,
+it's good to raise issues through the normal issue trackers for the proposal.
+However, when doing so, it's worth being careful to avoid giving a *mistaken* impression
+that engagement in the discussion constitutes support.
+In some cases, avoiding this impression may require having some of the discussion in the standards-positions issue.
+However, in many cases that can be avoided
+by giving appropriate context when filing issues, such as:
+"I was reading [specification] in order to understand it better
+to help evaluate what Mozilla thinks of it,
+and while doing that I noticed ..."
+
+Members of the Mozilla community are
+welcome to judge that we've come to sufficient consensus in the issue,
+and make a pull request to document that consensus by changing `activities.json`.
+When this happens, we'd like to try to keep the technical discussion
+about what the position is
+happening in the issue
+(so that it stays in one place),
+and limit the discussion in the pull request
+to the details of making the change to `activities.json`.
+