TiddlyWiki5/contributing.md

<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>Any visual changes introduced by the PR should be noted and illustrated with before/after screenshots</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 "imperative mood" 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 "If applied, this commit will...". 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 techniques 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><tbody><tr class="evenRow"><td align="left">praise</td><td align="left">Praises highlight something positive. Try to leave at least one of these comments per review. Do not leave false praise (which can actually be damaging). Do look for something to sincerely praise</td></tr><tr class="oddRow"><td align="left">nitpick</td><td align="left">Nitpicks are small, trivial, but necessary changes. Distinguishing nitpick comments significantly helps direct the reader's attention to comments requiring more involvement</td></tr><tr class="evenRow"><td align="left">suggestion</td><td align="left">Suggestions are specific requests to improve the subject under review. It is assumed that we all want to do what's best, so these comments are never dismissed as “mere suggestions”, but are taken seriously</td></tr><tr class="oddRow"><td align="left">issue</td><td align="left">Issues represent user-facing problems. If possible, it's great to follow this kind of comment with a suggestion</td></tr><tr class="evenRow"><td align="left">question</td><td align="left">Questions are appropriate if you have a potential concern but are not quite sure if it's relevant or not. Asking the author for clarification or investigation can lead to a quick resolution</td></tr><tr class="oddRow"><td align="left">thought</td><td align="left">Thoughts represent an idea that popped up from reviewing. These comments are non-blocking by nature, but they are extremely valuable and can lead to more focused initiatives and mentoring opportunities</td></tr><tr class="evenRow"><td align="left">chore</td><td align="left">Chores are simple tasks that must be done before the subject can be “officially” accepted. Usually, these comments reference some common process. Try to leave a link to the process description so that the reader knows how to resolve the chore</td></tr></tbody></table><h1 class="">Contributor License Agreement</h1><p>Like other <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/OpenSource.html">OpenSource</a> projects, <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki5.html">TiddlyWiki5</a> needs a signed contributor license agreement from individual contributors. This is a legal agreement that allows contributors to assert that they own the copyright of their contribution, and that they agree to license it to the <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/UnaMesa.html">UnaMesa</a> Association (the legal entity that owns <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki.html">TiddlyWiki</a> on behalf of the community).</p><ul><li>For individuals use: <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-individual.md" rel="noopener noreferrer" target="_blank">licenses/CLA-individual</a></li><li>For entities use: <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-entity.md" rel="noopener noreferrer" target="_blank">licenses/CLA-entity</a></li></ul><h1 class="">How to sign the CLA</h1><p>Create a <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/GitHub.html">GitHub</a> pull request to add your name to <code>cla-individual.md</code> or <code>cla-entity.md</code>, with the date in the format (YYYY/MM/DD).</p><p><strong>step by step</strong></p><ol><li>Navigate to <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-individual.md" rel="noopener noreferrer" target="_blank">licenses/CLA-individual</a> or <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-entity.md" rel="noopener noreferrer" target="_blank">licenses/CLA-entity</a> according to whether you are signing as an individual or representative of an organisation</li><li>Ensure that the "branch" dropdown at the top left is set to <code>tiddlywiki-com</code></li><li>Click the "edit" button at the top-right corner (clicking this button will fork the project so you can edit the file)</li><li>Add your name at the bottom<ul><li>eg: <code>Jeremy Ruston, @Jermolene, 2011/11/22</code></li></ul></li><li>Below the edit box for the CLA text you should see a box labelled <strong>Propose file change</strong></li><li>Enter a brief title to explain the change (eg, "Signing the CLA")</li><li>Click the green button labelled <strong>Propose file change</strong></li><li>On the following screen, click the green button labelled <strong>Create pull request</strong></li></ol><hr><p><em>The CLA documents used for this project were created using <a class="tc-tiddlylink-external" href="http://www.harmonyagreements.org" rel="noopener noreferrer" target="_blank">Harmony Project Templates</a>. "HA-CLA-I-LIST Version 1.0" for "CLA-individual" and "HA-CLA-E-LIST Version 1.0" for "CLA-entity".</em>
</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>
</p>
	<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>Any visual changes introduced by the PR should be noted and illustrated with before/after screenshots</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 "imperative mood" 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 "If applied, this commit will...". 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 techniques 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><tbody><tr class="evenRow"><td align="left">praise</td><td align="left">Praises highlight something positive. Try to leave at least one of these comments per review. Do not leave false praise (which can actually be damaging). Do look for something to sincerely praise</td></tr><tr class="oddRow"><td align="left">nitpick</td><td align="left">Nitpicks are small, trivial, but necessary changes. Distinguishing nitpick comments significantly helps direct the reader's attention to comments requiring more involvement</td></tr><tr class="evenRow"><td align="left">suggestion</td><td align="left">Suggestions are specific requests to improve the subject under review. It is assumed that we all want to do what's best, so these comments are never dismissed as “mere suggestions”, but are taken seriously</td></tr><tr class="oddRow"><td align="left">issue</td><td align="left">Issues represent user-facing problems. If possible, it's great to follow this kind of comment with a suggestion</td></tr><tr class="evenRow"><td align="left">question</td><td align="left">Questions are appropriate if you have a potential concern but are not quite sure if it's relevant or not. Asking the author for clarification or investigation can lead to a quick resolution</td></tr><tr class="oddRow"><td align="left">thought</td><td align="left">Thoughts represent an idea that popped up from reviewing. These comments are non-blocking by nature, but they are extremely valuable and can lead to more focused initiatives and mentoring opportunities</td></tr><tr class="evenRow"><td align="left">chore</td><td align="left">Chores are simple tasks that must be done before the subject can be “officially” accepted. Usually, these comments reference some common process. Try to leave a link to the process description so that the reader knows how to resolve the chore</td></tr></tbody></table><h1 class="">Contributor License Agreement</h1><p>Like other <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/OpenSource.html">OpenSource</a> projects, <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki5.html">TiddlyWiki5</a> needs a signed contributor license agreement from individual contributors. This is a legal agreement that allows contributors to assert that they own the copyright of their contribution, and that they agree to license it to the <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/UnaMesa.html">UnaMesa</a> Association (the legal entity that owns <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/TiddlyWiki.html">TiddlyWiki</a> on behalf of the community).</p><ul><li>For individuals use: <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-individual.md" rel="noopener noreferrer" target="_blank">licenses/CLA-individual</a></li><li>For entities use: <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-entity.md" rel="noopener noreferrer" target="_blank">licenses/CLA-entity</a></li></ul><h1 class="">How to sign the CLA</h1><p>Create a <a class="tc-tiddlylink tc-tiddlylink-resolves" href="https://tiddlywiki.com/static/GitHub.html">GitHub</a> pull request to add your name to <code>cla-individual.md</code> or <code>cla-entity.md</code>, with the date in the format (YYYY/MM/DD).</p><p><strong>step by step</strong></p><ol><li>Navigate to <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-individual.md" rel="noopener noreferrer" target="_blank">licenses/CLA-individual</a> or <a class="tc-tiddlylink-external" href="https://github.com/TiddlyWiki/TiddlyWiki5/tree/tiddlywiki-com/licenses/cla-entity.md" rel="noopener noreferrer" target="_blank">licenses/CLA-entity</a> according to whether you are signing as an individual or representative of an organisation</li><li>Ensure that the "branch" dropdown at the top left is set to <code>tiddlywiki-com</code></li><li>Click the "edit" button at the top-right corner (clicking this button will fork the project so you can edit the file)</li><li>Add your name at the bottom<ul><li>eg: <code>Jeremy Ruston, @Jermolene, 2011/11/22</code></li></ul></li><li>Below the edit box for the CLA text you should see a box labelled <strong>Propose file change</strong></li><li>Enter a brief title to explain the change (eg, "Signing the CLA")</li><li>Click the green button labelled <strong>Propose file change</strong></li><li>On the following screen, click the green button labelled <strong>Create pull request</strong></li></ol><hr><p><em>The CLA documents used for this project were created using <a class="tc-tiddlylink-external" href="http://www.harmonyagreements.org" rel="noopener noreferrer" target="_blank">Harmony Project Templates</a>. "HA-CLA-I-LIST Version 1.0" for "CLA-individual" and "HA-CLA-E-LIST Version 1.0" for "CLA-entity".</em>
	`</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>`
	`</p>`