Talk:Development Q&A
Guidelines for adding to the dev Q&A
- Keep it as close to the source as possible.
No interpretation, no spin. It's not our job to build hype, glean what GSG meant to say or read their minds. It's their responsibility to communicate their point. We're just documenting what they said.
The reasoning for this is that almost noone checks the source. Very, very few readers are going to check the summary against the stream snippet. Most people will read the summary, assume it's the truth and run with it. And that's fine; that's largely why this page exists - so that people don't have to watch every dev stream to know how they react to community suggestions.
But that also means we have to convey what was actually said, not what someone else thought was said. Readers expect words from the mouths of GSG. Giving them something else is just bad journalism.
- When the same reply contains answers of different levels of certainty, focus on the more vague one and/or the one that promises less.
This is for when someone says "maybe" and someone else adds "don't get your hopes up" in the same reply. The truth is that people are going to retell these in a game of broken telephone. "They might add X" will morph into "they'll probably add X" and then into "it's likely they'll add X", simply because the speakers want to believe X will get added.
In (frequent) cases of "I think the situation with X is ..., but I'm not sure", a good option is to paraphrase that into "The situation with X might be that..."
The stream team already has to be careful with their wording. They're aware that anything that even remotely sounds like a promise will be taken as a promise. We are their allies, we shouldn't make their jobs harder. If someone comes to the devs saying "but it says here you promised X" and it's because we took the part of the answer that sounded like that, GSG will have to be even more careful and vague going forward - and that's no fun for anyone involved.
- If none of the devs said anything of substance, don't make an entry.
This is for cases when they read out a suggestion, but get distracted by gameplay and don't provide any answer. The same goes for when GSG misinterpret the question and comment on something unrelated to the suggestion.
A reply that's essentially "not sure" borders on having substance. By default, make an entry for it, but use your judgement. Most of the time it's clear from context; when a dev's point is "not sure, I don't have enough knowledge and I don't want to give false information", it's better to omit that reply from the summary.
- Avoid mentioning the dev by name unless they specifically say it's their personal opinion, and it's clear the opinion doesn't reflect the general course of development.
Most of the time it's not important which of them replied, and mentioning it takes valuable table space (more on that below). However, for example, Johan often says he wants the minigun to have more ammo. We know it's an injoke and that the minigun is not going to get more ammo. So, when someone suggests to rebalance the minigun, and Johan off-handedly jokes that it should get more ammo, putting that as a straight impersonal answer will confuse readers. Intonation and context are lost in a short text summary, and that should be kept in mind.
GSG are also aware of this and usually preface their answers with "well I think..." when they're about to say something controversial or going against the general design of the game.
- Avoid editor's notes unless absolutely necessary.
Comments from editors should not be needed, as per the "no interpretation" guideline. I've used them twice in around 2200 answers, and it was for humor that would get lost in transcription. One was sarcasm and one was the joke where the devs keep pestering Mike to add a petting zoo. Taken at face value, the text could be very misleading, and we can't trust readers to go and listen to the context in audio form. We also can't trust them to read the intro on the Q&A page where it says some replies are jokes.
- Keep the "Suggestion" text no more than 57 characters and the "Comment" text no more than 140 characters.
This isn't just for brevity. This is how much text the current font can fit without doing a line break at 13pt on 1920x1080 in wide mode. The table is already enormous, keeping it as trim and short as possible saves a lot of scrolling.
In general, paraphrase the replies until you can get the entry to fit into one line without breaks in the conditions mentioned above.
- Keep replies sorted.
Sorting is as follows:
- By stream date from newest to oldest.
- Within the same date - by category alphabetically.
- Within the same category - by suggestion alphabetically.
Or just send them to me so I can sort in my Excel sheet/converter.
ArsonCat (talk) 21:21, 1 April 2023 (UTC)