From 71cf406eae267004613cf146e3f9af303b7b5fc4 Mon Sep 17 00:00:00 2001 From: Eric Scouten Date: Mon, 5 Feb 2024 10:59:16 -0800 Subject: [PATCH] Refine governance policy --- docs/modules/ROOT/pages/index.adoc | 2 +- .../ROOT/partials/version-history.adoc | 4 +++ governance.md | 28 ++++++++++++++++--- 3 files changed, 29 insertions(+), 5 deletions(-) diff --git a/docs/modules/ROOT/pages/index.adoc b/docs/modules/ROOT/pages/index.adoc index 816213a..ee79cac 100644 --- a/docs/modules/ROOT/pages/index.adoc +++ b/docs/modules/ROOT/pages/index.adoc @@ -8,7 +8,7 @@ The link:https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specifica This specification describes a _<>_ referred to here as the *<<_identity_assertion,identity assertion>>* that can be added to a _<>_ to enable a _<<_credential_subject,credential subject>>_ to prove control over a digital identity and to use that identity to document their role in the _<>’s_ lifecycle. -*Pre-draft 04 February 2024* · xref:_version_history[] +*Pre-draft 05 February 2024* · xref:_version_history[] [#maintainers] *Maintainers:* diff --git a/docs/modules/ROOT/partials/version-history.adoc b/docs/modules/ROOT/partials/version-history.adoc index 582ae85..ffdf57e 100644 --- a/docs/modules/ROOT/partials/version-history.adoc +++ b/docs/modules/ROOT/partials/version-history.adoc @@ -98,3 +98,7 @@ _This section is non-normative._ * Update references to C2PA technical specification from version 1.4 to 2.0. * Adopt C2PA 2.0 concept of “well-formed manifest” in xref:_validation_method[xrefstyle=full]. * Translate many "to do" items to GitHub issues. See link:https://github.com/creator-assertions/identity-assertion/issues[Open issues]. + +*05 February 2024* + +* Refined description of roles in link:https://github.com/creator-assertions/identity-assertion/blob/main/governance.md[`governance.md`] in project repository. diff --git a/governance.md b/governance.md index c23fcff..831bfe2 100644 --- a/governance.md +++ b/governance.md @@ -1,4 +1,6 @@ -# Community Specification Governance Policy 1.0 +# Creator Assertions Working Group Governance Policy + +_Adapted from [Community Specification Governance Policy 1.0](https://github.com/CommunitySpecification/Community_Specification/blob/main/5._Governance.md) and [FINOS FDC3 Governance Policy](https://github.com/finos/FDC3/blob/master/GOVERNANCE.md)._ This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group and must adhere to the requirements in this document. @@ -6,11 +8,29 @@ This document provides the governance policy for specifications and other docume Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group. -**1.1. Maintainer.** “Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the Working Group. Maintainers are also responsible for determining consensus and coordinating appeals. Each Working Group will designate one or more Maintainer for that Working Group. A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants. +### 1.1. Participants + +“Participants” are those that have made Contributions to the Working Group subject to the [Community Specification Contribution Policy 1.0](https://github.com/finos/standards-project-blueprint/blob/master/governance-documents/6._Contributing.md). The [Creator Assertions Working Group](https://creator-assertions.github.io) has the specific purpose of defining and releasing technical standards that extend the [Coalition for Content Provenance and Authenticity](https://c2pa.org) [technical specification](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html) to describe additional assertions that allow content creators to express individual and organizational intent about their content. + +In practice, “participants” means people that attend and contribute to meetings, raise issues, pull requests (to submit patches to the standards projects), and provide editorial reviews. If you wish to become a participant, you are invited to: + +* [Read the CAWG contributing guide](https://creator-assertions.github.io/index.html#_contributing) +* [File an issue for discussion](https://github.com/creator-assertions/identity-assertion/issues) +* [File a pull request (suggested revision)](https://github.com/creator-assertions/identity-assertion/pulls) (NOTE: requires acceptance of the Community Specification License.) +* [Attend a working group meeting](https://creator-assertions.github.io/index.html#_meeting_schedule) +* [Contact one of the maintainers directly](https://creator-assertions.github.io/identity/0.1-draft/index.html#maintainers) + +### 1.2. Editors and Maintainers + +“Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. Each Working Group will designate an Editor for that Working Group. A Working Group may select a new Editor upon Approval of the Working Group Participants. + +“Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the Working Group. Maintainers are also responsible for determining consensus and coordinating appeals. Each Working Group will designate one or more Maintainer for that Working Group. A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants. + +#### How do you become an Editor or Maintainer? -**1.2. Editor.** “Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. Each Working Group will designate an Editor for that Working Group. A Working Group may select a new Editor upon Approval of the Working Group Participants. +Once you have signed the Contributor License Agreement, you can apply to become an **editor** or **maintainer** by [Contact one of the existing maintainers directly](https://creator-assertions.github.io/identity/0.1-draft/index.html#maintainers). Generally, the maintainers will look for both a history of contribution to CAWG and a commitment to investing sufficient time in the role from any prospective candidates before accepting them to either of those roles. -**1.3. Participants.** “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License. +If you are new to CAWG, but willing to make the investment of time, the maintainers can work with you to build up a history of contribution. ## 2. Decision Making