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.