Guide to Contributing to the Wiki

We're glad you've shown interest in contributing to the Baystation 12 Wiki. Our wiki is a living document, and we welcome additions from our players. In order to contribute:

1. Join the Baystation 12 Discord and use the /tickets open command.
2. Share your proposed edits. This can be anything from fixing a typo to rewriting articles to adding entirely new content.
   • You should include your draft in the ticket, either as a link to a Google Doc, HackMD, or other collaborative writing tool, or as a file (.doc, .txt, etc.). The former is preferred for ease of review.
   • If you plan to include any images in your contribution, please include them in the ticket.
   • Be patient while staff review your contribution, and be prepared to implement edits.
     • All changes need to be checked for style and grammar, and changes to articles dealing with mechanical features (such as guides and role pages) need to be verified for accuracy. Lore-related changes require lore approval, and may take longer to review.
     • Be aware that your contribution may not be approved. We recommend asking staff about a proposed contribution before writing it, in order to gauge interest before putting in the effort.
     • Be open to feedback, and be prepared to implement edits. Especially for large contributions, several rounds of edits may be necessary before a draft is approved.
3. Once reviewed and approved, a staff member will add your edits to the Baystation 12 wiki.

If you have any questions about the contribution process, join the the Baystation 12 Discord and ask a staff member for help.

Contribution Basics

The Baystation 12 Wiki exists both as a guide to help players navigate the rules and mechanics of the game server, and as an encyclopedia of the server's lore. These two sections are the primary bulk of this wiki, and editing them requires you both to be knowledgeable about the game, and to be able to present that knowledge in a clear, professional manner so that players can engage with the game and its setting as easily as possible.

If you come from another SS13-based wiki, keep in mind we most likely do things much differently. Be sure to read through our policies and guidelines before proposing any edits!

Mechanical Articles

The first and primary component of the wiki the mechanical section: articles that are designed to teach the player about the mechanical features of the game. This includes both the "Guides" and the "Roles" category. These articles are designed to teach players how to play the game, what certain roles do, or other mechanical information. They may also be used to give reference information through the use of tables, databases, and files. When contributing to mechanical articles, content should be clear, concise, and accurate in order help players best familiarize themselves with the game.

Lore Articles

The secondary component of the wiki is the lore section: the area of the wiki where players are taught the background story of the game in an encyclopedic format, consisting of articles in the "Lore" category. In this section, articles provide the history and current status of anything that may appear in the world. When contributing to lore articles, you will be telling players factual information – content should be presented as if you were writing an encyclopedia article.

Note that in order to change or add any content to the lore section, your proposal must be approved by the Head Administrator. Additionally, lore regarding alien species may not be changed without the permission of the relevant Species Maintainer, and must be discussed with them for approval.

Getting Started: Finding an Article to Edit

To get started, simply find an article you think could be improved and start working on a draft. For major changes, it is recommended you talk to staff first to determine interest.

There are numerous areas you can help edit in:

• Editing grammar and other common mistakes
• Adding new content
• Updating or reworking existing content
• Creating visual aids
• Doing article maintenance

To more easily find this content in need of editing, you can find a list of pages using our maintenance tags. These tags mark pages that need improvement, and are categorized for easy review. These include:

• Needs Cleanup: Articles with grammar or formatting issues, excessive Manual of Style violations, informal tone, or other miscellaneous issues in need of fixing.
• Stubs: Articles that are missing content necessary for the topic, or that do not have all required information for completion.
• Outdated Articles: Articles with information that does not reflect the current state of the game server or of the server's lore.

Editing Philosophies

Being a contributor means working with others. The wiki is created by multiple people from a variety of different backgrounds and focuses. Keeping that in mind:

• Be assertive: Your knowledge and experiences count. Be assertive about the information you present.
• Be open to feedback: On the other hand, remember that the wiki is written by and for everyone, and that writing for a collaborative project means accepting feedback. Don't be afraid to listen, and don't be offended if someone requests changes.
• Be respectful: Contributing works best when you work with your fellow contributors, not against them. Don't tear down another author's work – feedback should be constructive, not destructive.
• Make the change: If you want to see something on the wiki, write it! It doesn't have to be perfect right away, and we'll be there to help. Feel free to get creative and experiment with new content.

In a nutshell, don't worry about being perfect or making mistakes – but remember that the wiki is a public project, and everyone here is volunteering their time and effort to try and make the wiki a better place. Be kind.

