IOD: Help us Improve Developer Chats

I've been involved in several chats hosted on MSDN recently. Today I was talking to someone internally who was also working on scheduling chats for his team. We both complained about the  overhead involved in scheduling and running a chat at Microsoft.  In truth there aren't many barriers and Jana's team does a great job working with the current system and process. Sure, the step by step documentation we have look intimidating, but the process works like this for us:

  1. I decide to host a chat with my team
  2. I open the internal chat schedule calendar, find an open spot on the developer chat schedule and "reserve" the MSDN chat room.
  3. At the same time I write up my chat title and abstract and submit that with my request.
  4. Then I create a calendar item with a real conference room or dial-in number that is sent out to the team members I want to participate.
  5. Now I have to track down a chat Moderator and invite them as well. It doesn't seem like there are currently enough moderators internally since they are hard to come by. I think I owe a LOT of favors for the chats I've hosted and I hope they don't bring their hammers after me to collect any time soon. :-)
  6. Get the chat advertised on the chat page, newsgroups, blogs, dev centers, etc.
  7. On the day of the chat the process really gets handed off to the moderator who seems to have to following responsibilities:
    1. Makes sure everyone from Microsoft shows up a little early to install the chat manager tool we use to track the questions, question owners, participants, transcript, etc.
    2. Makes sure MS people have "MS" after their names
    3. Makes sure MS people have read/write access rather than just read only access. (Not sure why this step is required.)
    4. Teaches the MS people how to use the chat tool. (I admit that it could be simpler.)
    5. Instructs MS people to prepare their short bios.
    6. Counts down the time to the start of the chat and instructs people to post their bio's in order.
    7. Directs the participants to stay on topic. "No, the source safe team can not tell you why Windows 98 doesn't recognize your USB device."
    8. Boots anyone who strays really off topic. "No, the female developers will NOT tell you what they are wearing. Goodbye!"
    9. Counts down to the end of the chat.
    10. Collects the Q/A from the transcript and submits it to be posted for download on MSDN.

At a recent chat I asked the participants how they had heard about the chat.  A majority of them seemed to imply that they found out on the day of or close to real time an decided to stop by.  This made me wonder...

Why not have more topical chat rooms like IRC channels for teams to use so there is no need to fuss with a central scheduling calendar.  Then the team could decide to host a chat at any moment, post a blog entry, a newsgroup post, etc go into the room, and start answering questions with the people that heard about the chat in real time and where interested in stopping by. 

  • Would people come or would there end up being too many overlapping chats?
  • Would it be as useful?
  • Would people leverage the channels to get questions answered when MS people aren't around? Sort of like a more real time newsgroup.
  • Are the product teams better off having scheduled "Answer Bashes" on developer forums? (We tell you all to post your questions and product teams "bash out" as many answers as possible in real time. )
  • I'd also like to know if any of you have ever leveraged a chat transcript to answer a question or simply because you wanted to see what was discussed?
  • Do we do too many chats or too few?

Any thing else you think we could do to make the developer focused chats better? In the mean time I think its time to train more moderators. :-)