LiveJournal Support Administration Forum

Guide Part II

leora — Thu, 29 May 2003 12:33:13 GMT

Remember, the anchor links in part I won't work for the text in part II since I had to break it into two posts. But anyhow, here's part II of the Guide. Feel free to comment on either part with suggestions or questions.

Interim Level One

After a volunteer has been helping in Support for a while, they may be given I1, the first interim priv level, in one or more of the Support categories. I1 conveys two privileges, supportviewscreened and supportmakeinternal.

I1 makes Support a bit easier by allowing a volunteer to focus on requests that have not yet been adequately answered. It also includes some responsibilities.

I1s are expected to keep screened answers confidential. They can see them for their own benefit, so they can concentrate their efforts. They should not be discussing these screened answers. If they have questions about them they can either email the category admin(s) for the category or bring them up in reviews. If an I1 is part of a mentoring program, then they can also ask their mentor.

I1s are expected to understand that not all screened answers are good models. Try not to pick up bad habits from other volunteers. If a screened answer isn't approved, there may be a good reason for that. Some volunteers will find that other screened answers offer them a better perspective on how ambiguous requests may be interpreted or what information might be useful to include.

I1s are expected to use internal comments wisely. While unprived volunteers have the ability to add internal comments as screened answers, these internal comments will be labeled as such. They are more eye-catching, and volunteers expect them to be important. Interim privs should not be commenting about shortcomings in other screened answers, what should be approved, or what needs to be in an approved answer. But internal comments can be used to share information on unusual requests.

The general guideline for internal comments is only post them if there is something beyond the routine that you feel other volunteers need to know about. Some good examples of internal comment use would be linking to previous requests by the same user if they relate or linking to Zilla items that relate to the request. Another good use would be linking to a suggestion that related to the request. However, don't link to standard well-known resources, since most volunteers will already be aware of them and it will just add clutter.

Internal comments are expected to be professional. The general guideline is that every time you leave an internal comment, you should be prepared for what you would tell the user if somehow it became visible. If you would not be able to handle that situation, you may want to re-think your comment.

Internal comments are not to be used for irrelevant chatter or to talk about a user behind his/her back. When you reach I2, you may see some internal comments that are humorous. Many of the internal actions require some text be left, as such, privs are allowed to leave off-topic comments in these cases, but they still must not be offensive.

When you earn your first I1 priv, you will be given access to support_interim. This community is a good place to ask questions specific to using interim privs.

Interim Level Two

By the time you are given interim level two in a category, you probably have a great deal of Support experience and a good feel for how Support is done. Many volunteers will find themselves at I2 level for longer than they were unprived or I1. This will of course vary from person to person, but it's a common occurrence. Try not to let it frustrate you. The step to supporthelp is a difficult one as mistakes made as a supporthelp can harm the users. As such, it is given out very carefully.We prefer to err on the side of taking longer.

The primary responsibilities of an I2 are to keep the screened answers and internal comments confidential, to move requests to their proper categories , and to refrain from trying to train new volunteers. Training is left to supporthelps, to lessen the chance of people being given inaccurate information. While I2s tend to be very advanced and knowledgeable volunteers, they are not quite ready to take on training.

Since I2s can change the category of requests and touch requests, they are expected to do so when appropriate. If a request is in the wrong category it is required that the category be changed first. Always check the category of a request before doing anything else with the request. Please read over the section on the purpose of each private category. It is very important that requests that should be in private categories get moved into them as quickly as possible. Remember, when in doubt, move the request to support@.

To change the category of a request select internal comment/action and the new category from the drop down. Include some text, this can be as little as "." if the change is obvious or a brief note about the request if you have anything to say, and then submit.

Touching a request will re-green it and mark it as needing more help. To touch a request select internal comment/action and check the box to touch a request. Then include some text and submit.

Since I2s can see other internal comments, they can see whether something has been pointed out yet or not. As such, they can use internal comments a bit more broadly. Useful things to leave internal comments about would include the current state of the user's information as it relates to the request. For example, if the user is trying to add memories, you can leave an IC about how many memories the user has. If the user is trying to change the bio, you can leave an IC about what the text of the bio currently is. This makes it easier to tell when the user has succeeded and the request can be closed.

You may see internal comments about things missing in Support answers or what is needed in an answer, but you should not make internal comments like this until you have the supporthelp priv.If you have made it to I2, you definitely have the ability to become a supporthelp priv if you keep at it.

Summary Tags

Being a Supporthelp Priv

There are many aspects to being a supporthelp priv. In its simplest form, you simply answer and approve things on the board. In reality, most supporthelps do much more than that. First, the obligations of a supporthelp priv.

Supporthelps have all the obligations of interim privs. They are expected to keep private information confidential and to treat all volunteers and users with respect. They are required to change the category of requests before doing anything else in the request. They do not have to handle any request they do not want to, even if they know how to, but if they do handle a request they must approve an acceptable screened answer rather than writing their own if an acceptable one is already present.

The abilities of a supporthelp are: to approve comments (see leaving comments) to approve answers (see approving screened answers)
to leave answers and comments (rarely used and usually discouraged) to change summaries (see summary change tags)

Supporthelps are also given membership and the ability to post in lj_support.

When you first gain supporthelp, you should look over the Support policy memories in lj_support. Some of the entries about policies will be friends-only. You will be expected to know and follow them. You should receive an email that will make this a little easier. The Useful Extra category also has some helpful friends-only material.

Many supporthelps will do more than just that. Supporthelps may be involved in giving reviews, mentoring, answering questions in the Support communities, suggesting good volunteers for privs, bringing up issues for discussion, and reporting volunteers when there are problems. To get involved in these activities, discuss it with the relevant category admins.

Remember, if you do a review you should send it to the volunteer and cc it to the category admin(s). For most categories you will then also be expected to post a summary in the category's community. To find out the specifics of your category, ask the admin(s).

If you do decide to mentor someone, please make sure that you keep in touch with your mentoree/manatee. If you cannot do the reviews yourself, ask someone else to. But it is vital that manatees not be ignored. By accepting one, you are stating that you will handle this volunteer's questions and reviews. If you do not feel up to it, either do not offer to mentor or make special arrangements for the parts you can't handle.

As a supporthelp priv you will be expected to serve as a good example to the other volunteers. While all volunteers are expected to be courteous and respectful, it is more strictly enforced on supporthelps. Other volunteers are considered to still be in training, and as such, mistakes are more understandable. We do not expect supporthelp privs to never make mistakes though. It's perfectly fine if some mistakes happen. You may be informed of such mistakes by email, but it doesn't mean anyone thinks you're a bad priv. It just means we want you to learn from it and improve. Mistakes of fact or policy are completely understandable. We simply don't expect supporthelps to make mistakes such as leaking confidential information or harassing volunteers or requestees.

While we like all volunteers to follow up on the requests they try to answer, we especially encourage supporthelp privs to do so. A supporthelp priv can see a request through its entire life-cycle. From possible commenting, to approval, to potential touching, any necessary summary changes, validation nags, and closing comments. By following up on requests, you learn what information is most important to include, both for answers and internal comments.

A validation nag is a followup comment that reminds a user of the importance of validating. It is used after the request has been sitting for a few days (how long may vary by category, check with the admin(s) if you intend to leave validation comments) and the account is still not validated. The current version of the validation nag will be sent to you when you earn supporthelp in the general/unknown category. If you need the nag and do not have it, please request a copy.

Requests should not be given more than one validation nag.

Leaving Comments

Comments are used to ask questions or give additional information. Comments should only be used when necessary. If a request is ambiguous, it does not necessarily need a comment. Whenever possible, an answer should simply address all possible interpretations. This is usually faster and simpler.

However, sometimes a request will not contain sufficient information to resolve it. In these cases a supporthelp should comment requesting the additional information.

Comments are also used to correct mistakes. If the approved answer neglects to mention something important, a comment can add that information. Comments are commonly used in validation nags, as explained in the supporthelp section.

Approving Answers

Deciding which answer to approve is not always easy, and there are no firm rules that will always work. However, this section provides some basic concepts to make it a little clearer.

Do not approve answers that violate any of the Support policies as explained here or here.

Do not approve incoherent or terribly written answers, but in general a single typo is okay. If the typo causes the answer to be offensive or confusing, then that would make it unapprovable.

If information that is important to the request is in the FAQ linked to or in a FAQ linked to from the FAQ linked to, then that is generally acceptable. However, if it requires following links beyond that, it is not reasonable to expect the user to find the information and the answer cannot be considered complete.

If an answer is close to approvable, but not quite so, it is encouraged for supporthelps to email the volunteer to improve the answer. It is never required to do so, but doing so helps both the request get answered and the volunteer improve.

If the volunteer is an I2, you can leave an IC stating how you would want to see the answer improved. This is generally easier than emailing, and will usually result in the volunteer seeing the information and correcting the answer.

Supporthelps are expected to approve the first good answer. However, if a user re-submits an answer with small improvements whether to count that new answer as later or based on the time of the original answer is up to the particular supporthelp. As long as you are consistent, it should affect all screened volunteers equally and still be fair.

It is good, but not required to leave explanations of why you approved what you did. In some cases this will be obvious. If it is, you do not need to leave any sort of note. But these notes are helpful both to I2s, so they can learn what the standards are, and to other supporthelps, so they can answer questions about approval easier. They can also save time and effort during eviews.

Reporting Volunteers

Any volunteer may report anyone who they feel is violating Support policies, causing problems, or simply making mistakes. All reports should be sent to support@livejournal.com. Some volunteers are reluctant to report mistakes. Please keep in mind that a report does not mean that the volunteer in question will necessarily lose privs or have any other action taken. But mistakes need to be reported so that the volunteer can be corrected. Most reports will be handled simply with a reminder to the volunteer of the correct way to handle the situation. Warnings and removal of privs are usually reserved for people who continue to make the same mistakes after being informed of what they should be doing.

Particularly good volunteers and Support requests handled particularly well should also be pointed out. However, only those with supporthelp priv in the relevant category should be pointing out such things. These can also be reported to support@livejournal.com. Pointing out particularly good volunteers is often most appropriately done in the community for the that category. By the time you have supporthelp, you should know which is appropriate for your category.

Leaving Support

Should you wish to stop volunteering, you can, of course, do so at any time. If you have privs, you should contact support@livejournal.com to have them removed. If you simply go inactive for a long time, you may find that your privs have been removed for you. This is not personal, it is simply a matter that privs are given to people so that they can perform certain tasks. If you stop doing the tasks, you stop needing the privs.

If you wish to re-join Support after a long absence, you should again contact support@livejournal.com so that you can be caught up as quickly and easily as possible. The Catching Up category of lj_support's memories is specifically designed to assist returning volunteers.

Support Oddities

Sometimes weird things happen on the Support board. These can startle or disturb volunteers who haven't seen them before. This section attempts to list some of the unusual things known to happen from time to time.

Negative Time

Probably the oddest is when Support requests get labeled with negative time. Support requests normally show how long ago they were opened. Sometimes the clocks desynch and cause the requests to be labeled with impossible times. This will usually get noticed and fixed pretty quickly.

Posted NEVER

Social Aspects of Support

This section does not contain any information that a volunteer needs to know. However, whenever a large group of people work together for a while, they will create references that can be rather confusing. This section attempts to outline the tangential creations of Support.

#lj_support and IRC

Several Support volunteers hang out on an Internet Relay Chat (IRC) channel. This is not an official channel in any way. It is currently located on irc.lazynet.org on the channel #lj_support. It can also be found through http://www.callete.com/ljsupport/. You can check its current location or ask questions about using IRC in supportlounge.

Answered With Elegance (AWE)

Every so often a list of particularly well-answered requests is posted to supportlounge. Any supporthelp priv may submit a request to be included in AWE unless they answered the request themselves.

Support Bunnies

Like many other things in this section, there is really no good reason for Support bunnies. But one volunteer, mullenkamp, created a cute bunny. Then several people edited their icons to also include that bunny. The bunny became a sort of mascot of the Support team. Now many volunteers have user pictures that include one or more bunnies.Several Support volunteers answer requests quick like a bunneh.

Support Cats

The cat is a natural mascot for the categories, because the word "category" is often shortened to "cat". While the exact type of cats that represent each category is not currently known, general/unknown is a calico cat.

Chinchillas

One volunteer, leora, became very interested in having a pet chinchilla. Somehow it worked its way into posts and comments enough that many people started making references to chinchillas. The user picture for privchange is at the time of this writing, a chinchilla. Her name is Koala! and the exclamation mark is part of her name.

The French Toast Support Category

This is purely a joke. Before category admins had the ability to add and remove privs directly, they would post what changes they want to lj_supportadmin and jproulx would then make them. leora included in a normal batch of priv changes that she should be given "SuperGodlyPowerOverAllBowBeforeMeMereMortalsAndFeedMeFrenchToast" priv. Then Jproulx added supporthelp FrenchToast to her privs to play along. The priv doesn't do anything and the category does not actually exist. Although there have been some discussions about the best way to make french toast and some user pictures of french toast spawned from this.

