Wikipedia talk:Flow

Please use mw:Talk:Structured Discussions instead, for centralized feedback.

Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15

This page has archives. Sections older than 15 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present.

As if discussions on talk pages are not structured, the WMF in it’s infinite wisdom just decided to rename Flow to mw:Structured Discussions, the official ratio is this:

Structured Discussion was formerly known as “Flow”. Flow was a bigger project that has been re-scoped to focus on user-to-user discussions. The software has been renamed to reflect this change.

They fail to see the difference between a structure and bondage gear. And they obviously hate flexibility. Grüße vom Sänger ♫ ^(talk) 19:57, 14 September 2017 (UTC)[reply]

Wikitext talkpage are "structured" in a way that editors who are accustomed to the system can understand, but not always intuitively, e.g. interleaved comments, or inconsistent indenting, or bulletpoints mixed with colons.

Wikitext talkpages are not "structured" in a way that software can understand. E.g. the indented quote you pasted above, is not programatically identifiable as being written by you, except by analysing every single revision ever made to this page and significant changes to the "diff" system (which is easily confused by refactored (moved around) blocks of text).

Just like templates and databases bring consistency (and the possibility of powerful new features) to structured data, a structured discussion system brings consistency (and the possibility of powerful new features) to human discussion.

I know you dislike it, and I don't want to argue, but please ask any programmer that you respect for confirmation that wikitext talkpages are not "structured" in a software-sense. Quiddity (WMF) (talk) 20:30, 14 September 2017 (UTC)[reply]

Talk pages have the same structure as every other page at Wikipedia. Anyone who cannot deal with a talk page is unable to contribute in a useful manner. Of course people need help for their first few posts (and first few article edits, and first few attempts to add references), but help is part of a collaborative community. A simple script to add a comment is all that is needed: guess what indent to apply and whether to add four tildes. The script would cover most usage cases for a new user. Flow is fine for baby talk or for discussions where hard facts are being discussed, such as when someone is asking an expert how to perform some operation. Flow is useless for typical discussions concerning disputed topics with multiple views from multiple people. Johnuniq (talk) 23:06, 14 September 2017 (UTC)[reply]

I agree entirely with User:Johnuniq. I hope that the statement on the project page that there is no intention to return Flow to tne English Wikipedia is still correct. Doug Weller talk 09:12, 24 September 2017 (UTC)[reply]

Quiddity (WMF), I'm a programmer and I fully understand what you mean about structure. However 99% of the people on the planet aren't programmers. The name "structured discussions" may be obvious and natural inside the WMF, but it isn't going to be so natural and obvious for people who don't know about software internals and don't care. Under the plain-English meaning of the word, any normal person would say 'yes, the Wikipedia article for United States is structured'. This new name is clumsy, confusing, and trying to rename the project is pointlessly disruptive. We have countless megabytes of discussions and information about Flow. Are you going to spend the next few years trying to argue/correct people who keep calling it Flow? People who say Flow either because that is the only name they know, or because it's 18 characters shorter, or because they are using the most common name to ensure other people understand what they are discussing. You're really fighting human nature on the '18 characters longer' point. You'd have an easier time getting people to switch to 'Glix' or 'Zopy'. Alsee (talk) 09:03, 15 September 2017 (UTC)[reply]

Talk pages are for humans, the software is just a tool. If software can't read it, so what? It's the humans that should be able to read it in a proper way, and I don't think any human will have a problem with the structure of this topic right now. They will even grasp intuitively that this is an answer to you, and not to Alsee. If machines are not able to grasp it, they are not fit for talk pages, that's all. Machines are nothing we should put up first, they are just tools, not subjects. Grüße vom Sänger ♫ ^(talk) 09:13, 15 September 2017 (UTC)[reply]

I think that the discussion from top to bottom and infinite scrolling are really the principal nuisances of Flow, whereas the current talk page format I have difficulty in telling posts apart and to figure out which indentation to use, and having to sign posts and needing a bot for this is also irritating. Granted I am more used to the discussion style of TV Tropes which is very similar to Flow. I am interested to know whether users who are not long accustomed to Wikipedia would find such a modified Flow easier or harder to comment on than the current talk page format. Jo-Jo Eumerus (talk, contributions) 15:35, 18 September 2017 (UTC)[reply]

