
Don’t email me - jonaslejon
http://daniel.haxx.se/blog/2013/10/08/dont-email-me/
======
casca
For some context, Daniel Stenberg is the lead developer in the widely used
curl and libcurl OSS. He is extremely responsive on the mailing lists and will
often provide detailed answers to difficult questions.

~~~
sebcat
Also libssh2, which is really nice IMHO

------
pfortuny
It is too long an explanation for the simple fact that: "private conversations
with the owner of a public project are impolite."

As a general rule, that tends to be true.

I guess he has had some relief from writing that rant but it is unnecessary:
nobody should expect a private answer from a developer of a public project.
Even more: there is no expectation of an answer to an email.

~~~
Sujan
It is not to long, but as long as the author thought it needed to be. The
simple fact you mention, obviously is not thet known to people - that's why
they write mails to him. And he wrote this post he can point them to now, so
they learn too.

And it also is obviously necessary, because people expect private answers. And
the also expect answers to emails. And that's totally ok, because it is ok to
be wrong. It only becomes a problem, if they don't accept the answer they get
including the link to that article.

~~~
pfortuny
As long as he got some relief, I am happy that he wrote it.

In any case: the fact that people may expect answers does not imply he is rude
not giving them.

~~~
Sujan
I even think it is important, he wrote it. Not only as a release valve, but
because a) we are talking about it and b) it can be part of educating the
'masses' on why some things are the way they are (or should be).

~~~
pfortuny
Anything which helps people learn something necessary is welcome. I cannot but
support it. What I intended to say is: sometimes abstraction helps explaining
things. I just tried to abstract what led him to say so many things. The
problem with rants is that people usually do not realize they are the object
of it.

As someone told me time ago, if you want to say something to someone who is
misbehaving, do not use a public medium: everybody else will get the message
but he won't.

~~~
Sujan
Valid.

The rant format definitely tends to cause its own problems.

I think it's all our job now to take (parts of) his points and apply them to
support and help pages of projects. That's probably most effective way to
trigger change in general behaviour.

------
jaggederest
It's funny, because from his point of view mailing lists are awesome.

But from the point of view of everyone else they're pretty terrible - it's
extremely rare I've had mailing lists deliver value.

For most open source projects, the correct way has been to find the
backchannel - the mailing list is only a source of frustration and bikesheds.
You must either contact maintainers personally or find an IRC or other real
time method.

~~~
alextingle
Well, I'm with him. If you are trying to work collaboratively, mailing lists
are absolutely the best way to get stuff done.

~~~
bonaldi
Forums are far better. Mailing lists seem like a hack to do forum-type stuff
over email.

Still using a mailing list nowadays is like using that web-to-email gateway
Stallman uses.

~~~
Shish2k
Try being an active member on 50 forums. Try being an active member on 50
mailing lists.

