How to Contribute to the rTS Wiki (rtech.support)

To contribute to the rTS Wiki, go to the public GitHub repository that backs the site and read the Contributing Guide before making any changes. The wiki is built with GitHub Pages, so all edits flow through the repository's workflow rather than an on-site editor. This path suits anyone who wants to fix a typo, expand a guide, or add a new page — but you should be comfortable with GitHub's fork-and-pull-request model, since the site offers no other submission route.

What the wiki is and who runs it

The rTS Wiki at rtech.support is the official documentation site for r/Techsupport, described on its homepage as "built by the community for the community." It is not a staffed product with an editorial team; it is a volunteer project. The homepage credits a long list of individual contributors — PipeItToDevNull, sealsrock12, TheKrol, Daspletosaurid, Mr-KayZ, and dozens more — as the people writing the wiki.

That matters for contributors: there is no gatekeeper to email and no submission form. Your contribution is a change to a shared repository, reviewed by the same volunteers who maintain it.

Before you start

Confirm three things so your first contribution isn't wasted effort:

• The topic fits. The wiki's highlighted content covers clean-installing Windows, dealing with malware infections, cyber hygiene with MFA, and personal backup plans. Check whether a page on your topic already exists before drafting a new one.
• You can use GitHub. The site is created via GitHub Pages, and the repository is the only editing surface. You'll need a GitHub account and a basic grasp of forks, branches, and pull requests.
• You've read the Contributing Guide. The homepage explicitly directs would-be contributors to check out the Contributing Guide first. It is the authoritative source for style, scope, and process — follow it over any general advice, including this article.

Step-by-step: making a contribution

1. Open the repository. From the rTS Wiki homepage, follow the "repository can be found here" link in the "How can I contribute?" section. This takes you to the GitHub project behind the site.
2. Read the Contributing Guide. Locate it in the repository (linked from the homepage section as well). Note any rules on page structure, tone, and what content is in or out of scope.
3. Fork the repository to your own GitHub account. This gives you a copy you can edit without affecting the live site.
4. Create a branch for your change — for example, a branch named after the page you're fixing. Keeping each contribution on its own branch makes review easier.
5. Make your edit to the relevant page file, or add a new page if the guide permits it. Match the formatting and heading conventions of existing pages so the site renders consistently.
6. Commit with a clear message describing what changed and why. A message like "Fix broken MFA setup step" tells reviewers more than "update."
7. Open a pull request against the main repository. In the description, state the problem your change solves and link any related discussion.
8. Respond to review. Maintainers may request revisions; the pull request is the conversation thread for that.

Expected result: once your pull request is merged, your change appears on the live site the next time GitHub Pages publishes the repository — the same mechanism that builds every page on rtech.support.

Common sticking points

• Editing the live site directly. There is no on-site edit button described on the homepage. If you look for one, you'll waste time; the repository is the entry point.
• Skipping the Contributing Guide. Because the project is volunteer-run, unwritten conventions matter. A technically correct edit that ignores the guide's structure may still be sent back.
• Large unsolicited rewrites. The homepage frames contributions as community writing, with named authors per area. A sweeping rewrite of someone's page is harder to review than a focused fix; start small.
• Assuming a fast turnaround. Review is done by volunteers listed on the homepage, not a support desk. Plan for your pull request to sit for a while.

Is contributing the right move for you?

The wiki's own framing is the best guide to expectations: it is written by contributors, for the community, and the Contributing Guide — not this article — is the document that governs how your work is accepted.