Lists - please read

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Dear TC members,

first of all I would like to ask for your apologies for this rather long 
mail, but I think the complexity of this topics requires this. This mail 
contains a proposal how to proceed. If you are interested in only that, 
you may skip this mail until you find a heading that indicates the start 
of this proposal.

As discussed in the last con call, a discussion about backward 
compatibility guidelines has been started. I think this is very helpful. 
We should continue this discussion, but I suggest to exclude all list 
related questions from this discussion, because these guidelines have a 
validity not only for lists. I will put the backward compatibility topic 
on the agenda of our call for Monday. Maybe we are able to agree on 
something in the call, but I think this is not essential for continuing 
the list discussions.

The backwards compatibility guidelines will be helpful in our list 
discussions, because they will provide the authors of the list proposals 
with information what is requested by the TC (or individual TC members), 
and they will provide all others with some guidelines that may have to 
be considered than analyzing the proposals. However, I don't think that 
the guidelines alone will be sufficient to come to an unambiguous 
conclusion whether a certain proposal would be acceptable.

One other issue we have is that the two proposals we have currently are 
very different in the style they are written, and in the style how they 
are explained. This makes it actually very difficult to compare them 
without doing a very deep analysis of the two proposals. That's 
something we need to address, too. Unfortunately, we have not much time 
left to come to a conclusion, and we will not have a TC call between the 
2nd, and the 23th of April. For this reason, I suggest that we do not 
wait until we have backward compatibility guidelines before addressing 
this issue, but to work on these two tasks in parallel. More precisely, 
I would like to propose the following roadmap for our discussions:

Roadmap Proposal
----------------

We reset our discussions, meaning that we assume that no proposals have 
been submitted to the TC. We further continue our discussions about 
backward compatibility. The authors of the list proposals are asked to 
follow these discussions closely, and shall based on these discussions 
decide until April, the 5th COB, whether they want to submit a proposal 
to the TC.

If a TC member wants to submit a proposal, then this proposal must meet 
the following formal requirements:
1. It must be submitted the the TC's document repository so that it can 
be easily and unambiguously located.
2. It must contain the literal text that should be added to the 
specification, and also the text that should be removed. In other words, 
it must be identifiable what exactly is changed in the specification, 
and what will be the resulting text if the proposals gets accepted.
3. Explanatory text must be differentiable from the proposed text for 
the specification. In other words, it must be identifiable what text is 
added to the specification, and what text is only explanatory.
4. Where possible, the changes should be explained by examples that show 
what ODF does (or does not) allow now and how the proposal would change 
that.

Proposals must be submitted to the TC until April, the 5th COB, which 
means it has to be worked on them in parallel to the backward 
compatibility guidelines. That's not the best situation, but I think our 
schedule does not allow another solution if we want to have some buffer 
time, which I think we should have.

After the proposals have been submitted, and if we get multiple 
proposals, then the proposers get a chance to prepare an analysis of how 
they think their proposal differs from the other proposal technically 
and why. This should be a single document. The aim of this analysis 
shall not be to advertise the own proposal, but to explain to the TC 
members what the differences between the proposal are, and to figure out 
whether the two proposals maybe could be combined, what of cause still 
would be the best solution. The due date for this is Friday, April the 
13th COB.

If we still have two proposals, then the proposers should get a chance 
to comment the analysis. This again should be a single document. Due 
date for this is Wednesday, April the 18th COB.

In the TC call at April the 23th, we may either vote on the proposal(s), 
or agree to conduct an e-mail ballot. To give everyone a fair chance to 
follow the discussions, a discussion of the list topic that goes beyond 
the preparation of document's mentioned should be avoided.

If a TC member cannot meet one of the due date but wishes to submit a 
document to the TC, then she or he should inform the TC as soon as 
possible, but in any case before the due date. This information should 
contain the date until the document will be submitted.

We stay with this plan and schedule/roadmap, except that the TC formally 
makes some other decision.

I would like to propose that we formally agree on this procedure in our 
con call on Monday.

Best regards

Michael
-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering