The proper policy document is located
on the CAcert website .

This document is a working draft to include
future revisions only, and is currently
only relevant for the [policy] group.
Suggested additions in BLUE, strikes in blue.
Iang 20100507: fixed two errors being cacert-policy and 1.3 terminology.
Iang 20100507: incorporated suggestions from CCS - 2.3, 5.4, 6.5
Uli 20130223: incorporating suggestion to transfer section from CPS 9.16.1 to PoP 5.4, added reworded p20100306 into #2.5, header reformated to reflect new header style
Uli 20130310: fixing /wiki/ migration from 2009 in links according to PoP 2.5

Name: PoP COD1
Status: POLICY p20080204.1, DRAFT p20130223
Editor: Iang 20080309
Licence: CC-by-sa+DRP
PoP Status - POLICY
PoP Status - DRAFT

Policy on Policy

0. Preliminaries

Policy on Policy adopts the IETF model of 'rough consensus' to create CAcert documents within the open [policy] mail list forum. CAcert Policy Group mail list forum.

1. Scope and Purpose

1.1 This policy documents and controls the process by which CAcert creates and promulgates policies.

1.2 The policy covers itself. The policy replaces prior ones. For Audit purposes, the policy is part of the Configuration-Control Specification ("CCS", DRC_A.1) and also documents part of the CCS.

1.3 The policies so created are generally binding on CAcert, registered users and related parties CAcert Inc., members under CAcert Community Agreement (CCA => COD9) and other related parties under other agreements.

1.4 The Policy Officer manages all policies and the policy group. The policy group is formed on the open mailing list known as [cacert-policy] CAcert Policy Group, and is to be open to all Community Members of CAcert.

2. Basic Model

2.1 The basic concept was drawn from the IETF model.

2.2 Policies are documented. Documents start as Work-In-Progress, move through to DRAFT and finalise in POLICY status.

2.3 Decisions are taken by "Rough Consensus." A vote may be called to clarify.

2.4 Documents should include a minimum of information in a standardised format managed by the Documentation Officer: the Title, short name, Document Status, date the Status was reached, Editor, date / time of the last edit, Abstract.

2.5 Editors may make the following changes, where it is clear that the change does not change the policy:

Such changes to be notified to the policy group, and to be folded into effect, etc, without further ado.

2.6 Documents of lower status (work-in-progress or DRAFT) must not be confusable with documents of higher status (DRAFT or POLICY). Copies should be eliminated where not being worked on.

3. Work-In-Progress

3.1 An Editor is identified. This person is responsible for drafting the document, following the consensus of the policy group.

3.2 The Policy Officer resolves minor disputes and keeps order.

3.3 The mail list of the policy group is used as the primary debating forum. A sub-group may be formed, but decision-taking should be visible on the main group.

3.4 Documents start with the status of "Work-In-Progress" or WIP for short.

4. DRAFT status

4.1 On completion, a document moves to DRAFT status.

4.2 A DRAFT is a policy-in-effect for the Community and is to be distributed and treated as such.

4.3 As far as the Community is concerned, the DRAFT is policy. Challenges and concerns can be addressed to the policy group, and policy group discussions on a DRAFT may be presented in Dispute Resolution.

4.4 Revisions of DRAFTs must be treated as decisions on the policy group.

4.5 The period of the DRAFT status is announced widely, which should be at least a month and no longer than a year.

4.6 During the period of DRAFT, CAcert Inc. retains a veto over policies that effect the running of CAcert Inc.

5. POLICY status

5.1 After DRAFT period has elapsed with no revision beyond minor and editorial changes, there should be a decision to move the document from DRAFT to POLICY status.

5.2 Once POLICY, the Community may only challenge the document in Dispute Resolution.

5.3 Policy group may propose changes to a POLICY document in order to update it. When changes move to DRAFT status, they may be included in the POLICY document, but must be clearly indicated within as DRAFT not POLICY.

5.4 POLICY documents are published on the CAcert website in plain HTML. Change control must be in place.

6. Open Process

6.1 All policy discussions and documents should be open processes. There should be a fair chance for the Community to have their views heard. Rough Consensus is the working metric.

6.2 Contributions to formally controlled documents such as Policies are transferred fully to CAcert Inc. Copyrights and similar intellectual property rights required to incorporate the Contribution are either transferred to CAcert Inc, or, are issued and contributed under free, open, non-restrictive, irrevocable, exclusive, and clear licence to CAcert Inc. In all cases, CAcert Inc licenses the contributions back to the community under an open licence.

6.3 Contributors declare any conflicts of interest.

6.4 Policies should be issued under free, open, non-restrictive, irrevocable, non-exclusive, and clear licence by CAcert, Inc.

6.5 Mailing lists should be archived, and important meetings should be minuted. A record of decisions is to be maintained.

7. Disputes.

7.1 Any questions not resolved by these rules may be voted on in the policy group, or may be dealt with in Dispute Resolution.

7.2 The Policy Officer may decide a tight vote in a minor matter only. Failure of Rough Consensus may be declared by dissenting members.

7.3 Matters unresolved refer back to further group discussion.

7.4 The external avenue for disputes is to file a dispute according to CAcert's Dispute Resolution Policy DRP => COD7.