Edit documentation in TW and use Github API to create PRs directly?

[saqimtiaz]

Hi @Mark_S thank you for the considered thoughts, very helpful.

Note that I have updated the demo this morning with a few changes:

Demo: updating docs and creating a PR from within TiddlyWiki

I have pushed through some quick changes, hopefully I haven’t broken anything. I have been spending time on this that I really do not have to spare at present, so it is my hope that others will chip in to get this to a state where it is usable. The code itself is very concise and not complex. Changes: Disable “Make a PR” button and show an error message if the tiddler titles entered do not correspond to real tiddlers. Primary concern here is someone forgetting brackets around a title with s…

@Mark_S

I feel like this is usable as is, solving the problem of multiple tiddlers, viewing the tiddler as edited, and eliminating the need for a local repository. For experienced users like Pmario it may be limiting, but for everyone else it’s a door-opener. Among other things, it means you can be at any computer, maybe even a tablet or phone, when you submit changes.

I think the primary obstacle is going to be when someone submits a PR and gets asked to correct something minor before it can be merged. Without delving into the Github UI there will be no way to easily update the PR that they have created. But otherwise I agree, this should already be a step forwards.

@Mark_S

I’m not sure what interface improvements would make it qualitatively better. Dragging and dropping your tiddlers from the “Recent Tiddlers” tab is pretty easy for anyone who’s at the level of someone who is interested in doing this.

The main concern I had was users forgetting brackets around tiddler titles with spaces and thus creating broken PRs. I have introduced some wikitext handling to prevent this.

@Mark_S

The main thing missing from the UI might be a way to add paths for new tiddlers. I’m thinking they could be inserted into “$:/config/OriginalTiddlerPaths” ?

@pmario and I discussed this in either this thread or the one with the demo. Even on node.js there is nothing to guide where new tiddlers go in the directory structure. What would be helpful here both for this work and for updating docs via node.js is a $:/config/FileSystemPaths tiddler for the tw-com edition.

Adding new tiddler paths to “$:/config/OriginalTiddlerPaths” doesn’t help much if all new tiddlers are just being added to the root of the tiddlers directory. I would rather users don’t have to decide where the tiddlers go and it can be calculated from the $:/config/FileSystemPaths tiddler.

@Mark_S

Maybe also instructions to the user to refresh their fork if it’s been awhile since submitting updates. Though I’m not sure if that’s even necessary if the source tiddlers are coming from tiddlywiki. com.

Right. I think the real issue is figuring out the user story. Is this installed on TiddlyWiki.com? or at a different URL that we link to from tw-com and which mirrors it but also adds the plugin? What if the user is working on larger changes and wants to save changes during their work (download saver?). Figuring out a recommended process and documenting would probably help those less familiar with working with TiddlyWiki.

@Mark_S

The plugin only allows the creation of PR’s. One way around this limitation would be to have a convention where fix-it PR’s could be submitted with prefix “Supercedes PR#xxxx” . Then whoever is doing the pull could know to skip the prior PR request. This is operating on the theory that most of the time the first PR is good enough.

Yes that kind of thing can work. What would be needed is a way for them to continue where they left off with their changes. Do we assume that the user has saved the file in which they made changes? If we had the ability to generate TiddlyWiki files from PRs that could help (and is possible via Github Actions). They could take the file from their previous PR and use that as a starting point for revising.