*{{draft}} {{random person's idea}}* !!!
Executive summary: add Flow discussions to pages with {{#useFlow:1}}.
Converting a Talk page to a Flow board is disruptive and controversial. It delivers better conversations (for new and average users) right now, but it will be years before Flow nails all the other use cases for talk pages (collaboration, metadata, workflows). Our workaround for that period is to put stuff other than conversations in the Flow board header (nomenclature https://www.mediawiki.org/wiki/Flow/Nomenclature#Picture). Flow topics live in an external cross-wiki DB separate from the page, but I haven't seen a good use case why we need the Flow board header to be in this cross-wiki DB.
Maybe it doesn't have to be so black and white. Imagine a world where Flow topics appear on a talk page but it's still a wikitext talk page. Enabling Flow on a page would be like LQT – someone adds a {{#useFlow:1}} magic word to a page and it gets Flow discussions. We de-emphasize the Flow board header, because you still have an entire regular page for templates, categories, workflows and whatever.
*+ No disruptive conversion*
*+ No bugs with categories in Flow board header*
*+ Avoid issues with changing the content model of a page*
*+ No complaints about narrow Flow board header*
*+ No break in the page history*
*+ No need to for a tricky archive-existing script* Although admins might choose to run a bot to move old wikitext section topics to an archive when adding {{#useFlow:1}}. *+ Don't have to solve the other three talk page use cases* (collaboration, metadata, workflows) *to gain Flow's improved conversations*. *+ The Collaboration team is adding an optional feature to existing talk pages* *, rather than perception of usurpation and war*
*+ We get feature parity "for free"* A number of complaints about Flow boards shift, because part of the talk page remains wikitext that users can view-source, diff, revert, monitor, etc. in the usual way. Topics are still a very different animal. Bots don't break, they will add stuff to the wikitext. Special:Search can still find text in the page (but not in its Flow topics until we do the search integration we need to do regardless of this proposal). Page move, #REDIRECT, etc. all kind-of work.
*+ We gain flexibility* A pure discussion page like Talk:Beta Features/Hovercards https://www.mediawiki.org/wiki/Talk:Beta_Features/Hovercards can still be {{#useFlow:1}} and a minimal wikitext part. LiquidThreads did it this way and AFAIK the flexibility was useful and non-controversial. We could support different behavior, e.g. {{#useFlow:*42*}} might only display a link to Flow topics. See "Feeds" section below.
There are downsides.
*- Two ways to discuss on a talk page* If {{#useFlow:1}} then we would adjust the [Add topic] tab to jump to the *Start a new topic* Flow form. Still, old-timers would continue to create wikitext section topics.
*- Hybrid page user experience is messy*
*- Hybrid page implementation is messy and slow* MediaWiki has to load regular wikitext then load Flow topics, handle two kinds of JavaScript, etc.
*- The page gets infinite scroll behavior* (People keep demanding the notion of archives, if we respond to them and provide a way to move old and closed Flow topics, e.g. to a /All_topics_archive subpage, then a talk page with Flow topics could adopt an approach where it *doesn't* scroll forever. That is orthogonal to this proposal.)
*- The upcoming Flow TOC and fixed header has to coexist with regular page TOC* If Flow discussions are the last thing on the page then once you scroll down to them you're in a different kind of thing, so it's OK to get a different appearance. Like LQT. The {{#useFlow:1}} could automatically add a "Discussion topics" to the end of the regular wikitext TOC. Displaying all the Flow topic titles in the regular TOC is very hard, and impossible if there are hundreds of them, but maybe the TOC could display the first (newest) 20 topic titles.
*- Need to go two places to see full history of talk page* The talk page history (probably) wouldn't show all changes to the "Topics on the page", you'll still have to go to a separate board history.
*+/- "Flow board" goes away* We're already de-emphasizing actions on a Flow board. You watch individual topics, you get notified about them. "Flow board" evolves into the notion of "All the topics started on this page". *+/- People might add* {{#useFlow:1}}* to regular pages* On the rest of the web, you scroll down a page and arrive at discussions about it. There's value in splitting off discussion of an encyclopedia article from the article itself, but maybe WikiProject:Breakfast or even User:SPage doesn't need the confusion of a separate talk page.
*What about Feeds?* This ties into the "Feeds https://www.mediawiki.org/wiki/Flow/Basic_information#Feeds" feature, for which IMO we need a more concrete plan. As I understand it, the main reason for the pain (UUIDs, storagemodels, separate revision management) of a separate cross-wiki Flow DB is so that a conversation about an image in an article can appear on the article's talk page, also on the image's talk page on Commons, on the image author's talk page on Commons, and in the subscriptions of people interested in the article or image. This is fantastic, but in order to work when one of those talk pages isn't a Flow board we have to wrestle with all the issues of a hybrid page (TOC, infinite scroll, etc.), so why not do it now? I don't know how a Feed would be enabled on a regular talk page, but it sounds like an elaboration of this, {{#useFlow:|relatedTopicFeed}}.
Thanks so much for reading!
-- =S Page Collaboration team engineer
On 12/11/2014 02:38 PM, S Page wrote:
/{{draft}} {{random person's idea}}/ !!!
Executive summary: add Flow discussions to pages with {{#useFlow:1}}.
I don't like this idea. We should be moving away from storing metadata in wikitext and hacky parser functions and not adding more of them.
ContentHandler currently has some bugs because it really hasn't been tested outside of Wikidata, but I believe most of those are short-term issues and that it is the best way to integrate Flow into normal MediaWiki pages.
-- kunal
You could explore building some JavaScript that replaces links to Flow pages with a board. I think it would be really useful tool to generate arbitrary boards in talk pages. I do agree with you S, I personally think the dichotomy approach has a lot of problems.
On Fri, Dec 12, 2014 at 2:31 PM, Kunal Mehta legoktm@wikimedia.org wrote:
On 12/11/2014 02:38 PM, S Page wrote:
/{{draft}} {{random person's idea}}/ !!!
Executive summary: add Flow discussions to pages with {{#useFlow:1}}.
I don't like this idea. We should be moving away from storing metadata in wikitext and hacky parser functions and not adding more of them.
ContentHandler currently has some bugs because it really hasn't been tested outside of Wikidata, but I believe most of those are short-term issues and that it is the best way to integrate Flow into normal MediaWiki pages.
-- kunal
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Fri, Dec 12, 2014 at 2:31 PM, Kunal Mehta legoktm@wikimedia.org wrote:
On 12/11/2014 02:38 PM, S Page wrote:
/{{draft}} {{random person's idea}}/ !!!
Executive summary: add Flow discussions to pages with {{#useFlow:1}}.
I don't like this idea. We should be moving away from storing metadata in wikitext and hacky parser functions and not adding more of them.
Sure, there are other ways to implement "This wikitext page should show Flow topics" (e.g. a Page property). I mentioned LQT's implementation because I'm familiar with the way LQT allows a hybrid page (example https://en.wiktionary.org/wiki/User_talk:Yair_rand)
ContentHandler currently has some bugs because it really hasn't been tested outside of Wikidata, but I believe most of those are short-term issues and that it is the best way to integrate Flow into normal MediaWiki pages.
Are you supporting my idea of a hybrid page but disagreeing with the implementation, or preferring the current "disruptive" switch to content model=flow-board?
Thanks, -- =S Page Collaboration team engineer
S, I understand the desire for an easier "compromise" solution to the transition problem. But I think the system that you're suggesting would create a jumble of functionality that would be just as bad, if not worse, for the users who are trying to navigate it.
If people are going to work together on wiki talk pages, they need to be able to talk to each other. Seeing two different communication systems operating on different pages would be confusing enough. Having to choose between the two systems on the same page is just impossible for users to figure out. It tries to please everyone and would actually suit no one.
Right now, there are some important gaps in the use cases that Flow supports. We have to figure out how to create multi-editable Collaboration space, and we have to figure out short-term and long-term solutions for what to do with the yellow Metadata boxes. These are hard problems, and it's going to take us a while to figure them out.
But I think saying "let's do both at once" is basically giving up on the idea that it's possible to make something that's better than blank wiki talk pages and the template-heavy cultural practices that we currently see on the big WPs. We can do better than just add another confusing element to the page.
Danny
On Fri, Dec 12, 2014 at 3:31 PM, S Page spage@wikimedia.org wrote:
On Fri, Dec 12, 2014 at 2:31 PM, Kunal Mehta legoktm@wikimedia.org wrote:
On 12/11/2014 02:38 PM, S Page wrote:
/{{draft}} {{random person's idea}}/ !!!
Executive summary: add Flow discussions to pages with {{#useFlow:1}}.
I don't like this idea. We should be moving away from storing metadata in wikitext and hacky parser functions and not adding more of them.
Sure, there are other ways to implement "This wikitext page should show Flow topics" (e.g. a Page property). I mentioned LQT's implementation because I'm familiar with the way LQT allows a hybrid page (example https://en.wiktionary.org/wiki/User_talk:Yair_rand)
ContentHandler currently has some bugs because it really hasn't been tested outside of Wikidata, but I believe most of those are short-term issues and that it is the best way to integrate Flow into normal MediaWiki pages.
Are you supporting my idea of a hybrid page but disagreeing with the implementation, or preferring the current "disruptive" switch to content model=flow-board?
Thanks,
=S Page Collaboration team engineer
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Fri, Dec 12, 2014 at 4:37 PM, Danny Horn dhorn@wikimedia.org wrote:
S, I understand the desire for an easier "compromise" solution to the transition problem. But I think the system that you're suggesting would create a jumble of functionality that would be just as bad, if not worse, for the users who are trying to navigate it.
I completely agree with Danny on this. I think the road for Flow is "slow and steady wins the race" - covering the use cases we need to, in order to gradually transform wiki culture across projects, starting from the fastest-moving ones (smaller languages, projects that are willing to move over wholesale, new initiatives).