Contributing to the Wiki
The 57 Studios™ Modding Knowledge Base is a living, continuously maintained technical reference for the Unturned™ modding community. Every article in the knowledge base was written, revised, validated, and published by a contributor, a person who understood a specific corner of the modding workflow well enough to document it for others. The knowledge base grows through contributions from the modding community, and this article explains exactly how a new contributor can submit content, what standards the content must meet, how the editorial process works, and what the contributor can expect after submission.
Anyone can contribute to the 57 Studios™ Modding Knowledge Base. There is no application process, no minimum level of experience, and no gatekeeping mechanism that prevents a person from submitting a correction, an improvement, or an entirely new article. The knowledge base is a community resource, and 57 Studios™ maintains it as an open project with a documented contribution pipeline. The only requirement is that the submitted content meets the article standards documented here and in the VOICE-CONTRACT.md file referenced throughout this article.
This article is the final orientation document in the getting-started section of the knowledge base. The previous article (Offline Downloads) documents how to obtain a portable copy of the documentation. The next section, Steam Setup, begins the toolchain installation sequence that leads into actual mod development. A reader who has completed this article understands how the knowledge base is authored and maintained, and is equipped to contribute to it.
Who this article is for
This article is written for three audiences. The first audience is the mod developer who has noticed a gap, an error, or an unclear passage in the knowledge base and wants to fix it directly rather than hoping someone else will. The second audience is the experienced modder who wants to contribute a complete new article documenting a workflow, a file format, or a system chain that the knowledge base does not yet cover. The third audience is the prospective contributor who is curious about how the knowledge base is produced and wants to understand the editorial model before committing to a contribution.
No prior experience with documentation writing or with the knowledge base's toolchain is assumed or required. The contribution process is designed to be accessible to a first-time contributor working on any Windows computer with a text editor and a GitHub account.
Prerequisites
- Completion of the getting-started section up to and including Offline Downloads
- A GitHub account (free; sign up at
https://github.com/) - A text editor capable of editing Markdown files (Notepad++, Visual Studio Code, or any plain-text editor)
- A basic understanding of what files and folders are (covered in What is a File? and What is a Folder?)
- A basic understanding of what a download is (covered in What is a Download?)
- A working internet connection for submitting contributions
- Approximately thirty minutes of uninterrupted reading time
What you'll learn
- The philosophy and editorial model of the 57 Studios™ Modding Knowledge Base
- What kinds of contributions are welcome and what kinds are not
- How the knowledge base is authored (Markdown format, frontmatter, file structure)
- The article standards every contribution must meet, as established in the voice contract
- The complete submission process, from finding the repository to opening a pull request
- How the editorial review process works and what to expect after submission
- The attribution policy (57 Studios™ as the collective author)
- How to update an existing article versus creating a new article
- The preferred way to report issues without submitting code changes
- The conventions that govern article structure, voice, formatting, and cross-linking
How the knowledge base is authored and published
The 57 Studios™ Modding Knowledge Base is a collection of Markdown files stored in a GitHub repository. Each article is a single .md file in the articles/ directory, organized into subdirectories by section (e.g., articles/getting-started/, articles/items/, articles/unity-setup/). The repository is public and can be viewed, forked, and cloned by anyone with a GitHub account.
The knowledge base is built and published as a static website at https://docs.57studios.net/. The build process converts the Markdown files into HTML pages, applies the site's visual theme, generates the navigation structure from the prev and next fields in each article's frontmatter, and deploys the result to the web server. The build process is triggered automatically when changes are merged into the main branch of the repository. A contributor does not need to understand the build process to submit content; the contributor only needs to write the Markdown file correctly, and the build pipeline handles the rest.
The editorial model
The knowledge base follows a collective authorship model. Every article is attributed to "57 Studios" as the author. No individual contributor names appear in the article prose, frontmatter, or document history table. The organization is the author, and individual contributors are acknowledged through the GitHub contribution history and through internal project records, but never through bylines on published articles.
This model is intentional and is documented in the voice contract (VOICE-CONTRACT.md, section 12). The collective authorship model removes the authorship anxiety that can deter new contributors ("Who am I to write an authoritative article on this topic?"), simplifies the editorial maintenance burden (a single author line never goes stale when contributors come and go), and reinforces the knowledge base's identity as a community resource rather than a collection of individually-branded essays.
The collective authorship model does not mean individual contributions are invisible. Every proposed change is submitted through a GitHub pull request, which carries the contributor's GitHub username, the date of submission, the list of changed files, and the commit message describing the change. The contribution is publicly attributed to the contributor in the repository's commit history and in the pull request record. The distinction is that the published article page carries "57 Studios" as the author, while the repository history carries the contributor's identity.
The flowchart above shows the contribution pipeline from writing to publication. The editorial review step is the only gate, and it checks only that the submitted content meets the documented article standards. It does not evaluate the contributor's credentials, experience level, or relationship with 57 Studios™.
What kinds of contributions are welcome
The knowledge base welcomes contributions across a wide spectrum of size and complexity. The following categories cover the most common types of contribution.
Corrections
A correction is a change to an existing article that fixes an error. The error might be a typo, a misstated field name, an incorrect default value, a broken cross-reference link, or a procedure step that is described in the wrong order. Corrections are the easiest type of contribution to make and the most important type to submit promptly: an error that goes uncorrected misleads every mod developer who reads that article until the correction is published.
To submit a correction, the contributor edits the relevant .md file directly, fixes the error, and submits a pull request with a commit message that describes what was wrong and what the fix is. The editorial review for a correction is typically fast because the change is small and targeted.
Improvements
An improvement is a change to an existing article that adds value without fixing an error. Examples include adding a new FAQ entry that answers a question the original article did not address, expanding an under-documented section with additional detail, adding a worked example that illustrates a concept, or adding a diagnostic table entry that covers a failure mode the original article missed.
Improvements follow the same submission process as corrections but tend to involve larger changes and therefore a slightly longer editorial review. The contributor should include in the pull request description a brief explanation of what was added and why the addition improves the article.
New articles
A new article is a complete, standalone .md file that documents a topic the knowledge base does not currently cover. New articles are the highest-effort and highest-value type of contribution. A well-written new article that documents a system chain, a file format, or a workflow comprehensively becomes part of the permanent knowledge base and serves every future mod developer who works in that area.
New articles must meet the full set of article standards documented in the voice contract and in this article. The editorial review for a new article is more thorough than for a correction or improvement because the article is being evaluated as a complete unit against every standard in the voice contract.
Before writing a new article, the contributor should confirm that the topic is not already covered elsewhere in the knowledge base, either in a dedicated article or as a subsection of a larger article. The contributor should also confirm that the topic falls within the knowledge base's scope: Unturned™ mod development, the Unity Editor toolchain, the 57 Studios™ server infrastructure, or the foundational computer literacy required to use the modding tools.
Issue reports
An issue report is a contribution that identifies a problem without proposing a specific fix. If a mod developer notices an error, a gap, or an unclear passage in the knowledge base but is not confident in writing the correction directly, the developer can file an issue on the GitHub repository describing the problem. The issue should include the article path, the specific section or claim that is problematic, the reason it is problematic, and, if known, what the correct information should be.
Issue reports are triaged by 57 Studios™ and either assigned to an existing contributor for resolution or left open for a community contributor to address. Filing an issue is the recommended route for a mod developer who wants to contribute to the knowledge base's quality but is not yet comfortable writing or editing articles directly.
Article standards
Every contribution to the knowledge base must meet the article standards documented in the voice contract (VOICE-CONTRACT.md). The voice contract is the binding authority on article structure, formatting, voice, and conventions. A contributor who submits content that violates a provision of the voice contract will receive feedback identifying the violation and requesting revision. The editorial review does not accept articles that knowingly violate the voice contract.
The most important voice contract provisions for a new contributor to understand are summarized below. This summary is not a substitute for reading the voice contract in full; the summary highlights the provisions that first-time contributors most commonly overlook.
Article structure
Every article must follow the skeleton documented in the voice contract (section 2). The mandatory sections for a reference or tutorial article are: title, opening prose, image placeholder, prerequisites, what you'll learn, background/system architecture, main content, FAQ (at least five entries), cross-references, and document history. The mandatory sections for an orientation article (getting-started section) are: title, opening prose, image placeholder, main content, best practices, cross-references, and document history.
Articles that omit mandatory sections will be returned for revision. The most commonly omitted sections are the FAQ (which must have at least five entries, each with a question mark in the heading) and the document history table.
Voice register
The knowledge base uses a formal, patient, sincere, authoritative voice register. The prose must be confident declarations, not hedged speculations. Every claim must be verifiable against a source document or a shipped game file. The prose must never be knowing, self-aware, self-referential, or otherwise self-commenting. The content of an article treats its subject with complete sincerity. This is the established corpus character that all contributions match.
Dashes rule
Dashes rule
Only the plain hyphen is permitted in prose (voice contract, section 10). No em dashes, no en dashes. The single permitted exception is the em dash used as an empty table cell placeholder, which is an established convention in the existing corpus.
Attribution
All attribution is to "57 Studios" only (voice contract, section 12). The document history table's Author column is always "57 Studios." No individual names appear anywhere in article prose, frontmatter, or metadata.
Accuracy rule
Every claim in every article must trace to evidence (voice contract, section 15). The evidence sources are the official Smartly Dressed Games modding documentation and the shipped Unturned™ game files. A contributor must not invent identifiers, guess field names, or fabricate default values. If a value does not appear in the source documentation or in a shipped game file, it must not appear in the article.
Line count floor
Every article must be at least 500 lines long (voice contract, section 14). The target is 750 lines. Articles shorter than 500 lines are incomplete and will not be accepted. A contributor who is documenting a genuinely thin topic must supplement the article with worked examples, Mermaid diagrams, expanded FAQ entries, diagnostic tables, and appendices to reach the floor.
The article file format
Every article in the knowledge base is a Markdown file with YAML frontmatter. The frontmatter is the block of YAML between the opening and closing --- delimiters at the top of the file. The frontmatter contains the article's metadata: title, description, prev/next navigation links, and (for Format B articles) additional fields like ogImage, canonical, type, faqSchema, and howToSchema.
Format A frontmatter (minimal)
Format A is used for getting-started orientation articles and select troubleshooting articles. It contains only the essential fields:
yaml
---
title: "Article Title"
description: "Sentence-length description of the article."
prev:
text: "Previous Article Title"
link: "/section/previous-article-slug"
next:
text: "Next Article Title"
link: "/section/next-article-slug"
---Format B frontmatter (full)
Format B is used for reference articles, tutorial articles, deep-dive articles, and all items/articles. It contains additional metadata fields:
yaml
---
title: "Article Title | 57 Studios Modding KB"
description: "Sentence-length description, 80-160 characters, keyword-dense."
ogImage: /og/section/article-slug.png
canonical: https://docs.57studios.net/section/article-slug
type: article
prev:
text: "Previous Article Title"
link: "/section/previous-article-slug"
next:
text: "Next Article Title"
link: "/section/next-article-slug"
faqSchema: true
howToSchema: true
---The title field in Format B appends the suffix " | 57 Studios Modding KB". The ogImage and canonical fields are required in Format B and absent in Format A. The faqSchema and howToSchema fields are set to true or false based on whether the article contains an FAQ section or procedural content.
Frontmatter field reference
| Field | Required | Notes |
|---|---|---|
title | Always | Format B appends " | 57 Studios Modding KB". Format A uses bare title. |
description | Always | Single sentence, 80-160 chars, front-loads search terms. |
ogImage | Format B | Path: /og/<section>/<slug>.png. |
canonical | Format B | Full URL: https://docs.57studios.net/<section>/<slug>. |
type | Format B | Always "article". |
prev | Usually | { text, link }. Omit only when article is first in section. |
next | Usually | { text, link }. Omit only when article is last in section. |
faqSchema | Format B | true or false. true when article has FAQ section. |
howToSchema | Format B | true or false. true when article contains procedures. |
The prev/next chain
The prev and next fields in each article's frontmatter form a doubly-linked list across every article in a section. The link field is root-relative, lowercase, hyphenated, and has no .md extension. The text field matches the target article's title exactly, minus the KB suffix for Format B articles.
When adding a new article to a section, the contributor must update the prev and next fields of the adjacent articles so that the chain remains unbroken. For example, if a new article is inserted between article A and article B, article A's next field and article B's prev field must both be updated to point to the new article. The new article's prev points to A and its next points to B.
Broken prev/next chains cause navigation breakage
A missing or incorrectly-linked prev or next field will prevent the previous/next navigation buttons from appearing on the published article page. A broken chain also breaks the section's sequential reading progression, which is the primary learning path for new mod developers. The editorial review checks the prev/next chain for every new article submission.
The submission process
The contribution submission process follows the standard GitHub pull request workflow. The steps below assume the contributor has a GitHub account and a text editor installed. No other tools are required.
Step 1: Fork the repository
Navigate to the knowledge base repository at https://github.com/smartlydressedgames/57studios-wiki. Click the "Fork" button in the upper-right corner of the page. GitHub creates a copy of the repository under the contributor's GitHub account. This fork is the contributor's personal workspace where changes can be made without affecting the main repository.
Step 2: Clone the fork to the local computer
Open a command prompt or PowerShell window. Navigate to the folder where the repository should be stored (the cohort recommendation is C:\Dev\repos\). Clone the fork with:
git clone https://github.com/<your-username>/57studios-wiki.gitReplace <your-username> with the contributor's GitHub username. The clone operation downloads the entire repository to the local computer.
Step 3: Create a new branch for the contribution
Navigate into the cloned repository folder and create a new branch for the contribution:
cd 57studios-wiki
git checkout -b my-contributionThe branch name should be descriptive of the change (e.g., fix-offline-downloads-link, add-resource-asset-article, improve-melee-faq). The branch isolates the contribution's changes from the main branch and from any other work in progress.
Step 4: Make the changes
Open the relevant .md files in a text editor and make the changes. For a new article, create the .md file in the appropriate section subdirectory under articles/. For a correction or improvement, edit the existing file. Follow the article standards documented in the voice contract and in this article.
Before writing a new article, read the exemplars
The knowledge base includes three exemplar articles that serve as structural models for every article type. Read the exemplar that matches the article type being written:
- Short orientation articles:
articles/getting-started/what-is-a-file.mdas the model for Format A frontmatter, orientation prose, and heavy appendix structure. - Median reference articles:
articles/items/melee-asset.mdas the model for Format B frontmatter, balanced callouts, and worked examples. - Long reference articles:
articles/items/magazine-asset.mdas the model for exhaustive field references, deep-dive concept articles, and extensive FAQ sections.
The exemplars demonstrate the article skeleton, the voice register, the table conventions, and the callout usage that the voice contract prescribes. A contributor who has not read the exemplars will produce articles that diverge from the established style and require more revision.
Step 5: Commit the changes
After making the changes, stage them for commit and write a commit message:
git add .
git commit -m "Add article: My New Article Title"The commit message should be concise and descriptive. For a correction, the message should describe what was wrong and what the fix is. For a new article, the message should state the article title.
Step 6: Push the branch to the fork
Push the branch to the contributor's fork on GitHub:
git push origin my-contributionStep 7: Open a pull request
Navigate to the contributor's fork on GitHub. GitHub displays a banner suggesting that the recently pushed branch be opened as a pull request. Click "Compare & pull request." Fill in the pull request title and description. The description should explain what the contribution contains and why it improves the knowledge base. Click "Create pull request."
The pull request is now visible to the 57 Studios™ editorial team. The contributor will receive notifications when the pull request is reviewed, when feedback is provided, and when the pull request is merged.
Step 8: Respond to review feedback
The editorial review may request changes before the contribution can be merged. The feedback will appear as comments on the pull request. The contributor makes the requested changes on the same branch, commits them, and pushes the updated branch to the fork. The pull request updates automatically to reflect the new commits.
Step 9: Merge and publication
Once the editorial review is satisfied, the pull request is merged into the main branch. The merge triggers the build pipeline, and the updated or new article appears on https://docs.57studios.net/ within a few minutes.
The editorial review process
The editorial review checks the submitted contribution against the article standards documented in the voice contract. The review does not evaluate the contributor's credentials or experience. The review evaluates only the content against the written standards.
The typical review covers the following checks:
- Frontmatter correctness. The
title,description,prev, andnextfields (andogImage,canonical,type,faqSchema,howToSchemafor Format B) are present and correctly formatted. - Article structure. All mandatory sections from the voice contract skeleton are present.
- Voice register. The prose uses the formal, patient, sincere, authoritative register. No forbidden vocabulary appears.
- Dashes rule. No em dashes or en dashes appear in prose. The only permitted em dashes are in empty table cells.
- Accuracy. Every claim that can be verified is verified against the named evidence sources. No invented identifiers, field names, or default values appear.
- Cross-links. Internal links use the correct root-relative, lowercase, hyphenated format. External links are minimized to the permitted URL set. Cross-references include the canonical SDG documentation link.
- Line count. The article meets or exceeds the 500-line floor.
- Attribution. The document history table's Author column is "57 Studios." No individual names appear in prose, frontmatter, or metadata.
- Trademarks. Format A articles use Unicode
™. Format B articles use HTML™entities. Smartly Dressed Games is never trademark-marked.
The review feedback is written to be actionable. Each requested change includes a reference to the specific voice contract provision that the current content violates, a description of what is currently wrong, and a suggestion for how to fix it. The contributor is not expected to guess what the reviewer wants; the feedback is explicit.
Editorial review turnaround time
The 57 Studios™ editorial team reviews pull requests on a rolling basis. The typical turnaround time for an initial review is within one week of submission. Corrections and small improvements are typically reviewed within two to three days. Large new articles may take longer because the review is more thorough. If a pull request has not received a review within two weeks, the contributor may add a comment to the pull request asking for a status update.
What not to contribute
Some types of content are outside the knowledge base's scope and should not be submitted.
Personal or promotional content
The knowledge base is a technical reference for Unturned™ mod development, not a platform for promoting individual modders, mod projects, servers, YouTube channels, or commercial services. Articles that primarily promote a specific person, mod, or service will be declined.
Duplicate content
Before writing a new article, search the knowledge base to confirm the topic is not already covered. A topic that is covered in an existing article should be improved through an expansion of that article, not duplicated in a new article.
Out-of-scope content
The knowledge base covers Unturned™ mod development, the Unity Editor toolchain, the 57 Studios™ server infrastructure, and the foundational computer literacy required to use the tools. Content outside these domains (general Unity tutorials unrelated to Unturned™, game design theory, Blender modeling tutorials not specific to Unturned™ asset preparation) is out of scope.
However, the knowledge base's foundational section (getting-started) explicitly covers foundational computer literacy topics because new mod developers arrive with a wide range of technical backgrounds. A contributor who is unsure whether a topic is in scope should file an issue asking for guidance before writing the article.
Content that violates the voice contract
A submission that knowingly violates the voice contract's provisions on voice register, forbidden vocabulary, dashes, or attribution will be declined. The voice contract is the binding standard, and articles that do not meet the standard are not published.
Best practices for contributors
- Read the voice contract in full before writing. The summary in this article covers the most commonly overlooked provisions, but the voice contract is the authority and every provision in it is binding.
- Read the exemplar articles that match the type of article being written. The exemplars demonstrate the conventions in practice and save substantial revision time.
- Keep corrections small and targeted. A pull request that fixes a single typo in a single article is preferred over a pull request that fixes ten typos across ten articles, because the small pull request is faster to review and less likely to introduce collateral changes.
- Write descriptive commit messages. A commit message of "fix" tells the reviewer nothing. A commit message of "fix incorrect Damage_Resource default value in melee asset article" tells the reviewer exactly what changed.
- Respond to review feedback promptly. The sooner the contributor addresses requested changes, the sooner the contribution is published. Pull requests that sit unaddressed for more than two weeks may be closed.
- Test every cross-link before submitting. A broken internal link (wrong slug, wrong section) is the single most common technical error in new article submissions. Click every link in the article to confirm it resolves to the intended target.
- Check the line count before submitting. Run a line-count tool (
Get-Content article.md | Measure-Object -Linein PowerShell) to confirm the article meets the 500-line floor. An article that is 20 lines short of the floor and is submitted anyway will be returned for revision. - Search for em dashes before submitting. The text editor's find function (
Ctrl+F) can search for the Unicode em dash character and the en dash character. Replace every instance (except empty table cells) with a plain hyphen. - File an issue if the scope or direction of a contribution is uncertain. The issue is a low-commitment way to get guidance before investing time in a full article draft.
Frequently asked questions
Do I need permission to contribute?
No. The knowledge base is an open project. Anyone can fork the repository, make changes, and submit a pull request. No permission, application, or approval is required before starting.
Will my name appear on the article I write?
No. The knowledge base uses a collective authorship model in which every article is attributed to "57 Studios." Your contribution is recorded in the GitHub repository's commit history and in the pull request record, but your name does not appear on the published article page.
What happens if my pull request is declined?
A decline is rare. The editorial review process is designed to request revisions rather than to decline submissions outright. The most common reason a pull request would be declined is that the content is out of scope (personal promotion, duplicate content, content outside the modding domain). If a pull request is declined, the reviewer will explain the reason in the pull request comments, and the contributor can use that feedback to guide a future submission.
How long does the editorial review take?
Corrections and small improvements are typically reviewed within two to three days. New articles are typically reviewed within one week. Large, complex articles may take longer. If a pull request has not received a review within two weeks, the contributor may add a comment asking for a status update.
Can I contribute to an article someone else wrote?
Yes. The knowledge base is collectively authored, and any contributor can propose improvements to any article. The editorial review evaluates the improvement on its merits, not on who wrote the original article or who is proposing the change.
What if I don't know Git?
The submission process uses Git and GitHub because they are the standard tools for managing collaborative text projects. A contributor who does not know Git can learn the subset of Git commands needed for the submission workflow in approximately fifteen minutes. The six commands needed (clone, checkout, add, commit, push, and the GitHub pull request interface) are documented in this article's submission process section. For a contributor who wants to contribute without learning Git, filing an issue describing the problem or proposed content is the recommended alternative.
Can I submit an article that is shorter than 500 lines?
No. The 500-line floor is a hard requirement in the voice contract. An article shorter than 500 lines will be returned for revision with suggestions for expansion. The recommended expansion strategies are: add worked .dat examples, add Mermaid diagrams, expand the FAQ section to cover more edge cases, add diagnostic tables, and add appendices with quick-reference cards.
How do I know which frontmatter format to use?
Format A (minimal) is used for getting-started orientation articles and select troubleshooting articles. Format B (full) is used for reference articles, tutorial articles, deep-dive articles, and all items/articles. If you are unsure, check an existing article in the same section for the format it uses.
Can I use the official Unturned game files as evidence for my article?
Yes, and doing so is required by the accuracy rule (voice contract, section 15). Every claim in an article must trace to evidence: the official SDG documentation, the shipped Unturned™ game files, or both. A contributor must open and read the relevant game files, extract the actual field names and values, and cite them in the article. Never invent identifiers or guess values.
What is the difference between a correction and an improvement?
A correction fixes an error: a typo, a wrong field name, a wrong default value, a broken link. An improvement adds value without fixing an error: a new FAQ entry, an expanded explanation, a worked example, a diagnostic table entry. Both are welcome, and both follow the same submission process.
Can I submit a contribution in a language other than English?
The knowledge base is currently published in English only. Contributions in other languages are not accepted at this time because the editorial team cannot review content in languages it does not read. If 57 Studios™ adds support for additional languages in the future, the contributing process will be updated to reflect the new language options.
Do I need to provide images or diagrams with my article?
Image placeholders (the  or /og/getting-started/what-is-unturned.png line that appears early in every article) are required by the article skeleton. The actual image files do not need to be contributed by the article author. The 57 Studios™ editorial team handles image production (screenshots, OG images, diagram rendering) separately from article text contributions. The contributor should include the placeholder line and leave the image production to the editorial pipeline.
Can I contribute a draft that is not yet complete?
A partial draft can be submitted as a pull request in draft status. On GitHub, when opening a pull request, the contributor can select "Create draft pull request" from the dropdown next to the "Create pull request" button. A draft pull request signals to the editorial team that the contribution is in progress and is not ready for final review. The editorial team may provide early feedback on a draft but will not perform a full review until the draft is marked as ready.
What if I need to update my pull request after submitting it?
Make the changes on the same branch, commit them, and push the branch again. The pull request updates automatically to reflect the new commits. There is no need to open a new pull request or close the existing one. The editorial team sees the latest state of the branch on every review pass.
How do I handle merge conflicts in my pull request?
A merge conflict occurs when the contributor's branch and the main branch have both modified the same lines of a file since the branch was created. GitHub displays a warning on the pull request when a merge conflict exists. To resolve the conflict, the contributor pulls the latest main branch into their feature branch, resolves the conflict in the affected file, commits the resolution, and pushes the updated branch. If the contributor is uncomfortable resolving merge conflicts, the editorial team can assist through pull request comments.
Can I contribute a series of related articles in a single pull request?
A pull request should be scoped to one logical change. A single pull request that contains three related articles on the same topic (e.g., a gun asset article, its magazine article, and its attachment article) is acceptable because the three articles are part of the same logical contribution. A single pull request that contains one correction to a melee article and one new article about map lighting is not acceptable because the two changes are unrelated. Pull requests that mix unrelated changes are slower to review and more likely to introduce review confusion.
How do I know what evidence sources my article needs to cite?
The work order system specifies the evidence sources for every article. When the editorial team assigns or accepts a new article topic, the work order lists the exact source extract path in .wikigen/sdg-sections/ and the exact shipped game file paths under the Unturned installation directory that the writer must open and read. If no work order exists for the proposed article, the contributor should file an issue describing the proposed topic and the evidence sources available. The editorial team will respond with guidance on whether the sources are sufficient.
What is the difference between the knowledge base and the official SDG documentation?
The Smartly Dressed Games modding documentation is the official field and system reference, authored by the game's developers. The 57 Studios Modding Knowledge Base is a community-maintained knowledge base that expands on the official documentation with worked examples, diagnostic tables, balance guidance, design patterns, cohort-validated best practices, and the foundational computer literacy articles that the official documentation assumes readers already possess. The knowledge base cites the official documentation as its primary evidence source and does not contradict it. Articles that directly replicate the official documentation without adding value are not accepted; articles that expand, illustrate, or contextualize the official documentation are the knowledge base's core contribution.
Can I use screenshots from the game in my article?
Screenshots from Unturned™ gameplay can be used as evidence in an article, particularly when the screenshot demonstrates a behavior, a UI element, or a configuration result that the text describes. However, the editorial team handles final image production, so contributor-provided screenshots serve as evidence and reference material rather than as final published images. The contributor should describe what the screenshot shows and why it is relevant, and the editorial team will produce the final published image.
How do I suggest a new article topic without writing the article myself?
File an issue on the GitHub repository with the title "New article proposal: [Topic]" and a description that covers what the article should document, why the topic is currently undocumented or under-documented, and what evidence sources exist (SDG documentation chapters, game files, community knowledge). The editorial team will evaluate the proposal and either create a work order for the topic or explain why the topic is not currently within scope.
What happens to my fork after my pull request is merged?
The fork persists on GitHub under the contributor's account. The merged branch can be deleted (GitHub offers a "Delete branch" button after merge), but the fork itself remains. The contributor can keep the fork synchronized with the main repository using git fetch upstream and git merge upstream/main, or can delete the fork and create a new one for the next contribution. Either approach is acceptable.
How does the knowledge base handle articles that become outdated?
Outdated articles are flagged for revision through the issue tracking system. A community member who notices an outdated claim, an obsolete procedure, or a field value that has changed files an issue describing the specific problem. An editorial team member or community contributor then submits a correction pull request that updates the article. There is no automated staleness detection; the knowledge base relies on community vigilance to identify content that has fallen behind the current state of the game or the modding toolchain.
How the build pipeline works
The knowledge base is built from Markdown source files into a static website using a build pipeline that runs automatically on merge to the main branch. Understanding the build pipeline is not required for contributing, but a basic awareness of what happens after a pull request is merged helps contributors understand the full lifecycle of their content.
The build pipeline performs the following transformations on every merge:
- Markdown to HTML conversion. Each
.mdfile is converted into a complete HTML page with the site's visual theme, navigation elements, and metadata tags. - Frontmatter processing. The YAML frontmatter at the top of each article is parsed into the page's
<title>, description tag, Open Graph tags, and JSON-LD structured data (for FAQ and HowTo schema). - Link resolution. Internal cross-references (links between articles) are validated during the build. A broken internal link produces a build warning.
- Navigation generation. The
prevandnextfields across all articles in a section are assembled into the prev/next navigation bar at the bottom of each article page. - Section index generation. The section
index.mdfiles are compiled into the section overview pages that list all articles in the section. - Search index generation. The article text is indexed for the site's search engine, enabling the relevance-ranked search that is one of the live site's features not available in the offline documentation.
The build pipeline takes approximately two to three minutes from merge to deployment. The contributor can verify that the build succeeded by visiting the article's URL on https://docs.57studios.net/ after the merge notification appears on the pull request.
Appendix E: Pull request description template
A well-written pull request description accelerates the editorial review by giving the reviewer immediate context for what the contribution contains and why. Copy the template below and fill in each section.
## What this contribution contains
[A one- to three-sentence summary of what the contribution adds, fixes, or improves.]
## Why this contribution improves the knowledge base
[A one- to two-sentence explanation of why the change matters to mod developers.]
## Evidence sources
- SDG documentation chapter: [Chapter number and title]
- Game files referenced: [Paths under the Unturned installation directory]
- Community-validated knowledge: [Brief description if applicable]
## Checklist
- [ ] Article meets the 500-line minimum (run `Get-Content article.md | Measure-Object -Line` in PowerShell)
- [ ] Voice contract provisions are satisfied (voice register, forbidden vocabulary, dashes rule, attribution)
- [ ] All mandatory sections from the voice contract skeleton are present
- [ ] All cross-links are tested and resolve correctly
- [ ] Frontmatter prev/next fields are correct and the section chain is unbroken
- [ ] Document history table is present with Author column set to "57 Studios"
- [ ] No em dashes or en dashes appear in prose (empty table cells excepted)
- [ ] Trademarks use the correct convention for the article's frontmatter format
## Notes for the reviewer
[Any context the reviewer needs: known edge cases, design decisions, areas where feedback is especially welcome.]The template is a guideline, not a rigid requirement. A contribution that is too small to justify a full template (a single-typo correction, for instance) can use a simplified description. The template is most useful for new article submissions and for substantial improvements to existing articles.
Appendix A: Contribution workflow quick-reference card
| Step | Command or action |
|---|---|
| Fork the repository | Click "Fork" on https://github.com/smartlydressedgames/57studios-wiki |
| Clone the fork | git clone https://github.com/<username>/57studios-wiki.git |
| Create a branch | git checkout -b my-contribution |
| Make changes | Edit .md files in a text editor |
| Stage changes | git add . |
| Commit changes | git commit -m "Descriptive message" |
| Push branch | git push origin my-contribution |
| Open pull request | Click "Compare & pull request" on the fork's GitHub page |
| Respond to review | Make requested changes, commit, push again |
| Merge and publish | 57 Studios editorial team merges the pull request; the site builds automatically |
Appendix B: Markdown formatting quick reference
Markdown is the formatting language used by every article in the knowledge base. The table below covers the Markdown constructs that recur in knowledge base articles.
| Construct | Markdown syntax | Used for |
|---|---|---|
| Heading level 1 | # Title | Article title only |
| Heading level 2 | ## Section Title | Major sections |
| Heading level 3 | ### Subsection Title | Subsections, FAQ entries |
| Bold text | **bold** | Emphasis |
| Italic text | *italic* | Book titles, mild emphasis |
| Inline code | `code` | File names, field names, enum values |
| Bullet list | - Item on each line | Lists |
| Numbered list | 1. Item on each line | Procedural steps |
| Table | Rows of | cell | cell | with |\-\-\-| separator | Field references, diagnostics, comparisons |
| Internal link | [Link Text](/getting-started/what-is-unturned) | Cross-references to other articles |
| External link | [Link Text](https://full-url) | Links to external sites |
| Image |  | Image placeholders |
| Blockquote | > Quoted text | Source attribution, scope disclaimers |
| Code block (fenced) | ``` before and after | Complete .dat file examples, ASCII diagrams |
Appendix C: Common submission errors and how to avoid them
| Error | Detection | Prevention |
|---|---|---|
| Missing FAQ section | Count ### headings before submission | The voice contract skeleton requires at least 5 FAQ entries with question marks in headings |
| Em dash in prose | Search for Unicode em dash character in text editor | Replace with plain hyphen |
| Broken internal link | Click every link in the article before submitting | Links must be root-relative, lowercase, hyphenated, no .md extension |
| Incorrect frontmatter format | Check the title field for Format A vs Format B suffix | Format A uses bare title; Format B appends " | 57 Studios Modding KB" |
| Article under 500 lines | Run Get-Content article.md | Measure-Object -Line in PowerShell | Expand with worked examples, FAQ entries, diagrams, diagnostic tables, appendices |
| Individual name in document history | Check the Author column in the document history table | The Author column is always "57 Studios" |
| Missing image placeholder | Check for the  line in the article body | Every article must have an image placeholder after the opening prose |
| Missing document history table | Check for the ## Document history section | Every article must have a document history table with Version, Date, Author, and Notes columns |
Caliber used instead of Caliber_Reference in magazine article | Verify field names against the source documentation | Never invent or guess field names; open the source evidence and copy the exact field name |
Appendix D: External references
| Resource | URL | Notes |
|---|---|---|
| 57 Studios Modding Knowledge Base repository | https://github.com/smartlydressedgames/57studios-wiki | The GitHub repository containing all article source files |
| VOICE-CONTRACT.md | https://github.com/smartlydressedgames/57studios-wiki/blob/main/.wikigen/VOICE-CONTRACT.md | The binding article-writing standards document |
| Smartly Dressed Games modding documentation | https://docs.smartlydressedgames.com/en/stable/ | Official SDG field and system reference |
| Unturned on Steam | https://store.steampowered.com/app/304930/Unturned/ | Game page and community hub |
| GitHub documentation | https://docs.github.com/en | Official GitHub documentation for pull requests, forks, and repository management |
| 57 Studios Modding Knowledge Base | https://docs.57studios.net/ | The live published knowledge base |
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-26 | 57 Studios | Initial publication. Covers contribution philosophy, article standards, submission process, editorial review, and contributor best practices. |
Cross-references
- Offline Downloads, the previous article in this section; documents offline documentation access.
- What is a File?, the foundational file-system article that establishes the concepts used throughout the knowledge base.
- How to Create a Steam Account, the first article in the next section; begins the Steam toolchain setup.
- VOICE-CONTRACT.md, the binding article-writing standards document referenced throughout this article.
- Smartly Dressed Games modding documentation, the official SDG documentation that every reference article cites.
- Unturned on Steam, the Unturned™ Steam store page.