Arie (arie) wrote in xxcustomization,


I. Third Party Requests
      User's making requests on behalf of "friends" should be asked politely, via comment, to have their friend open their own request. Simply inform the user that when a request is filed, the system automatically picks up certain information about their journal styles that volunteers need in order to best assist them. That in order to get the best and most complete answer possible, volunteers need to see this information and communicate with the journal owner directly. That their friend will still be able to ask them any questions and they will still be able to help their friend with any overrides given, but that their friend will need to open their own request for us to best help them.

II. Not Logged In Requests
      Because it is very difficult to fully answer the requests of non logged in users, these people should be asked to resubmit there request while logged in. This is also to help prevent inadvertently using our valuable time answering the requests of non-users from other services. Customization is not like some of the other categories, in that well over 99.9% of the requests we deal with are for customization of an existing journal. There is very rarely a legitimate reason for a non-user to submit a request for customization. Once in a very long while there will be a request from a non-user wanting to know if something is possible before purchasing an account. These are rare in the extreme and are easily identifiable as they aren't asking for specific instructions.
      These users should be told, as with third party requests, that to get the best, most complete answer they will need to be logged in when they submit their request. That the system automatically picks up certain information about their journal that volunteers will need to know in order to help them and that many overrides are dependent on existing overrides, so the only way to get a thorough and complete answer is to resubmit their request while logged in. This should be done via comment, just as with third party requests.

III. Multiple & Duplicate Requests
      A. For users taking extreme advantage of the support system (by posting multiple request for single items, posting conflicting requests, abandoning previous requests to open new ones for different customization help, or opening new requests instead of commenting to the relevant request), please make a Friends Only post to customization or e-mail me (arie) so that I can look at the situation and take the appropriate action. The reason for this is because in most cases I need to close several of the open requests and the only way I can completely be sure of whether closing all, or all but one request, is appropriate is by actually seeing all the currently open support request. If they're in support@ I can't tell how best to handle the situation.
      B. For duplicate requests, please move the earlier one (or in the case where one has more information, the one with the least amount of relevant information) off the board to support@ with a comment to the user that the duplicate request is being moved, why it is being moved, and that if they have information to add to please comment to their other request. Please provide a link to the request that is remaining on the support board. Depending on the situation, you may also need to ask them to be patient in waiting for a response.

IV. Changeable Subjects
      A. If the Summary line of the request already pretty well says what the user is asking for, there is no need to change it. This means that even if they are using improper spelling, grammar, punctuation, excessive smilies or annoying typing and phrasing, there is no need to change the request summary unless it also doesn't actually state what the user wants.
      Changing a summary line should only be used when absolutely necessary because altering the summary line will make it more difficult for the request owner to come back to the request if they have misplaced their confirmation e-mail. It is important that we balance our need to change a subject line to something more descriptive with the user's need to be able to locate their request.
      B. Be as descriptive as possible, but remember there's a character limit, so be concise.
      C. If a request involves anything other then information that can be found in FAQs or howto posts, you will need to put a "+" at the beginning of the subject line. This will allow us to separate the more time consuming or more advanced requests from the easier more beginning level requests, so that volunteers can better manage their time.

V. Commenting to the User
      A. When commenting to the user, please first evaluate whether a comment is necessary. If they could be asking for one of two things, there is no need for a comment to ask which. An answer should include both. An example of this would be "changing the title of my journal." If the user is not specific about whether they mean the navigation table title or the browser title, instructions for both should be included. If changing the navigation bar title is not possible for their style, this should be noted.
      B. Comments to users should remain on the same professional level as answers. That is, they should contain complete sentences, reasonably good grammar and punctuation, proper spelling, and should not sound uncertain or unsure. As with answers to users, minor errors that do not hinder understandability are acceptable. If you are unsure of something due to the current or past journal state conflicting with the request and are asking for information to clarify it, you can state "It appears that {description}. Do you still require help with this? If so please comment back to this request to let volunteers know."
      C. Do not comment to a user asking them to close the request. Instead, remind them that in order to make the changes or correct the error they will need to review the previous response to their request. After a brief period of time (generally 72 hours) I will then be able to close the request even if it has not been applied. This type of comment should only be made after the request has been answered for at least a week.

VI. Testing Overrides - supporthelp privs
      Before approving any answer with code, test the code given. Even if its a very simple, very basic override. A space in the wrong place or a missing closing bracket are easy to overlook and can cause the whole override not to function properly.
      If the answer involves step by step instructions, follow each step yourself, exactly as its written. See if when you get to the end you have achieved the expected results. Don't skip steps or take shortcuts because you know the system, follow them exactly as given; its the only way to be sure they will work for the user who may not have all the knowledge of how the system works that you do.

