<h5id="feel-free-to-discuss-in-the-discussions-section.">Feel free to discuss in the <ahref="https://github.com/Anon-Planet/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/Anon-Planet/thgtoa/issues">issues</a> section.</h5>
<li>You can <ahref="https://github.com/Anon-Planet/thgtoa/issues/new">submit bugs and feature requests</a> with detailed information about your issue or idea:
<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/Anon-Planet/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>
<li><strong>Don’t</strong> make mass changes (such as replacing “I” with “we”) using automated serach/replace functionality.
<ul>
<li>Search/replace doesn’t understand context, and as such, will inevitably cause inconsistencies and make the guide harder to read.</li>
<li>If it’s part of a larger PR, it’ll also make the reviewer’s life harder, as they’ll have to go through manually and undo everything by hand.</li>
<li><em>If you’re going to make mass changes, take the time to do it properly</em>. Otherwise I’ll just have to undo it anyway.</li>
<li>If your change contains backslashes (<code>\</code>), either escape them with another backslash (<code>\\</code>) or put them in a <code>code block</code>.</li>
<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>
</ul>
<h3id="large-prs">Large PRs</h3>
<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>
<p>For an example of what <em>not</em> to do, see: <ahref="https://github.com/Anon-Planet/thgtoa/pull/51"class="uri">https://github.com/Anon-Planet/thgtoa/pull/51</a>. This PR contains enough changes to split into multiple smaller and individually-reviewable PRs.</p>
<h3id="updating-prs">Updating PRs</h3>
<p>While a PR is being reviewed, modifications may be made to it by the reviewer prior to merging. If this is the case, a new branch will be created for the PR’s review. If you would like to submit a change to a PR that is in the process of being reviewed, <em>do not update the PR directly</em>. This will only cause merge conflicts and delay the PR from being merged. Instead, submit your changes to the PR’s review branch.</p>
<p>For an example of what <em>not</em> to do, see: <ahref="https://github.com/Anon-Planet/thgtoa/pull/51"class="uri">https://github.com/Anon-Planet/thgtoa/pull/51</a>. Instead of submitting changes to the PR directly, they should have been submitted as changes to the <ahref="https://github.com/NobodySpecial256/thgtoa/tree/pr/51">PR’s associated review branch</a>.</p>
<hr/>
<p><strong>Thank you</strong> for taking the few moments to read this far! You’re already way ahead of the curve, so keep it up!</p>