Useful Links

Glossary of Support Terms

Support has a lot of terms and abbreviations that will get used without thinking. This can be confusing to new volunteers. In an attempt to make it clearer, here is a glossary of many of the terms used. Some of these are directly related to Support, others simply tend to come up in conversation with Support volunteers or in Support posts or comments. Some of these are terms that are used elsewhere, but since we get questions about them, they are included.

admin: Someone in an administrative role. This word can be fuzzy. Sometimes people only refer to staff (employees of LiveJournal) as LiveJournal admins. Others refer to the category administrators as admins. Basically, it's just someone in an official leadership position, and the specifics
vary.
approve: The act of turning a screened answer into an answer that the user will see. Privs approve answers in requests.
AWE

Guide Part I

leora — Thu, 29 May 2003 12:31:49 GMT

Here's a much more finished version.
SuportOffice is down, but I just left the text as if it isn't. And my definition list in part II keeps being broken, but I have no clue why. If anyone can figure it out, that'd be neat.
Anyhow the LiveJournal Support Guide in progress:

So You Want to be a Support Volunteer

Introduction
Basic Support Rules
How Support Works
Support Rules in More Detail

Courtesy
Professionalism
Helpfulness

Support Communities
Why Answers Don't Get Approved
How to Improve at Support
Reviews
Mentoring
Support Privs
Understanding the Categories
Interim Level One
Interim Level Two
Summary Tags
Being a Supporthelp Priv
Leaving Comments
Approving Answers
Reporting Volunteers
Leaving Support
Support Oddities

Negative Time
Posted NEVER
Requests Disappearing
Multiple Answers or Comments
Requestees Talking to
Themselves

Social Aspects of Support

#lj_support and IRC
Answered With Elegance (AWE)
Support Bunnies
Support Cats
Chinchillas
The French Toast Support Category

Useful Links
Glossary of Support Terms

Introduction

LiveJournal can always use more volunteers and helping out in Support is a great way to learn more about how LiveJournal works. However, it is a time-consuming task that requires patience and professionalism. Don't expect to just jump in answering questions and get a bunch of points. For many volunteers it will take weeks to earn their first support point.

However, if you're reading this, you're already off to a good start. The information in this document is designed to help you understand Support and get your answers approved. Some other good resources are the following communities:
lj_support - the main Support community where policies are announced. New volunteers cannot join, but they can and should friend it. Reading lj_support is required for all support
volunteers.
learn_support - the community for new Support volunteers. Volunteers are encouraged to join and post questions here. The guidelines for HelpScreening are linked to from its userinfo. Both of the above communities have particularly helpful posts
saved as memories. Reading through the memories is a very good way to learn more.

Please note that there is a lot of material you can read, and reading it will almost surely help you do better in Support. But don't feel as if you need to read through everything right now. It's generally best to take things at your own pace. Start with the first three sections of this guide, and then read the rest as you feel ready to learn more.

This guide is designed to answer most of the common questions Support volunteers at all different experience levels have. While reading the sections for more experienced volunteers is fine, there is no reason to feel you should. This is a very long document, and is meant to be read in small pieces as you progress in Support.

Basic Support Rules

There are many Support policies, but only a few that are really important to keep in mind when you're just starting out. For a more detailed listing of support policies, check out the Support communities and later parts of this Guide.

Never contact users off of the Support board. If there is a reason why it is important to do so, then someone who is authorized to do so will. We do not want users to feel harassed or stalked because of their Support requests.

Treat people with respect. This goes for both the people who submit requests and your fellow volunteers. Do not make fun of people who submit Support requests. If you have a question to ask, ask it politely. If someone offends you, contact someone about it privately rather than starting a flamewar. Most problems are caused by misunderstandings that can be sorted out if everyone just discusses the issue calmly. If you notice mistakes in Support answers, email support@livejournal.com about it and it will be forwarded to the appropriate person or people.

Do not copy other volunteers' answers. You can use other people's answers as a guide to what content yours should include, but write your own answers. If you need help with the wording, ask in HelpScreening.

If a request contains any private information or reports a security bug, do not discuss the request with anyone. As you become more experienced with Support, you will learn how to handle these requests, but until you do, it's simplest to just keep quiet about them. Volunteers who are found discussing private information on the board or using it for their own purposes may be banned from Support.

How Support Works

Users submit Support requests that are then opened on the board as green requests. They remain green until an answer is approved, and then they turn yellow. If they re-open because the user needs more help, they will turn green again until re-answered and say "answered still needs help". When a request closes it will be moved to the closed section and be a pinkish red. Eventually it will disappear entirely, but still be findable by the specific URL to the request. The exact colors may vary from system to system.

As a new Support volunteer your answers will be screened. This means that someone with more experience in Support will read them over and only allow them to be sent to the users if they meet Support's guidelines. There are several Support guidelines both for the board as a whole and category-specific. These will be explained in more depth later.

There are many forms of information in Support requests that you will not be able to see at first. The most notable are other volunteers' screened answers. This means that sometimes you will answer a question that already has an acceptable answer in it. Don't let this discourage you. As a new volunteer you should focus on learning as much as you can. In time you will be able to see these answers.

Sometimes instead of an answer, a comment will be made. Comments are used primarily to request more information. Sometimes they are used to point out additional information that was left out of a previous answer or to followup on a request. Comments can never earn Support points.

If you see a comment in a request asking for more information, you should not attempt to answer the request until the user has replied back. While sometimes an answer will be approved before then, especially if the user seems unwilling to reply back, most of the time attempting to answer such questions will just be a waste of effort.

If you see a request that needs a comment, you can leave a screened answer intended to go through as a comment to the user. Support volunteers can approve screened answers as comments, and will do so when appropriate.

If it's an unusual request and you have information that shouldn't go through to the user, but may be helpful to Support, you can leave a message to the other volunteers. Leave a screened answer with the words "INTERNAL COMMENT" all in caps with the information. This will help volunteers to resolve the request. These screened answers can also never earn points, but they do help to get requests resolved. Internal comments should only be used if you have good reason to suspect that the information you can provide is unusual. In most cases experienced Support volunteers will know enough to handle requests.

After a request has been answered, the user may reply back with more questions. These further questions must then be answered, but not necessarily by the person who answered the first question. It's a good idea to check back on Support requests you have answered both to see what sort of answer was approvable and to check for followup questions. Once the user is fully helped either the user will close the request or it will sit until one of the Support closers comes to close it.

Requests, regardless of who closes them, can be closed with credit to any answer in the request or without credit. Support closers will attempt to assign credit fairly, but only one person can receive credit for each request. The users may assign points fairly, but they also may close without credit. This is just a natural part of Support. Not all requests are expected to yield points for anyone.

Most requests will take about a week to close. Many will take longer if they require users to comment back, second answers, or new problems. These too will eventually close, but later.

Closed requests can also be re-opened by users. This does not happen often, but when it does the points will be revoked. They may then be re-assigned when the request closes again.

The value of a request is based upon the time the answer/screened answer was submitted. The value of that answer, if the request is closed to it, will be the amount showing at that time, regardless of when it is approved or closed. Most requests are worth one or two points, and the maximum they can be worth is ten points.

Once you have earned points, they will show on your full user info page. You can also see both your points and how it compares to every Support volunteer who has ever earned points at the High Scores page. On that page there will be little numbers in red or green next to many of the scores. This is how much their rank has changed since the last time it was calculated. Points and rank are updated more or less instantaneously. Change in rank is usually updated weekly, but sometimes problems happen and changes in rank will freeze and not be updated for a while.

You can find the specific requests which earned you points in public categories through use of the Support Office. This is not an official LiveJournal tool, but is very useful for Support volunteers. It can do more than just find where you earned points. It is located at http://supportoffice.callete.com/.

Support Rules in More Detail

Support is divided into categories. Each category is run by one or more category admins who can set policies for that category. Thus there are both rules that apply in all public categories and rules that are category-specific. This Guide focuses on overall rules. The best way to learn category-specific rules is through lj_support's memories and the communities for the categories and through the communities for specific categories.

The first rule of Support is that any policy might have an exception if a good enough reason comes up. Policies are there to improve how Support works, not bind us in cases where they don't fit. If you believe that an exception is needed in a specific case, you should contact the relevant category admins or email support@livejournal.com to ask about it. Sometimes exceptions will be made.

The most important rules of Support were presented in the section What rules do I need to follow?. This section goes into detail on more policies. If there is ever a conflict between this guide and information given in official Support communities, then the communities take
precedence. This guide cannot be constantly updated, and the communities can deal with issues as they occur.

There are some exceptions to the rules in the short rules section. Answer copying is allowed with the permission of the person who wrote the original answer, but is highly discouraged for most volunteers anyway. Answer copying makes it harder to learn how to do Support, and thus is generally only used by those who have enough experience already to not need more work on answer writing. Reusing your own answers is perfectly acceptable so long as you modify them to fit the specific request you are answering.

Contacting users off the board is rarely allowed, but if a user writes a thank you post in their journal, you may comment politely to it. If the user friends you, you may then comment to them or friend them if you wish.

Support strives to be courteous, professional, and helpful. While some rules work toward more than one of those, the rules divide up fairly well based on those concepts. This section also explores what those ideas mean.

Courtesy

Courtesy is fairly simple. No matter what you think of a user's request, answer it with the respect you'd want if you had asked it. If you can't do that, do not touch the request in any way. You are always free to ignore requests that you dislike. Even in discussions outside the Support center, don't ridicule questions.

