Talk:Flow/Architecture/API/Archive 2014

enwiki bots that edit talk pages
I did a database query to find all bots that edited a talk page on enwiki in the last 30 days. I excluded archive bots, signature bots, and anything else that would be unnecessary with or unaffected by Flow.


 * Notifications (adding new sections)
 * BracketBot, Legobot, HasteurBot, Theo's Little Bot, ImageTaggingBot, DYKUpdateBot, RMCD bot, DPL bot, SuggestBot, Cyberbot II (also comments on the sections it creates), Cyberbot I, HostBot, DYKHousekeepingBot, EarwigBot, UcuchaBot, LaraBot, ReferenceBot, MadmanBot, Commons fair use upload bot


 * Cleanup (editing comments):
 * AnomieBOT, OgreBot


 * Editing page header (Wikiproject banners, etc)
 * ProteinBoxBot, DYKUpdateBot, VoxelBot, DumbBOT, Cyberbot I, Lowercase sigmabot, MenoBot II, AnkitAWB, SporkBot, MenoBot


 * Other:
 * JL-Bot

So except for a handful, the vast majority of bots fall into 2 categories. This also shows that there are some limited use cases to allowing bots to edit other peoples' posts. Mr.Z-man (talk) 02:19, 5 February 2014 (UTC)


 * Thanks Mr.Z-man. I used that and a database query from Okeyes, to compile more notes on bots, at Flow/Bots. More details welcome, and we'll need to research bots outside Enwiki soon, too. Quiddity (WMF) (talk) 20:58, 13 May 2014 (UTC)

