Topic on Talk:Structured Discussions

In the current state Flow is useless for most talk pages, as it's just some forum implementation, and that's a very unimportant use case.
It breaks the collaboration on article improvement use case, that's by far the most important one, as article improvement is the main goal of the whole project.

Currently there is nothing really worth improving to see here, but nonetheless the WMF-people seem to have the impression to develop something really useful. As this has to something completely different to what's tested here currently, is there anywhere something to see from those future plans? Or is this future really so many years away now as it seems?

Re: "collaboration on article improvement use case" - They are definitely going to be changing "who can edit another user's post" - They're just waiting on Design to give specifications for how edits (by another person other than the original author) should be denoted. E.g. LQT has this explanation in the top-right corner. (which really ought to link to the history page, and specify the username(s) of the editors, or something similar).

Re: Improvements to the basic Talkpage experience, Flow will solve many of the basic problems, such as:

• Keeping the content and the edit-history together, which our usual cut&paste archiving breaks.
• Making it easy to see if something was edited after it was initially written, without checking every subsequent edit.
• Fixing the WP:INDENTGAP issues (where we mis-use HTML Definition lists to create :::these indents) which makes it troublesome to add paragraph breaks, and which are bad for accessibility
• Enabling the watchlisting of single topics on busy pages. (The beginnings of this are implemented, but will require a lot of fine-tuning and additional editor-options, over the coming months).

So, yes you are correct that Flow only has a few features at the moment, that are clear improvements to a basic talkpage, but they form the basis for complex things to come...

Re: Future features. The "user-to-user" discussion workflow, is one of the most central types of workflow - most of our other workflows stem outwards from (or hook into) that. They're going to be working on the "discussion" and other underlying-architecture aspects for a while longer, but once that is further along the idea is to use these structured discussions in ways that would (or do) currently require a mountain of templates and scripts, and would require sub-page transclusions for every thread in a standard talkpage. They plan to create a modular set of elements, that each wiki can combine however they need/want. This will enable all wikis to have complex functionality/workflows, without requiring a significant userbase of volunteer template- & bot- developers. It will also enable greater complexity/efficiency at the large wikis. E.g. One of the most complex listings of discussion-centered workflows (that I know of), is at en:Wikipedia:WikiProject Military history/Article alerts. All of those workflows should require less manual upkeep and triage - they should be more efficient, so that highly active editors can do more, in their limited time.

E.g. It shouldn't require manual editing to add deletion sorting tags, if the talkpage already has relevant WikiProject banners. This example could potentially be solved with another bot, but that solution doesn't help anyone else.

E.g.2. It should be easier to notify editors about particular workflows that they might be interested in. If I AfD an article, it should be easy for me to pop-open a list of the heavy contributors and original author, so that I can ping them for their potential input. (And they should be able to specify how such notifications reach them - via watchlist, or echo-notification, or email, or perhaps a to-do list box on their userpage, or anything else that we can dream up.)

Hence the goal/description of "make the wiki discussion system more efficient for experienced users", which doesn't really encapsulate the complexity they're working towards, but it's a start. Just like Flow.

(Hope that helps. Let me know which bits are useful, and which are not? That'll help me improve the main documentation, which really needs more of these details.)

One "must have" use case is the discussion, complete with testing etc., of layout changes in the article, like table layout, paragraph structure, so that it is viewable how it would look like on the article page. For that use case the talk page has to look exactly as the article page, at least in the area where this discussion takes place.

You seem to focus too much on the forum-like part, that imho isn't essential at all, and miss all other stuff.

Regarding your bullet points (that again only deal with the forum aspect):

• That's what happens currently on every wiki-page, whether the archive is far down the scroll or one click away doesn't make much difference.
• Nice to have, but not really essential, the history usually is enough for that goal.
• Should be done easily with VE and some special button therefore, no need to break the whole process.
• Should be possible as well for ordinary pages, if resources were put there instead of this Flow and bling stuff like MV.

How do I move the indents to show it was an answer to your post? Easy on normal pages, impossible here.

Re: viewing content as it will appear within the article - that's a good point, and is one of the reasons that there's soon going to be (some sort of) a width-changer/preference. Having an easy way to change the width will be good for a few reasons, particularly because it'll help remind us content-editors that all articles are seen in a huge variety of ways - from people on small laptops, to people with large widescreen monitors, to people who tile their windows, etc. What looks great at 1920×1080 might look terrible at 1024x768, and vice-versa, and we shouldn't be customizing page layouts to only look good at a specific width (or font-size).

Re: focus on forum - I understand what you're saying, but the majority of threads on a talkpage are discussions between editors, and the other workflows (things like: checklists for article assessments, XfCs, content-drafting, etc) almost all include some "discussion" aspect, i.e. somewhere we use a ~~~~. The workflows that aren't part of those groups are almost all attaching meta-data using templates+categories. All of this will be supported by Flow eventually, but they're concentrating on building just a few parts at a time, hence the current focus.

Re: Moving the indents - refactoring where a Post appears, is a feature on the to-do list, along with splitting/merging Topics. I'm sorry that I can't help with that sooner. :(

Hope that helps.

Ah yes, the often-used "*~~~~" voting format gets really ugly with Flow. Good point.