Re: QT4CG “Charter and process” proposal

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

For me, personally, that is a *really* inconvenient way to make
comments. (I appreciate that if you live in the Microsoft ecosystem and
do everything in Word with SharePoint, it may be the greatest thing
since sliced bread. I don’t.)

Below, please find may attempt to present Dimitre’s questions. Apologies
if I messed any of it up.

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

DN: Shouldn’t the XDM (XQuery and XPath Data Model) also be mentioned?

Yes, I wasn’t trying to be exhaustive, but I probably should have been.

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

DN: When should we expect the minutes for a weekly conference call to be
    published?

As soon as practical. The aim, I think, should be to get them out
shortly after the call. And for agendas to be published at least 24
hours in advance.

| 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

DN: We need a clear definition of “consensus” (all, 66%, 50%+, or …) Do
we know the total number of group members and will this total number be
used in defining “consensus” or just the number of the actual
participants in a specific conference call?

As I said in the other reply, I actually don’t think nailing down
specific percentages is the best plan. 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.

If we start arguing about whether 6 people or 7 constitute consensus, we
probably don’t have 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.

DN: Could you, please, define well-defined

Informally, I think a proposal is well-defined if it’s clear (most
technical readers understand it) and complete (no technical readers
immediately identify unanswered or unanswerable questions). If a
proposal will require changes to several specifications, one aspect of
being well defined, to my mind, is that it has tracked the changes
across all the specifications involved to some level of detail.

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

DN: Could you, please, define “clear consensus”

See above and my other reply.

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

I think we’re all here to help improve the specifications and help the
community. On the one hand, I understand the point your making. On the
other hand, I don’t know exactly what to do about actual facts that I
can’t change.

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

I don’t think the paragraph you’re referring to says we can’t or won’t
make changes. It says that we should strongly favor backwards
compatibility. I think Mike made the point last week that changes to the
Data Model have a much, much greater knock-on effect than, for example,
adding a new function.

I think it would be nice if we could finish V.next in a year or two
rather than 10 or 15. I’m (personally) in favor of keeping a narrow(ish)
scope in order to achieve that.

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

I think “not sufficiently complete” is roughly analagous to “well
defined”. See above.

| + The editor will as soon as practicable after each meeting update the
|   draft specifications on GitHub and republish them, with change
|   markings.

DN: Could this text be added: “and the editor will notify all group
members as soon as any new such changes have been made”?

Sure. I mean, trust me, as an editor, I want folks to know when I’ve
made changes. Note also that it’s possible to subscribe to repositories
and issues at GitHub so you can be automatically notified of all changes.

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica