Re: Have you all gone crazy? Was: On being web-friendly and why info must die

[Stephen J. Turnbull]

Phillip Lord writes:

 > If Eric is trying to stir things up a bit, that is surely not a bad
 > thing.

"Double, double, toil and trouble!  Fire, burn, and cauldron, bubble!"
you mean?

Eric is stirring up nothing but trouble with his intemperate
vituperations.  Karl is a little more circumspect, but he is also
going to fail.  Of all free software philosophers, even more so than
RMS, *those two* should be well aware of the distinction between the
*software* and the *project*.  A work of free software is the world's,
'tis true, but nary a project be that be not "owned" by its
participants.

The right way to stir things up is to appeal to the choir, not to the
tourists gawking at the icons in the back of the hall.  The criterion
for appeal of a new documentation format is clear: present a proof of
concept translation of a "representative" Emacs manual[1] to the new
source format, along with built manuals in the target format(s) and
any tools needed to implement the desired navigation features.  The
cost is high, but experience shows that worthwhile moves usually have
redundant costs being paid.

For example, I've observed 6 VCS transitions closely.  In 3 cases
(including the current move of Emacs to git), the choice was based on
consensus of the involved developers, and only one conversion was done
(but note that Eric's conversion was not based on one of the existing
git mirrors, and was done a couple dozen times I guess).  In the other
3 cases, multiple repos were presented for consideration -- a lot of
redundant effort from one point of view.

In other cases (3 cases of issue tracker introduction), it was
universally agreed that "some" was better than "none".  In two cases,
projects just took the first thing that had a volunteer to implement
and run the tracker.  In the case of Emacs, however, there was a
strong demand that the existing email-centric workflow be extended,
and the only candidate with a proof-of-concept implementation that
satisfied that requirement was the current debbugs tracker.  That
despite protests that Bugzilla, Roundup, Trac, etc "can be" configured
to be controlled by email.  But no implementation was presented, and
debbugs won by default.

I suspect a careful study would substantiate such anecdotes.  For the
documentation format, the core members of the project clearly consider
the existing Texinfo manuals to be adequate (and often, excellent).
So there's no hurry to produce a proof of concept -- but I would say
one is necessary, and the cost is not exorbitant according to common
practice.


Footnotes: 
[1]  It needs to be an Emacs manual for ease of comparison.  I don't
think any of the naysayers would feel comfortable switching from
Texinfo based on the now out-of-date org-mode manual translation, for
example.