Be courteous toward other volunteers. Learn from answers by other volunteers (when you can tell that they're right), but don't just copy them word for word. If you feel compelled to complain about a common mistake, criticize the mistake, not the individuals who made it. Make corrections privately. Don't ridicule answers.

Specific rules:

Don't lie to users. There shouldn't be any request that requires you to lie to a user. You can simplify, many users do not need full details, but try to be honest.
Never ask users to close their requests. If a user is causing serious problems, then email support@livejournal.com about it. Most open requests will get closed naturally.
Don't tell people to email other users unless it's about joining a closed community or contacting the maintainer to deal with community issues. People do not like when they are annoyed by someone and that person tells them support told them to do so.
Do not include information that is completely irrelevant to the request. You can justify including the lj-cut tag when explaining how to post pictures. But don't answer a how to validate question with: And I noticed that your journal has really poor contrast and you can modify your
colors by doing FOO.
Do not misrepresent the names or policies of other sites. For example, "PayPal" should be properly capitilized. Sites that allow remote loading for a fee should not be mentioned as not allowing remote loading at all. We would not want these sites misrepresenting LiveJournal, so we should represent them properly if it comes up.

Professionalism

Professionalism gives people a good impression of both LiveJournal and the Support team. You are expected to act professionally in all Support-related contexts. If you are commenting in an official community and represent yourself as a Support volunteer, then your comment should be professional
and courteous. However, when you are outside Support contexts, your actions may be whatever you wish.

Specific rules:

Don't use an obscene user picture or username. LiveJournal can have members as young as thirteen, and as such the Support board should remain PG-13. In any case, an answer from someone with an offensive name or picture does not inspire confidence.
Do not use the words "we" or "us". Support volunteers are rarely allowed to speak officially on behalf of LiveJournal. We do not want to give the impression that we are doing so. We do represent LiveJournal in the sense that we are what users see when they come to Support for help, but we do not make official decisions. Support volunteers do not control LiveJournal policies and should not give the impression that they can.
Do not point requestees to other places when they have support problems. If they have a suggestion link to http://www.livejournal.com/suggestions and tell them to check the prior suggestions. If it is a suggestion that has been shot down many times, you can simply tell them that it has been suggested before and the reasons why it will not be implemented. If it is currently in Zilla or has received positive feedback, then say that the idea has been considered before and may be implemented at some point in the future. Do not point them to the Zilla item.
Do not give support for things outside of the domain of LiveJournal. We can't Support everything. As such, if something falls outside the domain of LiveJournal, inform the user and try to give them a pointer of where to go to. Such as with complex HTML, suggest they do a web search with their favorite search engine for "HTML tutorial" or similar phrases.
Do not give out invitation codes through Support. Giving out invitation codes to everyone who asks for one defeats the purpose of the invitation code system and encourages abuse. Likewise, do not link users to communities that give out invitation codes. The invite code
system was created in part to prevent abusive users from getting more accounts from which to hurt people. We do not want to make it easier for these users to hurt others.
If you have a choice of references always pick the most official one. Journals intended for the public such as news are ideal. If there is none, then go with an official LiveJournal community. If there is none, try for a LiveJournal or goathack site with a disclaimer. If not, then
an outside site. Try to avoid linking to Zilla, lj_support, helpscreening, and other sites intended to help volunteers/staff. When including links to LiveJournal posts use the talkread rather than the talkpost form. You want to
encourage users to read comments in the post rather than to comment.
Whenever you link to a page that is not an official LiveJournal page you should include a disclaimer that it is not affiliated with LiveJournal and LiveJournal cannot be held responsible for its content. This is useful for many reasons, if the page should change, it makes it less likely users will complain. If the page has ads, it's important for users to know that those ads have no connection with LiveJournal and LiveJournal does not benefit from them in any way.
Be sure of your answer. Don't write something like, .Well, I'm not sure, but when my friend had a problem like this, blah blah blah worked .... Professional answers give the user an answer-ideally, the correct answer. The exception to this is when the user has been very vague but you think you know what the user is asking about. Then you can say something like, .If you mean FOO, then you should do BAR. If you had something else in mind, please reply back so someone can help you further.. Asking for more information or clarification belongs in comments, which can be useful in these situations. However, it is better to answer the question whenever possible than to comment for more information. So, if a simple if FOO then BAR might resolve it, that should be tried.
Slang and idioms should be avoided in all Support answers. It not only looks unprofessional, but not all users will understand such expressions. Support helps people around the world, including non-native English speakers. Slang and idioms will often confuse such users.
In general, avoid sentence fragments. All the standard rules of good writing apply to Support answers. Nobody is likely to mind if you split an infinitive here or there or end a sentence with a preposition, but try to write clearly and concisely.
Avoid phrases like "Hope this helps". It looks unprofessional and some users will read it as a sign of uncertainty.
Avoid emoticons. It looks unprofessional and may confuse some users.
Don't sign your answers or use a greeting to begin them. Greetings and signatures are reserved for answers that are officially from LiveJournal, to make the distinction clearer. It is also unnecessary as the public categories have answers go out with your username and user picture.
Put your entire answer into one reply. We don't want people flooded with e-mails in reply to their support requests. If your answer has already been sent to the user, and you left something out or made a mistake, then you need to post a follow-up, but try to prevent that from happening. If your incorrect answer is still a Screened Answer, no harm has been done; rewrite it completely and correctly rather than submitting a follow-up. If your answer was incorrect or incomplete, approved, and you do not have supporthelp privs, then submit a correction and email support@livejournal.com with a link to the request and a brief note that you were approved with a mistake that you need to correct. Don't worry that you made a mistake, no one expects you to be perfect, just fix it as best as you can.
Don't link back to the request itself. The link is added automatically to the response sent by e-mail.

Helpfulness

Helpfulness involves actually giving the user an answer they can use in response to their request. The entire point of Support is to help people. We want to do it kindly and without offense, but we need to make sure that we help them.

Specific rules:

Always point users toward relevant FAQs. It's good for them to know the FAQs are there and they may find it useful if they run into further problems.
When including a FAQ from the drop-down, somewhere in the body of the answer there should be a mention of why the FAQ was included. This can be a simple sentence like: The above referenced FAQ explains how to validate your account. The importance of mentioning it is twofold, one to make it clear to the user how the FAQ relates to their request. Often the relation is obvious, but in some requests it may not be apparent to the user. The second reason is to ensure that the user knows there is a FAQ link that should be followed. Most users will read their answers in email, and the answer will embedded in some other text about the Support request. This can sometimes be confusing, and we want to make things as clear as possible.
Don't quote the FAQ unless you are quoting a small excerpt to highlight the information. In general, just direct the user to the relevant portion of the FAQ. We want them to go to the FAQ, and they don't want to read the same information twice.
When linking to guides, do not link directly. Use the find?guide= format instead. Ideally, one day all the guides will be translated. The direct links may go to only the English versions while the find?guide= format should go to the version in the user's language of choice. Whether it ends up working this way or not, we prefer to have volunteers get into the habit of doing it this way now.
Be very careful whenever you tell a user to make a change involving things outside LiveJournal, such as turning on cookies or turning off email filters. Always either tell them to do it in a way that only affects LiveJournal or warn them about the possible downside to what they are doing. For example, in the case of filters, you may want to recommend they adjust them to allow LiveJournal emails through without affecting the rest of the filters.
Never tell a user to give their password to anyone. If the user brings up the idea, explain why that is a bad idea.
Don't tell users to delete their accounts unless they are asking how to delete their accounts. If you have a really good reason to do so, recommend they back up their journal first, in case anything goes wrong.
Don't assume the user is using a particular client, web browser, or operating system. If you're not sure, give a generic answer. Explain how to do things with any client listed on the account. If they don't list a client and they want to do something that is easier with a client, mention that.
Don't mention sites that offer various services, such as remote image hosting, hosting other journals, etc. It's better to tell them to search the web and in the case of images to check with their ISP. These policies change rapidly and without notice. Referring users to a specific site generally causes more harm than good.
Answers must thoroughly answer the user's direct question, address any misconceptions the user has about LiveJournal, and address any obvious LiveJournal problems the user has. This means that if the user asks about getting a source code, but clearly wants an invite code, you should address the fact that the source code is a different thing from an invite code. Likewise if a user asks about how to add a user picture, but the account isn't validated, you should tell the user how to validate as well as how to add a user picture.

Support Communities

The main journal for Support is lj_support. Every Support volunteer should read it. Official policies are announced there and relevant LiveJournal news is relayed there. Sometimes the direction that LiveJournal Support should take is discussed there. Any volunteer may read it, but only experienced volunteers are granted posting access. Posting access and membership is given when a volunteer earns supporthelp priv in any category of Support.

The next community to consider is learn_support. This community is open to all volunteers. It is used to give tips on how to better answer in Support and to ask Support-related questions.

All of the public Support categories have communities. They
are:
support_clients, support_comms, support_embed, support_general, support_styles, support_syn, support_upi, support_web, and web_ui. Information about them can be found in the userinfo for each community.

Other Support Communities:

lj_supportadmin is the administrative community. Only category admins and LiveJournal staff have membership there. While any volunteer may watch it, and sometimes posts are made publicly, for the most part there is little worth seeing there for non-members.

support_interim is the community for interim privs. When you earn interim privs, you will be added, until then it is not worth watching.

supportlounge is an unofficial community where many Support volunteers post about their Support experience, amusing Support related events, or share particularly impressive requests.

howto_userdoc is an official community for the discussion of tutorials for inclusion in howto. While not a part of the Support Board, it is closely tied to Support and considered a part of the Support system.

privchange is a journal where the addition and removal of Support privs is announced. No one is required to watch it, but many volunteers wish to know about priv changes.

howtosupport is an unofficial community with tutorials about writing Support answers and understanding various aspects of LiveJournal that frequently come up in Support.

Other Helpful Communities:

All of these are helpful in their own way, but most volunteers will not want to watch them all. You should see which you find tend to be most useful for you.

lj_biz is for the discussion of LiveJournal business matters.
changelog is where changes to the LiveJournal code are announced.
lj_dev is where development changes are discussed.
lj_maintenance is where outages and network problems are announced.
lj_userdoc is for discussing the FAQs and guides.
news is where important LiveJournal news is announced.
paidmembers where news related to paid user accounts is announced.

Why Answers Don't Get Approved

Support takes patience and dedication and new volunteers should not expect to get approvals or points quickly. How long it takes will depend on what skills you enter Support with, what you read, and how much effort you put into it. Keep in mind that only approved answers can earn points and that not every request closes with credit. For more details about how the Support system works check over the section about it.

One common reason for not getting approved is not being first. As a new volunteer, you can't see other answers. When an answer gets approved, compare the timestamp. If it is earlier than yours, then it was also screened.

Another common reason for new volunteers not being approved is that their form doesn't meet Support standards. Support likes to have a very professional appearance. Things like emoticons (e.g. :)), "Hope this helps.", slang, poor spelling, and incomplete sentences can keep an accurate answer from being approved.

Answers should always be in one complete screened answer. If you notice you made a mistake, resubmit a new complete answer without the mistake. Do not submit a correction. Since yourr answer hasn't been approved yet, the corrected version can be sent to the user. Almost every volunteer will mess up sometimes and re-submit. There is no reason to worry about resubmissions. However, if you find you are constantly resubmitting answers, then you should proofread more carefully before you answer. You may wish to write your answers in a text editor so that you can see them more clearly.

Another possibility is that the answer required more information. There are three issues that must be considered in every request. First, the user's explicit question must be addressed. Second, any misconceptions that the user has must be addressed. An example of this is a user asking for a source code to start a journal. The user probably means they want an invitation code, so there should be a brief explanation of what each code is and how each is used. Finally, the answer must address any other issues the user needs to be informed of, but wouldn't have known enough to ask about.

One example of this is a user asking an unrelated question, but the account is not validated. Validation must always be addressed when it comes up as not being validated will lead to several problems for the user.

For more information on why your answers weren't approved you can ask in learn_support. Please read the community's guidelines.
Remember, if no answer has been approved yet, then wait to find out what will be. Sometimes simply no one qualified to handle the request has gotten to it yet. If no answer is approved yet, your answer may be fine.

How to improve at Support

There are several things you can do to get better at Support By reading this, you've already started. Another is to go through the memories for various Support communities. A good way to improve is to look over approved answers. Don't copy them, but see how they're written and what sort of information they contain.

While answering requests, read them carefully. What things might the user mean? If the user may be referring to multiple things, address them all. If the user asks multiple questions, answer them all.

Read over your answer carefully. Is it well-written? Is it spaced nicely? Does it include references when needed? Did you mention every FAQ you used?

Think about what the user knows and what the user needs to know. Try to make sure your answer provides all the information the user will need to resolve the issue. Also make sure you address any misconceptions the user has or alternate methods of accomplishing the goal.

Learn the FAQs and check them every so often, since they do change. An answer that doesn't include a relevant FAQ will almost never be approved. Part of being able to answer most Support requests is knowing where the relevant information is.

Look over the information provided with the request. Is this a logged in user? Is the account validated? Is the user free or paid? These things may have an effect on the answer.

Try to answer questions and check back to see what got approved. How was it different from your answer? If it was your answer, then great. Look at requests you can't answer, and check back on them to see how they do get answered. Ask questions in HelpScreening and get a review. After you have learned the basics of a category, you may wish to inquire about getting a mentor.

Reviews

Reviews are a wonderful way of learning how to improve your answers in Support. They involve an experienced volunteer looking over many requests you have recently tried to answer in a category and giving you feedback. It allows Support volunteers to get feedback that is more personalized to their needs, and it helps the category admins keep track of your progress.

Since Support is divided up into different categories, each run by its own category admin(s), reviews are generally done for one category at a time. To get a review, contact the admin(s) of the category you are interested in. They may not review you themselves, but they will make sure someone competent does. If you do not know the admin(s) for a category you are interested in, submit the request to support@livejournal.com and ask them to forward it to the relevant admins.

There are four basic methods used for reviewing. The first is that you collect requests to be reviewed. The second is that you collect requests to be reviewed that are then supplemented by the category admin. The third is that you request a review and the category admin collects all of the information. The fourth is that you are given example requests to answer, which will then be reviewed. In any of these cases, you may also be asked to comment on what you did and why and anything you learned from the request. If you do not know which type of review a category uses, ask.

To gather requests for a review that uses requests from the board, go to the Support board and filter to "You Replied" and whatever category you want a review in. Do not remove any requests from this filter unless you are specifically instructed to.

Then make an email with the URLs to each request in that filter. Include your username and whether you have any privs in that category, and if so, which privs. If you have any specific questions about some of the requests, include those as well, that way the reviewer can address them.

How helpful a review is really varies. Some volunteers find them to be the best way to learn, others do fine on their own. Sometimes a review happens at just the right time to help a volunteer improve further, while other reviews for the same volunteer don't help much. But they are definitely worth a try. New volunteers should generally get a review in any category they've been working in to a moderate extent for two weeks or more. Then get another after about three weeks or so, longer if you spend a significant amount of time away from Support during that time. Volunteers with all of the interim privs should generally be reviewed more often. These are just rules of thumb and will vary from person to person and category to category. Always feel free to ask a category admin about what they think is best for you.

When you get your review, you should expect comments on how your answers could be improved. But do not expect every request you submitted to be mentioned in the review. Often several requests have the same problem or were all done well. In these cases, there is little to say, and they will often simply be removed. If a large number of your requests are removed you either likely do a lot of similar request types or are doing very well.

A review can take a while to get done, especially depending on the size of the review, the time of year (around holidays many volunteers may be away or busy), the category, and just luck. If you don't hear back about a review you sent after a week, send an email asking if it was received and whether everything is okay. Sometimes emails get lost or misplaced, and we don't want any volunteers being ignored through such accidents. If another week passes, send another reminder, the admin may need to get in touch with the volunteer doing the review to make sure no problems came up.

Your review or its summary will then likely be shared with the supporthelp privs for that category. This is to help the supporthelps to better teach you about Support, and because in most categories the supporthelp privs help to decide when new volunteers are ready for different levels of privs.

If for any reason the requested review format causes problems for you, discuss it with the admins for the categories you are interested in. These formats tend to be easiest and work best for most volunteers, but special arrangements can be worked out at times to meet a particular volunteer's needs.

Mentoring

Some categories have mentoring programs. Having a mentor will give you someone to go to with questions. Your mentor will also likely review you, and may bring up issues for you to try to work on. You do not need a mentor to improve at Support, but some volunteers will feel more comfortable having someone specific they know they can go to for advice and answers.

Some categories may have a waiting list for mentors. Some categories may limit mentoring to those who have already earned at least I1. You should check with the category admin(s) for specific and current information. As always, if you don't know who they are, you can have support@livejournal.com forward the request for you.

Support Privs

There are many privileges or "privs" associated with Support. A priv is what gives someone the technical ability to do something. Most privs are publicly viewable at http://www.livejournal.com/admin/priv/.

Support volunteers will also refer to someone with the priv as a priv. So, the group of people with any of the interim Support privileges are collectively referred to as the interim privs.

All Support privileges are given on a per category basis. Some people will have privileges in all categories, but they either are in administrative positions or have earned privs in each category.

There are four interim privs. They are:

supportviewscreened - the ability to see other screened answers in requests
supportmakeinternal - the ability to make internal comments in requests
supportviewinternal - the ability to see internal comments in requests
supportmovetouch - the ability to change the category of a request or re-green a request

Interim privs will be explained more fully in the sections on I1s and I2s. They stand for interim level one and interim level two. Level one consists of having supportviewscreened and supportmakeinternal. Level two consists of having all of the interim privs.

Supporthelp is the priv that allows a volunteer to approve screened answers and comments. It also allows the volunteer to submit an answer or comment that does not need to be approved, but this is rarely used. It is generally reserved for times when the board is flooded with requests, such as during technical difficulties, to quickly answer numerous requests on the same subject. Another function of the supporthelp priv is the ability to change the summary of a request. The summary is the text that appears on the Support board about the request. Supporthelps generally help to teach newer volunteers how to answer in Support.

Supportclose allows a volunteer to close requests and assign points. This priv is generally reserved for Support administrators.

There are also admin privs that allow someone to give privs to other people.

Understanding the Categories

The following are the public Support categories: clients,
communities, embedding, general/unknown, syndication, user
picture icons, web user interface.

The following are the private Support categories: abuse, account payments, feedback, press, privacy, support@, webmaster.

The public categories are best understood by looking through relevant communities and Support community memories.

The communities for each category are listed below and who should read the community and how it should be used will be explained in the userinfo.

Clients: support_clients
Communities: support_comms
Embedding: support_embed
General/Unknown: support_general
Style Systems: support_system
Syndication: support_syn
User Picture Icons: support_upi
Web User Interface: support_web and web_ui

There is also howto_userdoc which supports the howto journal. howto is affiliated with Support, but not a part of the Support Board itself.

An explanation of the private categories and how they affect Support volunteers is below.

Abuse - this is the team that handles reported violations of the Terms of Service. All requests reporting specific journals for suspected abuse such as harassment or copyright violations, reporting "hacked" journals, asking questions about suspended accounts, asking legal questions, or asking about the Terms of Service should be moved to the abuse category. Requests from the parents of minors should also generally be moved to Abuse as they need more delicate handling. If you see an abuse request in Support and do not have the ability to move it, check the userinfo for lj_abuse. Contact people who are members of the community and one of them will move it for you, if it is deemed to be abuse-related.

Account Payments - this category handles problems with account payments. If a user didn't have a payment go through or had a problem with how their payment was processed, it is handled by accounts. Unless the request contains personal information, such as a credit card number, it can generally sit on the board until someone with the ability to move requests sees it. If it does contain personal information, contact a supporthelp priv to move it. You can start by contacting category admins, as they generally are around and have LiveJournal email addresses that are easy to find. You can use the members list for lj_supportadmin as a guide for who can be contacted, but do not email bradfitz about a routine Support issue such as a request needing to be moved.

Feedback - is not currently being used, but might be used at some point to allow people to provide feedback to LiveJournal.

Press - handles requests from the press for information. If someone wants an interview or quotes from LiveJournal staff members, it should be moved to press. These requests can generally sit on the public board until a volunteer capable of moving them sees them.

Privacy - handles questions about the LiveJournal privacy policy or concerns about LiveJournal sending out spam. These are rarely urgent and can sit until moved.

Support@ - handles junk requests such as duplicates and nonsense. For those who can move requests, duplicates should contain an internal comment linking to the other request by the user. These requests can sit until moved by someone with the privs to do so. Support@ also handles forwarding private requests when the category is unclear. If you have the ability to move requests, know a request should be private, but don't know where it should go, move it to support@ with an internal comment asking them to forward it. Support@ also handles requests that would be on the general board, except they contain personal information that must be kept private. These requests need to be moved quickly, and if you see one, but do not have the privs to move the request, contact a supporthelp as explained in accounts category. Finally, support@ handles requests about Support itself. If you need to report a complaint or problem with a Support volunteer or the Support system, you can open a request in support@. You can also use support@ to ask private questions about Support that you don't know where to ask. Support@ should be contacted if you wish to leave Support and have your Support privs removed.

WebMaster - requests about business issues, security holes, or the death of a LiveJournal user. Security holes need to be moved off the public board immediately, see the accounts category for details.

Special Note: Sometimes we get reports that a LiveJournal user may be committing suicide. While there is only so much that LiveJournal can do in such cases, they need to be handled immediately. Sometimes the authorities can be contacted. Either Webmaster or Abuse can handle such issues. The most important thing to do in such cases, is to make sure it is brought to the attention of the people who can deal with it. Please, do not be shy about emailing volunteers or staff. We would rather more people be contacted than necessary than that the request be overlooked.

Some requests are unclear about whether they should be public or private. In these cases, always err on the side of privacy. A request can easily be moved back to the public board. If the request has already been moved to a private category and sent back, everyone with the ability to move requests will be able to see that.

Also, with requests that should be private, it is even more important that you respect the privacy of the requestees, and you are expected not to discuss such requests at all. Do not post about them, even to get them moved, as this just causes more people to see them. Ideally, all private requests would go only to private categories, but when they don't, we expect volunteers to act respectfully toward the requestees.

For more information on each category you can see this post.

Part 2 of the Guide

leora — Sun, 22 Dec 2002 08:57:28 GMT

See previous post. Remember, please comment to my comment, not the post itself.

Interim Level One

After a volunteer has been helping in Support for a while, they may be given I1, the first interim priv level, in one or more of the Support categories. I1 conveys two privileges, supportviewscreened and supportmakeinternal.

I1 makes Support a bit easier by allowing a volunteer to focus on requests that have not yet been adequately answered. It also includes some responsibilities.

I1s are expected to keep screened answers confidential. They can see them for their own benefit, so they can concentrate their efforts. They should not be discussing these screened answers, except if they have questions about them they can either email the category admin(s) for the category privately about them or bring them up in reviews. If an I1 is part of a mentoring program, then they can also ask their mentor.

I1s are expected to understand that not all screened answers are good models. Try not to pick up bad habits from other volunteers. If a screened answer isn't approved, there may be a good reason for it. But some volunteers will find that other screened answers offer them a better perspective on how ambiguous requests may be interpreted or what information might be useful to include.

I1s are expected to use internal comments wisely. While unprived volunteers have the ability to add internal comments as screened answers, these internal comments will be labeled as such. They are more eye-catching, and volunteers expect them to be important. Interim privs should not be commenting about shortcomings in other screened answers, what should be approved, or what needs to be in an approved answer. But internal comments can be used to share information on unusual requests.

The general guideline for internal comments is only post them if there is something beyond the routine that you feel other volunteers need to know about. Some good examples of internal comment use would be linking to previous requests by the same user if they relate or linking to zilla items that relate to the request. Another good use would be linking to a suggestion that related to the request. However, don't link to standard well-known resources, since most volunteers will already be aware of them and it will just add clutter.

Internal comments are expected to be professional. The general guideline is that every time you leave an internal comment, you should be prepared for what you would tell the user if somehow it became visible. If you would not be able to handle that situation, you may want to re-think your comment. Internal comments are not to be used for irrelevant chatter or to talk about a user behind his/her back. When you reach I2, you may see some internal comments that are humorous. Many of the internal actions require some text be left, as such, privs are allowed to leave off-topic comments in these cases, but they still must not be offensive.

When you earn your first I1 priv, you will be given access to support_interim. This community is a good place to ask questions specific to using interim privs.

Interim Level Two

By the time you are given interim level two in a category, you probably have a great deal of Support experience and a good feel for how Support is done. Many volunteers will find themselves at I2 level for longer than they were unprived or I1. This will of course vary from person to person, but it's a common occurence. Try not to let it frustrate you. The step to supporthelp is a difficult one as mistakes made as a supporthelp can harm the users. As such, it is given out very carefully.

The primary responsibilities of an I2 are to keep the screened answers and internal comments confidential, to move requests to their proper categories , and to refrain from trying to train new volunteers. Training is left to supporthelps, to lessen the chance of people being given inaccurate information. While I2s tend to be very advanced and knowledgeable volunteers, they are not quite ready to take on training.

Since I2s can move categories and touch requests, they are expected to do so when appropriate. If a request is in the wrong category it is required that the category be changed first. Always check the category of a request before doing anything else with the request. Please read over the section on the purpose of each private category. It is very important that requests that should be in private categories get moved into them as quickly as possible.

To change the category of a request select internal comment/action and the new category from the drop down. Include some text, this can be as little as "." if the change is obvious or a brief note about the request if you have anything to say, and then submit.

Touching a request will re-green it and mark it as needing more help. To touch a request select internal comment/action and check the box to touch a request. Then include some text and submit.

Since I2s can see other internal comments, they can see whether something has been pointed out yet or not. As such, they can use internal comments a bit more broadly. Useful things to leave internal comments about would include the current state of the user's information as it relates to the request. For example, if the user is trying to add memories, you can leave an IC about how many memories the user has. If the user is trying to change the bio, you can leave an IC about what the text of the bio currently is. This makes it easier to tell when the user has succeeded and the request can be closed.

You may see internal comments about things missing in Support answers or what is needed in an answer, but you should not make internal comments like this until you have the supporthelp priv.If you have made it to I2, you definitely have the ability to become a supporthelp priv if you keep at it.

Summary Tags

Summary tags can only be added by supporthelp privs, but understanding them may prove useful to any volunteer. Summary tags are designed such that no one needs to remember them or use them, but doing so can save you time and effort. Not all tags are used in all categories. If you have supporthelp and wish to know which tags are used in your category, ask the admin(s).

[auc] - awaiting user comment. Used when the request cannot be answered further without feedback from the user. The volunteer who added this tag is responsible for checking back on the request and removing it after the user comments.
[c] - customization. This means that the request involves some customization elements and may particularly appeal to some volunteers and be too complicated for others.
[ui] - under investigation. Used when an unusual problem is being looked into so that all of the requests about it can easily be located.
[v] - validation. This means the user hasn't validated his/her account, and as such the request will not close as quickly. The [v] tag should be added only after a validation nag is given on the request.
[xx] - closable. This signifies that the request is definitely resolved. It should only be used in cases where the resolution of the user's request can be confirmed.

Many categories encourage volunteers to preface a summary change with a /. This allows volunteers without I2 or supporthelp to tell that the summary has been changed. This can better help a volunteer judge the user's level of knowledge and what sort of answer to give.

Being a Supporthelp Priv

There are many aspects to being a supporthelp priv. In its simplest form, you simply answer and approve things on the board. In reality, most supporthelps do much more than that. First, the obligations of a supporthelp priv.

Supporthelps have all the obligations of interim privs. They are expected to keep private information confidential and to treat all volunteers and users with respect. They are required to change the category of requests before doing anything else in the request. They do not have to handle any request they do not want to, even if they know how to, but if they do handle a request they must approve an acceptable screened answer rather than writing their own if an acceptable one is present.

The abilities of a supporthelp are:
to leave comments (see leaving comments)
to approve answers (see approving screened answers)
to leave answers (rarely used and usually discouraged)
to change summaries (see summary change tags)

Supporthelps are also given membership and the ability to post in lj_support.

When you first gain supporthelp, you should look over the Support policy memories in lj_support. Some of the policies will be friends-only. You will be expected to know and follow them. You should receive an email that will make this a little easier. The Useful Extras category also has some helpful friends-only material.

Many supporthelps will do more than just that. Supporthelps may be involved in giving reviews, mentoring, answering questions in the Support communities, suggesting good volunteers for privs, bringing up issues for discussion, and reporting volunteers when there are problems. To get involved in these activities, discuss it with the relevant category admins.

Remember, if you do a review you should send it to the volunteer and cc it to the category admin(s). For most categories you will then also be expected to post a summary in the category's community. To find out the specifics of your category, ask the admin(s).

If you do decide to mentor someone, please make sure that you keep in touch with your mentoree/manatee. If you cannot do the reviews yourself, ask someone else to. But it is vital that manatees not be ignored. By accepting one, you are stating that you will handle this volunteer's questions and reviews. If you do not feel up to it, either do not offer to mentor or make special arrangements for the parts you can't handle.

As a supporthelp priv you will be expected to serve as a good example to the other volunteers. While all volunteers are expected to be courteous and respectful, it is more strictly enforced on supporthelps. Other volunteers are considered to still be in training, and as such, mistakes are more understandable. We do not expect supporthelp privs to never make mistakes though. It's perfectly fine if some mistakes happen. You may be informed of such mistakes by email, but it doesn't mean anyone thinks you're a bad priv. It just means we want you to learn from it and improve. Mistakes of fact or policy are completely understandable. We simply don't expect supporthelps to make mistakes such as leaking confidential information or harassing volunteers or requestees.

While we like all volunteers to follow up on the requests they try to answer, we especially encourage supporthelp privs to do so. A supporthelp priv can see a request through its entire life-cycle. From possible commenting, to approval, to potential touching, any necessary summary changes, validation nags, and closing comments. By following up on requests, you learn what information is most important to include, both for answers and internal comments.

A validation nag is a followup comment that reminds a user of the importance of validating. It is used after the request has been sitting for a few days (how long may vary by category, check with the admin(s) if you intend to leave validation comments) and the account is still not validated. The current version of the validation nag will be sent to you when you earn supporthelp in the general/unknown category. If you need the nag and do not have it, please request a copy.

Requests should not be given more than one validation nag.

Leaving Comments

Approving Answers

Deciding which answer to approve is not always easy, and there are no firm rules that will always work. However, this section provides some basic concepts to make it a little clearer.

Do not approve answers that violate any of the Support policies as explained here or here.

Do not approve incoherent or terribly written answers, but in general a single typo is okay. If the typo causes the answer to be offensive or confusing, then that would make it unapprovable.

If information that is important to the request is in the FAQ linked to or in a FAQ linked to from the FAQ linked to, then that is generally acceptable. However, if it requires following links beyond that, it is not reasonable to expect the user to find the information and the answer cannot be considered complete.

If an answer is close to approvable, but not quite so, it is encouraged for supporthelps to email the volunteer to improve the answer. It is never required to do so, but doing so helps both the request get answered and the volunteer to improve.

If the volunteer is an I2, you can leave an IC stating how you would want to see the answer improved. This is generally easier than emailing, and will usually result in the volunteer seeing the information and correcting the answer.

Supporthelps are expected to approve the first good answer. However, if a user re-submits an answer with small improvements whether to count that new answer as later or based on the time of the original answer is up to the particular supporthelp. As long as you are consistent, it should affect all screened volunteers equally and still be fair.

It is good, but not required to leave explanations of why you approved what you did. In some cases this will beobvious. If it is, you do not need to leave any sort of note. But these notes are helpful both to I2s, so they can learn what the standards are, and to other supporthelps, so they can answer questions about approvals. It can also help to make reviews easier.

Reporting Volunteers

Any volunteer may report anyone whom they feel is violating Support policies, causing problems, or simply making mistakes. All reports should be sent to support@livejournal.com. Some volunteers are reluctant to report mistakes. Please keep in mind that a report does not mean that the volunteer in question will necessarily lose privs or have any other action taken. But mistakes need to be reported so that the volunteer can be corrected. Most reports will be handled simply with a reminder to the volunteer of the correct way to handle the situation. Warnings and removal of privs are usually reserved for people who continue to make the same mistakes after being informed of what they should be doing.

Particularly good volunteers and Support requests handled particularly well should also be pointed out. However, only those with supporthelp priv in the relevant category should be pointing out such things. These can also be reported to support@livejournal.com. Pointing out particularly good volunteers is often most appropriately done in the community for the that category. By the time you have supporthelp, you should know which is appropriate for your category.

Leaving Support

Support Oddities

Negative Time

Posted NEVER

Requests Disappearing

Requests with Multiple Answers or Comments

Some requests will have two answers about the same thing or two comments doing the same thing. This is caused by two different things. First, multiple Support answers and comments can happen because of technical problems just as multiple entries can. The other, and more common, reason is that two different people were trying to work on the request at the same time. The screening system keeps most collisions, as they are called in Support, from happening, but a few still get through. To reduce the chance of collisions and to encourage error-checking supporthelp privs are encouraged to always post screened first and then approve.

Requestees Talking to Themselves

Requests Regreening or Not Regreening

The mechanism for a request to go from yellow to green again is actually unrelated to the mechanism by which users leave comments in their requests. Because of this, users may mark a request as "still needs help" without commenting about what help they need. They also may ask for more help, but not mark it as needing that help. To deal with the latter, some people can "touch" a request and make it green again. Requests that are green with no comment will generally get given a comment by a supporthelp asking what the user needs more help with.

Social Aspects of Support

#lj_support and IRC

Answered With Elegance (AWE)

Support Bunnies

Support Cats

Chinchillas

One volunteer, leora, became very interested in having a pet chinchilla. Somehow it worked its way into posts and comments enough that many people started making references to chinchillas. The user picture for privchange is, at the time of this writing, a chinchilla. Her name is Koala! and the exclamation mark is part of her name.

The French Toast Support Category

Useful Links

Glossary of Support Terms

admin: Someone in an administrative role. This word can be fuzzy. Sometimes people only refer to staff (employees of LiveJournal) as LiveJournal admins. Others refer to the category administrators as admins. Basically, it's just someone in an official leadership position, and the specifics vary.
approve: The act of turning a screened answer into an answer that the user will see. Privs approve answers in requests.
AWE

The Guide - Rough Draft, Almost Complete Part 1

leora — Sun, 22 Dec 2002 08:55:08 GMT

Notes:
a) For those who saw it before, some sections have been edited, most noticeably rules2 and improving.
b) For those who suggested improvements, I tried to improve, but if I missed some, let me know.
c) I need to post in two parts, I exceeded the max posting size this time
d) This post is public
e) I will leave a comment in each of these posts, please comment to that comment or other comments in the post, not the post itself - I just don't want to be emailed the guide bunches of times
f) Anchor tags will break when they straddle posts, don't worry about it.
g) The glossary is the only part known to be incomplete

