Community and contribution [was: Re: http://wiki.dlang.org/DIP25]

[Joseph Rushton Wakeling via Digitalmars-d]

On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
> I did want to say something about this. I've given a close read to the "Lost a
> new commercial user this week" thread, through and through. It seems I've
> identified a problem that belongs to us. ("Us" is a vacuous term meaning "the
> leaders of the D community").
>
> My initial read of your complaint went like this: it's about Windows (I don't
> even have an installation), it's about vibe.d (haven't used it yet), and it's
> also discussing documentation (which is something we can indeed improve and I
> know how to). So a large part of the problem wasn't even mine to work on.
>
> Others harbored similar perceptions. The corollary has been that essentially
> you're asking them to stop working on D aspects they do care about and start
> working on D aspects you and others care about - all on their free time.

A few thoughts on this.  (This turned a bit longer than expected in the writing, 
so I've highlighted some TL;DR sections to highlight key ideas.)

I think that one of the most common sources of community friction in open source 
is people mistaking being _asked_ to work on something that someone else cares 
about, for being _expected_ to do so.

That's very unfortunate, because it means that all too often people will come 
into a community, full of enthusiasm for this new thing they've discovered, make 
some suggestions, and get shot down like they're some sort of plague carrier. 
(The D community is pretty good at not doing this with newcomers, but deals less 
well with people repeatedly raising ideas; more on that in a moment.)

Obviously, there are people who display an enormous sense of entitlement, who 
are rude or just throw demands around in a very arrogant way.  But simply 
saying, "I want this", "I need this", or "I think this would be a good idea" 
should not IMO be a trigger for criticism or hostility.  Most of the time, 
people do understand the fundamental constraints of a volunteer community with 
limited resources, and what they are interested in having is either 
acknowledgement of a good idea or use-case (preferably with something getting 
onto a TODO list, but not necessarily with any priority), or feedback that helps 
them understand alternative ways to solve their problem.  (Caveat: it matters 
whether the problem is actually solved, or just worked around.)

----------------------------------------------------------------------------
TL;DR: I think it would be good to have a strong community guideline that people 
are not to be criticized or treated badly for having requests or suggestions, 
even if they are not willing to implement them themselves.  The quid pro quo is 
that it's necessary to be (calmly) candid with people about the limits of _only_ 
contributing ideas or requests: "You can ask but not demand".
----------------------------------------------------------------------------

The other observation is that, often, what frustrates core contributors about 
people coming in with ideas and requests and so on, is that responding to that 
takes time and effort and often distracts from limited time available to deliver 
actual work.  It can be very, very wearing having to explain to people time and 
time again why something is a certain way, or to have to make the case yet again 
why X is not considered a priority, or whatever.

Now, in some cases, these problems are self-inflicted.  I've encountered core 
contributors in some communities who simply _could not let go_ of the need to 
prove someone else wrong, or to explain to the n'th degree why something was not 
possible.  (This interacts very badly with me, because I find it very difficult 
to let go of a discussion where I feel that I've been misunderstood:-)  In other 
cases I've seen core contributors regularly engage in rudeness or sometimes even 
virulent personal attacks, and then bemoan how demotivating it is having to deal 
with belligerent arguments on the mailing lists.  Thankfully the D community 
sees very little of this.

More often, it's simply a result of the discrepancy between numbers of 
contributors and numbers of (verbally active) users -- and it only gets 
compounded by the feeling that, if people spent half the time contributing that 
they spent arguing, far more things would get done and the core contributors 
would have a much easier time of it.

IMHO there are two important things to address here.  One is to give a lot of 
priority to entry blockers -- to the things that prevent people from becoming 
users or contributors.  Difficult installation experiences, obscure 
dependencies, weird or out-of-date tools etc. are all things that are boring but 
important to address because the work to solve them can pay off massively in 
terms of how many people are willing to get involved.  (D's move to GitHub is a 
great example.)

Obviously volunteer contributors can't be obliged to accept these priorities, 
but it should be possible to highlight and stress them as key things for the 
project, as well as maybe engaging in some outreach to try and invite people 
outside the current community to consider contributing their expertise.  There 
could also be special rewards for people who deliver particularly important 
goals (I'm thinking of things like signed copies of TDPL with personalized 
thank-you notes; personally I reckon such things may be more precious than a 
financial bounty:-).

----------------------------------------------------------------------------
TL;DR: When setting project priorities, put a real stress on entry problems, and 
consider outreach if the existing community doesn't seem able or willing to 
engage with something important.  And be creative with the rewards for good 
stuff :-)
----------------------------------------------------------------------------

The other is to embrace the fact that past a certain scale, there are always 
going to be lots of people who are keen to take place in community discussion 
(because hey, it's FUN:-) but who for whatever reason are not going to 
contribute code or documentation.  The opportunity here is to ensure that key 
knowledge is spread among these people, that they have good understanding of the 
what/where/why of the state of development, so that they are in a position to 
bear the brunt of the explanation and conversation duties; ideally, they would 
(simply by doing what they enjoy naturally) take away a lot of the need for core 
contributors to engage in day-to-day forum conversation.

In other words, you try and scale things so that core contributors primarily 
talk with and guide regular forum participants, and they talk with other people, 
and get recognition for the value of what they're doing (any easy reward might 
be, for example, the right to have an @dlang.org email address).  Note that it 
doesn't need to be some sort of official role; there must be plenty of people 
who might balk at the idea of community commitments or duties, who will 
nevertheless do this well if simply engaged with.

----------------------------------------------------------------------------
TL;DR: Enable enthusiastic forum participants to be the front line of 
communication, to take the heat off the core devs.
----------------------------------------------------------------------------

> Then I figured we must take ownership of D issues. Your initial post was pure
> and simple user feedback - a knowledgeable and well-informed and well-meaning
> user but nevertheless a user who is not quite willing to roll sleeves up and
> proceed with adding work. If we consider ourselves a free-wheeling grassroots
> tribe, best we can do invite you to do the work and review and merge it in (or
> snicker at you if you're not up for it). If, on the other hand, we want to be a
> real organization, we must take the feedback and own it.

Even allowing for the difference between grassroots vs. organized projects, I 
personally think it's one of the most counter-productive sides of open source 
culture, that it's considered OK to snicker at people who don't want to get 
their hands dirty.  There are lots of reasons people can't or won't contribute 
at any given moment; it surely suffices to politely point out the limitations of 
non-involvement, and deal firmly with the handful of nasty people who get 
abusive when that happens.

I'm really happy to see your resolve on the need to find ways to "take 
ownership" of user issues.  It's been one of my regular sadnesses, seeing 
various people (Manu and others) be very committed in providing feedback and 
use-case scenarios, and not getting the engagement that their insight deserves.

> A simple simile: say you mention to the manager of a grocery store that they
> should have more organic fruit, and mention anecdotes of potential customers
> shunning the store because it doesn't. If the store is a cooperative of folks
> selling stuff they grow on their own, the manager might invite you to join in
> with your produce. If, on the other hand, the store is an established
> supermarket, they'd do good to take your suggestion seriously.

Yes, but :-)  A smart cooperative will still take on board the feedback and 
consider if it might be worthwhile doing something themselves, even if it's not 
directly in line with their personal interests.  In terms of how D can do things 
better, that might include trying to find better ways of documenting user 
feedback and trying to better highlight worthwhile projects.  That might be 
possible to organize independent of your next suggestion.

> We're in the "cooperative" stage of D, and we need to move toward the
> "established organization" stage. We should start transitioning to that next
> year; part of it is I plan to look seriously at the non-profit organization angle.

That's really great to hear; I don't want to say anything to anticipate or 
prejudge what you have in mind, but I am looking forward to further elaboration 
of this idea.