Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

tsee (4409)

tsee
  reversethis-{gro.napc} {ta} {relleums}
http://steffen-mueller.net/

You can find most of my Open Source Perl software in my CPAN directory [cpan.org].

Journal of tsee (4409)

Monday October 20, 2008
02:25 PM

Tired of ignorant users

[ #37706 ]

Warning. A bit of a frustrated rant ahead.

I have many, many distributions on the CPAN and have been struggling very hard to support them as well as I possibly can. Unsurprisingly, providing user support and fixing bugs is not the only thing I do and certainly not the only thing I like to do. In order to be a good CPAN citizen, I have adopted various unmaintained modules and applied tiny changes or made large overhauls resulting in a total of 488 .tar.gz files in my BACKPAN directory. Sorry if I'm coming across as a narcissistic, self-righteous bastard, but I'm trying to get across that the time it takes to maintain all that is not negligible.

One of those distributions is PAR, the Perl Archive Toolkit, and many are related. If you happen not to know what that is, it's a set of tools for packaging, managing, and distributing binary packages of Perl code and related resources and was written by Audrey Tang. It's a complex and very system dependent piece of software and I'm very, very glad that unlike many other packages in my CPAN directory, I'm not the only one who works on it. There is an active mailing list with quite a few incredibly nice, competent, and patient subscribers. In particular, there are various people who have a better overview over the code and its peculiarities on some platforms than I do. (I don't do Windows nor MacOS, for example.)

Now, each and every manual page of a PAR-related module states explicitly that support requests shall go to the PAR mailing list and bugs to the request tracker (which also sends a copy to the list, thanks to Jesse Vincent's tireless work). The PAR homepage prominently displays that same information and nowhere does it as much as mention me.

Regardless, I regularly receive support requests for the PAR modules from users to my personal e-mail address. I'm glad to hear they're using PAR, but they're usually very badly written and do not even give enough information for me to help them.
So far, I think I have answered all of these mails except maybe a handful that were either extremely impertinent or just unlucky because I was much busier than usual.
I started replying with an answer to their problem if I had one. Eventually, I grew tired of that and gave them their answer after noting that they should follow up on the mailing list.
This, however, has turned out to be highly ineffective. Those who got their answer usually didn't end up participating in the mailing list but just disappeared again.

How do you solve this dilemma? I still want to try to help wherever I can, but should I really spread my spare time thin between those who read the documentation, do some testing, and write a well-phrased mail to the mailing list and those who just send me a two-line mail saying that my shit doesn't install on their computer with an unspecified operating system? I'm exaggerating here. There's lots of shades in between.
Replying simply RTFM or Send it to the mailing list and include your system details and logs feels really rude. Forwarding the terrible thing to the list seems much worse: I'd be rude to those people who spend their spare time supporting the software. I'm actually thinking about not answering those mails at all unless they seem particularly interesting.

I can't be the only one in this situation. How do you handle this?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I don't think it's rude to ask people to send their question to the appropriate list. I do this for every single project of mine for which there is a list, and I have a very firm policy of never answering questions sent to me personally for said projects. I don't want to encourage bad habits.

    I usually just reply with something like "Please send all DateTime-related questions to datetime@perl.org."

    It's short, but I don't think it's rude. The person who sent me personal email was the rude one, if anything, fo

  • Users will do the simplest, most obvious thing (to them). Looking up the author on search.cpan and mailing them directly is often just that. And it works universally for all modules, rather than having to examine the documentation of each one and following each individual's instructions.

    Given that, there's really no way to stop it. And there's useful signal in each bit of feedback. I'm just glad for the feedback and I forward them quietly to the appropriate email address and deal with it (or let it be

  • BTW search.cpan.org now supports customizing the "discussion forum" link using the MailingList resource in META.yml... or it did. It seems to have disappeared. I'll ping Graham.

  • Part of what will make things easier is if you adjust your goggles. Instead of seeing them as ignorant, there are any number of other potential explanations for why they sent you the mail. In any case, don't see it as a character flaw. Makes life much easier to deal with.

    Second, there's nothing at all rude about redirecting someone to a list. Explain to them how they can better serve themselves. Make it about helping the person, not about how you're not interested. "I'm sorry but I think you'll get a

    --

    --
    xoa

    • You appear to be ignorant of the fact that ignorance is not a character flaw!

      --
      rjbs
      • Exactly. Perhaps a replybot or boilerplate reply with all of that text explaining why you can't personally triage their problem.

        Hi $name,
            Please send your questions about $thing to $forum. Sorry for the automated response. Per-incident support is available via $company at $rate/hr. Tips for asking good questions are available at $link. You may also find your answer in $faq.

        Thanks

        That will at least solve the ignorance. Laziness, selfishness, &c may lead some to feel that this was rude of you, but that's an ignorance you can't correct via e-mail.

  • That's how emails to Tim Bunce about DBI seem to be handled, and I don't see a problem with that. Even if I see the bit about the mailing list in the AUTHORS section of PAR, I may be under the impression that I have to join the list, which I don't want to do. So emailing the author or filling out an RT ticket may seem to be the best way to just report the problem.
    • Exactly. You can simplify the workflow, in fact, by just replying with a note asking them to please not send you support questions directly and telling them that you are redirecting their question to the mailing list – which you then include in the list of recipients, making sure to quote the original mail in full. That boils the whole process down to a single action.

      It’s not rude to redirect them. If anyone is being rude, it’s them.