Policy on Policy adopts the IETF model of 'rough consensus' to create CAcert documents @@ -93,15 +93,15 @@ th {
-+
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. @@ -111,7 +111,7 @@ the policy is part of the Configuration-Control Specification and also documents part of the CCS.
-+
1.3 The policies so created are generally binding on CAcert, registered users and related parties @@ -119,7 +119,7 @@ The policies so created are generally binding on (CCA => COD9) and other related parties under other agreements.
-+
1.4 The Policy Officer manages all policies and the policy group. @@ -128,27 +128,27 @@ known as [cacert-policy], and is to be open to all Community Members of CAcert.
-+
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: @@ -169,21 +169,21 @@ must not be confusable with documents of higher status Copies should be eliminated where not being worked on.
-+
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 @@ -192,27 +192,27 @@ 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.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, @@ -220,19 +220,19 @@ 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 @@ -240,8 +240,8 @@ policies that effect the running of CAcert Inc.
-+
5.1 After DRAFT period has elapsed with no revision beyond minor and editorial changes, @@ -250,13 +250,13 @@ 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, @@ -273,9 +273,9 @@ under the same change control as critical source code under SP => COD8.
-+
6.1 All policy discussions and documents should be open processes. There should be a fair chance for @@ -284,7 +284,7 @@ to have their views heard. Rough Consensus is the working metric.
-+
6.2 Contributions to formally controlled documents such as Policies @@ -302,12 +302,12 @@ 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, @@ -315,36 +315,36 @@ irrevocable, non-exclusive, and clear licence by CAcert, Inc.
-+
6.5 Mailing lists should be archived, and important meetings should be minuted. Policy Officer is to maintain a record of decisions.
-+
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