So, without further ado, Part 1 of the Guide

So You Want to be a Support Volunteer

Introduction
Basic Support Rules
How Support Works
Support Rules in More Detail

Courtesy
Professionalism
Helpfulness

Negative Time
Posted NEVER
Requests Disappearing
Multiple Answers or Comments
Requestees Talking to Themselves
Requests Regreening or Not Regreening

Social Aspects of Support

#lj_support and IRC
Answered With Elegance (AWE)
Support Bunnies
Support Cats
Chinchillas
The French Toast Support Category

Useful Links
Glossary of Support Terms

Introduction

LiveJournal can always use more volunteers and helping out in Support is a great way to learn more about how LiveJournal works. However, it is a time-consuming task that requires patience and professionalism. Don't expect to just jump in answering questions and get a bunch of points. For many volunteers it will take weeks to earn their first support point.

However, if you're reading this, you're already off to a good start. The information in this document is designed to help you understand support and get your answers approved. Some other good resources are the following communities:
lj_support - the main Support community where policies are announced. New volunteers cannot join, but they can and should friend it. Reading lj_support is required for all support volunteers.
learn_support - the community for new Support volunteers. Volunteers are encouraged to join and post questions here. The guidelines for HelpScreening are linked to from its userinfo.
Both of the above communities have particularly helpful posts saved as memories. Reading through the memories is a very good way to learn more.

