Support Guide
From SupportWiki
LiveJournal is a volunteer-friendly organization, 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. For many volunteers it will take weeks to earn that first approval.
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. We'll do our best to answer your questions according to the FAQ below.
Please note that there is a lot of material you can read, both here and in the official communities. Don't feel as though you need to read through everything right now. If you're new to support and you just want to get started now, just look over the "Mechanics" section, and leave the rest for when you have more time.
Mechanics
What are the absolute basics I need to know in order to get started?
First, feel free to jump right in! Support volunteers are a welcoming crowd, and you won't be causing a hindrance by leaving a screened answer. Trust what you know about LiveJournal, and trust what you've read in the FAQ.
Never contact users off of the Support board. Keeping all communication limited to the Support board ensures that users get the best possible answer, and we do not want users to feel harassed or stalked because of their Support requests. This includes leaving comments or sending emails for test purposes.
Do not copy other volunteers' answers, and don't copy the FAQ. If the user's question is answered by a FAQ, select that FAQ in the drop down box and direct the user to it, rather than copying and pasting what's in the FAQ.
If a request contains any private information or reports a security bug, leave it alone. Another volunteer will move it to a private category. Do not discuss or archive what you've seen; volunteers who are found discussing private information on the public board or using it for their own purposes may be banned from Support.
Please visit the following communities:
-
![[profile for lj_support]](/images/community.gif)
lj_support - the main Support community where policies are announced. Reading this community is required for all support volunteers. Membership is restricted to those holding the supporthelp priv, but you can and should watch lj_support from your Friends page.
- learn_support - the community for new Support volunteers (formerly called "helpscreening"). Volunteers at all levels are encouraged to post questions here about anything having to do with answering requests, or Support itself. This is a moderated community; please read the community guidelines carefully before posting.
If you notice mistakes in Support answers, or if you're concerned that you were passed over unfairly, email support@livejournal.com about it and the situation will be investigated by category admins.
How does Support work?
Users submit questions, which are then displayed on the board as green requests. As a new Support volunteer, your answers to these requests will be screened. This means that the user can't see your answer yet; neither can most other LiveJournal users. Someone else with more experience in Support will read your answers over and, if they are correct and meet Support's guidelines, they will send the answer through to the user. These guidelines will be explained in the policies section. Once an answer has been selected and sent to the user, the request will turn yellow in the main list and change from "Open" to "Answered, awaiting close".
Some internal information in Support requests will not be visible to you at first, most notably the screened responses of other volunteers. This means that sometimes you will answer a request that already has an acceptable answer recorded to it. That earlier answer will appear for you later, after it has been approved. This is certainly frustrating, but do not let it discourage you -- everyone experiences this at first. As a new volunteer you should focus on learning and practice, which can best be done by answering requests, even requests on which your answer is not approved.
Sometimes instead of an answer, a volunteer will make a comment. 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 follow up on a request. Comments are not eligible for Support points. If you see a request that needs a comment, you can leave that comment as a screened response. Senior volunteers can approve screened responses as either answers or 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 other volunteers, you can write it in a screened response with the words "INTERNAL COMMENT" all in capitals at the top. Internal comments should only be used if you have good reason to believe that the information you can provide is not common knowledge.
After a request has been answered, the user may reply with more questions. This is called a "regreen" because the request's color on the main board will go from yellow back to green. These further questions must then be answered, but they do not have to be answered by the person who answered the first question. In most cases, anyone can answer a regreened request.
Once the user's questions have been answered, either the user will close the request or it will sit until one of the Support closers comes to close it. This may take a week or longer, depending on the category and the request. Once a request is closed, it will only be visible if you specifically select to view closed requests on the main board, where they'll appear as red. Closed requests can be re-opened by users or by Support closers if either believe that the original question was not completely answered. Under certain circumstances, administrators may also lock a request, which prevents the user from re-opening it. Once a request has been closed for a few days, it will disappear from the main board, although it will still be available at its direct URL.
Requests can be closed either with credit to an approved answer or without credit. Only one person can receive credit for each request, so support closers try to assign points fairly. The users may also assign points when closing, but they also may choose to close without credit.
The point value of a request is based upon the time the answer was submitted, not when the request is approved or closed. The minimum requests can be worth is one point, and the maximum they can be worth is ten points.
Once you have earned points, they will show on your profile page, after your number of comments made and received. You can also see your point total on the High Scores page.
Why didn't my answer get approved?
Support takes patience and new volunteers should not expect to get approvals or points quickly. How long it takes will depend on what skills you have when entering Support, 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, see the previous section.
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 on the answers. If it is earlier than yours, then it was already there when you wrote your answer.
Another common reason for new volunteers not being approved is that their writing style is not in Support form. As part of keeping a professional appearance, Support uses a mainly formal writing style. Emoticons, "Hope this helps", slang, poor spelling, and incomplete sentences can keep an accurate answer from being approved.
Another possibility is that the answer required more information than what you provided. There are three issues that must be considered in every request:
- The user's explicit question must be addressed.
- Any misconceptions that the user has must be addressed.
- The answer must address any other issues the user needs to be informed of, but wouldn't have known enough to ask about. (The best example of this is a user whose email address is not validated who asks an unrelated question. Validation must always be addressed when it comes up, as not being validated will lead to several problems for the user, such as being unable to post comments or resecure their account in the case of a break-in.)
For more specific information about why your answers weren't approved, please ask in learn_support. As with all communities, review the community's guidelines before posting. You can also email your question to support@livejournal.com if you want your question to only be seen by category admins, or if you're concerned about a possible error in the approved answer.
What are the policies I need to know about?
A list of support policies may be found at Category:Support Policies.
Support is divided into categories, each of which is maintained by one or more category supportadmins who can set policies for that category. There may be some policies that only apply in certain categories. Category-specific policies are mentioned in lj_support entries and in the category's page on this wiki.
Training
How can I improve? What resources are available to me?
There are several things you can do to improve at Support. By reading this, you've already started. A good way to learn what to include in your answers is to look over approved answers. Don't copy them, but observe how they're written and what sort of information they contain.
While answering requests, read them carefully and try to understand the user's point of view. If the user is unclear and might be referring to a number of possible situations, address them all. If the user asks multiple questions, answer them all. Think about what the user already knows and what the user needs to know.
Read over your answer carefully. Is it well-written? Does the spacing make it easy to read? Does it include FAQ references when needed?
Learn the FAQs and check them every so often, since they do change. If you promise an answer is in an FAQ, read it yourself to make sure the answer will deliver on your promise.
Look over the information provided with the request. Is the account validated? What is the user's account level? What style system are they using? What diagnostics were submitted with the support request? These things may have an effect on the answer.
Try to answer questions and check back to see what was approved. Look at requests you can't answer, and check back on them to see how they do get answered. You can turn on notifications to get an email every time a new request is opened in a category that you're interested in. Ask questions in learn_support and get a review. After you have learned the basics of a category, you may wish to inquire about getting a mentor.
What are the official Support communities?
The main journal for Support is lj_support, and the main journal for screened volunteers is learn_support, both of which were explained earlier in this Guide.
Many Support categories have official communities. They are:
- support_comms - Communities
- lj_userdoc - Documentation
- support_general - General/Unknown
- support_entries - Entries
- support_mobile - Mobile Features
- support_sb - ScrapBook
- support_styles - Style Systems
- support_syn - Syndication (RSS)
- support_upi - Userpics
- support_web - Web Interface
Some of these communities are intended for supporthelps only, and do not have public entries. Others contain information about the category's training process, specific policies, or suggested reading.
Other Official Related Communities:
- supportlounge is the equivalent of our off-duty cafeteria.
- lj_supportadmin is the administrative community. Only category admins and LiveJournal staff have membership there.
- support_interim is the community for those holding interim privs. When you earn interim privs, you should request membership; until then it is not worth watching.
- howto_userdoc is for the discussion of tutorials for inclusion in howto and s2howto. While it does not directly affect work on 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. Many volunteers watch this community so that they may be aware of -- and celebrate -- priv changes.
- lj_docadmin is the administrative community for Documentation. Membership is limited to staff, administrators, and SupportHelps.
- lj_releases is used by LiveJournal staff to announce releases: new features, updated features, and bug fixes.
This is not an exhaustive list; more official communities are listed in the FAQ. Feel free to explore these communities and watch the ones that are most interesting to you.
What does each Support category handle?
The following are the public Support categories: Communities, Documentation, General/Unknown, Entries, Issue Investigation, Mobile Features, Scrapbook, Style Systems, Syndication, The Independent, Userpics, and Web Interface. The private Support categories are: Abuse/AbuseLJ/AbuseRU, Account Payments, Feedback, SUP Services, Schools Directory, support@, and Webmaster.
Staff-only categories are: Issue Investigation, The Independent, Account Payments, Feedback, SUP Services, and Webmaster. While the first two are publicly viewable as the information in them may help investigations in other categories, only staff members may answer these requests.
The public categories are best understood by looking through relevant communities and Support community memories. The communities for each category are listed in the above section, and an explanation of who should read the community and how it should be used can be found in the userinfo of each community.
If a request is opened in the wrong category and belongs in a private category, contact someone with the privs to move it. However, keep in mind that people with moving privileges are around 24 hours a day, so most requests that belong in a private category are moved within a few minutes.
- Abuse - 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, reports of journal break-ins, asking questions about suspended accounts, asking legal questions, or asking about the Terms of Service should be moved to the Abuse category. Abuse also handles reports that a user may be attempting suicide. For more information about the Abuse Team, see the userinfo of lj_abuse.
- Account Payments - 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.
- Feedback - is used to allow people to provide feedback to LiveJournal staff.
- SUP Services - is used as an extension of Russian Support, handling Russian language requests that need to be moved private or need a staff answer.
- Schools Directory - manages the directory of schools that a user can choose on their userinfo.
- Support@ - handles requests about Support itself. Emails sent to support@livejournal.com become support requests in the support@ category. You can use support@ to ask questions about Support that you don't know where to ask. Review requests for most categories are submitted to Support@. Support@ also handles requests that would be on the general board, except they contain personal information that must be kept private.
- Webmaster - requests about business issues, security holes, running bots, or any technical support request that requires an answer from a staff member.
- xx-spam - categories that are contacted by email receive a great deal of spam, which is sent to xx-spam to be closed.
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 requesters, 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. If you are in IRC and see a request that needs to be moved, call attention to these requests via private message only.
What's a review? Why should I get one?
Reviews are our main training tool in Support. An experienced volunteer will look over your recent answers in a category and then send you comments regarding each of those answers. This process gives you feedback more personalized to your needs and skills, 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, and the process for reviewing may be different depending on the category. The learn_support community contains more in-depth information about reviews; see its profile page for the most relevant link.
Can I get a mentor?
There is no formal mentoring program at this time, but if you'd like to pair up with a mentor, email support@. Category admins may be able to match you with someone, if you don't have anyone in mind.
Having a mentor will give you someone to go to with questions. Your mentor will also likely be your main reviewer. You do not need a mentor to improve at Support, but some volunteers feel more comfortable having someone specific they know that they can go to for advice and answers.
For informal, single-request mentoring, this is sometimes available in the #learn_support IRC channel.
When should I report another volunteer? How do I do so?
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 or who are behaving with deliberate malice.
Particularly good volunteers and Support requests handled particularly well should also be reported to admins, because admins enjoy sending notes of praise. These reports can also be sent to support@. AWE, Answered With Elegance, is another way to celebrate volunteer work on difficult or unique requests. AWE is posted irregularly, but the more links that are reported, the more often it can be posted. If you see work on a request that's suitable for an AWE nod, please see the userinfo of supportlounge for information about who to email with the link.
Concerns about a category admin should be emailed directly to the Technical Support Manager, as category admins are able to read anything emailed to support@. The Technical Support Manager at this time is ![[profile for coffeechica]](/images/userinfo.gif)
coffeechica![[wiki page for coffeechica]](/images/swiki.gif)
and her supervisor is currently tupshin.
What should I do if I'm feeling stuck or burned out?
Feeling stuck or burned out often means that something needs to change. Talk to a category admin or a supporthelp that you trust. It may be that you need a break, or at least a fresh perspective on your work.
Some volunteers find that a change of pace helps them to get through difficult periods. If you're a specialist, try answering in a few different categories. If you're trying to get privs in all the categories, you may be attempting too much and focusing on one or two may help you feel like you're making more progress. Also, there are a variety of other volunteer opportunities on LiveJournal, and experimenting with the other opportunities that are available can provide you with the change of pace that you need to make your volunteering experience more interesting. You may even enjoy spending some time at another volunteer-driven organization.
Privs
What are privs? What kinds of Support privs are available?
There are many privileges or "privs" associated with Support. A priv is what gives someone permission to take a particular action on a request. Most privs are publicly viewable at [1].
Support volunteers will also refer to someone with the priv as a priv. So, the people with any of the interim Support privileges are collectively referred to as the interim privs.
Most Support privileges are given on a per-category basis. Each priv has an "argument" after the priv itself, to designate in which category the priv is earned, e.g. "supportviewscreened:styles" grants the ability to view screened answers in the Styles category. Some people have privileges in all categories. These are called global privs, or unarged privs, because they have no argument after the priv. Staff members often will have an asterisk as an argument, meaning that they hold this priv in all categories, public and private.
There are nine support-related privs:
- supportviewscreened - the ability to see other screened responses 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 and insert a request into or remove a request from the queue
- supportchangesummary - the ability to change a request's summary
- supportviewstocks - the ability to access a category's stock answer files
- supporthelp - a combination of the six above privs, plus the ability to approve answers or comments
- supportclose - the ability to close an open request, with or without credit
- supportread - the ability to read requests that are in private categories
There are also admin privs that allow category admins to grant privs to others. Interim privs will be explained more fully in the following sections.
How do I get privs? What privs are given to each interim level?
Privs are granted at the discretion of category admins, and will be given to volunteers as they gain experience handling requests in a particular category. Most support categories require that you submit one or more reviews before you will be granted any privs. However, you should not expect privs to be given after every review. Your objectives should always be focused on learning how to improve your answers rather than on gaining specific privileges.
Interim level one (I1) consists of having supportviewscreened and supportmakeinternal. Interim level two (I2) consists of having those two plus supportviewinternal and supportmovetouch. A few categories offer supportviewinternal privs to those who reach I1. Interim level three (I3), previously called "priv-playing", consists of supportchangesummary and supportviewstocks.
Supporthelp includes all of the above plus the ability to approve screened responses as either answers or comments. It also allows the volunteer to submit an answer or comment directly, without the extra step of approving.
Supportclose allows a volunteer to close requests and assign points. This priv is generally reserved for Support administrators, but is occasionally granted to supporthelps.
What do I need to know as a new I1?
Using your new privs
I1 conveys two privileges, supportviewscreened and supportmakeinternal. A few categories offer supportviewinternal privs to those who reach I1. I1 makes Support a bit easier by allowing a volunteer to focus on requests that have not yet been adequately answered.
I1s are expected to keep screened responses confidential. They should not be discussing these screened responses in public or with anyone who is unable to view them. If they have questions about them, they can either email the category admin(s) for the category or bring them up in reviews, or with their mentor if applicable.
I1s are expected to use internal comments wisely. Non-supporthelps should not be commenting about shortcomings in other screened responses, what should be approved, or what needs to be in an approved answer. Only post ICs 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 related requests by the same user, or linking to tickets that relate 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. Do not leave an internal comment declaring that a request should be moved.
Internal comments are expected to be professional. 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. Privs are allowed to leave short off-topic comments in cases where an IC is automatically created, such as while moving or approving, but the content still must not be offensive.
Common issues at I1
I1s spend most of their time practicing writing according to support style.
I1s are expected to understand that not all screened responses are good models. If a screened response isn't approved, there may be a good reason for that. Some volunteers will find that other screened responses offer them a better perspective on how ambiguous requests may be interpreted or what information might be useful to include.
When you earn your first I1 priv, you should request to join support_interim. This community is a good place to ask questions specific to using interim privs. There is also more information in its memories about using your new privs.
And now that you can see screened answers, you might be tempted to provide feedback to others in the learn_support community, or email individual volunteers to correct them or ask them to change their answers. However, those are the sort of tasks that should be saved for people with supporthelp priv. Do not provide any feedback for other screened volunteers. While your answers are good, and you're clearly dedicated to the prospect of doing support and improving your answers, it's really easy for incorrect information to circulate through learn_support. Almost all the supporthelps watch learn_support, so someone will certainly be along within 24 hours to give a clear and correct answer. You are certainly welcome to post comments welcoming, supporting and encouraging those who are newer than yourself. Just hold back your specific advice about approval policies for now.
What do I need to know as a new I2?
Using your new privs
I2 conveys two new privileges, supportmovetouch and supportviewinternal (if the category did not already offer this as part of the I1 package).
If a request is in the wrong category, change the category first before doing anything else with the request. To change the category of a request, select "Internal Comment/Action" and the new category from the drop down. If the change is not obvious, add a brief note about why you are moving it, and then submit.
Before moving any requests, please review the What Goes Where entry. If you're unsure of where a request goes, don't move it unless it contains sensitive information. Wait for it to be moved by someone who is sure where it should go. Mishandled requests can result in unnecessary delays for the user, so we would rather have you ask than mismove in all cases that don't involve sensitive information. If you feel it is an urgent issue and needs to be moved off the public board, move it to support@ and an admin will redirect it if necessary.
You now have the ability to remove requests from the queue (degreen them). This is most often used when a user comments back with a 'Thanks!' to an answer they received, or in the case of duplicate requests. This type of comment needs no further action from us and should be degreened. However, use caution when degreening a request. Even if the user does not specifically ask another question, some types of user response may still need a follow-up answer. If a request is removed from the queue and still requires input, it could be days before an admin sees it again. If you are at all unsure about a degreen, leave it as is for another priv to deal with.
Common issues at I2
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 unprivved or I1. This will 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 caution.
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 still completing their own training and should focus their energy on that. If you don't think supporthelps have done an adequate job explaining something, or you see information that you feel is incorrect, email support@ and one of the admins will set things right.
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.
Now that you're an I2, we'd like you to submit the more indepth review request format, as we find this can speed a person's progress through the I2 stage.
What do I need to know as a new I3?
Using your new privs
I3 conveys two new privileges: supportchangesummary and supportviewstocks.
You can change the summary to include summary tags for how the request should be handled, such as indicating the user's preferred language or that a request needs admin attention. If a request's summary is not descriptive of the user's situation, you can change the summary to better describe the problem they are having. Try to use their own words whenever possible, and do not jump to conclusions. An incorrectly-changed summary might confuse privless volunteers or I1s who cannot see the original summary.
To change the summary, select "Internal Comment" and click the checkbox next to the summary. Enter the new summary in the text box. If you are adding more than just a processing tag, please add a slash (/) to indicate to volunteers unable to see ICs that the summary's text was changed.
You now have the ability to view stock answers for this category, but please be careful. All stocks must be tailored to the content of the request, to ensure that each user receives an answer that is most appropriate to their situation. Do not fall into the trap of scanning for keywords in a request and pasting a stock without a more careful reading of either the request or the answer. Stock answers marked with an asterisk (*) are absolutely not approvable without tailoring, so pay extra attention to these.
Priv-playing
The last stage of supporthelp training is priv-playing, though this may be skipped or altered depending on the category or the volunteer. If a category admin has awarded you I3 status, you may begin priv-playing at any time.
Priv-players are invited to leave ICs describing the action they would take if they were a supporthelp. Admins request that each priv-play IC be marked as such, and include the following information:
- What information the request needs
- What information, if anything, would make the answer better
- Whether the priv-player would approve any of the existing screeneds on the answer
- What other supporthelp actions the priv-player would take, if anything
What should I do if I want to leave Support?
Should you wish to stop volunteering, you can do so at any time. If you have privs, you should email support@ to alert admins to your absence, informing them if you intend to return. This is a courtesy to support admins, who wish to know who in their category should be considered as available and active. If you would like your privs to be removed, mention this as well.
If you go inactive for more than a month or two, you may find that your privs have been removed for you. This is not personal; it is simply because privs are given to people so that they can perform certain tasks. If you stop doing the tasks, you stop needing the privs. Each category has a different definition of who is active. Please consult your category admin(s) for more information about the category's inactivity policies.
What should I do if I want to return to Support after an absence?
If you wish to re-join Support after a long absence, you should again contact support@livejournal.com so that you can catch up as quickly and easily as possible. Please also read the applicable "Changes of Support" entries recorded in lj_support, as these are specifically designed to assist returning volunteers.
It is difficult to return to Support after an absence, and many volunteers get frustrated at having to be a screenie again, particularly if the volunteer once held supporthelp. Don't be discouraged. In most cases, interim privs can be awarded to returning supporthelps on the merit of past work in the category, so please do not hesitate to contact an admin for assistance if you're feeling frustrated.
Supporthelps
What do I need to know as a new supporthelp?
There are many aspects to being a supporthelp priv. The must fundamental task of a supporthelp is to answer and approve things on the board, but most supporthelps do much more than that.
Supporthelps 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 response rather than writing their own if an acceptable one is already present. Supporthelps still have the options they had as a screened user and interim. You can still leave screened answers for others to approve. You may still ask questions in learn_support.
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; please review these. The category might have more information for you in the memories of its official community.
Many supporthelps will do more than just work on the board. Supporthelps are welcome to become involved with reviews, mentoring, answering questions in the Support communities, spotting volunteers in need of reviews, bringing up issues for discussion, and reporting volunteers when necessary. To get involved in these activities, discuss it with the relevant category admins, who will direct you to the information you will need.
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. However, we do not expect supporthelp privs to be perfect. It's perfectly fine if some mistakes happen. You may be informed of such mistakes by e-mail, 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, and in most cases are harmless in the grand scheme of things.
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 can manage a request through its entire life-cycle. By following up on requests, you learn what information is most important to include, both for answers and internal comments. Supporthelps are not done learning simply because they've completed training. Some categories encourage post-SH reviews; contact your category admin(s) to see if you are eligible for one.
How do I approve an answer?
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 earlier in this Guide.
Do not approve incoherent or poorly 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 an average person would be able to figure out their problem given the content of the answer and the included links, this answer is approvable.
If an answer is close to approvable but not quite so, and the request is not urgent, it is encouraged for supporthelps to email the volunteer to improve the answer. It is never required to do so, but doing so helps the request get answered and the volunteer improve. It also increases volunteer morale, particularly if this is a request on which the volunteer has put forth considerable effort. If you do this, please IC on the request with a time limit under 24 hours that the volunteer has in order to resubmit their answer, before another volunteer may be approved instead.
Supporthelps are expected to approve the first approvable answer. However, if a user re-submits an answer with small improvements on their earlier approvable answer, many supporthelps choose to approve the re-submit as if it were the first answer on the request. This can mean that screened answers left in-between the re-submits may be passed over, but as the volunteer had the first approvable answer on the request, they would have been approved anyway.
It is good, but not required to leave explanations of why you approved what you did if it is not obvious. These notes are helpful both to I2s, so they can learn what the standards are, and to other supporthelps, so they can answer learn_support and review questions more accurately.
When should I leave comments instead of answers?
Comments are used to ask questions or give additional information. However, if a request is ambiguous, it does not necessarily need a comment. Whenever it will be faster and simpler, an answer should simply address all possible interpretations. A supporthelp should comment requesting additional information only in those cases where the request does not contain sufficient information to resolve it.
Comments can also be used to correct mistakes. If the approved answer neglects to mention something important, a comment can add that information. Some supporthelps prefer to comment rather than answer if the user has already solved their problem, but this is up to the individual supporthelp.
What do I need to know about changing summaries?
Be sparing with changing summaries. When changing a summary, preface the change with a "/", to alert those who do not have supportviewinternal that the summary has been changed.
If a request has unusual circumstances but an unremarkable summary, changing the summary to something more descriptive can help make that request easier to find later, when researching requests of that type. Summaries may also be changed to add bracketed summary tags to denote language or the need for admin attention.
Admins
What does a category admin do?
A category admin participates in the following activities:
- Making sure the requests in the category are answered promptly and correctly
- Monitoring the training of volunteers in the category, providing encouragement and correction
- Participating in policy discussion in lj_supportadmin as well as in any other applicable communities
- Managing privs in the category
- Monitoring the documentation applicable to the category and proposing updates when necessary
This list is not exhaustive, and not all admins will do each of these tasks. Most categories have multiple admins who cooperate to keep the category running smoothly.
How are category admins selected?
Category admins are appointed when an existing admin decides to step down, but also in the case where site growth or personal life changes make it difficult for the existing admins to keep up with the category's needs.
Each category admin is selected according to different criteria, depending on the needs of the category administration at that time. A supporthelp's unique talents will be taken into consideration, especially when balanced with the talents of the existing category admins. Sometimes admins will advertise in the category's community when there is an open position; other times the selection will take place without notice or consent of the existing supporthelps in the category.
While the duties of category admins may differ according to the open position, all admin candidates should have a history of being mature, available, friendly, and cooperative.
Oddities
Why did that request vanish?
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, particularly in the case of Abuse 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. Similarly, requests can appear on the public board already several hours or even days old if they were moved in from a private category.
Why are there two approved answers/comments on this request?
Some requests will have two answers about the same thing or two comments doing the same thing. This can be caused in two different ways. 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 result is often called a "collision". To reduce the chance of collisions, supporthelp privs are encouraged to always post screened first and then approve.
Why does this user seem to be talking to himself?
Sometimes you'll see comments from the user who opened a request that look like half of a conversation. They may say something like "No, that's not the problem," or add additional information without the request having any approved responses from Support. Typically, these are requests opened by someone with support privs. They are replying to screened responses or internal comments that they can see.
What do the red and green numbers on the high scores page mean?
These numbers indicate a change in rank. This information is updated every Sunday.
Social Aspects
Does Support have an off-duty community?
supportlounge is our off-duty community and is maintained by volunteers. Supportlounge is the place to celebrate milestones, share user thank-yous, and almost anything else related to the social side of volunteer tech support. Special events, such as holiday celebrations or in-person meetups, are often planned there. As with all communities, please read the community guidelines carefully before posting.
What about an IRC channel?
Many Support volunteers gather in #lj_support, an Internet Relay Chat (IRC) channel. (Instructions for connecting to IRC are included on the community profile page for supportlounge.) This channel resides on an official network maintained by LiveJournal's operations staff, and the channel itself is moderated by supportadmins. It is an excellent way to contact other volunteers if you spot a request that needs to be moved, or if you want to help coordinate efforts to manage requests during site difficulties. #lj_support can also be an off-duty channel as much as it is a place for official activity, so the conversation is more akin to a workplace's cafeteria than a formal meeting place.
The #lj_support channel has a number of other side channels, and any special events happening in other rooms will be mentioned in #lj_support's topic.
There are a number of quick reference items in IRC tools.
Reference
What are some links that I can bookmark?
There are many links that you may find helpful, both for your own reference and to refer to in Support requests. However, before referencing any link in an answer, you should always check that the link currently works and contains the expected information. Some of these links aren't official and those links shouldn't be used in answers, but they are included because volunteers find them helpful.
- American Registry for Internet Numbers search: http://www.arin.net/whois/index.html
- Birthdays: http://www.livejournal.com/birthdays.bml
- Buy for Friends: http://www.livejournal.com/paidaccounts/friends.bml
- Change Support Notifications: http://www.livejournal.com/support/changenotify.bml
- Cluster Checker: http://www.livejournal.com/misc/whereami.bml
- Color Code Guide: http://www.livejournal.com/community/howto/28475.html
- Color Usage Guide: http://www.livejournal.com/users/howto/26423.html
- Console: http://www.livejournalcom/admin/console/
- Console Reference: http://www.livejournal.com/admin/console/reference.bml
- Jira Bug Tracking: http://jira.sup.com
- LiveJournal Code Repository: http://code.livejournal.org/trac/livejournal & http://code.livejournal.org/trac/ljcom
- News Link for Friending: http://www.livejournal.com/friends/add.bml?user=news
- News Page: http://www.livejournal.com/news.bml
- Popular With Friends: http://www.livejournal.com/friends/popwithfriends.bml
- Portal: http://www.livejournal.com/portal/
- Priv Lookup: http://www.livejournal.com/admin/priv/
- Statistics: http://www.livejournal.com/stats.bml
- Status: http://status.livejournal.org/
- Style Browser (S1): http://www.livejournalcom/styles/browse/
- Suggestions: http://www.livejournal.com/suggestions/
- Terms of Service: http://www.livejournal.com/legal/tos.bml
- Variable List: http://www.livejournal.com/developer/varlist.bml
Do you have a glossary to the commonly-used Support jargon?
Yes we do! It's at Category:Support Jargon.
