--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+
+<html>
+<head><title>Policy on Policy</title></head>
+<body>
+
+<table width="100%">
+
+<tr>
+<td> PoP </td>
+<td> </td>
+<td width="20%"> Iang </td>
+</tr>
+
+<tr>
+<td> POLICY <a href="http://wiki.cacert.org/wiki/PolicyDecisions">p200800204.1</a> </td>
+<td> </td>
+<td>
+ 20080309
+</td>
+</tr>
+
+<tr>
+<td> COD1 </td>
+<td> </td>
+<td> </td>
+</tr>
+
+
+<tr>
+<td> </td>
+<td > <b>Policy on Policy</b> </td>
+<td> </td>
+</tr>
+
+</table>
+
+<h2> 0. Preliminaries </h2>
+<p>
+ Policy on Policy adopts the IETF model of
+ 'rough consensus' to create CAcert documents
+ within the open [policy] mail list forum.
+</p>
+
+
+<h2> 1. Scope and Purpose </h2>
+
+<p>
+1.1
+This policy documents and controls the process by which
+CAcert creates and promulgates policies.
+</p>
+
+<p>
+1.2
+The policy covers itself.
+The policy replaces prior ones.
+For Audit purposes,
+the policy is part of the Configuration-Control Specification
+("CCS", <a href="http://rossde.com/CA_review/CA_review_A.html#A1">DRC_A.1</a>)
+and also documents part of the CCS.
+</p>
+
+<p>
+1.3
+The policies so created are generally binding on
+CAcert, registered users and related parties.
+</p>
+
+<p>
+1.4
+The Policy Officer manages all policies
+and the policy group.
+The policy group is formed on the open mailing list
+known as [policy], and is to be open to all
+Community Members of CAcert.
+</p>
+
+<h2> 2. Basic Model </h2>
+
+<p>
+2.1
+The basic concept was drawn from the IETF model.
+</p>
+
+<p>
+2.2
+Policies are documented.
+Documents start as <i>Work-In-Progress</i>, move through to
+<i>DRAFT</i> and finalise in <i>POLICY</i> status.
+</p>
+
+<p>
+2.3
+Decisions are taken by "Rough Consensus."
+A vote may be called to clarify.
+</p>
+
+<p>
+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.
+</p>
+
+<h2> 3. Work-In-Progress </h2>
+
+<p>
+3.1
+An Editor is identified.
+This person is responsible for
+drafting the document, following the consensus of the policy group.
+</p>
+
+<p>
+3.2
+The Policy Officer resolves minor disputes and keeps order.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+3.4
+Documents start with the status of
+"Work-In-Progress" or WIP for short.
+</p>
+
+
+<h2> 4. DRAFT status </h2>
+
+<p>
+4.1
+On completion, a document moves to DRAFT status.
+</p>
+
+<p>
+4.2
+A DRAFT is a policy-in-effect for the Community and is
+to be distributed and treated as such.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+4.4
+Revisions of DRAFTs
+must be treated as decisions on the policy group.
+</p>
+
+<p>
+4.5
+The period of the DRAFT status is announced widely,
+which should be at least a month and no longer than a year.
+</p>
+
+<p>
+4.6
+During the period of DRAFT,
+CAcert Inc. retains a veto over
+policies that effect the running of CAcert Inc.
+</p>
+
+
+<h2> 5. POLICY status </h2>
+<p>
+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.
+</p>
+
+<p>
+5.2
+Once POLICY, the Community may only challenge the document
+in Dispute Resolution.
+</p>
+
+<p>
+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.
+</p>
+
+<h2> 6. Open Process </h2>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+6.3
+Contributors declare any conflicts of interest.
+</p>
+
+<p>
+6.4
+Policies should be issued under free, open,
+non-restrictive,
+irrevocable, non-exclusive,
+and clear licence by CAcert, Inc.
+</p>
+
+<p>
+6.5
+Mailing lists should be archived,
+and important meetings should be minuted.
+</p>
+
+<h2> 7. Disputes. </h2>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+7.3
+Matters unresolved refer back
+to further group discussion.
+</p>
+
+<p>
+7.4
+The external avenue for disputes is to file a dispute
+according to CAcert's
+<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.html">
+Dispute Resolution Policy</a>
+DRP => COD7.
+</p>
+
+</body>
+</html>
projects / gigi.git / blobdiff