What are the acceptance criteria for Flow?
The Core Features team has enabled Flow on this talk page.
- Please conduct testing at Talk:Sandbox, retaining this page for discussions and suggestions.
- If you find bugs not yet tracked, report in Bugzilla if you can, and here if you can't.
- 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
Is Flow going to be an extension, or will it be integrated into MediaWiki?
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.
What are the planned additional features, that would make Flow useful?
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.
Test level 1. Editing test level 1.
Test level 2
Test level 3
Test level 4
Test level 5
Does this indent?
Test level 2a
Test level 3a
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.
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 ;)
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.
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.
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.
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.
- "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:
- Wikimedia_Engineering/2014-15_Goals#Editor Engagement – Core Features This is scary stuff. Even thugh "This page is currently a draft." Uh.
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.
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).
When database changed in new version
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.
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.
Showing closed topics as collapsed by default
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.
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".
+1. The whole point of closing a topic is to reduce its visibility and avoid distracting people, I'd have thought. :-)
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/
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.
Making life easier
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. :)
Content stays in new topic box after saving
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
Huh. When I visit Talk:Phabricator/Help it appears just fine. Maybe the link from the notification doesn't work correctly?
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.
Aha, interesting. Thank you!
Topic appears two times
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
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).