QT4CG “Charter and process” proposal

Hi folks,

In the agenda I just published, I proposed that we might want to
consider adopting a more up-to-date charter and process. I don’t know
what the official route would be for changing the W3C community group
page’s charter, and I don’t think there is a process document for
community groups.

But, informally if not formally, I think we would all benefit from
having some ground rules in place. Mike and I chatted about it a little
bit, and here’s something to consider as a starting point.

QT4 CG Charter and process

The group 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) 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 forums together with weekly conference calls. Formal progress will
be made through minuted decisions made at the weekly conference calls.

The general modus operandi of the group will be 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 clear consensus to do otherwise.

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

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

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

+ 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

--
Norman Tovey-Walsh <ndw@nwalsh.com>
https://nwalsh.com/

> The reason lightning doesn't strike twice in the same place is that the
> same place isn't there the second time.--Willie Tyler