summaryrefslogtreecommitdiff
path: root/KEP-0001.txt
diff options
context:
space:
mode:
authorGeorg Greve <greve@katana.(none)>2010-11-22 17:05:18 (GMT)
committerGeorg Greve <greve@katana.(none)>2010-11-22 17:05:18 (GMT)
commit2a3589f8ad5f18e67a02f81c40802a0050ecd5dd (patch)
tree1c6597e74394af6975dac7ef533a10288d34a86b /KEP-0001.txt
parent133dd988a341de660fac397d81a41eb785ad2fbe (diff)
downloadkeps-2a3589f8ad5f18e67a02f81c40802a0050ecd5dd.tar.gz
Included feedback from Paul regarding kolab.org usage & KEP tagging for server side releases, as well as revision-specific linking that came out of discussion.
Diffstat (limited to 'KEP-0001.txt')
-rw-r--r--KEP-0001.txt12
1 files changed, 9 insertions, 3 deletions
diff --git a/KEP-0001.txt b/KEP-0001.txt
index 5a3fa0d..56d484a 100644
--- a/KEP-0001.txt
+++ b/KEP-0001.txt
@@ -21,6 +21,8 @@ Some of the most important benefits of the KEPs are to (a) require ideas to be f
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].
+{{note|The GIT repository and secretariat list will be moved to the kolab.org infrastructure once the infrastructure reworking is complete.}}
+
== KEP Types ==
There are four kinds of KEP:
@@ -61,7 +63,7 @@ The life cycle of a KEP is
** For opposition to be procedurally qualified, it should be based on procedural questions and concerns, as well as accompanied by an improvement proposal.
* As the drafting continues, the author(s) will continue to work in feedback, bringing the document to a consensus opinion, providing updated drafts through wiki.kolab.org, as sensible, helpful and appropriate to facilitate good and timely consensus building.
* KEPs are adopted by consensus in the form of lack of sustained, qualified opposition.
-* When a KEP has been thoroughly discussed, either on public list before it has become formalized, or in its drafting stage, the secretariat should then issue a "closing call" for the KEP, stating the deadline by which it will be considered adopted. This deadline should be
+* When a KEP has been thoroughly discussed, either on public list before it has become formalized, or in its drafting stage, the secretariat should then issue a "closing call" for the KEP pointing to the version to be accepted as a '''revision-specific link''' and 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.
* When the closing call is issued, the KEP should be moved into the authoritative name space on wiki.kolab.org/KEP:<NUMBER> and while the authors can continue to work on the version in git, updates of the authoritative version should now go through the secretariat.
@@ -82,10 +84,10 @@ The life cycle of a KEP is
=== Implementation & Followup ===
-* Once a KEP has been accepted, an issue shall be created in the public Kolab Systems issue tracker instance for this KEP, linking to the official KEP location, as well as containing the abstract and the likely affected components.
+* Once a KEP has been accepted, an issue shall be created in the public Kolab Systems issue tracker instance for this KEP, linking to the official KEP location '''as a revision-specific link''', as well as containing the abstract and the likely affected components.
* All likely affected Authoritative Component Contacts shall be added to the recipient list of this issue to ensure they receive the information about the KEP and can incorporate it into their workflow accordingly.
* The issue is then split for the various issues for components that are tracked on the Kolab Systems issue tracker.
-* The issues shall then be normally resolved, and be re-opened upon potential modification of the KEP.
+* The issues shall then be normally resolved, and be re-opened upon potential modification of the KEP, again pointing to the new version as a revision-specific link.
== The Secretariat ==
@@ -95,6 +97,10 @@ The life cycle of a KEP is
* '''Authoritative Component Contact''': As the Kolab Groupware Solution incorporates many technologies and integrates with many up- and downstream projects, a Design or Technology KEP can likely result in changes to various components, which often will have their own issue tracking, each of which might see changes in multiple components. So one KEP could easily lead to multiple tickets in several issue trackers. In order to ensure that all affected components receive information regarding KEPs that are likely to affect them, all components shall have designated contact addresses (either individuals or mailing lists) that should receive information about relevant KEPs.
+== KEPs and the Server Release Process ==
+
+* The accepted and latest draft versions of all KEPs shall be tagged with each release of the server of the Kolab Groupware Solution, documenting which state of the KEPs has gone into a certain release, and forming part of the documentation of the Kolab Groupware Server.
+
== References ==
{{Reflist}}