Proposal: Community Policy Framework

[jpitts]

Author	Jamie Pitts
Discussions To	TBD
Status	WIP
Type	Informational
Category	Policy
Created	2019-03-20

Ethereum Community Policy Framework

Abstract

This is to serve as a framework for developing integrity-related community policies, enabling teams to evaluate, adopt, and take action on written sets of social code. A key aspect of the Community Policy Framework is the Corpus, a GitHub repository where the policy work occurs.

Motivation

This is to separate the concern of policy content and subject matter from the concern of general policy development, adoption, and maintenance, recognizing that in some cases there is overlap.

What is a Community Policy

A Community Policy is a document containing a set of related declarations which articulate a team's shared values, tolerances for behavior, and desired outcomes. A Policy also specifies actions which team members will take to enforce the policy, whether in response to violations or to reward behavior. Community Policies are intended to be adopted voluntarily on the team-level.

Who are the Editors?

Community Policy Editors help move the policy-writing process along and have control over the pull request process in the GitHub-based policy repository.

What is a Community Policy Corpus?

A Corpus is a GitHub repo containing a large number of related policies, enabling policy-makers and Editors to collaborate and for the community to have visibility into the process. As a Policy is finalized, it is copied to a separate repository to make it easier for Teams to maintain their version of that Policy.

What is a Team's "community-policies" repository?

A Team maintains a "community-policies" repo as a clear way to specify which policies they have adopted and take action on. This, in conjunction with individual Policy repos, enables Teams to check out Policies as git submodules and periodically update their copy.

Writing Work Flow

[ WIP ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]

Each status change is requested by the Policy champion and reviewed by the Editors. Use a pull request to update the status. Please include a link to where people should continue discussing your Policy. The Editors will process these requests as per the conditions below.

• Active -- Some policies may also have a status of “Active” if they require continual or periodic updating. If there is current work to update a Policy, Active status is added.
• Work in progress (WIP) -- A Policy remains a WIP until it has one or more champions. A draft begins once the WIP becomes a directory containing files and presented as a [pull request].
• Draft -- This is when the difficult policy work is performed. The champion may submit follow-up pull requests with further changes to the draft until such point as the Policy is mature and ready to proceed to the next status. A Policy in draft status must be test-adopted by one or more teams to be considered for promotion to the next status.
• Last Call -- This Policy will listed prominently on the Integrity Ring website and announced. A reasonable time period is allowed for feedback from stakeholders in the community.
• Accepted -- This Policy is now ready for adoption by teams, and the Policy content is copied over to its own GitHub repo, and released. The process for teams deciding whether to adopt it into their operation is not part of the Community Policy Framework.
• Final -- This Policy version is designated as the "state of the art" and is merged to master on the Policy GitHub repository. If this is the first version of the Policy, Accepted immediately becomes Final.

Adoption Work Flow

Participating teams must maintain a GitHub repository named "community-policies" which contains the policies they are adopting or have adopted, as well as a README.md describing how they are managing their policies.

[ ADOPTING ] -> [ DRAFT ] -> [ LAST CALL ] ->[ ACCEPTED ] -> [ FINAL ]

• Adopting -- A Team in the community formally begins the process of adoption. This starts with checking out the Policy as a git submodule in a branch of the team's "community-policies" GitHub repository.
• Draft -- The Policy implementation work has begun, possibly in coordination with a Policy Contact. A champion in the team has been identified who is configuring the Policy and working on attaining consensus for adoption by the team.
• Last Call -- This Policy and configuration is announced to the team and to the community. A reasonable time period is allowed for feedback from team members, Policy Contact (if any), and stakeholders.
• Accepted -- The team is now ready to formally adopt the Policy. When the team has reached consensus that it can adopt, the status is set to Final.
• Final -- The branch on the Team's "community-policies" GitHub repo where the Policy work was being done is now merged to master, enabling anyone in the community to see that the Policy is in effect.

Configuring, Versioning, and Forking

A Policy can describe how parts of its text may be altered or configured by the adopting team, how it is versioned, and how it may be forked.

References

Ethereum EIP-1, a document governing the structure and flow of proposed improvements to Ethereum-related technology.

[yeqbfgxjiq]

This looks legit. I like how each team can customize their own policy and process in their own repo, but also has access to the support and resources of the broader community in the Corpus repo. Thanks for putting this together :)

[jpitts]

I found an interesting example, the NPM project (a critical pieces of javascript infrastructure) actually defines a "policies" repository...

https://github.com/npm/policies