Notes from Zurich Hackathon
From the Flow API session:


 * Mobile apps will in future talk to Flow over the API!
 * We need HTML of posts, but without UI cruft -- we need pure data for that stuff. This should be coming as I understand.
 * Fancy wiki features in posts -- extensions, videos, etc?
 * Currently there are two problems:
 * Parsoid doesn't handle all extensions
 * we don't know which JS modules are needed to trigger things
 * Possible ways around this: add a lightweight JS or server-side DOM postprocess that detects semantic HTML5 patterns for extensions and feeds back the JS modules you need
 * Note that the page header is not a plain wiki page like in LQT, it's another Flow object.
 * (maybe ContentHandler could make it act like that though, if that's useful for people)

Hackathon presentation
Presentation by S Page -- May 10, 2014

Flow is available for testing on Talk:Flow, Talk:Sandbox, WikiProject:Breakfast, several other pages.

S shows Talk:Sandbox, with Firebug open to show the API calls.

Creates a new topic. Right now, Flow supports wikitext. We're going to build a mini-visual editor for the Flow boards.

Posting the new topic -- it makes an API request.

One advantage to Flow is that it signs posts for you -- no more four tildes to create a signature, which is difficult for new people to grasp.

A Flow board isn't a regular wiki page. It's got a header. After that, it's an open-ended window into a bunch of topics. Topic is a title, comments on it, replies to the comments, and then replies to replies. There's two levels of reply-to reply.


 * Q: Why only two levels of nesting?


 * Maryana: Infinite nesting is hard on mobile, and it's hard to follow a conversation with infinite nesting.

A topic includes a title, a heading, and comments.

At the bottom of the page there's a link for older topics -- there's infinite scrolling, and you can see more topics.

Coming soon: the ability to sort so that you can see active topics at the top, new topics or old topics.

Permalink shows you the conversation.


 * Q: Is it possible for a user to enable this on Commons?


 * S: We turn it on with PHP, by request. Talk to Danny, the Flow PM, if you're interested in testing it out on a wiki that you're active on.

On WMF wiki, we store all the posts as HTML. This shouldn't have an effect on people using the API.

When you make a reply, a new post came in.
 * action flow
 * submodule reply
 * render true (you want it to respond with what the HTML should look like in the reply)
 * repcontent has the text of the reply
 * repreplyTo has a UUID which post you're replying to
 * workflow has a UUID for the topic you're replying to

Eventually, this will work cross-wiki -- you could have a discussion that shows up on Commons, on the WP page where the image is used, and on the user talk page for the user who uploaded it.

We use the word workflow because we want it to include not just conversations, but also the ways that people use talk now -- RfC, RfA, voting, etc.

Making a new post:
 * topic -- shows the UUID for the reply

We'll be adding more information that will be needed to render the post client-side. Right now, you only get the rendered HTML, but we're changing it to expose more data. We'll be using handlebars, just giving pure data in a JSON structure.


 * Q: What about embedding video, which might need JS to render?


 * S: It's wikitext, and we're using parsoid to turn wikitext to HTML. Parsoid's output doesn't have the icons, etc.


 * Brion: We may need to some extra steps to add the UI elements. Can you detect what's in the post?


 * Q: Is the module list on parsoid?


 * S: Good point! We'll have to look into this more. Parsoid needs to be more dynamic.

We'd love to have more clients for the API. Right now, it's just the JS client, and we know that works. We're very anxious to have other people use it, so we get it right. The best way to do that is to experiment on the Flow page, and see what it sends out.

It's all action=flow, and various submodules.

For the read API, the client is loading in more topics. When you do a preview, there's a call asking for the wikitext to flow parsoid util, to convert it to HTML.

list=flow -- you can ask for a view, header view, topic summary view, and it'll tell you what those things are.

One thing we added for people writing bots: Prop=flowinfo finds out if the page is flow enabled.

We plan on making a list available so people writing bots can experiment.


 * Q: A use case for Commons (GW toolset) -- right now, we've got Specialpage ext, it kicks off batchupload progress. Could we use this to update the user about what's going on? As you're processing 100 files, it posts on the user talk page to show we're 25% through, 50% through, here's the errors. Could we create a user subpage to test this?


 * S: Yes, we can make a Flow-enabled test page for you.


 * Q: How do we do that?


 * S: Right now, contact the Flow team. Andrew Garrett is working on converting our Flow board to a Content Handler type, to let admins enable Flow on pages. This is a really good example of a use case, thanks!

To reply to a topic, you'll need a token. See the Flow/Architecture/API page for more info.

The read API is based on queries right now (action=query), which accepts action parameters. Depending on the action you're going to do, it's going to accept different parameters. But it's not easy to see what parameters it uses without looking deep into the code.

We're going to make it more like the write API, using action=flow, with submodules to request particular actions.

The headers are just regular wikitext; right now, you can do anything you want.

Editing comments -- we allow people to edit their own messages, but it's restricted. So it's possible that bots may not be able to make edits. We may work on a way to let bots make edits. We need feedback from people about whether they need that. In the near-ish future, we're planning to let people opt in to have Flow on their own user talk page, so it would be good to experiment.


 * Q: Do you have filters so you can just get Flow-enabled items in recent changes? Is there a special namespace? There are bots that check links -- WebLinkChecker.pi -- and it would be good to post to the article talk page when it's Flow-enabled.


 * S: Right now, there's a "commented" link in the log items. We don't tag the items. That's a good question; we'll look into that.


 * Q: How do you archive?


 * S: There's two parts to it. Existing non-Flow conversations are moved to an archive. The Flow page itself doesn't do archive because it's open-ended -- you can keep scrolling. We're hoping that the action of archiving goes away. Logged-in people can hide inappropriate topics; people with rights can do moderation actions.


 * Maryana: We could adapt the hiding feature to become an archive for closed items.


 * Q: Is it possible to move a topic from one page to another?


 * S: Not yet.


 * Danny: I want to do that very much. We'll work on it.


 * Q: Is there going to be a migration path from LiquidThreads to Flow? Translatewiki.net uses LQT a lot, we'll need this. I'm really looking forward to moving to Flow, but we can't until we can keep the existing LQT content.


 * S: Andrew is working on an export script.


 * Danny: Let's catch up and talk about it.


 * Q: Is it possible to tag topics? I'm interested in some topics and not others?


 * Maryana: We don't have tags yet, but we're thinking about it.


 * Q: Do templates in posts update?


 * S: Not yet, but we're thinking about it.

Thanks to everyone for coming! We're in #wikimedia-corefeatures IRC all the time, come ask us questions.