GOD manual
No edit summary |
mNo edit summary |
||
| Line 13: | Line 13: | ||
== Style guide == | == Style guide == | ||
If you're migrating content from the old manual to this wiki, unless it's likely to be widely applicable to non-GOD crew, create pages ''under'' this page, with names like [[ | If you're migrating content from the old manual to this wiki, unless it's likely to be widely applicable to non-GOD crew, create pages ''under'' this page, with names like [[GOD manual/Potions]]. | ||
Cross-linking is good. Try to avoid repeating yourself – having the same information in multiple places is a good way to have multiple bits of information fall out of sync with each other – and instead write something once and link to it anywhere else it's useful. | Cross-linking is good. Try to avoid repeating yourself – having the same information in multiple places is a good way to have multiple bits of information fall out of sync with each other – and instead write something once and link to it anywhere else it's useful. | ||
There are competing goals to everything we're writing here: we want things that are quick and easy and straightforward to follow, and we ''also'' want to document why we do things the way we do them, so if we want to change things in future we have half a chance of understanding why things are the way they are now. Consider having separate sections in any process documentation for (a) a process overview for folk who know what they're doing but want a reminder of some specifics, (b) a detailed step-by-step guide for folk who have no idea what they're doing, and (c) a final section explaining the reasoning behind anything that isn't obvious. | There are competing goals to everything we're writing here: we want things that are quick and easy and straightforward to follow, and we ''also'' want to document why we do things the way we do them, so if we want to change things in future we have half a chance of understanding why things are the way they are now. Consider having separate sections in any process documentation for (a) a process overview for folk who know what they're doing but want a reminder of some specifics, (b) a detailed step-by-step guide for folk who have no idea what they're doing, and (c) a final section explaining the reasoning behind anything that isn't obvious. | ||
Revision as of 19:26, 3 July 2023
The GOD manual is the repository for the vast majority of processes that GOD crew follow at (and occasionally between) events.
Historically, the GOD manual has been a PDF. As of now – July 2023 – we're in the process of migrating it from the PDF to this wiki. If you'd like to help, get in touch with Adam.
For now, we're in the interminable migration period where many things haven't been migrated, so you might need to check both this wiki and the PDF manual.
Caution: this wiki is publicly accessible. The vast majority of things that GOD do are fine to publish here, but be careful not to reference details of plot that aren't generally available. You can talk about the existence of (say) chaos fruit, since that's available on the player wiki, and you can talk about how we organise them and print them, but don't give any details about how they work from a plot or game mechanic perspective. Equally, if you want to provide screenshots or similar, make sure you don't use a real player account; use Crew Room (PID 0) or Ref Dummy Character (CID 0.1).
Contents
...
Style guide
If you're migrating content from the old manual to this wiki, unless it's likely to be widely applicable to non-GOD crew, create pages under this page, with names like GOD manual/Potions.
Cross-linking is good. Try to avoid repeating yourself – having the same information in multiple places is a good way to have multiple bits of information fall out of sync with each other – and instead write something once and link to it anywhere else it's useful.
There are competing goals to everything we're writing here: we want things that are quick and easy and straightforward to follow, and we also want to document why we do things the way we do them, so if we want to change things in future we have half a chance of understanding why things are the way they are now. Consider having separate sections in any process documentation for (a) a process overview for folk who know what they're doing but want a reminder of some specifics, (b) a detailed step-by-step guide for folk who have no idea what they're doing, and (c) a final section explaining the reasoning behind anything that isn't obvious.