Wikipedia talk:Flow/Archive 7

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 5

May I assume that this annoyance will disappear under Flow?

In the process of making these edits,[1][2][3] I fixed a number of bad links caused by archiving.[4][5][6][7] may I assume that Flow will make this sort of silliness unnecessary? --Guy Macon (talk) 19:44, 16 December 2013 (UTC)

It should, as I understand things; links to and between topics will be absolute rather than relative. We've still got some way to go to make the URLs non-hideous, mind.

(Nice to see you feeling better, by the way; hope the health issues are clearing up :)). Okeyes (WMF) (talk) 20:16, 16 December 2013 (UTC)

BUT... If Flow eventually replaces a talk page, the current idea is to move the content of the corresponding pre-Flow talk page to an Archive sub-page. This means that ALL the links to that pre-Flow talk page will have to be updated. Would it not make sense to keep the old talk page where it is, have Flow linked with e.g. a sub-page of it and do some work on the Talk tab and talk page to recognise when the Flow sub-page should be called? I know it's pretty draft as an idea, but I'm really concerned with the billions of links that would either become obsolete/wrong or would have to be updated. IMHO, this issue should be somehow tackled globally. Klipe (talk) 23:55, 16 December 2013 (UTC)

In the present-day system, there are bots that fix links to discussions after they are archived. Perhaps bots could handle some of these things as well? I would certainly expect that discussions under Flow could include internal links that go to archived pre-Flow discussions. --Tryptofish (talk) 00:26, 18 December 2013 (UTC)

Yes – it's important to remember that we'll be rolling Flow out slowly and progressively (not all in one go), so we have plenty of time to work out how to set up some bots/scripts to update the links of pre-Flow discussions :) Maryana (WMF) (talk) 18:52, 18 December 2013 (UTC)

@Klipe: The current system (archiving things to a subpage) is exactly what they'll be doing with the current content when a page is Flow-enabled. So, yes, there will be broken links, but exactly the same amount as for regular archived discussions. Eg. Wikipedia talk:WikiProject Video games would get 1 more page added to the 102 archived-discussion subpages it currently has. Quiddity (WMF) (talk) 22:29, 18 December 2013 (UTC)

@Tryptofish: Afaik, only Cluebot III does the "fix backlinks pointing to archived sections" task, and only for the pages that it is assigned to archiving.

@All: It certainly would be interesting to explore other options, as long as they don't require thousands of volunteer hours. Particularly for pages that don't currently have any archives. I was (privately/personally) contemplating some sort of "stick some of the old content in a read-only post at the bottom of the Flow Board" type thing... eg for pages like Talk:Bohemian Waxwing and Talk:Florence Fuller (both are recent FAs, and with very few (and quite recent) threads). I'm not sure if that would be too confusing? or better than archiving? or complicated to develop? - just an idea, and more [feasible] ideas would be great! Quiddity (WMF) (talk) 22:29, 18 December 2013 (UTC)

Quiddity, there are discussions on my watchlist where AnomieBOT does that too. About your question to all, perhaps the simplest thing would be to make all talk pages that don't have any archives into a single archive for each such page; I think the most important thing is simply that it be easy to navigate to them from the new Flow discussions. --Tryptofish (talk) 22:39, 18 December 2013 (UTC)

@Tryptofish: Looking through AnomieBOT's tasklist (so huge!), I only see User:AnomieBOT/source/tasks/ACNClerk.pm mentioning updating crosslinks. However, possibly it's an undocumented (there) task at other pages. Good to know.

Re: Simplest thing: Yeah, that's the currently proposed solution. I'm not sure if there are other options that are both better and feasible. Quiddity (WMF) (talk) 00:19, 19 December 2013 (UTC)

@Quiddity (WMF): I do encounter broken links occasionally, so I don't think that there is a working process yet, valid on all Mediawiki-based wikis, that could be used in the context of the transition to Flow. There are processes, based on bots, on some wikis, for some pages... The huge amount of would-be-broken links due to the transition to Flow, as well as the anticipated wide scope of Flow deployment make me fear that these existing ad hoc solutions may not be efficient. They will be sufficient for project talk pages on WP:en and a few other ones, but what about everything else? I don't have a miracle solution to propose, rather suggest this being though carefully. Maybe "designing the transition to Flow" would deserve a dedicated page where ideas could be brainstormed and evaluated against several types of talk pages and wikis. Klipe (talk) 10:09, 19 December 2013 (UTC)

Future feature planning

Last week, the Flow team had a meeting to discuss some of the features that they plan to prioritize for the next 3 months.

The (very large) raw list is at mw:Flow Portal/Release planning, where the potential features are in 5 categories (or "buckets"). They're roughly arranged by a mixture of difficulty and priority, such that items nearer to the top of each list are the most likely to be concentrated on. Disclaimer: All ordering and notes are rough, and details will definitely change over the course of the quarter. Also, they definitely can't create everything listed there in 3 months, but those are the items currently on the radar, and known to be desired. They'd greatly appreciate your feedback on:

What other items should be considered?
What items are you particularly looking forward to, that could perhaps be prioritized higher?

(Sidenote: You can also see the slides from Maryana's brief introductory-presentation at File:Flow 2nd release planning.pdf although much of it was elaborated on in dialogue, so apologies if points are unclear.) Thanks, –Quiddity (WMF) (talk) 01:22, 10 December 2013 (UTC)

I see plenty of good ideas in this list. Here are some suggestions and comments.

Search/browse/filter - One of the sort order of flow topics (or better for me a sort of a real table of content of all topics without loading their content) that I would find really useful is "by topic creation date" (i.e. not the date of last edit of the topic title but really the date of initial creation of the topic) as this would be the most stable order. Maybe the usefulness of this sort order would decrease over time, but for existing contributor this could be an important feature to help transition from old talk pages to Flow boards. I would put this rather high on the priorities list.
Search/browse/filter - "see (a user's) contributions in one place": I would put this higher in priority. It's very much useful to have all contributions of a single user together in one list, also to counter vandalism.
Widgets and workflows - "Topic/Header undo. As an admin, I want to be able to undo the most recent change to the content of the header/topic title so when there is vandalism, I don't have to copy/paste the old content."
- I'm very much surprised to see a link between admin and anti-vandal fight. Counter vandalism requires lots of resources. Leaving this to admins would totally overload them.
- The ability to revert to any previous version should be made available to more contributors, at least autopatrolled ones (although this choice could be let to each wiki via some site-level setting). Otherwise vandals will quickly learn to edit twice in a row, possibly with different users/IPs.
- As owner of my own user board, I want to roll-back to any previous version (similar to the current possibility to edit an old version and save it as the newest version of the page). I would enable this for any registered user.
As a user, I want to have the ability to look at the wikitext of other users' posts (learn by example).

Klipe (talk) 21:20, 14 December 2013 (UTC)

The rationale for 4 is an interesting one (and a good one!); I was thinking of it more as 'we're discussing content changes, we reach consensus...and now we can't copy it over to the article. Well, crap'. More good reasons to do it, I guess :). Okeyes (WMF) (talk) 17:46, 16 December 2013 (UTC)

@Okeyes (WMF): Update mingle:638 as needed. Quiddity (WMF) (talk) 22:06, 18 December 2013 (UTC)

@Klipe: Re: 3.1 - that's just bad wording on our part. The notes were from a brainstorming session, and contain inexactitudes. (Mixing personas/roles). I shall fix that one.

Re: 2 - I'm not sure why that's even in there. It should be resolved once bugzilla:57868 gets merged and pushed-live.

Re: 1 - The mw:Extension:CirrusSearch updates are coming along at the moment, and once that's more stable, the Flow team will start developing the search possibilities. Definitely a lot of potential goodness, here. :) Quiddity (WMF) (talk) 22:06, 18 December 2013 (UTC)

@Okeyes (WMF) & Quiddity (WMF): Thanks for the positive answers. Do you know about when can we expect to see the next update on ee-flow.wmflabs? Klipe (talk) 09:54, 19 December 2013 (UTC)

@Klipe: ee-flow.wmflabs updates regularly (sometimes a few times a day) with various updates and patches.

We're still trying to work out the best way to let anyone who wants to know about the prolific details - There's these 2 pages in git and gerrit for the high-velocity firehose of info, but anything less than that would require some heavy hours of manual culling and delving... :/

I'm planning on creating a concise overview of the big-ticket items that were recently added/fixed, at some point before the new year. I'll probably just add that in a thread here, as I'm thinking that the Newsletter subscribers probably just want to hear about items where they can give feedback. Quiddity (WMF) (talk) 22:58, 19 December 2013 (UTC)

@Quiddity (WMF) An overview of the main changes would indeed be welcome, as it's otherwise difficult to know what to look at, what to test. Anyway, with the raw lists you provided, I already spotted some interesting improvements such as Special:Contributions now including Flow updates! @DevTeam: keep on with the good work! Klipe (talk) 15:58, 20 December 2013 (UTC)

Flow - a quick news update

I've left posts at the 4 WikiProject pages seeking their confirmation of readiness. Here's the excerpt of the "What's new and coming soon" part:

Here's a synopsis of what's been added recently (which you can test at mw:Talk:Sandbox):

mw:Special:Contributions now works properly again.
3 viewing options: normal, collapsed, and small for a Table of contents-like view of the page
Attribution of moderated content (see mockup image)

Here's a list of items that they're working on this month as top-priority, which will be added to the live software as soon as possible (some likely before the WikiProject trial period).

Next two weeks:

A more condensed "small view" (see mockup image)
Attribution of edited content (see mockup image)
Replacing the roll-over links (e.g. "Reply") with static links, and moving the permalink/moderation tools into an "action menu" (see mockup image)

Next four weeks:

Better automated edit-summaries (see notes)
Abuse-filter integration (see analysis)
A "thank" button (that works like the current thank feature)
A system to "Close and summarize" an entire topic (equivalent to {{hat}} etc)

Beyond that, there's the long list of brainstormed features, at mw:Flow Portal/Release planning#Feature buckets - your feedback and suggestions would, as ever, be most appreciated. The more we/you speak up with good insights, the faster it will turn into the discussion&collaboration system we've always wanted and needed. Thanks again. Quiddity (WMF) (talk) 00:33, 24 December 2013 (UTC)

Full Wikicode/WikiHTML supported?

Someone mentioned that wikicoding is now fully supported by Flow and its editor. Is that correct? I remember mentions of needing a scratchspace to accommodate the non-support. Now En.Wiki has a scratchspace, called [[Draft:]] (see WP:Drafts). -- 65.94.78.9 (talk) 20:11, 22 December 2013 (UTC)

See for yourself. And the draft namespace has been put forward for reasons completely unrelated to Flow. Making it a "scratch space" would be a misuse of it. Keφr 21:12, 22 December 2013 (UTC)

(edit conflict) Yup, wikitext is working fine - You can test it at mw:Talk:Sandbox. (or see existing test examples like this)

The within-Flow-scratchpad idea is still a possibility, if it is needed/wanted. Essentially, (I think), it would be a "post" without any editing restrictions, and it's [only/mainly] needed because Flow is currently configured to only allow the original author (if logged-in) or an admin, the ability to edit posts. See the "Comment editing" section in Wikipedia:Flow/FAQ#Components of the discussion system for more details.

(The new Draft namespace is not really related to this at all.)

HTH. Quiddity (WMF) (talk) 21:16, 22 December 2013 (UTC)

FWIW, I can see an argument for having discrete scratchpad pages as well (things like GANs come to mind). But, we'll see :). Okeyes (WMF) (talk) 20:11, 26 December 2013 (UTC)

Note that whatever is supported, the result may not be consistent with how it appears on non-Flow pages because Flow uses its own layout decisions and style sheets. I perceive this as an issue and I don't understand why the Flow effort/project/extension/... focuses so much on the layout. For instance, why using different fonts (typeface, size, colour) than what's defined in the user's preferred (or default) skin? Why fix the board width, unlike regular wiki pages content? With such layout constraints, it seems impossible to integrate Flow boards within page ensembles that also include regular wiki pages. For example, some wikiprojects set a common header on the project page and its corresponding talk page: transcluding this same same wikiproject header into the flow board header doesn't produce the expected consistent result. Or at least I couldn't find a way to achieve this... I see great potential in the functionality part of Flow, for both new and existing contributors. I see much less value in many of its layout details and would love to see these tackled as a new skin, which would encompass more than just the talk pages (and possibly become the default one if that's what most new users would like most). Klipe (talk) 08:58, 31 December 2013 (UTC)

Flow feedback

I was asked to leave some feedback. Firstly, let me say that I am always supportive of changes where benefits outweigh the problems. This can even include losing some functionality in order to get different better functionality. Unfortunately, this is not how feel about Flow.

I probably come across as harsh, but there are few things in modern UI tendencies that I hate more than making everything spacious and littered with inconsistent shiny buttons and links like Flow does. There is little constructive and specific feedback I can add to the development of Flow, because I simply disagree with the design methodology the project has taken. To put it bluntly, I do not like Facebook-ation of our talk pages. This isn't a social network and most editors are power users that use talk pages to read and participate in hundreds of threads and use syntax and edits that Flow simply can't allow in principle. I guess my biggest problem is that Flow isn't a smart talk page parsing, it's a completely different system in parallel to existing stuff.

