How to conclude KEP2 for good

Bernhard Reiter bernhard at intevation.de
Mon Apr 4 14:45:12 CEST 2011


Friends of the Kolab Format,

the last two weeks have shown that the pure mailing list approach is not 
bringing us close to getting a KEP 2 that is fully understood by everyone 
and allows those who came later to the discussion to understand the rationale 
behind all the design decisions.

Replying to one important paragraph of Florian's email [1]:

Am Montag, 4. April 2011 10:50:22 schrieb Florian v. Samson:
> I have the impression many of the other subscribers of this mailing-list
> are tired of the whole ongoing KEP2 discussion, even though at least you,
> Bernhard, Jeroen and I seem to agree, that properties and implications of
> each proposed solution must be very well understood,

This is my observation as well, and even we four are 
somewhat too entrenched in too long emails. As for the others:
We have probably lost you, over this!
This should not have happened. :(

Georg and I have been talking how we can improve the process and achieve a 
conclusion in a timely manner so we can implement it as soon as possible. In 
principle we believe the idea of a consensus based process for KEPs is okay, 
but in this case the complexity seems to lead us in circles.

So how can we do what Florian also suggests?:

>  I believe a transparent compilation of
> 
> technical and behavioural pros and cons in KEP2 for each proposed
> solution is crucial, so people not following the discussion closely
> (anymore) are still able to form a substantiated opinion without
> retracing the whole discussion

Our proposal is to start a new wiki page with to try and summarize the missing
argumentation lines and suggest a solution with the rest as a design decision 
on which there will be a short feedback period which will then hopefully allow 
us to shorten the KEP to only the relevant points.

I volunteer to start,  taking Florian's nice email summary parts from [1] and 
bulding on the results of Georg's KEP2 draft to briefly document the main 
lines of arguments. Starting with the three discussion topics I've suggested 
here in [2]. Give me time until tomorrow. Then maybe the few people deeply 
into the topic can add arguments in the wiki and have a new joined suggestion 
until the end of the week.

Ideally we find the overview again, 
re-connect with the people that have less time to look into the details 
and get a KEP2 done timely.
 
Best,
Bernhard

[1] http://kolab.org/pipermail/kolab-format/2011-April/001317.html
  Datum: Montag, 4. April 2011"
  "Betreff: Re: A summary of sorts (was: Re: Why and when storing local
  time? (Re: Basic rationale of the KEP #2 design))
 

[2] http://kolab.org/pipermail/kolab-format/2011-April/001309.html
  Datum: Freitag, 1. April 2011
  Betreff: Re: Rationale of the KEP2 design: central in-format TZ-data vs.      
  individual local TZ-databases and more (Part 2)
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110404/6e685638/attachment.sig>


More information about the format mailing list