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

["Stephen J. Turnbull" <stephen@xemacs.org>]

Karl Fogel writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:

 > >I suspect a careful study would substantiate [the] anecdotes
 > >[presented in an earlier post].  For the documentation format, the
 > >core members of the project clearly consider the existing Texinfo
 > >manuals to be a dequate (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.

"Can", yes.  Does, I dunno.  The high-quality large contributions I
know in some detail were mostly done "speculatively", because there
was a need in the software -- not because there was demand from the
project.[1]  If you want control over integration, you typically need
to either become trusted core, or you need to fork.  Especially in
Emacs.  Little has changed here since the 1980s in that respect.

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

That's a poor example, IMO.  There's clearly no consensus, and there
won't be one because the core really does prefer the email-based
workflow.  No?  As I see it, anyway, here there's only one choice:
build the damn mousetrap, and *show* the core that it catches mice
without bruising their fingernails.  If *you* don't have faith the
mousetrap will be enough better, then it probably isn't enough better.

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

I'm with Fred Brooks: build one to throw away.  "You will, anyway."
Cf. Eric -- he didn't throw just one repo away, he junked one every
couple days for a few weeks.

 > I believe that in other projects the lever is in the latter
 > position rather more often (than it is in Emacs), and consequently
 > people are more motivated to work on those things -- because they
 > feel there is less chance their work will be rejected in the end.

But there's a good reason for that: few projects are as old as Emacs,
few works are of the quality of Emacs.  *Many* of the projects are
brand new; anything is better than nothing.  (That's not entirely
true; one of my GSoC projects was mandated by the org to use Podio for
workflow.  Nothing is *definitely* better than vanilla Podio.  But I
digress.)  Very few are as solid, or have as well-established
traditions and workflows, as does Emacs.

Python is very similar to Emacs in terms of age and solidity, and
there is a lunatic fringe there advocating random changes.[2]  But
real progress on anything like workflow changes in Python takes at
least as much time as in Emacs, multiple Python Enhancement Proposals,
often discussion at one, sometimes two of the annual Language Summits,
and often multiple demonstration implementations.  But (aside from the
aforementioned fringe) nobody there thinks this process unnatural.

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

I concede that you know your mind better than I do.  But given that
you *did* "write the book", I at least have trouble distinguishing
your "I wish"es from your "You should"s.  If you see what I mean. :-)

Anyway, I apologize and will work on my own temper in the New Year.
Happy Holidays to you and all the denizens of emacs-devel!


Footnotes: 
[1]  "In the software" is not a great expression -- as I see it, this
applies to infrastructure projects too (especially things like repo
mirrors in a different VCS, but including trackers and testing
infrastructure), but the wording is poor for that.  Even the tracker
to some extent, although that (and mailing lists) are pretty much the
most un-decentralizable aspects.

[2]  I don't consider any of the people currently advocating radical
changes for Emacs to be lunatics at all.  The culture is very
different from Python.