
How to get an open source community to be interested in helping you - zdw
https://www.snoyman.com/blog/2017/10/manipulating-maintainers
======
zzzeek
Intro: I am the creator and maintainer of SQLAlchemy. The post below describes
my anecdotal experience working on this project and a few other related ones.

Great post, definitely these are the things that make for a great
participating in an OSS project.

Unfortunately, the folks who spew out impatient, one liner bug reports are
exactly the folks who will never read such a blog post, or anything else for
that matter. They won't even read the _ALL BOLDFACE_ bug posting instructions
I put up that tell them to post a usage example and don't just show a line of
code you think should change.

I've had many days ruined by naive idiots who think I work for them or
something, and it is an ongoing, multi-year practice to learn how to not
escalate and how to not have your day ruled by such people.

In case I'm not getting downmodded here enough, I'll add that users/nicknames
that seem to identify as female never have any of these issues - users that
identify as female always come very well prepared with great test cases and
all the up front research done. More and more the issue of "decency" seems to
pervade all areas of human interaction as we've descended into such a non-
decent era.

~~~
jordigh
So, taking your comment at face value, I would hypothesise that women try
extra-hard to be nice because they have faced or are afraid to face worse
social repercussions if they're not.

~~~
zzzeek
that is correct. they know they have to come 10x more prepared.

------
sverhagen
"I'm going to have to strip off the extraneous bits until I'm staring the
problem in the face. Why should I spend my time doing that, when you—the
person asking for help—could be?"

Oh, the dozens and dozens of times I solved my own problem while making it
reproducible, before actually filing the report!

