Any community can require to have Structured discussions on their wiki by following the requirements described on https://www.mediawiki.org/wiki/Structured_Discussions/Request_Structured_Discussions_on_a_page.
It is completely possible. I co-mentored @happy5214 on a project specifically to address this issue. Pywikibot now has support for the most common bot scenarios (posting a new topic or replying to an existing topic with a warning, etc.), as well as a rarer scenario (resolve/reopen for clerking bots).
This work is merged, and the Pywikibot community is maintaining it (and I expect more work will be done for Pywikibot Flow support in the future).
I expect other bot frameworks will start to support Flow if they haven't already.
Flow does not require archives, though, so those particular bots will not be used. It just shows you the most recent topics (either in order of topic creation, or order of activity), and you can go as far back into the past as you want.
The problem at this point is, that there are also bot owners, who use custom code, like me, and want to do (in my view) more important things, than fix API Edit action, if there is a flow board. Why we don't require community consensus for each wiki? In this case, bot owners can prepare them, if the community accepts flow. Otherwise, everthing is unchanged. There are strong communitys, they don't want flow, without asking them, like at dewiki. Remeber the MediaViewer story, where the WMF uses superprotect, to overrule this community decision. I guess noone (WMF and community) wants something like that again. The other problem is, that flow has at my view to important security bugs, they are not fixed yet. I know a few of them, because I found them, the security bug I reported, has not a low impact, and this a big problem, if someone knows, how to replicate that. And there are still other issues, that were not fixed, for example, that you can't leave a redirect, when moving a flow board.
As this task is about "personal talk opt-in", would that in consequence mean that a community's majority decision would disallow its community members to individually opt-in for trying such a beta feature?
This is an incredibly serious comment to make in the middle of a discussion. Could you please provide a link to the security bugs please? Please do not give details here.
[Edit: I guess that you mean T110744, which is definitely a bug to fix but I disagree is a security issue. Are there any others, given that you said there were multiple important bugs?]
(Commented at T110744)
I agree with @MGChecker:
For example the VisualEditor or MediaViewer, each user can decide, if he want to opt-in or out. The problem with flow is, if I would enable flow at my talk page, every user, who wants to speak to me, have to use flow, or don't communicate, and that's a problem with this feature.
That's also true about features in MediaWiki you now take for granted, like categories or templates. When we introduced those things they were also disruptive. Just because something is disruptive doesn't mean it can never be released.
However, because the discussion on the Kurier is leading a lot of people here and making them worry unnecessarily, I'm happy to re-state that we are not going to enable even this opt-in for Flow on a wiki where its community is against it.
It is important to note at this point that community consensus regarding Flow usage at de-wiki was not yet polled. There are supportive and opposed voices, with the latter ones currently being a little louder on Kurier. @Luke081515 is actually just guessing that the community would reject flow pages, but there is no evidence yet that this is correct.
A real problem is the somewhat unclear situation about Flow. There was an AFAIK non-WMF story in Signpost titled “Flow placed on ice” in early September , which many of the de-Kurier readers understood as the end of Flow. Within that context, it was a bit surprising that Flow shall now be introduced in all Wikis. However, this merely seems to be a communication problem, since most of the de-wiki users probably did not read the official (?) WMF statements at en-wiki  and on the mailing list . To my opinion, an official statement about WMF’s stategy regarding talk pages and the collaborative processes connected with it would be very useful, particularly if it covers information about what actually is about to change for the communities.
This is also valid the other way round. If I were to prefer Flow talk pages, I had to life with users who would not like to switch to Flow. Our users are almost entirely free in managing their pages in the user namespace including the user talk page. I would strongly encourage giving them the opportunity to use modern tools for this process, like for instance the Flow extension. A self-developed bot code like in Luke081515’s case must not be a blocker for the introduction of such an important feature.
But there is another possibility to use Flow on all the wikis:
- let the reader decide (opt-in), how to read and write by Flow on talk pages
- don't let the page owner decide, how to read and write his talk page
- the talk page source code will be the same, but the formatting will be different
You have to change the programming code for that, but so Flow can be accepted better ...
No, you need community consensus of that wiki Flow should be enabled, also as Beta opt in.
You cannot override the community opinions about the enabling on their wiki. That is not the right way.
Isn't it possible to enable Flow in a new namespace? So the user keeps his user talk:$user and gets a user flow:$user ?
user talk: for important messages, bot messages and admin messages to user's address and his work.
user flow: for any further discussions and forum postings, to hold up the community life
I think, we should discuss this seriously ...
Thank you ...
You have mis-understood my comment. I said:
"it's not true that we need all wikis to agree before we enable it on any wiki"
For example, if the French Wikipedia wanted the feature, they do not need to get the permission of all the other wikis.
After discussion Growth team has decided to close that task, because there is no need to track or goal those deployments.
It is still possible to have Structured discussions enabled for wikis that wish them. Any community can require to have Structured discussions on their wiki by following the requirements described on https://www.mediawiki.org/wiki/Structured_Discussions/Request_Structured_Discussions_on_a_page.