<div class="gmail_quote">On Tue, Jul 7, 2009 at 6:57 PM, Onno Benschop <<a href="mailto:onno@itmaze.com.au">onno@itmaze.com.au</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On 03/07/09 11:44, Andrew Sayers wrote: > when someone comes to you with a problem, first > fix the presenting problem, then fix the second-order problem that > caused it, then the third-order problem, and so on back to the original > source. Although this significantly increases the amount of work per > issue, it's more than offset by the reduction in the number of issues. > </div>This approach speaks to me in many ways. As the manager of an IT help-desk for 5000 seats in the mid-90's I instigated a regimen where user problems were fixed by users. The way that worked is that the IT professionals were discouraged to just "click and fix" a problem, they had to explain to the user what caused the issue, how they got themselves into the problem, and how to dig themselves out. This met with lots of opposition. * Users were upset that phone calls took longer than "click and fix". * Management was upset that call queues were escalating and that number of resolutions processed were declining. * Helpdesk staff felt unloved because they couldn't just be a hero and fix the problem. It has been said that I'm a stubborn person and I persisted. After 3 months, something really interesting started happening. The number of calls to the help-desk started declining. Initially management thought it was because users were so fed up waiting that they stopped calling us. Further investigation indicated that users were having less problems. They were more confident, more knowledgeable and more able to help themselves. The kinds of problems we started seeing on the help-desk were meta-problems, not "click and fix" problems. </blockquote><div> Interesting solution, although I think it depends on how many people you're trying to help. We probably get enough *new* people needing help that the time spent would be self-defeating. Sure, that one person would be less likely to need help again, but in the meantime two new people show up and don't get any help because you're busy explaining to person A. Ideally, each time someone came up with a problem, the support person would write up a wiki article (or similar) with the full explanation, and then just copy and paste the link. It costs just as much time up front, but once a solid base of wiki articles are built up it should be able to move even faster than giving "click and fix" solutions. Again, an officially defined structure for the wiki would be nice. Perhaps something like <a href="http://wiki.ubuntu.com/Support/">wiki.ubuntu.com/Support/</a><release>/<category>/<article-title> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It seems to me that emails to this list alone show an increasing trend towards support style questions. We could coordinate a response effort, say, emails coming in on Monday are dealt with by one person, Tuesdays, by another, etc. Spread the load among several "sign-posters". How scalable this is across the community, I'm unsure. </blockquote><div> I think that's too structured for a community-driven effort. If Canonical wants to hire people to monitor #ubuntu-signpost, and structure it like that, then great. As a collection of volunteers though, that's too much of a precise commitment. I try and help out when I can, but my schedule is never defined enough for me to dedicate a specific block of time to it. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> IIRC there is a company in the Netherlands (I forget its name), that decided that more than 15 employees was too many. Keeping track of each other becomes too hard, being social with all colleagues is too complicated, accounting becomes a means in itself, etc. If the company grows to that size, it's sales territory is split in half and the company is split in half. Rinse and repeat. We could do a similar thing with IRC channels, though I don't know if that would result in users flocking to the single place where people are responding - we see it today where people come into #ubuntu-server because "no-one's responding in #ubuntu" </blockquote><div> Very interesting company. Again, I would think that a lot of the problem is that #ubuntu is just overcrowded. Ideally it would be a signpost as well. Unless you're a volunteer directing people, we want to try and move you off of the signpost and to the proper subchannel ASAP. As soon as more than x people actively seeking help are on a channel (not sure how many in this case), it becomes hard for new people on the channel to get attention. The trick would be to get the volunteers onto the right subchannel so that when someone on #ubuntu points the user to #ubuntu-sound, there are a couple of people on #ubuntu-sound to help them. Otherwise, they'll just go back to #ubuntu and start complaining. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I have a fair amount of experience speaking to large groups but I've been trying to think how I might apply those skills to teaching a class of say 1000. How do you do such a thing on a mass scale? IRC is a useful tool to talk to lots of people online, but it's hardly useful as a means to show someone what's on the screen now and what it means. It also requires that students have a set-up where they can follow along in real time. Using electronic white boards, or webinars, or streaming video all feel pretty clunky to me and hardly the way to help so many. </blockquote><div> An up-to-date / better-organized wiki would help, but it lacks interactiveness. I think it's the best we can do on a global basis though. Even though many people may have the same problem over the lifecycle of a release, they won't all have it at the same time. Anything the requires actual useful interactivity requires a human at the other end, with a fair amount of time per problem. That just isn't feasible. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I've also wondered if 5 minute vod/pod casts might be a way to help solve particular issues. The argument for is that it's a digestible chunk of "monkey see, monkey do", but all the FAQ's and wiki documentation to date doesn't appear to stem the flood of questions that seem to already have an answer, so perhaps the teaching needs to focus on "how to help you help yourself". </blockquote><div> The other issue with casts is language. The wiki can be translated automagically by google or bablefish, but casts can't. On a somewhat unrelated note, as soon as I saw "how to help you help yourself" I immediately thought of Let Me Google That For You [1], although I'm not sure how the concept would apply in this situation. I just thought I'd toss it out there in case somebody else sees a useful parallel. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The individual comments in this thread are heartening and indicate to me that there are others thinking about this. What I don't know is if the proposed methods can scale more than a single order of magnitude, which is not even close to being enough to deal with a bell-curve that is heading this way. It would be really productive if we can come up with a process that leveraged the size of the community, but I'm yet to figure a way that we can "pass it on". </blockquote><div> Optimistically speaking, I think you're underestimating the community itself. Look at, as an example, Microsoft. Sure, they offer some help online in official documentation, but that's rarely the first hit when you google a problem. Chances are it's a site like Eldergeek [2] instead. I would guess / hope that right about when we hit the big influx in users, we'll get another whole slew of people who would operate sites like Psychocats [3]. While ideally they should all be integrated into the Ubuntu support section, I'm not complaining as long as they get the job done. </div></div> [1] <a href="http://lmgtfy.com/">http://lmgtfy.com/</a> [2] <a href="http://www.theeldergeek.com/">http://www.theeldergeek.com/</a> [3] <a href="http://www.psychocats.net/ubuntu/index.php">http://www.psychocats.net/ubuntu/index.php</a>