Currently, cust more or less "owns" the long-standing part of the formal support guide that essentially says "don't say no." And of course, all of the more general parts of the official guide apply to any cust support work. Steering toward what essentially would emerge as a cust-specific chapter of the official support guide, let's start with discussion along the following lines:
- Adhere to all general support policies. Notably, do not provide any customization support that would contravene the LiveJournal TOS.
- Be respectful to all: to LiveJournal and its developers, to other support volunteers, to new support candidates, to users, and to all other persons, groups, or products. Do not use LiveJournal customization support as the forum for personal views on customization tastes, browser reliability, or any other subjective issue.
- Stay current and informed. A support response may be completely incorrect if it relies on outdated information.
- Avoid unnecessary negatives or restrictions. If you don't like complicated overrides, then simply abstain from response on a question that could be solved via override. Similarly, if a user wishes assistance in customizing a particular methodology, such as a marquee or blinking text, avoid participating in response if you cannot provide your support in a positive, respectful way.
- Know as much as possible about the user asking the question before starting to develop an answer. Is the user currently a paid member? What styles are being used on all views? What overrides are in place? Does the user's browser affect the answer?
- Avoid copying the answer to a separate question. Exceptions to this rule include the very simplest referrals to FAQs or pre-approved boilerplate responses posted in the customization support community or in lj_support.
- Whenever possible, use official LiveJournal references. Include a suitable FAQ link or reference to howto or lj_style whenever suitable. If a reference to a non-official livejournal or non-LJ source would add sufficient additional value to the response, add a disclaimer noting the unofficial nature of the reference.
What, nothing about valid HTML or avoiding <font> or whatnot? And how about recommended practices, like adding in useful HTML/CSS comments and such? Well yeah, some of that might get added in here as this emerges, based on any discussion we see here. But as has been discussed elsewhere recently in a posting from leora, some of it might remain simply recommended practice, versus policy. Input and debate welcome.