Styleguide

About

Guidelines for editing pages on the wiki for consistent quality and style.

Articles

Edits

Every time you save your edit a commit is made. This commit will be reviewed by administrators. To make their lives easier try not to split your changes into dozens of separate commits but do them all in one go. Another thing that really helps is adding a summary (aka 'Comment') and make proper use of the minor edit option. Both will tell the administrator what to look for when checking the edit. Stating your intention as well, can prevent misunderstandings like: Rephrased foreword for increased readability.

New Pages

Avoid duplicates by thoroughly searching in the wiki and asking if need be. Try to following the existing naming schemes including capitalization. Here is an example, if you were to write a guide of how to walk properly:

Bad: Walk
A bit closer: How to Walk
Almost there: Guide to walking
Good: Guide to Walking

Jokes

Some pages are intended to be entertaining, but when writing guides, please remember that a new player might not realize that something is a joke or sarcasm and will instead take it at face value. For more practical guides, less jokes are better. Where it is more discretionary, please think about where jokes fit and where they don't, and if you are updating someone else's joke, think whether yours is actually funnier.

Terminology

Try to be consistent with any terminology and ask for clarification if need be:

Use tick instead of cycle

Article Quality

When revising and writing articles try to consider the following things:

Correct Language	Check grammar / punctuation / typos. Basically make sure it feels like authentic english
Consistent Capitalisation	For recipes and lists of ingredients capitalize the first letter if it's a multiword statement (Lime juice), but if it's a proper name (Beepsky Smash / Quadruple Sec), capitalize both. For mixed ingredients only capitalize the actual item ("coil of Wire").
Consistent language	Some articles are packed with humour, while others are rather technical. Both is perfectly fine. Try to stay compatible when editing articles.
Ressources	Check for broken / outdated images and links. Make sure the style of used icons is consistent.
Correctness	Making sure that anything stated is true and isn't outdated. Best checked by experienced players and reading the game-code.
Scope / Completeness	Anything described should either be complete, or it should be obvious that it isn't meant to be complete. The best example for the latter are things that are meant to be explored by the players. Best checked by experienced players, developers and reading the code. Remember, that guides are not meant to convert the reader into a ultrarobust powergaming machine by spoonfeeding optimized strategies.
Lore	While there is not fixed lore-concept, it does not hurt to provide slight lore-related hints once in a while. This can best be done for non-technical descriptions and whenever reasoning is given for things being how they are (besides 'science' / 'magic')
Design	Even the best article will feel boring without the proper use of icons and formatting. Proper Highlighting, templates and standard structures are to be used to increase readability without being excessive
Learning-Context	Make sure that basic guides stay basic. Guides should reveal their content by being read top to bottom without prior knowledge and link-jumping. They should still have structured sections that are good to look up for experienced players, too.

Having someone proofread an article for a second opinion never hurt anyone.

Images

Most images can be found in the icons/ source code icons directory. .dmi files are png images with some extra metadata that BYOND uses to handle animations etc. You can easily change the extension and open them with your image editor of choice. When uploading images extracted from gamefiles it can be helpful to comment the source and the content like:

Extracted from icons/obj/storage.dmi
Evidence bag

The content is especially useful if the image name is not intuitive.

Do not upload duplicate files. Update them instead. When uploading new versions of images it can take a while for them to get cached by the wiki. There is no need for repeated uploads. This can take quite a while.

Sprites

Where possible, sprites should be uploaded as a 32px by 32px PNG graphic (for static images) or a 32px by 32px GIF image for animated images. All images should be on an alpha (transparent) background where possible.

Map Images

Should consist of the area being covered and its immediate surrounding walls. Always include full tiles. A quality crop can be easily achieved by using a 32px by 32px grid and the marquee tool set to snap to said grid.

Refer to the images below for further guidance.

Good	Bad

Collaboration

Private pages / sandboxes

It is considered rude to change anything on another users private page without prior explicit permission. If you like someones draft you can copy and edit it in your sandbox.

To use your sandbox use Special:MyPage/Sandbox to be redirected to your own sandbox. You can create as many private sandboxes as you want. Just create an article in the appropriate namespace like: https://wiki.yogstation.net/wiki/User:YourUserName/YourSandboxName

Editing templates

Be very careful when editing templates, as breaking them will look really bad. It is easy to miss relevant use cases - use your sandbox to tinker with a copy and coordinate with the wiki-staff before applying bigger changes.

And as always, make sure to update the documentation.

Contribution guides
General	Hosting a server, Setting up git, Guide to GitKraken, Downloading the source code, Guide to contributing to the game, Reporting issues, Game resources category, Guide to changelogs
Database (MySQL)	Setting up the database, MySQL
Coding	Understanding SS13 code, SS13 for experienced programmers, Text Formatting
Mapping	Guide to mapping, Room Structure, Map merger
Spriting	Guide to spriting
Wiki	Guide to contributing to the wiki, Wikicode, Styleguide