W3C CCG Work Item Process

Draft Community Group Report,

This version:
https://w3c-ccg.github.io/workitem-process/
Issue Tracking:
GitHub
Inline In Spec
Editors:
Kim Hamilton Duffy (MIT Open Learning)
Heather Vescent (The Purple Tornado Inc)
Wayne Chang (Spruce Systems Inc.)
Authors:
Joe Andrieu, Legendary Requirements, http://legreq.com/
Christopher Allen, Blockchain Commons, http://www.lifewithalacrity.com/

Abstract

Documentation for the W3C CCG Work Item process

Status of this document

1. Introduction

To streamline and clarify how the W3C Credentials Community Group operates, this document outlines the process by which a CCG work item is created, managed, and finalized by the group.

2. Terminology

community report: A category of CCG work item whose target deliverable is a collaborative document, with the goal of being completed and published by the CCG as a final report on [W3C-CCG-PAGE]. A community report must not suggest it is a standard or on the W3C standard track.

ongoing community draft — A category of CCG work item with a ccg repository that will be maintained by the CCG in perpetuity. It is not intended to beome a final report. Examples include registries, conformance tests, schemas, reference code, etc.

task force — A category of CCG work item that meets on a regular basis to address a specific topic within the scope of the CCG. It is not intended to beome a final report and may be concluded at any time by the participants. Examples include the VC-EDU task force, Secure Data Storage task force and DID Resolution task force. From time to time, task forces will provide updates to the main CCG community.

community specification: A type of community report, with intended transition to becoming a standard track working group [W3C-CANDIDATE-REC]

community note: A type of community report, with intended transition to becoming a [W3C-WG-NOTE]

community commentary: A type of community report not intended to transition to a [W3C-WG].

rough draft: A stage of a community report work item that is not yet available in a ccg repository, but is being iterated on via whatever medium or format the editors favor, e.g., Google Docs, Github, etc

unreleased draft: A stage of a community report work item that exists as a ccg repository but which is not yet a released draft

released draft: A stage of a community report work item that is tagged with a git release number but not published to W3C.

published draft: A stage of community report work item in which CCG chairs have approved a released draft and published it on the [W3C-CCG-PAGE]

final report: A stage of community report work item in which a published draft has been approved by the CCG community and the W3C staff, and is considered accepted as a [CG-FINAL-REPORT].

conformance test suite: A type of ongoing community draft, with the goal as being a companion to a community specification for testing of conformance.

registry: A type of ongoing community draft, with the goal of providing an informative, long-lived list (such as credential status methods, DID methods, Linked Data Key Types)

schema: A type of ongoing community draft, with the goal of providing reference schemas, such as JSON-LD contexts or JSON schemas.

experimental implementation: A type of ongoing community draft, with the goal of providing an example implementation of a community specification.

work item: An effort that is adopted by the CCG for further development and refinement. The process for CCG work items is described in this document.

release tag: A git concept for "freezing" a git artifact.

ccg repository , for iteration by CCG members through discussion, issues, and pull requests,

proposal: The initial stage of a CCG work item in which the CCG member announces their intention. adoption: The stage after proposal in which the CCG community discusses the proposed work item draft: The stage after a CCG work item has been accepted final: The final success stage of CCG work item. This only applies to community report work items, and not ongoing community drafts. archived: A stage of CCG work item which has been retired by the Chairs due to inactivity

stage: Refers to a phase of a CCG work item within the overall lifecycle

category: A course classification of CCG work items

type: A finer classification of CCG work items

target deliverable: The desired output or outcome of a CCG work item, which corresponds to CCG’s work item classifications

2.1. Work Item Requirements

2.1.1. W3C Requirements

As per [W3C-CG-GUIDELNES], W3C Community Groups (CGs) are established for communities of stakeholders to socialize their ideas for possible future standardization. CGs can publish documents with relatively minimal process and requirements other than that contributors agree to the [W3C-CLA].

The CCG manages a large number of work items, and in the course of its work, has developed conventions and tools to help streamline the process for its members, as well as guidelines and requirements to enable the chairs to manage the group more effectively. This document is designed to conform to W3C’s [CG-PROCESS] and [CG-REQUIREMENTS], which are the ultimate requirements for a W3C community group.

Group members may propose a different process for their work item, which the chairs may choose to accept (on a case-by-case basis) as long as the W3C’s [CG-PROCESS] and [CG-REQUIREMENTS] are met.

NOTE: Long term these may be replaced by new W3C processes, but currently as Working Groups currently terminate, until a new process for these is created by the W3C we maintain them as community groups are perpetual.

2.1.2. Additional CCG Requirements

The CCG has additional requirements in order to adopt a work item:

2.1.3. Work Item Scope

In general, any work that advances the [CCG-MISSION] is welcome for consideration as a work item.

2.1.4. Work Item Questions

Each proposed work item must answer the following questions in their proposal. These questions are based on the Heilmeir Catechism. The intention is to improve clarity and understanding of the proposed work item.

2.1.5. Work Item Best Practices

While not a requirement, the following best practices are recommended

2.2. Work Item / Target Deliverable Classification

2.2.1. Categories

CCG classifies its work items by the target deliverable. The first relevant classification is a target deliverable category; the CCG distinguishes between three:

The ongoing community draft category is not common in the W3C, but has emerged as a useful concept in the CCG to cover ongoing work items that are useful to the community, while not being intended to turn into a final report

The task force category is not common in the W3C, but has emerged as a useful activity in the CCG to discuss topics of importance to the community. Task forces must have