Please note that there is a lot of material you can read, and reading it will almost surely help you do better in Support. But don't feel as if you need to read through everything right now. It's generally best to take things at your own pace. Start with the first three sections of this guide, and then read the rest as you feel ready to learn more.

This guide is designed to answer most of the common questions Support volunteers at all different experience levels have. While reading the sections for more experienced volunteers is fine, there is no reason to feel you should. This is a very long document, and is meant to be read in small pieces as you progress in Support.

Basic Support Rules

There are many Support policies, but only a few that are really important to keep in mind when you're just starting out. For a more detailed listing of support policies, check out the Support communities and later parts of this Guide.

Never contact users off of the Support board. If there is a reason why it is important to do so, then someone who is authorized to do so will. We do not want users to feel harassed or stalked because of their Support requests.

Treat people with respect. This goes for both the people who submit requests and your fellow volunteers. Do not make fun of people who submit Support requests. If you have a question to ask, ask it politely. If someone offends you, contact someone about it privately rather than starting a flamewar. Most problems are caused by misunderstandings that can be sorted out if everyone just discusses the issue calmly. If you notice mistakes in Support answers, email support@livejournal.com about it and it will be forwarded to the appropriate person or people.

Do not copy other volunteers' answers. You can use other people's answers as a guide to what content yours should include, but write your own answers. If you need help with the wording, ask in HelpScreening.

If a request contains any private information or reports a security bug, do not discuss the request with anyone. As you become more experienced with Support, you will learn how to handle these requests, but until you do, it's simplest to just keep quiet about them. Volunteers who are found discussing private infromation on the board or using it for their own pruposes may be banned from Support.

How Support Works

Users submit Support requests that are then opened on the board as green requests. They remain green until an answer is approved, and then they turn yellow. If they re-open because the user needs more help, they will turn green again until re-answered and say "answered still needs help". When a request closes it will be moved to the closed section and be a pinkish red. Eventually it will disappear entirely, but still be findable by the specific URL to the request. The exact colors may vary from system to system.

As a new Support volunteer your answers will be screened. This means that someone with more experience in Support will read them over and only allow them to be sent to the users if they meet Support's guidelines. There are several Support guidelines both for the board as a whole and category-specific. These will be explained in more depth later.

There are many forms of information in Support requests that you will not be able to see at first. The most notable are other volunteers' screened answers. This means that sometimes you will answer a question that already has an acceptable answer in it. Don't let this discourage you. As a new volunteer you should focus on learning as much as you can. In time you will be able to see these answers.

Sometimes instead of an answer, a comment will be made. Comments are used primarily to request more information. Sometimes they are used to point out additional information that was left out of a previous answer or to followup on a request. Comments can only be made by experienced Support volunteers and can never earn Support points.

If you see a comment in a request asking for more information, you should not attempt to answer the request until the user has replied back. While sometimes an answer will be approved before then, especially if the user seems unwilling to reply back, most of the time attempting to answer such questions will just be a waste of effort. If you see a request that needs a comment, you generally should just wait for someone to leave one. But if it's a particularly unusual request and you know something about the issue you think most others do not, you can leave a screened answer with the words "INTERNAL COMMENT" all in caps with the information. This will help volunteers to resolve the request. These screened answers can also never earn points, but they do help to get requests resolved.

After a request has been answered, the user may reply back with more questions. These further questions must then be answered. It's a good idea to check back on Support requests you have answered both to see what sort of answer was approvable and to check for followup questions. Once the user is fully helped either the user will close the request or it will sit until one of the Support closers comes to close it. Requests, regardless of who closes them, can be closed with credit to any answer in the request or without credit. Support closers will attempt to assign credit fairly, but only one person can receive credit for each request. The users may assign points fairly, but they also may close without credit. This is just a natural part of Support. Not all requests are expected to yield points for anyone.

Most requests will take about a week to close. Many will take longer if they require users to comment back, second answers, or the user does not resolve an issue, such as by having an unvalidated email address. These too will eventually close, but later.

Closed requests can also be re-opened by users. This does not happen often, but when it does the points will be revoked. They may then be re-assigned when the request closes again.

The value of a request is based upon the time the answer/screened answer was submitted. The value of that answer, if the request is closed to it, will be the amount showing at the time, regardless of when it is approved or closed. Most requests are worth one or two points.

Once you have earned points, they will show on your full user info page. You can also see both your points and how it compares to every Support volunteer who has ever earned points at the High Scores page. On that page there will be little numbers in red or green next to many of the scores. This is how much their rank has changed since the last time it was calculated. Points and rank are updated more or less instantaneously. Change in rank is usually updated weekly, but sometimes problems happen and changes in rank will freeze and not be updated for a while.

You can find the specific requests which earned you points in public categories through use of the Support Office. This is not an official LiveJournal tool, but is very useful for Support volunteers. It can do more than just find where you earned points. It is located at http://supportoffice.callete.com/

Support Rules in More Detail

Courtesy

Courtesy is fairly simple. No matter what you think of a user's request, answer it with the respect you'd want if you had asked it. If you can't do that, do not touch the request. You are always free to ignore requests that you dislike. Even in discussions outside the Support center, don't ridicule questions.