Basic Editing and Writing

Wiki pages are managed and edited directly by server staff, so contributors don't need to know wiki markup (unless they're staff) – just grab your favorite text editor and start writing! If you would like to learn more about our wiki's markup, you can find resources on MediaWiki markup and documentation here.

1. Be descriptive. Don't use vague wording, such as "things," "stuff," etc. Do your best to identify, describe and explain anything that may appear.
2. Use pictures to orient the reader. Pictures are extremely important. They not only provide a visual description to what you are talking about, they can help break up the text and provide "way-points" for a readers eye to catch on. This makes a guide easier to read and easier to follow. Remember to add pictures and plan your article around them. If you don't add them, it's unlikely somebody else will.
3. Minimize background info. Keep information relevant. Use linking to help move additional information. Minimizing background info can also help to prevent readers from getting the info they otherwise wouldn't want to read – the majority of readers only want a specific piece of information, so keeping information short and concise can help them find it.
4. Cross-link heavily. Readers often want to visit other areas of the site or gain more information on a topic. Using the search bar can be an annoyance when they are only looking for the information you mention. You should cross-link heavily so that readers can find that information quickly and effectively.
5. Be simple, not loquacious. Don't use big words, jargon or otherwise assume that the reader is an expert on the subject. Pretend that you are explaining the topic to someone with no background knowledge.
6. Don't overuse markup. Overusing markup, such as bolding, italics, templates or even icons can disorient the reader. Keep markup to a minimum and use it only when necessary.
7. Don't use passive voice. Avoid "I," "Me" or anything else from a first-person perspective. This also helps maintain the neutrality of an article.
8. Use the Manual of Style. When writing, use the Manual of Style below to ensure that content follows the stylistic guidelines of the rest of the wiki. This keeps our wiki consistent, and lets authors know what to expect when making new content.

Manual of Style

When writing and editing content for the wiki, we follow a certain style. The Manual of Style provides a set of guidelines for authors to use when writing new content, and lets us keep our wiki clean and consistent. You should read the Manual of Style thoroughly before editing, to make sure you understand what is expected from an article. For example, using a level-one header is always unacceptable! This is reserved for system maintenance and special articles.

There are situations in which the Manual of Style is ignored – this is acceptable at the discretion of a staff editor, but excessive violations of the manual should be avoided.

Page Creation

Article Titles

1. Article titles follow Title Case.
2. If the article title is within the opening paragraph, it must be bolded.
3. Article titles should not contain a suffix, except where absolutely unavoidable.

Notability

Articles must:

1. Contain enough information to warrant a new page.
2. Be about some part of the game or its community.

Articles must not be one of the following:

1. Unreleased or removed content.
2. Joke or hoax articles.
3. Created for the purpose of advertising specific servers or other products.

Editing

Style of Pages

When creating a page, use the same style as other pages of the same category. This helps both readers and editors, as it lets readers get accustomed to the site and how to find information.

• Header names and order must be consistent. Do not use top-level headers within articles, as these are reserved for page titles.
• All articles, excepting maintenance pages and special articles like the Rules page, should be categorized under Guides, Roles, or Lore. New pages should follow the existing format for their category:
  • All pages should be tagged with their category, as well as any relevant sub-categories.
  • Pages should include the navbox for their category at the bottom of the page (see: Template:Navbox Guides, Template:Navbox Roles, Template:Navbox Lore).
  • When adding new pages, remember to update the category menu (see: Guides, Roles, Lore) and the relevant navbox to include a link to that page.
  • Additionally:
    • Guide pages should instruct players on some aspect of the game server. They should be written in the style of game guides. Guides should, where possible, aim to teach players the underlying principles of mechanics rather than providing step-by-step instructions, and guides should not encourage powergaming.
    • Role pages should describe a role and its expectations within the game server, and may include mechanical guides where relevant to the role. They should be written in the style of game guides. Each role page should include the Job Page Header at the top of the page with relevant information about the role (see: Template:JobPageHeader).
    • Lore pages should provide background information about some aspect of Baystation 12's world. They should be written in the style of encyclopedia articles, similar to Wikipedia. Information should be presented in an objective manner and should be factual in-universe. Articles should be engaging and concise. Keep language simple, and don't assume your readers have extensive background knowledge of the subject – a casual player should be able to pick up your article and understand it without having to look up what "psephocratic directorial confederation" means.

Writing

1. 

   An example of good versus bad emphasis using bolding.
   Text markup should be kept limited:
   • Articles may use bolding for emphasis, such as when enumerating lists or introducing new terms. The use of bolding should be kept limited, and should not become distracting.
   • Italics should be reserved for special notes. It may also be used for certain nouns, like ship names and classes (e.g. "The SEV Torch is a Mako-class corvette"), and should otherwise be avoided.
   • Small text should only be used for special notes or in tables.
   • Other markup, such as ALL CAPS, underlining, and non-standard font colors should not be used.
2. Articles should always begin with a summary paragraph, followed by a level 2 header.
3. Acronyms must always be all caps.

Articles should "flow." This means that they are not "chopped up" into smaller sections by icons, pictures or templates.

Jokes

Jokes are only allowed when used sparingly and do not affect the flow of an article.

Linking

1. Linking must not be more than 10% of the article.
2. Links must only be linked once at the first instance of the appearance of the link, with exception to templates and tables.
3. Unless it affects the wording of an article, two links should never be beside each other.

Redirects

Redirects are acceptable under any of the following conditions:

1. Alternative spelling of the title, such as "Armour" for "Armor".
2. Alternative names, shortened name, or acronyms, such as "SCG" for "Sol Central Government".
3. Previous article name, such as a recently-merged article.
4. Alternative capitalization or form, including changing the title to a plural case.

Templates

Articles should always have the navbox appropriate for their category. These allow users to more easily identify quick information and find other links. Additionally, Role pages and the main page for each alien species should always have a header box.

Headings

1. Headings always use level 2+ headers.
2. Headings may follow Title Case or sentence case, but should be kept consistent within the same article.

Content

1. Articles must not contain notices of bugs, glitches or problems in the game. This is to both reduce workload when the bug is inevitably fixed, and prevent misinformation or breaking of the flow of an article.
2. Articles must not contain HTML if markup is available. This does not apply to backend pages (i.e., templates).

Grammar and Vocabulary

Baystation 12 follows Wikipedia's standards for grammar and punctuation, which may be found here.

Prefer vocabulary common to all varieties of English. Insisting on a single term or a single usage as the only correct option does not serve the purposes of an international wiki.

While Baystation 12 does not prefer any national variety of English, text within a given article should use the conventions of one particular variety and should follow it consistently. The exceptions are:

• Proper names: Use the subject's own spelling e.g., "joint project of the United States Department of Defense and the Australian Defence Force".
• Passages explicitly discussing varieties of English.
• URLs: Changing the spelling of part of an external link's URL will almost always break the link.

Universally used terms are preferable to regional terms, especially in article titles. For example, "glasses" is preferred to the national varieties "spectacles" (British English) and "eyeglasses" (American English); "ten million" is preferable to "one crore" (Indian English).

• If one variant spelling appears in an article title, make a redirect page to accommodate the other variants – as with "artefact" and "artifact" – so that all variants can be used in searches and in linking.
• Try to use commonly understood words or phrases instead of phrases with multiple meanings, or phrases that differ between varieties of English. For example, use "alternative" or "alternating" rather than "alternate", depending on which sense is intended.
• If such terms are unavoidable, you may explain terms to prevent confusion. For example, "the trunk (American English) or boot (British English) of a car".

Images

Icons / Sprites

1. Icons and sprites must be (at standard tile size) 32x32 to 64x64 pixels. Icons for use in Job Page Headers or Species Page Headers may be up-scaled to 96x96 pixels. Non-standard tile sizes may be scaled in the same manner.
2. Use .png format.
3. Transparency must be kept.
4. Icons are only acceptable when they are a direct rip from the source.
5. Up-scaled icons (from 32x32 to 64x64 or 96x96) must be done by nearest neighbor.

Screenshots

Screenshots of the world can be done in the editor – however, it is preferred that the screenshots be taken in-game.

1. Screenshots must have transparency removed.
2. Use .png format.
3. Screenshots must be kept borderless (no window visible).
4. Screenshots must not contain multiple windows, to preserve readability.
5. Screenshots of locations must not have the standard HUD visible.
6. Screenshots must be up to date, and must not contain any visible bugs or glitches, as to maintain sanity.

Other images

• Images taken from other websites must comply to copyright. Any images that do not comply with copyright will be deleted.
• Images must be of high quality and should relate to the article.
• "Real" images should be used sparingly.

---