1
0
mirror of https://github.com/Jermolene/TiddlyWiki5 synced 2024-11-26 19:47:20 +00:00
TiddlyWiki5/contributing.md

3 lines
9.1 KiB
Markdown
Raw Normal View History

2021-04-05 09:11:29 +00:00
<h1 class="">Contributing to <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki5.html">TiddlyWiki5</a></h1><p>Here we focus on contributions via <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/GitHub.html">GitHub</a> Pull Requests but there are many other ways that anyone can help the <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki.html">TiddlyWiki</a> project, such as <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/ReportingBugs.html">reporting bugs</a> or helping to <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/Improving%2520TiddlyWiki%2520Documentation.html">improve our documentation</a>.</p><h1 class="">Rules for Pull Requests</h1><p>PRs must meet these minimum requirements before they can be considered for merging:</p><ul><li>The material in the PR must be free of licensing restrictions. Which means that either:<ul><li>The author must hold the copyright in all of the material themselves</li><li>The material must be licensed under a license compatible with <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki.html">TiddlyWiki</a>'s BSD license</li></ul></li><li>The author must sign the Contributors License Agreement (see below)</li><li>Each PR should only make a single feature change</li><li>The title of the PR should be 50 characters or less</li><li>The title of the PR should be capitalised, and should not end with a period</li><li>The title of the PR should be written in the imperative mood. See below</li><li>Adequate explanation in the body of the PR for the motivation and implementation of the change. Focus on the <em>why</em> and <em>what</em>, rather than the <em>how</em></li><li>PRs must be self-contained. Although they can link to material elsewhere, everything needed to understand the intention of the PR should be included</li><li>Documentation as appropriate for end-users or developers</li><li>Observe the coding style</li><li>Read the developers documentation</li><li>Please open a consultation issue prior to investing time in making a large PR</li></ul><h2 class="">Imperative Mood for PR Titles</h2><p>The &quot;imperative mood&quot; means written as if giving a command or instruction. See <a class="tc-tiddlylink-external" href="https://chris.beams.io/posts/git-commit/#imperative" rel="noopener noreferrer" target="_blank">this post</a> for more details, but the gist is that the title of the PR should make sense when used to complete the sentence &quot;If applied, this commit will...&quot;. So for example, these are good PR titles:</p><ul><li>If applied, this commit will <em>update the contributing guidelines</em></li><li>If applied, this commit will <em>change css-escape-polyfill to a $tw.utils method</em></li><li>If applied, this commit will <em>make it easier to subclass the wikitext parser with a custom rule set</em></li></ul><p>These a poorly worded PR titles:</p><ul><li><strike>If applied, this commit will <em>edit text widgets should use default text for missing fields</em></strike></li><li><strike>If applied, this commit will <em>signing the CLA</em></strike></li><li><strike>If applied, this commit will <em>don't crash if options.event is missing</em></strike></li></ul><p>PR titles may also include a short prefix to indicate the subsystem to which they apply. For example:</p><ul><li><em>Menu plugin: Include menu text in aerial rotator</em></li></ul><h1 class="">Commenting on Pull Requests</h1><p>One of the principles of open source is that many pairs of eyes on the code can improve quality. So, we welcome comments and critiques of pending PRs. <a class="tc-tiddlylink-external" href="https://conventionalcomments.org" rel="noopener noreferrer" target="_blank">Conventional Comments</a> has some techcniques to help make comments as constructive and actionable as possible. Notably, they recommend prefixing a comment with a label to clarify the intention:</p><table><tb
</p><p><em>This file was automatically generated by <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki5.html">TiddlyWiki5</a></em>
2013-07-02 07:38:00 +00:00
</p>