For a task force to remain active, it must

If a response is not rendered within two weeks of the chairs' request, then the chairs may deem the task force to be inactive.

2.2.2. Types

These categories are further broken down into the following target deliverable types:

Figure: Types of Work Items work item types

2.3. Work Item Lifecycle

A CCG work item's lifecycle differs depending on its category:

Figure: Work Item Process Overview work item process overview

The lifecycle stages are:

  1. proposal

  2. adoption

  3. draft

  4. archived

  5. final -- not relevant for ongoing community draft

2.3.1. Proposal Stage

A more concise version of this information is made available at [CCG-PROPOSE-WORK-ITEM].

A CCG member initiates a proposal by creating a [CCG-GITHUB-ISSUES] with the “New Work Item” template. The template prompts for the following proposal elements:

  1. Abstract or Draft of proposed work item (typically a link to a google doc or a markdown page in Github)

  2. Editors responsible for advancing the work item. Initially, a proposal may have a single editor; however, before approval of a work item it must have more than one editor, and editors must include representation from at least two companies.

  3. Work item questions

Once the proposal github issue exists, the member should post the announcement to the CCG mailing list Credentials Community Group <[public-credentials@w3.org](mailto:public-credentials@w3.org)>, linking to the Github issue.

2.3.2. Adoption Stage

Once a proposal is announced, the community group will discuss it for a period of at least one week. This discussion may take place on the mailing list and the regular conference call at the Chairs discretion. During this time, proposers should seek support and consensus around their specific proposal.

Once there has been suitable opportunity for conversation, the chairs will make a determination as follows: if the chairs decide the work item is appropriate, has sufficient community support, and there are no principled objections, the chairs will formally accept the work item.

2.3.3. Draft Stage

Once approved, the Chairs will facilitate creation of a ccg repository, as described in [CCG-CREATE-REPO]. . The editors will facilitate CCG progress on the work item per W3C practices including transparency and public documentation of meetings discussing the work item. To manage the intellectual property of contributions, editors should track work item contributors in the drafts.

2.3.4. Final Stage

A work item that succeeds in becoming a final report is closed. Details for this follow in § 2.4.1 Community Report Stages. The existing ccg repository description will be noted as being “FINAL:”.

ongoing community drafts are not eligible to enter this stage.

2.3.5. Archived Stage

If the chairs determine that progress on a work item is not progressing satisfactorily, they will notify the editors that they have one month to demonstrate progress. After this notice it is at the chairs discretion to keep the work item in the CCG roadmap, change the editors for the work item, or remove the work item from the CCG roadmap and formally close the work item, and the existing ccg repository description will be noted as being “CLOSED:”

Applies here and in following sections. The convention of marking stage by the repository description prefix may not be the best way; should we use tags instead?

2.4. Work Item Stages, by Category

This section provides more detail to work item stages, depending on the work item category

Figure: Work Item Process Detail work item process details

2.4.1. Community Report Stages

2.4.1.1. Rough Draft Stage
2.4.1.2. Unreleased Draft Stage
2.4.1.3. Releeased Draft Stage
2.4.1.4. Published Draft Stage
2.4.1.5. Final Report Stage

2.4.2. Ongoing community draft stages

Propose a CG work item with the intent to make it an ongoing community draft (such as a CG Registry). The proposal would pass per the CG’s documented consensus process.

W3C leadership may propose a ongoing community draft process, in which case this would be revised to include that.

Any normative registry work items should be chartered by a W3C working group and shall be run according to that charter. Charter should include plans for releasing snapshots of the work item.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Informative References

[CCG-CREATE-REPO]
CCG Create Repo. URL: https://w3c-ccg.github.io/create_repo.html
[CCG-GITHUB-ISSUES]
CCG Github Issues. URL: https://github.com/w3c-ccg/community/issues
[CCG-MISSION]
W3C CCG Mission. Adopted. URL: https://www.w3.org/community/credentials/
[CCG-PROPOSE-WORK-ITEM]
Propose a CCG Work Item. URL: https://w3c-ccg.github.io/propose_work_item.html
[CCG-WORK-ITEMS]
CCG Work Items. URL: https://github.com/w3c-ccg/community/blob/master/work_items.md
[CG-FINAL-REPORT]
Community Group Final Reports. URL: https://www.w3.org/community/reports
[CG-PROCESS]
Community Group Process FAQ. URL: https://www.w3.org/community/about/faq/#how-do-we-publish-a-specification
[CG-REQUIREMENTS]
Community Group Requirements. URL: https://www.w3.org/community/reports/reqs/
[SEMVER]
Semantic Versioning. URL: https://semver.org/
[W3C-CANDIDATE-REC]
W3C Candidate Recommendation. URL: https://www.w3.org/2005/10/Process-20051014/tr.html#q74
[W3C-CCG-PAGE]
W3C Credentials Community Page. URL: https://www.w3.org/community/credentials/
[W3C-CG-GUIDELNES]
W3C community process guidelines. URL: https://www.w3.org/community/about/
[W3C-CLA]
W3C Community Contributor License Agreement (CLA). URL: https://www.w3.org/community/about/agreements/cla/
[W3C-WG]
W3C Working Groups. URL: https://www.w3.org/groups/wg/
[W3C-WG-NOTE]
W3C Working Group Note. URL: https://www.w3.org/2005/10/Process-20051014/tr.html#q75

Issues Index

Applies here and in following sections. The convention of marking stage by the repository description prefix may not be the best way; should we use tags instead?