[OpenISO] Disagreement resolution process (was Re: Core G..)

[Norbert Bollow]

Henrik Sundberg <storangen at gmail.com> wrote:

> 2007/9/10, Norbert Bollow <nb at bollow.ch>:
> > Regarding specifications which do not satisfy the criteria for
> > approval as a standard, OpenISO.org evaluates only concerns about
> > issues which are in themselves serious enough to justify (if the
> > concern is found to be valid) refusal of approval as a standard.
> 
> I like this. It means that we don't need hundreds of comments for
> OOXML. We just need a few main reasons.

Yes (comment-bombing strategies should not be needed in OpenISO.org
since we'll formulate the approval criteria so that the real reasons
for not wanting to approve something will not get excluded from
discussion on precedural grounds), although in the specific case of
OOXML, I expect that already the "main reasons" will turn out to be
more than just "a few". :-)

> If these are fixed there will be a bigger effort to see if the
> proposal is good enough.

One thing I don't like about all the attention that technical details
of MS-OOXML are getting is that fixing those details merely has the
effect of giving Microsoft a better anti-competitive standards-war
weapon to use against the existing, genuinely-open document format
standard (ODF).

> > ## Decision-making Processes and Requirements ##
> > Therefore, OpenISO.org adopts the rule that all disgreements which
> > cannot be resolved by means of Working-Group consensus processes must
> > be addressed by means of an independent, professional evaluation of
> > the relevant facts.
> 
> But who are better than the group members to do this evaluation?

This is in reference to situations in which the Working-Group process
has failed to successfully make this evaluation in regard to a
particular question.  This possibility needs to be addressed somehow,
unless someone is able to propose a way in which a Working-Group
process can be organized so that that is guaranteed to never happen.

> Isn't it just like invalidating the working group and start a new one?

No, not at all.  The external mediator would only evaluate the
arguments of the protagonists to determine which of the arguments
(if any) are valid in a fact-oriented, scientific sense, so that
the disagreement is resolved and ceases to block the affected
Working-Group from being able to publish its findings.

Nota bene, the level of expertise which is required for being able
to reliably evaluate a proposed argument with regard to its validity
is significantly lower than the level of expertise which is required
for figuring out what should be said about a question and supplying
a valid argument.

I'm confident that it will be possible to find the level of expertise
which is required for validity-checking arguments not only within the
Working-Group but also outside of it.

Let me emphasize that the goal of this rule is not at all to
disempower Working-Groups from being able to resolve disagreements
among themselves by means of fact-oriented discussion, but rather
the goal of the rule to give Working-Group members a strong incentive
to admit it when an argument that they have proposed is invalidated
by a valid counterargument.

Therefore, I hope that the effect of having this rule will be to
greatly reduce the frequency of the kind of situations in which it
would need to be invoked.

(I'll update the Core Guidelines draft by including the above
clarifications.)

> > If it turns out that there are several justifiable viewpoints, the
> > proponents of the various possible approaches can all get their
> > preferred solutions equally endorsed by OpenISO.org provided that the
> > openness and maturity requirements are fulfilled.
> 
> Doesn't this mean that the standards will contain parts that do the
> same thing? And increase the cost of implementing the standard?

Nonono.... if the text under consideration is a draft standard, what
that rule intends is to tell them: "If you can't reach agreement on
factual grounds, you have the freedom to fork, and OpenISO.org will
not pick sides if both groups manage to produce a specification which
satisfies the openness and maturity requirements."  If however the
document under consideration is a review of a specification (let's say
MS-OOXML) and one group wants to have "you can use ODF instead" in the
review, and another group wants a recommendation for another
alternative, then both alternatives will get equally recommended if
and only if they both fulfil the OpenISO.org openness and maturity
requirements.

(I'll update the Core Guidelines draft by including the above
clarifications.)

Greetings,
Norbert.


-- 
Norbert Bollow <nb at bollow.ch>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org