Re: [oiic-formation-discuss] Feedback to the ODF TC

["Dave Pawson" <dave.pawson@gmail.com>]

Re main TC feedback as a deliverable.

2008/6/22 jose lorenzo <hozelda@yahoo.com>:

>> This is why the TC needs to be able to feed these examples
>> back to the
>> main TC for cleanup.
>> This should be a deliverable.
>>
>
> We begin to build up a list of all anticipated issues with ODF (eg) 1.1. We categorize the problems if necessary. We optionally suggest solutions for each such item. We let the ODF TC know of the growing list. Formally, this TC (once the TC is created and the first draft of the list is finished) presents the list to the main TC at some point (this would be the first installment of a batch of related deliverables).
>
> The ODF TC would have been keeping up and so can possibly resolve most issues quickly once presented with this official gripe list. They then let us know of their growing list of resolutions. We work off that unofficial list. Eventually, they return a full official reply, most of which should not be a surprise to us.


I'd like the formal deliverable to be a list of issues re testability Jose.
Rationale.
1. It's a deliverable from one TC to another.
2. It should (Oasis view) call for some reaction.
3. We are in a good position if the main TC doesn't respond.

I'm less sure about 'how to fix it'. *suggestions* possibly, but that
is getting close to treading on toes?

I do like the unofficial contact too.



> The point is to have everyone be aware of the build-up of problems/solutions

+1


> Once such a list is started (unofficially Dave already started or added to it), we will be able to see what else we may do or if to tweak the process.

(In line with the TCs required deliverables and scope)

>
> Another issue is how to achieve consensus over what goes on the official list. One approach is to have anyone present their items for the list and have each be considered individually (or in batches since multiple issues with potential fixes could be inter-related).


Good point. Easier to have a clear reason to feed back: I.e. something
against which
to judge an item?
E.g.
* A Sentence, para isn't clear to [3?] or more TC members
* A Sentence isn't testable.
* A para has no requirement yet appears normative
* A para/sentence is informative yet is not marked as such.

This kind of checklist would make it easier to decide whether an item
should be part of the feedback.


> Separately, I think everyone that wants to work on ODF changes should do so and then approach the appropriate TC. OASIS would be foolish to reject really good work that was already done. But if they did, other parties outside OASIS might be interested. These parties might include antitrust authorities, other standards groups, and FOSS projects working on implementations.


<grin/> Oh yes.


regards




-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk