Wikipedia talk:Flow
 | Please use mw:Talk:Structured Discussions instead, for centralized feedback. |
|
This page has archives. Sections older than 15 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
Concerns about flow
[edit]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)
- 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)
- 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)
- 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)
- 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)
- 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)
- "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)
- 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)
- 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)
- 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.
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- @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)
- @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)
- 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)
- 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)
- 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)
- 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)
- "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)
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)
- @Pi zero: That would be phab:T4308 I believe. Jo-Jo Eumerus (talk, contributions) 18:57, 25 September 2017 (UTC)
- @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)
- 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)
- 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)
- 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)
- (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)
- 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)
- 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)
- 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)
- @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)
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)
WMF is refusing to uninstall Flow on Commons
[edit]The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Commons established Consensus to uninstall Flow, as was done on EnWiki and on WetaWiki. The WMF has just posted a response refusing to uninstall Flow. Alsee (talk) 04:25, 3 March 2018 (UTC)
- I personally think Flow is wholly unfit for its stated purpose (and that's putting it mildly), but in this case I see WMF's response as reasonable. Shock Brigade Harvester Boris (talk) 05:12, 3 March 2018 (UTC)
- Shock Brigade Harvester Boris when you say the response is 'reasonable', do you mean that you would personally find it an acceptable result? Or do you mean you think it reasonable and worthwhile for the WMF to battle and further damage WMF-community relations over this? Especially when a volunteer dev has already done the work writing the patch to carry out the task? Alsee (talk) 06:20, 3 March 2018 (UTC)
Note: The WMF has opened a Phab task to build a superprotect level for Flow. Alsee (talk) 06:14, 3 March 2018 (UTC)
- Um, to me it reads like they are planning to remove all flow content sans some log entries, and that "superprotect" thing sounds more like permanent archival to me as well. Jo-Jo Eumerus (talk, contributions) 09:39, 3 March 2018 (UTC)
Talk pages consultation 2019
[edit]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)
request info
[edit]this idea sounds good. please keep me posted!! --Sm8900 (talk) 14:51, 30 January 2020 (UTC)
- Sm8900: You may want to watchlist mw:Talk pages project/Updates. --HHill (talk) 15:38, 30 January 2020 (UTC)
Should we re-export Flow boards with revision history
[edit]Over on MediaWiki.org I'm working on a script to export Flow boards to wikitext with revision history (a process that is much more painful that it looks for a wide range of reasons). You can see how it looks at mw:Special:Log/import/Flow cleanup bot. It just occurred to me that, since there are dumps of the Flow boards on enwiki before Flow was uninstalled, it would be possible to do the same thing here and replace the current manual exports of Flow boards with no history that were performed in 2016 with exports generated by that script from the dumps (modified slightly). Would that be a good idea? * Pppery * it has begun... 04:57, 6 March 2025 (UTC)
- This is probably not something I'll get to for a while anyway, but the idea occurred to me while I was spelunking old corners of the wikiverse and I'm interested in seeing what others think. * Pppery * it has begun... 04:58, 6 March 2025 (UTC)