Replace Wikitcms(?)

adamwill commented

2026-04-18 17:23:06 +00:00

Owner

Wikitcms is my semi-tongue-in-cheek conceptualization of the longstanding system we have for doing release validation testing via the wiki. Starting way back in the mists of time with small, hand-written-and-schlepped-about pages of wiki tables, we've over time developed a wacky and somewhat-sophisticated mechanism that essentially (ab)uses the wiki as a programmatic and interactive interface for both displaying and submitting test results.

This is, on one level, clearly insane, but on another level, works so irritatingly well that every time we've previously thought about replacing it, we've decided against it.

The Age Of AI Scrapers might be another time it's worth thinking about replacing it, though, because the wiki is a very attractive target for them. It's also a big, awkward, and fundamentally-kinda-insecure thing that infra dearly wants to get rid of, but which Wikitmcs is one of the larger reasons they can't.

So...thoughts?

In the past we've tried various 'off-the-shelf' TCMSes, many of which don't exist any more. Nitrate is one that still exists. We've generally found these both too big and too opinionated for our needs, though; they tend to be designed around workflows that don't really match what we do with validation testing.

Extending testdays-web to also handle release validation is another option.

A third is to build something specific, as light as possible, probably based around resultsdb for result storage and...what, maybe a static site generator?...for interactive display and submission.

There's kinda a few elements to consider here:

Storage and display of the test cases themselves. mediawiki lets us do some fancy tricks with these, via its templating and transclusion mechanisms plus some of the extensions we have installed, and I have used these capabilities extensively in a few cases. We can probably live with the hit of going to a less-sophisticated, static templating system like Jinja or whatever's possible with asiidoc or whatever, though, in the interests of making life easier on infra.
Storage of the results. If we're doing this, I'd really like if the results went to resultsdb. That might require building...something...to allow interactive authenticated submission to resultsdb, though. We already have a convention for describing compose-level test results in resultsdb - we should just follow how openQA automated test results are formatted.
Interactive display of the results. Currently there's basically the wiki tables, the Summary view (which uses fancy mediawiki transclusion tricks), and testcase_stats (which is a static site generated by relval). Obviously if we were building something we'd have scope to design whatever views we wanted, but we'd probably want to at least replicate/improve on those two to start with.
Result submission. Probably it would be a good idea to make it possible to submit results from the viewing UI, however that's implemented. We might also still want to support relval report-results. Potentially we could add other methods too, but not sure it's needed?

This is really more of an epic than a task, but for now, filing this ticket so we can kick it around. If we come to any decisions we can split up the work into more tickets, obvs.

