[Blend-tinker-devel] wiki.d.o on a git-backed engine

Tue Jan 14 21:05:22 GMT 2025

Hi Ahmad,

Quoting Ahmad Khalifa (2025-01-14 21:10:55)
> On 14/01/2025 11:55, Jonas Smedegaard wrote:
> > # User interface(s)
> > 
> > One detail we might disagree on is the notion of "user", which is tied
> > to the notion of "web": The originial WikiWikiWeb was edited via a web
> > *browser* whereas some newer systems are edited offline and then pushed
> > (via web or other protocols) to be read via a web browser. A few of
> > those systems offer web-based editing as well, as an optional addon.
> > 
> > Strictly requiring web-browser-based editing limits available options.
> 
> 1. Developer-type user (will read the code)
> 2. Power-user (will read the manual)
> 3. Contributing user (likes debian ecosystem)
> 4. Casual-user (uses debian OS, little time to even do a websearch, will 
> only look at overly-SEOd pages that come up in the first page)
> 
> I would say as you go from 1 to 4, the number of users go up. The 
> biggest audience for a wiki are casual users who don't know what git is.
> 
> If you can convert casual-users into contributing-user, that's great.
> So for me the web-editing capability is the most important feature after 
> web-browsing :)

I think we can all agree that ideally all users have pleasant access.

Question is not what users we want, but if we want users more than we
want speed more than we want functional wiki code. I.e. a complex
problem that cannot be meaningfully separated into subproblems, because
deciding on one subpart (what users to cover) affects the other (what
time does it take to finalize an edit in a giant wiki, what systems
exist that offers a git backend, etc.).

> > # Markup
> > 
> > Some esp. early wikis use markup now considered obscure, where most
> > newer systems use some flavor of Markdown.
> > 
> > Markdown-based wikis sometimes deviate further through custom markers,
> > and some add metadata at the top, most commonly as YAML or TOML data.
> > 
> > Do we want to require a certain markup, or leave that to whatever system
> > we want for different reasons?
> > 
> > This obviously affects the migration challenge, but perhaps not decide
> > now, but just keep it in mind when considering system options.
> 
> Can we agree that it has to be accessible to Contributing-users?
> This will unintentionally bias towards markdown or mediawiki format, but 
> that's not my intent here.

Sure, but the more variables we turn into hard requirements, the less
likely we can reach a functional system at all.

> > # Backend
> > 
> > Most wikis store page content as files in a POSIX filesystem, or as
> > strings in an SQL database, or as documents in a NoSQL database, as is
> > standard for those backends, with revision control and web editing added
> > as custom logic on top of that.
> > 
> > Git-based wikis use a standardized revision control, with web access as
> > custom logic on top.
> > 
> > The use of a standardised version control system is a key feature for
> > me, and judging from the topic of this thread also for others.
> > 
> > Requiring git-based backend limits options, and perhaps most notably
> > excludes the undeniably popular system Mediawiki, used e.g. for
> > Wikipedia. Some disagree with me on that, though:
> > https://webmasters.stackexchange.com/a/82433
> 
> I see git-based backend as a not-so-great feature to have. Database 
> backends are more popular for admins. phpMyAdmin for even web-based 
> DB-editing.
> If you have the same stack as Wordpress/MediaWiki and friends, then you 
> have a much bigger pool of contributors/power users able to help.

Interesting.  That was kinda the starting point of this conversation.

Perhaps another conversation makes more sense, which does not start at
the conversation topic "wiki.d.o on a git-backed engine".  I suggest to
seek conversation partners at the d-devel mailinglist for that other
conversation, because the very reason I proposed to discuss it here was
the shared interest in lightweight systems. Specifically, I noticed some
interest in Mediawiki, and those folks is unlikely to have joined this
conversation due to the (for them) off-putting conversation topic here.

> > # Rendering
> > 
> > Some wikis render each page on-demand, and some render all pages ahead
> > of time after each content edit. The latter are called static web
> > compilers.
> > 
> > I am a big fan of static web compilers, but whether they are more
> > efficient obviously depends on how frequently a site is being edited
> > versus viewed, and how expensive a full site recompilation is.
> 
> I like SSGs, I use pelican and hugo. But neither have a web-editing 
> interface, you have to compile it. That's Ok for developer tools.
> 
> 
> > # Migration
> > 
> > MoinMoin use a filesystem-based backend with each page revision in a
> > sequence-numbered subdirectory. Content markup predates Markdown and is
> > called Creole. A plugin mechanism introduces custom markers that need
> > caring for as well.
> > 
> > Around 2005 I packaged the Perl modules usable for transforming wiki markup,
> > including from MoinMoin Creole to flavors of Markdown.
> > 
> > An attempt to migrate to Ikiwiki was investigated around 2008-2009.  I
> > vaguely remembered that effort to be lead by Frank Lin PIAT, but reading
> > some archived emails it seems I was more convinced than him on that, so
> > I am no longer sure what happened back then, and it was before I gained
> > familiarity with git so I have no code lying around related to that.
> > 
> > The best that I know of is the work by anarcat and others, maintained at
> > https://ikiwiki.info/tips/convert_moinmoin_to_ikiwiki/
> > 
> > I have some unfinished code converting a relatively large ikiwiki site
> > to Zola, which might have some use also for migrating to other systems
> > like hugo.
> 
> When this migration happened back then, how far did it get? Stuck at 90% 
> or much earlier?

If by "this" you mean the last of the 3 you quote above, then it is a
migration not from MoinMoin but from ikiwiki to zola - I guess it is 90%
done (but the remaining 10% may be the hardest to tackle).

For the other earlier migrations, I don't know.  Perhaps ask Frank Lin
and anarcat.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/blend-tinker-devel/attachments/20250114/0389cdbb/attachment.sig>