summaryrefslogtreecommitdiff
path: root/KEP-0001.txt
diff options
context:
space:
mode:
authorGeorg Greve <greve@katana.(none)>2010-11-22 16:26:03 (GMT)
committerGeorg Greve <greve@katana.(none)>2010-11-22 16:26:03 (GMT)
commit133dd988a341de660fac397d81a41eb785ad2fbe (patch)
treea9c706a3d8885d59212570445579eb7034252936 /KEP-0001.txt
parent9671102dbaf9b8d64930e5aa3054a6be41f5f479 (diff)
downloadkeps-133dd988a341de660fac397d81a41eb785ad2fbe.tar.gz
Added Authoritative Component Contact concept, as well as issue tracking methodology, after discussion with Jeroen & Christoph
Diffstat (limited to 'KEP-0001.txt')
-rw-r--r--KEP-0001.txt17
1 files changed, 13 insertions, 4 deletions
diff --git a/KEP-0001.txt b/KEP-0001.txt
index 8f68025..5a3fa0d 100644
--- a/KEP-0001.txt
+++ b/KEP-0001.txt
@@ -65,8 +65,8 @@ The life cycle of a KEP is
** '''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.
-* The closing call should go to the canonical discussion mailing list, as well as all public mailing list that seem sensible and relevant. kolab-devel@kolab.org shall always be informed.
-* 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.
+* The closing call should go to the canonical discussion mailing list, as well as all public mailing list that seem sensible and relevant and all likely affected Authoritative Component Contacts (see below). kolab-devel@kolab.org shall always be informed.
+* In reaction to the closing call, any member of the Kolab community or of affected components 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 ===
@@ -80,11 +80,20 @@ The life cycle of a KEP is
* If a KEP is no longer relevant to Kolab, the secretariat shall send a note of 'pending retirement' to the canonical mailing list on which it was discussed, as well as kolab-devel@kolab.org (if not identical) 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'.
+=== 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.
+* 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 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.
+* The secretariat should 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.
+
+* In absence of volunteers who are not themselves active authors or participating in the discussions, it shall deemed acceptable to have author participate in the secretariat. In no case shall an active author of a KEP perform the secretariat duties for their own KEP in question.
-In absence of volunteers who are not themselves active authors or participating in the discussions, it shall deemed acceptable to have author participate in the secretariat. In no case shall an active author of a KEP perform the secretariat duties for their own KEP in question.
+* '''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.
== References ==