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

[Karl Fogel <kfogel@red-bean.com>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>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.

Spot on, IMHO.  Another way to look at it:

Sometimes one can get a consensus that a transition would probably be a good idea, *in advance* of anyone doing the sample transition work.  That advance consensus can then help motivate people to work on the change, because they have confidence that their work will eventually be used for the real transition.  E.g., if there were broad consensus that a Web-based bug tracker (with APIs and email controllability) would *probably* be a good thing to move to from Debbugs, then someone might be more willing to work on it.

What a critical mass of Emacs developers currently express is a slightly different stance, though: "Debbugs is good enough until someone comes along and shows a concrete implementation of something else that is unequivocally better."  So now if someone's going to do all that work to demonstrate a different system, they're doing it under a much greater risk that their work will end up being wasted.  The lever can be on one of two settings: "We stay here until something clearly better is shown" vs "We'd probably like to change, unless we unexpectedly discover that there's nowhere better to go."  For many parts of the Emacs project, the lever is in the former position.  I believe that in other projects the lever is in the latter position rather more often (than it is in Emacs), and consequent
 ly people are more motivated to work on those things -- because they feel there is less chance their work will be rejected in the end.

Stephen, FWIW I don't think I was displaying any confusion between the software and the project (as per your first paragraph) :-).  I'm quite aware of what it would take here, and merely regret that I don't, alas, have time right now to work on these things in a way that would be effective for the Emacs project.

Best,
-K