I'm not sure we need to implement converting to wikitext.

You can just move the Flow board and protect it (this could be done automatically by a special page if we think it's a common issue). Converting to wikitext would be needed is if you wanted to uninstall Flow completely, but that's not happening currently.

It's very hard to adequately preserve the attribution information from Flow in a wikitext page, and currently this code is not doing so. It doesn't attribute anyone for header and the same issue would occur for summary (for header especially, that could be a fair amount of work on a real talk pages). It doesn't attribute people who edit posts (which now any auto-confirmed user can do).

It also doesn't preserve the summary at all, but that could easily be fixed.

We should check with legal about whether it's okay to discard edit history like this (it's definitely very problematic).

Related to / inspired by https://gerrit.wikimedia.org/r/#/c/178968/

It's very hard to adequately preserve the attribution information from Flow in a wikitext page, and currently this code is not doing so.

To elaborate on this, proper attribution could be done with synthetic edits under the correct username. Basically, replay the board in time order:

1. If a topic is created, create a section under the right user.
2. If an action occurs within a topic (including creation or edit of summary), serialize the whole topic (including summary), and make a section edit (replacing the whole section) under the user that did the action (TEST: multiple sections with same topic title),
3. If a header is created or edited, edit the lede.

In the course of writing this, I refined my thoughts above, and it doesn't seem as hard as I previously thought.

We need to discuss, though.

See T122961: Remove Flow from Wikipedia talk:WikiProject Breakfast on enwp.

Note, the above requires that the conversion script actually does the edits in a cron job/deferred, rather than just outputting text (with just one output/one edit, there is no proper attribution).

Temporarily protecting the page while these edits are made would help ensure the correct diffs.

The hardest part of the above is snapshotting a topic at a point in time (and finding all the right revisions at that time).

The link to the sample conversion in the description of this task is broken.

In T96301#1930861, @Scott wrote:

The link to the sample conversion in the description of this task is broken.

Added as part of the spec for T90075: Update and retest the convertToText script (if we were to use the script, we would need to update it first anyway, then produce another sample)

Just a sugestion: what about a special page (Special:DisableFlow) to do the contrary that Special:EnableFlow do?

I'm not sure we need to implement converting to wikitext.

As previously discussed e.g. around https://phabricator.wikimedia.org/T188806#4020474, enabling Flow is a quite disruptive change on a wiki (for example the default edit experience with basic things such as the edit button and links changes dramatically on talk pages), so it should not be irreversible. A wiki should be able to uninstall Flow without harmful consequences.

Discussion are often an important part of the history of pages, especially on public wikis, so they need a long-term digital preservation plan. Preserving the content as wikitext is the first step to ensure its preservation, although ideally we'd also preserve the history of edits and authors as well as incoming links.

The multiline list item RfC isn't strictly a necessity, but having it would make it much simpler to serialize Flow discussions into wikitext without having to worry about the many edge-cases around using wikitext lists to indent content that might contain tables, multiline templates, and other multiline tags which would be broken by just indiscriminately adding :::: to the start of every line...