CONTRIBUTING

Guidelines¶

Contributions require approval, but requirements are light and expectations are low.

For edits, positive technical changes like fixing typos or grammar, updating links, or adding relevant footnotes will all be approved eventually. Changes to the content itself is subject to the approval of the relevant authors.

For new additions, as long as you put in enough effort for others to get the gist of your content, and what you create fits in the world and isn’t awful, it’ll get approved.

The world is big, so it’s not hard to fit in it. Some examples of things that wouldn’t fit, however, would be things like new gods, people or technology from another planet, magic that doesn’t follow established rules, or events that contradict established history. Of course, what is currently established could change to suit what you want to add, provided that the changes are also met with the needed approval, so big world-changing ideas are still worth thinking about if you have them and are willing to discuss them.

As for what “awful” means, there are two main parts. First would be things that aren’t believable, like a character that never experiences failure or rejection, or has no drawbacks. Second would be anything that can be considered hateful or offensive with no believable in-world reason to exist.

Additionally, if what you intend to contribute will directly reference, or be used to actively promote real-world politics, ideologies, religious beliefs, or violence, it will be rejected. This is universal and non-negotiable.

Basically, be cool and stay true to the fiction, and you’ll probably be fine.

Be sure to also look over the meta notes, as they contain valuable real-world points of comparison for creators, like how to handle foreign language, using mystic matter and attunement, and where to draw and apply real-world influences.

Style guide¶

In an attempt to keep this wiki looking somewhat consistent, here are some guidelines on how to actually write stuff.

Templates¶

When creating a new page, check if there’s a template available for it, like the Character profile or Organization templates. These give a basic structure that you should try to stick with for the sake of consistency, but feel free to add or remove sections as you need. If there is no existing template, you may still find the Infobox template useful when inserted at the top of a page.

(If you’re reading this from the wiki, the missing templates folder is viewable in the repo.)

Credit¶

When creating a new page, if you want to be credited for it, include the Author info template at the very bottom of the page and edit it to suit you. Use the same info for any other pages you create to keep it consistent. You can also use this block to declare a different license for the content of your page. If you do not include this on your page, you will receive no credit and your page will be licensed with the default CC-BY-SA 4.0.

Links¶

When another article is mentioned in any article, or you want to link to an external page somewhere on the internet for any reason, link to it only at the first mention. Unless you have a very specific reason, try not to link to the same thing more than once in the same article.

Spelling¶

American English spelling is expected to be used on all canon articles. The only situation where British English spelling should be used instead is in the context of names, items, quotes, and stories originating from or set in areas of the world that would use it.

Punctuation¶

Yes, I put this entire subheading here just to tell you to use double quotation marks instead of single, avoid exclamation marks entirely (outside of quoted dialogue) if possible, and use the oxford comma.

Voice¶

Something something passive voice bad, third grade English teacher.

To be frank, I don’t care whether or not you use the active voice or the passive voice, all I care about is that the information is conveyed. If you want to edit things written in the passive voice into the active voice, I won’t stop you, but I’m also not going to stop anyone else from writing in the passive voice in the first place. Go wild.

Tense¶

Everything should be written in the past tense. All articles here are written with the assumption that “current time” is near the end of the year 2033. There is nothing beyond that point, and nothing taking place actively at that time, and that’s by design.

Numbers¶

In prose, all numbers less than 11 should be spelled out, and all numbers greater than ten should be shown numerically. Exceptions can include:

• General, non-exact numbers at and beyond the million (X million/billion/etc)
• The passage of time (7 minutes, 3 days, etc)
• Dates, times, and coordinates

Dates¶

