summaryrefslogtreecommitdiff
path: root/KEP-0001.txt
diff options
context:
space:
mode:
authorGeorg Greve <greve@katana.(none)>2010-11-18 14:29:16 (GMT)
committerGeorg Greve <greve@katana.(none)>2010-11-18 14:29:16 (GMT)
commit15555eec917fb314a61bb32b50fb62e33e9ec85a (patch)
tree03214627a3bbe53aa97e5f6ab9aa5088e6ddbdc9 /KEP-0001.txt
parent6b8e8ea889f248206937c8e92debdc5aa0c8a237 (diff)
downloadkeps-15555eec917fb314a61bb32b50fb62e33e9ec85a.tar.gz
Drafting on procedure, based on some discussions with Jeroen and others.
Diffstat (limited to 'KEP-0001.txt')
-rw-r--r--KEP-0001.txt46
1 files changed, 41 insertions, 5 deletions
diff --git a/KEP-0001.txt b/KEP-0001.txt
index a22e0d1..1340fc5 100644
--- a/KEP-0001.txt
+++ b/KEP-0001.txt
@@ -15,9 +15,9 @@ __TOC__
== Abstract ==
-KEP stands for Kolab Enhancement Proposal. A KEP is modeled closely after the Python Enhancement Proposal process <ref name="PEP-1">{{cite web|url=http://www.python.org/dev/peps/pep-0001 |title=PEP 1, PEP Purpose and Guidelines |last=Warsaw |first=Hylton}}</ref>. A Kolab Enhancement Proposal is a design document providing information to the Kolab community, or describing a new feature for the Kolab Groupware Solution or its processes or environment. The KEP should provide a concise technical specification of the feature and a rationale for the feature.
+KEP stands for Kolab Enhancement Proposal. A KEP is modeled closely after the Python Enhancement Proposal process <ref name="PEP-1">{{cite web|url=http://www.python.org/dev/peps/pep-0001 |title=PEP 1, PEP Purpose and Guidelines |last=Warsaw |first=Hylton}}</ref>. A Kolab Enhancement Proposal is a design document providing information to the Kolab community, or describing a new feature for the Kolab Groupware Solution or its processes or environment. The KEP should provide a concise technical or procedural specification of the feature and a rationale for the feature.
-Some of the most important benefits of the KEPs are to (a) require ideas to be fully thought out, (b) communicate a change to those who did not particupate in the discussion, (c) document it for future reference and use by new members of our community. We intend KEPs to be the preferred mechanisms for documenting the design decisions that have gone into Kolab after its re-launch in 2010 as well as proposing new features, for collecting community input on an issue. The KEP author is responsible for building consensus within the community and documenting dissenting opinions.
+Some of the most important benefits of the KEPs are to (a) require ideas to be fully thought out, (b) communicate a change to those who did not participate in the discussion, (c) document it for future reference and use by new members of our community and (d) facilitate community based decision making. We intend KEPs to be the preferred mechanisms for documenting the design decisions that have gone into Kolab after its re-launch in 2010 as well as proposing new features, for collecting community input on an issue. The KEP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the KEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. This historical record is available in the KEP GIT repository provided by Kolab Systems. The information is available via GIT web access [http://git.kolabsys.com/keps/ here].
@@ -32,9 +32,45 @@ There are three kinds of KEP:
== KEP Process ==
-The KEP Process is modeled after the PEP process, excluding the forms of markup and headers, with Kolab Systems providing the moderator and reference point. The authoritative address to send KEPs is [mailto:kep-editors@lists.kolabsys.com kep-editors@lists.kolabsys.com], after which discussion will take place on the appropriate list.
-
-We expect that we will need to evolve our processes away from the PEP process as we employ a different development methodology and have a different community. But starting from the established PEP process should at least provide us with a sane default.
+The KEP Process began with a rough approximation of the PEP process, excluding the forms of markup and headers, with Kolab Systems providing the infrastructure and reference point. The authoritative address to send KEPs is [mailto:kep-secretariat@lists.kolabsys.com kep-secretariat@lists.kolabsys.com], after which discussion will take place on the appropriate list.
+
+The life cycle of a KEP is
+
+=== Creation ===
+* A new draft KEP is sent to [mailto:kep-secretariat@lists.kolabsys.com kep-secretariat@lists.kolabsys.com] with the request to assign a number for this KEP.
+* The secretariat assigns the next sequential number to this KEP, ensures the formatting is correct and all header fields are provided, sets up the corresponding tooling, such as the [http://wiki.kolab.org/KEP Wiki] page, the corresponding [https://bugzilla.kolabsys.com Bugzilla] issue, and places the file in the [http://git.kolabsys.com/keps/ GIT repository].
+* The secretariat then announces the new KEP to kep-announce@lists.kolabsys.com and gives the author(s) of the KEP access to the repository.
+
+=== Discussion and Finalization ===
+* The KEP will then be discussed on the most appropriate public mailing list:
+** '''Design KEP''' are typically discussed on [mailto:kolab-format@kolab.org kolab-format@kolab.org]
+** '''Technology KEP''' are typically discussed on [mailto:kolab-devel@kolab.org kolab-format@kolab.org]
+** '''Informational KEP''' are typically discussed on [mailto:kolab-devel@kolab.org kolab-format@kolab.org]
+** '''Process KEP''' are typically discussed on [mailto:kolab-devel@kolab.org kolab-format@kolab.org]
+* Feedback or comments should always be sent with CC: to the author(s) or be entered into the respective Bugzilla issue.
+* The author(s) have the obligation to consider each substantive submission and comment, to judge it carefully and on its technical/substantive merits, and to try and incorporate it in the most constructive, inclusive and consensus building manner.
+* KEPs are adopted by consensus in the form of lack of sustained, qualified opposition.
+* While all kinds of comments are welcome, opposing views owe it to the author(s) to have given good consideration to the aspects raised in the KEP. Depending on the kind of KEP, this means qualified opposition must meet certain minimum criteria:
+** For opposition to be technically qualified, it should be based on the KEP and its references, and make a topical technical point disproving any particular part of the KEPs argument, conclusion or decision.
+** For opposition to be procedurally qualified, it should be based on procedural questions and concerns, as well as accompanied by an improvement proposal.
+* When a KEP has been thoroughly discussed, either on public list before it has become formalized, or in its drafting stage, the secretariat should issue a "closing call" for the KEP, stating the deadline by which it will be considered adopted. This deadline should be
+** '''two weeks''' after the closing call for all KEP that are based on more than '''six weeks''' of discussion on the respective public mailing lists, either before they became formalized as KEP, or after, and
+** '''six weeks''' for all KEP that have been discussed shorter.
+* The closing call should go to kep-announce@lists.kolabsys.com as well as the public mailing list on which the discussion took place.
+* In reaction to the closing call, any member of the Kolab community can request a two week extension for important reasons with the secretariat. This extension will be granted once for any KEP.
+* If there is sustained, qualified opposition (as described above) after the closing call, the author(s) must take that into account in the best way possible, potentially documenting sustained opposition in the KEP. Afterwards, the author(s) shall request another closing call from the secretariat.
+
+=== Adoption, Rejection and Retraction ===
+* If there was no qualified opposition to a closing call on a KEP within the deadline set by the secretariat, the KEP has been formally adopted and its status will be changed to 'accepted'.
+* The author(s) of a KEP can at any point in time retract their proposal, the KEP will then be considered closed, its status will be changed to 'retracted'.
+* If a KEP fails to gain acceptance within '''one calendar year''' after it was initially proposed, its status shall be changed to 'rejected'. A new KEP with a similar proposition can then be requested by the same author(s) or others.
+
+=== Replacement, Retirement ===
+* If a KEP is no longer relevant to Kolab, the secretariat shall send a note of 'pending retirement' to kep-announce@lists.kolabsys.com with no less than '''six weeks''' of notice period for opposition. If no opposition is received, the KEP shall be deemed 'retired' and of purely historical interest.
+* If a KEP has been replaced by another KEP which has been duly accepted, its status shall be set to 'replaced'.
+
+== The Secretariat ==
+The secretariat shall consist of volunteers who are '''not''' currently active in the KEP process as authors or discutants and shall understand their role as a purely faclitatory one. Any member of the Kolab community can volunteer for the secretariat, and shall be held in high honors for helping with this important task.
== References ==