Re: More metaproblem

[Eli Zaretskii <eliz@gnu.org>]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: esr@thyrsus.com,  eggert@cs.ucla.edu,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 05 Dec 2014 10:51:40 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >Not really sure how to respond to this.  What exactly is the purpose
> >of what you wrote?
> 
> I'm trying to spell out the nature of the problem in order to persuade
> influential Emacs developers (like you) that there is a problem.

In that case, you are wasting your energy, at least on me.  I have no
doubt there is a problem.  The question, as always, is how to solve
it, not whether it exists.

> I'd like to build momentum similarly around the idea of revamping the
> way we treat contributors, especially new or lightly-contributing ones.

We don't need a momentum.  We need specific practical actions, which
boils down to have volunteers step forward and make that happen.

> If we had a consensus about how to improve the contributor intake
> process, that might make people who are currently too afraid to
> volunteer to do it less afraid.  Currently, volunteering to do it
> implies long arguments on this list with people who think things are
> fine the way they are, which is prospectively exhausting, so no one's
> likely to come out of the woodwork and even try right now.

The arguments happen _solely_ because instead of volunteering, people
try to steam about how wrong the current situation is.  The moment
someone actually does something to improve things, I assure you there
will be no arguments, at least not long ones and not involving the
core maintainers.  (Yes, there will be a few requests here and there,
but that's understandable.)

> >> What most projects do is have a development web page. linked to from
> >> their main user-facing web page.  The development page organizes all
> >> this stuff and provides links to source code repository, dev guidelines
> >> & documentation, etc.
> >
> >Volunteers are welcome to take similar care of the Emacs Web page.
> >I'm sure they will be most welcome if and when they come.
> 
> Hmm, what is the path for such volunteers?

Err... just say that you do, and ask Stefan for instructions on how to
modify the relevant pages?

> That site & page are maintained by the FSF -- they're not in the Emacs
> tree anywhere.  In other words, whatever the procedures are for
> improving the Emacs home page (and creating a developer welcome page),
> they are completely different from the procedures for improving the
> Emacs code.  So, yay, now I have to learn *two* contribution paths.

So you want to change the way FSF maintains Savannah at the same time
you improve Emacs?  And you are still saying this is the practical way
towards improving Emacs, with good chances of success?

> >> It's not just a matter of contributing documentation.  We don't even
> >> *have a place to put such documentation* right now.
> >
> >Of course we do: etc/CONTRIBUTE.  We just decided to move it to the
> >top-level directory.
> 
> It should be a web page.  That's how things work now.
> 
> But my hypothesis is that anyone who tried to convert it to web page
> right now would face multiple obstacles, including not just technical
> obstacles but resistance to goal itself.
> 
> I'd love to be wrong about that.  Am I?

Yes, you are.  AFAIR, no one ever tried that, and therefore there
could be no resistance.

> >> Mozilla Firefox or LibreOffice, to name two off the top of my head.
> >
> >Don't know anything about those.  I do know about GCC, GDB, Groff,
> >Guile, heck, even Make.  Nothing easy there for newcomers.
> 
> You've named some of the oldest free software projects on the Net, and
> ones specifically oriented toward GNU toolchain programmers.  I think
> there *might* be some selection bias at work here :-).

The only bias here is that those are projects I actively participate
in, on some more or less meaningful level.  I can only speak about
things I'm familiar with.

> Above, you seem to be confirming my assertion that you don't think
> there's a real problem here -- that is, you think that the changes I
> describe would not make Emacs easier to contribute to, because the real
> causes that make Emacs hard to contribute to have to do with the nature
> of the code base.

Yes.

> I don't think that's true, especially in Emacs' case: it has a
> well-documented extension language and gazillions of lines of Elisp
> code for people to use as examples.  Few projects should be as easy
> to contribute to as Emacs should be.

What we sorely miss is not random contributions -- these are
important, but they won't help enough.  What we need is to widen the
very small circle of people who can be called "core maintainers" --
those who can review patches, mentor newcomers, write meaningful and
correct "contribute" Web pages, and do all the other tasks that were
discussed here.  And, btw, also develop major new features for Emacs,
without which this project is doomed.

It is impossible to do all that without good familiarity with at least
some areas of the Emacs core.  Without that, you cannot do all those
tasks that everyone wants to be done.  If you don't understand this,
then I'm sorry, but your views on how to make Emacs a better project
in the long run are of no practical importance, because your accents
are all wrong.  Yes, it is very important to make the initiation for
new contributors easier and more friendly, but that will not "save" us
in the long run, unless we also have some practical way of drawing
those newcomers into the Emacs depths, until they become "core".

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

There's no opposition to that.  Never was, never will be.  The only
problem is to find volunteers capable of doing that and then
maintaining the results.

>   - Not oppose using a modern bug tracker -- one that supports email
>     manipulation but *also* supports manipulation via a web browser.
>     (Redmine, for example.)

I don't know anything about that, and personally never expressed any
opposition.  I do have a few simple requirements for a bug tracker,
but that's all.

> Those two changes alone would lower the barrier to entry significantly.

Then let's go!

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

THERE'S NO RESISTANCE!!  Please stop barking up the wrong tree.

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

I cannot read people's minds; maybe you can.  I don't know what anyone
might think about volunteering, unless they actually speak up and
volunteer.  I challenge you to find any examples of volunteers in this
area who were turned down by "senior developers".

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

That barrier doesn't exist!  You are imagining it.