I understand there is no way WMF will not be taking this social-media-style-comment system approach, as new editors prefer "pretty simple interface" and are more likely to engage. I was asked to provide my feedback, but I'm afraid I'm the kind of person that would ask to implement current raw talk page system if Flow was already the default first. Sorry for this being a rant, rather than a proposal of alternate solutions or improvements, but--being a software developer myself--I'm not sure how useful "just scrap it all and enhance current system" is. — HELLKNOWZ ▎TALK 22:29, 24 December 2013 (UTC)

That's okay; it's useful feedback nonetheless :). Largely I echo what Quiddity said at your talk page - could you expand on individual points? An example would be 'inconsistent buttons': which buttons are inconsistent?

For what it's worth, I'm one of the power users you mention: I'm still trying to piece together how I'll work with Flow, and how Flow will work with me. Things like the broadly-spaced text don't work perfectly for me, but I understand the rationale behind them - that being that actually, most Wikipedians aren't power users who use talk pages: a lot of them, particularly newer ones, avoid talk pages all together. We ran a survey of new contributors (I'm about to run another one, which I'd also appreciate feedback on - poke me if you want a link) that found that of 516 new users (people who joined in the last month), only 69 were both aware talk pages existed and had tried editing them. So there's obviously a pretty substantial space between where talk pages are and where they should be to get people communicating with each other.

Obviously, making it work for newcomers is not the only factor in our decision-making by a long way - it needs to work for experienced users too. This is about rebalancing the current, slanted system, not biasing it in the other direction. So any and all feedback on things like the UI design would be appreciated (Why do you disagree with the design rationales, for example? What are your counter-arguments?). In the meantime, thanks for your comments so far :). Okeyes (WMF) (talk) 20:18, 26 December 2013 (UTC)

I understand the rationale, which is why I'm being deliberately vague as I don't want to get lost in cosmetic concerns. I have refrained from posting my feedback for a long time because I know how subjective and consequently unhelpful it is to condemn the entire project. I realize you and your colleagues are looking for concrete feedback and not some wishy-washy "I just don't like it, Facebook sucks, wah wah". But there is no way anyone involved will simply scrap the whole idea and just work on enhancing current talk pages. The fact is, more new users will engage pretty interface and most existing users will learn to live with it. For every argument against Flow, you will provide an argument pro Flow. This isn't a debate I can "win", in fact I support Flow because I know that at the end of the day Flow will most likely improve the project.

I have no doubt that if I were to post a long list of feedback items, you will take some of my specific concerns onboard and indeed make the system better. But I am the wrong person to ask. I am on the wrong ship and that would be like asking what color to paint the mast. I'm still on the wrong ship. — HELLKNOWZ ▎TALK 21:06, 26 December 2013 (UTC)

That's...a lot more enlightened and reasonable than the comments I'm used to receiving ;). Mind you, a lot of those comments were for AFT5, so...apples, oranges.

I am slightly saddened not to get concrete feedback, but I understand your position. FWIW, we're planning on making a ship that works for the same sailors, so if you see any parts that do need backwards compatibility, or do need changing (as minor as text or as major as indentation), please do let us know. Okeyes (WMF) (talk) 21:22, 26 December 2013 (UTC)

Note also that Hellknowz just expressed exactly what I wanted to express at this page several topics above, but apparently failed. I strongly suggest to hold a RfC on the issue, as I suspect that the majority of users just do not like the whole idea of FLOW, and you guys are just wasting your time developing a tool which is not to be used. It would be easier to stop it now than to wait until the second AFT disaster comes, with the difference that AFT could be ignored, and FLOW will be impossible to avoid. Would be glad to see that I am wrong and this is just my personal problem.--Ymblanter (talk) 23:05, 26 December 2013 (UTC)

We're currently holding multiple straw polls over the first deployment; they pass, it gets deployed, they don't, it doesn't. I think holding a site-wide or movement-wide RfC on this is probably a flawed idea (although I've debated it, as have Quiddity and Maryana); the problems are (1) it's inherently biased, because the only participants are those who can at least tolerate the current system and (2) it's impossible to give an accurate portrayal of what flow will look like when it's "finished" based on where we are now. That's why we're opting for many small polls at each stage of release (and therefore each stage of development). Okeyes (WMF) (talk) 23:12, 26 December 2013 (UTC)

Alas, a lot of the comments I have seen about Flow are examples of Baby Duck Syndrome. Useful feedback? Not so much. :( --Guy Macon (talk) 17:46, 27 December 2013 (UTC)

You do realize that I maintain a web page and I am pretty active in various (social) media since 1995, right?--Ymblanter (talk) 17:53, 27 December 2013 (UTC)

Your point being? You do realize that "straw poll participants" != "Ymblanter", right? (Smiles at 1995 reference, continues using Gopher...) --Guy Macon (talk) 19:15, 27 December 2013 (UTC)

You have heard two opinions here, on one you have been wrong, at best 50% success (and I suspect 0%). Right, Gopher, Mosaica, Newsgroups, Windows 3.0, Unix for X-terminals etc. Sure, we all would be happy to go back to the stone age of internet because of the Baby Duck Syndrome.--Ymblanter (talk) 19:20, 27 December 2013 (UTC)

I have absolutely no idea what you are talking about. Okeyes mentioned that WMF is holding multiple straw polls and mentioned two problems that they need to be aware of. I mentioned a third problem. Being aware of things like selection bias and Baby Duck Syndrome can only help their efforts. I fail to see how my discussing potential problems with running a straw poll concerns you in any way. More light and less heat, please. --Guy Macon (talk) 20:18, 27 December 2013 (UTC)

I thought you are explicitly referring to Hellknowz and me as the only two users in this thread who provided negative feedback on FLOW. Apparently, I was wrong. Sorry for misunderstanding. I am still of the opinion that we are running towards the second AFT disaster, but this opinion does not seem to be of interest to anybody, so I would rather shut up and wait until the disaster comes.--Ymblanter (talk) 20:30, 27 December 2013 (UTC)

Can you all promise to never write sentences like "only participants are those who can at least tolerate the current system" again? I find the idea that listening to the people that helped build English Wikipedia is somehow inadequate horribly misguided. We know what it took to build it and we know what gets in our way.—Kww(talk) 20:28, 27 December 2013 (UTC)

In my opinion, you misunderstood the implications if that statement. I don't think that anyone thinks that listening to the people that helped build the English Wikipedia is somehow inadequate, nor do I think that anything resembling that was implied. Biased does not imply inadequate. Perhaps an analogy would help me explain it. Consider the computer keyboard on the original IBM PC. Let's say that you are doing straw polls on a new design for the upcoming IBM PC AT, and you poll experienced touch typists. They will give you very useful feedback on key stiffness, placement, and travel. They might catch problems like the fact that the SysReq key is useless, or that the caps lock should work like the one on a Selectric. (tHE WAY THE pc DOES IT IS STUPID!) They will be rather useless on the question of whether the keycap legends are visible enough -- that requires a hunt-and-peck typist. And they just might conclude that a mouse is not very useful because you have to take your hands off the home row. You wouldn't want to ignore them, but you should be aware of the natural bias that comes from being an experienced tough typist. --Guy Macon (talk) 22:09, 27 December 2013 (UTC)

After following the discussions about Flow and VE, I don't think I'm misreading things at all. It seems evident that input from people that have experience with the site is devalued relative to the notion of what a new user would prefer, despite there being no reliable way of measuring what actually helps new users. It seems to stem from the notion that Wikipedia is somehow failing due to a lack of new editors. I wonder about that. Four million articles isn't enough for a foundation? Are we falling behind in our ability to track the latest movements of every celebrity? Do we not have enough lists based on strange intersections of categories? Is our coverage of India soap operas insufficient? —Kww(talk) 22:50, 29 December 2013 (UTC)

If you mean fandom, listcruft, and sports-statistics articles, that's probably not the main risk area. If you strip out everything like that, and all the non-notable places imported from geographic databases etc, you'll hit a bedrock of at least 500k essential articles. How many of those are satisfactorily written and referenced? 10%? Maybe 15%? Per Wikipedia:Good articles/Summary "adding good and featured articles and lists together gives a total of 50,409 articles". I reckon we're just scratching the surface of creating a proper encyclopedia. How many active, productive, reference-citing editors do we have? Not enough! We need to attract and retain new blood – bright, energetic, well-educated people who have many other calls on their time – to deliver the next wave of improvement. - Pointillist (talk) 00:19, 30 December 2013 (UTC)

To attract new content builders, Wikipedia needs methods to quickly resolve disputes (even if the wrong decision is made), and needs procedures to readily remove or topic ban POV pushers. Adding buttons to make chatting easier is unlikely to attract anyone capable of building a proper encyclopedia. Johnuniq (talk) 01:32, 30 December 2013 (UTC)

If Flow is done right, it might help with the former. For example, no more procedural closes due to "wrong venue" (just attach the thread to the proper venue, which is easy and does not cause edit conflicts), discussions relevant to a particular page will be in one place, discussion invitations can be made easier. Of course, that is a big "if". I keep saying that Flow will be pointless if limited only to user talk pages: the most significant feature will be threads visible in multiple places. (Now that I think of it, if Flow is done right, there will be no need for "user talk pages" at all — since every thread is relevant to a Wikipedia page, they should be attached to that page, instead of users' pages.) Keφr 18:28, 30 December 2013 (UTC)

Mhm. The idea of non-fragmented discussions is a big part of what initially got me interested in Flow. (Eg hooking together FAC and AfD discussion with the articles themselves, and potentially Wikiprojects and main editors getting to add those discussions into a easy Feed.) Making that work perfectly (and adaptably) is immensely complicated given all the potential variations, hence Everything is being built slow & steady, with continual requests for feedback & suggestion.

(I had the same thought about usertalk pages! But, they'll probably always be wanted both for socialization/friendliness, and for hesitant editors/questions (some people feel more comfortable 1-on-1, rather than asking an entire "room" of people). Quiddity (WMF) (talk) 23:41, 30 December 2013 (UTC)

An editor that couldn't handle reference templates when released and a talk-page mechanism where we still can't get a firm commitment to handle wikitext and templates don't make me think that editors that are inclined to create satisfactorily written and referenced articles is the target demographic. I'd love to see mechanisms put in place to attract people that would do a good job of writing scrupulously sourced articles. Do we have a method of determining whether the people that like any individual flow feature are from the group that writes well and is willing to provide accurate citations vs. which appeal to the group that wants to simply add material based on their own personal opinion and hearsay?—Kww(talk) 03:07, 30 December 2013 (UTC)

"An editor that couldn't handle reference templates when released". I entirely agree with that. I suppose that to the WMF it appeared to be safer to "evolve" the new editor in an Agile-ish way rather than do a big design up front that took citations seriously. I'm not entirely unsympathetic. WMF's fund-raising implies that the cash is needed to run the servers but they have far more than they need for that, what they desperately need is editors and they are naturally casting around for initiatives that will attract them. Having a WYSIWYG UI will be a good thing. A modern issue tracking & discussion system will also be good. Whether VE and Flow will ever be fit for those purposes remains to be seen, but anyway those aren't enough to attract desirable contributors. If I were in charge I'd take some of the spare cash and invest in building a world-class reference/research system to take the pain out of finding and citing sources properly. That might actually make a difference! What do you think? - Pointillist (talk) 13:06, 30 December 2013 (UTC)

Just to note that there is a difference between VE and FLOW. VE is an opt-in feature (and it used to be an opt-out feature), which means that those who do not want to use it just ignore it (my understanding is that this is a vast majority of editors in the English Wikipedia). FLOW can not be made opt-out: It is either there or not. Concerning the reference system, could you please expand a bit what you mean by it? I do not quite understand.--Ymblanter (talk) 13:13, 30 December 2013 (UTC)

@Ymblanter, that's a good point about Flow being "big bang" rather than opt-in. About the referencing system, you can find some of my ideas in VE Feedback 2013 Archive 13. Those thought-starters are mainly about making better use of the existing corpus of references. In addition I'd like to have a guided research system that helps you to find the best reliable sources for your content, maybe using heuristics specific to article categories or wiki-projects. For example, a system for supporting Military History contributors might search within sources and authors already used in MILHIST's good and featured articles. The idea is to help well-intentioned new editors contribute at a more valuable level much sooner, so their effort is more likely to be appreciated. - Pointillist (talk) 17:35, 30 December 2013 (UTC)

I think he is right - it's something we're fully aware of, and is the reason we're taking things in such a step-by-step way (today the wikiprojects, tomorrow the straw poll!). To address quite a few points at once (sorry for the absence, it was holiday season. And then I was tired, because: holiday season):

Kww, I'm sorry you feel that existing contributors have been devalued; for what it's worth, from where I'm sitting it looks like there's actually quite a bit of factoring in of feedback from experienced users. Just off the top of my head, the pseudo-TOC, increased indentation, the more-standard history page we're working on, abusefilter integration, post editing, improved watchlist and special:contributions tracking - these are all things experienced users have requested, and in some cases (the history page comes to mind) features we've had to argue with the more, ah, 'liberal' members of the team for. We're definitely factoring people in, here, and I'm not sure where the perception that we're not comes from - one theory of mine is simply that it's a relative versus absolute thing. The decisions we make internally as a community can be safely optimised just for experienced users, and so decision-making processes that don't follow that look biased away from power users (which, in relativistic terms, they are). We're used to optimising 100 percent of a decision towards power users, and so when power users only come out tops 60 percent of the time, it's taken as a dramatic shift away from the norm. Anyway. I'm not sure where the wikitext thing is coming from; we currently have wikitext support (you can try it). We've avoided promising we will support all wikitext everywhere, both because we're limited by Parsoid (which the team doesn't control) and because there's some wikitext we probably don't want people using (god knows what happens if you instantiate a TOC in the middle of Flow), but I remember Maryana explicitly promising you, months ago, that we would support the wikitext people needed to use and that you were welcome to bring up examples of wikitext that wasn't supported that we need. I haven't seen you do so.
Johnuniq: I agree with Kefir that there's some optimisation to do with talk pages that would help with the problems you bring up; I disagree that Flow is a "chat system", or that improving communications mechanisms on enwiki wouldn't help attract more good editors. Wikipedia needs more than just the ability to remove POV pushers to attract new content editors; it needs an interface that allows nascent content editors to ask questions about what they're doing, what the rules are and how they should be going about contributing. Of course, it needs a lot of other things as well, but this is (I think) a necessary step. Removing POV pushers is great for solving one part of the problem new editors face, which is territorial, biased or aggressive contributors, but it does nothing to help them find out how to resolve those problems, or what language style they're meant to be using, or how to cite references, or a thousand other small things that newcomers are confronted with all-at-once. Okeyes (WMF) (talk) 20:15, 30 December 2013 (UTC)

Okeyes, if Maryana has made any explicit commitments, I've missed them. The discussion on complete wikitext went so circular I gave up ("We won't guarantee complete wikitext support because of Parsoid"->"But you have to support complete wikitext, including templates!"->"We'll support everything you need"->"Tell us what you will support, so we can tell if it's everything we need"->"We can't tell you what we will support, because it's under Parsoid's control"->...). Combined with the fact that the last time I actually got a commitment from a Flow developer it was rescinded on the basis that Flow developers weren't permitted to make commitments, I think you can understand why I might find these discussions frustratingly fluid.—Kww(talk) 21:08, 30 December 2013 (UTC)

What was that commitment? If you mean Brandon's comment way-back-when, he's not a developer ;). The FAQ has some comments on wikitext; in terms of what people need and that argument, it's probably more useful and reliable for people to just try doing what they'd usually do, in Flow, and see if it works - there's a lot of sandbox experimentation along those lines that is going on as we speak and seems to have produced some bugzilla entries for us to work on. Okeyes (WMF) (talk) 21:42, 30 December 2013 (UTC)

@Pointillist: Re: "invest in building a world-class reference/research system" - go check out m:Grants:IEG/The Wikipedia Library and then Wikipedia:The Wikipedia Library! Slow & steady (and with input and assistance from many people) is how all good things are made. :) Quiddity (WMF) (talk) 23:58, 30 December 2013 (UTC)

That's a project designed to serve people that are already skilled with referencing. It's valuable, and a good idea. What I would like to see is a focus on attracting people that want to do that kind of work. I think the foundation of all the "facebook" comments is based on the fear that Flow will attract the wrong kind of editors. I don't see that this is necessarily true, but I would like to see some methodology used to address it. If a feature is popular among people that are likely to actually add well-sourced academic material to Wikipedia, that feature should be prioritised over a feature that appeals to editors that are inclined to argue over whether Lady Gaga could beat up Britney Spears in a barfight. It's easy to make such judgement calls when you are receiving feedback from established editors: we are a relatively known quantity. When you are a evaluating these "new editors", it's much harder. I don't expect perfection, but I'd like to get the impression that WMF was at least attempting such an analysis.—Kww(talk) 22:30, 31 December 2013 (UTC)

Stopping the development

I tried it yesterday, and my conclusion is that FLOW should not be unable on the English Wikipedia, unless there is an opt-out option. If it gets unabled, I will most likely leave the project or concentrate my work in the article space. More specific comments, which I copy from WN:Policy, are below.--Ymblanter (talk) 07:40, 9 December 2013 (UTC)

Right now, I have my watchlist. I use the custom script which shows where there are new edits, and which pages I have already looked at. There are many pages I do not look at immedialely and wait until there are more new edits which I can all assess at the same time. I decide whether I want to look at the page or not on the basis of the edit summary (for instance, if I see someone assessed a talk page of a rarely visited article for a project, chances are this is the only edit in the last several days and does not reuire my immediate attention.

Now, at least for the talk pages, the wacthlist will be replaced by FLOW. Right now it does not show which edits were made since my last visit, but imagine it would be modified to show them in a different color, this must be doable. (Note that it is more useful if one can mark threads as read and unread). However, even if it does, there is no tree structure, so if I want so understand what the new replies are related to, I need to refresh the whole branch of the discussion (which for long discussions may contain hundreds of replies left at different times). Even if the tree structure has been created (which is, again, doable though probably not intended at the moment), I still have to look through the whole thread of my messages on different talk pages, which is a lot more than what I am doing now, and is beyond the time capacity I have at my disposal.--Ymblanter (talk) 06:51, 9 December 2013 (UTC)

I see that the subthreads are being discussed above, but without ability to mark see threads/messages and without edit summaries it still remains useless. If all of this has been implemented, I do not see much difference with the current organization of talk pages.--Ymblanter (talk) 07:42, 9 December 2013 (UTC)

No, the watchlist will still exist for talk pages. The difference is you'll be able to follow specific threads, as well as specific pages. Example: say you have two talk pages, those for AN/I and those for RfA. You're discussing something specific on AN/I, but care about RfA-related discussions uniformly. You'll be able to just be notified of replies to the specific AN/I thread, avoiding being notified of Every Single Reply To Any Thread Ever, and be notified of messages on Talk:RfA. We're not deprecating the watchlist - we are making watchlisting more granular. Okeyes (WMF) (talk) 17:42, 9 December 2013 (UTC)

This I do not understand. In my understanding, in FLOW one can not leave edit summaries. Without edit summaries, the watchlist functionality is very much reduced.--Ymblanter (talk) 19:09, 9 December 2013 (UTC)

What specifically confused you? Yep, you won't be able to leave edit summaries. Having said that, in my experience the most useful element of watchlist functionality for talk pages is the /*little thread title*/ which tells you whether it's something you'll care about or not - that's something that is going to be present in Flow entries in recentchanges/watchlisting. Okeyes (WMF) (talk) 19:23, 9 December 2013 (UTC)

As I replied to Maryana at WP:NP:POLICY, if (i) the deep threads; (ii) the edit summaries; (iii) the markable read thread markup have all been implemented, then for me FLOW looks like just a bad re-design of what we already have.--Ymblanter (talk) 20:33, 9 December 2013 (UTC)

That doesn't seem to relate to what I said, but, okay. Okeyes (WMF) (talk) 21:31, 9 December 2013 (UTC)

Comment: I did some wiki-stalking of your contribs, Yaroslav ;) These are you recent contributions to the Wikipedia talk namespace (which is where the first release of Flow will be deployed, on just a few Wikiproject talk pages). When you're not doing AfD or AfC (not places we're planning to Flow-enable anytime soon), it looks like you never actually fill out an edit summary on those pages, except in rare cases when you're editing your comment. If you were looking at your watchlist and seeing those changes on a Flow-enabled page, which aspect of these edit summaries would be important to you? Maryana (WMF) (talk) 20:20, 9 December 2013 (UTC)
Comments on the article talk pages that someone changed assessment or smth like this, mostly. For pages like AN or noticeboards I mainly check them once or twice per day, and then go through all edits, I do not have time for doing more (except for when I am waiting for the response, then I indeed watch for the edit section).--Ymblanter (talk) 20:31, 9 December 2013 (UTC)
So, your objection to flow is based around wikiproject tags, then? Okeyes (WMF) (talk) 21:31, 9 December 2013 (UTC)
I am not comfortable having this discussion against four people who get salary to promote flow. I am sorry. My business was to let you know that there is a large fraction of long-time users for whom flow is not acceptable. I am pretty sure you underestimate the problem. I have a long experience dealing with facebook style of comments, and I find them uncomfortable. You can of course reduce this to the wikiproject tags if you wish. Note that my real life job is, in particular, to teach, and I was able to formulate clearly what I do not like. Others will leave without trying to formulate anything. Whatever I tried yesterday is not a product I ever want to use, and I am not interesting in helping to develop it.--Ymblanter (talk) 21:44, 9 December 2013 (UTC)
We're not being paid to promote flow, we're being paid to make sure it's useful - very different things. If you look up the page you'll see a lot of people who are not staffers participating - I'm hoping some of them will chip in on this thread, too.

I very much appreciate your comments but I'm having some difficulty parsing them and trying to work out exactly what your issues with Flow are - narrower than a lack of edit summaries (which has been addressed) and "tree structures" (I'm still not sure what that means). I'm not trying to deprecate your thoughts, just identify what you mean by them specifically. Okeyes (WMF) (talk) 21:57, 9 December 2013 (UTC)
By tree structures I mean nesting levels discussing above. Edit summaries have not been addressed - you just mentioned you believe they are not important. And, again, I am not feeling comfortable when all my objections are refuted immediately with the reasoning they are not important. I remember liquid threads too well. May be you should not parse my comments - everything can be parsed to small enough pieces and refuted - but take a volunteer (not me), add to their watchlist 10K pages and ask them to use flow at all talk pages for a month, doing a minimum of 20 edits in the talk page space per day. Then we can look at their impressions, and possibly parse them.--Ymblanter (talk) 22:12, 9 December 2013 (UTC)