Dates should be exclusively written numerically in the YYYY/MM/DD format. You may use hyphens as separators as well (YYYY-MM-DD) but the in-world preferred standard is to use slashes. If you want to drop the year, the month must still come first (MM/DD). The week-day format (W##/DD) is also acceptable if you’re into that. This world uses the Gregorian calendar, including leap years, but the months and days in this world do not have names. You can learn more about the specifics of in-world timekeeping here.

Pronouns¶

Third-person pronouns should be always be used in all articles unless explicitly referring to the reader, or yourself as the author, both of which you should try to avoid doing outside of meta content anyway. Whenever a character’s gender is uncertain, use the singular “they” and “themself” to refer to them.

Formality¶

Formal use of language is preferred for most things, but far from mandatory. You should aim to write as formally and impartially as possible, but don’t overthink it if that will hold you back. Just remember that everything written here should be presented as though this world was the real world, and this wiki describes it to its people.

Capitalization¶

Both in article titles and inside the articles themselves, unnecessary capitalization should be avoided. Capitalization should be reserved exclusively for proper nouns, the start of sentences, and in-world titles for events and media. For example:
…they fought in the Siege of Soukotan. ✔️
…they fought in The Siege of Soukotan. ❌
…they fought in the siege of Soukotan. ❌

Italics¶

In-world media and works of art of any kind should always be italicized. The names of historical events, organizations, or other articles should never be italicized. As you can see here, using italics for emphasis is also acceptable, and you should do that rather than using boldface, but ideally your sentences should be explicit enough to not need emphasis at all.

Headings¶

Do not use H1 (#) headings at all. Ever. Period. The name of the file is treated as an H1 heading, so the highest heading you should ever use is H2 (##). Headings are automatically parsed into a table of contents, so every heading in a file needs to be H2 or smaller so that they are all correctly nested under the file name.

Provided you keep that in mind, you can as few or as many headings as you like. You can nest them as deep as H6 (######) if you want to get really crazy.

Admonitions/Callouts¶

Obsidian supports 12 distinct types of admonition (or callout) natively since v0.14.0. They support markdown and wikilinks. For more specific details about them, check the Obsidian documentation.

Of the available 12, this wiki will most often use four, which will also be made quickly accessible with Obsidian templates.

You may change the titles of these if you feel another word would fit better for your intended purpose, but please stay consistent to the intended purpose of these colors. For the foldable boxes, you can also replace the plus with a minus to have them be folded by default if you want.

Of course, you can still use the other natively supported options if you want to. Here they all are so you can see what they look like and their names and aliases.

How to contribute¶

This entire wiki is written with Obsidian in mind, and readability is focused on Obsidian first. I highly recommend that anyone who wishes to contribute to this wiki use Obsidian to do so. With that said, it is not a requirement and you are free to use whatever method you want to contribute to this wiki.

Another thing to keep in mind is that your contributions to this wiki will automatically be licensed under Creative Commons CC BY-SA 4.0 by default, like everything else. You can instead choose to use a different license for your contributions by including it explicitly on your pages, and if you make it easy for others to contact you, you can make separate agreements with individuals as well. For instance, using a non-commercial license publicly, but separately allowing commercial usage only with your explicit permission or under your own terms.

I strongly suggest that if you choose to use another license, you use another Creative Commons license. You can try another license if you really want to, but I’ll have to look over it and decide whether or not it aligns with the purpose of this wiki. I am very critical of intellectual property law and want this world to remain fully open, so “All Rights Reserved” will never be accepted on this wiki. Restrictions may be applied, but all content on this wiki must remain free to use and share to some degree.

Now then, on to some of the ways you can contribute.

Issues¶

If you would rather not fiddle with git but you still want to contribute something, you can submit an issue without the need for anything more than a GitHub account. Click on the New Issue button at the top right and off you go. If you aren’t familiar with git, this will be the easiest for you.

Are you suggesting a small edit, correction, or improvement to a page? Paste a link to the page in question (either from the wiki or the repo), then include the text you want changed, followed by your proposed changes. If you’re suggesting an addition rather than a change, just say so.

Are you suggesting the addition of an entirely new page? Write a little bit about what your new page is and why you want to add it, then attach the page as a separate file. It’s strongly preferred to attach .md files with Obsidian Markdown formatting, but .txt, .odt, .rtf, and .docx files are acceptable. If you want to be credited for your work, make sure you use the author info template at the bottom of your page!

If you don’t have a Markdown editor and don’t want to download anything, you have options. If you have Obsidian and you download this vault (click Code, then Download ZIP), you can create new pages that way and simply upload the finished .md file with your issue.

Once your issue goes through and the proposed changes are accepted, they will be added to the main vault on your behalf, potentially with some changes to the basic formatting for consistency.

Pull requests¶

If you are relatively familiar with git, this route will be preferable to submitting an issue because rather than submitting a proposal for edits or attaching an extra file, you can just make the edits directly to the files or add a new file directly to the collection yourself and submit them for approval, and you can submit several things at once. Since this whole project is just words instead of code, though, this shouldn’t be too difficult even if you aren’t familiar with git.

At the top right of the repo (in the Code tab), click on the Fork button to create your own copy of the repo under your GitHub account.

If you don’t want to download anything or you don’t know what cloning a repo means, you can actually edit files and upload new ones to your forked repo from right here in the browser.

For edits, just find the .md file you want to edit and click on it, then click on the small pencil button on the top right corner of the container with all the text in it. It’ll be on the same line as the button that says “Raw”.

To add a new page, navigate into the folder where your new page belongs, click on the Add file button in the top right, and you can either create a new file from scratch or upload a file you already wrote.

In both cases, from there, you can edit the file and preview it, and when you’re done, just enter a summary of your edits in the Commit Changes area, then hit the green button. After making changes, you should see a new button on your forked repo to create a new pull request, or in other words, submit your changes for review.

Be aware that the more changes you make for your pull request, the more difficult it might be to accept! If your pull request has some accepted changes and some rejected ones, it will be closed without merging, then I will work with you to get the accepted changes in anyway.

You should also remember to synchronize your fork before getting to work on any changes, because there may have been other changes already merged into the main branch that you don’t have yet! If ever you see the sync fork button near the top right corner, click on it.

Have a look at the GitHub documentation if you want to learn more about git, forks, and pull requests. If you take the time to learn the basics of this stuff, you can download your fork to your computer locally and use any program you want to write with, and you can do all of this without even opening your browser if you’re so inclined.

Of course, if you know what cloning is and how to do it, you don’t need me to tell you that.

Obsidian git¶

If you’re an Obsidian user, you can use the Obsidian git plugin for this. This is the method I recommend, because the vault looks best in Obsidian, was made in Obsidian, and is most convenient to work with through Obsidian.

First, fork the repo as decribed earlier, then (assuming you’re a Windows user who doesn’t like the command line) follow this guide with one major difference. That guide tells you to start with a new, empty repo, but for our purposes your repo will already have a vault in it, so you can skip the whole “making your vault a repository” step. GitHub Desktop has a Mac version too, and even a Linux version sometimes for some reason, but you’re on your own there.

In the Obsidian git plugin settings, I recommend enabling pull updates on startup, push on backup, and pull changes before push. You will still (to my knowledge) have to manually sync your fork with the main repo every now and then, but with these settings, you can sync your fork and then open Obsidian and it will automatically be up to date as well.

I also would recommend leaving automatic backups turned off, and instead do it manually for every file you change by pressing ctrl+P, searching for “backup”, and choosing “create backup with specific message” so you can be descriptive about what changed instead of having 500 of the same commit message. But ultimately, it’s in your hands, not mine.

I will admit, setting this up for the first time did not go smoothly for me, but it’s been long enough that I don’t remember what my problem was. What I do know for sure, however, is that it wasn’t the fault of the plugin, it was something to do with my git setup being wrong on Windows. On Linux, it went perfectly. Your mileage may vary, look through the plugin issues and use Google if you have trouble.

It’s also entirely possible to use Obsidian and simply upload your changes through the browser as described in the pull requests section without using the git plugin, but it’s less cool.