VII. E-mailing Volunteers About Requests
      A. Only those with supporthelp privs in customization should e-mail volunteers about answers in the customization category.
      B. A customization supporthelp priv is free to e-mail a volunteer regarding improvements to a screened answer. Please do not post to a community or leave a comment in a volunteer's journal to try and get in touch with a specific volunteer regarding improvements to a support answer.
      C. It is important to keep in mind that the same rules about first, best apply. If there is another answer that contains all of the information that the user needs --including any information you would be asking another volunteer to add-- then you should approve that answer, rather then e-mailing the volunteer. If there is no approvable answer to a request then an e-mail is appropriate.

VIII. Approving the First, Best Answer
      A. When approving an answer you should approve the first, best answer. The first, best answer is the first one that contains all necessary information, including next logical steps, all proper links, and has only minor grammatical, punctuation or spelling errors.
      B. If an answer is very difficult to understand due to grammar, punctuation or spelling errors, then this is not the "best" answer. However, please keep in mind that no answer will be "perfect" and that minor errors are acceptable. We want to sound as professional as possible, but we must also balance this with the fact that we are only human. For example a comma splice or run-on sentence, by itself, is not cause for not approving an otherwise acceptable answer.
      C. As long as all information is present in some logical order, then the actual order or level of information given, by itself, is not a reason to approve a later answer.

IX. Approval Notes
      When doing approvals, please leave a note in the approval comment that states what the journal currently looks like. This makes it easier to determine if overrides have been applied or not when checking for closings.

X. Follow Up, Closing Comments & Closing Lists
      A. It is important that you remember to follow up with any older requests you may have commented on, answered, or done approvals for, as users often fail to mark a request as "needs more help," even though they leave a comment that they require further assistance. This will allow you to "touch" the request for the user and it will help prevent extended delays in their receiving a response back.
      B. In the course of doing follow up (via your youreplied filter or by going over a section of the board), if you find that a request is closeable you can mark it as such with an internal comment. This internal comment should include the reason why you believe the request is closeable, such as "applied overrides" or "asked to comment back and has not, request abandoned."
      C. If you have made several closing comments, or gone through a significant portion of the board to find closeable requests, you can make a list of these requests and e-mail them to me. If I don't agree with some of the reasons that you've marked a request as closeable, I'll e-mail you back with why I didn't close a particular request so you'll know for the future.

XI. Review Summaries
      After you have completed a review for a screened volunteer, please post a brief summary of that review to customization as a Friends Only post. This will allow privs to get an idea where the volunteer is currently at and will allow us all to see how the screened volunteer has progressed between reviews. If a screened volunteer doesn't want a summary of their review posted for the other privs to see, they'll indicate it when they request the review. If you have any doubts at all, e-mail the volunteer to double check with them.

XII. Recommending Screened Volunteers for Privs
      A. Only those with supporthelp priv in customization can recommend volunteers for customization privs.
      B. A customization supporthelp priv is free to recommend any screened volunteer or interim priv for any higher level of privs once they feel the volunteer is ready for them.
      C. Please do this in a Friends Only post to customization along with a brief explanation (with examples, if possible) of why you believe this person is ready for the level of privs you are recommending them for.

XIII. Additions to & Corrections in howto
      A. If you have a suggestion for a new post to howto please e-mail me (arie) with the code or a link to a request containing the code and a sentence or two about why you think it would make a good addition to the tutorials.
      B. If you notice an error in a howto tutorial, please e-mail me with a link to the tutorial (or the title of the tutorial) along with what correction needs to be made.

XIV. Correcting Another Priv Once an Answer is Approved
      A. In a word: don't. This is my responsibility and they may have already contacted me regarding their mistake.
      B. If you notice that a priv has mistakenly approved a wrong answer or has unknowingly provided wrong information to a user, please e-mail me with a link to the request and a brief explanation of why you believe the response the user received was incorrect. I will then be able to mention to the priv what the correct answer is for future reference.
      C. You should not leave a comment or approve a second response yourself. Not all privs are able to check back on each of their requests and leaving an IC may not always reach them. The best way to make sure that the oversight is corrected is to e-mail me. This way if it is a simple mistake there are no hurt feelings and if the priv didn't know the answer that was sent to the user was wrong, then I can let them know the correct answer for the future.
      D. This does not preclude debate within internals about whether something can be done or not. If one priv comments via internal that they believe it can or cannot be done and asks for opinions or feedback you are then, of course free to comment yourself. This only covers once an answer has been sent to the user. Do keep in mind, however, that ICs are held to the same professional standards as answers and comments sent to the user.
Comments for this post were disabled by the author