Re: More metaproblem

[Jorgen Schaefer]

On Thu, 04 Dec 2014 23:21:33 +0200
Eli Zaretskii <address@hidden> wrote:

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

Do you realize how incredibly hostile this comes across as?

As a possible contributor, reading this, how inclined do you think this
makes me to bring up possible stumbling blocks I might have when trying
to contribute to Emacs?

And let me tell you, my experience with *trying* to contribute to Emacs
so far mainly has left me with the impression that I might be able to
contribute to Emacs *despite*, not *because*, of the best efforts of
"the management". But only if I work really hard for it.

Of course, I should not bring this up, because my time is limited and I
am only interested in some minor contributions, so my opinion is
irrelevant, and I "don't have the right to whine" about this, right?

On this topic, I can highly recommend Brenda Lynne Chawner's thesis
_Factors Influencing Participant Satisfaction with Free/Libre and Open
Source Software Projects._[1] Section 9.3 includes this rather hands-on
list of suggestions (p. 213):

| - ensure that the project’s ‘About’ page and documentation include
|   information about what types of contributions are most needed, and
|   how to contribute
| - acknowledge and celebrate contributions, so that people who do
|   contribute feel appreciated and motivated to continue;
| - monitor questions in the project’s email discussion list and/or
|   forums, particularly those from newcomers, to ensure that they are
|   answered;
| - provide information to the project’s community about the project’s
|   future development, perhaps in the form of a ‘road map’ that lists
|   the planned changes and enhancements;
| - ensure that documentation is up-to-date, and that aspects of the
|   software that may be perceived as complex are explained clearly;
|   and
| - find out what barriers participants encounter when making a
|   contribution to the project, and take steps to minimise or
|   eliminate them.

It is probably not obvious to you, but Emacs fails at every single one
of those to various degrees.

And only somewhat related, for you especially, Eli, I can highly
recommend John E. Vincent's essay on _Software Empathy_.[2]


(As a balancing point, I should add that it's not all bleak. I have
received very kind and helpful responses to some questions on this
list, and especially - but not only - Stefan can be very friendly and
supportive.)


Regards,
Jorgen


[1]
http://researcharchive.vuw.ac.nz/bitstream/handle/10063/1710/thesis.pdf?sequence=4
Summary at
http://opensource.com/business/14/8/study-participant-satisfaction-open-source-projects

[2] http://blog.lusis.org/blog/2014/10/19/software-empathy/