How to conclude KEP2 for good

[Shawn Walker]

I've been following this, but following this is complicated because everybody is having their own
opinion of how this KEP2 should go about.

I think having a list of options in the wiki page of the list of solutions with a clear description
of what each solution is about along with a con and pro about that solution.

But, it will come down to that nobody is going to be 100% satisfied with whatever solution is
selected for KEP2.

Regards,
Shawn

On 4/4/2011 7:45 AM, Bernhard Reiter wrote:
> 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)
> 
> 
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Shawn Walker
Senior Software Developer
swalker at bynari.net
Bynari, Inc.
222 W Las Colinas Blvd, Suite 1320N
Irving, TX  75039
http://www.bynari.net
(800) 241-1086
(214) 350-5772 X29
(214) 352-3530 fax