Be courteous toward other volunteers, too. Learn from answers by other volunteers (when you can tell that they're right), but don't just copy them word for word. If you feel compelled to complain about a common mistake, criticize the mistake, not the individuals who made it. Make corrections privately. Don't ridicule answers.

Specific rules:

Don't lie to users. There shouldn't be any request that requires you to lie to a user. You can simplify, many users do not need full details, but try to be honest.
Never ask users to close their requests. If a user is causing serious problems, then email support@livejournal.com about it. Most open requests will get closed naturally.
Don't tell people to email other users unless it's about joining a closed community or contacting the maintainer to deal with community issues. People do not like when they are annoyed by someone and that person tells them support told them to do so.
Do not include information that is completely irrelevant to the request. You can justify including the lj-cut tag when explaining how to post pictures. But don't answer a how to validate question with: And I noticed that your journal has really poor contrast and you can modify your colors by doing FOO.
Do not misrepresent the names or policies of other sites. For example, "PayPal" should be properly capitilized. Sites that allow remote loading for a fee should not be mentioned as not allowing remote loading at all. We would not want these sites misrepresenting LiveJournal, so we should represent them properly if it comes up.

Professionalism

Professionalism gives people a good impression of both LiveJournal and the Support team. You are expected to act professionaly in all Support-related contexts. If you are commenting in an official community and represent yourself as a Support volunteer, then your comment should be professional and courteous. However, when you are outside Support contexts, your actions may be whatever you wish.

Specific rules:

Don't use an obscene user picture or username. LiveJournal can have members as young as thirteen, and as such the Support board should remain PG-13. In any case, an answer from someone with an offensive name or picture does not inspire confidence.

Do not use the words "we" or "us". Support volunteers are rarely allowed to speak officially on behalf of LiveJournal. We do not want to give the impression that we are doing so. We do represent LiveJournal in the sense that we are what users see when they come to Support for help, but we do not make official decisions. Support volunteers do not control LiveJournal policies and should not give the impression that they can.

Do not point requestees to other places when they have support problems. If they have a suggestion, check to see if it has been suggested before and reference a link to it in your answer. Always link to http://www.livejournal.com/suggestions and tell them to check the prior suggestions (even if you did, they may have future suggestions).

Do not give Support for things outside of the domain of LiveJournal. We can't Support everything. As such, if something falls outside the domain of LiveJournal, inform the user and try to give them a pointer of where to go to. Such as with complex HTML, suggest they do a web search with their favorite search engine for "HTML tutorial" or similar phrases.

Do not give out invitation codes through Support. Giving out invitation codes to everyone who asks for one defeats the purpose of the invitation code system and encourages abuse. Likewise, do not link users to communities that give out invitation codes. The invite code system was created in part to prevent abusive users from getting more accounts from which to hurt people. We do not want to make it easier for these users to hurt others.

If you have a choice of references always pick the most official one. Journals intended for the public such as news are ideal. If there is none, then go with an official LiveJournal community. If there is none, try for a LiveJournal or goathack site with a disclaimer. If not, then an outside site. Try to avoid linking to Zilla, lj_support, helpscreening, and other sites intended to help volunteers/staff. When including links to LiveJournal posts use the talkread rather than the talkpost form. You want to encourage users to read comments in the post rather than to comment.

Whenever you link to a page that is not an official LiveJournal page you should include a disclaimer that it is not affiliated with LiveJournal and LiveJournal cannot be held responsible for its content. This is useful for many reasons, if the page should change, it makes it less likely users will complain. If the page has ads, it's important for users to know that those ads have no connection with LiveJournal and LiveJournal does not benefit from them in any way.

Be sure of your answer. Don't write something like, “Well, I'm not sure, but when my friend had a problem like this, blah blah blah worked ...” Professional answers give the user an answer—ideally, the correct answer. The exception to this is when the user has been very vague but you think you know what the user is asking about. Then you can say something like, “If you mean FOO, then you should do BAR. If you had something else in mind, please reply back to let us know.” Asking for more information or clarification belongs in comments, which only people with the supporthelp privilege can send.
Slang and idioms should be avoided in all Support answers. It not only looks unprofessional, but not all users will understand such expressions. Support helps people around the world, including non-native English speakers. Slang and idioms will often confuse such users.
In general, avoid sentence fragments. All the standard rules of good writing apply to Support answers. Nobody is likely to mind if you split an infinitive here or there or end a sentence with a preposition, but try to write clearly and concisely.
Avoid phrases like "Hope this helps".</strong> It looks unprofessional and some users will read it as a sign of uncertainty.
Put your entire answer into one reply. We don't want people flooded with e-mails in reply to their support requests. If your answer has already been sent to the user, and you left something out or made a mistake, then you need to post a follow-up, but try to prevent that from happening. If your incorrect answer is still a Screened Answer, no harm has been done; rewrite it completely and correctly rather than submitting a follow-up.
Don't link back to the request itself. The link is added automatically to the response sent by e-mail.

Helpfulness

Helpfulness involves actually giving the user an answer to their request that they can use. The entire point of Support is to help people. We want to do it kindly and without offense, but we need to make sure that we help them.

Specific rules:

Always point users toward relevant FAQs. It's good for them to know the FAQs are there and they may find it useful if they run into further problems.
When including a FAQ from the drop-down, somewhere in the body of the answer there should be a mention of why the FAQ was included. This can be a simple sentence like: The above referenced FAQ explains how to validate your account. The importance of mentioning it is twofold, one to make it clear to the user how the FAQ relates to their request. Often the relation is obvious, but in some requests it may not be apparent to the user. The second reason is to ensure that the user knows there is a FAQ link that should be followed. Most users will read their answers in email, and the answer will embedded in some other text about the Support request. This can sometimes be confusing, and we want to make things as clear as possible.
Don't quote the FAQ unless you are quoting a small excerpt to highlight the information. In general, just direct the user to the relevant portion of the FAQ.
When linking to guides, do not link directly. Use the find?guide= format instead. Ideally, one day all the guides will be translated. The direct links may go to only the English versions while the find?guide= format should go to the version int he user's language of choice. Whether it ends up working this way or not, we prefer to have volunteers get into the habit of doing it this way now.
Be very careful whenever you tell a user to make a change involving things outside LiveJournal, such as turning on cookies or turning off email filters. Always either tell them to do it in a way that only affects LiveJournal or warn them about the possible downside to what they are doing. With filters, you may want to recommend they adjust them to allow LiveJournal emails through without affecting the rest of the filters.
Never tell a user to give their password to anyone. If the user brings up the idea, explain why that is a bad idea.
Don't tell users to delete their accounts unless they are asking how to delete their accounts. If you have a really good reason to do so, recommend they back up their journal first in case anything goes wrong.
Don't assume the user is using a particular client, web browser, or operating system. If you're not sure give a generic answer. Explain how to do things with any client listed on the account. If they don't list a client and they want to do something that is easier with a client, mention that.
Don't mention sites that offer various services, such as remote image hosting, hosting other journals, etc. It's better to tell them to search the web and in the case of images to check with their ISP. These policies change rapidly and without notice. Refering users to a specific site generally causes more harm than good.
</strong>Answers must thoroughly answer both the user's direct question, address any misconceptions the user has about LiveJournal, and address any obvious LiveJournal problems the user has.</strong> This means that if the user asks about getting a source code, but clearly wants an invite code, you should address the fact that the source code is a different thing from an invite code. Likewise if a user asks about how to add a user picture, but the account isn't validated, you should tell the user how to validate as well as how to add a user picture.

Support Communities

The main journal for Support is lj_support. Every Support volunteer should read it. Official policies are announced there and relevant LiveJournal news is relayed there. Sometimes the direction that LiveJournal Support should take is discussed there. Any volunteer may read it, but only experienced volunteers are granted posting access. Posting access and membership is given when a volunteer earns supporthelp priv in any category of Support.

The next community to consider is learn_support. This community is open to all volunteers. It is used to give tips on how to better answer in Support and to ask Support-related questions.

Many of the Support categories have communities. The ones that do will be described below.

support_clients is the community for the clients category. It is recommended to all volunteers who answer in clients.

support_comms is the community for the communities category. Anyone who volunteers in communities is welcome to watch it, but it is not required. Only those with supporthelp priv can post.

support_general is the community for the general/unknown category. It is not required for anyone, and should only be watched by those with supporthelp priv.

support_upi is the community for the user picture icons category. Anyone who volunteers in user picture icons is welcome to watch it, but it is not required. Only those with supporthelp priv can post.

support_web is the community for the web interface category. It should be watched by all with supporthelp priv, but is not recommended for other volunteers.

Other Support Communities:

lj_supportadmin is the administrative community. Only category admins and LiveJournal staff have membership there. While any volunteer may watch it, and sometimes posts are made publicly, for the most part there is little worth seeing there for non-members.

support_interim is the community for interim privs. When you earn interim privs, you will be added, until then it is not worth watching.

supportlounge is an unofficial community where many Support volunteers post about their Support experience, amusing Support related events, or share particularly impressive requests.

customization is an official community for the discussion of tutorials for inclusion in howto. Customization is not a part of the Support Board, but it is closely tied to Support and considered a part of the Support system.

privchange is a journal where the addition and removal of Support privs is announced. No one is required to watch it, but many volunteers wish to know about priv changes.

howtosupport is an official community with tutorials about writing Support answers and understanding various aspects of LiveJournal that frequently come up in Support.

Other Helpful Communities:

All of these are helpful in their own way, but most volunteers will not want to watch them all. You should see which you find tend to be most useful for you.

lj_biz is for the discussion of LiveJournal business matters.
changelog is where changes to the LiveJournal code are announced.
lj_dev is where development changes are discussed.
lj_maintenance is where outages and networks problems are announced.
lj_userdoc is for discussing the FAQs and guides.
news is where important LiveJournal news is announced.
paidmembers where news related to paid user accounts is announced.

Why Answers Don't Get Approved

Support takes patience and dedication and new volunteers should not expect to get approvals or points quickly. How long it takes will depend on what skills you enter Support with, what you read, and how much effort you put into it. Keep in mind that only approved answers can earn points and that not every request closes with credit. For more details about how the Support system works check over the section about it.

One common reason for not getting approved is not being first. As a new volunteer, you can't see other answers. When an answer gets approved, compare the timestamp. If it is earlier than yours, then it was also screened.

Another common reason for new volunteers not being approved is that their form doesn't meet Support standards. Support likes to have a very professional appearance. Things like emoticons (e.g. :)), "Hope this helps.", slang, poor spelling, and incomplete sentences can keep an accurate answer from being approved.

Answers should always be in one complete screened answer. If you notice you made a mistake, resubmit a new complete answer without the mistake. Do not submit a correction. Since your answer hasn't been approved yet, the corrected version can be sent to the user. Almost every volunteer will mess up sometimes and re-submit. There is no reason to worry about resubmissions. However, if you find you are constantly resubmitting answers, then you should proofread more carefully before you answer. You may wish to write your answers in a text editor so that you can see them more clearly.

Another possibility is that the answer required more information. There are three issues that must be considered in every request. First, the user's explicit question must be addressed. Second, any misconceptions that the user has must be addressed. An example of this is a user asking for a source code to start a journal. The user probably means they want an invitation code, so there should be a brief explanation of what each code is and how each is used. Finally, the answer must address any other issues the user needs to be informed of, but wouldn't have known enough to ask about.

One example of this is a user asking an unrelated question, but the account is not validated. Validation must always be addressed when it comes up as not being validated will lead to several problems for the user. Another example is a user asking about validation for a new account who lost the email. The email includes information on how to get started. The user might not realize this and know that it also was lost, so you should also point the user to the How do I get started FAQ.

For more information on why your answers weren't approved you can ask in learn_support. Please read the community's guidelines. Remember, if no answer has been approved yet, then wait to find out what will be. Sometimes simply no one qualified to handle the request has gotten to it yet. If no answer is approved yet, your answer may be fine.

How to improve at Support

There are several things you can do to get better at Support. By reading this, you've already started. Another is to go through the memories for various Support communities. A good way to improve is to look over approved answers. Don't copy them, but see how they're written and what sort of information they contain.

While answering requests, read them carefully. What things might the user mean? If the user may be referring to multiple things, address them all. If the user asks multiple questions, answer them all.

Read over your answer carefully. Is it well-written? Is it spaced nicely? Does it include references when needed? Did you mention every FAQ you used?

Think about what the user knows and what the user needs to know. Try to make sure your answer provides all the information the user will need to resolve the issue. Also make sure you address any misconceptions the user has or alternate methods of accomplishing the goal.

Learn the FAQs and check them every so often, since they do change. An answer that doesn't include a relevant FAQ will almost never be approved. Part of being able to answer most Support requests is knowing where the relevant information is.

Look over the information provided with the request. Is this a logged in user? Is the account validated? Is the user free or paid? These things may have an effect on the answer.

Try to answer questions and check back to see what got approved. How was it different from your answer? If it was your answer, then great. Look at requests you can't answer, and check back on them to see how they do get answered.

Ask questions in HelpScreening and get a review. After you have learned the basics of a category, you may wish to inquire about getting a mentor.

Reviews

Reviews are a wonderful way of learning how to improve your answers in Support. They involve an experienced volunteer looking over all of the requests you have recently tried to answer in a category and giving you feedback. It allows Support volunteers to get feedback that is more personalized to their needs, and it helps the category admins to keep track of your progress.

Since Support is divided up into different categories, each run by its own category admin(s), reviews are generally done for one category at a time. To get a review, contact the admin(s) of the category you are interested in. They may not review you themselves, but they will make sure someone competent does. If you do not know the admin(s) for a category you are interested in, submit the request to support@livejournal.com and ask them to forward it to the relevant admins.

There are four basic methods used for reviewing. The first is that you collect requests to be reviewed. The second is that you collect requests to be reviewed that are then supplemented by the category admin. The third is that you request a review and the category admin collects all of the information. The fourth is that you are given example requests to answer, which will then be reviewed. In any of these cases, you may also be asked to comment on what you did and why and anything you learned from the request.

To gather requests for a review, go to the Support board and filter to you replied and whatever category you want a review in. Do not remove any requests from this filter unless you are specifically instructed to.

Then make an email with the URLs to each request in that filter. Include your username and whether you have any privs in that category, and if so, which privs. If you have any specific questions about some of the requests, include those as well, that way the reviewer can address them.

How helpful a review is really varies. Some volunteers find them to be the best way to learn, others do fine on their own. Sometimes a review happens at just the right time to help a volunteer improve further, while other reviews for the same volunteer don't help much. But they are definitely worth a try. New volunteers should generally get a review in any category they've been working in to a moderate extent for two weeks or more. Then get another after about three weeks or so, longer if you spend a significant amount of time away from Support during that time. Volunteers with all of the interim privs should generally be reviewed more often. These are just rules of thumb and will vary from person to person and category to category. Always feel free to ask a category admin about what they think is best for you.

When you get your review, you should expect comments on how your answers could be improved. But do not expect every request you submitted to be mentioned in the review. Often several requests have the same problem or were all done well. In these cases, there is little to say, and they will often simply be removed. If a large number of your requests are removed you either likely do a lot of similar request types or are doing very well.

A review can take a while to get done, especially depending on the size of the review, the time of year (around holidays many volunteers may be away or busy), the category, and just luck. If you don't hear back about a review you sent after a week, send an email asking if it was received and whether everything is okay. Sometimes emails get lost or misplaced, and we don't want any volunteers being ignored through such accidents. If another week passes, send another reminder, the admin may need to get in touch with the volunteer doing the review to make sure no problems came up.

Your review or its summary wll then likely be shared with the supporthelp privs for that category. This is to help the supporthelps to better teach you about Support, and because in most categories the supporthelp privs help to decide when new volunteers are ready for different levels of privs.

If for any reason the requested review format causes problems for you, discuss it with the admins for the categories you are interested in. These formats tend to be easiest and work best for most volunteers, but special arrangements can be worked out at times to meet a particular volunteer's needs.

Mentoring

Support Privs

There are many privileges or "privs" associated with Support. A priv is what gives someone the technical ability to do something. Most privs are publicly viewable at http://www.livejournal.com/admin/priv/

Support volunteers will also refer to someone with the priv as a priv. So, the group of people with any of the interim Support privileges are collectively referred to as the interim privs.

All Support privileges are given on a per category basis. Some people will have privileges in all categories, but they either are in administrative positions or have earned privs in each category.

There are four interim privs. They are:

supportviewscreened - the ability to see other screened answers in requests
supportmakeinternal - the ability to make internal comments in requests
supportviewinternal - the ability to see internal comments in requests
supportmovetouch - the ability to change the category of a request or re-green a request

Interim privs will be explained more fully in the sections on I1s and I2s. They stand for interim level one and interim level two. Level one consists of having supportviewscreened and supportmakeinternal. Level two consists of having all of the interim privs.

Supporthelp is the priv that allows a volunteer to approve screened answers and make comments. It also allows the volunteer to submit an answer that does not need to be approved, but this is rarely used. It is generally reserved for times when the board is flooded with requests, such as during technical difficulties, to quickly answer numerous requests on the same subject. Another function of the supporthelp priv is the ability to change the summary of a request. The summary is the text that appears on the Support board about the request. Supporthelps generally help to teach newer volunteers how to answer in Support.

Supportclose allows a volunteer to close requests and assign points. This priv is generally reserved for Support administrators.

There are also admin privs that allow someone to give privs to other people.

Understanding the Categories

The following are the public Support categories: clients, communities, embedding, general/unknown, user picture icons, web interface.

The following are the private Support categories: abuse, account payments, press, privacy, support@, webmaster.

The public categories are best understood by looking through relevant communities and Support community memories. An explanation of the private categories and how they affect Support volunteers is below.

Abuse - this is the team that handles reported violations of the Terms of Service. All requests reporting specific journals for suspected abuse such as harassment or copyright violations, reporting "hacked" journals, asking questions about suspended accounts, asking legal questions, or asking about the Terms of Service should be moved to the abuse category. Requests from the parents of minors should also generally be moved to Abuse as they need more delicate handling. If you see an abuse request in Support and do not have the ability to move it, check the userinfo for lj_abuse. Contact people who are members of the community and one of them will move it for you, if it is deemed to be abuse-related.

Account Payments - this category handles problems with account payments. If a user didn't have a payment go through or had a problem with how their payment was processed, it is handled by accounts. Unless the request contains personal information, such as a credit card number, it can generally sit on the board until someone with the ability to move requests sees it. If it does contain personal information, contact a supporthelp priv to move it. You can start by contacting category admins, as they generally are around and have LiveJournal email addresses that are easy to find. You can use the members list for lj_supportadmin as a guide for who can be contacted.

Press - handles requests from the press for information. If someone wants an interview or quotes from LiveJournal staff members, it should be moved to press. These requests can generally sit on the public board until a volunteer capable of moving them sees them.

Privacy - handles questions about the LiveJournal privacy policy or concerns about LiveJournal sending out spam. These are rarely urgent and can sit until moved.

Support@ - handles junk requests such as duplicates and nonsense. For those who can move requests, duplicates should contain an internal comment linking to the other request by the user. These requests can sit until moved by someone with the privs to do so. Support@ also handles forwarding private requests when the category is unclear. If you have the ability to move requests, know a request should be private, but don't know where it should go, move it to support@ with an internal comment asking them to forward it. Support@ also handles requests that would be on the general board, except they contain personal information that must be kept private. These requests need to be moved quickly, and if you see one, but do not have the privs to move the request, contact a supporthelp as explained in accounts category. Finally, support@ handles requests about Support itself. If you need to report a complaint or problem with a Support volunteer or the Support system, you can open a request in support@. You can also use support@ to ask private questions about Support that you don't know where to ask. Support@ should be contacted if you wish to leave Support and have your Support privs removed.

WebMaster - requests about business issues, security holes, or the death of a LiveJournal user. Security holes need to be moved off the public board immediately, see the accounts category for details.

Special Note: Sometimes we get reports that a LiveJournal user may be commiting suicide. While there is only so much that LiveJournal can do in such cases, they need to be handled immediately. Sometimes the authorities can be contacted. Either Webmaster or Abuse can handle such issues. The most important thing to do in such cases, is to make sure it is brought ot the attention of the people who can deal with it. Please, do not be shy about emailing people. We would rather more people get contacted than necessary than that the request be overlooked.

Some requests are unclear about whether they should be public or private. In these cases, always err on the side of privacy. A request can easily be moved back to the public board. Also, with requests that should be private, it is even more important that you respect the privacy of the requestees, and you are expected not to discuss such requests at all. Do not post about them, even to get them moved, as this just causes more people to see them. Ideally, all private requests would go to private categories, but when they don't, we expect volunteers to act respectfully toward the requestees.

Embedding co-admin

jproulx — Sat, 21 Dec 2002 07:04:01 GMT

I'm giving chemicallace co-administration status in embedding. When I have more details, I'll post to lj_support.

Until the Interim Plan is Ready

leora — Sat, 14 Dec 2002 20:07:56 GMT

Note: this post is public, as I really didn't see any reason to make it confidential.

I think until the interims have an approved plan and email, category admins should continue sending out welcome emails themselves as they see fit. (Note: if any of them want the email I have or any of the other standardized emailings, just let me know.)

I don't want to rush the interims, nor do I want the new volunteers to lose out while we wait for the interim plan to be ready. So, I think it's best for us to just email, and let them know whom we've contacted. That's my opinion. :)

