Re: Metaproblem, part 3

[Stephen J. Turnbull]

Eric S. Raymond writes:
 > Stephen J. Turnbull <address@hidden>:

 > > I see worries about "hostile" environment, and suggestions for
 > > making things more welcoming to new contributors.  I have to ask,
 > > what do all you folks who are suggesting Emacs change its
 > > procedures think is in it for the mentors and core developers?
 > 
 > A future for Emacs.

Nonsense.  Emacs surely has a future (!= "oblivion").  You want a
*different* future for Emacs than the one it's heading toward now.

My question is what is *that* future, and what's in it for the current
crew of developers?

 > I'm trying to get the project moving in a direction that will lower
 > barriers to entry and attract new developers

That would be nice, as long as they are able to contribute at the
level of coherence with existing facilities and the level of quality
demanded of a platform.  It's not obvious to me that the kinds of
changes you're insisting on will attract the kind of developer that
I believe Emacs needs.  OTOH, it might chase some of the ones it has
already into early retirement.

And note well: I'm not sure you meant it the way it sounds, but lower
barriers to entry don't attract entry.  Expected profits do.
Contributing to Emacs *is* like contributing to an OS kernel, or to a
production-quality language translator, or a debugger, or a security
library.  High quality is demanded, and a large fraction of
submissions require substantial rewrites and often design changes to
be acceptable.  That drives the cost for drive-bys way up (not to
mention a bit for the reviewers).

 > because I'm seriously concerned that without such changes Emacs
 > will ossify and dwindle into irrelevance.

I don't see ossification, nor do I expect it, and I'm not sure why you
do.  Nor can irrelevance be remedied by drive-by contributors.

I think you're likely making the same mistake that economic pundits
have made repeatedly concerning the decline of the US economy.  Emacs
development is very resilient, just as American industry has been.[1]

I'll also mention another analogy: note that many of the same business
practices that Japan has made famous have been of no help when grafted
into foreign firms, at least as the Japanese do them.  Sometimes they
were doomed to failure because they required ripping the organization
apart to fit it into the Japanese mold, and in other cases they
required careful adaptation to U.S. and European contexts.

Moral: I see no hurry to fix what could be better, but ain't yet
broke.  "To everything there is a season."  This season was git's.
It's time to rest on your laurels for a while.  Emacs will still be
here when you're again ready for it, and it for you. ;-)

 > There are many things I would rather be doing than having the kinds
 > of arguments this aim will inecitably land me in.

It's hardly inevitable that there be arguments about doing the things
being proposed here.  What makes the arguments inevitable is you want
to do them now, directly changing the current infrastructure (which
necessarily interferes with the work of the core developers), and with
promises of acceptance etc.

Karl wants to put the new "contributor docs" in www/ under source.
Why not create a subproject with a modern workflow (and modern
infrastructure)?  That might not be a good answer in other projects,
but it deserves consideration in Emacs because Emacs has a long
history of successful decentralized subprojects.  Savannah would host
them, I'm sure, in git.  You can use the existing emacs-devel list or
a new list (also GNU-hosted).  I don't know about tracker
infrastructure, but surely between the two of you you can scare up a
proof-of-concept host.

You want to move away from Texinfo.  The issue there IMHO is that all
of the HTML docs (even Sphinx) are beat by Info because (1) the
navigation tools provided are poor and nonstandard except for
hyperlinks (most important), (2) HTML is ugly in Emacs and therefore
requires starting up a browser (hardly agile and changes focus, as
well as affecting my browsing reflexes), and (3) they lack good
indexes (the indicies generated by Texinfo at
https://www.gnu.org/software/emacs/manual/html_node/emacs/ are better
than nothing, but hardly great).  On top of that, conversion of the
doc tree will be a large effort.  Why fix what really ain't broke?
It's not important that your opinion differs from mine -- what matters
is that an awful lot of people agree with me that the only immediately
available direction from the current doc system is *down*.

But OK, reasonable people might say Emacs doc system is broke.  So
port the Elisp manual to your proposed efficient and beautiful source
format, and demonstrate satisfactory navigation tools for several
target formats and an excellent target format that runs in Emacs, and
you'll have a *lot* of support and *much* less resistence.  And guess
what?  You can do this in a separate branch too, and the same
considerations as for the new website apply.  Of course the format
change will make merging changes between the branch and the mainline a
pain in the interim, but if it's not worth that small amount of pain,
I have to question the need for the whole project.

The issue tracker is a different dimension.  There are big gains
possible there, but yes, as somebody complained, *all* of the effort
needs to come from outside the maintainer group -- who are a key
constituency for a tracker.  The maintainers are definitely going to
suffer severe disruption in their time allocation (due to requirements
specification before the switch, and changes in workflow after) and in
their workflow post-switch.

For all of the above, build it and they will come, I'm pretty sure --
your time won't be wasted.  But ask them to do much of the work, or
buy a pig in a poke -- you'll get resistence.

The Emacs development community is in a box and not realizing its
potential, I'll admit, and out-of-the-box thinking is needed.  What
you and Karl are missing is that the projects on which you base your
New Conventional Wisdom are in their own box, and the thinking Emacs
needs is, IMHO, outside of *that* box too!

 > But I think it's important enough that I'm here.

<rant>
If you think it's that important, you'll stifle yourself and address
the single most important issue, which is making the population of
potential reviewers and mentors of the fresh blood happy with your
changes.  Those are the current core devs and maintainers.
</rant>

You say, "you build it and they (the fresh blood) will come".  My
guess is a trickle -- Lisp, let alone Emacs Lisp, is a barrier, as is
the collection of (by modern standards) crufty old coding idioms in C.
Again, I say "you (Eric and Karl) build it and they (the existing core
and maintainership) will come."  That's a no-brainer because they're
already here, aren't going anywhere, and your new infrastructure is
going to be as good as you say, right?  Anything *that* good, the
maintainers will notice![2]

"Even in Emacs"[sic], there is no shortage of drive-by contributors.
But Emacs Lisp is more than an "extension language"; along with Emacs
itself it is a complete application development and runtime support
platform.  What Emacs core needs, far more so than org-mode or "Battle
for Wesnoth" or even Subversion does, is developers who have a pretty
good knowledge of a fair slice of the code base and deep knowledge of
some piece of it, to be to able review and mentor others, as well as
to keep the code base sane.[3]  Of course, such developers must be
completely ignorant of Emacs at some point in their lives!  But to
bring them up to speed in reasonable time requires not only mentoring,
but dedicated unsexy study and repeated submission to correction on
the part of the wannabe core developer.  If Texinfo and debbugs scare
someone away, I doubt they were core material in the first place.
(That's not saying at least a better website and bug tracker aren't
obviously good ideas, just that I doubt they'll have that much effect
on new blood, and if not the impact on maintainers had better be
minimal.)


Footnotes: 
[1]  And yes, there are real problems, in both Emacs and the American
economy.  But no need to ask for Last Rites for either.

[2]  And no, they don't have to be fools to fail to see how wonderful
it will be.  They just have to be not-you.  I don't see it either, and
I work with a lot of the tools you espouse.

[3]  That's why the "bias" that Karl noticed in Eli's list of projects
whose practices are similar to Emacs's probably means that they are an
appropriate peer group for comparison, rather than a sample hopelessly
unrepresentative of best current practice.