Actually, I agree with Ymblanter that edit summaries are important in discussion pages - but looking at our own edit summaries won't necessarily tell you that, because what's important to us are summaries by others that appear on our watchlist. For example, looking at my watchlist right now, I see a "calling all talk-page stalkers" summary on a usertalk, which tells me that there's something I might want to respond to; a summary that actually addresses me directly (in a thread I haven't participated in so probably under Flow wouldn't be watching); and a post to an article talk page with the summary "poop", which flags for me that the edit is a test or vandalism (and someone's already reverted it as I typed this). While I also use the section tags to watch for changes, these types of edit-summary flags are important too. If edit summaries are indeed not included in Flow, that significantly impacts my ability to attend to such conversations. As an administrator, I can also get an idea of the tenor of the conversation by looking at edit-summaries - if I start to see insults flying, even without looking at the thread in question I can realize that it would benefit from an intervention of some kind before things get too out of hand. Without that flag, I'm either monitoring all threads more closely or arriving too late to help in any way short of blocking. Nikkimaria (talk) 00:43, 10 December 2013 (UTC)

@Ymblanter and Nikkimaria: What you see now, is just the first step - there will be large changes coming over the months ahead - which changes those are exactly, will be based on what we want and request and suggest (plus user testing, and research, and what is possible, and etc). Eg:

Nesting/threading levels: We are almost all in agreement (community and Flow team staff) that the current level of nesting is completely insufficient. They will be changing that very soon. IIRC the next test will be 3 levels of nesting. They'll test that out, and ask us for feedback, and we'll see if that is a good balance (bearing in mind that we editors tend to use the {{outdent}} template after about 5-8 levels, in practice, per Nikkimaria just now, who outdented after 6 levels).
Edit summaries: See the discussion Fram and I and Okyes are having about edit summaries. There are definitely going to be edit-summaries for topic-changes, and header-changes, and edits-of-posts. The only question is whether we need them for initial post save. (Your comments here are excellent feedback, and appreciated, and being closely listened to.)

For the initial posting of a comment, most people don't use them, or misuse them (see that linked thread, for the short list). Can we think of something better, or a way to improve the current imperfect system, that will be clearer, and allow us editors to work more efficiently? What can you dream of, to improve edit-summaries, and their current half-useful state? Small-tweaks, large-tweaks, more warnings-of-missing-summary, better short documentation, anything. (Actually, I'll copy some of my post across, below, so that it's easier for everyone to read and respond to.)

Marked as read: Not yet, but eventually. It's on the feature list, of things that we all want, but is not part of the Minimum Viable Product.

More, below. –Quiddity (WMF) (talk) 01:09, 10 December 2013 (UTC)

Edit summaries

(Some comments I wrote at ee-flow, copied to here, for easier discussion.)

IIRC, the main rationales for not including an option for edit-summaries in talkpage posts (Flow posts), include:

it creates more complexity that isn't generally needed (bad for newcomers)
it creates more communication-channels that might be overlooked by the intended audience. (bad for everyone)
it creates more communication-channels that need to be potentially-moderated. (bad for moderators)
Most of the current content is noise. (most of my discussion/talkpage messages are summarized with "reply" or "reply to [x]")
Possibly other factors?

Eg. How useful are the summaries in

and could we (whilst doing this overhaul of the discussion&collaboration system) think this aspect through again, and see if it could be improved?

But I also understand the rationales for retaining it, including:

