The psychology of naming your internal distribution lists

Date:November 9, 2005 / year-entry #342
Orig Link:
Comments:    8
Summary:One problem that I'm sure everybody has run into is what I'm going to call the "comp.unix.wizards" problem. People who have a problem with unix are looking for someone who can help them, and given the choice between a general questions group and a wizard group, they're obviously going to choose the wizards because that's...

One problem that I'm sure everybody has run into is what I'm going to call the "comp.unix.wizards" problem. People who have a problem with unix are looking for someone who can help them, and given the choice between a general questions group and a wizard group, they're obviously going to choose the wizards because that's where the smart people are! Of course, this annoys the wizards who created the group for focusing on advanced unix topics.

Here's a trick I've seen used by more than one team: Give your non-technical distribution list the name "XYZ Technical Discussion". Meanwhile, name your internal team communication distribution list something less attractive like "XYZ Infrastructure Committee". Your "XYZ Technical Discussion" list will get the support questions, and people will feel like they're getting a "more direct line" to the technical staff. In reality, of course, the technical staff read both the "XYZ Technical Discussion" and the "XYZ Infrastructure Committee" groups. This is just a trick for keeping external support questions separate from internal team communication.

(Now, by revealing this trick, I risk ruining it.)

Comments (8)
  1. Bryan says:

    they’re obviously going to choose the wizards

    > because that’s where the smart people are!

    That’s why changed its name to, at least. They wanted to become a place that wasn’t "just" for newbies.

    Anyway, I’ve found that it sometimes helps to have separate <project>-support (or <project>-users) and <project>-dev mailing lists/forums/whatever. As long as -support or -users is clearly marked (and the documentation for <project> points at it), the right people read the list/forum, and it’s mentioned first, that’s usually enough.

    Of course there are always a few people that post support questions to the -dev list, but usually it works to just point them to the right list when it happens.

    (OTOH, most -dev lists I’m familiar with are not "internal", either. Hmm.)

  2. Garry Trinder says:

    You your own suggestion inside Microsoft.

    Take a look on

    "C# General" forums has a lot of request related to .NET Framework – not language.

  3. Vince P says:

    I love when people use Raymond’s articles(?) as sounding boards about all things Microsoft.

    Have these people ever tried the mental excersize of putting themselves in his shoes. From their tone, I bet that wouldn’t be taking too kindly scores of messages from people complaining about things they have no control over.

  4. Vince,

    Remember, in this day and age it is now an art to bash MS.

    There are companies, like ZDNet, who play it both ways. MS advertises on ZDNet. David Berlind posts stuff all the time bashing MS whether or not there is any reason to do so (his recent stuff about Mass. is rediculous). Those who love to hate MS visit ZDNet more and more to vent their emotions giving ZDNet a higher reader base. ZDNet then charges MS more because the "advertising real-estate" is more valuable because more people are visiting the site.

    You just have to love the genius behind this. When MS makes FUD against anything, it’s "bad old Microsoft being the schoolyard bully again. Oh woe is me, the 800lbs gorilla is at it again trying to assimilate us all into the collective."

    But FUD against MS, whether true or not, is a big money making machine.


  5. BT says:

    > (Now, by revealing this trick, I risk ruining it.)

    Not true, the peaple who would fall for the trick in the first place most likey would not be reading your block.

  6. Cooney says:

    Wouldn’t the solution for comp.unix.wizards be to forge a cancellation for noob questions?

    //spent too much time on NANAE

  7. MSDN Archive says:

    Our team’s distribution list used to have "Public Key Infrastructure" in the name. Bad idea. We kept getting mail from people all over campus who had lost their keycards to get into their buildings. After a few weeks we changed it to "PKI". Problem solved.

  8. Moz says:

    ASR got round this by being moderated… but having no moderator. Anyone unable to forge an approved: line couldn’t post :) Although to some degree the name (alt.sysadmin.recovery) is not suggestive of "good place to ask for help". It did get a variety of early spam though (and who in their right mind is going to spam the place most likely to have people able to act on their dislike of spam…)

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index