Discussion of the first attempt to build a community-curated edition (a “recipie list” edition): Community curated edition: “Recipe list” edition
How do you think we should coordinate to compile a community curated edition?
…Are there ways to work on a shared wiki? Or are there other simpler ways to proceed? Etc.
Make your reflections and ask your questions here.
I know that people have been working on these, but I really don’t know if there are any tools—outside Jeremy’s commercial offering—that are actually ready now. I’ve several times wanted them, and would like to take a swing at it one one day. But my knowledge isn’t there yet for such an undertaking.
Failing that, the next best thing is probably also not possible. If we had a group of software developers, then I would suggest using Node and Git and contributing to a shared repository, with automated builds for every commit, served up over GitHub pages or some such. But the group of likely committers varies too widely in their skills with such tools, and we certainly don’t want to preclude useful contributions because the contributor isn’t buried head-deep in developer tooling.
That seems to leave us with some manual process. People make their own minor tweaks or major overhauls to the current version, then submit them back to one coordinator to merge them together and repost as the latest version. It’s a bit of an ugly process, but I’m afraid it might be the best we can hope for.
I am willing to try being the coordinator for a recipe edition, if people would like me to do it. Note that this is not an editorial role, only a logistics one. Decisions would be made in conversations here. They would get promoted to the latest version by the coordinator. Note that if I do take this on, I will do so atop git. And I would probably open it up for others to contribute through git processes, and would simply serve as in intermediary for those who don’t do git.
Similar to the offer made by @Scott_Sauyet, I’m willing to be the point-person for compiling a bibliographic “curated edition” that includes bibtex and refnotes plugins, as well as other fields and templates, populated by a sample variety of titles, excerpts, etc., to make for a helpful tour.
If, as you curate a working wiki edition, you can isolate all the components that make up that edition and share those components, like the idea of a manifest. I am prepared to add such editions to a factory wiki, where the user can dial on demand an edition. Although the idea would be to still maintain a separate “source of truth” maintained by a curator.
Whether or not you see the value in what I propose, I think it important when building an edition not to loose sight of the components, settings, plugins and tiddlers involved in building the edition. Not only does it help document, but also assist maintenance and give people insight if they want to integrate editions or additional features into an edition.
I am happy to take on the curation of one or more editions myself and will do so based on community needs, but I plan to use my factory to make this as smooth as possible.
Minor technical challenge;
I have a lot of useful solutions as bookmarklets, is there a way to apply bookmarklets to an innerwiki in an iframe? I will raise a separate topic for this.
I’m not sure I follow completely what you mean by this “factory” process.
But on the biblio demo edition project, I’m slowly building up a version of my personal bibliographic database, but with the following process:
One worry I have about a “factory” configuration process is that dependencies can be quite complex. There could be ways in which fields and/or cascade conditions don’t play nicely with each other if they were developed independently. So some pretty robust experimentation might be needed. Of course, that would be an important process for us, as a community, to move toward some “best practices”.
Great questions!
I don’t see an easy way to collaborate directly. But I think there are “best practices” that we can converge on, and we can be good beta testers for one another’s solutions-in-progress.
Here are two “best practice” issue that I hope we can agree on:
This is crucial. I was assuming that this would best be done by placing all the infrastructure tiddlers under their own common namespace, for instance:
$:/community/recipes/templates/IngredientTemplate
$:/community/recipes/functions/convertUnits.js
$:/community/recipes/buttons/NewRecipe
$:/community/recipes/styles/RecipeLayout
Anything under $:/community/recipes would be part of the core for this. We might maintain a manifest that includes these and any external plugins used. To my mind adding everything from such a manifest to an empty edition would make it into a recipe wiki, and in fact that’s how our own “Empty” edition would be built.
I’ve said before that I’m impressed with this. I simply am not ready now to focus on the distribution. We need to have a few editions under our belts before I want to spend mental energy on this.
If you have the uncompressed source for the bookmarklets, then I’m guessing we could write a fairly mechanical transformation of them to handle that, and then recompress them. But these would probably be separate bookmarks from the original. If you have an uncompressed one you would like me to look over, I can play around with it and see if I can figure it out.
I didn’t think that was what was being suggested, but if so, I agree with you wholeheartedly. Let’s not do too much premature abstraction. If we later see commonalities between these editions let’s factor those out later.
Lets start as simple as we can and only go far enough to make a widely usable edition. We’re not aiming for perfection, unless its the one described by Antoine de Saint-Exupéry:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Any suggestions for how this is documented? Is there simply an “About this Edition” tiddler in a semi-prominent location that contains all this information? Or is it external to the edition itself but somehow linked in the edition download page? Something else?
Absolutely.
In this case, as I mention above, I’d rather use a common prefix. While everyone who contributes to an edition should get full credit, it’s much more usable to have all of these under the $:/community/recipes or $:/community/bibliography namespaces.
Wow, yes, that’s a great idea and a powerful technique. We probably would want to write ourselves an editor to make that easier to maintain.
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.
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.
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)
@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…
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.
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.
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!
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.
In my own packages along with the namespaces tiddlers I have the following standard tiddlers which are transcluded into say $:/community/recipes
Then commonly
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.
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?
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. 
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!
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.
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:
But all of these pale in comparison to their main goal:
So, yes, keep them as clean and understandable as we can, so long as that doesn’t interfere with the primary goal.
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).
This may be a good objective, but should not get in the way of community contributions.
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.
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.
