Don’t email me(daniel.haxx.se)
daniel.haxx.se
Don’t email me
http://daniel.haxx.se/blog/2013/10/08/dont-email-me/
19 comments
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.
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.
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.
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.
In any case: the fact that people may expect answers does not imply he is rude not giving them.
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).
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.
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.
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.
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.
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.
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.
Well, I'm with him. If you are trying to work collaboratively, mailing lists are absolutely the best way to get stuff done.
[deleted]
Yes, I agree. From my experience I learned that:
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.
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.
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.
Still using a mailing list nowadays is like using that web-to-email gateway Stallman uses.
Forums are OK, but second-best. The problem I see with a forum is probably the thing you like about it: messages are broken up by (arbitrary) "topic" or "subject". Basically, each thread in a forum operates like its own little mailing list - that enables someone to ignore parts of the discussion. They will then inevitably miss something that they needed to have seen.
"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.
"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.
What you're saying there is essentially "mailing lists don't scale".
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.
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.
You've nailed it, except I still think it's a feature not a bug. I think you might think that way too, if you'd been involved in an open source project with tens of thousands of non-technical users.
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.
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.
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)
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)
There is an opportunity out there. I am sure of it.
Reddit
Why? Mailing lists have a common UI (your email client), they are easier to archive locally, messages are processable entities (can be easily tagged, filtered, forwarded, etc) and they can be used when the service is offline.
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 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.
I think "a good archive for new members" is more important than just the "only" suggests.
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.
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.
Fair enough, but frankly well-designed and well-run forums are few and far between. And even less support real threading, which I consider a killer feature for this kind of discussions.
> 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.
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.
[0] http://mail63.csoft.net/pipermail/ldmud-talk/
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.
[0] http://mail63.csoft.net/pipermail/ldmud-talk/
I can't figure why "forums" and "mailing lists" are two separate things. Making a nice unified mailing-list/forum hybrid doesn't sound impossible... honestly though, most maling-list web-views are terrible and excruciating to navigate.
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.
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.
> Making a nice unified mailing-list/forum hybrid doesn't sound impossible...
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.
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.
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.
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 never understood why mailing lists prosper when newsgroups are mostly dead
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.
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.
> I don't know why, but spam on mailing lists seems relatively rare
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.
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.
Care to elaborate? I tried to research why Usenet was superior to more recent communication channels, but my Google fu fails me every time.
I'm not necessarily talking about Usenet in particular but rather the "Network News Transfer Protocol" versus SMTP.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
Back in the 90s, I worked at several ISPs, and let me say that NNTP required more infrastructure than SMTP. First, you need to arrange for NNTP feeds. Then you needed disk space. Tons and tons of disk space, because most of the people using Usenet wanted the alt.binaries.* groups. Skimp out on those, and there was a sizable number of customers who would go elsewhere. Then you needed to configure your expiration policies (posts in alt.binaries.* expire after 24 hours; the rest of Usenet expires in two weeks, that type of stuff).
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.
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.
Usenet was superior because the average IQ was higher and people more knowledgeable. A normal consequence of access being technologically limited to academia and very tech-savvy people.
Usenet is superior because it evolved to handle large scale discussions properly. These include:
- 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.
- 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.
... all of which reddit (and to a lesser extent, slashdot and disqus) do just as well.
Comparing Usenet or even mailing list cultural posting norms with Reddit is asinine.
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).
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).
I hope you realize that the mailing list is older than Usenet!
I did not actually, for some reason I always thought NNTP predated SMTP but wikipedia tells me it was created as an alternative to SMTP for newsgroups[1]. The more you know.
So my first wording was actually correct: "newsgroups are mailing lists done right" :)
[1] https://en.wikipedia.org/wiki/Network_News_Transfer_Protocol
So my first wording was actually correct: "newsgroups are mailing lists done right" :)
[1] https://en.wikipedia.org/wiki/Network_News_Transfer_Protocol
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).
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
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
Those sound like dysfunctional projects, to me.
My typical experience is pick one or two of:
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.
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.
According to your bio you are a coder, so let me ask you this: have you never found an answer to a tech question in a mailing list archive?
A mailing list archive is a web site that happens to draw content from a mailing list.
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'.
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'.
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>
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>
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.)
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.)
Just a view from the other side of the fence; I've found the Go team tend to do a very good job of balancing core performance advances and addressing feature requests from the community.
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.
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.
Pray, tell me more about this distinction between almost infinite and very finite!
[deleted]
>(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."
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."
"in a healthy org" There-in lies the problem.
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.
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 hear ya (and understood your point). I agree that it's OK in moderation or when very specifically asked for (whether it's obviously justified or not).
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.
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.
I agree completely, and I'm happy to see examples of orgs where the execs / directors respect and realise that the teams that they hire (IT, HR, Sales, Pick / Pack, whatever) will do the best job they can given the opportunity. The feeling of trust in employees is tangible, and therefore mutual and reciprocal.
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.
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.
Seconded! At my company, our support staff are explicitly instructed not to treat anyone in the IT organization differently, but they do still bend over backward for the top business execs. As long as they consistently file postmortems and analyze root causes, I'm mostly ok with that.
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.
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.
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.
> For a lot of OSS communities, if it didn't happen on the list, it didn't happen.
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.
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.
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.
Even if I'm wrong, comments on pull requests are certainly notifications for everyone who is watching the repo.
That's why starring was released https://github.com/blog/1204-notifications-stars
Watching is if you actually want to pay attention to activity as opposed to just bookmark something.
Watching is if you actually want to pay attention to activity as opposed to just bookmark something.
Notifications on GitHub are still too coarsely-grained to be useful.
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!
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!
You're being sarcastic, but if their policy statement is on their webpage and you fail to find it or ignore it, yes you are being rude.
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.
Loading really slow. Mirror http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...
Email him.
[deleted]
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.
"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."
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."
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.
https://github.com/daleharvey/goodfirstpatch/issues/9
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
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.
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.
> 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.
I guess you could allow non-subscribers to post to the list. Though that comes with its own problems.
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.
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.
The less distractions and more streamlined your process are, the more time you save to be able to do other work.
Sunlight is the best disinfectant
For many things, and the in-box oo
For many things, and the in-box oo
I'll email you if I want. Just don't reply.
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.
No.
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.