I did some HEAVY cleanup. I figured that this page was rather unreadable if you don't really care about flow development and just wanted to find out what it was about. Most of the information was 2-4 years old and did not help any user who is currently reading the page. Most information was duplicate with the mediawiki.org pages to begin with. I considered it best to keep to a short description of the product and its intent, a description of the current state, and the links to the relevant team and product pages. Is there anything that should be re-added that I had not considered ? —TheDJ (talk • contribs) 14:11, 15 September 2017 (UTC)[reply]

Should this page now be moved to WP:Structured Content, to match the mw: one? Though most of us here probably think of it as "Flow" now, it has a new name which will become the main name its known by as it continues to be maintained and developed.--JohnBlackburne^words_deeds 17:40, 15 September 2017 (UTC)[reply]

Maybe we wait until it really is the new name everywhere? I just looked at the "Beta" preferences on Wikidata, and there it is still called "Flow". —Kusma (t·c) 20:37, 15 September 2017 (UTC)[reply]

It is the new name everywhere, see translatewiki.net. It just takes a few days before it's updated to MediaWiki wikis. Stryn (talk) 07:51, 18 September 2017 (UTC)[reply]

No rush though, another week won't be a problem :) —TheDJ (talk • contribs) 09:00, 18 September 2017 (UTC)[reply]

So if we do move... do we move all subpages with it ? See: Special:PrefixIndex/Wikipedia:Flow and Special:PrefixIndex/Wikipedia_talk:Flow —TheDJ (talk • contribs) 07:46, 22 September 2017 (UTC)[reply]

@TheDJ: I would just move this page and talk. The others are just historical, but would have to be rewritten otherwise. --Jules (Mrjulesd) 14:39, 23 September 2017 (UTC)[reply]

I have concerns that Flow will result in no technical support for the current talk page system. It is claimed that wikitext cannot allow "per-topic notifications". I am not convinced this is true. One could improve the current wikitext so that it does allow this. Doc James (talk · contribs · email) 18:44, 23 September 2017 (UTC)[reply]

The current talk page system does not seem to need additional support, or so it seems to me. Jo-Jo Eumerus (talk, contributions) 19:26, 23 September 2017 (UTC)[reply]

I would love the ability to watchlist sections of talk pages. This is something many have requested. I do not see that it would be that hard technically. Would also be nice to have a version of VE that works on talk pages so new and old editors do not need to learn two or three systems of editing. Doc James (talk · contribs · email) 19:39, 23 September 2017 (UTC)[reply]

According to phab:T2738 there is a moderately complex solution for a particular case. Watching sections of pages in general would require a significant change of how wiki pages in general work. Making Flow compatible with standard markup is potentially a different solution to the "systems of editing" issue, not sure how hard that would be. Jo-Jo Eumerus (talk, contributions) 09:30, 24 September 2017 (UTC)[reply]

It seems fairly clear, standing back from details to see the big picture, that making Flow compatible with standard markup is an unrealistic goal. Trying to make a fundamentally different platform "pretend" to be like another, such as in this case, swallows up unbounded amounts of expert labor to chase after an unending supply of flaws in the pretense. It's easy to make things look just the same if at their foundation they really are the same, and ultimately hopeless to try to make them look just the same if at foundation they aren't.

There is, tbh, a structural flaw in the way the Foundation is positioned relative to the sisterhood. The Foundation has a powerful impulse to apply expert programmers to developing stuff for the sisterhood. What would actually be good for the sisterhood? A stable, simple, easy-to-use markup platform that vastly empowers volunteers, giving scope for their imaginations. This, though, clashes severely with the Foundation's impulse — in the long run, the Foundation's impulse leads to perpetual platform instability in the name of having expert programmers add things instead of empowering the volunteers to do them. Could the Foundation resist this impulse? Perhaps — supposing a concerted effort at the Foundation to build that resistance into its corporate culture. It's all made even more difficult because figuring out how to empower volunteers with simplicity is a much harder design task than adding specialized features that increase volunteers' dependence on tech support — and the harder design task flies in the face of what commercial social-media platforms seek to do (hence a fatal flaw in the Foundation comparing itself to any commercial platform). --Pi zero (talk)

Just a note.. If I read some of the tickets that are currently under consideration correctly, then it seems that Structured Discussion posts will be stored in wikitext again. Which doesn't mean they will be wiki pages, as there is a difference between a page and it's storage format (and in this case even the storage format of a part of the page), but does make sure that they'll be closer to wiki code parsing. —TheDJ (talk • contribs) 08:19, 25 September 2017 (UTC)[reply]

For what I know, that means only that every individual post will be stored in wiki markup; the structure of the page itself will not be represented by markup, but by a relational database schema. This is not closer to a wiki system than before, since it doesn't allow editors to define the structure of the page; as Pi zero said, Flow is a fundamentally different platform at its core. I find Pi zero's comment most insightful - the best the Foundation could do is empower the community to build and improve our own tools, but the WMF's gravitas pushes it towards building simple tools that will make editors more dependent on developers. Diego (talk) 08:51, 25 September 2017 (UTC)[reply]

"the structure of the page itself will not be represented by markup, but by a relational database schema." That is correct. —TheDJ (talk • contribs) 09:36, 25 September 2017 (UTC)[reply]

I don't think we are likely to ever have section watch listing.. Let's put it this way. If equals signs for headers are deprecated, and instead people need to use buttons like: Add new section, Remove section, Rename section, maybe then, we can think about watch listing sections. Before that, it seems highly unlikely to me. —TheDJ (talk • contribs) 08:19, 25 September 2017 (UTC)[reply]

What does the internal representation have to do with the user interface? Equal signs for headers are good enough for the parser to detect the location of each subsection for the Table of Contents, editing sections and creating edit summaries; I don't see a reason why they couldn't also be use to generate targetted notices. Diego (talk) 08:53, 25 September 2017 (UTC)[reply]

Header identifiers are not unique, not stable, don't reliably indicate start and/or end of a section, aren't stored atomically (we store pages, not sections) and can be moved or even deleted, untraceably from pages. Retroactively adding or inferring such details from wiki code is fragile and complex (building a parser on top of a non-stable parser) and most importantly I think, terribly resource intensive as well. We are already having trouble with people with 100000 or more pages on their watchlist, if we additionally would have section watch listing implemented with such weak underpinnings, watch lists would become a significant performance problem for which there would not be an immediate solution. I went with explaining this problem in UI concepts :) —TheDJ (talk • contribs) 09:32, 25 September 2017 (UTC)[reply]