Note: this post is shockingly free of chinchillas. How sad.

Pending Absence

macheide — Wed, 07 Aug 2002 07:18:49 GMT

I have a business trip coming up that will so heavily occupy my time as to take me 100% out of action beginning next Tuesday, August 13, through Monday, August 19. I'm expecting that arie will be carrying all cust admin through that period, although she could probably use an extra hand or two (or new computer or new OS).

Suggested Support Change

leora — Tue, 02 Apr 2002 01:15:30 GMT

This has been brought up informally in various places, but never formally discussed. And since several other support improvements are in the works (of which I am very appreciative) it seemed a good time to find out if this would be a wanted change -

Making support request answers default to screened answer

I view it as a good idea because this way if anything messes up it doesn't go through to the user. And you have to decide to send something publicly. We've had people have computer problems that sent an answer through. We've had people simply forget to change the option. This should cut down on anything like that.

Also, I think at this point most privs choose to answer screened and then approve anyway. So, while this would annoy a few people, they would still have the ability to select answer, and most people would probably find it more convenient.

Since this would likely affect the private categories as well, I think if people think it's a good idea then we should ask people who deal with the private categories, such as Tommyx (is there anyone else who doesn't read this community? I had listed Sherm, but since I made this public, he'll see it) whether they have any objections.

Hmmm, I thought about public/private level on this, but see no reason to make it private. I primarily want the opinions of the other admins, but it would affect all support volunteers with supportpriv.

So... opinions?

New Support Category

opiummmm — Fri, 29 Mar 2002 15:11:48 GMT

There's a new category available, "communities", and I was wondering if gooner would mind admin'ing it?

Note to highway

opiummmm — Thu, 28 Mar 2002 14:44:49 GMT

This CVS commit changes the format of the embedding page, and it shows a new ASP method. Later on tonight it'll be merged in live, but for now you can see the changes at http://goathack.livejournal.org:8006/developer/embedding.bml

opiummmm — Thu, 28 Mar 2002 06:22:02 GMT

 agree, don't make any changes however, every one that previously had supportclose please notify the cat admin if for some reason you will be away from support for a long period of time. As for me at this point I will almost exclusively look at items 7+ days, other support admins may do the same at this point.
 
We'll have some new features that will keep track of who closed what and when, and the ability to reverse things soon so for now just talk to each other using internal comments or in the respective support community.
 
To those who have supportclose within a cat (cat admin), if you are monitoring something and don't want a support admin to close something, if it is over a week old, make an internal comment that YOU will are dealing with the request and will close it later, otherwise...it might be closed by support admin.
 
Sound good?
 
-dak
----- Original Message ----- 
From: Adrien LaBombarde 
To: Rob Martin 
Cc: Dakus Lat ; Jesse Proulx 
Sent: Wednesday, March 27, 2002 9:19 AM
Subject: Customization Supportclose


Regarding the quoted note below, NO, gooner, please don't stop the valuable work you've been doing on supportclose, at least not for the customization area. I'm hoping that the addition of myself along with two aides --- highway and nilesta (when she returns) --- might be able to add to the efforts of you and the others sufficiently to maybe keep the hangover stuff down to some acceptable level. If all I do is replace your work, we'll still be short-handed. If anything, I'm the new kid on the block when it comes to supportclose, with much to learn from you and the others. By all means, continue.
 
Eventually, I imagine that it might be useful to set up some ways to coordinate, so we have consistency in our work so users and volunteers know what to expect, and so we don't trip over each other. For the time being, though, unless anyone has an opposing view, I'd just as soon work like we are doing now, and let the ways of coordination emerge from how we do that by instinct.
 
Thanks for all you're doing, and let me know if there's anything I can do to make it easier or better for you.
________________________________
macheide
 
 
----- Original Message ----- 
From: "Rob Martin" <gooner_@hotmail.com>
To: <leora@livejournal.com>; <macheide@livejournal.com>; <mega@livejournal.com>; <visions@livejournal.com>; <highway@livejournal.com>
Sent: Tuesday, March 26, 2002 3:57 AM
Subject: lj supportclose stuff


