<h1class="title">The Hitchhiker's Guide to Online Anonymity</h1>
</header>
<h5id="any-opinion-is-welcome.">Any opinion is welcome.</h5>
<h5id="feel-free-to-discuss-in-the-discussions-section.">Feel free to discuss in the <ahref="https://github.com/AnonyPla-ng/thgtoa/discussions">discussions</a> section.</h5>
<h5id="feel-free-report-issues-in-the-issues-section.">Feel free report issues in the <ahref="https://github.com/AnonyPla-ng/thgtoa/issues">issues</a> section.</h5>
<h4id="there-are-multiple-ways-you-can-add-to-the-guide">There are multiple ways you can add to the guide:</h4>
<ul>
<li>You can <ahref="https://github.com/AnonyPla-ng/thgtoa/issues/new">submit bugs and feature requests</a> with detailed information about your issue or idea:
<ul>
<li>If you’d like to propose an addition, please follow the standards outlined here.</li>
<li>If you’re reporting an issue, please be sure to include the expected behaviour, the observed behaviour, and steps to reproduce the problem.</li>
</ul></li>
<li>This can require technical knowledge, but you can also get involved in conversations about bug reports and feature requests. This is a great way to get involved without getting too overwhelmed!</li>
<li><ahref="https://github.com/AnonyPla-ng/thgtoa/pulls">Help fellow committers test recently submitted pull requests</a>. Simply by pulling down a pull request and testing it, you can help ensure our new code contributions for stability and quality.</li>
<p>For those of you who are looking to add content to the guide, include the following:</p>
<h5id="pull-requests"><u>Pull Requests</u></h5>
<ul>
<li><strong>Do</strong> create a <ahref="http://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches">topic branch</a> to work on instead of working directly on <code>master</code>. This helps to:
<ul>
<li>Protect the process.</li>
<li>Ensures users are aware of commits on the branch being considered for merge.</li>
<li>Allows for a location for more commits to be offered without mingling with other contributor changes.</li>
<li>Allows contributors to make progress while a PR is still being reviewed.</li>
</ul></li>
<li><strong>Do</strong> follow the <ahref="http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html">50/72 rule</a> for Git commit messages.</li>
<li><strong>Do</strong> write “WIP” on your PR and/or open a <ahref="https://help.github.com/en/articles/about-pull-requests#draft-pull-requests">draft PR</a> if submitting unfinished changes..</li>
<li><strong>Do</strong> make sure the title of a draft PR makes it immediately clear that it’s a draft</li>
<li><strong>Do</strong> target your pull request to the <strong>master branch</strong>.</li>
<li><strong>Do</strong> specify a descriptive title to make searching for your pull request easier.</li>
<li><strong>Don’t</strong> leave your pull request description blank.</li>
<li><strong>Don’t</strong> abandon your pull request. Being responsive helps us land your changes faster.</li>
<li><strong>Don’t</strong> post questions in older closed PRs.</li>
<li><strong>Do</strong> stick to the guide to find common style issues.</li>
</ul>
<p>When reporting guide issues:</p>
<ul>
<li><strong>Do</strong> write a detailed description of your issue and use a descriptive title.</li>
<li><strong>Do</strong> make it as detailed as possible and don’t just submit 50 line changes without explaining.</li>
<li><strong>Don’t</strong> file duplicate reports; search for your bug before filing a new report.</li>
<li><strong>Don’t</strong> attempt to report issues on a closed PR.</li>
<p>Please split large sets of changes into multiple PRs. For example, a PR that adds Windows 11 support, removes Windows AME references, and fixes typos can be split into 3 PRs. This makes PRs easier to review prior to merging.</p>
