azurelunatic | A Style Guide? Not yet!

[19:09] zvi: rahaeli: are you going to have any open to casual driters through support, or is it all going to be cult^h^h^h^h trained support members?
[19:10] zvi: s/driters/drifters
[19:10] rahaeli: yeah, pretty sure we'll do anyone-can-answer
[19:10] rahaeli: well
[19:10] rahaeli: anyone can submi a possible answer
[19:10] rahaeli: that will have to be reviewed/approved by someone experienced ,etc
[19:10] * zvi nods
[19:10] rahaeli: and there'll be a support guide with the support answering guidelines and blah blah
[19:11] rahaeli: if i close my eyes and wish really hard, maybe somone will deliver a fullyfunctional support system staffed by knowledgeable, experienced, professional, and eager people
[19:11] ivorygates: adgeek: it will require Research thank god for wikipedia. and rah: i resemble that remark.
[19:11] Azz: I got my first support point already! I used Mark's public answer as a support style guide, despite being used to LJ's support style. :D
[19:11] rahaeli: IG: if you do not use the words "ich bin ein jellydonut", i will be very sad.
[19:12] ivorygates: *cackle*
[19:12] ysobel: I got a spr0t point too! I um. used LJ support style >_>
[19:12] ivorygates: du mir bis du dunkin donuts
[19:12] rahaeli: yeah. our support style guide will kinda be "okay. you know D's emails? you know that tone? that's what you want."
[19:12] *** You are now known as Azz|movienight.
[19:12] rahaeli: only that means i have to put it into *words*
[19:12] UrsaMajor: rah: you mean we get to overwhelm people with WALL O' TEXT? ;)
[19:12] Azz|movienight: ...let me see if I can get back to you on that by tomorrow sometime.
[19:12] zvi: oh, asking you to put something in words is a terrible imposition ...
[19:12] ivorygates: (hey, the longer entry length? i can totally DVD "captains" in ONE ENTRY!)
[19:12] rahaeli: oh fuck you ursie ;)
[19:13] rahaeli: ig: ooooo
[19:13] * ysobel giggles
[19:13] UrsaMajor: :D
[19:13] * Azz|movienight is sometimes Very Good at Summing Up Shit
[19:13] rahaeli: but yeah, i know that there's a whole lot of Stuff brewing around in the back of my head about support
[19:13] rahaeli: i just hope it coughs up a synthesis by open beta :P
[19:13] Azz|movienight: 1) do not sound like a robot.
[19:14] Azz|movienight: 2) by that, I mean if you talk in corporate-speak, I will shiv you with a plastic knife
[19:14] ysobel: *snerk*
[19:14] rahaeli: "breezy and light, but professional-sounding"
[19:14] zvi: But 3) don't threaten the users w/ violence
[19:14] rahaeli: ....well damn
[19:14] rahaeli: there goes all my plans
[19:14] Azz|movienight: 3) casual tone is OK, but do not insult the user
[19:14] rahaeli: dammit zvi you never let me have any funnnnnn
[19:14] * rahaeli whine
[19:14] ysobel: she didn't say don't *be* violent, just don't *threaten*
[19:15] zvi: ysobel has hit upon an important distinction :)
[19:15] * MissKat is going to head to bed. Muscle relaxants are <3
[19:15] rahaeli: oh well that's all right then
[19:15] * ysobel out of idle curiosity does a word count on current entry
[19:15] Azz|movienight: 4) if the user calls a thing by some non-standard name, try to work with the user's terms, and try to define to them what it's likely to be called in the FAQs they'll be reading.
[19:15] *** MissKat is now known as MissKat|bedddddd.
[19:15] rahaeli: but doing so in a way that doesn't make the user think you're correcting them EVEN WHEN YOU TOTALLY ARE
[19:16] Azz|movienight: 5) wall-of-text sometimes has to happen, but if you must do that, then break it apart somewhere else
[19:16] Azz|movienight: 6) sometimes you just have to use those $640 words. Be kind. Include a dictionary.
[19:17] Azz|movienight: 7) Assume they have a brain until proven otherwise.
[19:17] ysobel: ...over 1600 words so far and i am just getting to the main issue. man, i totally should not have recruited jdn to write this for me
[19:17] * rahaeli snickers
[19:17] rahaeli: i believe i tried to warn you
[19:17] rahaeli: or maybe i just thought about warning you
[19:17] zvi: 7 seems like a recipe for frustration
[19:17] Azz|movienight: 8) Assume that they don't know the things that you know until proven otherwise.
[19:17] rahaeli: zvi: yeah, but lj support is the converse most of the time and it makes people :(
[19:17] ysobel: you totally went "HERE HAVE FUN"
[19:17] rahaeli: and occasionally D:
[19:18] Azz|movienight: 9) People, in the aggregate, suck beyond all imagining. Do not be surprised when they do.
[19:18] rahaeli: isa: damn. well, know that i am sympathetic to your plight
[19:18] Azz|movienight: 10) Individuals rock beyond all imagining. Be delighted when they do.
[19:19] Azz|movienight: 11) They will try to do things with the system that the system was never intended to do. However, intended by whom? Sometimes the will of the userbase reigns. Sometimes the will of the people steering this tugboat does. Hang on tight.
[19:19] niq: re: 7
[19:19] niq: you can, actually, assume people don't have a brain and yet not condescend to them
[19:19] niq: assume merely that they have temporarily mislaid their brain to sleep deprivation or what have you -- it's not inherent, it's not a character flaw.
[19:20] hilarytamar: Hey, quick poll: an LJ friend's computer has died & she'll be offline for about 10 days. She has in the past said she likes getting letters. Dropping her a letter every few days = spiffy or = stalkery?
[19:20] zvi: spiffy
[19:20] rahaeli: spiffy
[19:20] rahaeli: esp. since i know who you're talking about
[19:20] rahaeli: and she could use the <3
[19:20] amaliedageek: real dead tree mail is spiffy
[19:21] hilarytamar: *nodnod* Cool. Thanks.
[19:21] Azz|movienight: 12) when possible, look for the underlying principle behind something that on its face seems unreasonable. Sometimes it is in fact unreasonable; sometimes it means that someone has identified a problem, doesn't know how to articulate it, and is giving the best solution they know how to think up.
[19:21] hilarytamar: And I might even have a couple spiffy cards -- the kind you pick up because they're spiffy but you have no reason to mail out when you get them, so you hoard them. That's not just me, right?
[19:21] Azz|movienight: ht: not just you
[19:21] Azz|movienight: ... and I am 10 minutes late for movie night now. :D
[19:21] * Azz|movienight zips
[19:21] amaliedageek: nope, I do it too
[19:22] amaliedageek: azz: go, already!
[19:22] hilarytamar: Azz|movienight: are these principles of support or of life? Seems to work either way.
[19:22] Azz|movienight: a bit of both. some I learned from D; some I learned from LJ Suggestions. <3
[19:22] ivorygates: HT: spiffwallah
[19:23] rahaeli: "assume good faith. also assume the person at the other end of the screen is a malevolent fuckwit. behave as though the former is true, while making plans for the latter to be true."
[19:23] Azz|movienight: heeeeeeee
[19:23] JD: haha

