Re: The specification development process

Norm Tovey-Walsh <ndw@nwalsh.com> writes:

> [[PGP Signed Part:Undecided]]
> Hello,
>
> In issue #536[1], Dimitre comments on our process. ...
>
> I’m taking my chairing hat off here. What follows are my personal
> observations.

Ditto here.

>> Isn't it good to have an agile approach to this project, with goals
>> that are established, agreed upon and understood by everyone, with
>> clear starting documentation and supporting tools, with probably
>> bi-weekly or monthly Sprints with tasks commitments as part of every
>> Sprint?

For what it's worth, I think my answer to DN's question is:  maybe.

In many projects of various kinds I have seen a divide-and-conquer
approach work very nicely.  To produce X, we solve problems A, B, C,
..., H, K, in some order; it will be obvious how to produce X from the
results of those sub-problems.  If there are dependencies among
problems, there can be sequencing constraints; if there are cyclic
dependencies either those working on the project try to do all parts of
the cycle at once (doable if the cycle is small enough) or else all
solutions are treated as tentative until all problems in the cycle have
tentative solutions, and then another trip (or several) around the cycle
is necessary to revise earlier work in light of later decisions --
perhaps some people will think of it as a kind of gradual constraint
relaxation problem, or an instance of simulated annealing.  Sometimes
there will be disagreements over where the dependencies lie, and the
schedule may need adjustment.

In the initial design of XML we started from an inventory over all the
places where a set of existing designed differed from each other or from
the full SGML specification, and the basic divide-and-conquer strategy
was to treat each such disagreement as a dimension in the design space,
and to design the spec by choosing a point on each axis of the space.
As soon as we set a schedule for addressing the design questions, there
were objections from some people in the WG claiming that one topic had
to be treated as logically prior to all others, so we revised the
schedule and took up that topic (character-set issues) first.  (To this
day I do not understand why those WG members thought issues like
retaining or dropping the SGML SHORTTAG feature could not be decided
until after the character-set issues had been resolved, and I lean
towards thinking that they said "character set issues are logically
prior to all others" when the reality was merely that they were more
interested in character-set issues than in the others.  But no great
harm was done in the end.)

If there is a way to organize the work we have to do on QT4 into a set
of identifiable milestones, so as to allow us all to focus better, that
might help us make better progress.  But I don't have the impression
that we are losing a lot of time owing to thrashing and people having to
keep many different things in their heads at once, so I would not expect
a huge speedup.  It might help, psychologically, to give the work a
stronger feeling of coherence (working to a plan, and not just doing one
thing after the other).

So if someone can see a way to organize the work into stages or
milestones or layers or phases, and that organizational plan appeals to
the group as a whole, I am all in favor.  But I don't see a natural set
of phases myself, and I would not like to spend CG time seeking one,
because I don't think it's a sine qua non for progress.  (One
divide-and-conquer technnique is very simple: there are issues.  Close
one issue after another.  When the last issue is closed, you're done.)

And bi-weekly or monthly sprints seem unhelpful to me in this kind of
work.  (In the XML work, we did get some mileage from an early decision
to publish a first draft of the spec at the SGML '96 conference, which
gave us a deadline for a first draft, and about six weeks to work
through the list of design questions we started with.  It then took
another 18 months to get from first draft to Rec.)


> One painful aspect of the process is that there are some issues on which
> *we will not agree*. That’s just the way it is.

Alas, yes.  I do not think any specs are exceptions to this.  Certainly,
none that I have been involved with.

In the development of XML, for example, I think most members of the
group were than once on the verge of leaving the group because we could
not stand the thought of having our names on such a botched spec.  I
repeatedly had to remind myself of the lines in Brecht's play "The
Measure" on the importance of consensus:

  Gehe nicht ohne uns den richtigen Weg
  ohne uns ist er
  der falscheste.

  Do not follow the correct path without us.
  Without us, it is
  the wrong path.

(I translate loosely.)

In the end, no one did actually leave, and I think we were right to
stay, because a spec we all found bearable was more widely useful than
any of the imaginary specs we would individually have preferred.

My two cents, for what they are worth.

Michael

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

Received on Thursday, 15 June 2023 18:54:13 UTC