emacs-devel
[Top][All Lists]
Advanced

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

Re: Metaproblem, part 3


From: David Kastrup
Subject: Re: Metaproblem, part 3
Date: Sat, 06 Dec 2014 11:51:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> writes:

> Eric Abrahamsen writes:
>
>  > It would be nice to explicitly let posters know that they can ask
>  > someone for help with implementing a feature/squashing a
>  > bug. There's lots of helpful advice here and on emacs.help, but
>  > that's not quite the same as knowing that someone has committed (to
>  > some extent) to assisting you.
>
> I see worries about "hostile" environment, and suggestions for making
> things more welcoming to new contributors.  I have to ask, what do all
> you folks who are suggesting Emacs change its procedures think is in
> it for the mentors and core developers?

Profiting increasingly from work done by others.  That's actually a bit
more of expected payback than for the usual "you developers should jump
for joy when I have a good idea for your project that just needs some
working out by code runts" offering to free projects where the resulting
mailing list threads tend to get even more level-headed developers
marked for hostility.

The previous active maintainer of LilyPond, Graham Percival, chose to
try the effectiveness of mentoring, investing a large amount of work and
effort in individual mentoring of several would-be contributors.

The outcome overall was characterized as a huge disappointment by him,
with less work being done in the time the mentored persons stayed active
than he could have done himself in the time the tutoring took.

I have seen similar results for hiring outside people for doing free
software work: the return of investment tends to be hugely
disappointing.

The main reason for that is that the people commonly working on Free
Software projects tend to be self-motivated and skilled, and their skill
level leads to a reasonable return of satisfaction from their work.

So to get more people on board, it does not seem effective helping
single persons across some barriers of entry that are actually of the
kind that will stick around and that will continue to affect the balance
of freely contributed work and the satisfaction derived from a job well
done.  Instead you have to work on lowering the barriers of entry
altogether.  For better or worse, work will only get done by people
developing a vested interest and some loyalty to a project and its goals
and community.

And it is also useful to try breaking down the barriers between users,
power users, and developers as their numbers tend to be vastly different
and so even small changes can make quite a difference.

A system has to become usable and workable without too many of the
"please look aside while I fix this using some magic incantations that
you'll never understand" moments for users asking for assistance with
the problems encountered in daily work.

Texinfo is not really a relevant hurdle for getting Emacs documentation
written.  Elisp is.  Arguably things like lexical bindings have taken
far too long to arrive (and they still aren't in XEmacs if I remember
correctly) and there is not much in direction of making the language
more placatable.  Common Lisp compatibility might be one idea for
inheriting other people's work on making Lisp a general-purpose
commodity but, uh, Common Lisp has not exactly focused on being a
concise expressive language easily embraced by its users.

At any rate, I am suspicious of any promise of free software prosperity
to come from the hands of preachers rather than workers.  The danger
that one is left with less than what one started with when the
motivational Ponzi scheme of rewiring infrastructure to the newest fad
breaks down is real.

-- 
David Kastrup




reply via email to

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