Re: Efforts to attract more users?

["Stephen J. Turnbull" <stephen@xemacs.org>]

Back to the "attract more users" thread.  Specifically, "attract more
user/developers."

Juanma Barranquero writes:
 > On Sat, Jul 10, 2010 at 02:28, Lennart Borgman
 > <lennart.borgman@gmail.com> wrote:
 > 
 > > I told you at that time how to do the merge. You seemed to believe it
 > > could be done another way.
 > 
 > Yes, you told me "here's my code, please adapt it to the trunk, as I
 > don't have time to do it myself" (not exact quote, but that's the
 > feeling).

That's not the feeling I get at all.  I don't have complete sympathy
for Lennart, there is clearly some aspect of contributing to Emacs
that he just doesn't get, leading to blocked communication with
disheartening frequency.  However, "take it or leave it" is NOT AT ALL
what I get from his posts.  There a separate issue, that when you
submit working code to Emacs, you will be told to change it in ways
that give you heartburn.  Lennart has had *multiple* experiences where
he has submitted working code, communications over the integration
break down, and his code was refused, without anybody ever doing more
than looking at it and saying "that can't work" (usually with a
theoretical rationale that for whatever reason Lennart doesn't get).
While (as I mention above), Lennart has to take some responsibility
for the communications breakdown, I cannot at all blame him for not
wanting to go through that again.

One of the nice things about working on <beep>Emacs and <boop>Emacs,
as well as projects like Python, Mailman, and Bazaar, is that
sometimes (not always, of course) other people will do the work that
you for whatever reason don't want to do.

It's a shame that GNU Emacs, of all the projects in the world, feels
so impoverished that its developers can't take time out to mentor
somebody like Lennart, show him the ropes, and *teach* him how to make
submissions that get accepted the first time around and require only
minor adjustments and checks before integration to the trunk.  I think
in this case the proposed change is such an obvious winner that it's
only Emacs-side stubbornness that prevents it from being implemented.