There is an alternative approach detailed in the ticket, where we basically ignore most of those problems (Nemo's approach). I personally call this the 'lossy' variant. But I think that a big reason people have reservations about that approach, is that it's just moving the goal post of complaints. So when that works (still, or possibly with even MORE performance problems btw), people will start complaining about sections suddenly disappearing from their watchlist, archiving not working etc. and will be stuck further down on the dead end road —TheDJ (talk • contribs) 09:51, 25 September 2017 (UTC)[reply]

I think that 'lossy' variant has great potential, and would be a welcome improvement, covering a large number of cases. As long as its users develop an accurate mental model ("you're following a section named 'xyzzy' "), they would understand why and how the section is no longer being followed (e.g. "section 'xyzzy' has been renamed to 'foobar' "). The software could avoid complaints by providing support for fallback situations, such as issuing a last notification when the section is renamed or archived, and/or going back to tracking the whole page in those cases (with a notice explaining the cause). Diego (talk) 10:21, 25 September 2017 (UTC)[reply]

@Diego Moya: How would you expect multiple watched sections on the same page to be handled in such a situation ? —TheDJ (talk • contribs) 15:02, 25 September 2017 (UTC)[reply]

@TheDJ: By creating several search filters for the same page, one for each followed thread, and each with its own text pattern, no? I don't see any particular problem in that. More problematic would be what happens if several sections share the same name, like "Arbitrary break". But even then if users are aware of how the filter works, i.e. that you subscribe to "sections with string YYY in their title". And the community could work around the problem, by avoiding exact duplicate titles. I think that's a small price to pay for the flexibility of avoiding a strict discussion model with unique IDs for each thread, and is consistent with the mental model of "everything in a wiki is a raw text string with markup". Diego (talk) 17:55, 25 September 2017 (UTC)[reply]

"no technical support for the current talk page system" There is no current talk page system. There is no functional difference between a wikipage and a talkpage, other than that wikipages have even namespace numbers and talk pages have uneven namespace number. Both therefor have the exact same amount of technical support. —TheDJ (talk • contribs) 09:43, 25 September 2017 (UTC)[reply]

Alternatively, there is a feature I've had on my wish-list for years. For lack of a better name (suggestions?), call it "subwatch". The idea is that, in addition to marking certain individual pages as watched, one can mark certain pages subwatched; subwatching doesn't directly affect which edits show up on your watchlist, but it does help you to watch subpages of that page. Thus:

• At the moment you first mark a page P for subwatch, P and all its subpages go on your watchlist.
• Whenever a new subpage of subwatched P is created, that newly created page immediately goes on your watchlist.
• Those are the only two things that are actually done by subwatching P. At any time you can choose to unwatch any subpage of P, or you can even unwatch P itself, with no affect on the subwatch on P: even though you might not be watching P itself, any newly created subpage of P will be automatically watched.

You could, for example, set yourself up to automatically watch all nomination pages for a certain type of nominations, and then you could unwatch the ones that you decide aren't going to be of ongoing interest to you. On Wikibooks, of course, this could be hugely convenient, if you're interested in a particular book and want to know about anything done to it (including addition of new modules to the book). On Wikinews — and perhaps elsewhere, who knows, perhaps even on Wikipedia — one might set up some sort of hierarchy discussion arrangement that would put each comment on a separate page and use the subwatch facility to help tie them all together. --Pi zero (talk) 17:32, 25 September 2017 (UTC)[reply]

@Pi zero: That would be phab:T4308 I believe. Jo-Jo Eumerus (talk, contributions) 18:57, 25 September 2017 (UTC)[reply]

@Jo-Jo Eumerus: Hm. Interesting. There seem to be some similarities. I think what I'm describing would be much simpler to implement, easier to use, and perhaps effectively more powerful because of its simplicity. --Pi zero (talk) 19:10, 25 September 2017 (UTC)[reply]

Using subpages is what LQT basically did. If I remember correctly, that was causing significant performance problems though (exploding the pages table of the database). Not sure if those performance problems would still be an issue. —TheDJ (talk • contribs) 20:30, 25 September 2017 (UTC)[reply]

Well, sort of yes. Using subpages is certainly part of what LQT does. It also does some other things that are quite unpleasant (although we still use LQT on en.wn, to this day, even though we agree it's nasty for most purposes, because for the specific thing we use it for we've found it more effective than a wiki page — and yes, we did discuss Flow some time back and concluded that, for the one purpose where LQT was more effective than an ordinary wiki page, it was also superior to Flow... but I digress). --Pi zero (talk) 20:51, 25 September 2017 (UTC)[reply]

I might point out, though, that the device I'm describing would, I believe, be immensely useful for the other things I was mentioning, regardless of whether one chose to use it in that particular highly-inefficient way. Granted, the relevance to the current discussion is for talk threads. --Pi zero (talk) 21:08, 25 September 2017 (UTC)[reply]

(Or I could just be misunderstanding the other proposal... sigh. Well, the current notification system does a lot to improve things.) --Pi zero (talk) 14:25, 26 September 2017 (UTC)[reply]

I wrote up this essay about improving wikitalk a couple years ago, back when some people were still serious about implementing flow. Everything I wrote remains valid. User:Oiyarbepsy/Wikitalk: The Next Generation. Oiyarbepsy (talk) 17:04, 3 March 2018 (UTC)[reply]

The foundation is running a consultation on what to do about Talk_pages (implicitly including discussion of what, if anything, to do about Flow). Everyone is invited to participate in the RFC at WP:Talk pages consultation 2019. Alsee (talk) 13:56, 24 February 2019 (UTC)[reply]

this idea sounds good. please keep me posted!! --Sm8900 (talk) 14:51, 30 January 2020 (UTC)[reply]

Sm8900: You may want to watchlist mw:Talk pages project/Updates. --HHill (talk) 15:38, 30 January 2020 (UTC)[reply]