Talk:Flow

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
By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

How to opt-in?

Reply • 2 comments •
2
Fgnievinskitalk contribs

Where to go to request Flow to be deployed on a particular Talk page, please? I'm looking for a more pragmatic answer than "In late 2014, we will increase the number of places where Flow is deployed; these deployments will occur with consensus from community members who use those discussion spaces." Thanks.

Quiddity (WMF)talk contribs

They're currently collecting specific requests for Wikis/Namespaces/Pages, and then considering further rollouts as time/resources allows. E.g. There are a few Wiki that have requested rollout to either a test-page or an entire namespace.

They're not expanding beyond the current test pages, for a few more months, but please let me know where you'd suggest/request that Flow be enabled, so that I can add it to the list? Thanks. :)

Reply to "How to opt-in?"

Notifications for moderated topics

Reply • 3 comments •
3
Jay8gtalk contribs

Flow really shouldn't send notifications for moderated topics. This is frustrating for me, as many pages on my watchlist keep getting spam topics, and is confusing, especially for new users, as there is no indication of the hidden topic on the board page, where the notification takes you. (Alternately, it could send you to the topic page, but I don't think that would be really useful.)

Klipetalk contribs

There may occasionally be good reasons to unhide a topic... Let's imagine the following: user A creates a topic, then user B sees the notification and hides the topic, then the notification gets removed from all other users watching the board... The probability is high that only user A (obviously watching the topic) will realise that the topic was hidden and possibly react. Is this what we want? Doesn't it make it vandals life too easy?

In general, I would prefer the notification for any new topic to send me on the topic page instead of on the parent board. If then I see that the topic is moderated, that's not a big deal.

Having notifications send me to the topic page would also make more sense in the long term, when we'll be able to link a topic to multiple boards: if I watch the board A and a topic created on another board later gets linked to that board A, then I want to be notified of the fact that there is an additional topic on board A although it may be older than many other topics already present on board A. Finding it back on the board may not be easy.

Hhhippotalk contribs

It's not really possible to 'take back' a notification when the topic gets hidden, in particular if the notification was sent by e-mail.

I agree that linking to the topic makes sense, but only if the topic itself is on the watchlist or otherwise triggering the notification (ping etc.). If the trigger is "new topic on a watched board", then there's only one notification for possibly several new topics, so the link has to go to the board.

To avoid confusion if the topic was hidden in the meantime, the link function should be "show me all activity on that board between (timestamp in the notification) and (now)", for example like this. Linking an existing topic to a watched board would count as a 'change', so the topic would be marked.

Reply to "Notifications for moderated topics"

Will Flow ever be the real LQT 4.0

Reply • 3 comments •
3
DaSchtalk contribs

Can we ever expect to have a migration from LQT 2 to Flow, so that we can assume, that Flow is LQT 4.0 and not just some kind of incompatible never ready software that's only use-case is to upset users?

Klipetalk contribs
We'll be working on a conversion script that turns LQT discussions into Flow topics, in late 2014.
Quiddity (WMF)talk contribs

They're working on that migration script right now. A large quantity of the work is done, and it's currently going through testing and edge-case discovery. Once it's had some more bug-fixes and polish, they'll be doing some public demonstrations of page-conversions, for wider feedback and analysis.

If you'd like to follow the details, see https://trello.com/c/6OqlxIYI/ for the product management notes, and https://gerrit.wikimedia.org/r/#/c/119243/ for the WIP code.

Reply to "Will Flow ever be the real LQT 4.0"

Typo in topic

Reply • 2 comments •
2
Be..anyonetalk contribs

On Template_talk:Extension you might be able to see how I miserably failed to fix a typo in topic Imcompatible with Template:EL with the help of {{delete|typo}}. ~~~~

Quiddity (WMF)talk contribs

Hmm, that should have been possible to fix by clicking "Change subject" at the top-right of the thread (e.g. in the new copy you made at Thread:Template talk:Extension/Incompatible with Template:EL). But possibly there's a Liquidthreads bug that I'm not familiar with.

Regarding Flow, is/was it easy enough to find the "Edit title" link in the topic's actionmenu?

Reply to "Typo in topic"

Acceptance criteria

Reply • 7 comments •
7
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?

Jorm (WMF)talk contribs

You'll have to ask Danny Horn what the acceptance criteria are.

Sänger S.Gtalk contribs

You have to ask the communities what the acceptance criteria are, they have to have the last word, not some bureaucrats in SF.

Klipetalk contribs

Flow is meant to support various kinds of workflows, with the current basic "discussion workflow" being just one of them (others include actual collaborative work, voting and polling, etc.).

Probably the acceptance criteria at the level of the overall Flow software project should remain in WMF hands while those at the level of each workflow should be set by the communities.

One could even imagine that the criteria for a given workflow may be slightly different from one to another community... meaning Flow should support configurable workflows instead of rigid ones (and that's an acceptance criteria at the software project level).

Sänger S.Gtalk contribs

Flow is meant to support various kinds of workflows, with the current basic "discussion workflow" being just one of them (others include actual collaborative work, voting and polling, etc.).

As all this has to be ready to have it deployed to real WP-lemma talk-pages (all this use-cases are possibly there at some time for any article), it's probably really some years from deployment in the real world. So far it's just fit for some users talk pages, who want them this restricted, and perhaps some external, thus not so important, wikis, that only need blah-blah talk-pages.

Reply to "Acceptance criteria"

Extension

Reply • 3 comments •
3
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

Thanks!

Reply to "Extension"

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

Reply • 4 comments •
4
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.

Quiddity (WMF)talk contribs

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.

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

Indents

Reply • 20 comments •
20
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 •
2
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 •
5
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 https://trello.com/c/x8lHHkA6/

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"