Don’t email me
daniel.haxx.se
daniel.haxx.se
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.
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.
In any case: the fact that people may expect answers does not imply he is rude not giving them.
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.
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.
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.
A) Message gets ignored, no response
B) Other people respond with the same problem, no solutions
C) Unhelpful response detailing the solution to some superficially similar but unrelated problem
D) Excoriating reply about how that is not really a problem because I am bad at life and/or not supposed to be using it for that.
E) Discussion pace on the topic rapidly log-descent-curves into zero without anything really being resolved but lots of time being spent.
F) Discussion on the mailing list is so high volume that trying to pay attention to it is akin to drinking from a firehose, and a solution is posted in an unobtrusive way 330 messages later.
This is even true when attempting to make meaningful contributions of time and energy, money, or both.
- user agents that thread properly
- long expiration times for local caches (spools)
- cultural norms (that differed from group to group) about replies, new posts, quoting, and FAQs
- groups are folders: the participant needs to make a decision to subscribe to a group, and then each time to read one group at a time, rather than trying to handle a dozen different groups in date-received order
- and for a mixed blessing, search over the current spool was reasonably easy but general search was hard or impossible.
I still don't know how I can pipe a reddit comment into patch(1) or git(1). I can do that easily with mbox files (which can come from SMTP or nntp-to-mbox.pl(1) or something).
When you subscribe to a mailing list you cannot easily fetch older emails to get some context, you usually have to use some web interface. If you want to manage your subscriptions you have to use an other web interface, you can't usually do it easily from your mail client.
There is no standard way to subscribe to a mailing list either, you have to hunt for the subscription form.
That being said, in this day and age using dedicated protocols is not really "in" anymore so I don't expect NNTP to make a comeback. I still think that a good web forum would still be a massive improvement over most mailing lists.
That's what google groups could have been by the way, if Google had cared enough to make it worthwhile.
Maybe a HN-style discussion "tree" with no upvotes/downvotes or external links but the possibility to add attachements (and maybe gateway interfaces with SMTP and/or NNTP) would be the killer of mailing lists.
This is not true. I haven't seen any mailing list for which I can't manage my subscription with SMTP. They might exists, but almost everyone use mailman which works fine.
> There is no standard way to subscribe to a mailing list either, you have to hunt for the subscription form.
Just send an email to list-join@fqdn or list+subscribe@fqdn. It's really a pity google groups is inferior even to mailman, but I guess you can't have nice things.
Yes, nothing is standardized, but it works well enough with extremely little infrastructure, both on server side, and especially on client side. NNTP requires more infrastructure on both sides.
You're right, but as you point out that's not standard. It's not usually directly integrated in your mail client. It's just a hack. NNTP clients have all that baked in.
> Yes, nothing is standardized, but it works well enough with extremely little infrastructure, both on server side, and especially on client side. NNTP requires more infrastructure on both sides.
I don't think NNTP requires more infrastructure on the server side (installing mailman vs. installing a NNTP daemon) but you're right that it does require installing a client on the client side (since everybody already has a mail client anyway. That's why I said I would be fine with a well designed web app to replace mailing lists.
While not standardised, I expect any decent e-mail client to handle mailing lists mostly automatically at least in that regard, e.g. Claws-Mail builds a nice menu from List-* headers. It is true that one usually needs to manually add filtering on the server side (in Sieve, maildrop or whatever you use), which is not as nice as the standard handling of news, but you can even automatise that if you’re willing to have emails containing random headers create the corresponding folders (which, of course, you shouldn't do).
> I don't think NNTP requires more infrastructure on the server side (installing mailman vs. installing a NNTP daemon) but you're right that it does require installing a client on the client side (since everybody already has a mail client anyway.
Most email clients also have NNTP support baked in, so the client side is not really an issue. However, newsservers have to keep at least a rolling archive of messages and possibly federate with others, whereas a mailman installation is mostly stand-alone and doesn’t even have to keep an archive if you don’t want to.
Then there was the software that supported NNTP---all requiring arcane black arts to keep running smoothly. As much as I loved Usenet back in the day, administrating Usenet (or NNTP) was something I loathed. The server side stuff was just horrible.
So my first wording was actually correct: "newsgroups are mailing lists done right" :)
[1] https://en.wikipedia.org/wiki/Network_News_Transfer_Protocol
Spam, AFAIK. I don't know why, but spam on mailing lists seems relatively rare, compared to usenet which was ~99% spam last time I looked.
Mailing lists have a central place where all messages come in, and that can ban spammers. Usenet is distributed and messages come from everywhere, so any spam protections needs to be done in the client.
1) First hand, official documentation is the only one that matters. No blog posts. Some projects have very bad, or inexistent documentation, but those are probably not worth using anyway. I have found software and documentation quality to be very strongly correlated.
2) If you want to participate, or you have a deep problem that can't be solved by reading the documentation, mailing lists are the way to go. Web forums, stackoverflow and similar things are an awful waste of time. Do your homework before posting to a mailing list. If you send HTML emails and/or you don't fmt(1) or par(1) your email, you will be ignored.
3) IRC is great for social interaction. Sometimes you'll solve a minor problem on IRC, but that's not what it's for. You can learn a lot on IRC just by listening to other people talk about technology.
Still using a mailing list nowadays is like using that web-to-email gateway Stallman uses.
The only thing missing in a mailing list is a good archive for new members; the web UIs are usually terrible. Personally, I wish I could just get an archive file (zip, tar, etc) of a certain period of time.
The reason it's lacking shows the problem with mailing lists: they restrict participation to those who were members at the time. Yes, there's a limited ability to have search after the fact, but most of the web UIs are awful, and the search is weak.
Worse still is if you join late and somehow find a thread from 2010, there's no way to revive it with updated information or corrections. So the archives suffer terribly from bitrot, in some cases sending latecomers down the wrong path for years to come.
In a well-designed forum, by contrast, threads "live" forever. When something useful needs to be said or asked, a thread can spring back to life. As a result, their archives remain useful for longer, and they don't need to suffer nearly as much from newcomers asking the same old FAQs, either.
To boot, with the right forum, you can also have posts sent to your email, for all the local benefits you mention.
Three data points/opinions:
- at least some mailing lists let you download an archive file for a given month, e.g. [0].
- I much prefer navigating the web interface of a mailing list than navigating a forum, simply because most forums lack proper threading, not to mention the bazillion of blinking .GIFs, unnecessary Javascript and all that other superfluous crap that is completely irrelevant to the discussion.
- Not to mention that searching a mailing list archive is trivial if you keep it locally and even if you don’t, it will still work. Trying to find something on e.g. talk.maemo.org, I always have to resort to Google with some site: operator, and even then the results are usually worse than those returned by a comparable search run on the web archive of a mailing list.
"But how else can you manage the volume of messages?" I hear you cry. Well, having only a single "thread" forces you to use social pressure to keep the discussion on topic.
A forum can have obscure corners which people start to use for off-topic discussions, or general mouthing-off or project gossip. That kind of noise can't be tolerated on a mailing list - because there's no good way to ignore it. So the off topic stuff is pushed out, and the discussion remains mostly on-topic.
The "social pressure" that keeps mailing list discussions on-topic is often interpreted by newbies as "rude people shouting at them", and perhaps that's accurate. But the end result is worthwhile.
One man's gossip is another man's networking. Your off-topic rant might be my eureka moment.
That mailing lists discourage participation for fear of savagery from list members who can't find what they care about is a bug, not a feature.
I love them, really I do, but it only takes 0.1% of the user-base to naively believe that it's easier to ask for help than to RTFM, and bang - there goes 110% of your time dealing with them.
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)
Give me a big threaded forum where each "category" corresponds to its own mailing list (so you can just avoid email-subbing to the "offtopic" one). Then you can also include some nice secondary features like upvotes/downvotes and the like.
That's basically what Google Groups used to be (I haven't used them in awhile, so no clue if they've changed significantly since then): at its heart, it's NNTP. You choose to receive messages as they come, or in digest form. You can either reply to the email, or login to the web interface and reply there. The web interface groups discrete email subjects as separate forum posts (with some mild intelligence to lump "some topic" and "re: some topic" together).
It's not without its own set of issues, but I found it a good compromise since those who only wanted to interact with the email interface could keep that, while those that wanted a more full-featured forum experience could do so as well.
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
Of course that's useful - good documentation is important.
Is the best way to write that documentation a mailing list? I seriously doubt it.
And that said, I'm not discussing 'googling for mailing list archives to solve problems', I'm discussing 'attempting to email the list to solve problems'.
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.
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>
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, not including "can we have feature x from language y" requests, most obvious issues (garbage collection performance, crypto, http and html libraries etc.) are being addressed in a logical and timely fashion.
If I were wearing a hat, I'd take it off for you.
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."
The statement you quoted was meant (although not in any way obvious) to be a resigned statement of acceptance that, given a certain size, there will be those in any company that demand special attention, and sometimes it's a battle you can't win. Although it does throw everyone else's schedules out of whack.
I was just trying to point out some of the downsides that I've shared with my teams who are sometimes too eager-beaver to work in pecking order rather than priority order. People generally want to do the right thing; sometimes they need help framing what that right thing is.
If you're the head of a company, or indeed anyone leading a team, please take note of the above point. Trust your people to do their job (you can still measure their performance) and they will trust you to do your's.
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.
Even if I'm wrong, comments on pull requests are certainly notifications for everyone who is watching the repo.
Watching is if you actually want to pay attention to activity as opposed to just bookmark something.
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.
Yeah, well, maybe that's a bad idea?
There is another big FOSS project I know which has its own bug tracker from way back when (horribly outdated, frequently malfunctioning, terrible usability) and then they have their new GitHub tracker. The result? If you want to file anything, you have to file it in both systems.
What I'm trying to say is: You have to make a choice at some point. Either you move forward and solve problems, or you stay where you are. But don't blame the move forward for not allowing you to stay where you are.
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!
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."
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.
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.
I guess you could allow non-subscribers to post to the list. Though that comes with its own problems.
The less distractions and more streamlined your process are, the more time you save to be able to do other work.
For many things, and the in-box oo