When there's some software that lets me see all activity from all forums in
one place, I might consider using one again :P (RSS is a good start in theory,
but I've not seen a single forum which uses it effectively)

~~~
bjelkeman-again
There is an opportunity out there. I am sure of it.

------
Intermernet
I've been involved in many areas of IT over the years, but, in the enterprise
arena, there's a strongly upheld rule that I've always presumed OSS projects
followed.

The rule can be summarised as "Send a help-desk ticket."

I have regularly advised team members to reply to personal requests for
assistance with a polite "Send a help-desk ticket" (Obviously precluding the
Directors / VIPs in the company)

This centralises the information, allows reporting and transparency, and means
that if some-one happens to be off sick, or away on holidays, someone else can
look after the problem.

Programmers like their instructions and data to be in orderly, prioritisable
queues and I see no reason why support requests should be any different.

</rant>

~~~
enneff
On the Go project we frequently say "File an issue." That's because the issue
tracker is the primary way we organize our work. If your issue isn't on the
tracker, then it's not visible to us.

A lot of people take that as "File an issue and STFU." I guess that's because
when your problem goes from being an active discussion thread to an issue
labelled as "Priority-Later" you feel like you're being ignored. But the
reality is that there's a practically infinite amount of work to do and a very
small number of people to do it.

Now that I think about it, this seems to be the main reason people resent
being redirected to the "proper channels." Because they know they're not going
to get special treatment. They'll just have to wait until their problem
reaches the top of the pile. (And maybe it never will.)

~~~
foobarbazqux
Pray, tell me more about this distinction between almost infinite and very
finite!

------
skore
I don't get why he doesn't like Pull Requests on GitHub. It obviously depends
on the kind of mailing list software you use, but most of them (like _shudder_
GNU Mailman) strongly discourage the user to hunt for existing requests and
make pretty much everything hard to follow except if you follow everything all
the time. Of course, if you're a maintainer, it's your job to follow almost
everything all the time. But casual contributors simply don't have that kind
of time and energy available.

With PRs on GitHub, a corresponding issue is usually filed and if people still
email you, simply tell them to first search there and then post their own.
That way, everybody can see and search the existing stack quickly.

I recently tried to contribute to a project that maintains both a mailman
mailing list (I offer a thousand internets to somebody who builds a general
purpose and usable UI to that) and a GitHub tracker and it was an absolute
nightmare to coordinate.

~~~
TheSilentMan
Also, I'm pretty sure pull requests wind up as notifications for anyone who is
watching the repo, not just people listed as contributors.

Even if I'm wrong, comments on pull requests are certainly notifications for
everyone who is watching the repo.

~~~
bjeanes
That's why starring was released [https://github.com/blog/1204-notifications-
stars](https://github.com/blog/1204-notifications-stars)

Watching is if you actually _want_ to pay attention to activity as opposed to
just bookmark something.

------
joosters
Obviously, before emailing anyone, you should first search the web for any
manifestos or policy statements that they've written on the subject of
communication. Not doing so is _terribly_ rude.

~~~
dspillett
If there is a preferred contact method _use it_. If you don't know if there is
a preferred contact method _have a look in obvious places first_ then by all
means go with what you find convenient if there is no other preference
obviously indicated. This is particularly true for a project where the devs
are volunteers or people who otherwise only work part time on that area.

By emailing an individual directly when there is a proper support route setup
you are basically shouting "Oi you, developer type, this is my priority and it
should be your's to, I don't know what else you are doing, but you should look
at this". You are a cold caller. You are the restaurant customer who snaps his
fingers and loudly calls "Boy!" to get a waiter's attention. Yes, you are
being rude. Don't expect me to be _glad_ that you chose to grace me personally
with your message.

The easy way around this I find is to prioritise things that have come through
the proper channels. I don't ignore direct emails, but they don't get looked
at quickly ( _especially_ if they have the "urgent" flag set) and when I do
respond I point out that they would probably have been dealt with yesterday
(or last week) if they had used the preferred contact point. In a commercial
setting our SLAs don't kick in until an issue is raised through the right
channels, so it is in your interests to use the right contact method.

The right answer to a phone call informing you that the email a user sent two
hours ago is urgent? "Well then it is urgent that you raise the issue the
right way, would you like reminding of the support portal's location?" (or for
certain requests "would you like reminding of your project/account manager's
phone number?").

Yes, this _is_ why I'm generally not directly customer facing and a method I
use in order to ensure that I remain not directly customer facing!

------
mgkimsal
This advice should/could be taken in to account for more internal/corporate
teams as well. I've tried to fight an uphill battle for years with teams I've
been on to get everyone to just use a couple internal mailing lists instead of
manually emailing multiple people directly about a project. Having a
searchable discussion archive about ideas/topics on a project is extremely
useful for new people joining a team, but they _rarely_ exist in corporate
environments. Often there's an outdated wiki, and maybe sometimes a ticketing
system, but the bulk of the discussion that happened electronically are locked
in peoples' emailboxes. :/

------
p4bl0
I totally agree with the author. However I would argue that for his 6th point,
trying IRC before subscribing to the mailing-list is in general a good idea.

~~~
ameoba
Many people new to IRC feel the need to immediately take their questions to
private message. Much of the same logic the blog makes about personal email
apply to personal messages on IRC - don't do it unless you've got a really
good reason to do so.

------
t0
Loading really slow. Mirror
[http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fdaniel.haxx.se%2Fblog%2F2013%2F10%2F08%2Fdont-
email-me%2F)

~~~
angelortega
Email him.

~~~
t0
You might be able to curl the page.

------
blackdogie
On the case of useful emails
[http://five.sentenc.es/](http://five.sentenc.es/) is quite a nice idea,
polite and to the point. There is also the shorter version,
[http://two.sentenc.es/](http://two.sentenc.es/) if you are so inclined !

------
dchichkov
Perhaps a pre-cooked auto-reply could fix that? Hey, it can even be automated;
a filter/answering bot for developers with public profiles ;) Showing only
heartwarming and applifting fun-mail and stowing everything else into spam
with an auto-reply suggesting a post to an appropriate mailing list.

~~~
joosters
Exactly. Think how many polite one-liner 'please post this to the mailing
list' replies he could have written in the time it took to create this
document. But instead, he expects people to waste their own time reading his
position piece. Narcissism.

~~~
MaulingMonkey
"Think how many polite one-liner 'please post this to the mailing list'
replies he could have written in the time it took to create this document."

The one liner isn't the expensive part.

First you have to read the mail. Then play twenty questions long enough to
figure out what they're actually asking about. Then suggest the proper mailing
list because you don't know anything about the subject. Then follow up when
they blithely ignore the suggestion, and the note that you don't know anything
about the subject, and are suggesting those who know everything about the
subject. Then follow up when they get upset when you in turn get insistent.
And then you answer in good faith when they ask why you won't....

That's the expensive part.

I've written my own rants. Shorter than the linked piece, granted, but the
linked piece is still shorter than any of many _single conversations_ I've had
trying to explain my position to the more insistent in response to their
questions. So many people are completely unfazed by my complete lack of
knowledge about whatever they want help with.

A linkable rant is more easily repeated to such people at much less expense of
my time. The points don't change much and can be stated more precisely and
concisely. Better yet: more obviously a waste of time when it is a waste. If
they're not actually interested, then we both win: I won't repeat it, and they
won't read it!

Rants like this are useful tools to end those pointless discussions. "If you
want my position, here it is. If you don't, then we won't have to waste both
our times arguing under the false pretense that you really do."

------
Sami_Lehtinen
So what if it's email? You can use DRY method and answer to it publicly. I
hate personal inefficient communication. If documentation lacks thing being
asked, update documentation. Don't answer the mail. Of course it would be more
efficient to handle these tickets using community than just one developer.
Answering queries publicly isn't as good method than updating documentation.
Depending from situation fixing program and usability is still better option
than updating documentation. I hate extensive documentation when updating
program version, if it could be done efficiently by automated script / proram.
I've been preaching about and utilizing this methodology last 15 years.

------
daleharvey
This is quite timely, in my general open source work I always do try to stick
to public communication channels, they have huge advantages.

But I am looking into making a project that helps first time open source
contributors write their first patch, and having a direct private channel for
the purpose of an introduction seems like it might help a lot.

[https://github.com/daleharvey/goodfirstpatch/issues/9](https://github.com/daleharvey/goodfirstpatch/issues/9)

------
qwerta
Had the same problem. I simply added statement to project readme, that I may
forward question to public lists. I refuse to repeat myself and documentation
for my project is not ready yet. For private conversation I usually require
donation.

Keeping information public is crucial for long-term success. You lose interest
and someone alse may want to takeover. But it is nearly impossible without
mailing list, unit tests, various prototypes and commit history.

------
spindritf
> you can say that subscribing to an email list can be daunting and flood you
> with hundreds or thousands of emails per month – that’s completely true

I guess you could allow non-subscribers to post to the list. Though that comes
with its own problems.

~~~
nzp
On all mailing lists I'm on that allow non-subscribers to post (a few high-
profile FOSS projects) the benefits far outweigh drawbacks. A few individuals
periodically complain about reply-to policy and duplicate emails (which, if
you're reasonable and take a few minutes to set things up, are non-issues)...
Spam is, mostly, minimal.

------
exo_duz
Efficient communication is key to this. I think that time is precious
especially when you're doing a startup (e.g. me).

The less distractions and more streamlined your process are, the more time you
save to be able to do other work.

------
001sky
_Sunlight is the best disinfectant_

For many things, and the in-box oo

------
knodi
I'll email you if I want. Just don't reply.

------
djim
stupidest shit ive ever read. dont even care who you are, you aren't more
important than anyone else. your time is not more valuable. emailing someone
is a perfectly normal way to have 1:1 conversations. abusing mailing lists and
excessive cc's just create noise.

~~~
otikik
No.

~~~
djim
Yes. Perhaps 1:1 emails aren't the answer, but the mailing list ovbiously
isn't working in this case. How about a forum for mass communications? That
allows for phyudo- 1:1 conversations while allowing the community to monitor
the response. Mailing lists are noisy and contain a lot of useless information
for most people subscribed to the list. So much that email providers like
Google have added features into their mail clients that allow you to "mute"
conversations that aren't specifically addressed to you. Like mailing lists.

