Updated process document

Hello,

Persuant to my action, here is an attempt to incorporate the feedback
that arose from our last discussion of the process document.

Six meetings in, we seem to be functioning smoothly and making good (if,
as always in standards groups, slow) progress. I hope that the initial
drafts of this document were useful in setting us on a positive course.

I don’t propose that we bring this back on the agenda for further
discussion, unless there is demand for it. If no one objects, I’ll find
a place to put it on the qt4cg.org page.

===

The community group (CG) aims to agree to extensions to the XSLT 3.0
Recommendation published on 8 June 2017 and the XQuery and XPath 3.1
Recommendations published on 21 March 2017, along with supporting
changes to the other specifications (XPath, Functions and Operators,
Serialization, etc.) on which these depend.

A preliminary proposal describing requirements for such extensions can
be found in Michael Kay's Proposal for XSLT 4.0 published in the
Proceedings of XML Prague 2020,
https://archive.xmlprague.cz/2020/files/xmlprague-2020-proceedings.pdf#page=121

This has been supplemented by a wide variety of proposed enhancements
which are registered as issues against the GitHub repository,
https://github.com/qt4cg/qtspecs/issues

It is intended that the group will operate through the use of email
and other online communication together with weekly conference calls.
Formal progress will be made through minuted decisions made at the
weekly conference calls. The scribe will publish the minutes as soon
as practical after each meeting.

Our common goal is to define additions and other changes to a family
of specifications. To that end, as described below, we expect that
well-defined proposals for changes will be made and those proposals
will be accepted (or not) according to the consensus of the group. The
terms “well-defined” and “consensus” are open to interpretation. No
attempt is made here to define them precisely. A precise definition is
only necessary if an issue has become acrimonious, at which point,
precision isn’t going to contribute usefully to a mutally acceptable
resolution anyway.

Informally, we could say that a proposal is well-defined if it is
clear and complete if it’s laid out in sufficient detail that an
editor could apply the changes without having to make additional
technical choices. If that’s not a useful metric for some proposals,
one alternative formulation would be that it’s laid out in sufficient
detail that someone could write a comprehensive set of test cases for
the proposal.

Merriam-Webster defines consensus as “general agreement.” We should
strive for unanimity, and work cooperatively towards a mutually
satisfactory solution where it doesn’t exist. It seems likely that if
one or more members are strongly opposed to a change, then it hasn’t
achieved consensus.

Broadly speaking, we expect the group will proceed as follows:

+ Technical debates should be held primarily offline; issues will only
  be placed on the agenda for a group call if (a) there is consensus
  behind a concrete proposal for the group to ratify, or (b) there is
  a clear choice to be made between competing proposals, or between
  making a well defined change or leaving the specification unchanged.

+ The default decision is to preserve the status quo (the existing
  specifications) unless there is a consensus to do otherwise.

+ Specifications without implementations have no value. The group
  should strive to be realistic about costs and benefits. Our focus
  should be on delivering the highest benefit features that are of at
  most moderate cost to specify and implement. We anticipate that
  users will, generally, have a sense of the benefits of a feature and
  implementors will, generally, have a sense of its costs.

+ 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.

+ There is a strong presumption against changes to the data model, on
  the theory that changes to the data model tend to have many knock-on
  effects that can take years to work through.

+ Before accepting a proposal, there must be agreement that it is
  well-defined. It must not leave apparent technical questions
  unanswered. Applying a proposal to the specifications should be an
  editorial process that doesn’t require additional technical
  decisions to be made.

+ The editor will as soon as practicable after each meeting update the
  draft specifications on GitHub and republish them, with change
  markings. Members are expected to check that the specifications have
  been updated correctly and to report any errors found as GitHub
  issues.


                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica