MS Paint Adventures Wiki
Advertisement

This is the Manual of Style for MS Paint Adventures Wiki. This page will give an idea of how to write articles so they are consistent with many of the similar articles. Note that this page is still a work in progress, but what it says thus far should be followed.

Editors should also read the Discussion "Manual of Style", which advises on how best to format posts on talk pages and forum pages for streamlined and consistent communication.

General article guide[]

  • Jailbreak's title is one word, not two.
  • Flash, or more fully, Adobe Flash, is a commercial product. Therefore, "Flash" is capitalized.
  • Article titles should use the most complete confirmed canon name available, e.g. "Calliope" or "John Egbert" rather than "uranianUmbra" or "John". However exceptions to this exist, e.g. "Spades Slick" instead of "Jack Noir" for his A2 iteration. Often, these exceptions are useful for disambiguation purposes, but ultimately they come down to a case-by-case basis, and common sense should guide the article naming. Titles must also be written in singular instead of plural, e.g. "troll" – exceptions are only when the article is a list, e.g. "List of dead characters", or naturally lends itself to plurality, e.g. "Ongoing gags".
    • Article titles should not capitalize all words, e.g. "Ongoing gags" rather than "Ongoing Gags"; the exception to this is if the title consists solely of a name that should be capitalized (see below).
  • Always include basic information about the subject when starting an article.
  • When writing the article content, adventure titles should be written in italics, e.g. Homestuck. Song titles will mostly not be mentioned in articles outside of the relevant album articles, and in infoboxes, where there is a specific template for them. However, if a song title is mentioned in the main text of an article, it should be in quote marks, e.g. "Umbral Ultimatum".
  • The definite (the) and indefinite articles (a/an) should be avoided in article titles, except if they are used as the official title. Also see; Wikipedia:Naming conventions (definite or indefinite article at beginning of name).
  • Wikilinking a word or phrase is limited to the first occurrence of that word or phrase on the page.
  • Many terms are commonly miscapitalized. Common ones include "first guardian", "the scratch" (not to be confused with Doc Scratch) and "dream self", none of which should be capitalized. Conversely, "the Medium", "the Tumor" and the "Green Sun" should be capitalized. If you wish to query a term's capitalization, there is a dedicated forum thread for deciding such cases.
  • Don't all-caps any words unless there is a good reason to. All-caps is used in MSPA for emphasis, usually when a term is first usedHS. It should only be used on the wiki in direct quotations to preserve the capitalisation that a character uses, or if it's clearly a stylistic part of the phrase itself, which will basically never be the case.
  • Avoid the terms "alpha" and "beta" when talking about the kids, their universes, and their sessions. Use "B2" and "B1" respectively instead, because these labels have been used in the comic itself. "Alpha" and "beta" are reserved for labeling timelines and timeline-hopping characters, as well as the two different versions of Sburb.

What should an article have?[]

What is needed can vary wildly depending on the topic of the page. Some things which would be found on almost all pages of a single topic may be completely absent from pages of a different topic.

For characters[]

