Community curated editions - How best to coordinate our efforts?

#21

I was thinking something related, but using a whole wiki. While I did think about such an extract, I don’t know how to create it. And since for me, this would be layered atop git, the whole wiki will likely be easier to integrate. But it’s a very similar workflow.

An interesting question: let’s say I create a new version (1), and you and @SnapSam each take a copy to work on, but hers is quicker, and she submits (2), which gets posted and @Springer picks it up to make additional changes. Then in quick succession, you submit (3) and @Springer submits (4). How do you track which version to update? I have some ideas of incorporating git hashes into the wiki, but it’s not entirely clear yet. Have you considered scenarios like this?

#22

Yes, although this scenario should be uncommon if there is a coordinated effort, the owner will need to resolve it. Idealy if someone is introducing code or modifying code shared with others, this is completed before the next change.

  • just looking at my own incremental changes to code, very few are of the kind that cant be modulised.
#23

This is probably worth its own thread, but I would be really interested in hearing your ideas on this!

#24

FYI: I think it easier to capture and manage changes to a reference wiki, than between separate wikis. Although what you suggest could be given tools to make it work, it is possibly easier to manage it through JSON packages of “changed tiddlers” tiddlers.

  • To delete or rename a tiddler, if replaced, may need a manual request to the owner.
1 Like
#25

Let’s keep it here. It could very well be useful to others trying to coordinate an edition.

I haven’t tried it yet, but I’ll get to it this coming week. The idea is that in a build step, before calling tiddliwiki --build, I grab the latest git reference (commit hash, tag) and store it in a tiddler under some system name.

Then, for those who are not working directly with git, but passing back wikis to merge, I can find at a glance what commit theirs was forked from, and I don’t need to try to dig that out.

I don’t remember a specific command to get the git commit hash, but I’m sure it exists, and there’s probably some GH action that will copy over a sample tiddler, replacing a placeholder token with the git commit/tag.

So, clearly it’s not something sophisticated, just a way to make it easier to take a non-git input and hook it back into the git world.

#26

The build script for the prerelease does this. See:

The streams pre-release build script does something similar:

This prior discussion about creating and maintaining editions may also be of interest:

I have been maintaining two editions for a small group of users for about four years now and the strategy of thinking of an edition as a set of plugins (some bespoke for the edition) is continuing to serve me well in terms of maintenance and pushing out updates, as well as making attempts at customization for end users easier.

#27

Ah, thank you. I hadn’t gone to look; it does seem an obvious thing to want. But not I have a model for the tiddler to generate. Thanks.

Thank you. I’ll take a look.

I was assuming that I would eventually put the important stuff in plugins. But I will probably do initial development in the main workspace; it’s simpler to work with.