Re: QT4CG “Charter and process” proposal

Norm Tovey-Walsh <norm@saxonica.com> writes:

> Dimitre Novatchev <dnovatchev@gmail.com> writes:
>> Just a few questions in the attached Word document.

A few comments on some of the questions and answers.

> ...
> DN: We need a clear definition of “consensus” ...

> ... My suggestion in my other reply
> was that we probably haven’t achieved consensus if more than one person
> is strongly objecting to a resolution.

> ...
> | + Specifications without implementations have no value. Therefore,
> |   while everyone gets a voice in putting forward ideas, the group will
> |   not accept proposals if implementors raise strong objections.
>
> DN: We must have a set of implementors pre-defined and well-known. If
> there is only one (major) implementor, for example, such as Saxonica,
> doesn’t this rule then give to this single implementor an absolute
> monopoly of overruling and forcing choices, and doesn’t then the group
> activity work solely for the benefit of this single implementor?

If I understand the situation, some of the changes we expect to consider
will affect XPath, the XPath Data Model, and the XPath functions
library.  For those specs, we have multiple implementors in the group.

And if I understand the phrase "the group will not accept proposals if
implementors raise strong objections", it amounts to saying that any
implementor has an effective veto.

Taken together, the principles that (1) consensus is reached only if
there is at most one strong objection to a proposal and (2) we won't
accept proposals if any implementors strongly object, will have the
effect that any implementor, and any two non-implementors, can block
consensus.  There is some risk of bad feeling in the group if
non-implementors feel undervalued (at the ratio of 2:1) as a result, and
I both hope and expect that implementors will be mindful of the implicit
responsibility placed on them by the second rule.

But if as a group we agree that implementations are essential to
success, then we can either give that agreement some visible force
within the group's work, or we can leave it as a vague but toothless
aspiration.

In practice, I think the effect is likely to be nil, for the simple
reason that if a non-implementor thinks an idea is a good one but learns
that one or more implementors is strongly opposed to it, in my
experience the non-implementor is likely to moderate their enthusiasm
for the idea and ask why the implementors are opposed.  If they have
good reasons and explain them, it seems unlikely that they will fail to
persuade at least one non-implementor to share their reservations about
the idea.  

> | + There is a strong presumption in favour of retaining backwards
> |   compatibility. Incompatible changes will only be made for "edge
> |   cases", and only if there is clear evidence that the existing
> |   specifications cause serious problems for users or implementors.
>
> DN: This is too restrictive. Shouldn’t we allow DM changes that are
> extending the current DM without any contradictions to the existing DM?

Unless I have misunderstood the terminology, extensions to the existing
data model that would not break existing code would not count as
breaking backwards compatibility.  (They might break forwards
compatibility, but I take the "backwards" here to be non-vacuous.  For
what it's worth, I suspect I am not the only CG member who would be
nervous at forward incompatibility, too, and would want a lot a
persuading before I agreed it would be a good idea.)

> | + Proposals for new features, at the time they are put forward for a
> |   formal decision, must be sufficiently complete in their technical
> |   detail that adding the new features to the specification is an
> |   editorial process that does not require making technical choices.
>
> DN: Could someone, please, define “not sufficiently complete”

For what it's worth, my personal standard is simple:  the group decision
should settle all substantive questions, and no one who understood the
group's decision should be surprised by anything that turns up in the
spec prose, once the editors have finished their work.

In practice, I think groups can usually reach consensus on whether
something is complete in this sense or not.  And in practice, I think
they are usually correct.  But because we are humans and we are using
natural languages to reach our agreement, it can happen that the group
is wrong, and different people have different understandings of what
they are agreeing to.  (For that reason, in the XML Schema WG the
editors were instructed to return to the group with a change proposal
with the new wording for the spec, and issues were not closed until that
proposal was adopted.  I would favor that here, too -- I alway favor it
-- but I suspect that many people find such a procedure too
bureaucratic, so I am reluctant to propose it.)

Michael


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Monday, 12 September 2022 19:07:21 UTC