Part 2 of the Guide
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
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 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
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
Similarly to negative time, if a request is less than a second old or believes it is, it will show up as posted "NEVER". In the normal course of Support, you will see these from time to time. It means you just happened to catch the request just as it came onto the board. It will appear normally at the next refresh.
Requests Disappearing
Sometimes you will do something in a request, and then not be able to find that request again. It may vanish from both the open and closed requests. This generally means it was moved into a private category. Usually you won't get points for such requests, but every so often an answer given publicly will be used in support@. This means you can get points that you then can't find.
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
Sometimes you'll see comments from the user who opened a request that look like half of a conversation. They may say that the problem isn't something that wasn't brought up yet or add additional information without prompting. These requests can look very odd. What they tend to be are requests opened by someone with support privs. They are replying to screened answers or internal comments that they can see.
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
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.
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
There are many links that you may find helpful, both for your own reference and to reference in Support requests. However, before referencing any link, you should always check that the link currently works and contains the expected information. Some of these links aren't official; they are included because volunteers find them helpful.
American Registry for Internet Numbers search: http://www.arin.net/whois/index.html
Banners: http://www.livejournal.com/banners.bml
Birthdays: http://www.livejournal.com/birthdays.bml
Cluster Checker: http://www.livejournal.com/misc/whereami.bml
Color Code Guide: http://goathack.livejournal.org:8055/docs/color_codes.html
Color Usage Guide: http://goathack.livejournal.org:8055/docs/usageguide.html
Communities Reference: http://www30.brinkster.com/communities/index.html
Console: http://www.livejournal.com/admin/console/
Console Reference: http://www.livejournal.com/admin/console/reference.bml
CVS Repository: http://www.danga.com/lj/cvsweb.cgi
Debugging Page: http://www.livejournal.com/misc/debug.bml
Documentation Index: http://home.att.net/~tribelessnomad/lj_support/docindex.htm
howto's memory page: http://www.livejournal.com/tools/memories.bml?user=howto
IRC Interface: http://www.callete.com/ljsupport/irc.cgi
Language Setting FAQ in English: http://www.livejournal.com/setlang.bml?uselang=en_LJ
Live Mode: http://www.livejournal.com/users/exampleusername/friends?mode=live
Meme Page: http://www.livejournal.com/meme.bml
Mood List: http://www.livejournal.com/moodlist.bml
News Link for Friending: http://www.livejournal.com/friends/add.bml?user=news
News Page: http://www.livejournal.com/news.bml
Portal: http://www.livejournal.com/portal
Priv Lookup: http://www.livejournal.com/admin/priv/
Similar Users: http://www.livejournal.com/interests.bml?mode=findsim
Statistics: http://www.livejournal.com/stats.bml
Status: http://status.livejournal.org/
Status of the Directory: http://status.livejournal.org/directory.html
Style Browser: http://www.livejournal.com/styles/browse/
Suicide Crisis Handling: http://www.livejournal.com/talkread.bml?journal=lj_support&itemid=38232
Style System Reference: http://www.livejournal.com/developer/styles.bml
Suggestions: http://www.livejournal.com/suggestions/
Variable List: http://www.livejournal.com/developer/varlist.bml
Terms of Service: http://www.livejournal.com/legal/tos.bml
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
Answered With Elegance - a posting of particularly well-answered requests to supportlounge to share with all of the volunteers. AWE posts come out irregularly.
BAR
This is a variable, like FOO is. It is used to represent that something gets filled in where it is used. FOO and BAR are the most commonly used, although others you may see are BAZ, QUX, GIN, and TONIC.
BBB
Big Blue Box - for a long time the box of known issues was blue. People are likely to still refer to it this way even though the color has changed. At the time of this writing, it is yellow, but it may change again. Some people are now calling it the Big Bright Box.
canned answer
A saved answer to a common request that is reused. These need to be modified to fit the particular request if the request is somehow different. A good volunteer knows when to edit a canned answer.
category admin
Someone who oversees one of the Support categories. Category Admins are usually the best contacts for information about their categories.
cats
While Support volunteers will sometimes discuss felines, this usually is referring to the public Support categories. People will ask a question like, "What cat is it in?"
close faery
This refers to anyone with the ability to close requests and assign points who has been actively closing the board. When closing isn't done regularly, it causes volunteers to get a large increase in points in a short time. Some volunteers refer to these points as coming from the close faery.
closing comments
This refers to going through requests and researching whether they are ready to be closed. Often internal comments are left pointing to evidence of the user having been helped. The name comes from before the ability to make summary changes, when all such requests needed comments to mark them as ready to be closed.
collision
When two supporthelps act at around the same time as each other, they can cause multiple comments/answers to go through. These are referred to as collisions. When multiple people comment answering the same question in a community, it is also referred to as a collision. Basically, a collision is any time that two or more people, by trying to be helpful, end up with a slightly less desireable effect.
comms
Short for communities. Usually used when referring to the communities Support category.
cust
Short for customization. Customization used to be a Support category and is still closely tied to Support.
custy gunk
Requests in the general/unknown category that would have been in the customization category when it existed.
degreening
The act of approving answers so that the requests turn from green to yellow.
disclaimer
A string of text in a Support answer used to warn a user about an issue. Generally there are a few more or less standard disclaimers needed for certain types of requests. An example would be that links to external site requires a disclaimer about it not being affiliated with LiveJournal.
snerk
hiccupping snicker, the kind of thing that makes milk come out of your nose.
filters
While this often will refer to things like custom friends groups, it can be used to refer to filtering the Support Board. Above the requests at the Support board are two drop down menus that let you see the Support board with only requests that meet certain criteria visible.
interim priv
Someone with some or all of the interim privs or a referall to one of the privs. Such as, WonderfulVolunteer is now an interim priv, because she just got two interim privs.
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
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 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
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
Similarly to negative time, if a request is less than a second old or believes it is, it will show up as posted "NEVER". In the normal course of Support, you will see these from time to time. It means you just happened to catch the request just as it came onto the board. It will appear normally at the next refresh.
Requests Disappearing
Sometimes you will do something in a request, and then not be able to find that request again. It may vanish from both the open and closed requests. This generally means it was moved into a private category. Usually you won't get points for such requests, but every so often an answer given publicly will be used in support@. This means you can get points that you then can't find.
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
Sometimes you'll see comments from the user who opened a request that look like half of a conversation. They may say that the problem isn't something that wasn't brought up yet or add additional information without prompting. These requests can look very odd. What they tend to be are requests opened by someone with support privs. They are replying to screened answers or internal comments that they can see.
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
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.
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
There are many links that you may find helpful, both for your own reference and to reference in Support requests. However, before referencing any link, you should always check that the link currently works and contains the expected information. Some of these links aren't official; they are included because volunteers find them helpful.
American Registry for Internet Numbers search: http://www.arin.net/whois/index.html
Banners: http://www.livejournal.com/banners.bml
Birthdays: http://www.livejournal.com/birthdays.bml
Cluster Checker: http://www.livejournal.com/misc/whereami.bml
Color Code Guide: http://goathack.livejournal.org:8055/docs/color_codes.html
Color Usage Guide: http://goathack.livejournal.org:8055/docs/usageguide.html
Communities Reference: http://www30.brinkster.com/communities/index.html
Console: http://www.livejournal.com/admin/console/
Console Reference: http://www.livejournal.com/admin/console/reference.bml
CVS Repository: http://www.danga.com/lj/cvsweb.cgi
Debugging Page: http://www.livejournal.com/misc/debug.bml
Documentation Index: http://home.att.net/~tribelessnomad/lj_support/docindex.htm
howto's memory page: http://www.livejournal.com/tools/memories.bml?user=howto
IRC Interface: http://www.callete.com/ljsupport/irc.cgi
Language Setting FAQ in English: http://www.livejournal.com/setlang.bml?uselang=en_LJ
Live Mode: http://www.livejournal.com/users/exampleusername/friends?mode=live
Meme Page: http://www.livejournal.com/meme.bml
Mood List: http://www.livejournal.com/moodlist.bml
News Link for Friending: http://www.livejournal.com/friends/add.bml?user=news
News Page: http://www.livejournal.com/news.bml
Portal: http://www.livejournal.com/portal
Priv Lookup: http://www.livejournal.com/admin/priv/
Similar Users: http://www.livejournal.com/interests.bml?mode=findsim
Statistics: http://www.livejournal.com/stats.bml
Status: http://status.livejournal.org/
Status of the Directory: http://status.livejournal.org/directory.html
Style Browser: http://www.livejournal.com/styles/browse/
Suicide Crisis Handling: http://www.livejournal.com/talkread.bml?journal=lj_support&itemid=38232
Style System Reference: http://www.livejournal.com/developer/styles.bml
Suggestions: http://www.livejournal.com/suggestions/
Variable List: http://www.livejournal.com/developer/varlist.bml
Terms of Service: http://www.livejournal.com/legal/tos.bml
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
Answered With Elegance - a posting of particularly well-answered requests to supportlounge to share with all of the volunteers. AWE posts come out irregularly.
BAR
This is a variable, like FOO is. It is used to represent that something gets filled in where it is used. FOO and BAR are the most commonly used, although others you may see are BAZ, QUX, GIN, and TONIC.
BBB
Big Blue Box - for a long time the box of known issues was blue. People are likely to still refer to it this way even though the color has changed. At the time of this writing, it is yellow, but it may change again. Some people are now calling it the Big Bright Box.
canned answer
A saved answer to a common request that is reused. These need to be modified to fit the particular request if the request is somehow different. A good volunteer knows when to edit a canned answer.
category admin
Someone who oversees one of the Support categories. Category Admins are usually the best contacts for information about their categories.
cats
While Support volunteers will sometimes discuss felines, this usually is referring to the public Support categories. People will ask a question like, "What cat is it in?"
close faery
This refers to anyone with the ability to close requests and assign points who has been actively closing the board. When closing isn't done regularly, it causes volunteers to get a large increase in points in a short time. Some volunteers refer to these points as coming from the close faery.
closing comments
This refers to going through requests and researching whether they are ready to be closed. Often internal comments are left pointing to evidence of the user having been helped. The name comes from before the ability to make summary changes, when all such requests needed comments to mark them as ready to be closed.
collision
When two supporthelps act at around the same time as each other, they can cause multiple comments/answers to go through. These are referred to as collisions. When multiple people comment answering the same question in a community, it is also referred to as a collision. Basically, a collision is any time that two or more people, by trying to be helpful, end up with a slightly less desireable effect.
comms
Short for communities. Usually used when referring to the communities Support category.
cust
Short for customization. Customization used to be a Support category and is still closely tied to Support.
custy gunk
Requests in the general/unknown category that would have been in the customization category when it existed.
degreening
The act of approving answers so that the requests turn from green to yellow.
disclaimer
A string of text in a Support answer used to warn a user about an issue. Generally there are a few more or less standard disclaimers needed for certain types of requests. An example would be that links to external site requires a disclaimer about it not being affiliated with LiveJournal.
snerk
hiccupping snicker, the kind of thing that makes milk come out of your nose.
filters
While this often will refer to things like custom friends groups, it can be used to refer to filtering the Support Board. Above the requests at the Support board are two drop down menus that let you see the Support board with only requests that meet certain criteria visible.
interim priv
Someone with some or all of the interim privs or a referall to one of the privs. Such as, WonderfulVolunteer is now an interim priv, because she just got two interim privs.