diff options
authorGeorg Greve (Kolab Systems) <>2010-11-18 12:36:57 (GMT)
committerJeroen van Meeuwen (Kolab Systems) <>2010-11-18 12:36:57 (GMT)
commit6b8e8ea889f248206937c8e92debdc5aa0c8a237 (patch)
parent12a655d62ea2027354c71fa83f0594955005a718 (diff)
Check in KEP-0001
1 files changed, 46 insertions, 0 deletions
diff --git a/KEP-0001.txt b/KEP-0001.txt
new file mode 100644
index 0000000..a22e0d1
--- /dev/null
+++ b/KEP-0001.txt
@@ -0,0 +1,46 @@
+ |number=1
+ |ticketnumber=29
+ |title=Bootstrap the KEP Process
+ |author=Georg Greve
+ |
+ |status=draft
+ |type=process
+ |creation_date=2010-11-16
+ |obsoleted_by=
+ |related=53, 34
+== 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= |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.
+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.
+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 [ here].
+== KEP Types ==
+There are three kinds of KEP:
+# A '''Design KEP''' describes a change to the Kolab Storage Format or other central design questions.
+# A '''Technology KEP''' describes a change to the integrated technologies.
+# An '''Informational KEP''' describes a Kolab design issue, or provides general guidelines or information to the Kolab community, but does not propose a new feature. Informational KEPs do not necessarily represent a Kolab community consensus or recommendation, so users and implementors are free to ignore Informational KEPs or follow their advice.
+# A '''Process KEP''' describes a process surrounding Kolab, or proposes a change to (or an event in) a process. Process KEPs are like Format KEPs but apply to areas other than the Kolab Groupware Solution itself. They may propose an implementation, but not to Kolab's codebase; they often require community consensus; unlike Informational KEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Kolab development. Any meta-KEP is also considered a Process 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 [], 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.
+== References ==
+== Copyright ==
+This document has been placed in the public domain.