Re: More metaproblem

[Eli Zaretskii]

> From: Karl Fogel <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Thu, 04 Dec 2014 12:33:10 -0600

Not really sure how to respond to this.  What exactly is the purpose
of what you wrote?

Anyway, some random comments.

> >See admin/notes/repo and admin/notes/commits.  What else is missing?
> 
> New developers are somehow supposed to know that those random files in
> admin/notes/ are what they need to read?

They usually ask and get told about that.

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

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

> >> Emacs is not an easy project for newcomers or drive-by contributors.
> >
> >Which large and complex project _is_ easy for newcomers?
> 
> 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.

> There are many more.

Please name them.

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.

> >I think if you dislike so much in Emacs development practices, you
> >should become much more active than you are, and then you maybe stand
> >a chance to start changing all that.
> 
> It's precisely that I don't have time to be more active than I am, that
> leads me to want the project's development procedures to be more
> conducive to developers like me -- there are many of them out there.

Then you don't have the right to whine about how the project is being
managed.  Any serious change in management comes from within, not from
the outside.  This is Free Software; each one scratches the itches
that bother them.  You cannot force me or anyone else to do things we
don't like or don't feel qualified doing.  You think it's important --
get your own sleeves up, and get to work.  If you don't, then you need
to learn to live in peace with what others do for you, however they
decide to do it.  Not working on something you consider important, and
instead pouncing on those who do work is just plain rude.

> But to deny that the project is difficult for incoming developers?

Who denied it?  I didn't.

> But claiming there is no problem, that the phenomenon is not real, does
> not seem plausible to me.

Who claimed that?  I didn't!

> For a widely used *programmer's tool*, that is self-documenting and
> has an extension language, Emacs has an astonishingly low rate of
> lightweight contributed development.

There's any number of small jobs described both in etc/TODO and on the
bug tracker.  If there are indeed people who want to contribute on
some small scale, there's a lot to be done, and such contributions
will and always were very welcome.

> Can you help make your hypothesis falsifiable?  (In the intellectually
> rigorous sense, I mean, not the "make it false" sense.)  I might be able
> to find some time to do that.  In other words, can you tell me what
> measurable signs *you* would look for to determine if a free software
> project were stagnating, and then we can look to see if Emacs is
> exhibiting those signs?  (For example: rate at which developers slow
> down or stop contributing; relatively greater slowdown in rate of
> acquisition of new developers compared to other projects; shrinking
> diversity in first responders to bug reports; etc, etc.)

I have neither time nor motivation for that.  I do what I can for
Emacs; I cannot do more.  I only hope what I do is enough.  I'm sure
the same is true for Stefan, and Glenn, and a handful of other "core
maintainers".  If you or someone else think what we do is not good
enough in some area, you are invited to come aboard and change how
things are done.

> Committers sorted by commit count since 1985, in case it's interesting
> (obviously doesn't count patches and many other things, so this is only
> semi-data, not data):

And what was that all about?  What did you post the list for?

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.