I have pushed a couple of quick changes:
An experiment with tracking new and modified tiddlers and automatically adding them to the PR. 
A new optional drag and drop interface instead of the textarea for entering the tiddler titles of tiddlers to include in the PR. Click the button in the top right to revert to a textarea. 
The error probably got introduced (Hi! I’m an error!) when dragging and dropping. I found I had to enter the field each time and put a space after each entry or the dragon-drop wouldn’t work on the next one. Hopefully your new drop-box will help avoid this problem.
Thanks!
Note that there seems to be an issue when creating a PR for _canonical_uri tiddlers with this approach, see Add tag Demonstration to related tiddlers by Marxsal · Pull Request #6213 · Jermolene/TiddlyWiki5 · GitHub
Please refrain from doing so until I get the chance to investigate, which may not be until later in the week.
The issue with tiddler types other than text/vnd.tiddlywiki should now be resolved. Note however that it is not possible to edit multids via the wiki (or via node.js).
The demo has been updated with improvements to the instructions and an option to export the tiddlers changed and submitted in the PR, thanks to a PR by @pmario
I have been contemplating the utility of a wizard that guides new users through setting up their Github access token and making their first PR. However, I am unsure as to how worthwhile the effort would be given that the demo is already very usable but uptake is absent.
I’m almost finished with my video series. … It took a bit longer than I wanted.
Adding and editing Captions needs way too much time in the youtube web UI
It covers those topics
I’m at the last video atm.
Apologies. Tested. Works. Thank you.
Should I send it again now to Official?
We can. Do we want to leave it at its current URL or do we want to deploy it a more official location?
I have been considering packaging it as a Commons plugin and having a Commons repository where it and other Commons plugins live. This would allow others to contribute to it directly (like Mark and Mario) without me being the bottleneck.
Or we could set up a TiddlyWiki Commons organization which could also allow for individual Commons repositories within it. I have not given this part a lot of thought so input is welcome.
It would also be nice to set up a Github action in the Tiddlywiki5 repository that on changes to the tiddlywiki-com branch, triggered an update to the PR mechanism. Currently it is on a timer (cron).
The videos are online: See the Intro thread here at TT: Use TiddlyWiki to Contribute to the TiddlyWiki Documentation
have fun!
Should we remove the ability to create PRs against the test repo?
Part of the problem is that the test repo is not up to date so the PR created is inaccurate as a preview of what the real PR diff would look like. Alternatively we could look into a mechanism to keep that fork up to date automatically.
I think, for the time being it should be an option. So users can create “throw away” test pull requests. … It may give them a bit more confidence.
At the moment I would prefer this option
See https://github.com/wei/pull
Install the GitHub app and I think the default settings will auto merge upstream changes to main/master https://github.com/apps/pull
Thank you @boris. Unfortunately that only creates a PR to merge master into the fork, which would require that I log into another account and merge those PRs.
I could setup a Github workflow to automatically merge those PRs, but that at point I may as well skip the app and just pull upstream master directly.
The default config merges automatically. If you give my bmann account permissions I can help set it up and/or do a test config on another fork.
@boris I have added you to the fork as a collaborator. Thank you!
It created the PR but did not merge it earlier. I just re-created the fork so let us see if that helps. However even apart from that, I do think we need a custom config as we need to keep the tiddlywiki-com branch updated (and not master).
A few thoughts for the future to follow. Though I am currently reluctant to make any changes since @pmario has put in a lot of time and effort into recording walkthrough videos, I felt it worthwhile to get this written down for potential future reference.
We could make the generation of the PR backup easier/automatic so that it becomes more of an implicit thing rather than something the user needs to do as a separate step. One easy win would be to change the export button to directly download the PR info as a JSON file rather than having to go via Advanced Search:
<$action-sendmessage
$message="tm-download-file"
$param="$:/core/templates/exporters/JsonFile"
exportFilter="[[$:/temp/pr-tiddlers]get[text]enlist-input[]] [[$:/temp/pr-tiddlers]get[text]enlist-input[]addprefix[$:/temp/prpath-]] [prefix[$:/temp/pr-]] [prefix[$:/config/sq/makepr/]]"
filename="pr.json"
/>
If we wanted to, we could take it a step further and automatically trigger the backup via the same button that creates the PR. Potentially we could also include in the json a tiddler with a link to the PR on Github and name the JSON file after the PR.
Another idea for the future would be to detect whether the Github PAT has been saved in local storage and only if not, show a modal that shows information on setting up a Github account and PAT.
Yea, I would love that. … I needed a backup function, since I thought it would be important, if the need to create a second PR with some changes arises. …
AdvancedSearch was the obvious place for me. Especially during testing, so I could easily change the elements that needed to be added or removed …
So once we exactly know what we want to store in the backup a 1-click solution will definitely be superior. …
I also think we may be able to automatically create a JSON filename, that matches the pr-name at GH. So the filename will be unique and has a direct relation to the PR.