Feat/define-task-force-and-mention-from-staging-process

CGCharter-1727386911.html

@@ -463,6 +463,16 @@ <h2 id="offboarding-chairs">
         communication as described above.
       </li>
     </ul>
+    <h2 id="task-forces">
+      Task Forces
+    </h2>
+    <p>
+      Task Forces are lightweight organizational subsets of the Community Group
+      that serve to channel work and attention to tasks (and allow others to
+      "tune out" of the many topics and work items proceeding in parallel that
+      are  less pressing for them). They can schedule their own topic calls
+      (i.e. public, minuted meetings on the CG calendar) and can tag niche email threads with the name of their task force as a courtesy to the rest of the group. When minutes from task-force specific topic calls are uploaded, they are marked by task force name. "Task Forces" are spun up by community group resolution, usually to work on a work item at any stage of formalization or to accomplish some other objective, and can be spun down or change scope at any time by internal consensus. The convener of a task force does NOT need to be the "champion" of a work item being coordinated in it, NOR do they need to be a Committer.
+    </p>
 
     <h2 id="charter-change">
       Amendments to this Charter

stage-process.md

@@ -27,6 +27,19 @@ by this staging process consider beginning its unofficial work already
 under the [W3C Software and Document License](https://www.w3.org/copyright/software-license-2023/),
 or similar license from the W3C.
 
+Note: As this process focuses on documents and deliverables, it is
+"individualistic" and refers to champions (usually one of the editors and/or
+primary authors of deliverable) as its primary control structure. In practice,
+the community group has a marked preference for collaborative work, and the
+formation of a "task force" to collect contributions is the default working
+mode. There is no requirement that a task force be lead by a work item's
+champion, and in many cases a task force is best convened by a "problem expert"
+or, e.g., a usability researcher rather than an implementer of a given solution,
+particularly if multiple solutions are being debated and compared by the group.
+Task Forces are not required but recommended, and can be formed at any stage,
+although typically community group conversation about forming one coincides with
+the adoption of a Stage 1 work item.
+
 ## Stage 0: Exploration
 
 The purpose of Stage 0 proposals is to allow anyone to raise and explore the
@@ -77,10 +90,10 @@ and fitness for purpose, and finally, identifying the best out of the many
 alternatives.
 
 **Great care** should be taken to avoid substantial technical/design discussions
-happening outside the "IPR" boundary of the Community Group members if normative
-status beyond stage 1 is desired; further standardization MUST be rejected if
-"clean IPR" cannot be achieved (e.g. by post-facto IP grants from all
-substantial contributors).
+happening outside the "IPR" (intellectual property rights) boundary of the
+Community Group members if normative status beyond stage 1 is desired; further
+standardization MUST be rejected if "clean IPR" cannot be achieved (e.g. by
+post-facto IP grants from all substantial contributors).
 
 * What's needed from champions?
   * [ ] Public identification of one or more
@@ -95,6 +108,11 @@ substantial contributors).
     their proposal, the WG chairs will create a repo for the champions to
     develop the feature or proposal (e.g.,
     [example](https://github.com/swicg/activitypub-http-signature)).
+  * [ ] If there is enough interest and diversity of contributors, a CG Task
+    Force can often be helpfully proposed at this point to house and track
+    discussions, but is not a requirement. Particularly for features with IPR
+    consequences, task forces can be helpful for pushing sensitive discussions
+    inside the IPR boundaries of the community group.
 
 ## Stage 2: Formalization (Community Group)