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.
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.
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.
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.
it's extremely rare I've had mailing lists deliver value
According to my memory and browsing history in this week I've been able to find solutions to issues in Emacs, Doxygen and Cygwin by Googling and ending up to their relevant mailing-list threads.
It is awesome that mailing-lists get archived and the problems (and solutions) other people had can be queried. Sure, I wasn't the first person to encounter these issues, so they had been already found and circumvented. Anyway, the issues/questions had been sent to mailing-list and they had been answered.
If mailing-lists didn't work, I wonder why Linux kernel manages to evolve at all. Sure, mailing lists aren't Stack Overflow where you get karma and gold medals for providing solutions.
I never understood why mailing lists prosper when newsgroups are mostly dead. Newsgroups are mailing lists done right (or rather, mailing lists are newsgroups done wrong).
I like to use gmane to browse projects' mailing lists and post to them. I use a NNTP client to do this. It's great when it works, except for the few cases where posting is broken (seems to be mostly google groups lists).
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.
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.)
>(Obviously precluding the Directors / VIPs in the company)
You might be surprised how infrequently "VIPs" want special treatment. When they do, IME, they'll make it perfectly clear, but in a healthy org, most senior people would prefer IT to work on the company's highest priorities.
If you give white glove treatment to every exec, everytime, you're not only working out of priority order, hurting the company today, you're also hiding a potential capacity problem for the future. "What do you mean help desk needs two more hires? Everytime I call, two techs come a-running; there's NO WAY they need more staff. Next."
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.
Because they don't go to the mailing list. For a lot of OSS communities, if it didn't happen on the list, it didn't happen. That's certainly how it is in all the big projects I've interacted with. I'd LOVE for a way to cc a mailing list on all PRs to a project, but that's not possible AFAIK.
Most PRs I reject with "this should be a patch sent to the list" simply because I'm not always the only one that should review something.
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.
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!
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. :/
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.
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.
On the case of useful emails http://five.sentenc.es/ is quite a nice idea, polite and to the point. There is also the shorter version, http://two.sentenc.es/ if you are so inclined !
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.
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.
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.
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.
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.
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.
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.
Emailing is a good way to have 1:1 conversations, but the whole point is that in many circumstances you aren't entitled to get a 1:1 conversation and personal attention of a busy stranger, so use the maillist or go away.
[+] [-] casca|12 years ago|reply
[+] [-] sebcat|12 years ago|reply
[+] [-] pfortuny|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] jaggederest|12 years ago|reply
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|12 years ago|reply
[+] [-] jzzskijj|12 years ago|reply
According to my memory and browsing history in this week I've been able to find solutions to issues in Emacs, Doxygen and Cygwin by Googling and ending up to their relevant mailing-list threads.
It is awesome that mailing-lists get archived and the problems (and solutions) other people had can be queried. Sure, I wasn't the first person to encounter these issues, so they had been already found and circumvented. Anyway, the issues/questions had been sent to mailing-list and they had been answered.
If mailing-lists didn't work, I wonder why Linux kernel manages to evolve at all. Sure, mailing lists aren't Stack Overflow where you get karma and gold medals for providing solutions.
[+] [-] simias|12 years ago|reply
[+] [-] xioxox|12 years ago|reply
On the website of my project I point users to the blog-like interface to gmane, which can be used to browse and post to a list: http://blog.gmane.org/gmane.comp.graphics.veusz.general
[+] [-] enneff|12 years ago|reply
[+] [-] dasil003|12 years ago|reply
[+] [-] Intermernet|12 years ago|reply
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|12 years ago|reply
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.)
[+] [-] sokoloff|12 years ago|reply
You might be surprised how infrequently "VIPs" want special treatment. When they do, IME, they'll make it perfectly clear, but in a healthy org, most senior people would prefer IT to work on the company's highest priorities.
If you give white glove treatment to every exec, everytime, you're not only working out of priority order, hurting the company today, you're also hiding a potential capacity problem for the future. "What do you mean help desk needs two more hires? Everytime I call, two techs come a-running; there's NO WAY they need more staff. Next."
[+] [-] skore|12 years ago|reply
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.
[+] [-] durin42|12 years ago|reply
Most PRs I reject with "this should be a patch sent to the list" simply because I'm not always the only one that should review something.
[+] [-] TheSilentMan|12 years ago|reply
Even if I'm wrong, comments on pull requests are certainly notifications for everyone who is watching the repo.
[+] [-] joosters|12 years ago|reply
[+] [-] dspillett|12 years ago|reply
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!
[+] [-] reginaldjcooper|12 years ago|reply
[+] [-] mgkimsal|12 years ago|reply
[+] [-] p4bl0|12 years ago|reply
[+] [-] ameoba|12 years ago|reply
[+] [-] t0|12 years ago|reply
[+] [-] angelortega|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] blackdogie|12 years ago|reply
[+] [-] dchichkov|12 years ago|reply
[+] [-] joosters|12 years ago|reply
[+] [-] Sami_Lehtinen|12 years ago|reply
[+] [-] daleharvey|12 years ago|reply
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
[+] [-] qwerta|12 years ago|reply
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|12 years ago|reply
I guess you could allow non-subscribers to post to the list. Though that comes with its own problems.
[+] [-] nzp|12 years ago|reply
[+] [-] exo_duz|12 years ago|reply
The less distractions and more streamlined your process are, the more time you save to be able to do other work.
[+] [-] 001sky|12 years ago|reply
For many things, and the in-box oo
[+] [-] knodi|12 years ago|reply
[+] [-] djim|12 years ago|reply
[+] [-] PeterisP|12 years ago|reply
[+] [-] otikik|12 years ago|reply