~~~
npsimons
Much like Rubber Ducking:
[https://en.wikipedia.org/wiki/Rubber_duck_debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)

------
qrv3w
These are great tidbits for how a contributor can get the attention of a
maintainer but I think these tips also inform well on how a maintainer can get
more contributors.

Recently I started a new project and got 7 contributors in a week - more than
I've gotten for any project ever. [1] I think its partly due to hacktoberfest
but also because I realized I can't waste a contributor's time. I made issues
with descriptions of exactly what should be done - where in the code they
could introduce edits, and what kind of dependencies people could use to
implement, etc. Though I could have done myself, I didn't have to and I also
got to see some ingenuity of other people!

[1]:
[https://github.com/schollz/croc/graphs/contributors](https://github.com/schollz/croc/graphs/contributors)

~~~
j_s
A recent Twitter discussion/checklist on attracting a community as a
maintainer:

[https://twitter.com/sehurlburt/status/921921604140937216](https://twitter.com/sehurlburt/status/921921604140937216)

------
roflc0ptic
OT, but Michael is a great guy. At LambdaConf, he got lunch with me
specifically to spend time explaining monad transformers, just because we were
chatting and I expressed confusion. Had no idea who he was. Later learned he's
the Yesod guy, which is the main Haskell web framework. I'm always grateful
when the big players in some domain make themselves as approachable as he
does.

~~~
cies
Yesod (most typesafe webframework), Stack (quick to become a very popular
build/install tool in Haskell land), conduit (a lib/ecosystem for dealing with
data streams), Stackage (publishes sets of packages know to work well
together). He's currently Director of Engineering at FP Complete.

Here the packages he's a maintainer for on Hackage:

[https://hackage.haskell.org/user/MichaelSnoyman](https://hackage.haskell.org/user/MichaelSnoyman)

------
FascinatedBox
As the sole maintainer of a pretty big repo, these are all super helpful.
Another is that, if the project in question is compiled, add in a gdb trace.
It's often the difference between "I know exactly what this is and I'll do it
now to get it over with." and "There's about three+ ways this could be
happening, I'll check it out later."

------
davidtgoldblatt
My experience working on an OSS project has been that the biggest thing
missing from the bug-reporter side isn't phrasing or planning, just
dedication. If someone doesn't post a useful initial bug report, we can still
probably work our way there if they keep pinging the thread or follow whatever
instructions come out of the maintenance side of things. OTOH, if I can't see
that an issue is actively causing someone pain, it's way easier for it to fall
off my radar. Apathy slows down resolution far more often than antipathy.

------
lwhalen
[http://www.catb.org/esr/faqs/smart-
questions.html](http://www.catb.org/esr/faqs/smart-questions.html)

ESR did it better, imho :-)

~~~
JoshTriplett
There's some marginally useful content buried in that, but wrapped in a
pervasive and unpleasant position of "the person you're asking is way more
important than you, lowly questioner", and many excuses attempting to justify
elitism.

I much prefer Julia Evans: [https://jvns.ca/blog/good-
questions/](https://jvns.ca/blog/good-questions/) and
[https://jvns.ca/blog/answer-questions-well/](https://jvns.ca/blog/answer-
questions-well/)

~~~
jerkstate
I had never seen Julia Evans' writing on the topic but have read ESR's many
times. It looks like Evans' guide is mostly geared towards being considerate
of the other person and ESR's is mostly geared towards collecting the
appropriate information beforehand and phrasing the question the right way.
Both are extremely important for effective question asking.

Regarding the "lowly questioner" dynamic, look at it this way: if you're
asking someone a question about their software, you're seeking to extract time
from someone in order to extract value from something that they created. Be
humble.

~~~
JoshTriplett
> It looks like Evans' guide is mostly geared towards being considerate of the
> other person and ESR's is mostly geared towards collecting the appropriate
> information beforehand and phrasing the question the right way.

[https://jvns.ca/blog/good-questions/](https://jvns.ca/blog/good-questions/)
covers both of those topics in detail, in my opinion.

------
Pica_soO
By not trying to window-shop? Aka, posting wishes disguised as suggestions.

My all time favorite- asking for a feature that is already existing, not
taking time to search the documentation, then when somebody duplicates the
information for you (basically becoming your free of charge search engine) -
you dont thank him, but ask for a implementation (basically hiring a
programmer for free)- once that doesent happen, you are never heard of again.

And that above is the norm in Open source community. Those hostility arise,
because there is a constant stream of clueless users doing the crybaby on
forums. Which is why man open source devs retreat to irc and only answer your
question if you lurk for a day and post a little history detailing your own
investment.

------
jancsika
The "XY Problem" link[1] has an authentic-sounding and hilarious impression of
a developer being a jerks to a newcomer.

A quick analysis of "Example 1":

* developer has already figured out that the person almost certainly means to get the extension, but they then inexplicably post the likely irrelevant answer that blithely returns the last three characters. (More on that below...)

* developer uses caps-- meant to convey that they are YELLING at the questioner-- which is unwarranted and pointlessly aggressive

* developer is obviously annoyed by questioner taking too many steps to get to a proper statement of their problem. But after the developer states the problem properly and the questioner confirms it, the developer wastes a step in their own response to demand that the questioner obtain an arbitrary level of knowledge before they state future problems. I write "arbitrary" because the developer has apparently decided that the questioner should have already known that a) a file extension is called a file extension and b) file extensions don't always contain three characters. But the implication is that a questioner armed with this increased level of knowledge (and who would have therefore Google'd the answer more easily) strangely would be more deserving of receiving an answer than someone who obviously sought out the help of a fellow human being because they didn't know what to search for. That's a bizarre (and frankly anti-social) line of reasoning.

* developer uses a mean-spirited adjective "blindly", ostensibly to hurt the newcomer's feelings. But this is my favorite part-- the developer has already shown that they were nearly certain that the questioner _meant_ to ask for concept they were unable to name-- an extension. (Plus having that confirmed by the questioner.) So for the insult to work here, the developer refers back to their _own_ irrelevant example, calling that "blindly grabbing three characters," and using sleight of hand to reinterpret that as the initial query. All this after having already confirmed the questioner's _actual_ problem!

That shows an impressive level of premeditation to be a jerk-- that is,
setting up an irrelevant answer in order to heighten the language for an
insult in a later response.

I sure hope this example response doesn't really reflect the current
communication style of FLOSS devs.

1) [http://xyproblem.info/](http://xyproblem.info/)

~~~
alien_at_work
False XP Problem is a pet peive of mine actually. Personally, I downvote any
answer on e.g. Stack Overflow that doesn't answer the question asked. The
proper way to respond to any technical question, IMO, is first answer it
exactly as ask if you can (if you don't, then don't answer). After that, you
may optionally ask what the person is trying to do and offer your expertise.

The issue I run into is this: I work in the enterprise environment. I have a
lot of experience but _sometimes_ I'm forced into doing something seemingly
stupid that you would normally never want to do (obviously more complicated
than the silly "last 3 characters" problem). So I ask on SO giving as little
detail as possible, purposely because I'm hoping to avoid a bunch of wasted
time with "but you don't _need_ to do that you can do solution A", where
solution A is a solution I already wanted to do but was unable because of some
reality of the company I work for (and no, I can't download or install
_anything_ and I won't be able to change that). All the obvious solutions will
be this way. What I actually needed was what I asked and I had to ask
precisely because I also never normally want to do this so I don't know how.

I find the kind of answers that some people advocate for extremely arrogant.
By answering e.g. an SO question by answering something that wasn't asked you
(a) assume you know more than the person asking (you may, or you may not) and
(b) assume there will never be another user anywhere that will actually need
the answer to the question that was asked. I get hit by (b) the most: I put my
question into google, I actually find an SO question that I need the answer to
but some jerk explained the user wanted something else, answered _that_ and
then, of course, the thread died.

~~~
ndh2
I also run into this problem when asking on SO. Even if you write in the
question "I've already ruled out ... as a possible solution" you still get
people trying to argue about it. I'd rather they ignore the question...

------
AdmiralAsshat
_There 's an old "ha ha, only serious" joke. If you go to a Linux forum and
ask for help fixing your WiFi driver, everyone will ignore you. If, instead,
you say "Linux sucks, you can't even get a f_&$ing WiFi driver working!"
thousands of people will solve the problem for you.*

This is 100% accurate. There is no better way to get assistance with HiDPI
tweaking on a Linux desktop than to go onto a subreddit and bash your DE of
choice, complaining about its lack of HiDPI support.

------
jimhefferon
A good summary.

I've also found that timing can be important. Basically: don't ask on Fri at
3:30.

~~~
vortico
You might be right statistically, but many of my acquaintances and I work on
open source beginning Friday and ending Sunday night. It depends on the
project. If it's an open source web server, you're right. If it's a tiling
window manager, the opposite is true.

~~~
jimhefferon
Fair. But timing matters.

------
nurettin
High usage attracts higher level developers. The motivation created by your
software being used by a large community of people is, in my opinion, the most
portant thing when contributing. Sometimes it is easy, like adding a few flags
to fpc, sometimes it is a bit more tricky, like adding utf-8 support to an IDE
which lacks it.

~~~
RoboTeddy
Agreed. This is why open source works: success brings in more resources (a
positive feedback loop). It's the same thing that happens in for-profit
companies.

------
ziikutv
I’d advise removing the first paragraph. It’ll trigger some readers into
rolling their eyes and leaving

------
pvaldes
Explain what you want to do in twenty seconds, or less.

