Re: [oiic-formation-discuss] TC formation proposal.

["Peter Dolding" <oiaohm@gmail.com>]

The added 12 deals with my major issue.  Back talk is required.  I
would change the "A report"  bit.  We really need to up stream them as
soon as we have them proven to be processed by the TC at next meeting
or main TC mailing list in case they are really quick to resolve.
Reports instead of a report.  With formal meeting reports ordered in
most critical to least.

On Tue, Jul 22, 2008 at 5:50 PM, Dave Pawson <dave.pawson@gmail.com> wrote:
>> Having software forbin in charter as well also hamstrings.
>
> The charter says the TC will not produce software.
> As a test implementer, any TC member is quite free to use
> the output of the TC to write software?
> Just that software will not be a main deliverable of the TC!
> The TC needs to produce good test specifications so that
> a test writer can use them.

That is the point that is not clear.  Current wording any TC member
could risk being picked on over creating automated or other forms of
test suits.

Test implementers bit needs to be made clear as part of there job of
testing applications they might be coding automated tools.  They will
not be setting out to code applications to directly compete with
implementers work only to assist and speed up testing of applications.

Now down to implementers tools and end user testing(acid test).

All implementers tools goal is a complete test of all parts of current
standard seeking to provide a detailed display of pass failure or
other wise.   Clear report output ed with references to standard for
all failures.

end user testing(acid test) Normally something with percentage or a
graphic displayed to user with the means to access deeper to get the
developer information.  This is also for speed targeted as the worst
causes of incompatibly existing.  Less detailed coverage equals lot
shorter time to complete the test.  Due to acid tests being simple to
use we could ask everyone to like visit the TC site download the test
and post a report back.  As a form of random sampling.  Even doing it
as like a slashdot thing.  Where a full test suit does not work.

These are the two groups of standard testing systems.  Both most
likely can be put under a better title.

13. Start Collecting Test Suite/s Targeting implementers and End Users
to acquire information on the implementation status of ODF from
different existing test writers.

Collection of created ODF test suite's really need to start of the get
go.  No point have new test writen if existing ones are up to snuff.

Ok wording of 13 might need another rework.  We don't need any
developed test cases disappearing into the mail list or anywhere else
to be lost for ever.  Building the complete test system is going to be
enough work once.

I guess this will be altered one we are up and running.  Or there will
be defined side allowances in the charter.  Remember you have to read
the charter and remember if a implementer can use it as a sledgehammer
to stop us from saying there implementation is crap they will.   Ie
that is outside the charter of what you should be doing.

Its the reason why I am reacting so bad to when people say if its not
in the spec its not our problem.   It is our problem.  We are to check
that implementations are compatible anything that stuffs with that is
our issue.   If its not we are a defanged watch dog unable to do our
job to protect the standard from going the way of RTF and other failed
attempts.  The charter has to protect the right to investigate.

They are a lot harder to write than a lot of people think.  Yes they
have to restrict but they have to clearly allow anything you many need
to do.  Even if you never do it.

Peter Dolding

PS I hate writing charters all the looking over shoulder you have to do.