Re: More metaproblem

[Karl Fogel]

Eli Zaretskii <address@hidden> 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.  If
enough agree, that can make it easier to fix, even if those people
aren't the ones who fix it.

For example, momentum is building around auto-generated ChangeLogs now,
largely because developers who contribute a lot to Emacs are either
supporting it or no longer actively resisting it.

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

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.

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

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.

>> > Feel free to contribute the missing documentation, and thanks in
>> > advance.
>> 
>> 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?

Specifically:

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?

(I don't mean volunteer to help, I just mean support the goal or anyway
not oppose it.)

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

>And what counts as "easy", anyway? having a "contribute" Web page?
>Are you really going to seriously claim that this is all that stands
>between a project and being "easy" on newcomers?  If so, perhaps we
>have been contributing to 2 very different classes of software
>projects, because the main obstacle in my experience is not the
>mundane rules like that, it's the need to understand the architecture
>and the design of a complex piece of software, enough so to be able to
>contribute non-trivial changes.

(See above about selection bias.)

My claim was specific:

I claimed that in the other projects I named, you *don't* see people
complaining about how hard it is to contribute, the way we regularly see
here.  I'll add to that the claim that you *do* see new contributor
acquisition and retention at a better rate in well-run projects.  I have
seen this myself in projects I know well, and I've checked my
impressions with people in other projects and they confirm it.

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

>To summarize, my analysis of what you wrote is that you expect too
>much of the handful of volunteers who develop and maintain Emacs
>entirely on their free time.  A few people can only do this much.  You
>want to improve things -- come aboard and be welcome.

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.

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.

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

-K