[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More metaproblem

From: Eric S. Raymond
Subject: Re: More metaproblem
Date: Fri, 5 Dec 2014 13:19:14 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Karl Fogel <address@hidden>:
> If we could work out the technical details to have a "www/" directory at
> the top level of the Emacs source tree, and have that be where both the
> home page http://www.gnu.org/software/emacs/ *and* soon-to-be-written
> new developer-oriented pages are maintained, would you be in favor of
> that?

Something at least roughly equivalent to this *needs to happen*.  

> Elisp code for people to use as examples.  Few projects should be as
> easy to contribute to as Emacs should be.

That is true.  The main barrier is not the codebase; it is guidance and
an uptake process that can best be described as shambolic.

> My request is simple and specific:
> I'm asking the biggest contributors to Emacs (you, among others) to
>   - Not oppose a revamp of the contributor documentation along the lines
>     I described;
>   - Not oppose using a modern bug tracker -- one that supports email
>     manipulation but *also* supports manipulation via a web browser.
>     (Redmine, for example.)
> Those two changes alone would lower the barrier to entry significantly.

Yes, they would.

We need to behave like a normal project with a normal interest in attracting
new developers, doing that in a normal way.  Practice in these areas has
long passed Emacs by.
> Senior developer resistance to those changes effectively means they can
> never take place.  Absence of such resistance doesn't guarantee that
> they will take place, but is certainly a necessary precondition.
> Right now, any volunteer energy toward such changes is pre-quashed:
> anyone who might think of doing them, but who reads this list, would
> quickly come to the conclusion that it would be a huge fight, a
> months-long abuse fest, and give up in advance.

Alas, I certainly could not falsify that charge by what I went through
moving us to git.  The Emacs dev list has a culture and traditions
which, though not actually designed to suppress new contributors,
might as well have been.

> So I'd love to see that barrier go away, just to see what would happen.

My meta-plan is to identify barriers to new developers, one by one, 
and dynamite them.

Not being on git was a *biiiig* one. The disorganized and
undiscoverable state of Emacs's internal documentation is another,
which is one reason one of my next minor to-dos is cleaning out the /etc
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]