Character articles, arguably the highlights of this Wiki, should be divided into:

  • Introduction (no heading)
  • Biography
  • Personality
  • Relationships
  • Thematic sections, if there are any (e.g. cherubs' symbology)
    • Note that there should be a very good reason for such sections to exist, rather than being merged into other sections or articles.
  • Gallery, if there is one (see image policy)
  • Trivia

At the bottom of the page, with no section headers, place:

  1. The navigation templates related to the character.
  2. The relevant categories associated with the character.

For concepts[]

Concept articles cover a broad range of topics and can vary from simple to complex. As such the contents of an article should be determined on a case-by-case basis, although some guidelines should be followed:

  • Introduction (no heading)
  • Mechanics and/or features
  • Different components of the concept

For locations[]

Each major location gets an article. Locations are usually given the fullest title used. A location article should include:

  • ...
  • ...
  • ...

Place the navigation template related to the location, and don't forget to categorize them according to the relevant categories.

When writing an article[]

Articles on the MS Paint Adventures Wiki, like the text in MS Paint Adventures itself, freely go between the careful, precise, general descriptive tone of Wikipedia and the generally conversational tone of MS Paint Adventures, riding mixed ongoing gags like a mechanical bull to establish superiority. In terms of the layout and ordering of content, bear in mind that sloppy is fine, but more importantly, arranged is fine too.

Active voice[]

The active voice should be used wherever it doesn't lead to unnecessary emphasis. Here is an example of a sentence in the passive voice:

  • John is stabbed by Jack for the second time, and...

Now, here is an example of that same sentence, except written in the active voice

  • Jack stabs John for the second time, and...

In the active voice, the person performing the action is the subject of the sentence, instead of the person or thing the action is performed on.

Verb tense[]

To determine which tense to use in articles, it is logical to describe events happening in-story in the present tense. However, for some events that are in the past in the story as well, it may be more relevant to use the past tense. In other words:

  • Use present tense to describe plot and events as they happen, e.g. "Jack stabs John", not "Jack stabbed John".
  • Use past tense when describing things that are exclusively in the past from the narrative perspective, such as the A1 troll session.

A related issue is a tendency of some edits to refer to events as happening "recently", i.e. being in an update that took place shortly before the time the edit was made. This is completely against the above guideline about present tense, and furthermore, common sense would indicate that writing in a manner that is capable of becoming outdated is simply not a good idea.

Basically, if an in-story event has been a "current" event taking place at any point in the story, it should be written in the present tense, whereas if it is only ever described as being an event in the past from the narrative point of view, it should be written in the past tense.

In addition, real-world events are always past tense, e.g. "[S] Cascade was released on October 25th".

Spelling[]

Since Andrew Hussie is American and uses US English in his adventures (Calliope notwithstanding), it is logical for this wiki to also use US English. However, that does not mean Commonwealth spellings must be purged. By all means, change them if you're editing the article in question anyway, but preferably don't make edits purely for that purpose.

Point of view[]

On most Wikis, there is a policy to give a "Neutral Point of View" (NPOV). Events should be described objectively, as a rule, and most certainly should not represent any specific fan bias.

Your personal ships in particular do not belong in articles, and will be disposed of in the customary way.

Spoilers[]

It is preferable to keep spoilers in the obvious sections, e.g. under a character's story heading rather than in their intro. However, our spoiler policy is essentially that we don't have one, and unmarked spoilers are to be expected. As such, one should aim to keep article openings as unspoilery as possible, but not go out of one's way to avoid everything that could possibly be a spoiler.

Categorizing[]

Each article must be categorized, and done so according to which category applies to it. A list of categories can be found here.

Category redundancy should be avoided. For example, a page that is categorized under Category:Homestuck characters should not also be in Category:Homestuck and Category:Characters.

Quoting slurs[]

It is an unfortunate fact that the content we cover contains a number of instances of slurs. It is generally possible to avoid quoting these words by simply summarising and rephrasing the quotes, such as in this edit diff (also pictured below), and this is the main route that should be taken wherever possible.

The example edit diff for removing a slur by rephrasing.

If for any reason the quote cannot be summarised – generally if it is being used for a purpose that demands the quote format – consider whether the slur can be removed without losing meaningful information or disrupting the flow of text.

If all else fails and a slur is unavoidable, such as in the title of the Data Structures for Assholes sequel book, the ultimate course of action is to adhere to the wiki's purpose of documentation, and retain it verbatim.

When creating tables and infoboxes[]

For table formatting and markup, see Help:Tables

When making a template[]

Be sure to add an explanation of what purpose it serves, so that the other users of the wiki do not have to guess. This goes double for admins, since if they see no purpose or even possible future potential use for the template, it is likely to be deleted. The explanation can be written as part of the template (between a <noinclude> and </noinclude>) or in the discussion page.

Working with Media Files[]

Adding images[]

The general practice would be to start image placement on the right side by adding "right" in the image coding, as in "[[File:Wiki.png|right]]". The next image would then be placed on the left – "[[File:Wiki.png|left]]" – forming a sort of zigzag pattern. The main exception to this is pages such as weapon lists (i.e. strife specibi and legendary weapons), which act as vertical pseudo-galleries, and have all images right-aligned. This may yet be brought into line with the normal policy, and in the meantime should be considered the sole exception.

An image without white or transparent background should be either bordered or thumbnailed by adding "border" or "thumb" respectively in the image coding, as in "[[File:Wiki.png|border]]" or "[[File:Wiki.png|thumb]]". Border is preferred for images that are a direct illustration of what the accompanying article text describes, and therefore does not require any additional caption. By contrast, a short descriptive caption should be added to thumbnailed images by writing the caption at the end of the code, as in "[[File:Wiki.png|thumb|Caption here]]". Apply common sense when deciding whether or not an image warrants a caption; if in doubt, though, remember that there is no harm in choosing thumbnail and having it changed to border later.

Image galleries should be created when a number of images in a section clutters the layout. However, before creating a gallery, it should be considered whether it would be more prudent to simply remove some superfluous images. Each image in a gallery should have a short descriptive caption, which is produced in the same way as captions on thumbnails.

Advertisement