> Hey!
> 
> Just a short note about supportclose.  As some of you will probably be 
> aware, for the last few months, I've had supportclose and been going though 
> the board daily and closing off requests.
> 
> Now that you have all been given supportclose for your categories, I will 
> assume you will want to do this yourself?  If you want sole responsibilty of 
> supportclose over your cat, just let me know.  I don't want to be treading 
> on any toes, so I'll leave things until I hear back from you.
> 
> Thanks!
> 
> -Rob
> (gooner)
>

Admins - supportclose

opiummmm — Mon, 25 Mar 2002 08:57:22 GMT

Dakus and I now have the admin priv over supportclose, so all of the category admins can now close requests in their category. If you want one or two of your volunteers to have this priv also, please let us know here and we'll set that up.

Web Client

mega — Thu, 31 Jan 2002 09:06:58 GMT

I just thought I would make this entry so that people are aware that I am not ignoring what needs to be done etc. Within the next day or so I shall be posting about the web client. At this stage it appears that the web client support queries are in and dealt with, which is obviously good.

I aim to go through the old web client queries and find the biggest problems people have been having and also workout the types of responses that support volunteers (priv'd and non-priv'd) have been giving.

Current Policy on Reporting Volunteers?

leora — Sat, 26 Jan 2002 14:22:32 GMT

Should people contact Dakus, Opi, and me? Or the admin of the category? Or all of the above? ...

This is something I wrote up for the support guide, but I wanted to make sure it was right before it was added, and now with the new system I really don't know. So I'll include what I wrote and when a policy is worked out it can be edited and added to the guide in some form. Slightly edited to reflect changes that I know affect it.

The guide can leave out the information altogether and simply say to find out the current correct procedure if you need to report someone. But we should sort out what that is regardless.

Reporting Support Volunteers

There are two reasons to report support volunteers: they are screened and doing very well and should be considered for supportpriv or they are causing problems.

The first is rather simple. If you have supportpriv and you see someone you think deserves it, either post friends-only in the appropriate community or email the category admin(s).

While we'd like for this to never be necessary, there may come a time when you see a support volunteer acting inappropriately. In order to maintain the high standards of the support board, support volunteers should report certain kinds of actions. If you feel there is something you need to report, please read this section thoroughly.

The sorts of things that need to be reported are people abusing their support privs by sending inappropriate messages, people consistently sending inaccurate answers, and people trying to unfairly gain support points.

Inappropriate messages can be ones that are rude to the users, bash the users publicly or in internal comments, or are simply off-topic.

Inaccurate answers are answers that are either consistently wrong or incomplete. Especially note any that may be actively harmful to the user or LiveJournal. Harmful answers involve asking the user to make inappropriate permanent changes, such as deleting information that did not need to be deleted or stating LiveJournal policies that are incorrect or outside the domain of support. Policy statements should generally be avoided unless you are absolutely sure it is LiveJournal's policy.

Unfairly trying to gain support points includes posting requests solely with the intent of answering them, having friends post requests for a specific user to answer, or having a bias in which answers are approved. Note that collisions are not considered an unfair way to get points, so if a user with supportpriv posts at almost the same time as you and that answer goes through and yours does not, that is not abuse. If you are a screened user and suspect unfair approval processes are in place, you
should post to learn_support first to ask why one answer was approved instead of another as most such situations are for reasons that new support volunteers may not notice.

In general, a single instance is not enough to warrant reporting someone. You should generally consider contacting the support volunteer privately and helping to correct inaccuracies before trying to take disciplinary measures. Most problems can be resolved simply by talking to the support volunteer. Support volunteers are not expected to be perfect, a mistake now and then is acceptable. However, if problems continue you should report it so that it can be dealt with.

If you're not sure, you should report it anyway so that it can be looked into. It is the task of those who run support to ensure its quality. Remember, the most important goal of support is to help users and that requires a good support staff. It is not your responsibility to judge who needs to be disciplined or reminded of some aspect of support, but it is considered a responsibility of every support volunteer to let those in charge know when someone is doing very well and might deserve support priv or very poorly and might need special attention. It is not your responsibility to try to reprimand them yourself.

Reports should currently be emailed to dakus, opiummmm, and leora. This may change, so if you have
taken a break from support and are not sure who is currently responsible, you should re-check this information or ask someone who knows.

Preparation for S2 Support

macheide — Wed, 23 Jan 2002 06:42:38 GMT

Another task to add to the initial list I posted here yesterday: to prepare the way for the advent of S2. Even after any wrinkles in the programming have been ironed out and the user interface is smooth as silicon and the documentation is in place, we all know that S2 is going to hit the customization support like a tsunami. And while the success of S2 will not depend on support, we're going to be an unnecessary drag if we're learning it right along with everyone else, not to mention the disservice we do to LiveJournal if we're caught playing catch-up.

I for one would hope to be an expert on S2 from day 1. I'm ill prepared for that, I'm afraid: my strengths taper off quickly once we leave the HTML/CSS shoreline. Even so, I think this one's too urgent a priority to commit to anything short of knowing S2 cold by the time it's set to launch.

I'd heartily welcome company in the effort to prepare support for S2. I'd welcome even more someone helping me get past my mental blocks that have hindered my progress on this so far.

Customization Supporthelp Privileges

macheide — Wed, 23 Jan 2002 06:42:38 GMT

[The following is advance-posted here for discussion from any of the support admins. If there is no objection, I'll give it the broader posting over in lj_support itself]

During the current transition period, obviously anyone with general supporthelp privileges should continue to have supporthelp privileges for customization questions. Volunteers with such privileges should continue to respond to customization questions, place notes on customization traffic, approve screened customization responses, and change categorizations, all within the existing guidelines.

Clearly, however, we are in the process of transforming the system into one where the general practitioner will not be authorized to perform specialized surgery, so to speak. At the end of the transition will be a set of volunteers with customization supporthelp privileges -- very likely smaller than the current set of volunteers who have general supporthelp privileges, but possibly adding at the outset several current candidates who are not yet privileged.

During the next 1-2 weeks, I plan to review the "portfolio" of responses for each current volunteer with general supporthelp priv, with the goal of making a batch recommendation to opi and dakus for granting of customization supporthelp priv. I also plan to conduct a similar review of non-priv volunteers who have been active in making screened customization responses during recent months.

If you are a volunteer with general privileges or an active candidate, you don't need to put in an application: I'll be checking everyone. And don't worry too much (yet) about the different customization philosophies some of us have; I'm not here to enforce mine, only to try to make sure that users get the best from any or all perspectives. Anyone wishing to contact me directly about this stage of our process can contact me directly at macheide@livejournal.com.

Customization Support Resource Inventory

macheide — Wed, 23 Jan 2002 06:42:37 GMT

For those who work on LiveJournal customization support, I would appreciate knowing the following information: type of computer; operating system; browser and browser version most frequently used; screen resolution; and any additional background information that might be relevant to an inventory of the resources we collectively bring to the support effort.

As one of many examples I could point to, if AOL is still behaving as it did when I'd finally had enough and quit a few years back, then a customization that works fine for Navigator or Explorer outside AOL won't necessarily do what we want for those who browse within AOL, even if AOL says it's using one of those browsers. If that remains true, then it would be good to know if we have any AOLers on call. We can't be all things to all users, but it would be good to know where we have to draw any lines.

Customization Support

macheide — Tue, 22 Jan 2002 14:51:19 GMT

For the immediate future, I anticipate seeing no significant changes for customization support other than possibly getting the leftovers out of the refrigerator earlier and reducing the load for dakus and opi. For the most part, at least for now, things will remain as they are for the support volunteers themselves:

Privs--If you already have general support priv status and are willing and able to respond to a customization question, don't wait for us to get the department up and running any differently. Keep on providing customization support according to the guidelines we've developed up to now, and let's make the transition as smooth and seamless to the user as possible.

Screens--If you are currently answering customization questions on a screened basis, don't stop. If your response is one that would have been approved yesterday, then it will be approved tomorrow just as well.

Personally, I see my first tasks at hand being:

Customization Clean-Up--Taking over the load of closing out old customization support requests and establishing protocol for regularly keeping up after that task.

Mentoring of New Customization Support Candidates--Keeping an eye out for fresh talent and assisting new people to join in with the team.

On-Going Customization Support Admin--I myself will be answering a whole lot less (unless I see something going stale), and will instead devote any spare time that I would have had into re-categorizing mis-categorized questions, approving acceptable screened traffic, and other such tasks. Of course, unless and until we modify any of the privs and duties, everyone with general priv status should continue to help out with those tasks as they have previously been doing.

Development of Policy and Protocol--I'm not anticipating diverging from the path that's already been set for us; but under the new departmental structure, there will be some new things that will evolve to help make the system work better for all of us.

But for now, until I've seen a bit more of where the edges of this new responsibility are, that's pretty much it. If and when we change any policy, procedure, or whatever, there will be discussion here before we venture too far. Mainly, we'll be aiming to do the best we can to facilitate and enhance customization support within the volunteer framework that has served LiveJournal well to this point.

Two thoughts about the new system

leora — Tue, 22 Jan 2002 10:08:28 GMT

On lj_support access
First off - I assume someone who gets privs in any category will be given privs to post and read friends-only entries in lj_support. If for some reason this is not the case, or some category admin wants these to be given out separately, I'll need to know.

On the off chance someone is removed from a category, I also need to know if posting/member access should be removed. If the person has access because of multiple categories, then it won't be an issue if they lose access to one. If they lose access for some reason that shows them to be unfit as a priv, then I would assume that dakus and opi should be told, maybe the other admins should be notified so that it can be decided if they should be removed altogether. If the person simply isn't doing well in that category, there may be no reason to pull access from the community journal.

I'd like to think it'll never come up - but the larger we get the more likely problems will come up from time to time, best to be prepared in advance.

On adding new privs
This is solely meant to make people think.

If we start adding people solely when they ask to be added we will run into the issue of people who don't ask to be added.

People might do this for one of two reasons:
a) They're nervous about asking
b) They'd prefer to be added when they are seen as good enough, it'd mean more if they just got added as opposed to having to ask. (This sort of thing shows up on the contributors list currently.)

So if we don't add new people who don't ask, we lose the benefit of them having privs, but if we do add them on our own, it encourages the above two issues.

To the admins

opiummmm — Tue, 22 Jan 2002 09:36:59 GMT

You are in charge of your department. You will be responsible for its upkeep, and also for the quality of answers given within each.

You will have every means to accomplish this, including being able to choose who can answer in your category. (if you wish to give someone the supporthelp prv for your category, go ahead and post that person's name as a top-level post in the community, and dakus or I will take care of it)

You can set the precedents/procedures for your category, and can write up whatever documentation you feel necessary for new people. You will also have a strong influence over the content that goes in FAQs.

If you wish to create a new community for your department, by all means do so, but please do not leave this community in the dark about what goes on in your community. A short post every once in a while is better than complete silence in this community.

Procedures that effect every department will be discussed here, and then once presentable, will be posted in lj_support.

I think that's about it.

Initial post.

opiummmm — Wed, 16 Jan 2002 09:59:58 GMT

This is the community for support admins. This is where we will discuss policy, and outline the criteria for support volunteers. This is a closed community, only in the sense that only support admins can post here. Anyone is free to take part in the public discussions, however.

LiveJournal Support Administration Forum

Guide Part II

Interim Level One

Interim Level Two

Summary Tags

Being a Supporthelp Priv

Leaving Comments

Approving Answers

Reporting Volunteers

Leaving Support

Support Oddities

Negative Time

Posted NEVER

Requests Disappearing

Requests with Multiple Answers or Comments

Requestees Talking to Themselves

Social Aspects of Support

#lj_support and IRC

Answered With Elegance (AWE)

Support Bunnies

Support Cats

Chinchillas

The French Toast Support Category

Useful Links

Glossary of Support Terms

Guide Part I

So You Want to be a Support Volunteer

Table of Contents

Introduction

Basic Support Rules

How Support Works

Support Rules in More Detail

Courtesy

Professionalism

Helpfulness

Support Communities

Why Answers Don't Get Approved

How to improve at Support

Reviews

Mentoring

Support Privs

Understanding the Categories

Part 2 of the Guide

Interim Level One

Interim Level Two

Summary Tags

Being a Supporthelp Priv

Leaving Comments

Approving Answers

Reporting Volunteers

Leaving Support

Support Oddities

Negative Time

Posted NEVER

Requests Disappearing

Requests with Multiple Answers or Comments

Requestees Talking to Themselves

Requests Regreening or Not Regreening

Social Aspects of Support

#lj_support and IRC

Answered With Elegance (AWE)

Support Bunnies

Support Cats

Chinchillas

The French Toast Support Category

Useful Links

Glossary of Support Terms

The Guide - Rough Draft, Almost Complete Part 1

So You Want to be a Support Volunteer

Table of Contents

Introduction

Basic Support Rules

How Support Works

Support Rules in More Detail

Courtesy

Professionalism

Helpfulness

Support Communities

Why Answers Don't Get Approved

How to improve at Support