Contractions aren't the devil.
Listen to anecdotes about how things are and are not working, but you ignore the hard statistics about these things at your dire peril.
Don't be afraid to anthropomorphize the parts of the system and their interrelation if that will get the point across.
Sometimes the balance between technical accuracy and understandability is delicate. Call for help at this point.
If you don't know something off the top of your head, throw down what you do know; someone else may have the missing piece that you don't.
Common-sense check your shit.
Even if something is common-sense to you, it doesn't always mean that it is to someone else. If there's a simple explanation for something that could have happened wrong, confirm explicitly that it didn't before going on to the fancy stuff.
It's OK to share stuff that's not a finished product under many circumstances. People appreciate hearing how things are going even if it's not done.
It's fine if you're going to use technical terms. Make sure to define them in plain language first.
Give the basic answer first, then give the tl;dr version.
Don't give false hope.
Don't let idealism blind you to cold hard reality.
Don't let cold hard reality discourage you from imagining how things would be in an ideal world.
Be generous with acknowledgement to the people who are helping.
This is the internet. It runs on internet time.
You are a human, not a robot. So is the person at the other end of the conversation.
Yes, people will ask the same questions over and over again. This is why FAQ stands for Frequently Asked Questions.
If you make it too hard to do, people will not do it. Yes, people will avoid doing things that they think are too hard even when it is actually really easy.
We want to find ways to make things easy and painless for people, even if we personally happen to think that they're plenty easy and painless to start with.
We want to deliver not just good service, but really great service.
If there's a problem, we want to be aware of it, even if it's not something we can do anything about.
If you see a situation that could use help, offer to help. (Don't force it on someone, as your idea of "help" may actually come across as nothing of the kind to them.)
Give examples.
Light wittiness, if you can swing it, is encouraged. (If you can't, don't stress over it.)
Show emotion, but don't let them see you pissed off or wounded if you can help it.
Emphasizing words, exclaiming, and asking questions are all OK, but in moderation.
Since some people can't tell the difference between a joke and a serious statement, don't make jokes that would be damaging if taken seriously, and telegraph it when you make some particularly outrageous joke. (Note: Support in general probably should not be outrageous except with friends.)
Someone, somewhere, will want to know all the numbers and all the technical details. Give it to them.
Specify what units of measurement you are using when you are giving numbers.
Your minion with graphs is always in order.
If things are not how you would like them to be, it is OK to say that up front.
If someone has a point, concede it. Your ego is not the point here.
Do your level best to avoid creating a privelege gap. This leads to people being and feeling disempowered, and all sorts of bad stuff.
Don't get grabby for the sake of having power/money/elephants. Do something useful with what you have.
Don't take away people's ability to vote with their pocketbook. Don't try to make it difficult/disadvantageous to leave; make it advantageous to stay. And not in the "because we won't X" sense.
Go into any situation knowing about how much room for negotiation you have. Avoid being backed into a situation where you have made a firm statement and your ass is showing.
If you do take a firm stand, it had damn well better be one that holds up under the Terms of Service.
Lower the wall. (Unpack for those who don't worship Miles Vorkosigan.)
If you know where the buttons are, avoid pushing them.
If you cannot deal with someone you dislike in a sufficiently gracious style as to avoid letting them know by any means, from overtly telling them to barely-conscious word choice, then you should let someone else deal with them.
If someone does not like something that is necessary, acknowledge the validity of their not liking it and let them know in as courteous a manner as possible why it is necessary. They do not have to like it, but they deserve to know why the decision was made.
If there is a reason something unpopular was done and it is not a reason that the public gets to know, explain as much as you can and advise that the rest is not for public consumption. (Check with someone before explaining, in case you've stepped over that line.)
Don't violate the trust of the userbase. It's hard to earn back.
Respond to both the question the person is literally asking, and the one that they don't know that they need to ask. Answer the question they've actually asked first.
Acknowledge your limitations and work to transcend them. Use tools.
We'd rather hear about an issue for the 50th time than not hear about it at all. (Remember this the 50th time we hear about it, and treat the person asking the question as the latest in a succession of Great Minds Thinking Alike, and show them where the other Great Minds have collected the Known Issues.)
Explain why.
Elegance/prettiness matters. Working also matters.
Your petty annoyance may be someone else's serious accessibility issue or expression of deep-seated disempowerment. Check yourself before you bare your ass.
If you'd like to see something done, say so. No one is going to read your mind. If you put it out there, someone may take it up, even if you've been meaning to do it and just haven't gotten around to it yet.
If someone else puts something out there and you have a spare minute, why not try your hand at doing it?
Avoid creating a shambling horror of the deep. Explaining what you are doing and why you are doing it helps avoid that, because, all indications to the contrary, we cannot actually read your mind, and neither can you two years later unless you leave enough notes. This applies to code, to documentation, and to decisions you came to after two weeks of debate that no one logged anywhere.
Chili sauce does not belong in anyone's eye.
Avoid Mart Bug Death. By which I mean, if there's a quick way to get something done, and a slow one but the slow way is going to be so elegant it makes strong men weep, try the quick way so at least it will get done, and then strong men won't punt you across the room.
Provide outlets for frustrations.
Always look for a better way, or at least be open to the idea that there might be a better way. Yes, even if you made the current way and you think it's practically perfect.
Be aware of scope creep and feature creep, and define what needs to be done at a minimum and stick to it.
Yes, offer it in another color.
Insist on a documentation trail as a matter of policy. If there's something that someone wants to try undocumented, tell them up front why documentation is a good idea, and don't let them pressure you into something that can land you in hot water. A vague disclaimer is no one's friend.
Be as generous as you can afford to be.
Be as precise as you can.
Keep on topic. Digressions happen, but you can make them happen over *there*.
(Don't kill the spirit of people by shooting them for a little digression.)
Keep the signal to noise ratio firmly in mind.
Professionalism. Learn it. Love it.
The person in charge of a project should be someone who is enthusiastic enough about it to put time and effort into it.
Pay your volunteers in acknowledgement and love. This does not make you a teacher; this makes you a manager. (Fuck you, Joe.)
Not everybody learns best in the way that you teach best. This doesn't mean there's anything wrong with either of you. Some people want words. Some people don't get it until they've done it themselves. Other people need plenty of pictures.
Don't badmouth people in public.
Separate content and format wherever you can.
There's something to be said for using a modern tool that was not coded in a dorm room in 1997. There's also something to be said for not jumping between tools every three months.
Connect with people, in person when possible.
Don't feel you have to strip yourself of your cultural, subcultural, or personal attributes. Volunteer culture is very curious and people will probably ask a lot of questions. Feel free to answer or turn away questions as you feel comfortable doing.
People who make and do stuff are nifty. The creative process is fascinating in all its forms.
Sometimes something technically nifty must be nixed for business reasons.
Try to not break shit that people are using.
There is significant value in using conventions that people have spontaneously generated.
People are going to care how things look, even if you personally don't. It's not an inherently silly thing to care about.
People can and will learn things. Education is a good thing.
You never want to have to deal with someone who used to love something and has learned to hate it. Don't contribute to making passionate people hate you and the site.
You may be someone's first and only experience with Support. Make that experience a positive one.
Even though you are not necessarily an Official Representative, your words may be taken as such. Take care.
People learn better when they have to learn to do something they want to do, rather than studying something for no discernable benefit.
Why waste time? If someone has already written something down better somewhere, you can point people to it for the definitive word, as already laid out. It's easier for you, because you don't have to re-invent the wheel. It's sometimes easier for them, too, since it should be in an easy to find, easy to bookmark place, and has been honed into a thing of awesomeness already.
If you're going to have an obsess-over-details conversation, have it in a "pull" environment instead of a "push" environment: where someone who does not want to be bombarded with every last "me too" or "no way" can skip it. An email list is "push", and so is the main IRC channel. The comments section of a post is generally "pull", and so is a wiki page. (A side IRC channel where everyone who is there is someone who wants to be there is a special case. So is the comments of a post belonging to someone who doesn't want or need to hear all the details, since they may not have turned off their comment notifs.)
If it's something sensitive, try in private if at all possible.
If you are using stats to make smart decisions, make sure that those stats do not contain stupid data.
If you leave a hole, someone is probably going to try to use it for nefarious purposes. It's better to close it than to have to slap them down.
Figure out what makes your awesome people awesome. See if you can clone them, or if what makes them awesome is teachable.
Style matters.
Readable format matters.
Indexing matters.
Some sort of logical format matters.
Enforcing strictness when dealing with user data is one of many, many ways you can help avoid introducing security holes.
Any limits on what people may or may not do, whether it's instituted for business, practicality, or code reasons, should be documented *somewhere*, even if it's not publicly. The fact that there is a limit should be acknowledged publicly, even if the parameters are not.
Turns out that when you build a project that explicitly teaches/mentors/nurtures new contributors, makes it easy for people to commit no matter what their energy/ability level, and consciously tries to root out exclusivist language/attitudes, you get a really diverse contributor base! who'd'a thunk it.
Not everybody uses the site the way you do; not everybody who uses the site differently uses it the same way. People who use the site differently are not inherently wrong for doing so. (That being said, sometimes the way they're trying to use the site is just not how the site works at all.)
More options are not always better.
If someone tries to turn something into Mart Bug Death, someone may get pissed off and do it quick and workable.
Even the things that are going to be set-once, like the name of the site, still shouldn't be hard-coded, because this is SPARTAAA. Er, open-source. We're not the only ones who will use this code.
If it can be fixed technically, rather than administratively or socially, oh god, please do it that way.
No, the minutes from your meeting don't actually need to be in the code base.
You are standing on the shoulders of giants.
Identify shit that has always bugged you. Maybe it will get fixed.
Poke shit until it breaks, then report what you did to break it.
It really is dangerous when you teach the Suit how to code.

A Style Guide? Not yet!

no subject