Add PR template for further automation

Learn from https://github.com/CleverRaven/Cataclysm-DDA/blob/master/.github/pull_request_template.md

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -6,20 +6,61 @@ labels: ''
 assignees: ''
 
 ---
+<!-- HOW TO USE: Under each "#### Heading" below, enter information relevant to your pull request.
+Leave the headings unless they don't apply to your PR.
 
-**Is your PR related to a problem? Please describe.**
-A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+Please read carefully and don't delete the comments delimited by "< !--" and "-- >"
+Once a pull request is submitted, automatic stylistic and consistency checks will be performed on the PR's changes.
+The results of these can be either seen under the "Files changed" section of a PR or in the check's details.
 
-**Describe the solution you are proposing**
-A clear and concise description of the changes you are proposing. Include images to show visual changes.
+NOTE: Please grant permission for repository maintainers to edit your PR.  It is common for PRs to be held up due to trivial changes being requested and the author being unavailable to make them. -->
 
-**Describe alternatives you've considered**
-A clear and concise description of any alternative solutions or features you've considered.
+## Summary
 
-**Additional context**
-Add any other context or screenshots about the feature request here.
+Category type "Brief description"
+<!-- This section should consist of exactly one line, edit the one above.
 
-If you link to discussions elsewhere then please copy and paste the important text, and don't expect readers to scan the entire discussion to find the relevant part.
+1. Replace the word "Category" with one of these words: Usability, Widget, Filter, Hackability, Document, Plugin, Server, Performance, Infrastructure, Translation, Accessibility, Theme.
+2. Replace the word "type" with one of these words: added, modified, fixed, extended, updated, improved, renamed, removed, hide.
+3. Replace the text inside the quotes with a brief description of your changes.
+Or if you don't want a changelog entry, replace the whole line with just the word "None" (with no quotes).
+
+This is checked by .github/workflows/pr-validator.yml automatically
+For more on the meaning of each category, see:
+https://tiddlywiki.com/dev/#Pull%20request%20for%20TiddlyWiki
+If approved and merged, your summary will be added to the project release notes:
+https://tiddlywiki.com/#Releases
+
+An example:
+
+## Summary
+
+Widget fixed "incorrect behaviour of default values with lookup Operator"
+
+-->
+
+## Is your PR related to a problem? Please describe
+
+<!-- With a few sentences, describe your reasons for making this change. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...].
+If it relates to an existing issue, you can link it with a # followed by the GitHub issue number, like #1234.  If your pull request *fully* resolves an issue, include the word "Fix" or "Fixes" before the issue number, like: Fixes #xxxx
+If there is no related issue, explain here what issue, feature, or other concern you are addressing.  If this is a bugfix, include steps to reproduce the original bug, so your fix can be verified. -->
+
+## Describe the solution
+
+<!-- A clear and concise description of the changes you are proposing. Include images to show visual changes. How does the feature work, or how does this fix a bug?  The easier you make your solution to understand, the faster it can get merged.  -->
+
+## Describe alternatives you've considered
+
+<!-- A clear and concise description of any alternative solutions or features you've considered. -->
+
+## Testing
+
+<!-- Describe what steps you took to test that this PR resolved the bug or added the feature, and what tests you performed to make sure it didn't cause any regressions.  Also include testing suggestions for reviewers and maintainers. -->
+
+## Additional context
+
+<!-- Add any other context (such as mock-ups, proof of concepts or screenshots) about the feature or bugfix here.
+If you link to discussions elsewhere then please copy and paste the important text, and don't expect readers to scan the entire discussion to find the relevant part.-->
 
 ## Checklist before requesting a review
 

.github/workflows/pr-validator.yml

@@ -0,0 +1,16 @@
+name: PR Validator
+on:
+  pull_request:
+    branches:
+    - master
+    types: [opened, edited, synchronize]
+jobs:
+  validate:
+    name: Validate PR
+    runs-on: ubuntu-latest
+    steps:
+      - name: "Validate SUMMARY"
+        uses: CleverRaven/pr-validator@master
+        with:
+          description-regex: '(\n|^)## Summary\s+`{0,3}(SUMMARY:\s+)?(None|((Usability|Widget|Filter|Hackability|Document|Plugin|Server|Performance|Infrastructure|Translation|Accessibility|Theme) +(added|modified|fixed|extended|updated|improved|renamed|removed|hide) +"(.+)"))`{0,3}\s*(\n|$)'
+          description-regex-flags: 'i'

editions/dev/tiddlers/build/Pull request for TiddlyWiki.tid

@@ -0,0 +1,107 @@
+title: Pull request for TiddlyWiki
+
+!! Changelog categories
+
+These are the categories used by Pull Request Summary lines as outlined in the [ext[PR Template|https://github.com/Jermolene/TiddlyWiki5/blob/master/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md]]
+In the end, it's up to the author to decide where ''they'' want their change to be listed, these are only guidelines, not rules.
+
+!!! None
+
+Please consider a summary of "SUMMARY: None" for minor additions, fixes, and documentation changes. There are far too many changes made to the core to feature anything approaching all of them in the changelog. (Do not add any description in quotes - e.g., SUMMARY: None "whatever" - after a summary of "None".)
+
+!!! Usability
+
+Adding new functionality to the wiki is a feature. These will generally be edits to the JS code in the core, though new wikitext may be involved as well.
+
+!!! Widget
+
+Make changes to core widgets, to support new attributes or improve performances.
+
+!!! Filter
+
+Add new core filters, or improve existing ones to support new parameters.
+
+!!! Hackability
+
+Usually this means extends what is capable to do within a community plugin. Or refactor the wikitext to make it easier to read and modify by the community.
+
+!!! Document
+
+Improving documents in editions/ folder.
+
+!!! Plugin
+
+If a change is either contained within an official plugin, it goes in this category.
+
+!!! Server
+
+Client-server improvements, or changes to the server code itself, including new command line options.
+
+!!! Performance
+
+When there's no functional change at all except for less execution time, it's performance.
+
+These will almost always happen in JS code.
+
+!!! Infrastructure
+
+These are changes for programmers, by programmers.
+Most users will never even know these happened, but they'll appreciate the improved stability and features that this kind of things enables.
+
+All manner of refactor and overhaul oriented at making the wiki easier to work on, and improvements to developer experiences fit in this category.
+
+These will frequently be JS changes, but wikitext reorganization also fits, as does development of tools that run outside the wiki.
+
+!!! Translation
+
+We want everyone to enjoy TiddlyWiki, so we do translations.
+
+Changes oriented at letting everyone use TiddlyWiki no matter what their language go here.
+
+!!! Accessibility
+
+Make wiki accessible to users without colour vision, or with other disabilities.
+
+!!! Theme
+
+About theme and palette.
+
+!! Change types
+
+!!! added
+
+This is for major new features, new plugins, new filters, new commands, new wikitext, new anything.
+
+!!! modified
+
+This might be breaking changes that will require users to update their wikis, or 
+
+!!! fixed
+
+If it was broken before, and it isn't anymore, that's a bugfix.
+
+This applies equally to JS and WikiText changes.
+
+!!! extended
+
+Add minor new features to existing plugins, filters, commands, wikitext, etc.
+
+!!! updated
+
+Update a dependency or resource to a newer version.
+
+!!! improved
+
+It might be a change to the way something works, that doesn't break anything. Only makes it works better.
+
+!!! renamed
+
+Simply change the name of widget, macro, or concept in the documentation.
+
+!!! removed
+
+This feature is not exist anymore.
+
+!!! hide
+
+This feature is still exist, but it's hidden from the user interface.