Community curated editions - How best to coordinate our efforts?

#8

Springer, Here I respond to your questions, however I do not want to cause a detailed discussion. A branch to a more advanced approach need not be discussed in detail here. If you want lets discuss elsewhere.

Thats fine, its a project I am working on, yet to be presented. My point is all editions should try to make clear what is involved in making them. I have done this in some editions I built. It helps when you come back to it, to improve or fix but as in my case it allows other developments or forking.

Don’t I know that!. But I already know how to deal with these clashes and it will help find them, especially of you want to add something. You can preview your resulting wiki, and if it works save it.

  • Keep in mind I am keen not to complicate this community effort to build more editions.
  • I just want us to plan to allow editions to document themself sufficiently to permit further use.

A practical example may be, lets say I use the recipes edition, but I have a cafe, so I want to add project management and advanced shopping lists, while tracking what is in stock.

  • You would go to the factory, select the recipes edition, drop projectify and other plugins on the preview, check it does not break, adjust if it does, then export your custom edition.
  • If it works well, you could then publish the delta to make your custom edition available to all.
  • Should the recipes edition be updated you can return and see if the new version is compatible with your changes. Produce your own new version and maybe even one day create an upgrade package.
  • I do have that under control, the Edition wiki only comes into existence by compiling the content into an Innerwiki. There will be no clash in the parent wiki.

Great, we are on the “same page”, That is what I intended to be understood. I am just asking we keep the idea of a manifest or simple namespace which indicates the difference between empty and the edition. An edition can then be packaged and not only available as a HTML but other futures become possible.

I can thanks, Perhaps I will start another thread. But for now here is a simple Home and Contents that creates a home tiddler, sets default tiddlers and creates a contents tab. I use this on new and other wikis all the time. It is contained within a bookmarklet tiddler for easy distribution. Home and Contents.json (2.0 KB)

  • It also serves and an example defacto approach to the default tiddlers and contents tabs, Editions would benefit from using some simple standard tiddlers like this. Reuse rather than write bespoke
1 Like
#9

@Springer (mostly)

Just to be clear, my comment in Tones’ thread about virtual fields, and the context in which it appeared, was not so much about virtual fields (or tiddlers) as about documenting TiddlyWiki code.

So, for the sake of clarity (at this stage, I think clarity is important) … the documentation looks like this:

<!--$ toc-searches
  @comments  Provides various searches of toc-tiddlers and the markup routines used
  to highlight them when found.
  <br><br>
  Primary example: <<doc-link toc-get-text-context>>.
$-->
<!-- \tiddler toc-searches() -->

<!--$ text-context-primary-filter
  @inscope foundTiddler <tiddler>
  @inscope find <text>
  @inscope show-max <number>
  @comments Returns the filter used to perform seek-text-in-context searches 
  in <<doc-link toc-tiddlers>> and related tiddlers. For context, it attempts to find 
  and return the text specified in `find` at the center of a 400 character block
  of text, though various factors (e.g. block markup and macros) can reduce the 
  actual length of the output.
  <br><br>
  <pre><code><$text text=<<text-context-primary-filter>>/></code></pre>
  <br>
  Called by <<doc-link toc-get-text-context-core>>.
  <br><br>
  This must remain a macro (`\define`) because it uses substitution.
$-->
\define text-context-primary-filter() [crazy-long-filter-no-one-cares-about]

Note the syntax “borrows” from HTML syntax for comments <!--$ ... stuff ... $-->
Note that whole tiddlers can be comment-documented using a pseudo-pragma buried in a comment:
<!-- \tiddler toc-searches() -->

And the render…

image
image928×440 28.4 KB

Frankly, I’m not sure this will aid the project just yet – except that it might offer up a “standard” to work to. Reason being: it’s in a state of flux while it’s still under developement.

#10

I will try to look at this soon. I’m a bit hampered by a flu-induced fuzzy brain, but I seem to be getting past it.

#11

The namespace protocol is very important for the key original tiddlers that make a given edition distinctive. However, I don’t think the namespace-based solution is sufficient because of two things:

(1) a solution might — and should, where appropriate — build on existing plugins already available in the community. So, my biblio demo edition will rely at least on existing refnotes and bibtex plugins, but will add further features.

(2) a solution might require some setting (such as the core setting “treat tiddler titles as links” or kookma’s utility setting to turn OFF the code-body view template (because of a conflict). Neither of these are within “my” name-space, but I would tag those setting-tiddlers, or otherwise add them to a draggable list, with appropriate commenting so that the reasons would be clear…

My current documentation for the biblio demo in progress (pared-down and streamlined for simplicity) looks like this: https://books-and-such.tiddlyhost.com/#books-and-such

I wish there were a virtual field implementation, though. I don’t like editing shadow tiddlers to add a field including my comment about its role in my solution.

All this is very much worth thinking through together!

#12

Agreed, l that why I propose a manifest. It will contain a list of titles and or filters such as [prefix[$:/community/recipes]] allowing all namespace and other tiddlers to be collected.

  • I use another method, in the $:/community/recipes tiddler I would have a package-filter field containing filters and tiddler titles that make up the solution, and if that solution creates tiddlers, I may also have a payload-filter which will be able to list the tiddlers such as recipies the user created.
  • If all community editions used the $:/community namespace where possible and have a manifest tiddler $:/community/recipes/manifest defining all tiddlers involved, including overwitten core tiddlers, config tiddlers etc… it is easy to understand and navigate.
  • You can drop the package filter in advanced search filter tab to export, delete all tiddlers if needed.
  • Good ideas, Yes perhaps a future, but I think this can be simplified and easier to read and update in its raw format.

In my own packages along with the namespaces tiddlers I have the following standard tiddlers which are transcluded into say $:/community/recipes

  • $:/community/recipes/usage
  • $:/community/recipes/releases
  • $:/community/recipes/settings or config
  • $:/community/recipes/designer-notes

Then commonly

  • $:/community/recipes/global and tagged
  • $:/community/recipes/images …
  • $:/community/recipes/stylesheet and tagged
  • $:/community/recipes/buttons …
  • …

At this point they are just a package of tiddlers but later can be mapped to plugins and plugin tabs like readme. The tree macro works with these, and plugins.

$:/plugins/community/recipies…

You get the idea?

I am not sure about the place of virtual fields, but ideally any edition or package could document the fieldname used or set by that solution.

Also when overwritting a core tiddler these should be documented, even keep a copy in the package eg $:/plugins/community/$:/core/macros/tag and allow read or reapply.

The problem is like Hearding cats, we need to quickly develop a de facto standard and not debate them too much, just start with something and look at improvements later.

#13

We are using TidGi to edit GitHub - tiddly-gittly/TiddlyWiki-Chinese-Tutorial: 中文社区共建的太微（TiddlyWiki）教程 , just put github PAT to the config, and TidGi app will auto sync to github.

But I also wondering if there is a easier approach, because many people don’t even know how to get github PAT.

Can tiddlyhost allow/only-allow multiple account to edit a wiki?

#14

Oh how nice, I see the conversation started very well. It’s already a lot more technical than I can understand, so I don’t have much to add here. :joy:

I agree.

I would also add, when building tiddlers, let’s try to keep them as readable as possible for users who want to learn by studying the community’s solutions.

You have my vote!

Wonderful!

#15

There is the great TW Documentation PR Maker by @saqimtiaz. I wonder if it is viable to adapt it to work with any GitHub-hosted TW, not just official TW docs. That is, how much of it is fine tuned to work with TW docs structure and repo, and how much is universal to handling TW on GH.
It does require having GH account and guides how to create the token, but doesn’t require much interaction or knowledge of git/GitHub apart from that.

#16

Oh, certainly. I agree with @TW_Tones that a manifest is crucial. And it should be easy to maintain.

That is not publicly available. I think you need to change a tiddlyhost setting.

I have several things on my plate, and am fighting the flu, but I will add this to my list. It does not sound overly difficult.

Yes, this!

Yeah, I keep hoping for a back-end that allows users to log in and then saves and tracks changes to shared wikis by authorized users. To my mind, it should probably save in the separate tid file format of the Node back-end, and likely auto-backup to some git instance.

I don’t think so, although I’d love to be proven wrong. @simon?

That’s a very good thought. I will check it out. I don’t use it myself, as the standard GitHub pull request is part of my usual flow both for personal projects and for my day job.

I don’t think needing a GH account and token is an overly burdensome restriction.

Yes, but as possible may end up being a large caveat when we want to take advantage of more advanced techniques. I think there are several subsidiary goals of these editions:

  • demonstrating good practices in using TW
  • showing off features of TW
  • helping the community coalesce around using tools, techniques, and plugins

But all of these pale in comparison to their main goal:

  • Providing a practical, easily-extensible edition for recipe tracking/bibliography/whatever

So, yes, keep them as clean and understandable as we can, so long as that doesn’t interfere with the primary goal.

#17

My bad! I’ve toggled the public status for my in-progress edition/demo (which is still very primitive, because I’m starting very carefully, recreating functions rather than copying from my more complex solution).

2 Likes
#18

This may be a good objective, but should not get in the way of community contributions.

  • This is a long standing issue, but there is a simple work around. Starting with a manual process on single file or tiddlyhost wiki.
  • I call it serial editors, editors have the login details but do not edit unless the recently reloaded wiki has an empty user, then set the user to indicate you are making changes. Once finished blank the user and save the wiki for other editors.
    • Changed tiddlers have the user creator/modifier in them and a custom recent view would be simple to create.
  • Other communications or agreements between editors, can also help, eg: I only edit on Odd days.
  • It may not be, but if two or more people do, they could kindly make changes as requested by a contributor not using a GitHub. It is good if we allow even naive users to contribute ideas.
#19

Of course not. The project I most want it for may get me to try my hand at it. But that will be some months at least, and quite possibly never.

It would be interesting for different editions to try out different of these techniques. If I do end up coordinating a recipe edition, I will probably use a git to handle this, allowing git users to do so directly and allowing others to email me copies of the wiki with their changes that I can then commit to git on their behalf. I’ve gotten quite used to the flexibility of git and don’t want to return to the bad old days where only one person can edit the project at a time.

But perhaps another edition might be handled the way you’re suggesting, and a third one in a different way. At some point we can see how well each has worked out.

Yes, that was my thinking as well.

#20

An approach to serial editing, the owner/contributor model.

I would think it fairly easy to make a tool you drop on a read only wiki under development, make changes, a contribution, preview and export the changes you would like applied, or the work you did to help, perhaps directly to an email attachment, as JSON within a ZIP, Or here in a thread, that you send to the “owner of the wiki”, they then load the JSON into a slightly more advanced Import wizard which allows the owner to preview the changes, or just install on a copy of the wiki to review the changes. If and only if the changes are appropriate accepts some or all changes and republish.

  • This is all possible now, except for me to find the time.
  • If handled correctly even the owner would follow a similar procedure and the proposed changes can be retained to document the releases and when changes were made.
  • Once underway we could develop this further so rejected changes can be sent back to the contributor to review and resend if appropriate.
  • Clashes are unlikely to occur, but if they do the owner can integrate them, especially if we gave the tools to do things like copy and apply changes from the difference engine rather than full tiddler replacement. Eg apply this change not that one, to a tiddler someone else changed recently.
#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.