[Wikitcms](https://fedoraproject.org/wiki/Wikitcms) is my semi-tongue-in-cheek conceptualization of the longstanding system we have for doing release validation testing via the wiki. Starting way back in the mists of time with small, hand-written-and-schlepped-about pages of wiki tables, we've over time developed a wacky and somewhat-sophisticated mechanism that essentially (ab)uses the wiki as a programmatic and interactive interface for both displaying and submitting test results. This is, on one level, clearly insane, but on another level, works so irritatingly well that every time we've previously thought about replacing it, we've decided against it. The Age Of AI Scrapers might be another time it's worth thinking about replacing it, though, because the wiki is a very attractive target for them. It's also a big, awkward, and fundamentally-kinda-insecure thing that infra dearly wants to get rid of, but which Wikitmcs is one of the larger reasons they can't. So...thoughts? In the past we've tried various 'off-the-shelf' TCMSes, many of which don't exist any more. [Nitrate](https://github.com/Nitrate/Nitrate) is one that still exists. We've generally found these both too big and too opinionated for our needs, though; they tend to be designed around workflows that don't really match what we do with validation testing. Extending [testdays-web](https://forge.fedoraproject.org/quality/testdays-web) to also handle release validation is another option. A third is to build something specific, as light as possible, probably based around resultsdb for result storage and...what, maybe a static site generator?...for interactive display and submission. There's kinda a few elements to consider here: 1. Storage and display of the test cases themselves. mediawiki lets us do some fancy tricks with these, via its templating and transclusion mechanisms plus some of the extensions we have installed, and I have used these capabilities extensively in a few cases. We can *probably* live with the hit of going to a less-sophisticated, static templating system like Jinja or whatever's possible with asiidoc or whatever, though, in the interests of making life easier on infra. 2. Storage of the results. If we're doing this, I'd really like if the results went to resultsdb. That might require building...something...to allow interactive authenticated submission to resultsdb, though. We already have a convention for describing compose-level test results in resultsdb - we should just follow how openQA automated test results are formatted. 3. Interactive display of the results. Currently there's basically the wiki tables, the Summary view (which uses fancy mediawiki transclusion tricks), and [testcase_stats](https://openqa.fedoraproject.org/testcase_stats) (which is a static site generated by relval). Obviously if we were building something we'd have scope to design whatever views we wanted, but we'd probably want to at least replicate/improve on those two to start with. 4. Result submission. Probably it would be a good idea to make it possible to submit results from the viewing UI, however that's implemented. We might also still want to support `relval report-results`. Potentially we could add other methods too, but not sure it's needed? This is really more of an epic than a task, but for now, filing this ticket so we can kick it around. If we come to any decisions we can split up the work into more tickets, obvs.

adamwill added the

labels

2026-04-18 17:23:06 +00:00

adamwill commented

2026-04-18 17:23:18 +00:00

Author

Owner

@kevin FYI

lruzicka commented

2026-04-20 08:32:58 +00:00

Owner

@adamwill wrote in #893 (comment):

The Age Of AI Scrapers might be another time it's worth thinking about replacing it, though, because the wiki is a very attractive target for them. It's also a big, awkward, and fundamentally-kinda-insecure thing that infra dearly wants to get rid of, but which Wikitmcs is one of the larger reasons they can't.

Wow, I have never expected this to be coming, yet it's here. I support the idea, as I have always found Wiki (not Wikitcms) too complicated to navigate. So yeah, I am in for it.

In the past we've tried various 'off-the-shelf' TCMSes, many of which don't exist any more. Nitrate is one that still exists. We've generally found these both too big and too opinionated for our needs, though; they tend to be designed around workflows that don't really match what we do with validation testing.

This problem has not disappeared. We still will have it. We have expectations about stuff that has been preventing us from using anything else. Therefore, I'd not try to adopt another TCMS out there, but I'd vote for something new, tailored to our needs. In the time of vibe-coding, this does not have to be too much of an obstacle any more. As I have seen, models are very good in doing web stuff. I am not sure if vibe-coding is the preffered way here, though, but it could help us get an AI task.

A third is to build something specific, as light as possible, probably based around resultsdb for result storage and...what, maybe a static site generator?...for interactive display and submission.

I would, personally, go this way. I love static site generators because they are easy to work with, powerful in terms of web building, and they build safe pages where attackers have nothing to do.

Storage and display of the test cases themselves. mediawiki lets us do some fancy tricks with these, via its templating and transclusion mechanisms plus some of the extensions we have installed, and I have used these capabilities extensively in a few cases. We can probably live with the hit of going to a less-sophisticated, static templating system like Jinja or whatever's possible with asiidoc or whatever, though, in the interests of making life easier on infra.

Asciidoc supports tables, such as

[cols="1,1,1,1,1",options="header"]
|===
|Column 1 |Column 2 |Column 3 |Column 4 |Column 5

|A1 |A2 |A3 |A4 |A5
|B1 |B2 |B3 |B4 |B5
|C1 |C2 |C3 |C4 |C5
|===

so it could be used to generate the output through some Asciidoc builder. With static generators, however, I have been using markdown or ReST, which I'd prefer. ReST offers something called a list-table which is used to generate a table out of a list which would be pretty easy to generate and probably also quite easy to read as a code. Or edit in a template.

However, I am not sure at the moment, how the static page would handle results reporting? From the top of my head, I could think of a back-end that would accept the result from a link generated for each field, so clicking the link would report the result. In that case, we'd need a login, I suppose. I am not sure about it though.

2. Storage of the results. If we're doing this, I'd really like if the results went to resultsdb. That might require building...something...to allow interactive authenticated submission to resultsdb, though. We already have a convention for describing compose-level test results in resultsdb - we should just follow how openQA automated test results are formatted.

Can resultsdb entries be edited? Or is it just dump a result and show it later?

4. Result submission. Probably it would be a good idea to make it possible to submit results from the viewing UI, however that's implemented. We might also still want to support `relval report-results`. Potentially we could add other methods too, but not sure it's needed?

I would like to also support a CLI non-interactive (programmatic) submission of the results, such as relval report --matrix Installation --group Virtualization --testrow Libvirt-42 --result pass, or via a json file, etc.

This is really more of an epic than a task, but for now, filing this ticket so we can kick it around. If we come to any decisions we can split up the work into more tickets, obvs.

@adamwill wrote in https://forge.fedoraproject.org/quality/tickets/issues/893#issue-113181: > The Age Of AI Scrapers might be another time it's worth thinking about replacing it, though, because the wiki is a very attractive target for them. It's also a big, awkward, and fundamentally-kinda-insecure thing that infra dearly wants to get rid of, but which Wikitmcs is one of the larger reasons they can't. Wow, I have never expected this to be coming, yet it's here. I support the idea, as I have always found Wiki (not Wikitcms) too complicated to navigate. So yeah, I am in for it. > In the past we've tried various 'off-the-shelf' TCMSes, many of which don't exist any more. [Nitrate](https://github.com/Nitrate/Nitrate) is one that still exists. We've generally found these both too big and too opinionated for our needs, though; they tend to be designed around workflows that don't really match what we do with validation testing. This problem has not disappeared. We still will have it. We have expectations about stuff that has been preventing us from using anything else. Therefore, I'd not try to adopt another TCMS out there, but I'd vote for something new, tailored to our needs. In the time of vibe-coding, this does not have to be too much of an obstacle any more. As I have seen, models are very good in doing web stuff. I am not sure if vibe-coding is the preffered way here, though, but it could help us get an AI task. > A third is to build something specific, as light as possible, probably based around resultsdb for result storage and...what, maybe a static site generator?...for interactive display and submission. I would, personally, go this way. I love static site generators because they are easy to work with, powerful in terms of web building, and they build safe pages where attackers have nothing to do. > Storage and display of the test cases themselves. mediawiki lets us do some fancy tricks with these, via its templating and transclusion mechanisms plus some of the extensions we have installed, and I have used these capabilities extensively in a few cases. We can _probably_ live with the hit of going to a less-sophisticated, static templating system like Jinja or whatever's possible with asiidoc or whatever, though, in the interests of making life easier on infra. Asciidoc supports tables, such as ``` [cols="1,1,1,1,1",options="header"] |=== |Column 1 |Column 2 |Column 3 |Column 4 |Column 5 |A1 |A2 |A3 |A4 |A5 |B1 |B2 |B3 |B4 |B5 |C1 |C2 |C3 |C4 |C5 |=== ``` so it could be used to generate the output through some Asciidoc builder. With static generators, however, I have been using markdown or ReST, which I'd prefer. ReST offers something called a `list-table` which is used to generate a table out of a list which would be pretty easy to generate and probably also quite easy to read as a code. Or edit in a template. However, I am not sure at the moment, how the static page would handle results reporting? From the top of my head, I could think of a back-end that would accept the result from a link generated for each field, so clicking the link would report the result. In that case, we'd need a login, I suppose. I am not sure about it though. > 2. Storage of the results. If we're doing this, I'd really like if the results went to resultsdb. That might require building...something...to allow interactive authenticated submission to resultsdb, though. We already have a convention for describing compose-level test results in resultsdb - we should just follow how openQA automated test results are formatted. Can resultsdb entries be edited? Or is it just dump a result and show it later? > 4. Result submission. Probably it would be a good idea to make it possible to submit results from the viewing UI, however that's implemented. We might also still want to support `relval report-results`. Potentially we could add other methods too, but not sure it's needed? I would like to also support a CLI non-interactive (programmatic) submission of the results, such as `relval report --matrix Installation --group Virtualization --testrow Libvirt-42 --result pass`, or via a json file, etc. > > > This is really more of an epic than a task, but for now, filing this ticket so we can kick it around. If we come to any decisions we can split up the work into more tickets, obvs.

psklenar commented

2026-04-20 09:42:57 +00:00

Owner

I agree that the current wikitcms system is getting complicated for writing/reading results, so I'm glad we're thinking about this for the future. I've also noticed that when I submit results from cloud automation, I sometimes get randomly blocked for a few hours. So I'm glad we're thinking about this for the future.

On one hand, this will be used primarily by our team, so I understand that using a full TCMS (I think its dead now) or something like ReportPortal (used here internally) might be "too big" for our needs.

On the other hand - is building this from scratch really simpler than adapting an existing solution? Maybe worth checking how ReportPortal is used internally and whether they could set it up publicly for us (including maintenance).

I agree that the current wikitcms system is getting complicated for writing/reading results, so I'm glad we're thinking about this for the future. I've also noticed that when I submit results from cloud automation, I sometimes get randomly blocked for a few hours. So I'm glad we're thinking about this for the future. On one hand, this will be used primarily by our team, so I understand that using a full TCMS (I think its dead now) or something like [ReportPortal](https://reportportal.io/) (used here internally) might be "too big" for our needs. On the other hand - is building this from scratch really simpler than adapting an existing solution? Maybe worth checking how ReportPortal is used internally and whether they could set it up publicly for us (including maintenance).

adamwill commented

2026-04-20 16:22:07 +00:00

Author

Owner

Allocate ≥ 2 CPUs & 6 GB RAM to Docker; ≥ 20 GB free disk space [from Installation gude]

😑

> Allocate ≥ 2 CPUs & 6 GB RAM to Docker; ≥ 20 GB free disk space [from [Installation gude](https://reportportal.io/installation/)] 😑

adamwill commented

2026-04-20 16:29:24 +00:00

Author

Owner

Aside from that, reading the install guide makes it look a lot like it's focused around agglomerating and doing stuff to automated test results, which is not what we're doing here.

Possibly you can submit results via the REST API, but then, the tool isn't really giving us a whole lot, I don't think? We'd still have to build a UI people could click on to generate an API call to submit the result to the tool...

Aside from that, reading the install guide makes it look a lot like it's focused around agglomerating and doing stuff to *automated* test results, which is not what we're doing here. Possibly you can submit results via the REST API, but then, the tool isn't really giving us a whole lot, I don't think? We'd still have to build a UI people could click on to generate an API call to submit the result to the tool...

adamwill commented

2026-04-20 16:39:43 +00:00

Author

Owner

I would, personally, go this way. I love static site generators because they are easy to work with, powerful in terms of web building, and they build safe pages where attackers have nothing to do.

Yes, this is why I like the idea too.

Storage and display of the test cases themselves. mediawiki lets us do some fancy tricks with these, via its templating and transclusion mechanisms plus some of the extensions we have installed, and I have used these capabilities extensively in a few cases. We can probably live with the hit of going to a less-sophisticated, static templating system like Jinja or whatever's possible with asiidoc or whatever, though, in the interests of making life easier on infra.

Asciidoc supports tables, such as...

I wasn't talking about the layout of the matrix pages, which should indeed be fairly easy to achieve in various formats. I was talking about test cases themselves. Some of them use dynamic template transclusion quite heavily - that is, the final test case pages are built out of templates and the behavior of the templates themselves depends on arguments they're passed. https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation_encrypted is a good example - look at the rendered version of that, now here's the 'source':

{{Associated_release_criterion|Beta|upgrade-requirements}}

{{QA/Test_Case
|description={{upgrade_description|from=current|flavor=workstation|pkgset=workstation|live=1|encrypt=1}}
|setup={{upgrade_setup|from=current|flavor=workstation|pkgset=workstation|live=1|encrypt=1}}
|actions={{dnf_upgrade_procedure}}
|results={{upgrade_results}}
}}

[[Category:Upgrade_system]]
[[Category:Package_dnf-plugin-system-upgrade_test_cases]]

and here's the "source" of one of the templates it uses:

<noinclude>{{tempdoc}}</noinclude>
<ol>
<li> Perform an installation of {{FedoraVersion|{{{flavor|long}}}|{{{from|current}}}}} with default partitioning.
<ul>
{{#if:{{{encrypt|}}}|<li> Enable disk encryption during installation.|}}
{{#if:{{{pkgset|}}}|<li> Select the {{ucfirst:{{{pkgset}}}}} package set {{#if:{{{live|}}}|or use the {{ucfirst:{{{pkgset}}}}} Live image|}}.|}}
</ul>
<li> Apply all system updates and reboot.
</ol>

aside from being a nightmare to write (whitespace is significant in wikitext, so you can't split it across lines and indent, so you wind up counting sets of two and three curly braces in your head a lot...), it works quite neatly, and is probably hard to replicate in less-insane but also less-capable syntaxes. (Jinja might actually do most of it? Not sure, and not sure about asciidoc). But if that's the biggest problem we can just bite the bullet and live without it, I think.

edit: oh, it's dynamic because if you change one of the template pages in mediawiki, the pages that use that template instantly reflect the change. This is handy for e.g. release numbers, as soon as we update CurrentFedoraVersion , all test cases that refer to it are instantly updated.

> I would, personally, go this way. I love static site generators because they are easy to work with, powerful in terms of web building, and they build safe pages where attackers have nothing to do. Yes, this is why I like the idea too. >> Storage and display of the test cases themselves. mediawiki lets us do some fancy tricks with these, via its templating and transclusion mechanisms plus some of the extensions we have installed, and I have used these capabilities extensively in a few cases. We can probably live with the hit of going to a less-sophisticated, static templating system like Jinja or whatever's possible with asiidoc or whatever, though, in the interests of making life easier on infra. > Asciidoc supports tables, such as... I wasn't talking about the layout of the *matrix pages*, which should indeed be fairly easy to achieve in various formats. I was talking about *test cases themselves*. Some of them use dynamic template transclusion quite heavily - that is, the final test case pages are built out of templates and the behavior of the *templates themselves* depends on arguments they're passed. https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation_encrypted is a good example - look at the rendered version of that, now here's the 'source': ``` {{Associated_release_criterion|Beta|upgrade-requirements}} {{QA/Test_Case |description={{upgrade_description|from=current|flavor=workstation|pkgset=workstation|live=1|encrypt=1}} |setup={{upgrade_setup|from=current|flavor=workstation|pkgset=workstation|live=1|encrypt=1}} |actions={{dnf_upgrade_procedure}} |results={{upgrade_results}} }} [[Category:Upgrade_system]] [[Category:Package_dnf-plugin-system-upgrade_test_cases]] ``` and here's the "source" of one of the templates it uses: ``` <noinclude>{{tempdoc}}</noinclude> <ol> <li> Perform an installation of {{FedoraVersion|{{{flavor|long}}}|{{{from|current}}}}} with default partitioning. <ul> {{#if:{{{encrypt|}}}|<li> Enable disk encryption during installation.|}} {{#if:{{{pkgset|}}}|<li> Select the {{ucfirst:{{{pkgset}}}}} package set {{#if:{{{live|}}}|or use the {{ucfirst:{{{pkgset}}}}} Live image|}}.|}} </ul> <li> Apply all system updates and reboot. </ol> ``` aside from being a nightmare to write (whitespace is significant in wikitext, so you can't split it across lines and indent, so you wind up counting sets of two and three curly braces in your head a lot...), it works quite neatly, and is probably hard to replicate in less-insane but also less-capable syntaxes. (Jinja might actually do most of it? Not sure, and not sure about asciidoc). But if that's the biggest problem we can just bite the bullet and live without it, I think. edit: oh, it's dynamic because if you change one of the template pages in mediawiki, the pages that use that template instantly reflect the change. This is handy for e.g. release numbers, as soon as we update CurrentFedoraVersion , all test cases that refer to it are instantly updated.

adamwill commented

2026-04-20 16:47:55 +00:00

Author

Owner

However, I am not sure at the moment, how the static page would handle results reporting? From the top of my head, I could think of a back-end that would accept the result from a link generated for each field, so clicking the link would report the result. In that case, we'd need a login, I suppose. I am not sure about it though.

I was figuring we'd sort of cheat here, and the 'report' button (or whatever) would be a link to...something that lets you submit a report into resultsdb and somehow handles the authentication. Maybe that specific little bit needs to be dynamic, the way people write mostly-static sites with dynamic comment sections...

> However, I am not sure at the moment, how the static page would handle results reporting? From the top of my head, I could think of a back-end that would accept the result from a link generated for each field, so clicking the link would report the result. In that case, we'd need a login, I suppose. I am not sure about it though. I was figuring we'd sort of cheat here, and the 'report' button (or whatever) would be a link to...*something* that lets you submit a report into resultsdb and somehow handles the authentication. Maybe that specific little bit needs to be dynamic, the way people write mostly-static sites with dynamic comment sections...

lruzicka commented

2026-04-20 17:14:08 +00:00

Owner

edit: oh, it's dynamic because if you change one of the template pages in mediawiki, the pages that use that template instantly reflect the change. This is handy for e.g. release numbers, as soon as we update CurrentFedoraVersion , all test cases that refer to it are instantly updated.

This is entirely possible in Asciidoc. At the basic level, it provides attributes, which act as variables that are substituted during rendering. You can define them in the document or pass them externally, making them suitable for simple parameterization.
It also supports conditional logic (if/else style constructs), allowing limited dynamic content based on attribute values.
For reuse and composition, AsciiDoc offers includes, so you can build documents from modular parts while sharing variables across them.

> edit: oh, it's dynamic because if you change one of the template pages in mediawiki, the pages that use that template instantly reflect the change. This is handy for e.g. release numbers, as soon as we update CurrentFedoraVersion , all test cases that refer to it are instantly updated. This is entirely possible in Asciidoc. At the basic level, it provides attributes, which act as variables that are substituted during rendering. You can define them in the document or pass them externally, making them suitable for simple parameterization. It also supports conditional logic (if/else style constructs), allowing limited dynamic content based on attribute values. For reuse and composition, AsciiDoc offers includes, so you can build documents from modular parts while sharing variables across them.

lruzicka commented

2026-04-20 17:14:35 +00:00

Owner

I was figuring we'd sort of cheat here, and the 'report' button (or whatever) would be a link to...something that lets you submit a report into resultsdb and somehow handles the authentication. Maybe that specific little bit needs to be dynamic, the way people write mostly-static sites with dynamic comment sections...

So that would work exactly as I'd have expected. Thanks.

> I was figuring we'd sort of cheat here, and the 'report' button (or whatever) would be a link to..._something_ that lets you submit a report into resultsdb and somehow handles the authentication. Maybe that specific little bit needs to be dynamic, the way people write mostly-static sites with dynamic comment sections... So that would work exactly as I'd have expected. Thanks.

adamwill commented

2026-04-20 17:24:53 +00:00

Author

Owner

@lruzicka wrote in #893 (comment):

edit: oh, it's dynamic because if you change one of the template pages in mediawiki, the pages that use that template instantly reflect the change. This is handy for e.g. release numbers, as soon as we update CurrentFedoraVersion , all test cases that refer to it are instantly updated.

This is entirely possible in Asciidoc. At the basic level, it provides attributes, which act as variables that are substituted during rendering. You can define them in the document or pass them externally, making them suitable for simple parameterization. It also supports conditional logic (if/else style constructs), allowing limited dynamic content based on attribute values. For reuse and composition, AsciiDoc offers includes, so you can build documents from modular parts while sharing variables across them.

Yes, but the actual rendered docs that people read aren't magically updated when you update the templates. You have to do a render+publish cycle. That's the bit that's different with mediawiki, which I'm using the term 'dynamic' for. It's less of an issue than it used to be now we have nice tools for doing automatic rendering and publishing, of course.

@lruzicka wrote in https://forge.fedoraproject.org/quality/tickets/issues/893#issuecomment-616976: > > edit: oh, it's dynamic because if you change one of the template pages in mediawiki, the pages that use that template instantly reflect the change. This is handy for e.g. release numbers, as soon as we update CurrentFedoraVersion , all test cases that refer to it are instantly updated. > > This is entirely possible in Asciidoc. At the basic level, it provides attributes, which act as variables that are substituted during rendering. You can define them in the document or pass them externally, making them suitable for simple parameterization. It also supports conditional logic (if/else style constructs), allowing limited dynamic content based on attribute values. For reuse and composition, AsciiDoc offers includes, so you can build documents from modular parts while sharing variables across them. Yes, but the actual rendered docs that people read aren't magically updated when you update the templates. You have to do a render+publish cycle. That's the bit that's different with mediawiki, which I'm using the term 'dynamic' for. It's less of an issue than it used to be now we have nice tools for doing automatic rendering and publishing, of course.

kparal commented

2026-05-07 15:50:57 +00:00

Owner

A year ago I'd say that there's no chance we can create a custom solution (outside of a Google Sheets wrapper). But recently the Jaroslav+Claude duo have been so productive that we might actually be able to 😀️ Whether it's a good idea, that's a different question. It depends on how desperately Infra wants to kill wiki. Because if we invest time into replacing something that works, we won't be able to do lots of other useful (and perhaps even more useful) stuff instead. This might be a good topic for a team Flock discussion.

Rows
Columns

Replace Wikitcms(?) #893