it can be a useful summary of a long-edit, by the author
- (but, does this get used as a TL;DR by some people, to ill effect? Summaries can also be misinformation, similar to mis-use of the minor edit button...)
it's understood by 'the regulars' as an even more informal communication-channel, and can carry personal messages such as apologies, or context phrased in a different "voice" than one might use in a post/thread.
As nikkimaria says, it can be a useful clue about vandalism, or tangents to glance at.
Possibly other factors? (please suggest what I've missed)

The page w:Help:Edit_summary#How_to_summarize says only:

"Talk pages. When editing talk pages, consider copying your comment to the edit summary, if it is brief; this allows users to check Recent changes, Page history and User contributions (see below) very efficiently."

and the current mediawiki "New section" button/action doesn't give an option to include a summary.

Lots to think about. Signal vs Noise. Idealism vs Pragmatism. Simplicity vs Complexity. It's definitely open for discussion and brainstorming. –Quiddity (WMF) (talk) 01:15, 10 December 2013 (UTC)

I think from my perspective use of edit summaries by regulars is very helpful for both informal chat and keeping track of conversations; newbies in practice use them less or use them in a different way (and I'm not sure how to address that). Take a look at the ANI history linked above, for example: section headings are great, but we also see things like "further note to liz", "closing", "It might be a good idea for uninvolved admins to add the above articles to their watchlists" - all of these are helpful for me in figuring out which comments I actually might care about. Tone in edit-sums, even if brief, can be key to tracking and understanding conversations. (I also use my own edit summaries to keep track of certain things for my reference, although that tends to apply more to mainspace edits than talkspace). Nikkimaria (talk) 02:21, 10 December 2013 (UTC)

Thanks, Nikkimaria, this is really helpful to get a sense of. Things like "further note to liz" and "closing" can be added as programmatic messages to the Flow history/watchlist views pretty easily just based on the actions you're taking (e.g., "Nikkimaria replied to Liz," "Nikkimaria closed the topic Foo on bar"), but the case of "hey any uninvolved admins reading this, come check out x and y" is tricker. Have you found yourself switching to using Echo mentions to rope specific people into conversations like this? I realize that's different from cases where it's not specific users you want, but a general class of users... but perhaps further down the line, being able to notify a random set of admins via Echo as part of a new post might do the trick? Maryana (WMF) (talk) 21:45, 10 December 2013 (UTC)

Maryana (WMF), I hope you won't take what I'm about to say the wrong way, as it's written with the best intention. May I ask you why you and your team have this tendency to propose functions for Flow that limit the possibilities of current talk pages, reducing them to a fixed subset of features? You did that at least for tables of content, subthreads and nesting, editing other people's comments, and now edit summaries.

The beauty of open-ended an simple tools like edit summaries is that they may be adapted by their users for new use cases that were not predicted at first; and that this adaptation doesn't require the involvement of a developer in the loop. This flexibility has proved itself invaluable for a project the size of Wikipedia. If you instead replace edit comments by a set of features like those you've just mentioned, intended for the few cases that you'll identify during the next months, you'll be reducing the chances that the tool could grow beyond what you might envision during the development phase, restricting the possibilities of collaboration to the use cases on which the initial design is based.

IMHO features that have proven themselves to work well should be preserved wherever possible, and only refined and re-designed by testing the candidate improvements in the field; not the other way around - building a replacement feature from scratch, and looking if it lives up to the tasks that were possible in the old feature.

It's OK if the programmatic messages you mention are added as the default value of edit comments, so that newbies benefit from them without requiring prior learning; but an experienced user should always be able to define exactly what they want to appear as the edit summary, as they can do now. If the problem is that new users won't find them and moderators need to actively look for them, you should work to improve their visibility, rather than replacing them with more limited versions; but please don't base you design on the decision to remove them as a feature, as you seem to be considering.Diego (talk) 23:43, 10 December 2013 (UTC)

Diego Moya: "May I ask you why you and your team have this tendency to propose functions for Flow that limit the possibilities of current talk pages, reducing them to a fixed subset of features?" I'm not sure that's an entirely fair assessment. We're starting new software from scratch, so we can't build in every single feature of talk pages (which have developed organically over 12+ years!) all at once. But not all use-cases of talk pages are of equal importance. There are some features of Wikipedia discussion without which, well, it's not even a Wikipedia discussion: adding a new comment, replying, moderating bad content. We've started with those things and will continue to build on top of the MVP scaffold; as more users try out the software, they can help identify the next set of things that are most critical to add. Edit summaries are important, but probably not so important that you can't even feasibly have a real discussion without them :-P Maryana (WMF) (talk) 00:04, 13 December 2013 (UTC)

Maryana (WMF) "We're starting new software from scratch, so we can't build in every single feature of talk pages". You're right that it wouldn't be fair, provided that's the assessment I made - but it's not. Of course I don't expect the new software to begin with all the features of the old. But when you do arrive to building one particular feature, you're talking of substituting a simple and generic feature, that users are familiar with, with a set of more complex and untested features that nevertheless are suited to less use cases. Programmatic messages and notifying a class of users would be helpful; but the question is, why would you think of suggesting them as a replacement for edit summaries as you seem to be doing? Instead of asking how to add tweaks and improvements to the current method, you're considering what features could be put in its place. Diego (talk) 07:05, 13 December 2013 (UTC)

Diego Moya: As with all the "experimental" items, the idea is to find out whether we can improve how things currently work, by examining the underlying problem/task that our current setups try to solve. – Eg. The way Echo didn't reinvent {{talkback}} messages, but instead solved the problem in a different way. – With edit-summaries, we're all currently using them inconsistently [from each other] and for varying purposes - So, what can we dream up, that solves the underlying problem of "I want more context, in a clear and consistent way"?

Better automated summaries, are one method. We could also automatically excerpt the first few words, as Klipe suggests below, and as the help page currently recommends. tl;dr: if we can't invent something better, then they'll re-implement the old methods, but now is the best time to dream-big-ideas. Quiddity (WMF) (talk) 20:50, 18 December 2013 (UTC)

At this point I find myself using Echo mostly to call newbies, not regulars. In theory the "random set" of whatever sounds promising, but in practice I think there's no guarantee it would help - nearly half of admins are inactive, after all, and not all active will be interested or able to participate - and such a system wouldn't meet the "calling all tps" type of edit-sum (unless you created something to ping everyone watching a page, which would get really annoying really fast IMO). Nikkimaria (talk) 01:03, 11 December 2013 (UTC)

Often, a new post in a thread doesn't have a coherent or helpful edit summary, and a new thread (in the present system) has an edit summary of the thread title. But sometimes an edit summary is _very_ helpful, even though they also need to be checked for deletion or suppression. — Arthur Rubin (talk) 01:39, 11 December 2013 (UTC)

One case in which I already wanted to add edit summaries several times in my Flow tests during the last few days is... when I actually edited existing text (using any pencil icon: on board header, on topic title or on any of my posts). In such cases, I want to be able to mention the nature of my changes, such as format improvement (adding bold...), language improvements (orthography, syntax...), correcting code (template parameters, link), adding an argument to a list (makes sense as long as no-one replied based on existing content) and the like. Klipe (talk) 09:23, 15 December 2013 (UTC)

I would even make it required for board header and topic title edits (actions available to any user), although for topic title edits the current automated mention (title changed from abcd to xyz) is very much valuable (for counter vandalism) and should definitely stay, with user entered summary appended to it. Klipe (talk) 10:21, 15 December 2013 (UTC)

For any new content, an automated edit summary could include the first few tens of characters of the new content (therefore including the @User mention if any). In case of a new reply, it would also be easy to automatically add a link pointing to the comment that is being replied to, although this may be only marginally useful. Klipe (talk) 09:23, 15 December 2013 (UTC)

What about a user preference to get the edit summary box appear on every edit? that input box would show the default automated summary and let the user change it before saving its edit. Klipe (talk) 09:23, 15 December 2013 (UTC)

Good points, all.

Re: Preferences: Personally, I love them (eg. firefox's overwhelming [about:config]), but getting the defaults to be as-good-as-possible is goal#1, and minimizing the number of preferences is goal#n (throughout mediawiki)).

They're going to start with automated summaries (see mingle description), and get those to be as useful as possible, and then see what can be improved from there. Quiddity (WMF) (talk) 20:34, 18 December 2013 (UTC)

WP:IDONTLIKEIT

We are being told WP:IDONTLIKEIT wasn't a valid argument against the introduction of Flow. Yet WP:IDONTLIKEIT (the existing wiki style even for discussions) seems to be the main argument in favour of Flow. Well, I like wiki, it's what we do here. We can improve it, but WP:IDONTLIKEIT is no argument to throw it out. --SpecMade (talk) 00:50, 20 December 2013 (UTC)

WP:IDONTLIKEIT is an argument to avoid in deletion discussions, and the reasons the essay gives for it are irrelevant here. Keφr 21:08, 22 December 2013 (UTC)

I don't think it's about liking or not liking it, it's about how you go about it. If people show up and complain in bad faith, or assuming bad faith on the part of the people (staff and editors) contributing to the project, they're probably not going to be listened to - this is true of any and every area on Wikipedia. If people show up and simply complain "I don't like it", they're unlikely to be listened to because, well, what feedback can you tease out of that comment? If people show up and say "I don't like it because the grey colouring hurts my eyes, and the header area is too big, and it needs more levels of indentation" - well, that's an IDONTLIKEIT comment I'm happy to accept, because it's one that provides tangible feedback. Okeyes (WMF) (talk) 20:18, 30 December 2013 (UTC)

I have a valid IDONTLIKEIT comment. I don't like what we have now. If we weren't used to it and the WMF tried to introduce such an abomination, an angry crowd would gather with pitchforks and torches to kill the undead thing. I am not criticizing the people who developed what we have now -- it was pretty good compared to other systems developed in 1995 -- but in the last 20 years we have learned better ways to format text. --Guy Macon (talk) 19:34, 3 January 2014 (UTC)

Usability Study

As some of you may have noticed, I am a proponent of replacing the current 20-year-old system with something better, and I am optimistic that Flow will, indeed be an improvement. One thing I like to do when I have an opinion on something is to search for the best arguments on the other side. While searching, I found the following research from 2005:

http://www.wikisym.org/ws2005/proceedings/paper-01.pdf

http://upload.wikimedia.org/wikipedia/wikimania2006/b/b5/CS1_slides.pdf

The authors asked a class of 4th grade children to collaboratively create complex pages using a system similar to our existing system after two 15 minute training sessions.

Comments? --Guy Macon (talk) 20:23, 3 January 2014 (UTC)

Maybe we need two systems. One for ordinary talk pages of articles (for beginners and 4th grade students), and one for the "maintenance" talk pages, where "productivity" and readability matters... Christian75 (talk) 19:33, 4 January 2014 (UTC)

Second new contributor survey (feedback wanted)

Hey all; I've posted the draft of the second survey of new contributors. If you've got any feedback on the questions, please do provide it; I'll leave this around until, say, the 6th before building and distributing the survey itself to give a week-long feedback period. Thanks :). Okeyes (WMF) (talk) 21:00, 30 December 2013 (UTC)

Since philosophizing about the "big picture" isn't helping directly, here is some concrete feedback that hopefully sheds some light on my thinking.

You ask "how do [new users] think people are meant to use talk pages", in order to understand "how new-ish contributors understand the purposes of talk pages". This is like showing someone chess for the first time and asking them how they think pieces should move. If we want them to discuss article issues on the talk page, then we write "Please discuss article issues here" on the talk page. If they think they can talk about off-topic, about other editors or just discuss funny fancruft, then that's them not having read our "rules", our "rules" being hard to find and/or understand, or them simply not caring. This is not a problem with the discussion system, old or new. This is a problem of not having properly told them why to use it. I don't necessarily have a problem with finding what users think, but wasn't this asked already last time and don't we have better questions to ask? Like the example below:

"How strongly would you agree or disagree with the following statements? -The page's structure and user interface was easy to understand; -Reading comments by other users was easy; -Replying to other users was simple to do; -Starting a new discussion was simple."

This is a loaded question if I have ever seen one. The survey conclusion will be -- interface needs improvement. To put it bluntly -- "o rly?" All four answers are different facets of the same box. And none of them have anything to do with the actual purpose of talk pages. Perhaps I wouldn't mind this question so much if editors were asked the real question: "Did the interactions on the talk page solve the issue? Did the editors reply to you? Did the editors understand your issue? Did you reply to the editors?" And the killer -- "did at any of these steps you find interface to be the limiting factor?" Ask them what they tried to do and ask them what they failed to do. At which point did users decide to leave the talk page? Was it when they saw it, when they tried to edit it, when they tried to post the question, when they were tracking updates, when they got or didn't get replies, when they tried to reply, etc.

Don't ask them what they need, they don't know what they need. Saying this at the expense of insulting the designers, but this is software development 101. Ask them what stopped them or how they can be more efficient in doing what our project needs. — HELLKNOWZ ▎TALK 22:24, 30 December 2013 (UTC)

That all makes a lot of sense (although actually some of them came up with some pretty good suggestions). Re the first question; I largely included that because some editors thought it might be interesting and don't have any particular attachment to it - happy to remove it. The second is really good feedback and looks like the sort of direction we probably want to go in; poking User:Maryana (WMF) unless I've missed something obvious. Okeyes (WMF) (talk) 22:41, 30 December 2013 (UTC)

Hellknowz, it's an important part of product development to understand the mental model of our users. Asking users what they think a given software feature is for, even if they've never used it before, is a widely-used qualitative research method for getting an understanding of that underlying mental model. By asking this question of our users over time, we've found that there are subtle but important differences between the mental model of readers who have never edited Wikipedia and brand-new users who've made an edit or two – the former tend to be much less aware of Wikipedia's norms, social structure, and community than the latter, even though the difference between 0 and 1 edits doesn't necessarily seem to be all that huge. This is the kind of thing we want to continue to test and learn more about, so that we can, for example, build first-time user tutorials or instructional text into Flow boards that give total newbies just-in-time training and don't annoy/clutter up the interface for more experienced users. From an overall product strategy standpoint, it's also useful for getting a sense of who we should actively target with features like Flow, and whether or not it's a good idea to expand the visibility of discussion so more readers and newer users can discover it.

RE your comment Don't ask [users] what they need, they don't know what they need. That's very Steve Jobs of you ;) but the idea that this is "our project," and "they" (new users) have no say in how it should or could work is problematic; there's a delicate balance to be struck between helping new users understand the fundamental policies and social norms of Wikipedia and WP:OWNing the entire project. Those policies and social norms are, after all, subject to change over time with discussion and consensus, just like all of Wikipedia. Maryana (WMF) (talk) 22:57, 2 January 2014 (UTC)

Maryana, those are all fair points and I can't really argue with any of them. But similarly, they don't address my position either. You see, that's my point – WMF has a slightly different design premise.

Both "our" goals are to attract new editors and have new editors stick around. In "your" case, this is first done by tailoring the system to what they would want and find easy and they hopefully join. In that scenario, of course their opinion matters! But in "my" case, the system is built first for functionality and efficiency and then new editors are asked if they want to join. A subtle, but–in my opinion–significant difference.

A new editor has no idea what talk pages do, what discussions are needed for the encyclopedia. Wikipedia is unique in this respect, there is no comment system and back-end community out there that matches ours (as you compare, we are making the first iPhone). So when you say we need to understand user mental model, I ask – how can they possibly have a model that matches Wikipedia before learning what Wikipedia is and needs? They can suggest Facebook-style or Reddit-style or YouTube-style system, but we are not one of them.

Let me give you a real example that I see every day – new users at AFD discussions. I have patiently explained countless times to new editors how our notability is the threshold, how arguments matter and not votes and should address our guidelines, how "(non-)importance", "(un)popularity", or "(un)usefulness" are subjective factors, how GNG lists carefully selected criteria, how authorship and attachment to the article don't work, etc. Now, imagine we decided to make a DeletionFlow extension and ask new users how they want it made. That's crazy -- they have no idea what V or GNG or OR or OWN is and how arguments should be formed! They cannot be making a decision that changes the whole system if they don't even know how the system works.

And that is how I feel with Flow (to a less extreme extent). I understand "free" and "anyone can edit", but I stress "encyclopedia". What is the point of all the new editors that join due to the amazing new comment system, but leave as soon as they realize it's only there to help the real work? You are fishing with fishing nets hoping some of the fish will be salmon, while I set up a contraption up the river that primarily catches salmon. You will catch a lot more mackerels of course, but don't forget our restaurant is called "Salmon Delights". — HELLKNOWZ ▎TALK 13:27, 3 January 2014 (UTC)

I think we're actually very much on the same page here, just coming at it from slightly different angles :) We both agree that someone whose only mental model for an online discussion system is YouTube-style "first post!!" or "omg, Justin Bieber sux rofl" is not someone we want contributing to discussion on Wikipedia. But what about somebody who's an active, thoughtful commenter on Paul Krugman's blog in the New York Times? Somebody who gathers reliable sources for each of her posts, understands and intelligently calls out undue weight and POV-pushing in other commenters, is logical and civil – that person, even though she may not know anything about AFD yet, will naturally be better at discussing the notability and verifiability of a new article. It's true there's no discussion system out there that's exactly like Wikipedia's, but some discussion spaces are closer to our project's norms and values than others, and by understanding what people who do or don't join our community are used to in an online discussion, we get a better idea of the types of features and design patterns that can help us get more of those good people in and keep the not-so-good people out. Maryana (WMF) (talk) 17:36, 3 January 2014 (UTC)

Actually, Hellknowz, I think a newbie could probably spec out a pretty decent DeletionFlow process, despite not knowing anything about policies or guidelines. You could probably get thoughtful answers by asking a bunch of people a question like this: "Somebody added an article to a website. Somebody else thinks that the article isn't a good fit for the website. A decision about keeping it or deleting it needs to be made. What kind of process would recommend that they use to make sure that a good, fair decision is made?" I would expect to see a variety of responses from people, including things making sure that there is time for everyone to participate in the decision, having a senior person or moderator make the decision, and so forth. It's not just about knowing one set of guidelines. WhatamIdoing (talk) 22:12, 4 January 2014 (UTC)

I'm sure someone among newbies will spec the best system possible. But on average, wouldn't users come up with every kind of possibility and not just the best one? If majority says "let's vote", are we going to change AfDs to voting? I highly doubt that. So if majority of users say "Reddit-style comments", is that what Flow will be? Or if majority says "leave it as is", will Flow get scrapped? I highly doubt that either. Flow is happening, it will have pretty interface, it will replace current syntax, it will prioritize new editors and I've come to terms with it. — HELLKNOWZ ▎TALK 22:45, 4 January 2014 (UTC)

Well, actually I don't think those are the suggestions we can expect (or the type of suggestions); we actually have a pretty good heuristic for what we might get out of these sorts of questions, because we asked them in the last survey. The responses we got were mostly along the lines of "I want to be notified when someone replies to me", "you need a more modern UI" or "make it easier to distinguish between different posts". I think treating as a popularity contest for various features and building whatever the votes say people want would be a mistake, but we can use it in the other direction and say "of the things we want to do, what don't people want?" - use it as a check and balance rather than a deciding factor. Okeyes (WMF) (talk) 19:26, 6 January 2014 (UTC)

Okay, I'd like to kick off the survey soon-ish. How does this sound:

We exclude the question about understood purposes of talk pages;
We include the question about suggested improvements, but use the information only as influences in our validation/invalidation of existing features requirements, rather than suggest new ones (in other words, in a weaker way than we do feedback from the existing community, since the existing community has a better idea as to the practicalities of a lot of suggestions).

Hellknowz, thoughts? Okeyes (WMF) (talk) 18:26, 7 January 2014 (UTC)

I think you shouldn't listen to me so directly :) because my philosophy differs in a way you think is minor, but I think is major. That said, I am okay with your changes. — HELLKNOWZ ▎TALK 18:31, 7 January 2014 (UTC)

It does, but the point you raise is valid under my philosophy, too :). I'll start work formalising this survey, then! Okeyes (WMF) (talk) 18:47, 7 January 2014 (UTC)

Why not start with an existing open-source message board?

Why are we not using an existing open-source message board and customizing it for our use?

In particular, I would like to see the documentation where the following were evaluated:

phpBB: https://www.phpbb.com/ https://wiki.phpbb.com/Main_Page

pyForum: http://pyforum.org/ http://code.google.com/p/pyforum/

--Guy Macon (talk) 20:59, 4 January 2014 (UTC)

Essentially, because we don't just need a simple message-board system, instead we need a workflow system that has discussions as a major component. Customizing the former into the latter, would be more work than just writing the latter from the ground up. The same problem applies to "updating liquidthreads". (And there are unrelated-but-similar discussions about bugzilla-vs-project-management software). There are a few more details at Wikipedia:Flow/FAQ#Why don't we use a pre-built system, like PHPBB or Discourse? HTH, let us know if it doesn't. :) Quiddity (WMF) (talk) 23:48, 6 January 2014 (UTC)

Thanks! Not sure why I missed that when I read all the docs on the project. :( --Guy Macon (talk) 21:40, 7 January 2014 (UTC)

Custom Signatures

Hi - I'm trying to learn how to make a custom, visually-distinct signature that conforms to WP:CUSTOMSIG, which I'm reviewing now. However, I saw mention of something called "Flow" and am to understand that, whatever the custom signature I finally (learn to) create, I won't be able to have it on Flow? Why? Can I object to this or opt-out? When will this changeover take place? Should I even bother making a custom signature if it's just going to be taken away from me later? THANK YOU IN ADVANCE FOR ANY GUIDANCE OR FEEDBACK!!! JDanek007^Talk 23:58, 21 January 2014 (UTC)

Flow isn't really using "signatures" at all. It's really just displaying one line out of the page history, where your signature already isn't showing.

It will likely be a couple of years before Flow is used everywhere, so if you want a fancy signature, you'll still have plenty of time to use it. WhatamIdoing (talk) 01:31, 22 January 2014 (UTC)

What WhatamIdoing said, basically. Okeyes (WMF) (talk) 17:13, 22 January 2014 (UTC)

Subscriptions

I admit that I haven't been keeping up with Flow, but I'm thinking about subscriptions to newsletters today. I believe the general theory is that I could 'subscribe' to The Signpost and receive it automagically in my feed (you're still planning feeds, right?). As a result, The Signpost folks would not have to maintain a list of who wants to receive the newsletter. They would just need to post it to [Wikipedia:Signpost/Newsletter] (for example), and it would appear in the feed for any user who had previously told Flow to keep track of that page and present new additions in your feed.

So if that's the plan—and overall, I think it's a great plan that will significantly reduce hassle for the senders of newsletters—I think that we (the community) need to re-think how we advertise newsletters. I suspect that the major source of subscriptions is someone stumbling across a useful newsletter on another person's talk page. But if the newsletter appears automagically in my feed, nobody can easily (or at all? it should probably be considered as private as a watchlist) tell that I'm subscribed, and therefore nobody can just happen to stumble across it and decide to subscribe on their own.

Does this sound like a realistic, if unintentional, outcome? WhatamIdoing (talk) 00:08, 16 January 2014 (UTC)

Yup, a valid concern. It's been mentioned previously as a reason to hesitate from using Echo to distribute newsletter updates, too. :/ Complexity everywhere! Quiddity (WMF) (talk) 02:07, 17 January 2014 (UTC)

Echo might be the solution: If I can advertise the existence of a newsletter via Echo (e.g., an annual announcement for The Signpost, perhaps automagically expiring after a eek or two, then that would balance it. A watchlist notice is another option, or a "community announcements" Flow board that people were automatically subscribed to.

Hey, can I have another pony? Can we have a feature that lets us subscribe everyone (or all admins or all autoconfirmed or whatever) to a Flow board by default? Presumably we'd control it the same way that we control watchlist and sitenotice pages. WhatamIdoing (talk) 01:36, 22 January 2014 (UTC)

Re: advertising via echo, and distributing via echo. That would still leave the problem of users not being as likely to "stumble upon" the newsletters that other editors subscribe to, and to glance through occasional issues on someone else's talkpage.

Fwiw, I updated the list of WP:News#Topic-specific newsletters a few months ago, and will give it another nudge now. (I wouldn't want "an annual reminder" for each of those items..)

Re: auto-subscribing editors to an announcements-feed, that sounds like a good idea. If definitely would require strict control, in the same way that the various WP:Notices are, to reduce the chance of anyone wanting to unsubscribe from it. Quiddity (WMF) (talk) 23:46, 22 January 2014 (UTC)

Large image when logged in

Not sure if this is intentional but when logged in I see File:Winter in New Hampshire.JPG as an embedded 3 megabyte image at the end, but not when not logged in. Tested with Opera (logged in and not, but I need to upgrade Opera) and Firefox (logged in only) and with Cologne Blue skin (also seen in Monobook but I use a lot of CSS and JS in that skin). I do have a lot of gadgets enabled but none that should expand images. -84user (talk) 23:08, 3 February 2014 (UTC)

Yeah, this is a bug in the software exploited by a user who chose to use an actual, used talk page for testing. The underlying bug will be fixed; the thread is deliberately now hidden. Okeyes (WMF) (talk) 23:11, 3 February 2014 (UTC)

Ah, I see. I thought it was part of the testing. How would an editor such as myself fix such problems, for example by changing the image to a [[:File:name.ext]] link as I would do normally? -84user (talk) 23:22, 3 February 2014 (UTC)

Currently the "hide" button is in the flag-icon, which is hidden under the image. >.<

Once the next release is deployed, (coming this Thursday), we would just click "hide" in the action menu, which will be in the grey topic-titlebar area (See the 3-dots action menu icon, in topics/posts at mw:talk:sandbox).

Re: Changing the wikitext: Flow is currently configured to only allow the original author (if signed-in) to edit a post, plus admins can edit the posts of other editors. This is explained (as an experimental config) at Wikipedia:Flow/FAQ#Components of the discussion system in the "Comment editing" row. HTH. Quiddity (WMF) (talk) 00:03, 4 February 2014 (UTC)

Diffs and deletions

In future implementation, will it be possible to see the diffs in the comments instead of trying to work them out from the full comments? As you know, seeing diffs is one of the most fundamental things on Wikipedia in vandal fighting, error correction etc.

Secondly, how do you delete comments? I've tried deleting the title and the comments and some bugs come up where it will not let you implement the changes once you've blanked them. Simply south...... disorganising disorganisation for just 7 years 17:29, 4 February 2014 (UTC)

Re: Diffs: The latest diff to a post or title is currently accessible from the pencil icon at the end of the post content, eg this post. The Board-history and Topic-history are in the process of being overhauled, to more closely match what we are all used to (ie. standard elements and ordering); see the product-management card, and detailed criteria for details. I'm not sure what the ETA is for that, or whether they'll be working on it piece-by-piece or all-at-once. (I believe piece-by-piece, to get the most needed functionality in place, a.s.a.p.). Quiddity (WMF) (talk) 21:37, 4 February 2014 (UTC)

Re: Deletion: For non-admins, the equivalent of "reverting" an edit is to use the "Hide" function. This current configuration is explained in the "Post moderation" section of Wikipedia:Flow/FAQ#Components of the discussion system. The idea is to make things less confusing for someone reading a discussion - Ie. in the current talkpage system, if posts are entirely deleted without trace, it's very hard to understand what happened without going through the page-history.

(Side-note - I've seen forums decimated of useful content, by a contributor "retiring" and deleting all of their submitted posts before doing so. :/ )

An idea that has been suggested, is to allow editors to delete their own posts within x seconds of submitting them, but this has complications to do with Notifications (see notes).

So that's the current situation. HTH. Quiddity (WMF) (talk) 21:37, 4 February 2014 (UTC)

Note on username display

@R'n'B: Hi, Re: your comment here ("Having my user name appear at the end of each section is confusing, when I haven't yet commented on the page. Also, the "Article collaboration" topic appears to be embedded in the middle of the "Welcome to Flow" topic, and the latter topic resumes after the end of the former one.") - the username at the end of each topic has been removed in the latest code (visible at mw:talk:sandbox) and should be live on Enwiki on Thursday. Regarding the "embedded topic" issue, I think you might be referring to this post, which has a screenshot as the main content! If you're seeing something else, further up, let us know. Hope that helps. Quiddity (WMF) (talk) 23:43, 4 February 2014 (UTC)

Doh! I didn't realize it was a screenshot. --R'n'B (call me Russ) 00:46, 5 February 2014 (UTC)

Unreadable title under Modern

Tracked in Phabricator
Task T62857

I use the Modern skin, and on all flow-enabled pages the title is black-coloured which makes it unreadable on the blue title background. To be clear, I'm generally fond of flow, modulo this and some of the other, more show-stopper bugs mentioned by Risker (talk · contribs) in the above section. L Faraone 16:02, 4 February 2014 (UTC)

@LFaraone: thanks, I've filed bugzilla:60857 to track this and have submitted a patch to fix it. Legoktm (talk) 03:00, 5 February 2014 (UTC)

Feedback on timestamp bug

Hi @Pocket calculator operator, EBernhardson (WMF), and Dougweller: Re: the comments about File:Date tangling.png at WikiProject_Breakfast - I believe those issues are fixed in the latest code - could you check whether the timestamp displays correctly (both with and without mouseover, in the browser(s) that you are seeing problems in) at http://ee-flow.wmflabs.org/wiki/Sandbox ? Let us know if that has fixed it. Thanks.

Generally, if we could discuss bugs here, and do any needed testing at Wikipedia talk:Flow/Developer test page, instead of in the WikiProject pages, that'd be much appreciated! :) Quiddity (WMF) (talk) 21:07, 4 February 2014 (UTC)

The problem is still present for me; in fact, it looks exactly like the screenshot I emailed to Maryana earlier today (which includes my browser detail). Risker (talk) 21:13, 4 February 2014 (UTC)

((ec)):I don't see any timestamps at all on that page, only n days or n months ago. Risker, what am I missing that you can see timestamps and I can't? Or are we talking about a different page? Dougweller (talk) 21:20, 4 February 2014 (UTC)

Hi @Dougweller:. The File:Date tangling.png illustrates the problem - look at the lower right corner of the posts in the screenshot. When I go to http://ee-flow.wmflabs.org/wiki/Sandbox which is supposed to be the "fix", I see the same problem. Risker (talk) 21:43, 4 February 2014 (UTC)

It does look very much the same, Quiddity. The reply button worked without incident this time. That detail may have been lost when I was figuring out how to post using Flow, and edited my comment several times. In any event, that is the extent of the input I can give. Good luck. :) Pocket calculator operator (talk) 21:31, 4 February 2014 (UTC)

@Dougweller: The timestamps should switch between "elapsed" (x ago) and "exact" (x o'clock) on mouseover.

Thanks all, for the added feedback. I'll file a bug for this now (bugzilla:60849). (I thought it might be fixed, because another user seeing the same bug, with a different browser, had reported that the code at ee-flow fixed it). Quiddity (WMF) (talk) 21:51, 4 February 2014 (UTC)

Thought I'd replied last night, sandbox looks fine to me now I know to hover! Dougweller (talk) 06:31, 5 February 2014 (UTC)

Report on Infinite scrolling

Yesterday's Alertbox column from the Nielsen Norman Group publishes an analysis of the usability of infinite scrolling. Some highlights:

Continuous scrolling is advantageous for content that streams constantly and has a relatively flat structure, where each unit of content belongs at the same level of hierarchy and has similar chances of being interesting to users.

Infinite scrolling has advantages, but should be applied with caution. Endless scrolling is not recommended for goal-oriented finding tasks, such as those requiring people to locate specific content. Finding [information] by feature might be difficult to accomplish quickly if all of the [topics] are presented linearly on a never-ending page, without sorting or other filtering or navigation techniques to help isolate the intended item.

Locating a previously found item on an extremely long page is inefficient, especially if that item is placed many scrolling segments down. It’s much easier for people to remember that the item is on page 3 than it is to gauge where the item is positioned on an extremely long page.

Endless scrolling can hurt the user experience as well. For task-driven activities, infinite scrolling can feel like drowning in an information abyss with no end in sight.

With pagination, there is a beginning and an end. There is a happy sense of completion when a page is reviewed. Pagination gives people control to decide whether or not to continue to the next page.

Infinite scrolling breaks the scroll bar by causing it to display the page length inaccurately.

Other analysis I've found for the usability of infinite-scrolling pages are this Smashing Magazine article, and this research paper providing a framework to study their usability. While results are still inconclusive, it seems to me that the infinite scroll metaphor is suitable for content consumption, but it's a bad choice for directed tasks such as collaboration and retrieval of archived content (two central goals of Wikipedia talk pages). As the focus of design in FLow is to use previous research for inspiration, I'd want to ask which research was evaluated when the choice to use an infinite scrolling interface was made, and whether you will ponder some alternative designs on the light of these findings. Diego (talk) 13:00, 3 February 2014 (UTC)

That's fantastic research, Diego; thank you for undertaking it and for providing us with the results :). User:Maryana (WMF), read! ;p. Okeyes (WMF) (talk) 19:27, 3 February 2014 (UTC)

Diego, yes, thank you again for gathering this info you're points are well taken for flow its interesting because some users will be mostly consuming and others consuming and contributing (task based interface) while we'd love for everyone to be part of the conversation (a major product and design goal for flow) we do want the information to be easily understandable very quickly for someone who isn't already part of the community or a specific discussion. We're working on search, we have multiple view formats for a board and the ability to deep link into a specific conversation or share a marker to a specific comment or tangent. We're investigating ways to display the right content at the right time, e.g. initially hide or show tangent replies? what level of default expansion do we show to new users, etc.

to you specific question about how are things findable in infinite scrolling interfaces? we have to work within the framework of the browser, e.g. you can browser find on page, something that isn't technically on the page at that point. How do you handle the state change when someone leaves a page and comes back via browser history buttons, to me these are mostly technical hurdles and I'm confident we can solve them. Check out http://developers.soundcloud.com/docs to see an interesting way they've delt with location in a long document, both via the TOC and a url hash. I think something like this plus some basic browser history manipulation could make the experience great for users with infinite scrolling.

I think only with some real world testing after the launch to the initial participating wikiprojects will we be able to answer some of the questions this poses. Jared Zimmerman (talk) 21:24, 3 February 2014 (UTC)

We do? Exactly who do we think will be simply reading the talkpage without any intent of contributing to it? Okeyes (WMF) (talk) 22:07, 3 February 2014 (UTC)

@Jared Zimmerman: Any answer on Okeyes (WMF)'s question above? I can't imagine anyone coming on a board (discussion page) only to read everything that's already there, indefinitely until he reaches the end of the board, without being somehow involved in a task. That task could be the intention to contribute to some of those discussion topics, the intention to start a new discussion topic if there isn't already one about the matter he has in mind, the hope to find some conclusions on a previous discussion that could guide his current work on an article or help him understand the background of some decision, the need to assess a user's behaviour (in contexts such as anti-vandal fight and ArbCom)... whatever except just reading because he has nothing else to do ! In my opinion, discussions are not the type of content that people would just consume without being involved in any kind of task. Klipe (talk) 11:41, 5 February 2014 (UTC)

But actually @Okeyes (WMF), @Klipe, because Flow is going to replace almost all existing discussion pages – including RfCs, XfDs, RfA, reference desks, village pumps etc – people will still want to read old conversations, e.g. to...

Check whether an issue has already been discussed and decided
Understand the background to a long-running discussion
Look for links to a specific article or source
Research the arguments made in the past by key participants
Prove that they predicted a problem years before anyone else did
Hunt for long-forgotten statements they hope will discredit potential admin candidates, WMF liaisons, etc.

...after which they may re-open the old thread (will that be permitted?) or contribute to a discussion somewhere else. Either Flow must support such patterns of use (something like e-Discovery for legal cases) or Flow should be for live discussions only, with "closed" threads being archived in another form. But what would that look like? - Pointillist (talk) 13:25, 5 February 2014 (UTC)

Thanks. When you can search (more like filter) a Flow board to only show matching topics, I hope we'll get the best of both worlds. If you're collaborating on a particular topic, I think you would start with its permalink. With existing talk pages, following a link like Talk:SomeArticle#Section_heading when the section has been renamed or archived is very frustrating; permalinks are better in that you'll always get to see the topic, and we're working on making the UUID of the post a little shorter (but still opaque). -- S Page (WMF) (talk) 22:00, 3 February 2014 (UTC)

Yes, true permalinks would be an improvement for archiving. But I'd rather have permalinks and search results work as an entry point to the infinite stream, not only to see the linked topic isolated. I.e. following the link should show that topic at the top of the screen, but it should still be possible to navigate down and load the other earlier topics as "more content" (and probably there should be a link at the top to load "newer content" too). That truly would achieve the best of both worlds. Diego (talk) 23:15, 3 February 2014 (UTC)

email notifications

Tracked in Phabricator
Task T62913

Email notifications for flow are turned on. Very spammy. Might want to have the default be web only. Gaijin42 (talk) 19:24, 5 February 2014 (UTC)

Re: the default - good point, I've submitted bugzilla:60913 to cover that. Thanks. Quiddity (WMF) (talk) 21:01, 5 February 2014 (UTC)

flow and pings

I got a notification saying that Dougweller mentioned me in a comment. A link to "view board" was there. No way to view the particular post or diff. Since my name appears below EVERY post in order to let me reply, I cant even do a good search to find the post. Completely unhelpful. Gaijin42 (talk) 19:01, 5 February 2014 (UTC)

Did it not automatically scroll you to the post, or put a little green highlight by it? Okeyes (WMF) (talk) 19:38, 5 February 2014 (UTC)

Okeyes (WMF) No. Using Chrome 33. Just double checked. Kept me at the top of the page. I scrolled down and also did not see a green dot. Gaijin42 (talk) 19:46, 5 February 2014 (UTC)

It's not a dot, it's a vertical line next to the post; hrm. Mind giving me the URL provided with the mention? I'll see if it triggers for me. Okeyes (WMF) (talk) 19:55, 5 February 2014 (UTC)

Okeyes (WMF) Ah! I have discovered it!. It works fine if you just click on the entire notification, but if you click on "View Board" that just goes to the page. Maybe it would be a better experience to have a link for "View Board" and "View Post"? Gaijin42 (talk) 20:08, 5 February 2014 (UTC)

There's also the issue of "bundling" (documented at mw:Echo/Feature requirements#Bundling).

Eg. I have one Notification that says "Dougweller replied to your post in [...]" - That "post" link correctly goes to the specific reply.

But the next Notification says "Okeyes (WMF) and 1 other replied to your post in [...] - That link just goes to the top of the topic. This makes sense logically, but is somewhat confusing.

This is at heart an Echo issue, whereby we probably all need to re-examine the links that are given in the flyout and email - eg. You're probably used to clicking on the small "view changes" link in normal Echo-Mention Notifications, because that leads to the diff (which we power-users like or are used to reading).

We also need to re-examine how Notification-bundling works in Flow. Eg that "User:foo and 5 others replied to you" should probably highlight each of the 6 replies with the green bar.

Does that make sense? Quiddity (WMF) (talk) 21:15, 5 February 2014 (UTC)

Avatars

In #Custom signature, above, there is the remarkable statement from a WMF employee that WMF is considering the use of user avatars in discussions. I realize that it is an early stage in the discussion, about something called "Global Profile", and it is separate from Flow itself. But, I want the developers here to hear me loud and clear on this: you need to consult with the editing community before you implement anything like that, and find out what the editing community as a whole thinks about it. That should all go without saying, but experience tells me it needs to be stated explicitly. --Tryptofish (talk) 19:43, 5 February 2014 (UTC)

As I said above, avatars are outside of the scope of Flow. They are not on the table at this time. They are being considered as part of a different project, one that has been in the works for close to two years, and has already had a great deal of community consultation (it was even presented at Wikimania DC - I know, because I presented it - and I plan on doing a larger, deeper dive come London). We can pinch this one off for now, I think, and not let it become a distraction.--Jorm (WMF) (talk) 19:53, 5 February 2014 (UTC)

(edit conflict) Pinch whatever you want (well, not literally), and I already said that I know that it's unrelated to Flow per se, but you and your colleagues better hear what I said about discussion on-wiki at the English Wikipedia. Not Wikimania, not Meta, but amongst editors here. As in making WP:Global Profile a blue link and having community discussion. If that's too distracting for you, too bad. --Tryptofish (talk) 19:58, 5 February 2014 (UTC)

Tryptofish, as the conversations about Flow show we're totally willing to do that :). At the moment, though, Flow is expected to take around two years to have entirely wrapped up, and GlobalProfiles is going to be after that. So, it may be a bit early. Okeyes (WMF) (talk) 20:02, 5 February 2014 (UTC)

Thanks Okeyes. I appreciate that. It sounded like one of your coworkers was a bit eager for avatars. --Tryptofish (talk) 20:08, 5 February 2014 (UTC)

I would much rather have custom signatures than avatars. Wikipedia is not a social network. KonveyorBelt 19:54, 5 February 2014 (UTC)

Wikipedia is absolutely a social network. It's a multi-user project where users communicate with each other. It has a purpose different than Facebook or MySpace, to be sure, but that does not absolve itself of the fact that it is social software. --Jorm (WMF) (talk) 19:57, 5 February 2014 (UTC)

Yes, it's a social network, but it's not The Social Network, and not all social networks are the same. Not all social networks should be configured the same. --Tryptofish (talk) 20:01, 5 February 2014 (UTC)

Wikipedia is a social network if a social network is people talking. But a lot of the recent developements, even Flow, seem to turn users more to discussing than actually editing. I like custom signatures. If I see purple writing with green subscript I know that it's the signature of WormThatTurned. Signatures identify people. But I'd hate to see editors having to spend more time configuring the profile, avatar, etc., than consturctively editing the encyclopedia. That what's Wikipedia's for, right? KonveyorBelt 20:07, 5 February 2014 (UTC)

Yes, and coming up with rules to regulate whether a Nazi flag avatar is acceptable or not. And conducting RfCs to give those rules official status. While precious editor time could have been spent elsewhere. Keφr 22:21, 5 February 2014 (UTC)

(edit conflict × 2) I just posted some questions in "custom signature" section. Since a new section has been started, let me copy my post from there: "And what is global profile? Is it going to be an alternative of userpage? Or will it be hosted somewhere at Wikimedia Labs or Meta (like edit count page)." Tito☸Dutta 19:56, 5 February 2014 (UTC)

Indeed, we need WP:Global Profile. --Tryptofish (talk) 20:01, 5 February 2014 (UTC)

Per the other talk section, there is mw:GlobalProfile/design, but it is not current, and it's not here. --Tryptofish (talk) 20:04, 5 February 2014 (UTC)

When it's time to start discussion - that is, when we're able to do anything other than "pie in the sky" some ideas, then we'll open those conversations. Just like we did here.--Jorm (WMF) (talk) 20:09, 5 February 2014 (UTC)

Feature request: show "Older topics" on permalinks

When I follow a permalink to Flow, the topic is loaded on the page; but if the topic is related to other previous or later ones (a common situation in very long discussions, such as a heated debate leading to a Request for comments), the topic is devoid of the necessary context.

For example, following this post there is a comment by one user. I know this user has made several similar comments posted as the previous topics in the page, but to find those other topics I need to:

Navigate to the main board "Talk:Flow"
Find again the same comment I was reading a moment ago, by scrolling down until the comment is loaded
Continue scrolling down until the next comments are loaded.

This search process could be avoided if, after following a permalink, the topic page included an "Older posts" link that works just like the one in the main page, by loading the topics immediately before the current one. (Bonus points if you also provide at the top a "Newer posts" that allows loading later topics). Diego (talk) 13:06, 5 February 2014 (UTC)

Don't you just love these Flow Permalinks? Thoroughly tested for usefulness. Corrected as soon as an issue was raised that had escaped the diligent testing. Exemplary effort. Fram (talk) 13:57, 5 February 2014 (UTC)

Apparently you can fix it by editing the URL by hand and removing the [postId]. Diego (talk) 18:06, 5 February 2014 (UTC)

Diego, that's an interesting idea. It seems potentially confusing to see a single topic and then by loading older and newer posts above and below, you sort of turn it back into the entire Flow board. Meanwhile, when you visit a permalink the sentence at the top "This topic was started on _Talk:Flow_" should definitely take you back to the topic in context on the board; that's T60251 "Flow: links back to board should display current topic." It's hard to meet everyone's expectations of what the permalink should do; an initial specification for permalinks called for a menu of options — URLs+wikilinks to current+historical versions of the post. -- S Page (WMF) (talk) 22:14, 5 February 2014 (UTC)

Hmm, but what happens if a topic is attached to more than one board? Should there be different permalinks depending on the context one want's to show? Or better just one permalink showing the topic alone as now, and then something like "This topic was started on Talk:Flow, and is also attached to Talk:Foo and Talk:Bar", each linking to the topic in context? — HHHIPPO 22:30, 5 February 2014 (UTC)

I didn't think how multiple boards should be handled, as it's not at all clear how that feature is expected to work. The current permalink already has a link to the board where it was created; the "show more comments above/below" should refer to that same board.

It would be great if following the "parent board" link showed the topic in context; my suggested "older/newer topics" could be replaced by a single "show in context" link (but then again, why would you need the permalink to filter only the selected topic, instead of showing it in context from the beginning?)

But that has problems of its own. How does it interact with the "infinite scroll" thing? What should be loaded "above" the topic - all the comments and topics more recent than this one? What if the topic is five years old? Would you lazily load new topics when scrolling up?

At least with my version any new topics are loaded only upon an explicit request by the user, and loading more topics requires more requests. This is equivalent to a form of pagination, which we have been using for decades. Diego (talk) 23:44, 5 February 2014 (UTC)

Please disable Flow from enwiki

Why has Flow been enabled on enwiki, when the discussions and tests on Mediawiki have shown enough major, major problems to keep you busy for quite a while?

We have:

No decent history
No decent watchlist entries
No archiving
No good search options
No indication of how we can enable and disable Flow (locally, not by asking)
No categories (the old talk page was on what, four categories?)

And so on. Some of these were part of the minimal requirements and promised to be implemented before going live with it.

If you desperately needed to test Flow here, why not use this page instead of a live environment? Fram (talk) 14:00, 4 February 2014 (UTC)

Honestly, as had been said at the tests at MediaWiki, this is not ready for enwiki. But why have we even bothered giving feedback as it obviously isn't taken into account... When you go to someone's history, you see

13:55, 4 February 2014 (topic) . . (+1,340)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:10, 4 February 2014 (topic) . . (+468)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:06, 4 February 2014 (topic) . . (+359)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:03, 4 February 2014 (topic) . . (+295)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:02, 4 February 2014 (topic | post) . . (+13)‎ . . Jayen466 (talk | contribs | block) edited a comment. 05:01, 4 February 2014 (topic) . . (+361)‎ . . Jayen466 (talk | contribs | block) added a comment. 04:59, 4 February 2014 (topic) . . (+276)‎ . . Jayen466 (talk | contribs | block) added a comment. 04:57, 4 February 2014 (topic) . . (+858)‎ . . Jayen466 (talk | contribs | block) added a comment.

No obvious display of where it happened, no edit summaries, no undo(!!!) or rollback(!!!). (Note: Jayen486's edits don't need undo or rollback, it's an example). Fram (talk) 14:38, 4 February 2014 (UTC)

I agree with Fram. Tito☸Dutta 14:40, 4 February 2014 (UTC)

Another funny problem; you can't see from your watchlist whether you have checked an edit yet or not; the "Pages that have been changed since you last visited them are shown with a green bullet." doesn't work, once you have been to a Flow page, all later comments will be stuck with a "blue" bullet as well. Apparently, when you've seen one, you've seen them all... So, like I said, history, watchlist, ... are all totally useless with Flow, and no alternatives are ready. Fram (talk) 14:49, 4 February 2014 (UTC)

All the issues you mention affect only people who use these two WikiProject talk pages. It was the decision of those two communities to give Flow a try, even though it's not done, and it's up to them if and when they want to go back to a standard talk page. I agree that Flow is not ready for a broad deployment, but I don't see any reason here to diable FLow from enwiki as long as the people actually affected by it are happy to test it.

The issues mentioned below, CU and RevDel not working, are a bit more worrying. However, what's the damage if we have no CU on two low-traffic pages for a while? How often is it usually used there? And is it really not working at all? I would guess all the needed data are somewhere in the database, it's just that the usual interface to retrieve them doesn't work here yet. But that doesn't mean CU is impossible, it might be one just has to wait until the interface works, and then retrieve the data, or it might be possible for the devs to retrieve the data manually if necessary.

For RevDel I guess we have to rely on the devs for the time being. I'm sure they have a close eye on these pages and they have the ability to RevDel by backend-magic if needed, so they can take on that role of administrators/oversighters until the feature is implemented. Maybe one of them can confirm this here to smooth the waters? — HHHIPPO 20:06, 4 February 2014 (UTC)

I don't mind this tool's implementation in the mentioned two pages. But in current condition I'll not like to see an announcement like "The initial Flow test was successful. But we realised not all editors (specially the new editors) don't follow these announcement discussions and have not got opportunity yo test this feature it. So we are extending flow to more/all talk pages." Flow is a powerful tool, it needs improvement Tito☸Dutta 21:08, 4 February 2014 (UTC)

No, the issus affect all admins, bureaucrats and so on. You have implemented new software, albeit on a very limited basis, that is totally unsuitable for any admin actions. Apart from the things listed by Risker below, and the things listed by me above (like the lack of undo, rollback, ...), there is also e.g. no option to protect or semi-protect Flow pages. And of course, when you have them on your watchlist, they literally flood your watchlist with totally unusable entries, instead of following the standard watchlist options. Absolutely useless, as said (but ignored) at MediaWiki. What's the point of having a test environment if you don't bother to fix the most basic errors before going live? Fram (talk) 07:53, 5 February 2014 (UTC)

So....protection works on MediaWiki.org, but apparently it hasn't be deployed to enwiki yet. Legoktm (talk) 08:05, 5 February 2014 (UTC)

Nono, we must be mistaken the MediaWiki admins in their wisdom have declared that protection and so on is available and works on Flow pages at enwiki; [8] (corrected link, there seslf-generated permalinks don't work in wikitext, as I had posted there a while ago...). I have seen many problematic replies from MediaWiki, but this one must be the icing on the cake, telling us without checking and without being able to check that we are wrong, and that protection is available to enwiki admins for flow pages. I thought ivory towers were a pre-1968 concept, but apparently this hasn't reached every institution yet. Still, they have now eliminated the one major problem (me) with a speed one normally never sees at MediaWiki when actual problems are reported. The wonders of IRC probably. Like Joe Jackson said, "If my eyes don't deceive me, there's something going wrong around here". Fram (talk) 09:47, 5 February 2014 (UTC)

@Fram: I looked into it a bit more. Protection can be enabled for Flow pages, it's just not exposed in the UI (?action=protect) until 1.23wmf12 is deployed to enwiki (Thursday). Protection can be applied via the API if you wanted. Legoktm (talk) 16:41, 5 February 2014 (UTC)

Well, if an option isn't accessible, the result for me as end-user admin is that it isn't available. Luckily it worked through Twinkle, but the standard protection was not available. Thanks for looking into this, it's not you I'm pissed at if I come across somewhat ungrateful. Fram (talk) 07:28, 6 February 2014 (UTC)

Flow live on Enwiki

Testing can be done at Wikipedia talk:Flow/Developer test page. Thanks!

Newer code (arriving here soon) can always be seen at mw:Talk:Sandbox, or even newer code at http://ee-flow.wmflabs.org/wiki/Sandbox.

Hi folks. I'm pleased to announce that, with the permission of the users involved, we've deployed Flow to Wikipedia talk:WikiProject Breakfast and Wikipedia talk:WikiProject Hampshire. Obviously, the intent is for editors to use the Flow boards as they would a normal talk page, so please don't use it for testing (unless you're a wikiproject member, of course!) - just use the test space at mw:Talk:Sandbox. If you've got feedback, please feel free, as always, to leave it either here or on the MediaWiki.org Flow talkpage. We'll be asking them directly in 2/4 weeks whether they're happy to continue testing, but will greatly appreciate all the feedback you all can give in the meantime. Once the first set of WikiProject members have had a chance to try out the software, we will be seeking other WikiProjects to volunteer for participation in this working-environment testing. Quiddity (WMF) (talk) 22:15, 3 February 2014 (UTC)

Basically as predicted: I tried to watch Wikipedia talk:WikiProject Hampshire, which made my watchlist unusable: About half of the top screen are taken by the activity of the Wikiproject talk. Unwatching now until smth gets modified.--Ymblanter (talk) 22:37, 3 February 2014 (UTC)

My experience from the Flow talk page on mediawiki.org is much the same. The truth is, it will require a slight shift in behavior. Unless you really want see all discussion activity, I would just unwatch a Flow board and instead wait for notifications that are built in when someone replies to a thread you're participating in or mentions you. Steven Walling (WMF) • talk 22:55, 3 February 2014 (UTC)

Well, no, because then you never get to actually see what's going on unless you've already participated. User:Ymblanter, this is a bug, not a feature; we'll be fixing and limiting it in the next 2 weeks. Okeyes (WMF) (talk) 22:58, 3 February 2014 (UTC)

@Okeyes (WMF): really? It would be nice but doesn't seem to correspond to what Quiddity (WMF) replied to Fram on mw just 7 days ago. Could we get new feedback there, also on the proposals made by Skalman and myself (here)? Klipe (talk) 11:58, 5 February 2014 (UTC)

Klipe, the permalinks generated by Flow are not working in Wikitext. This had been noted at MediaWiki, but not corrected yet, and not disabled either. The point of keeping the permalinks active while they can't be used correctly escapes me, but it doesn't really surprise me. Fram (talk) 12:01, 5 February 2014 (UTC)

Fram: I know about 2 issues with Permalinks (cf topic Permalinks on mw): URL containing square brackets and target post not being highlighted. It seems that at least the second one has been fixed in MediaWiki, and I know the workaround for the first one, so my links do actually work (at least for the time being and from Firefox on Win and OSX, as far as I can tell). Klipe (talk) 06:51, 6 February 2014 (UTC)

Klipe, I had started composing my post between your initial post above, and the revised version: [9]. So while your corrected link works, "the permalinks generated by Flow are not working in Wikitext" (like I said in my post). Fram (talk) 07:33, 6 February 2014 (UTC)

So if you're hiding this, will normal users get to see a topic has been replied to, as normally shows up on a watchlist or will you have to go to a talk page to discover what discussions have been going on? Also, why is the font so big? Finally, the Flow project has (I assume temporarily) wiped the history from WikiProject Hampshire and only replaced it with the Flow discussion history. Simply south...... disorganising disorganisation for just 7 years 00:02, 4 February 2014 (UTC)

@Simply south: Re: watchlist contents - there's definitely some tweaking needed, both immediately, and over the long-term as new features (such as per-topic watchlisting) get added. In the short-term, I believe they'll be aiming to get it to display as we expect (ie. only showing the last/most-recent change to the Board). But ideas for how it could be even better than the-standard-watchlists-we-have-now, are warmly appreciated. (Some ideas have already been put forward, but not compiled yet. Plus I'm hoping that we'll get some new/unique ideas if editors aren't presented with a list of options, but rather are given a blank slate to dream upon..)

Re: Font size in Flow Boards - there's an FAQ entry that briefly touches upon this issue (linking to a single ref). I'll ask the design team for additional info.

Re: History - I did a page-move archive so that the page history was easily accessible. :) Quiddity (WMF) (talk) 00:26, 4 February 2014 (UTC)

Additional issues

There are problems with both Checkuser and suppression which have been reported directly to the team and through Bugzilla. (As an aside, the enwiki functionaries were of the impression after running into serious issues with AFT5 that the WMF wouldn't release new extensions that permitted editing, even as tests, until it was certain that both CU and OS were properly integrated and functional. We were apparently incorrect in our understanding.)
Somehow the software is incorrectly determining which comment a user is responding to, and is sending notifications to the wrong person. I have received emails telling me that a user has responded to me, only to find that they were responding to someone else's comment entirely. I am assuming that the editor to whom the response was directed did not receive an email notice, either. This is repeated in the Echo notifications here onwiki.
I was unable to post a reply comment today when coming from the emailed link. I could type it, but it would not save. (I'm working on a different computer, WinXP on IE7.)

These are fairly significant issues, I think. Risker (talk) 14:18, 4 February 2014 (UTC)

I got a notification that I was "mentioned". I think you got a notification that someone had replied to you because you had posted the parent post. Assuming I am right, this means that if you have the temerity to start a discussion (equivalent to starting a talk page section) that will draw many commenters, your notifications will be inundated for days. You'll get a message that "someone replied to you" every time someone posts to the topic or subtopic you started. Andreas JN 466 16:27, 4 February 2014 (UTC)

Perhaps partially correct, although I've not started any topics, so not entirely bang on. In my early posts, I assumed that the space at the bottom of my screen was where I typed replies, and that resulted in outdented messages, but they weren't new topics. As far as I can tell, though, some of the emails I'm getting trace back to comments that don't start with me at all. Risker (talk) 16:30, 4 February 2014 (UTC)

The quantity of Notifications that are sent, vs what are wanted, is definitely an issue. Currently, the person who starts a topic, will get notified for each response to the entire topic, which is clearly too much in some cases (very active threads over a short time span), but might be wanted in (all?) other cases. Bundling the Notifications better ("User:Foo and 5 others have replied to your topic") might be a good start. Perhaps we want per-topic preferences (although that would create added UI and database complexity)? What other possibilities are there, and what would we prefer?

The incorrect Notifications might be related to bugzilla:60376, or might need to be captured in a new bug. Quiddity (WMF) (talk) 18:08, 5 February 2014 (UTC)

The team should also be aware ofthis. I do hope you'll let the user know when the test is over so they will feel comfortable in returning. Risker (talk) 17:01, 4 February 2014 (UTC)

Noted. Thanks for the pointer. Quiddity (WMF) (talk) 18:08, 5 February 2014 (UTC)

Redrose's objection to Flow was noted in the straw poll the wikiproject took, where they decided to use Flow. I'd like to make clear here that while I'm not pleased to see any user go, it's not surprising, and the future of the Flow test on those WikiProject talkpages will be driven by the participants in that WikiProject, not you, me, the WMF or any individual user. Okeyes (WMF) (talk) 18:13, 5 February 2014 (UTC)

If it impacts other users, outside that project, like with the Echo problem yesterday, then the future of Flow on these talkpages will definitely be driven by the full community, not by the participants in that wikiproject alone. And even if it only directly impacts users of a specific page, then it still may be decided by the community that we don't want it anywhere, e.g. for security or BLP reasons (like if we can't use our normal admin tools and so on on those pages). Fram (talk) 07:38, 6 February 2014 (UTC)

Please disable Flow from enwiki (bis)

So, with one simple edit, I have accidentally but apparently completely broken "Echo" for dozens of users (see the "Flow + Echo = Error?" section higher on this page). Can we now perhaps disable Flow until even more serious errors occur? This thing is not ready to be used on live environments, not even when it is only used on a few pages, and already affects people badly (both people not editing these pages but getting the errors from it, and people usually editing thes epages but removing them from their watchlist because of the wtachlist pollution). Fram (talk) 14:34, 5 February 2014 (UTC)

One problem is that Wikipedia talk:WikiProject Comics doesn't only contain the user names of those who have edited that page, but also the user names of lots of people who are involved in the page creation and deletion processes by virtue of transcluding User:AlexNewArtBot/ComicsSearchResult and Wikipedia:WikiProject Comics/Article alerts, which contain lots of user names. Result: Lots of additional people received a notification.

People who have switched on e-mail notification at Special:Preferences are able to find the Flow thread by clicking on a link in the e-mail and from there find this discussion. People who haven't switched on e-mail notifications can unfortunately not even see why they were notified, let alone find this discussion. --Stefan2 (talk) 14:51, 5 February 2014 (UTC)

So basically, the first determined vandal who reads this can create an account and disable Echo for most regular editors with only a few choice edits. Nice! Fram (talk) 15:02, 5 February 2014 (UTC)

Maybe you could temporarily blank and protect WP:NOE and similar pages which contain lots of usernames? It's not practical to blank discussion pages such as WP:ANI, though, so it is still possible to cause lots of disruption. --Stefan2 (talk) 15:16, 5 February 2014 (UTC)

I would protect the three pages that have Flow enabled now to stop this disruption from happening, but, oh right, protection isn't enabled on this pages at enwiki (this has been noted at MediaWiki, but the admins there refused to believe this). And I can't delete the three pages either, since that hasn't been disabled for Flow a well. And I can't remove Flow from them, since while Flow is opt-in, apparently we aren't able to choose this, we have to ask the MEdiaWiki people to change this. I thought VisualEditorr couldn't be topped as worst release ever, but the WMF sure is trying their hardest to prove me wrong! Fram (talk) 15:08, 5 February 2014 (UTC)

Hm. Talk pages of deleted pages are normally deleted per WP:CSD#G8. Will admins not be able to do this in the future? --Stefan2 (talk) 15:16, 5 February 2014 (UTC)

Rest assured, we will whine until we get our way :-) I hace raised this issue at WP:ANI now, this really is too urgent to let pass. Fram (talk) 15:22, 5 February 2014 (UTC)

If you'd listed those 100 users on a _normal_ talk page and signed it it would've done probably the same thing. Okeyes (WMF) (talk) 16:07, 5 February 2014 (UTC)

Are there any plans to fix it, or have I permanently lost my ability to view my notifications? If it is a bug with echo, is it just coincidence that it didn't affect me till this flow thing was enabled? Optimist on the run (talk) 16:25, 5 February 2014 (UTC)

You didn't lose it because Flow was enabled, you lost it because User:Fram transcluded a page containing hundreds of usernames, triggering notifications for those users. There are absolutely plans to fix it; I'll make sure it's in our next chunk of work (we have the planning meeting today). Okeyes (WMF) (talk) 17:38, 5 February 2014 (UTC)

Okeyes, can you stop spouting the same nonsense over and over again? Transcluding that page anywhere wouldn't have caused any problems at all. But because Flow stupidly substitutes instead of transcluding, and because there was a bug in Echo, things got totally broken. So yes, people lost their Echo fucntion because Flow was enabled on Enwiki despite serious reservations and bugs, and because a test revealed further problems. Without Flow, this wouldn't have happened. Fram (talk) 07:44, 6 February 2014 (UTC)

Fram's right, this is a serious potential weakness and so the test page should be at least protected, or even better completely disabled here. It is inexplicable to me why this is being tested here within the en.wiki site instead of at another Wikimedia domain or an offline intranet. The fact that an innocent test edit could completely remove a vital function for dozens of editors in one fell swoop shows that Flow isn't ready to interact with this site at all. It's really an unacceptable response to blame that on Fram rather than on whoever made the decision to enable Flow here. So speaking as one of those editors who now doesn't have working notifications, knock it the fuck off and fix what your new toy broke. Show us that you learned something from the VE debacle. postdlf (talk) 18:29, 5 February 2014 (UTC)

Please calm down, Postdlf. In order:

The test page can be protected (and will have full protection functionality for users, not just through the API, tomorrow);
It's being tested here because the people on those wikiprojects held a straw poll and volunteered to test it;
I'm not blaming the bug on Fram, merely this particular instance of it. It's worth noting that the same issue would've happened without Flow if someone created a revision of sufficient size on a normal talk page.
The bug will be fixed today: we've got a lightning deployment at around 4pm for this specific bug. Okeyes (WMF) (talk) 18:47, 5 February 2014 (UTC)

Okeyes, I think you are totally mistaken. Normally, when you transclude a page, you wouldn't have any problem. However, Flow for some reason didn't transclude the page, but substituted it, and all subpages on it as well. No idea why it did this. But this is a Flow-only bug, not somethng I could have done on any other page. Fram (talk) 20:12, 5 February 2014 (UTC)

Nnno, read what I actually said; the issue is the combination of "a mention" and "the size of the revision". Yeah, the substitution is a problem, but not the root of the issue. Okeyes (WMF) (talk) 20:15, 5 February 2014 (UTC)

Not having notifications for Flow enabled by default in user preferences also would have avoided this. postdlf (talk) 20:21, 5 February 2014 (UTC)

Okeyes, the "size of te revision" was caused by Flow, not by me. I transcluded a page, the size of that revision should have been +20 or thereabouts. Flow decided that transclusion is for wimps, and substituted it instead. I read what you actually said, please return the courtesy in the future. Fram (talk) 07:44, 6 February 2014 (UTC)

I don't see how Flow could do actual transclusions, since it's parsing wikitext at save time rather than at display time. The only thing that can be improved here is the documentation.

Either way, it seems the same bug in Echo could have easily been triggered by explicit substitution on any page, Flow or not, or even by editing a large page. Turning off Flow wouldn't have solved that, fixing the Echo bug did. Thanks to whoever fixed it so fast btw. — HHHIPPO 08:39, 6 February 2014 (UTC)

If Flow can't do transclusions, then we have a serious problem. But it seems to do transclusion of templates fairly well, only not of pages from other namespaces (I may be mistaken here, just giving my impression). "Editing a large page" ha never triggered this bug, or it would have been known since long. The page I transcluded (well, substituted accidentally) is a standard wikiproject talk page, not exceptionally large or anything, and no edits on that page have caused any problems before. Apparently, if I had substituted that page somewhere else, it would have caused the same problems: no idea whether that is true or not, no one tested it. But the difference is of course that transclusion of pages is much more common that substitution of pages. And anyway, at the time of my report, the only thing that was known to cause these problems was transcluding a page on a Flow page. Disabling Flow, which was only being tested on three pages anyway, was the easiest solution to prevent abuse of this problem until the root caues was found and fixed. Fram (talk) 09:08, 6 February 2014 (UTC)

There are important differences between substitution and transclusion which I think need to be addressed:

If I add {{Wikipedia:Flow}} to a page, then you can see that the article Wikipedia:Flow is transcluded by looking at the list of transcluded pages.
If I add {{subst:Wikipedia:Flow}} to a page, then you can't figure out where I found the text which I inserted. As you can't figure out where to find a list of authors, I am violating the copyright of the page Wikipedia:Flow by failing to satisfy the attribution requirement.
If the page Wikipedia:Flow subsequently is updated, then the updates will appear on the pages using {{Wikipedia:Flow}} but not on the pages using {{subst:Wikipedia:Flow}}. This is an important feature for multilingual templates such as Commons:Template:Unsigned where an updated version of the template may contain translations into more languages than currently available, thus making the template readable for more contributors.
If you substitute a large template, then the wikicode takes up a lot more space and it becomes harder to read and edit the page. On the other hand, if you transclude it, then the wikicode still only takes up very little space. --Stefan2 (talk) 14:14, 6 February 2014 (UTC)

February 6 updates

With the Thursday deployment train, these changes have arrived on Enwiki today:

Separate and static "Reply • Edit" links for posts
Other post actions are in a "[...]" action menu - (The icon itself is still being discussed. The color (light grey) will become darker with next Thursday's update.)
Timestamps no longer link to topic/post history - (Now in the action menu. More logical sorting for the action menu is underway.)

See/test those changes at Wikipedia talk:Flow/Developer test page.

Thanks. Quiddity (WMF) (talk) 00:15, 7 February 2014 (UTC)

The full changelog of changes is at mw:MediaWiki_1.23/wmf12/Changelog#Flow, though quite a few of them don't affect user interaction (like unit tests). Legoktm (talk) 00:23, 7 February 2014 (UTC)