Jump to: navigation, search

The Core Features team has enabled Flow on this talk page.

Previous feedback is on Talk:Flow Portal/Archive2 (using old Liquid Threads), and on our labs server.

Newest topics

Acceptance criteria

Reply • 3 comments •
Bobraynertalk contribs

What are the acceptance criteria for Flow?

Sänger S.Gtalk contribs
  • Be as flexible and diverse as current talk pages
  • Automatise signing
  • Automatise indention

The first is a must, the other two are nice-to-have

Bobraynertalk contribs

Thanks. Is there any ability to add/remove acceptance criteria, or are they fixed? Are there any per-wiki/per-platform acceptance criteria, or are they all product-focussed?

Reply to "Acceptance criteria"


Reply • 3 comments •
Derpmeuptalk contribs

Is Flow going to be an extension, or will it be integrated into MediaWiki?

Quiddity (WMF)talk contribs

Flow is currently an extension: Extension:Flow.

Whether or not to merge extensions into core, is lightly discussed at Schools of thought concerning integration of extensions into the core. Beyond that, I'm not sure. Hope that helps.

Derpmeuptalk contribs


Reply to "Extension"

What are the planned additional features, that would make Flow useful?

Reply • 3 comments •
Sänger S.Gtalk contribs

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?

Quiddity (WMF)talk contribs

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.)

Sänger S.Gtalk contribs

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.

Reply to "What are the planned additional features, that would make Flow useful?"


Reply • 20 comments •
Short Brigade Harvester Boristalk contribs

Test level 1. Editing test level 1.

Short Brigade Harvester Boristalk contribs

Test level 2

Short Brigade Harvester Boristalk contribs

Test level 2a

Short Brigade Harvester Boristalk contribs

Conclusion: Flow in its current form is unusable for the purpose of collaborative discussion. It would be great as a comment feature for casual readers, but it cannot handle the complex back-and-forth that typifies discussion and negotiation of article development.

Sänger S.Gtalk contribs

Yup, that's a nobrainer. But this thing is not for article development but for facebookisation, article development is so old-fashioned, don't bother the WMF with such outdated issues ;)

Short Brigade Harvester Boristalk contribs

I'm not sure I agree with your assessment of WMF's intention. While that may be part of it, I also believe that at least some of those at WMF want to help, but they have almost no idea what is involved in content development.

Nevertheless they have made it clear that Flow is coming, period, end of discussion. So protesting that is a waste of time. Our effort is better spent trying to help WMF developers minimize the damage to the editorial process.

Sänger S.Gtalk contribs

I don't agree with "Flow is coming, period".
I know some of those far away from the core of the wikiverse, that's mainly content development for WP and its sisters, and considerably far down the road as well software development to help that main purpose, obviously fall for useless bling items and want to shove them onto the community, come what may. But they have to be reigned in.
Anything, that doesn't help the main purpose of content development is rather useless stuff. Any WMF staffer working on such stuff is a wasted resource.

Short Brigade Harvester Boristalk contribs

It's quite clear that Flow is a non-negotiable mandate from WMF, and that if anyone doesn't like it WMF is happy for them to leave. They have said so, in so many words. It's possible to change things around the edges there's no point in arguing against Flow per se.

Sänger S.Gtalk contribs

It's quite understandable to have such a pessimistic view, but I hope that Lila will change things for the better, and she's not just talking hot air.

Atlasowatalk contribs

User:Sänger S.G, User:Short Brigade Harvester Boris: It's not really "clear that Flow is a non-negotiable mandate from WMF", see how Erik and Lila are testing the water:

  • "Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended)." Erik Moeller at Wikimedia-l: To Flow or not to Flow
  • "A much more useful discussion is whether a system like it (provided some of its properties are clarified and improved) is desirable, and if not, what alternative ways there are to make talk pages more user-friendly, and what the limitations of those methods are. Also, to the extent that there are aspects of the Flow architecture that really are dealbreakers, we should fix them now. As I wrote to Risker, I think it's worth considering spending some development time on turning something like the Teahouse gadget (which allows one click insertion of replies on the Teahouse Q/A page) into a Beta Feature after some further improvement, to see just how useful it could be for the common case. If there's an 80/20 rule and in 20% of cases it just gives up and edits the section, that might still be a time-saver and convenience. There might even be other relevant gadgets already in some languages/projects -- worth a closer look, for sure." Erik Moeller at Wikimedia-l: To Flow or not to Flow -> it does not flow
  • en:User_talk:LilaTretikov_(WMF)#Why is Flow DOI?

So i don't think that it's "clear that Flow is coming, period, end of discussion."

But, on the other hand:

Jay8gtalk contribs

I agree that more indent levels are needed. However, I think Flow is (or at least has the potential to be) an improvement over current discussion systems.

Sänger S.Gtalk contribs

Define "discussion system".
A talk page is not a discussion system, it's far more. The castration to only a discussion system is the core problem of Flow (and was as well with it's predecessor LiquidThingy).

Klipetalk contribs

Did you already have a look at Hhhippo's proposal on compact nesting? I think that it would be better than the current implementation relying only on indents.

Reply to "Indents"

When database changed in new version

Reply • 2 comments •
Guoyunhebravetalk contribs

If I installed the old version of Flow(beta), and in future, the database table of Flow changed, should I have to delete the old database table? I am afraid that Flow won't update old tables automatically or will empty old tables.

EBernhardson (WMF)talk contribs

Flow uses the standard update.php mechanism from within mediawiki, as such the data will migrate forward as expected. Flow also stores, by default, all content utilized in the last 3 days within its cache. At the WMF level db patches are their cache interaction are handled on an individual basis, from the outside it is probably easier to just update $wgFlowCacheVersion to invalidate the old cache after running update.php.

Reply to "When database changed in new version"

Showing closed topics as collapsed by default

Reply • 5 comments •
Pginer-WMFtalk contribs

Based on our experience in Talk:Content_translation, I was expecting that those conversations that we closed and summarised were shown collapsed by default since the summary already provides an overview of the topic. I don't know if this is also a valid assumptions for other use cases, or if it has been considered already.

SPage (WMF)talk contribs

We're still tinkering with moderation actions. Closed really meant Locked, in that you can't add replies, so we renamed it and took out the default collapse. If a topic is spurious, you can hide it, which takes it off the Flow board (but still in the history). That leaves the use case "Reduce the default visibility of a topic to its summary".

Jdforrester (WMF)talk contribs

+1. The whole point of closing a topic is to reduce its visibility and avoid distracting people, I'd have thought. :-)

Quiddity (WMF)talk contribs

We do need both options, and will get them eventually. I.e. We need to be able to use equivalents of both en:Template:Archive top and en:Template:Hidden archive top.

But generally (at Enwiki) we don't collapse closed/resolved topics, except for very offtopic/distracting, or very flame-filled threads.

I made some notes on 6 of the related templates, at

Jdforrester (WMF)talk contribs

Eh. We sort-of do; look at e.g. AfD where we both "archive" the discussion with a big blue box of static-ness, and then hide it by moving it to another "archive" page where no-one will find it.

Reply to "Showing closed topics as collapsed by default"

Making life easier

Reply • 1 comment •
Daniele Pugliesitalk contribs

With Flow finally we don't have to click the "signature" button anymore. This will make life easier both for experienced and new users. Also discussions are easier to open and reply. I am looking forward to see this tool active in all Wikimedia projects. Thanks. :)

Reply to "Making life easier"

Content stays in new topic box after saving

Reply • 2 comments •
Jay8gtalk contribs

After saving, the post content stays in the new topic box. This annoyingly triggers a "Do you want to leave this page?" box every subsequent refresh. Firefox 32.0.2, Windows 7

Quiddity (WMF)talk contribs

Filed as bugzilla:71776. Thanks.

Reply to "Content stays in new topic box after saving"

Missing topic

Reply • 4 comments •
Jay8gtalk contribs

This topic is missing on Talk:Phabricator/Help, at least for me. It does not appear to have been hidden or otherwise moderated. I noticed this only because I got a notification for the topic's creation. Does anyone know what's going on here?

Jdforrester (WMF)talk contribs

Huh. When I visit Talk:Phabricator/Help it appears just fine. Maybe the link from the notification doesn't work correctly?

Quiddity (WMF)talk contribs

Hmm, it's a problem with the sort-order. It's only visible if viewed in "recently active topics" mode. The board is empty if viewed in "Newest topics" mode. Filed as bugzilla:71762. Thanks.

Jdforrester (WMF)talk contribs

Aha, interesting. Thank you!

Reply to "Missing topic"

Topic appears two times

Reply • 4 comments •
Gerakitalk contribs

In Talk:Beta Features/Hovercards I created the topic Enable by default in el.wikipedia. It appears two times in the talk page, on the top of the page and somewhere in the middle, between older posts.

Quiddity (WMF)talk contribs

Thanks for the bug-report. I've added a note about this at

Sänger S.Gtalk contribs

I think title ans post are counted as two items. I got as well two lines in the history of this page for creating this one, first line was 5. Okt. 2014, 09:27 . . Sänger S.G (Diskussion | Beiträge) erstellte das Thema „Warum gibt es keinerlei Eingabehilfen?“. . . (+38)‎, and that's the number of letters (including spaces) in the title, second line is 5. Okt. 2014, 09:27 . . Sänger S.G (Diskussion | Beiträge) kommentierte auf „Warum gibt es keinerlei Eingabehilfen?“ (Dan versuche ich es noch mal ohne die zugehörige Wertung: Auch mit dem VE eingeschaltet gibt es hier keinerlei Eingabehilfen, gibt's ir…). . . (+982), and that's likely the number of letters in the post body (haven't counted).

Quite strange concept, or a bug.

Edith says: I just saw, I've made the completely wrong answer, or an answer to some completely different problem. Sorry

Quiddity (WMF)talk contribs

That behaviour was originally intended, because the person who created a new topictitle was not required to add any content as a first post. This has since been changed, and bugzilla:71619 was filed to merge the 2 elements (Topic created, and first post within).

Reply to "Topic appears two times"