+++ /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