Styleguide: Difference between revisions
(→Article Quality: New instructions on lore) |
mNo edit summary |
||
| Line 5: | Line 5: | ||
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: <code>Rephrased foreword for increased readability.</code> | 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: <code>Rephrased foreword for increased readability.</code> | ||
=== New Pages === | === New Pages === | ||
Avoid duplicates by thoroughly searching in the wiki and asking if need be. Try to | Avoid duplicates by thoroughly searching in the wiki and asking if need be. Try to follow the existing naming schemes including capitalization. Here is an example, if you were to write a guide of how to walk properly: | ||
* '''Bad:''' Walk | * '''Bad:''' Walk | ||
* '''A bit closer:''' How to Walk | * '''A bit closer:''' How to Walk | ||
| Line 21: | Line 21: | ||
{| class="wikitable" | {| class="wikitable" | ||
!Correct Language | !Correct Language | ||
|Check grammar / punctuation / typos. Basically make sure it feels like authentic | |Check grammar/punctuation/typos. Basically make sure it feels like authentic English. | ||
|- | |- | ||
!Consistent | !Consistent Capitalization | ||
|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"). | |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 | !Consistent Language | ||
|Some articles are packed with | |Some articles are packed with humor, while others are rather technical. Both are perfectly fine. Try to stay compatible when editing articles. | ||
|- | |- | ||
! | !Resources | ||
|Check for broken / outdated images and links. Make sure the style of used icons is consistent. | |Check for broken/outdated images and links. Make sure the style of used icons is consistent. | ||
|- | |- | ||
!Correctness | !Correctness | ||
|Making sure that anything stated is true and isn't outdated. Best checked by experienced players and reading the game-code. | |Making sure that anything stated is true and isn't outdated. Best checked by experienced players and reading the game-code. | ||
|- | |- | ||
!Scope / Completeness | !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 | |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 an ultrarobust powergaming machine by spoonfeeding optimized strategies. | ||
|- | |- | ||
!Lore | !Lore | ||
| Line 42: | Line 42: | ||
|- | |- | ||
!Design | !Design | ||
|Even the best article will feel boring without the proper use of icons and formatting. Proper | |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 | !Learning-Context | ||
| Line 48: | Line 48: | ||
|} | |} | ||
Having someone proofread an article for a second opinion never hurt anyone. | Having someone proofread an article for a second opinion never hurt anyone. | ||
== Images == | == Images == | ||
| Line 71: | Line 70: | ||
|} | |} | ||
== Collaboration == | == Collaboration == | ||
=== Private pages / sandboxes === | === Private pages/sandboxes === | ||
It is considered rude to change anything on another | It is considered rude to change anything on another user’s private page without prior explicit permission. If you like someone’s 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: | 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: | ||
Latest revision as of 13:05, 24 August 2022
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 follow 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
Categories
You can put articles into categores by inserting the appropriate command like [[Category:Guides]]. This should be done at the bottom of the page. Please refrain from creating new categories or editing article-categories without talking about it with the wiki-staff first. This is necessary for categories to be consistent.
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 Capitalization | 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 humor, while others are rather technical. Both are perfectly fine. Try to stay compatible when editing articles. |
| Resources | 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 an ultrarobust powergaming machine by spoonfeeding optimized strategies. |
| Lore | Follow the current lore as best as possible, if there is no established lore on the topic then do not write any lore and/or request lore from the Lore Team. |
| 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 user’s private page without prior explicit permission. If you like someone’s 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 |