a self debriefing

[Tom Albers]

At Monday 08 September 2008 20:25, you wrote:
> once the 4.2 schedule decision is worked out, i think it would be really good 
> to sit back and ask some questions. this may simply re-affirm what we are doing
>  
> or it may indicate need for changes. either way, having a conscious awareness 
> of how we are doing is undeniably better than simply making it up as we go 
> along.
> 
> some questions i'd suggest asking ourselves (please add your own as well):
> 
> * what has the 6 month cycle won us in terms of real benefit thus far?

Well, the counter question is, have we proven ourselfes enough so other parties will depend on it. I think not. Even before the first cycle was completed there were already votes to change the schedule (yeah, that was you ;-)). 
If I was a project that was looking at if it would be possible to depend on KDE's planning, I would be scared away immediatly. And to take a bit of blame myself: the 4.2 shifting thing would have been a confirmation of that conclusion.
So for people to trust our planning, we need to prove it first, that has not happened and that need 2-4 years more. Untill that I don't think we will get any benefit from it, other than clearity for users and devels.
 
> * are we getting the return in commitment promised from third parties due to 
> the discipline of a 6 month cycle, or do we need to re-assess that with them?

Already answered mostly. But querying the likely subjects would be a good idea.

> * how long before we can disentable the development cycle from it, ala Dirk 
> and Sebastian's presentation at Akademy '08?
>
> * if that disentanglement will take more than a year, how do we deal with 
> aligning our development with Qt? (our most critical and quickly evolving 
> component)

No ideas.

> * under what circumstances should we allow ourselves to alter the plan for the 
> cycle we are currently in at the time?

It is of course a matter of judging weights. If we would have external projects depending on our cycles, we would consider their position, but as long as we don't have any, we are tempted to not be to firm in keeping to the dates, which of course leads to doubts at those considering to depend on the cycle. So - and i can not stress this to much -, get a schedule and stick to it for ~5 releases, and then evaluate.

> * how do we define "useful predictability"? is it knowing that the goal in N 
> cycles from now will be 6 months, or is it more important to know with 
> certainty what the next 2-3 releases will actually be?
> 
> * are application developers being well served by the amount and form of 
> communication thus far?

no
 
> * are the libraries being well served by the amount and form of communication 
> thus far?

no
 
> overall, i think the release team is doing a very good job. the above 
> questions are not an indictment or a measure of distrust in the process. they 
> are, rather, out of respect for what is working and a desire to see this team 
> remain a healthy and well-oiled machine.

Allen's conclusions are spot on. We need to improve communication. But also the discussion in this room. The change to the 4.2 schedule was announced pretty clear on this mailinglist, but got no feedback at all. After posting to k-c-d there was so much resistance that we needed to revert. That simply implies this list failed and that we need to think why that happened. And to be honest, I don't want to repeat that ever in the future. I've got no answers how we can improve that though.

And, to make it personal: I would like to know what I should have done differently to prevent this, but I've found no answer yet by talking to myself.

Toma