Wikipedia talk:Flow/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

→

Archive 15

Through The Looking Glass

"There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone." --Bjarne Stroustrup

Background: (You can skip this section if you want.)

A while back I looked at something (exactly what is not important) that Wikipedia:Flow said would definitely be a feature of Flow. Alas, it was not theoretically possible. Not just hard. Impossible. Perpetual motion impossible. Turning lead into gold impossible. Despite the fact that nobody at the WMF (or anywhere else for that manner) could describe the steps that they hoped would get us to the impossible result (because no such sequence of steps exists or can exist) when asked about this someone from the WMF claimed that they do know how to do this impossible thing. (Who said what is not important. I am trying to fix the problem, not fix the blame). Later the claim was quietly deleted from the page. Not the ideal situation, but such things happen when it takes specialized technical knowledge to realize that something isn't just hard but is actually theoretically impossible.

The problem is not that error, but the reaction when I identified it. Rather than simply changing the page, I was first told that the impossible is possible, then told that Flow is completely undefined in all aspects and that no design decisions have been made, followed by further unpleasantness that isn't relevant here. Of course we all know that Flow is not undefined, and design decisions have been made. For example, it has been decided that Flow will sign your comments instead of asking you to add four tildes ("~~~~") at the end. That is not going to change, nor does anyone want it to.

There is a page at http://blogs.atlassian.com/2013/07/agile-requirements-documentation-a-guide/ and another at http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm that describe Agile Requirements Documentation.

The Agreement

Because of the above, we worked out a solution that everyone agreed to. We agreed that the WMF would pick a page on the English Wikipedia (Wikipedia:Flow would be a good choice) that documents, in broad strokes, WMF's current understanding about what Flow is.

This document was to contain selected "we haven't decided yet" items and selected "we don't know yet" items, but it was also to document everything that we know we are going to do (autosigning posts, for example). This document was to be kept short with broad strokes, not TL:DR detailed documentation. It would also document those things that we have agreed not to do, along with selected items that are desirable but might not or probably won't get done.

We agreed that, when we decide something here on this talk page and everyone agrees that it will be (not might be) done, someone at the WMF would update the page to reflect that decision. That edit would then be considered to be a promise and a commitment.

Of course even the best-laid plans sometimes need to be modified, so if the plans change, someone at the WMF would update the page and post a message on the talk page. Something like "Remember that autosigning thing we all agreed on? I had to move it into the 'we don't know yet' section because of...".

We also agreed that, every so often, key members of the Flow team would look the page over and make sure we don't have something in there that they will object to later.

That is what we agreed to do, and I set a reminder on my computer to fire in three months so I can whether it was done.

It has been three months. Nobody has notified me that it is done. Wikipedia:Flow mentions few things in the lead and in the "expectations" table, but it falls short of what I expected and what I thought we agreed to do.

I was especially disappointed when I checked https://wikimedia.mingle.thoughtworks.com/projects/flow/cards/288 and saw that it had been marked "done" without the slightest indication that anyone has actually done anything to implement my suggestion. --Guy Macon (talk) 04:07, 5 February 2014 (UTC)

Have you checked the various pages on MediaWiki.org, linked to from the sidebar of mw:Flow? — This, that and the other (talk) 05:33, 5 February 2014 (UTC)

Yes. I have. The page that comes closest is at at https://www.mediawiki.org/wiki/Flow/FAQ (which appears to be duplicated at Wikipedia:Flow/FAQ), but it really isn't documentation of what has been decided, but rather is answers to frequently-asked questions. Now it is true that the answer to a frequently-asked question often includes information about something that has been decided, but many of the items on that page are not about decisions made, I also see no indication that anyone considers a FAQ entry to be a promise and a commitment, or that every so often key members of the Flow team read the FAQ to make sure we don't have something in there that they will object to later. So basically, while it is a very useful FAQ, it isn't quite what we agreed on. Nor should it be expected to be what we agreed on, considering the fact that it was created nine months before we agreed. --Guy Macon (talk) 14:07, 5 February 2014 (UTC)

I concur with Guy Macon's sentiment - the current set of Flow publicized documents falls way sort of allowing "the stakeholders" (i.e. us) follow track of what has been decided, what is being considered and to what degree, and what won't happen; which is dissapointing, as these were supposed to happen in the open. Following regularly the several separate talk pages seems to be the only way to keep track of things, and those are frecuently lost in the archives. Diego (talk) 15:01, 5 February 2014 (UTC)

I've found Flow_Portal/MVP, which is more aligned with this request. Funnily, it's not linked from Wikipedia:Flow. Diego (talk) 15:07, 5 February 2014 (UTC)

Yes it is; see "requirements for the first release".

I did read that. In fact, I spent several hours closely examined every document I could find on Wikipedia and Wikimedia before posting this (which doesn't mean that I didn't miss something important). Here is a test (necessary but not sufficient) that will tell you if a page is what I described above. Does it document our decision to replace manual signing using ~~~~ with automatic signing? If it doesn't meet that minimum requirement, it is not what I am talking about. --Guy Macon (talk) 04:45, 6 February 2014 (UTC)

• Guy; I'm sorry if we've let you down :/. Would it be useful to have a more detailed conversation about what you'd like documented, so we can work on it? The above commentary is a good start, for example. I definitely recall surfacing the table and everything on the talk page a month or so ago, though. Hrm. Okeyes (WMF) (talk) 17:45, 5 February 2014 (UTC)

• I will be glad to do anything I can to help, but before we discuss in detail what decisions should be documented, we need at least a stub page that documents one decision. I suggest starting with autosigning, because I have already established that autosigning has unanimous support from the WMF and from the Wikipedia community.

Then, once we have that page, we need to have some indication that, as a group, the involved stakeholders on the WMF side have read the page and have made a commitment/promise that they will never come back and say "we never agreed to autosign" or "I was against autosigning from the start but haven't said anything until now". Saying "I used to support autosigning but I no longer do because of the following" is perfectly acceptable, with the assumption that you should have a good reason for going back on a promise/commitment.

I am going to try to explain the problem from the past that I am trying to solve for the future, but I need everyone to try really, really hard to stick to the topic of the document I am describing and not to re-discuss something from the archives just because I referred to it. I am also asking that if someone else does try to re-discuss the old issue that you do not reply, even to ask them to stop. Can we do that, please?

From mid-May 2013 to mid-September 2013‎ (four months) Wikipedia:Flow contained[1] the following text:

"Current plans indicate that there will be:

No edit conflicts, ever.

No unsigned posts in discussions—all posts and comments will be automatically signed and dated."

You will, of course, recognize that second one as our old friend, autosigning.

Alas, "No edit conflicts, ever" is impossible. I wrote up a detailed explanation as to why this is impossible at Wikipedia talk:Flow/Archive 4#Brewer’s Conjecture. Yes you can reduce edit conflicts by a lot, and yes, you can move the effect around (right now you can't save your edit without addressing the edit conflict. You can make it so that you can't start editing if there is another editor in the middle of an edit, but that does not mean the edit conflict didn't happen). You can even let one editor work on one sentence and another on the next sentence (with some limitations) but you simply cannot achieve the goal of "No edit conflicts, ever"

Again, I do not want to revisit the issue of edit conflicts. Please focus on the fact that the page made two promises, one that is desirable and easy, and another that is desirable and impossible. That's the background. Now I am going to discuss the problem. When I pointed out that "No edit conflicts, ever" is impossible, the reaction was to claim that nobody ever promised that or committed to that. Which of course implies that nobody ever promised autosigning or committed to autosigning. What came out of all of this was that we lack a page where we document what we have decided. So let's create that page, populate it with the one promise/commitment that we know we have, and have someone on the WMF side be in charge of getting positive confirmation that there is nothing on that page that anyone on the WMF side objects to, a task that will be repeated once a month. It really is that simple.

By the way. if anyone is about to reply with a suggestion that I create that page, that has already been addressed. Yes, I could create it myself. In fact I could edit all of the projects customer-facing documents. That would be very much like this passage from Shakespeare's Henry IV:

GLENDOWER: I can call spirits from the vasty deep.

HOTSPUR: Why, so can I, or so can any man, But will they come when you do call for them?

In other words, I can edit the documents, but I cannot make the developers do what the document says that they will do, and I cannot prevent anyone on the WMF side from coming back later and saying (rightly so) that I don't give them orders and that they never had any intention of doing what I ordered them to do. --Guy Macon (talk) 04:45, 6 February 2014 (UTC)

(Sound of crickets...) --Guy Macon (talk) 04:46, 7 February 2014 (UTC)

...Chirp... --Guy Macon (talk) 04:47, 8 February 2014 (UTC)

Sorry for the lack of reply; the volume of posts to this page has been throwing me off (oh, for a discussion system that notifies me when I'm replied to-wait ;)). I'll write something substantive up on Monday, if that's okay? I'm spending my weekend trying to get to an analytics task that I fell behind on. Okeyes (WMF) (talk) 01:15, 9 February 2014 (UTC)

Minor thing - could I ask you to please not use "surfac[e|ed|ing]" in communications with the community? It's jargon whose meaning will not be obvious to many people. Thank you. — Scott • talk 01:25, 9 February 2014 (UTC)

@Guy Macon: Apologies from me, too. Last week was very busy, and I was trying to rapidly answer some of the simpler questions here and at mw in the latter half.

For a very short answer: The table that Okeyes mentions above, is the one at Wikipedia:Flow/FAQ#Components of the discussion system, which is what we put together after the last discussion about this. The Flow team (and I) have been updating that table fairly regularly, with many of the broad-concerns.

What would you (or anyone) like to see changed, regarding that table? We could move it to the main WP:Flow page (leaving a redirect link) but as it expands that could result in TL;DR? We could add a few items, or dozens of items, to it? We could do something else entirely, and leave that as it is?

Fwiw, I do need/intend on updating the Flow project navboxes (both here and on mw) soon. I recently re-organized the main page index (mw:Flow/Pages), and I've been trying to add major discussion thread links to mw:Flow/Prior discussion-thread-roundup over the months (but it's not complete, and needs more subsections. Assistance welcome).

As with all communications problems, it's always a delicate tightrope walk between overwhelming detail, and insufficient detail; mixed with the problem of varying demographics (technical-folk, foreign-language-folk, wikignomes, admins&checkusers, WP newcomers, etc etc), and the problem of different preferences (m:mergism vs m:separatism in this case). Everyone's advice, is welcome. Quiddity (WMF) (talk) 22:14, 10 February 2014 (UTC)

I find the above to be somewhat frustrating to read, because it ignores my previous explanation that Wikipedia:Flow/FAQ in general and Wikipedia:Flow/FAQ#Components of the discussion system works well as part of a FAQ and should be retained where it is, but is not what I am talking about, which is a solution to the problem that WE LACK A PAGE WHERE WE DOCUMENT WHAT WE HAVE DECIDED. We. Lack. A. Page. Where. We. Document. What. We. Have. Decided.

I have already explained, several times over, what "a page where we document what we have decided" should look like. I have no idea why I am failing again and again to communicate this simple concept, or why I keep being pointed to things that utterly and completely fail to be a page where we document what we have decided.

I am not sure how I could have possibly made the following (cut and pasted from the discussion above) any clearer:

"The page that comes closest [to being a page where we document what we have decided] is at at https://www.mediawiki.org/wiki/Flow/FAQ (which appears to be duplicated at Wikipedia:Flow/FAQ), but it really isn't documentation of what has been decided, but rather is answers to frequently-asked questions. Now it is true that the answer to a frequently-asked question often includes information about something that has been decided, but many of the items on that page are not about decisions made, I also see no indication that anyone considers a FAQ entry to be a promise and a commitment, or that every so often key members of the Flow team read the FAQ to make sure we don't have something in there that they will object to later. So basically, while it is a very useful FAQ, it isn't quite [a page where we document what we have decided]."

I even provided a specific test that you can perform to determine whether the document you are pointing me to is, indeed, a page where we document what we have decided:

"Here is a test (necessary but not sufficient) that will tell you if a page is what I described above. Does it document our decision to replace manual signing using ~~~~ with automatic signing? If it doesn't meet that minimum requirement, it is not what I am talking about"

Can you understand how frustrating it is to write the above very clear and specific statement and then later be asked "What would you (or anyone) like to see changed" regarding something that does not in any way attempt to document the ONE decision that I said should be documented?

I did mention that we lack a page where we document what we have decided, right? because I mentioned it before and yet I am still being told to look at various documents that are not even close to being what I asked for, which I remind you in case anyone forgot is "a page where we document what we have decided." So here it is again:

• We agreed that the WMF would pick a page on the English Wikipedia (Wikipedia:Flow would be a good choice) that documents, in broad strokes, WMF's current understanding about what Flow is.
• This document was to contain selected "we haven't decided yet" items and selected "we don't know yet" items, but it was also to document everything that we know we are going to do (autosigning posts, for example).
• This document was to be kept short with broad strokes, not TL:DR detailed documentation.
• It would also document those things that we have agreed not to do, along with selected items that are desirable but might not or probably won't get done.
• We agreed that, when we decide something here on this talk page and everyone agrees that it will be (not might be) done, someone at the WMF would update the page to reflect that decision.
• We agreed that that edit would then be considered to be a promise and a commitment.
• We agreed that if the plans change, someone at the WMF would update the page and post a message about it. Something like "Remember that autosigning thing we all agreed on? I had to move it into the 'we don't know yet' section because of...'".
• We also agreed that, every so often, key members of the Flow team would look the page over and make sure it doesn't contain a promise/commitment that they do not agree to.

Please, before composing any reply that claims that some existing piece of documentation is "a page where we document what we have decided", ascertain whether the document in any way bears the slightest resemblance to what I described above. Does it fail to document autosigning? If so, erase your response and start over. Does it fail to contain a commitment from key members of the Flow team to look the page over and publicly agree that it reflects what we have decided? If so, erase your response and start over.

If, on the other hand, the decision has been made to not create a page where we document what we have decided but nobody wants to admit that fact publicly, send me an email saying that and I will disappear from this conversation without further comment. --Guy Macon (talk) 07:53, 11 February 2014 (UTC)

It hasn't; personally, I think this is a perfectly reasonable request. Sorry for taking so long to get back to you - the research project I'm on has occupied more time than I thought it would (work expands...you know the rest).

So, to clarify what I think is the initial problem; I understood your original request to be slightly more open-ended. It was after we'd had the big back-and-forths with you, Tryptofish and a few others discussing how Flow would work, where we were having to step back from a lot of the things that had been said before we had developers or a Product team. Some of these things were things where promises had been made to the community that they liked, some were things they didn't like (for good reason) - there were a lot of statements we had to strike and replace with "we don't know yet, we're largely experimenting".

What I thought you were asking for (I was evidently wrong) was a documentation of where we stood in all the broad areas - so, what we were going with for indentation, for example, where people could read more about it, and the status of this - should people interpret the current indentation level as a constant, or as something we're willing to change if turns out to be a bad idea? Evidently I misunderstood, and I agree that a page documenting 'things we have decided' would be worthwhile. Having said that, it's not within my powers to assign Quiddity to write it up (and it'd have to be Quiddity - my work is exclusively in the analytics domain these days) - I'm poking Maryana in the hope that she'll chip in with her thoughts on the idea and (hopefully) assign it as a task. Okeyes (WMF) (talk) 20:51, 11 February 2014 (UTC)

I am patiently waiting for Maryana to respond. Meanwhile, it might be worth pondering why its is that an idea from the Wikipedia side that everyone agrees is a good idea is encountering so much difficulty being accepted (or rejected, for that matter) on the WMF side. Remember, this idea solves a very real problem; see the "Background" section at the top of this section for details. --Guy Macon (talk) 01:41, 13 February 2014 (UTC)

...Chirp,... --Guy Macon (talk)

• I've been trying to parse this discussion and, frankly, having a very hard time. For most of the next fiscal year (through June 2015), Flow is a beta project. Every "decision" (from the frontend UI to the backend architecture) is just a provisional experiment. So if what you want is a page that documents the absolutely rock-solid decisions that have been made about Flow, that page will basically only contain one item for the next 6 months to a year: it's going to be a structured discussion system. When that changes, we'll document it. Maryana (WMF) (talk) 18:06, 14 February 2014 (UTC)
  • Yes, the above is overly flowery and hard to parse. However, please be aware that many people here are very knowledgable concerning software development, and no one (that I've seen) has asked for rock-solid documentation. What is wanted is a broad-brush overview (in one place please!), with a disclaimer at the top that everything is subject to change. For example, I am wondering about the current thinking regarding the ability to remove inappropriate posts (including the benign situation where a post is mistakenly made in the wrong place). If a troll posts "X is a pedo", who can remove it, and what will be visible after removal? What if the troll posts 100 times? An overview would give a brief description of the current thinking of the Flow team, perhaps with a guide concerning which points were possibly rock solid, and which were merely experimental. One advantage would be that an onlooker could see that points had been considered, even if they might disagree with the team's current approach—I posted something similar regarding removals at WT:Flow/Archive 3#Deletion and have no idea whether anyone has considered the problem. Yes, I've seen the trials being conducted here, but there is no indication whether what is visible is regarded by the Flow team as "about right", or whether it's on a to-do list as requiring a fix. Johnuniq (talk) 23:36, 14 February 2014 (UTC)
    • @Johnuniq: The question of how well "undo/rollback vs hide" works for vandalism, is definitely undecided (see the "Post moderation" row in the table of the FAQ). It's on my list of things to do a roundup/followup of. I'll aim to start a thread in the next couple of days, asking for ideas and suggesting some options. Quiddity (WMF) (talk) 00:36, 19 February 2014 (UTC)
  • Maryana, if you think that at this stage of the project that everything is just a provisional experiment, with all due respect, you are just plain wrong. Replacing ~~~~ with automatic signatures has been decided. It really has. Flow will not require me to remember to type ~~~~ at the end of my comment. It really won't. That's because it really has been decided, and despite the fact that nobody is asking for absolutely rock-solid decisions, the WMF has already made a rock-solid decision that Flow will not require me to remember to type ~~~~ at the end of my comments. So please, document that one decision, and we can expand it as we discover other things that have been decided. I have many years of experience managing software projects, and my advice on this is sound. Ask your own developers if you doubt me on this. --Guy Macon (talk) 00:05, 15 February 2014 (UTC)
    • @Guy Macon: I've added it to the FAQ table for now, with a "Confirmed". As Johnuniq notes, "(in one place please!)", what I'm trying to avoid is page-proliferation. Hence I asked those questions above about this table: whether it could be adapted, or moved, or something? (To put it another way: There's a fair amount of documentation already, and a lot more to come over the months. How should we structure it to best meet everyone's needs? Maybe we need a new thread to throw around some {{flow navigation}} sandbox overhaul ideas? ) Quiddity (WMF) (talk) 00:36, 19 February 2014 (UTC)

Thanks! That is a great start, and we can build from there, adding things as we figure out what we have decided to do and not to do. I have managed several projects that used Agile or Extreme Programming, and found a list of what has been decided to be quite helpful.

As for location, any location will do, but it probably should be moved out of where it is, because the FAQ contains material that, while extremely valuable, isn't exactly something that we have decided. Perhaps we should create a new page just for this purpose and transclude it into the FAQ?

Once we decide where we want this to reside, the next step is to make sure that everyone on the WMF side agrees that we have, indeed, decided to autosign posts, etc. In a normal business environment, this is best accomplished by having whoever signs the paychecks ask everyone to sign off on the list. This can be as informal as "if we don't hear any objections from you in the next 30 days we will consider you to have agreed with it" or as formal as an official sign-off sheet.

On the Wikipedia side we need to figure out how to get a groups of volunteers with a constant flow of people joining and leaving to "decide" something. I am going to do some brainstorming on that in another section. --Guy Macon (talk) 01:27, 19 February 2014 (UTC)

(...Sound of Crickets...) If it takes over two days to get a response to a simple question like "where should we put the list of things we have decided?", I fear that we are all going to die of old age before we are able to come to any sort of agreement on anything remotely controversial. --Guy Macon (talk) 05:21, 21 February 2014 (UTC)

@Guy Macon: My bad. I'm multitasking like an octopus, but still too much to do. Also, Okeyes has moved into the Analytics team (paperwork yet to complete/update), so Maryana and I are the main people reading the profusion of Flow talkpages and email and etc (though other people on the team do read the various pages at random times, and reply to specific technical questions, for which I'm very grateful).

On topic: We can split the table off into its own page. I'd suggest to WP:Flow/Feature status or similar? (Plus redirect the talkpage to here, to avoid further fragmentation.) Verifying the team's agreement on feature-status (experimental vs confirmed) would be up to Maryana. Thankfully, she's a regular Wikipedian, and has the necessary multiperspectivity for collating the information from editors/developers, and incorporating both short and longterm views.

I'm also still wrestling with the many-questions of cross-wiki documentation. I'm currently copying everything by hand between here and mediawiki.org, but this isn't practical nor complete, and things inevitably diverge if only briefly. Flow will hopefully end up partially solving the "not my wiki" problem for the discussion-aspect, but where and how should the documentation pages be replicated, and/or centralized? There are good arguments to be made for centralizing at any of Mediawiki/Meta/Enwiki, but the fallback-default will probably be trying to keep those 3 duplicated/synched (with Meta acting as the translation hub for other languages/projects). Advice on that, welcome. Quiddity (WMF) (talk) 19:32, 21 February 2014 (UTC)

Editing other people's comments

You've got a list of use cases here. It is unclear what permission is needed to do what. What I would like to know is if I, as a regular user, and working with other people's comments, will be able to:

• Completely remove comments
• Edit comments
• Revert changes to comments
• Move comments

--NeilN ^{talk to me} 04:00, 19 February 2014 (UTC)

I don't have an answer despite the last four times we discussed this:

Wikipedia talk:Flow/Archive 1#Editing comments by other people

Wikipedia talk:Flow/Archive 3#Request for Comment on editing other user's comments with Flow

Wikipedia talk:Flow/Archive 4#Fix edit-conflicts to allow editing other user comments

Wikipedia talk:Flow/Archive 5#Editing the comments of others

This relates to my suggestion that we have a place where we write down what we have decided rather than revisiting the same issue over and over. --Guy Macon (talk) 06:18, 19 February 2014 (UTC)

As far as I can remember, we agreed to experiment with this. The final two sentences in the conclusion also seem to state that. --HHill (talk) 08:11, 19 February 2014 (UTC)

Thanks. "[T]he first release version of Flow will not have comment editing." Hopefully WMF doesn't think putting Flow on three or four obscure talk pages is a good way to figure out what functionality is actually needed here. --NeilN ^{talk to me} 15:07, 19 February 2014 (UTC)

I don't think anyone at the WMF thinks that, but that doesn't make it not worth doing. What alternative would you suggest? No live testing at all? Starting with some high-volume, high-visibility pages? --Guy Macon (talk) 16:33, 19 February 2014 (UTC)

@Guy Macon, I just read your version of Tom DeMarco's hidden rules. Some of them seemed very relevant here! - Pointillist (talk) 17:03, 19 February 2014 (UTC)

Thanks! I have a fair amount of satisfied customers because I have a track record of taking over engineering projects (hardware and software) that are in deep trouble, fixing the problems, and bringing the project in on time and under budget. I require the manager/executive that hires me to read that page, and if later they cannot answer a couple of simple questions showing that they have read it, I decline the contract. I didn't get a good reputation by signing up to be a Cassandra. Ideally, the WMF would email me, ask for references, talk to some of the people I have consulted for to confirm that I can do what I say I can do, accept my offer of free help, and we could put together a plan. Until that happens, I will continue making suggestions as I have been doing. The good news is that some of the suggestions have been at least partially implemented, and as they see that my previous suggestions have been helpful, they should become more open to further suggestions. --Guy Macon (talk) 01:40, 20 February 2014 (UTC)

Guy Macon, that's not what I was suggesting at all - I'm not sure how you got that from what I wrote. All I'm saying is that the current deployment will not unearth the issues that come up on more contentious talk pages. Great success on the current talk pages should not be seen as an indication that Flow is ready for a wide rollout. --NeilN ^{talk to me} 14:24, 21 February 2014 (UTC)

My apologies for misunderstanding you. My fault entirely. You do bring up an excellent question though; how do we know that Flow is ready for full-scale deployment? Here is how I would do it if I were managing the project: I would come up with a plan, published in a conspicuous place, setting forth a series of tests. It might look something like this; a test page on the WMF servers, then a couple of low-volume talk pages, than a high-volume talk page, then full deployment on the WMF Wiki, then full deployment on one of the smaller Wikipedias, and so on. At each stage I would create a set of specific, testable acceptance criteria, with lots of input from those who have criticized previous WMF projects.

Alas, what I think will happen instead is that certain mistakes from the past will be repeated once again, with results reminiscent of the Battle of the Little Bighorn. --Guy Macon (talk) 19:26, 21 February 2014 (UTC)

@NeilN: Re: "Hopefully WMF doesn't think putting Flow on three or four obscure talk pages is a good way to figure out what functionality is actually needed here." - That's exactly the problem! Hence they're using the process of asking for volunteer-locations, starting with WikiProjects. The project Milhist did volunteer to be in on the initial test, but the flow-team decided that Flow needed a few additional features before it was ready to be enabled on the most active WikiProject on Enwiki! The work on overhauling the watchlist/RC/contribs elements is being done in this current sprint, and the next sprint. Once that's in place, I'll personally feel a lot more comfortable asking lots of people to "take another look and test-drive", and to again search for additional small and medium-size Wikiprojects to volunteer as testbeds, to help us guide this endeavour. But, it's always going to be a balancing act.

@Guy Macon: I will be reading that link above, and more, over the weekend. (I vaguely recall a handful of humorous adages/quips about documentation always being the problem, but don't have time to google for exactness. So, <insert hilarious/painful/insightful reference here>). Thanks again. :) Quiddity (WMF) (talk) 20:16, 21 February 2014 (UTC)

Guy Macon, yes I agree with your process. I've rolled out custom software to wildly disparate offices across a country (all ostensibly performing the same function) before and I always know the needs of the small offices involved in testing are not remotely the same as the large HQ offices. And the large offices can scream... --NeilN ^{talk to me} 20:27, 21 February 2014 (UTC)

Still, trying something first in a small way is not a bad idea, because you can catch problems that would effect everyone, both big and small, with minimum disruption. The main point is to not then consider the testing finished, and to organize more testing of busier/more complex areas next. —Anne Delong (talk) 14:14, 28 February 2014 (UTC)

Categories and linktables

Why doesnt the project page have any categories? Isnt that a problem when following changes with tools like Special:RecentChangesLinked or external tools like WikiProject watchlist, see... What will happend to categories for other talk pages? Christian75 (talk) 22:36, 27 February 2014 (UTC)

There are 2 bugs tracking that, bugzilla:58197 and bugzilla:57512. The former issue is also briefly discussed at Require users' attention on a specific thread. TL;DR: They're working on it, and it's definitely being thought about. HTH, let me know if it doesn't. :) Quiddity (WMF) (talk) 21:54, 28 February 2014 (UTC)

Proposal: fewer, more focused documentation pages

There are a lot of pages documenting flow, both on Wikipedia and Wikimedia. I propose that we start pruning those pages that are redundant, obsolete, etc. along with some selected merging. I am going to start by proposing that we mark the following as being historical/inactive:

Wikipedia:Flow/Newsletter

Wikipedia talk:Flow/Newsletter

This will prevent people signing up fr a newsletter that never comes.

BTW, here is what I hope doesn't happen; I hope that we don't see someone springing to action and writing newsletters just because of the above. We really do have too many places with information on Flow and we really should have more focused documentation --Guy Macon (talk) 17:18, 27 February 2014 (UTC)

Good point. It's getting very hard to find one's way around this labyrinth of pages. -- Ypnypn (talk) 18:10, 27 February 2014 (UTC)

Re: Newsletter - Partially my fault for over-hesitating, and not wishing to bother people who only want "Big Picture News". There's the weekly update which I could try to summarize and excerpt - mw:MediaWiki 1.23/wmf15#Flow - but I suspect most of the people who subscribed ot the newsletter don't want that level or regularity of detail. Perhaps we could split the "Newsletter - wanted contents" discussion into a separate thread? Quiddity (WMF) (talk) 22:25, 28 February 2014 (UTC)

Re: Documentation. There've been a lot of pages from the start! I recently re-arranged the main index, which I believe contains everything, at mw:Flow/Pages (the pages are grouped now, instead of alphabetical). Updating the navbox here and there, was going to be my next step. (But continually delayed by more urgent things, like emails, meetings, and replies here and everywhere.)

Given that Flow isn't cross-wiki yet, and won't be in the near-future, we're (I'm ;_;) stuck with having feedback scattered across 3+ wikis (although thankfully nobody except staff really use the ee-flow labs-wiki anymore). So, I'm also stuck with keeping documentation manually updated/mirrored. So yes, I'd love it if we had more condensed pages, and if everyone would help discuss and work on the various docs. Also, whatever we decide, has to keep eventual-translation in mind.

We want more info, too. Eg. mw:VisualEditor/Roadmap recently had a massize overhaul, which is the result of many weeks work. I'm trying to avoid "{sofixit} myself", which I'm used to as a wikipedian, but the hope is to hammer mw:Flow/Release planning into that kind of shape.

So, my thinking angle, and suggestion/question is, which of the existing pages (or their contents, moved to other places) would the different demographics want to see in the navbox? I suspect that starting with that, will make the rest of the work line up more clearly. Quiddity (WMF) (talk) 22:25, 28 February 2014 (UTC)

I have drafted a couple of replies to this but it is useless because we are from different planets. In brief, mw:Flow/Pages is not useful for an editor who would like to know what Flow is planned to do (apart from giving a warm glow). No one is asking for a newletter—please delete the clutter, not add to it. Johnuniq (talk) 02:36, 1 March 2014 (UTC)

I strongly disagree. I do consulting work where I am called in to fix engineering projects that are in trouble. This sort of documentation explosion is common; each individual author is trying to make the project better, but when put together there is no overall structure -- or rather several competing structures. To fix this sort of problem, the very first step is to create an index page with hyperlinks to all of the existing documentation, which is exactly what Quiddity has done here. I was actually thinking about doing something similar over the weekend. If I was managing this, my next steps would be:

1. Engage everyone involved in a search to make sure every existing document, no matter how obscure, is on the list.
2. Discuss and refine the sectioning/sorting of the index. This may include creating blank sections to be populated later. One section should be "obsolete/historical". Another should be "scheduled for merging"
3. Move items into the above two sections, labeling as appropriate with comments such as "to be merged into foo" or "superseded by bar". If needed, create stubs for merge targets.
4. Once you are happy with the organization of the index and all merges are complete, start renaming and moving the actual articles to match the index.

You can help with the next step. Did we miss any documents? --Guy Macon (talk) 07:04, 1 March 2014 (UTC)

Ummm, are you disagreeing with something I wrote? I did not say that such an index was not needed, merely that it was not useful for an editor wanting information about Flow—I'm thinking of practical things like how I correct a comment and how that will be apparent, or what happens if I paste "see [[Help:Table|here]]" (any link) in a comment? Johnuniq (talk) 08:21, 1 March 2014 (UTC)

You are right. I misread what you wrote. My reply was about something else -- something very much worth doing but having nothing to do with information about practical things. For that, I would like to see a tutorial and a cheatsheet. --Guy Macon (talk) 09:33, 1 March 2014 (UTC)

Yes, a tutorial/cheatsheet is needed (aimed half at existing-editors and half at newcomers?). Someone else suggested a "legend" for any icons we use, and it'd be nice to have that in a single location, too (rather than embedded in every Flow page). However, given that Flow is undergoing continuous change in these early months, any User-Guide should probably aim for simplicity, rather than comprehensiveness (So, more like WP:Cheatsheet, and not like mw:Help:VisualEditor/User guide yet). Anyway, let's take that to another thread, once this cleanup-endeavour is further along. Quiddity (WMF) (talk) 22:32, 3 March 2014 (UTC)

Indeed, sorry I wasn't clear, Johnuniq; I meant that the mw:Flow/Pages index was merely a list of everything, which we (documentation overhaulers) could use to get a big-picture view of what exists, and from that decide which pages to merge/update, and which to include in the navbox to meets our (various editor-facing) needs - I wouldn't direct newcomers there!

Re: "Is it complete?" I believe it is a complete list of all relevant pages on the 3 wikis covered. It was constructed partially through a subpage-search, and partially through adding items over the months whenever new pages were mentioned; I've just now verified/updated through a new sub-page search. It doesn't list a few editor-created things, such as sandbox experiments over the months, or the new User:Hhhippo/Flow, but those are generally items-for-a-discussion rather than documentation.

I'll nudge the Flow Team to help check for anything missing/misplaced, and to help brainstorm potentially useful (to us or them) sectioning/sorting divisions, and to annotate the links with suggestions.

There is already an "Historical" section, but I'll have to check with the Team whether I've mis-categorized anything (they might want to update/resuscitate some of those pages). Quiddity (WMF) (talk) 22:32, 3 March 2014 (UTC)

Subproposal for dealing with cross-wiki duplication

I propose that, as step 4 in the above section, we move all documentation to MediaWiki. The only pages we should leave on the English Wikipedia are Flow and Talk:Flow, and Flow should be one paragraph description and a link to the main Flow page on MediaWiki. If possible, this should also happen on the German Wikipedia, etc., but we here on the English Wikipedia have no control over that other than suggesting it. --Guy Macon (talk) 07:19, 1 March 2014 (UTC)

ssl_error_rx_record_too_long

https://ee-flow.wmflabs.org/wiki/Talk:Sandbox does not work... 78.35.196.38 (talk) 13:54, 3 March 2014 (UTC)

That labs server isn't set up for SSL. Please use http, rather than https. Thanks. Quiddity (WMF) (talk) 22:33, 3 March 2014 (UTC)

Design

I don't know if this is the right place to mention the following, if not, please direct me to the appropriate place(s).

The design seems just awful to me. Why don't you use the default fonts? Why does it look so washed on my screen? (I think that can all be fixed by CSS but still ...) Some text is overlaying some other text. Please, see my screenshot. — Giftpflanze 21:10, 3 March 2014 (UTC)

More specifically: Why does Flow use a different font from the rest of Wikipedia? -- Ypnypn (talk) 22:56, 3 March 2014 (UTC)

@Giftpflanze: Thanks for the screenshot, I filed a bug for that overlay/overlap (bugzilla:60849).

@Ypnypn: and Giftpflanze: Re: Fonts:

The font choices are meant to be in line with the mw:Typography refresh Beta Feature (which will be merged into the default Vector at some point in the next few weeks). I'm not sure if that font-stack is still being discussed, but the font-stack used here will eventually need to align with whatever the outcome there is. (The one that Flow is currently using, is a bit out-of-sync).

The same goes for the font-colors. (They're currently proposing a font color of #252525 for body text (a very dark grey), in the Typography refresh. Essentially because it's less headache-inducing, and I've recently been told that black-on-white can cause problems for dyslexic readers.[citation requested]) Flow currently has a #333333 color (a dark grey), but will presumably end up using whatever the Typography refresh goes with.

For other Flow design questions, it might be good to ask at Wikipedia talk:Flow/Design FAQ, but either location is fine.

TL;DR: Discuss the upcoming changes at mw:Typography refresh, because those changes will be coming to articles and eventually to Flow. HTH. Quiddity (WMF) (talk) 23:22, 3 March 2014 (UTC)

Okay, thanks for the info -- Ypnypn (talk) 01:16, 4 March 2014 (UTC)

A reference on black on white and dyslexia would be this - "we found no guidelines about gray scales and readability for dyslexics apart from the suggestion of using a light gray as background [39]. Most of our participants said that grey actually did not help them. For the font (using pure white in the background) 16 users (72.73%) preferred a pure black font instead of the three options of gray scale for the font." or this - "What visual dyslexic readers need to do is to configure the computer environment so that they can see comfortably what is on the screen". Light grey on the background seems to work better than dark gray for text; a guideline recommends a #FFFFE5 page color [2]. It looks like this is a more complex beast that merely using a washed out grey font to automatically help dyslexic readers. If you want to support them, the most important thing seems to be allowing end-user customization. Diego (talk) 07:25, 4 March 2014 (UTC)

Two-to-four-weeks test

What was the actual purpose of having a two-to-four weeks test on Wikipedia talk:WikiProject Hampshire and Wikipedia talk:WikiProject Breakfast, considering that actual Flow tests were not allowed to happen there anyway?

Looking at the history of Project Hampshire, you got normally one to two messages per month. The only thing the test could have provided was an anecdote about whether the page was used more often for Hampshire related questions than before, and it isn't. After the initial flurry of Flow comments (already the most discussed topic on the talk page in years), the project is back to where it was, no comments have been made in 14 days. Value of the test? Well, it was established that the watchlist bombing of Flow comments caused at least one editor to unwatch the page, but that's about it.

Looking at the history for Project Breakfast, we get the exact same issues and results. Again, Flow hasn't changed anything, the test hasn't revealed anything.

Whose decision wsa it to use these two projects, which get about two comments per month, as guine pigs for a one month trial? What was that supposed to achieve? I hope no one is going to claim these two as an overwhelming success, allowing the rollout to further projects... You have gotten all the testing you could want for a first round from Wikipedia talk:Flow/Developer test page, and even there traffic is considerably slowing down. The WMF have a truckload of issues, bugs, missing features, ... to handle before this thing is ready for a real rollout, to Wikiproject space or any other namespace.

Please disable Flow from all pages on enwiki except Wikipedia talk:Flow/Developer test page, and use this as the sole testing ground until Flow has a reasonable level of stability, usefulness, completeness, and support. Don't repeat the mistakes you made with the premature rollout of VE, by e.g. enabling this for user talk space, even on an opt-in base. It is not ready. Fram (talk) 08:27, 27 February 2014 (UTC)

+1 on every point. — Scott • talk 15:43, 27 February 2014 (UTC)

Agreed. Dougweller (talk) 19:06, 27 February 2014 (UTC)

To be utterly clear: No wide rollouts would even be considered, based on this obviously tiny sample. The next step, weeks from now - when the last set of RC/Watchlist/Contribs/History updates are in place, and the additional indent level (\o/ currently at mediawikiwiki, and arriving here next Thursday) and a variety of other feature-updates are deployed - will be to ask for just a few more Wikiprojects to volunteer. Slow and steady, with emphasis on slow, for months to come.

Background: There were 4 Enwiki projects who volunteered to be amongst the initial locations that trialled the early iterations: Breakfast, Hampshire, Video Games, and Military History. The Flow team (such an awkward and too-general phrase, but slightly handier than naming all the individuals each time :/ ) itself was hesitant about Milhist, and so postponed taking up their generous offer. The other 3 projects were asked to confirm if they were ready, and Video Games project members were quite uncertain. Hence only those 2 projects were the early adopters.

The team knows it is not ready for wide-scale deployment. They just want a few small and diverse pages, that are in actual use for real work, to help trial it in-situ, and give feedback based on that. Sandboxes get forgotten/ignored way too easily, and aren't good representations of real-situations; that was one of the problems VE ran into - only having it on a test wiki/namespace for many months. Real-world testing is like that quip about democracy. ;) See also Anne Delong's comment just above, which puts it perhaps better than I have.

HTH. Quiddity (WMF) (talk) 21:54, 28 February 2014 (UTC)

Are you all aware of the discussion about volunteering at Wikipedia talk:Noticeboard for India-related topics. Dougweller (talk) 12:02, 4 March 2014 (UTC)

Watchlist items

An update on "which items appear in our watchlist". The current solution, now live on all wikis, and as suggested by a few editors, is to show slightly more than "only the newest edit". I.e. Watchlists with default settings will currently list the most recent of any:

• new topics started
• content change in a topic (the last post, or last edit to a post or topic-title)
• moderation actions
• edits to the header

Further tweaks and changes will probably be needed, as the rollout grows and busier locations are added - (such as possibly merging together "newtopic/firstpost-on-that-topic" pairs?) - but this current setup demonstrates some of the interesting and informative possibilities.

There are some ongoing efforts to cleanup and improve the way our Watchlists work (eg bugzilla:33888 and bugzilla:51942 and dozens of others, plus the m:Watchlist wishlist), and hopefully these ideas, and anything suggested in reply, will help towards that. Feedback welcome. Quiddity (WMF) (talk) 01:45, 8 March 2014 (UTC)

RFC on Flow approval

RfC template/process suspended, with permission of the original author below. Quiddity (WMF) (talk) 06:06, 10 March 2014 (UTC)

Should there be a large-scale deployment of Flow?

I know this is very late, but I don't think the English Wikipedia has ever had a request for comment to approve Flow. The Wikimedia Foundation shouldn't be allowed to unilaterally determine consensus for the community. We should be able to decide our own consensus. Admins and Foundation employees, please don't snowball close or revert this edit without a lot of discussion. I think that this RFC is beneficial in that it will give a variety of opinions on how this should proceed, including perhaps the complete removal of Flow from Wikipedia. Anyone is free to add opinions and split others off as long as they don't disrupt votes already made. --Thebirdlover (talk) 16:38, 9 March 2014 (UTC)

What is the RFC about? What do you mean by "approving" Flow? Are you talking about test pages, a few specific WikiProjects, or large-scale deployment? -- Ypnypn (talk) 16:54, 9 March 2014 (UTC)

I'm talking about large-scale deployment. It's better that we decide on it now instead of later. The parts that are currently in progress of being implemented can be discussed though. --Thebirdlover (talk) 17:00, 9 March 2014 (UTC)

@Thebirdlover: This isn't very late - this is very early! This is a long-term project (1-2 years), that needs our input throughout, in order to help it develop into the system that we all (from powerusers to devs to newcomers) want. There have been various announcements encouraging participation over the months (Villagepumps and Signpost and etc), and as the feature-set grows (leading to less shock for those who are discovering it for the first time...), the announcements will increase. (It's been relatively quiet for a few months now, as the first set of MVP bugs and features are ironed out. I'll be ramping up the announcements again in a few weeks.)

I've also replied to your questions at mw:User talk:Jorm (WMF), and I'd request that you read through that, and the other docs, and then consider closing this RfC once the additional perspective is clearer. Slow and steady - like articles. It's not being rolled out widely, for a long time yet. HTH. Quiddity (WMF) (talk) 23:06, 9 March 2014 (UTC)

While I am very, very, conflicted about this, I'll suspend the RFC for now. The majority of the answers were at least partially satisfactory, albeit not exactly what I was hoping for. If I find little or no improvement within two months, I plan to reopen this. Currently, the likelihood is that I will, because I think that the improvements won't help out my main philosophical reasons for not liking it anyway. Wikipedia doesn't need this type of edit system. We're a self-sufficent website. Having a talk page system like the current one improved my performance in a way Flow can't. I was able to learn such things as common markup, making headers, and signing my name properly. As I said before, this travesty will just be our downfall. Simplicity isn't always the most subtle way to go by things. If anyone wants to keep this open, they can gladly say so and I won't dispute it. About 49% of me wants to debate this out now anyway. --Thebirdlover (talk) 23:42, 9 March 2014 (UTC)

Thank you. I've refactored this thread by removing the RfC template, and changing the subheaders into simple lists, for minimal disruption in the existing comments, and to take it out of the RfC noticeboards workflow.

Regarding "simplicity" - Flow is still in early stages yet, and there are a lot of features coming as rapidly as the devs can code them out, and many more after that we're continually suggesting and discussing. [that's the inclusive "we": the entire broadest-definition-community including staff]. It is not going to end up as a simplification - it's aiming at being an upgrade, with powerful new features (details in the voluminous docs, which we're updating/compacting over the next few weeks). So, look at the current iteration as a stub/start quality article, and help build it with feedback/suggestions/requests/bugreports/anything you're comfortable with. tl;dr It's going to be a lot different over the many coming months, growing and morphing continuously, based on the ongoing and constant feedback. :) Quiddity (WMF) (talk) 06:06, 10 March 2014 (UTC)

Support

Oppose

1. Oppose: Flow is a heavily flawed system. It is my opinion that it is poorly designed, strengthens the administrators at the expense of the Wikipedian, disrupts the Wikipedia pages, and will ironically ward off the people that it seeks to get. --Thebirdlover (talk) 16:38, 9 March 2014 (UTC)
2. Won't matter anyway, but I'd like to see more features added to bring it in line not just with the rest of MediaWiki but also en-wiki's specific policies and customs, ie. signatures, auto-archiving, etc. before it is released in full. KonveyorBelt 23:17, 9 March 2014 (UTC)

   See above comments. It's not getting widely deployed anytime soon. I've requested that the original author close this RfC, as it seems to be based on insufficient data. HTH. Quiddity (WMF) (talk) 23:23, 9 March 2014 (UTC)

Neutral

Other

1. I may make an Oppose comment later, but this is premature and pointless. The Foundation will implement Flow eventually, regardless of whether it actually works. And the Foundation (or, at least, the representatives posting here) agree it is not yet ready for "mass rollout". (They also agree that VE is not yet ready, but they rolled it out, anyway.) — Arthur Rubin (talk) 21:45, 9 March 2014 (UTC)

Hopeful endnote: See above discussion. It's not getting widely deployed anytime soon. Feedback requested at the #Watchlist items thread above though! Quiddity (WMF) (talk) 06:08, 10 March 2014 (UTC)

MediaWiki:Bad image list

I'll not call to protect or shutdown Flow for a third time now, but it has some serious new chances for vandals. Apparently, the MediaWiki:Bad image list protection / restriction doesn't work on Flow pages... See [3] EngFram (talk) 13:22, 21 February 2014 (UTC)

Submitted as bugzilla:61772. @Fram: per WP:BEANS and etc, I'd love it if you'd send us these sorts of concerns via email or IRC or usertalkpage message instead. Any of those would be faster and more efficient, and smoother by avoiding potential-drama. (There's none from this one, yet, but...) Please and thank you! Quiddity (WMF) (talk) 21:31, 21 February 2014 (UTC)

No. There are more than enough problems and issues with Flow to keep you (WMF) busy for months before it is really deployment-ready. This was obvious before you deployed it to a few pages here, and has become even more obvious since. If you want to test it here, then you'll have to live with the consequences. You have provided a new environment here where e.g. almost none of the normal admin tools were available (now we at least have protection, but that's it), and almost none of the monitoring tools either. Like I said at VisualEditor as well (and to no avail either), the WMF needs to change its testing approach drastically, and one thing they need to integrate is "testing like a vandal would", not just test whether the things work as expected (well, even that would be a vast improvement in VisualEditor), but also whether they can be broken or abused by vandals. What I did wasn't complicated or farfetched and didn't require any special tools or rights... Fram (talk) 07:52, 24 February 2014 (UTC)

But I'll give you a week to work out the worse implications of this error and let you correct it asap. Because it has non-Flow implications as well, but these I'll not post yet. I guess the smart people at the WMF will either already know about the further issues, or have no trouble figuring it out. Fram (talk) 08:03, 24 February 2014 (UTC)

http://dilbert.com/fast/2007-11-26/ --Guy Macon (talk) 08:51, 24 February 2014 (UTC)

:-D Fram (talk) 09:16, 24 February 2014 (UTC)

Quiddity, above you said "I'd love it if you'd send us these sorts of concerns via email or IRC or usertalkpage message instead. Any of those would be faster and more efficient,[...]" With the possible exception of IRC, which I loathe for other reasons, how would using email or usertalkpage message have been faster or more efficient? I have no idea who is online or not, so those two channels could well end up being slower and less efficient. I was aksed, in a previous bug posting, to use email, and for my next flow (or V? can't remember) problem, I emailed one of the WMF regulars for that product. My email was only seen half a day later (which is normal obviously). Apart from IRC, using this or similar pages is the fastest and most efficient method for such bugs and problems (I'm not talking about oversight and the like). I don't think you or anyone at the WMF would like me to mass-email all of them or post a message to all of their talk pages in the hope of catching anyone who is active, do you?

Further, considerig that we are now five days later, and neither this Flow problem nor the other related one have been solved, I suppose that "faster and more efficient" aren't really useful arguments here. Then again, considering that some major VE bugs stay open for half a year and longer, the WMF definition of "fast and efficient" may be different from the normal one. Fram (talk) 08:13, 27 February 2014 (UTC)

@Fram: My apologies that my initial message here wasn't clearly written or well phrased. (As someone smart regularly says, "Words are hard". ;) I was particularly meaning in regards to vandalism-related bugs - it's helpful for everyone (both editors and devs (both staff and volunteer)) to have a little extra breathing room regarding the haste with which specific bugs need to be worked on. (This goes for all software, not just Flow). I (personally) can totally understand the perspective of "I'll broadcast this issue widely, so that it has to be prioritized", particularly coming from anyone who has been frustrated with VE's many problems over the months, but that tactic has the potential to cause many more problems and further discontent for everyone (wp:beans etc); the alternative, is using the full-spectrum of communication options, depending on the context. Eg. on bugzilla, if someone submits a type of security bug, the ticket is hidden from public view initially, until it's had time to be worked on. Does that make sense? And yup, imperfections and delays - sadly unavoidable throughout life. Sometimes delays are great and to be encouraged! Sometimes not.

(Tangent: I wrote numerous emails to various staff back in June 2013. I'd like to think I was partially responsible for a few of the VE-rollout delays on Enwiki, although clearly not enough. I suspect those exhaustively re-written-before-sending emails are part of the reason I got this CL contract. My job (in one of the many ways I describe it to myself) is to translate things between all possible perspectives: I pass along, and sometimes rephrase, other people's ideas, so that they're perhaps clearer to the intended audience, and also sent to the right people. I try to do it delicately, showing respect to everyone involved, no matter how they phrase something initially. E.g. If something is going to be processed more efficiently with "a quiet word, sent privately, perhaps so as to 'save face'", then I'll go that route - If I want to offer constructive criticism to a frustrated new editor, who has a usertalkpage full of templates and stern notes, then I'll send them a private email offering a way for them to privately vent, or way for them to take the criticism to heart without having to publicly acknowledge it. Humans are prideful! I don't always get it right, or word it well, but I try my damndest to make things smoother and easier for everyone. (I could write about this for a while longer, but I'll stop in case I'm boring or annoying you, or anyone else.)).

So: the bug itself is being worked on along with the other high-priority bugs, and I've poked the devs to update the bugzilla ticket regarding whether it's a Flow or Parsoid issue. The other related bug that you mention: I (as an editor) would be immensely appreciative if you'll email me about it, rather than hoping the flow team do (or don't..) figure it out based on clues. :) Peace, and best wishes, Quiddity (WMF) (talk) 21:06, 28 February 2014 (UTC)

Well, let's just say that it is not a Flow issue but a Parsoid issue. That should be sufficient to work out the issue, I think. Fram (talk) 07:55, 10 March 2014 (UTC)

Topic filters / dynamic TOC

I've written up some ideas I've been hatching regarding archiving, TOCs and infinite scrolling here. I hope they don't overlap too much with what's been said before in discussions I didn't find or read yet. Probably not all details are feasible and desirable, but I hope the general ideas are made clear and worth considering. Let me know what you think! — HHHIPPO 22:44, 20 February 2014 (UTC)

These seem to be well-thought-out suggestions, and I've noted some first impressions on the talk page. I'd advise the WMF to prototype ideas like these (using read-only test data) as a mini-MVP project in parallel with the main Flow development cycle. It wouldn't take much effort to put something together and reassure us that Flow is going in the right direction. - Pointillist (talk) 00:53, 21 February 2014 (UTC)

Thanks! I have updated the concept a bit inspired by your comments and by WT:Flow/Design FAQ#More thoughts on infinite scrolling. It would be nice to hear some other opinions at some point. (pinging Quiddity (WMF), Maryana (WMF)) — HHHIPPO 14:12, 1 March 2014 (UTC)

As with the other dense thread of insights, I keep re-reading your suggestion page, but getting sent off on tangentially-inspired tasks before I can form a coherent reply. I'm glad to see that Maryana responded there though, and please be assured that I have read and appreciated it (many times now!). More later. :) Quiddity (WMF) (talk) 23:45, 13 March 2014 (UTC)

How do I see if a file is used on a Flow page?

For example, File:Date tangling.png is used on Wikipedia talk:WikiProject Breakfast. However, it does not show up in Special:WhatLinksHere/File:Date tangling.png or in the file usage section at the bottom of the file information page. How do I find out whether an image is used on a Flow page or not? Incidentally, a user nominated this for deletion as "unused", because the Flow usage didn't show up. --Stefan2 (talk) 00:33, 14 March 2014 (UTC)

@Stefan2: They've been working on that for a few weeks here at trello, and I gather the patch is approaching completion, for at least the initial fixes. Thanks for the note, and sorry for the extra task. Quiddity (WMF) (talk) 00:49, 14 March 2014 (UTC)

The strange case of the many URLs

I must be missing something, these all come from different lines on my watchlist, are all different (postid!), but as far as I can tell give all the exact same result. Somehow, this doesn't seem to be efficient (or what was intended). Fram (talk) 11:05, 13 March 2014 (UTC)

• [postId=rqtgh42tfqxw68r8]
• [postId=rqtgds3g9h2tzg24]
• [postId=rqtga0i1ev1sm4q0]
• [postId=rqtga0hv6db79duw]

Addendum; right, copying these here doesn't work. WMF, please get rid of these square brackets! Fram (talk) 11:06, 13 March 2014 (UTC)

I think (and as far as I can tell after testing/exploring) that the square bracket problem should finally be fixed as of a few hours ago, when the latest mediawiki branch + extensions were deployed to Enwiki. I can't find any links using that format, in my watchlist, or the action menu. Let me know if you find any - they might only be visible with a certain preference enabled? (I know they're not in enhancedRC - that's a separate bug...) Or they might be properly gone/fixed.

The updated URL structure removes the brackets, and fixes the "post-highlight" and "scroll-to-post" components.

Today's update does mean we get the latest bug (bugzilla:62162), whereby (diff) links lead to lovely "Fatal exception of type Flow\Exception\InvalidActionException" messages, but that has patches awaiting review, and the whole line it appears on is being re-arranged for consistency and logic.

As I wrote elsewhere today, all these elements (each link and item in watchlists/RC/contribs/logs) are being worked on, with much cursing (and documenting of the pain points) at mediawiki's many many systems that are almost-identical-but-not-quite. I guess this is part of what people refer to as technical debt - mediawiki has accumulated a lot over the last 14 years! Quiddity (WMF) (talk) 00:37, 14 March 2014 (UTC)

The square brackets links come from "my contributions", e.g. [postId=rqx8b3h6c47r3ax8] is my edit from this minute. And [postId=rqwgh7r2lmz8lpus] is one you made earlier (so it's not just in "my" contributions). Fram (talk) 08:16, 14 March 2014 (UTC)

Ah, got it. Thanks. I'll confirm/nag with the devs that these are being thoroughly removed. Quiddity (WMF) (talk) 21:13, 14 March 2014 (UTC)

Notification problem and history not working for me

I got a notification saying "Sj replied to your post in "Lorem Ipsum" on "Wikipedia talk Wiki Project Breakfast"." I went there and searched for "Lorem Ipsum", couldn't find it. After several searches I finally found it but it shouldn't be an effort to find it. Also, despite SJ commenting today on the history views, when I click on history in the dropdown menu I get

"Internal error -Wikipedia does not recognize the action specified by the URL.

Return to Main Page.

[dcb3c4dc] 2014-03-27 06:41:04: Fatal exception of type Flow\Exception\InvalidActionException

Dougweller (talk) 07:47, 27 March 2014 (UTC)

@Dougweller: Hi. I assume this post was in the deleted topic which I cannot see. I'll file a bug or 2 for this. Thanks. :) [Addendum: Is the bug with the history dropdown, for the same deleted Topic/Post?]

I'm also not sure why Sj was editing Diego's post so much. Sj, please (please!) continue your testing, and giving feedback, but ideally at Wikipedia talk:Flow/Developer test page and here, instead of within the Wikiproject. Thanks! <3 Quiddity (WMF) (talk) 00:16, 29 March 2014 (UTC)

Okay :-) I hope Diego and all will excuse my inline testing; I'll save that for test pages. – SJ + 08:19, 30 March 2014 (UTC)

Admin-only problems

When I go to the page history, it states at the top: "View or restore 18 deleted edits?". The link takes me to this page, where I don't see 18 deleted edits, but 18 admin actions (like protection), which I can "restore" since I deleted those on 8 February. However, the real deletions, like the topic deletion by Dougweller on the 17th, can not be undone here.

All this is rather confusing and seems to need loads of work. Is any progress being made on Flow, by the way, or are our two test projects left with an abandoned version and no near-future perspective of improvements? If you know that you are back to the drawingboards (which is good!) and that you will have a total overhaul in 3 or 6 months time, then it makes no sense to keep the two test pages alive in this form... Fram (talk) 15:29, 31 March 2014 (UTC)

Don't demolish the house while it's still being built. Ypnypn (talk) 16:01, 31 March 2014 (UTC)

That's why I don't propose removing the "Developer test page" here at enwiki, which is the only page that is really used for testing anyway. Fram (talk) 07:10, 1 April 2014 (UTC)

@Fram: Regarding moderation, they're doing some work on those features currently to integrate better with the various cornucopia of hooks, which is probably why that new link has appeared. I'll ask them about it, and file a bug if need be. Thanks.

They're also nearing completion on the first iteration of RC/watchlist/contribs changes, which involved a lot more fixing and/or adapting to technical debt than was expected. That's the first step to moving towards a revdel model. Those changes should be live on mediawikiwiki on Thursday, and Enwiki the week after. After this is done, future iterations of those features should be a lot (relatively) smoother.

In general: Flow is getting constant updates, based on feedback, plans, and bugs. There is a daily stream of progress, which can be seen most clearly here, or in the weekly changelogs (e.g.). It's always going to be too slow or too fast for some people, but slower is (imo) generally better. - As I continuously tell any staff member who asks me anything, "Slow and steady wins the race!" (Although that's not a very unique motto, so recently I've been going with "Eventualism über alles!" instead :) Hope that helps. Quiddity (WMF) (talk) 21:24, 31 March 2014 (UTC)

Apart from the history of the talk page header, I haven't seen any actual progress here in the last weeks. The issues that were mentioned extensively here last month seem all to remain in place. I believe you that there is progress, but there were so many issues to solve that I don't see the value of continuing the test at those two projects, with no or nearly no activity anyway. The added value of these seems purely symbolical, while the problems they create (e.g. people no longer watching the page) is real. No one is testing Flow or discussing it any longer (at enwiki) anyway. Put it on hold (here), and revive interest and discussion when a long list of substantial improvements can be presented, instead of havign a tool where the list of major problems grows faster than the list of solved issues of any importance. Fram (talk) 07:10, 1 April 2014 (UTC)

If this seems harsh, I wuold like to direct your attention to Wikipedia talk:Flow/Archive 8#Summary: known problems and discussion points. The first issue theer is the history, with the reply "Yep; we're refactoring the histories so you'll just have one page history with all the information. That's in our workload for this and next week. Okeyes (WMF) (talk) 17:04, 6 February 2014 (UTC)" Nearly two months later, this hasn't yet materialised. Additional problems appear though (e.g. if you go to Wikipedia talk:Flow/Developer test page right now (I can't make a permalink to this, I think; permalinks for topics, but not for the whole page?), you'll see that the second comment, "test without js", has in the header (left bottom) "1 month ago", while the third topic, "Sebastianowy thread" has there "28 days ago", even though it was created earlier; looking more closely, the topic "test without js" was created on March 24 ([4]), but the full page Wikipedia talk:Flow/Developer test page claims incorrectly that it was created Sunday 9 February; so the history is no longer consistent or trustworthy, assuming it ever was in Flow...) Fram (talk) 12:22, 1 April 2014 (UTC)

That's a weird timestamp bug; I'll investigate that next. Thanks for the pointer.

The unexpected delays are part of the joys of beta-testing software, which is why we're grateful to the wikiprojects that volunteered to help out (and why we didn't take up the offers of the busier wikiprojects that volunteered).

Permalinks within a board, are something that is being discussed in various inter-dept emails, with some older comments at bugzilla:58251. (TL;DR: We do want a method to make permalinks that go to "topic within the Board", but also want to retain the "topic by itself" view. Various technical-options, and defaults, are being considered.) Quiddity (WMF) (talk) 22:27, 4 April 2014 (UTC)

"An ounce of performance is worth pounds of promises." -- Mae West

Three months ago I asked for the following:

We lack a page where we document what we have decided. So let's create that page, populate it with the promises/commitments that we have made so far, and have someone on the WMF side be in charge of getting positive confirmation that there is nothing on that page that anyone on the WMF side objects to, a task that will be repeated once a month. It really is that simple.

I was promised that this would happen.

Two months ago I asked again. Again I was promised that this would happen.

One month ago... well, you can guess what happened.

I'm just saying.

"Unless commitment is made, there are only promises and hopes... but no plans." -- Peter Drucker

--Guy Macon (talk) 17:07, 31 March 2014 (UTC)

@Guy Macon: I thought we'd come to an agreement that the table of "Confirmed vs Experimental" features at Wikipedia:Flow/FAQ#Components of the discussion system was a suitable place for it, at least for now. My last 2 responses to you in the previous discussion mentioned some of the problems involved in moving it elsewhere; specifically as Johnuniq noted, "(in one place please!)".

We could move it to a subpage, and then transclude that back into the FAQ (so that people who are interested don't have to visit multiple locations to understand the details), but that still creates yet-another-page that anyone would have to watchlist to track changes.

In related news: Maryana has been working at annotating the page index and overhauling the navtemplate at Mediawikiwiki, as we discussed, and now that she's had time to give it a thorough re-read, I need to get more deeply involved, and replicate the changes to Enwiki. - However, we'd also like to centralize the documentation at a single wiki (Mediawikiwiki) so that pages are less likely to drift out of synch over time, and so that Enwiki doesn't have a 'special case' that other wikis won't; IE. create an updated summary at WP:Flow, and a lightweight user-guide, and then soft-redirect the other pages to mww, but leave all the discussions where they are because of m:not my wiki and watchlists. (I've been mulling it over for a while, hoping for a better solution, but I think it's like democracy...). Any thoughts on that? Thanks. :) Quiddity (WMF) (talk) 19:33, 31 March 2014 (UTC)

I looked through that, but it's still frustratingly vague about what happens. For example, right now if I see something fancy that another editor has posted in a comment, I can view their wikitext and work out exactly what template or other trick they used (I'm talking about useful things like {{ping|Example}} or {{u|Example}} and a lot more). It's unclear what Flow hopes to allow regarding those kind of things, and whether, if they were supported, it would be possible for anyone to view the wikitext that was pasted to create the message. I expressed another concern on 11 June 2013 (here) and I see that mw:Flow Portal/Basic information#User subscription and permissions still says that if X subscribes to Y's board, then Y is notified, and Y has to approve X's subscription—so if I want to monitor a problematic user, I have to get their permission. Johnuniq (talk) 01:46, 2 April 2014 (UTC)

It looks to me as if all the "fancy" stuff in Flow (whether wanted or not, whether beneficial or not), like subscription, cross-wiki pages, and so on, are still way, way, waaaay off, and probably shouldn't have been emphasised from the start. These things are sometimes used as reasons why Flow can't handle this or that, but so far all we get are the disadvantages (no archiving, no good TOC, no useful history, ...) and none of the advantages (none of which are very convincing anyway). Oh right, you can no longer forget your signature. Any other advantages of Flow so far? It's very hard to get a clear picture of where Flow stands now, what the supposed timeline is for the major improvements and implementations, and the where, what, how and why of it all. E.g. according to Releases, there hasn't been a release to enwiki since 20 February. Is this correct? Or is that page six versions out of date? [https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf20/Changelog#Flow suggests the latter). Fram (talk) 07:40, 2 April 2014 (UTC)

@Johnuniq: Re: "view another editor's wikitext", that's on the todo list, and is bugzilla:60465. That "Basic information" page is historical (I'll mark it as such, now), and as Jorm commented, the "permission" aspect was just a potential feature that was requested for consideration by the Ombudsman committee - it's not part of the current plan.

@Fram: Flow is part of the regular release "train", so the version of Extension:Flow that Enwiki uses, is updated at minimum every single Thursday. There are details on that, at wikitech:Deployments. That releases page you've linked, merely lists some of the milestones. The history page updates are almost done (and once complete/reviewed, they'll follow the release train to arrive here 9-14 days later, after getting a week+ of testing at the test sites, as per usual). The ToC design and implementation is progressing. There was a Quarterly planning meeting recently, and when the notes are onwiki, I'll point you towards those. HTH. Quiddity (WMF) (talk) 00:10, 4 April 2014 (UTC)

@Quiddity (WMF): you linked to Deployments: all I see there for Flow is "Week of March 31st: Hold" and "Week of April 7th: Hold". So this doesn't really help me one bit wrt Flow and its progress. The Trello ToC design link you gave doesn't seem to have much clear info on what is being presented. ToC is only one level deep, no subsections? Is it recent topic to old topic, or recent post to old post? That progress bar, does it work in a session or the next day as well? It seems to make it impossible to have a general or user-defined "us ewhole width" option once this progress bar is implemented, as it uses the right side of the screen which was so far uselessly empty. For me, it would be better to have no (or a very small) progress bar, and more of the screen space used to display the actual discussions. Reading that Trello discussion, using the right side to display, yuo know, the core content of a talk page is not even on the table, they are "inventing" stuff to fill the empty space. That is curiously backwards. And, like Guy has said time and again, there are way too many pages where one has to search to find all this stuff, and then one has to hope that the page you are reading is still up-to-date, which it often isn't. Fram (talk) 07:02, 4 April 2014 (UTC)

Sorry, the link to the Deployments calendar was meant to give you an overview of how the release train works, not as a Flow-specific resource (which I'd linked to a couple of, in the thread above).

Re: ToC: Flow doesn't have subsections (yet, partially because there hasn't been much demand for them). The ToC could potentially/easily be collapsible, if editors desire that. As for how it will work, I don't know exactly (it's just a mockup image after all), but I anticipate something better than mediawiki ToCs and LQT ToCs.

As for docs, yes there are a lot of pages (but too much is better than too little!), and we're in the (slow but ongoing) process of condensing/updating them. Quiddity (WMF) (talk) 22:29, 4 April 2014 (UTC)

As the flow project progresses, decisions get made. It would be be desirable to have a single page that documents those decisions so that commenters on the English Wikipedia side know not to rehash things that we already covered.

Is there a page that contains all such decisions? In other words, if an idea isn't on the list I know with certainty that it has not been accepted and that it has not been rejected.

Assuming that such a page exists, is there a way that I can be assured that a key player on the WMF side won't come back late in the project and say "I never read that page and never agreed to that"? In other words, if an idea is on the list I know with certainty that all of the key players on the WMF side agree on it.

It seems to me that, again and again I am being pointed to pages that, while quite useful and nice, fail to meet the above requirements. Typically I am told "I thought that [page the doesn't have any indication that WMF key players have signed off on it] is what you asked for". Yet I am also never told that my requirements are unrealistic or unclear. I am told that I will definitely get what I am asking for Real Soon Now, and so I wait another month and ask "where is it"?

So perhaps we can save some time this month. Just promise me that we will have a page where we document what we have decided and decided against. Promise me that an effort will be made to keep it up to date, and promise me that someone on the WMF side will be in charge of periodically getting positive confirmation that there is nothing on that page that anyone on the WMF side objects to. Then we can all go back to ignoring the issue, and I will have the rest of the month to find a new literary allusion to use when I bring it up again next month.

"Is that a page where we document what we have decided in your pocket, or are you just happy to see me?" --Not Mae West

--Guy Macon (talk) 04:34, 4 April 2014 (UTC)

Yes, the FAQ is "signed off on", by the Product Manager - (as in: if a team-member updates that page, then they run it by her (and other relevant team-members) first). Yes, I'll personally try to assist in updating it, and also nag the team to update it (and reread it), more often. Does that work, as a final answer? (If not, insert [promise] here, and trout me via email, or something ;) Quiddity (WMF) (talk) 22:29, 4 April 2014 (UTC)

[68f38336] 2014-04-07 11:36:55: Fatal exception of type Flow\Exception\InvalidActionException

I tried to comment on http://www.mediawiki.org/wiki/Talk:Flow and got aboves error.

The new system is terrible. There is too much space and not enough hints what belongs to each and who is saying what. I specially can't see any replies, there are just lots of boxes and "By clicking "Reply", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL" repeated over and over. --192.91.60.10 (talk) 11:39, 7 April 2014 (UTC)

If you're seeing that ToS (terms of service) message repeated, and many open reply-boxes, that means you've got javascript turned off. The non-js version hasn't been given much design attention yet, but is definitely planned.

Re: the Fatal exception, I'll investigate, and file a bug if it's a new one. Thanks for the report. (Filed as bugzilla:63649 - If you see this addendum, could you let us know what Browser/OS you're using? Thanks :) Quiddity (WMF) (talk) 20:22, 7 April 2014 (UTC) 20:45, 7 April 2014 (UTC)

Flow

For example, Flow will enable

1. automatic signing of posts,
   • Could be done with js - and User:Signbot makes it a non issue.
2. automatic threading,
   • could be done with js now
3. and per-thread notifications.
   • could be done by User:Mirror Bot now

What else will flow offer?

All the best, Rich Farmbrough, 22:37, 18 April 2014 (UTC).

Automatic threading could be done with JS? Show me. — Keφr 08:43, 19 April 2014 (UTC)

Fatal exception

I looked back on a conversation, tried clicking "unhide", got fatal exception from the following URL:

https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:WikiProject_Breakfast&workflow=ronqadmetsq9duv8&action=restore-topic

e.g. "[7f0e5ae2] 2014-05-06 19:18:34: Fatal exception of type Flow\Exception\InvalidActionException"

Wnt (talk) 19:19, 6 May 2014 (UTC)

@Wnt: Hmm, I'm unable to reproduce that. I tried hide/unhiding this testpage topic, including doing so whilst the topic was collapsed and also whilst expanded. Where there any other variables that you know of, which might be relevant? (eg. using a non-js browser, or ?). If you, too, can't think of other variables, then I'll just file it as a mystery bug! Thanks.

Re: unhiding the topic itself - Did you really intend to permanently unhide the topic? Or were you rather wanting to temporarily uncollapse it, in order to read it? If the latter, then you can just click on the grey Topic Titlebar, to expand/uncollapse a hidden element.

HTH. Quiddity (WMF) (talk) 22:26, 6 May 2014 (UTC)

It's true that I was just trying to read the topic. However, the error is reproducible with scripts not enabled - at your example, trying to hide the item yielded [5], another error. However, with scripts enabled (after some time hunting for the options - I guess people nowadays are supposed to look for any three tiny icons and assume that's something to click on?) I managed to hide and unhide without the error. (however, the edit to "hide" now has a line through it in my edit history, like a deleted edit. Which seems questionable...) Nonetheless, scripts or no scripts, the URLs I'm giving go straight to fatal error. Wnt (talk) 23:12, 6 May 2014 (UTC)

Summary

I noted a (to me) new functionality of so far dubious usability, "summarize". It does have one nice result though; when you add a summary to a discussion, all the history disappears (when checking "history" at the top right of the topic; the only thing that remains is the edits to the summary, everything else is gone!). Was this intentional (he asks innocently)? Fram (talk) 09:24, 7 May 2014 (UTC)

Thanks for the bug! I'm not sure if it's actually related to summarizing. Filed as bugzilla:65050. Note that the history seems to be fine at the other topic you summarized.

This feature is indeed brand new, and is intended to grow into (with our feedback and suggestions) something along the lines of {{Archive top}} and related templates. It could also be adapted or transformed into a preliminary summary? More feedback = more potential!

(I should really get a new edition of the newsletter written up... My bad. Soon.) Quiddity (WMF) (talk) 03:44, 9 May 2014 (UTC)

wt:breakfast board disabled?

Has the wt:breakfast board been disabled? I cannot post a new topic there and the latest posting from others is a month old. XOttawahitech (talk) 14:15, 8 May 2014 (UTC)

Just tested, still works. The 14-day test of Flow is ongoing (yeah right), the roadmap very realistic ("February 2014-June 2014: User talk beta feature opt-in, Limited article talk trial, ..."), the exchange of ideas and improvements impressive. Dead as a dodo.

A random example, Wikipedia:Flow/Community engagement#Release plan. "For the remainder of 2013, we've plotted..." yes, off to a good start. "Any feedback they might have – good or bad – will be gathered on the Flow portal talkpage. This page will be archived to avoid confusion between older and newer discussions and will also be converted to use Flow, as a way of forcing us to confront deficiencies in the software we expect others to use." The Flow portal talkpage, that is this page, right? Which, obviously, hasn't been converted to use Flow. Bye bye, promises by the WMF.

The end of the page is really brilliant:

"Current medium-term (January through March 2014) plans include some or all of the following:

• approaching more English Wikipedia WikiProjects about participating in a wider trial
• Flow-enabling new Beta features discussions on mediawiki.org
• creating a new beta feature option to Flow-enable a user talk page
• Flow-enabling a sample of articles under the scope of WikProjects that are using and happy with Flow
• approaching other language projects and sister projects to trial Flow in a limited opt-in fashion on their wikis
• converting Liquidthreads discussion on Mediawiki.org to Flow"

Before the trial, the promise was made that one possibility was to "End the trial and temporarily revert back to talkpages (all Flow discussion content will be turned back into free-form wikitext) while we implement any necessary changes". Why this hasn't been done while this project is flatlining is not exactly clear, even though the two projects are barely used it would be a good gesture by the WMF that they are aware that the trial has indicated that the software wasn't really ready yet and that further live trialing is a bit premature at the moment. Fram (talk) 14:31, 8 May 2014 (UTC)

The Flow portal talkpage mentioned above is afaik at mediawiki.org (and Flow has been enabled there). --HHill (talk) 16:38, 8 May 2014 (UTC)

Yup. That point was meaning the mediawiki.org page. Sorry for the ambiguity. (That page was previously using LiquidThreads, and hence was very confusing when newcomers arrived to discuss Flow). This page on Enwiki is currently/purposefully left as a standard talkpage, to avoid argument/distraction. (That's what I've been recommending to the team, at least.)

The two Wikiprojects that were taken up on their offer to help, are still welcome to stop trialling the software. They were quiet before Flow was enabled there, so the software is not to blame for the sparse activity. (Eg. July 2013 was silent at WT:Breakfast). The slow trialing is helpful for the dev team, and if the Wikiprojects are willing to continue using it, that would also be welcome.

Regarding the problem that Ottawahitech has had starting a new topic, I've tried to replicate the bug, but not had any success. As I wrote at User talk:Ottawahitech#Flow feedback, if any further clues are available (specifics as to how far you get before a problem is encountered, and details on the browser/OS used at the time, etc), they'd be much appreciated. Quiddity (WMF) (talk) 03:05, 9 May 2014 (UTC)

"The slow trialing is helpful for the dev team," In what way? I thought you had an agile approach, what use is it if that is then "slow" tested? What added value give the two Wikiprojects that the much more active (relatively speaking at least- Developer Test Page doesn't provide, apart from a rather hollow "hey, we are live on two Wikiproject pages!". Flow isn't ready at all, it has now been live for, well I don't know how long since the history is apparently ruined beyond repair ([6] the 7 February MzMcbride edit wasn't the first edit to this page, and the deleted edits don't give the full image either), but at least three months, and the deadlines presented have never been met (just look at the Community Engagement" page I linked to above.

As for "the talk page is at mediawiki", right... Too bad that e.g. the Labs page[7] (also rather moribund) directs people to this talk page as well, the enwiki one, and not the mediawiki one, making the claim that "Any feedback they might have – good or bad – will be gathered on the Flow portal talkpage." means the mediawiki talkpage a bit dubious... By the way, [8] only starts at 25 February, in the middle of a conversation. Is there a limit to the number of history items that get displayed, or is the older history lost, or what? In any case, infinite history scrolling isn't really useful either for very active pages.

Something else: [9] claims for this and next month that it is " Doing... Wider release to more WikiProject and community discussion spaces on English Wikipedia and other projects, on an opt-in trial basis". Any indication of what it is that is being done, and why? Which "community discussion spaces", which "projects"? Wouldn't it be more logical to first get most of the errors corrected, most of the comments you received included in the software and design, before rolling this out any further? And perhaps communicate the plans a bit more, indicate the improvements, instead of just playing along in the ivory tower and dumping things here? The "community engagement" as promised is again sorely lacking and one-sided (while not as bad as with VE, which would be an achievement...). Fram (talk) 07:30, 9 May 2014 (UTC)

The trialing on pages being used for actual work, as opposed to pure sandbox pages and via automated-testing scripts, is helpful because it brings up occasional suggestions and bugs that might not otherwise get mentioned/noticed.

Regarding Wider Releases, I've been pushing back against this for precisely the reasons you mention, until more bugs are fixed and features implemented. That's why you haven't heard more about those goals that were written by the product manager (managers are eternally optimistic about dates). Once Topic-sorting is finished, and a few more History page bugs are resolved, I'll start to renew the request for additional volunteer Enwiki locations.

Yes, I'm behind in documentation updates, and update/newsletter writing, for which I apologise and will work harder on.

Thanks for pointing out the history problems (infinite scroll, and missing entries). I'll file bugs for those momentarily. Quiddity (WMF) (talk) 18:37, 9 May 2014 (UTC)

Something is very wrong

I tried several times to post this to mw:Talk:Flow and mw:Talk:Flow, but it wouldn't post.

All topic history pages, such as this one, are broken, giving a Wikimedia Foundation error with the description
"PHP fatal error in /usr/local/apache/common-local/php-1.24wmf4/extensions/Flow/includes/Data/TopicHistoryIndex.php line 92:
Call to a member function getAlphadecimal() on a non-object ".

Also, several posts at one thread at Talk:Beta Features/Hovercards are showing up with the username "MediaWiki" and the content "Due to a technical error, this post could not be retrieved.". This might be an isolated incident, but these posts are the most recent flow posts I could find anywhere on MediaWiki with the exception of one post to the same thread that still works.

When trying to post this to the flow pages, I also got "An error occurred. The error message received was: Exception Caught: Attempted to compact row containing objects, must be scalar values: Flow\Model\UUID Object ( [binaryValue:protected] => ���]�g�e��j [hexValue:protected] => 05178f5def6791659d076a [alphadecimalValue:protected] => rufm8fwim748n696 [timestamp:protected] => ) " multiple times. It refused to post. However, another test post worked.

These may or may not be connected. (Firefox 24, Windows 7):Jay8g [V•T•E] 02:05, 10 May 2014 (UTC)

I get the same error, so I will post here my reply to Quiddity (WMF) at the "Infinite scroll is seriously annoying" thread: If there ain't going to be a configuration setup, then the design should be paginated. Among other things, infinite scroll makes the footer impossible to reach, and there are important things down there - such as the license, and the disclaimers. The infinite scroll may have problematic legal implications because of this. Diego (talk) 09:06, 10 May 2014 (UTC)

@Jay8g: Thanks for the reports. The devs are indeed working on it, with bugzilla:65051 and bugzilla:65093 being the ones that tracks two of those issues. Most of them are at mw:Zürich Hackathon 2014, so are fitting in patches between workshops.

@Diego Moya: Good point. (link to the thread for anyone curious). I'll ask the team on Monday, and I'll ping you when the posting bug is resolved so that you can add it to thread. Quiddity (WMF) (talk) 17:23, 10 May 2014 (UTC)

Problems encountered today

• Okay, good that the first comment in a section uses a smaller font; the previous one was way too big.
• However, you've not listened to the part that said "don't have subsequent comments in a smaller font", and now the subsequent comments are in such a small font that it's very difficult to read at a normal distance from the screen for anyone with the slightest bit of nearsightedness. All the UX design stuff I've read says "smaller font = less important". That is not the message that one should be sending for reponses. They should be visually just as important as the original post(s).
• T63077 is back with a vengeance and is even worse than it was previously. It's no longer a shivering chihuahua, it's now a shivering great dane, and the cursor was no longer returning to the "typing line" after the shiver, it was staying a few lines up.
• Clicking on external links inserted into the text does not open the link in a new tab, but takes one directly to the linked-to website; essentially, it closes the tab to the talk page. It should always open a new tab.
• It is not possible to examine an external link before clicking on it, so one has to trust that the person who inserted the link will not send the reader to a site that might be a problem for that reader. Gonna be honest, there aren't a lot of people I trust that well; even people I know who have acted in good faith have inserted links that I don't want to follow or that will create problems for some users. [Note: admins can click "edit" and see the link, but non-admins cannot do so]
• The amount of "whitespace" is well in excess of anything that has been linked to as examples of good use of whitespace. On a 17-inch screen, there's only 8 inches used; on a 14-inch screen, only 7.5 inches. This is excessive whitespace, particularly since it is so unbalanced (all but 2 inches are to the right on both screen sizes). Having the "whitespace" in two different colours - very faint grey on the left, faint blue on the right - is jarring to the eye. After spending a fair bit of time using Flow on Wikiproject Breakfast talk page tonight, I had to take analgesics for the headache; I've never had to do that with a Wikipedia page before. [Okay, maybe a couple of times, but because of the content, not because of the visual display!]

That's tonight's comments. Risker (talk) 05:43, 12 May 2014 (UTC)

Thanks Risker. In order:

• Font-size: This will be fixed in the (much-delayed) front-end overhaul. The font-size will match that used everywhere else, and posts will all use the same size. Ditto for font-color fixes.
• Bug 61077: I believe that's a separate (and probably fixed) bug, as we haven't seem the 1 pixel shimmer in quite a few months. The bug you're seeing there, is bugzilla:58657. Very annoying when encountered, I agree.
• Open external links in new tab: I was confused, but took a lucky guess, and found a gadget. I'm guessing you're using the (non-default) "Open external links in a new tab/window" Gadget? I've filed bugzilla:65243. :)
• Viewing the target of an EL: Hmm, many (I thought all?) browsers show the URL when we hover over the link, but I suppose that won't work for tablets or the mobile interface. Regardless, bugzilla:60465 ("provide View Source (showing the wikitext) of someone's post") tracks that request. It is needed for various use-cases, from viewing EL-targets, to learning wiki-code, to replicating content elsewhere.
• Whitespace: The main aspect to consider for ongoing discussion (which should probably be split into a new thread, or re-use one of the existing threads at WT:Flow/Design FAQ) is the upcoming Table of Contents addition, which will appear in the currently empty area at right. The initial iteration will look something like this http://area51.yar.gs/wmf/flow1/ but there's a design mockup for a future version, which I'm personally excited about - it introduces the idea of meta-data directly within the ToC, showing things like unread posts, or posts that mention us, as well as where we are within the length of the topic. Intriguing possibilities.

HTH. Quiddity (WMF) (talk) 01:37, 13 May 2014 (UTC)

Special:WhatLinksHere doesn't work for Flow headers.

Tracked in Phabricator
Task T59512

Special:WhatLinksHere doesn't always work on Flow. For example, Special:WhatLinksHere/Template:Flow-enabled, which should give a list of every page with flow enabled, yields nothing. -- Ypnypn (talk) 19:21, 20 May 2014 (UTC)

@Ypnypn: Thanks. That issue is tracked at bugzilla:57512 (more details in this trello card). I believe it's getting close-to-complete, but has been a nightmare of overlapping patchsets. Quiddity (WMF) (talk) 23:17, 20 May 2014 (UTC)

New topic tab

We recently had a user come to Wikipedia talk:WikiProject Hampshire who thought they couldn't edit the page (so left a message on the main project page instead). Presumably this is because there's no "Edit" tab at the top of the page. Could this be overcome by adding a "New topic" tab where the "Edit" tab would normally appear? WaggersTALK 12:00, 20 May 2014 (UTC)

I think one issue is that the text "Start a new topic" is written in a very light shade of gray, making it quite difficult to see. -- Ypnypn (talk) 19:18, 20 May 2014 (UTC)

I agree with Waggers that moving it to a different position is a problem. It's inconsistent with how it works with article pages, and with the muscle memory developed through habit. Diego (talk) 20:47, 20 May 2014 (UTC)

Great suggestion, Waggers. Plus I'm attending a design-review meeting in 10 minutes, so perfect timing. :)

@Ypnypn: Yup, I've grumbled at length, about the low-contrast text colors. However, the current UI hasn't been getting much work done on it, because the new Front-end overhaul has had priority (to get it here faster). Many bugs will be fixed, when that goes live. (and new ones introduced, inevitably! >.> ). HTH. Quiddity (WMF) (talk) 23:23, 20 May 2014 (UTC)

Export

How do I export flow talk pages? I have tried with special:export but the .xml file says something like "this talk page has been taken over by Flow board", but isnt it possible to export anything, even the wikiprojects in the top? Christian75 (talk) 21:04, 4 June 2014 (UTC)

You can't yet. This functionality is being worked on with the ContentHandler integration, but that's still very much a work in progress. Legoktm (talk) 04:18, 5 June 2014 (UTC)

There are still some problems

I have just checked out the sample talk pages using Flow. Though I have not commented yet using the new design, I may have to raise some issues which I do not know if they were raised already.

1. Wikilinks do not work in titles.
2. (Important) Spacing to the right. There is a lot of white space to the right that can be used to make scrolling down less tedious.
3. No table of contents. How can we navigate to a section right ahead without scrolling?
4. How will talk pages be archived? In the current implementation, a user can manually cut-and-paste the content of the talk page and transfer them to a new archive page. Or a bot (Lowercase sigmabot III or ClueBot III) can automatically archive a talk page. In the Flow implementation, we cannot manually edit the page to cut-and-paste the content; neither can we place a script for either of the two aformentioned bots to operate. In that case we will let the talk pages lengthen indefinitely. How do we archive talk pages in the Flow design?
5. Having uneditable comments means one cannot strike out or modify unintentionally placed things.
6. The heading has still been too large.
7. Why do we have the broken vertical lines? Say this:

Comment 1

Comment 1.1

Comment 1.1.1

Comment 1.1.2

Comment 1.2

Comment 1.2.1

Comment 2

There will be a vertical line to connect comments 1 and 2, and 1.1 and 1.2. The current implementation is still better as it makes indentations more noticeable.

1. How do we outdent? Once a long thread has gone on with every comment commented on, I am afraid the indentation in Flow will go really far to the right that we will need to scroll horizontally.
2. Still too much space between comments.
3. Why was the font made larger? The current implementation's font size is readable to most editors.
4. I am not comfortable with scrolling in a comment. we should allow for a long comment to be read straight without being scrolled.
5. Hidden details. Why scroll over an editor's name to reveal their user talk page and contribs? And why scroll over the 'x days ago' to reveal the timestamp?

Should the Flow on user talk pages be implemented:

1. How do we customise our user talk pages? I know we have editors with user pages that have complex stylings; how do we merge them in the talk page (e.g. custom tabs, borders, templates, notices, etc.)
2. Archival issue (raised above)

General:

1. Hello? This is not a blog, this is Wikipedia. Why do we make our Flow talk pages Blogger-style comments?
2. How can a talk page be opted-out from receiving the Flow design?

I may have raised a lot of concerns, but I believe these may make Flow a bit better. I already had feelings of opposing this Flow design, I liked how talk pages appear as it stands today. I wonder how editors can have more leeway for their user talk pages. Also, old norms should be kept. See how a ban of RHD vehicles has angered a lot of citizens in Russia? This is contrary to Thailand which permits both LHD and RHD vehicles. I could appreciate if there will be a way to opt-out and have these two systems co-exist. Japanese Rail Fan 09:07, 20 May 2014 (UTC)

(Quick note: I lost a partially written reply to this earlier, in a browser crash. I'll write it again tomorrow. Sorry for the delay.) Quiddity (WMF) (talk) 01:16, 23 May 2014 (UTC)

I understand, just take your time Japanese Rail Fan 06:57, 27 May 2014 (UTC)

@Japanese Rail Fan: Much thanks for your patience with my delayed reply, and even more so for your detailed feedback. In order:

1. Currently, no wikimarkup is functional (parsed) in Topic Titles. This is still under-discussion, with a previous request for feedback at mw:Talk:Flow and further discussion & issues mentioned at bugzilla:57153. One of the difficulties (mentioned in there) is in implementing a limited wikitext parser (See the bugzilla discussion for brief background, and this example diff - we currently let anything go in standard wikimarkup source headers, which leads to complications elsewhere if enabled in Flow). Another of the larger problems, is the current way that Flow implements "collapsing" of Topics, with the Title Text (as well as the rest of the Titlebar) serving this purpose - This is all still being continuously examined and re-evaluated, so might change in the future.
   The current proposed solution, is to use the "Summarize" feature (in the Actions menu dropdown, it's a Topic Summary that appears in the Titlebox, and can be added/edited at the start/middle/conclusion of a discussion.). For example, compare the first entry (especially what is seen in the ToC) at WP:RFPP, with this example in Flow. It's using the same {{la}} template, just in a different location.
2. Whitespace on the right: See this thread, particularly my 3rd bulletpoint.
3. ToC: as above, but 4th bulletpoint.
4. Archives: Flow is auto-archiving [Edit to add:] doesn't use a page-removal archive system, it keeps everything in the same location[/]. No bots will be required, and permalinks will never break. It's already auto-paginated for users without javascript, or infinite-scroll for users with javascript. (The latter, infinite-scrolling, has been troublesome in many ways, and is currently being re-examined, for either removal or overhaul.) There are a few features that are needed/planned, in order to make this auto-archiving possibility work well, including things like the option to "Re-sort topics by order of most-recent activity" (being developed at the moment), and "mark topic as closed" (currently available, but the output-display is hiding the title, which it shouldn't).
5. Editability of other people's comments: As the FAQ says (also at "Comment editing" in the table), this one is still experimental. There's some detailed research at mw:Flow/Editing comments, and I'd encourage the addition of more Example diffs in the 3rd section there (under the table). Older threads discussing this in depth, are collated here.
6. The Titlebar's size, the title-font itself, and other aspects of the visual design, are definitely still in the early stages of aesthetic experimentation and refinement. There's a large overhaul coming soon (much delayed, but planned to arrive in 3 weeks). I'll be sending out more news (and links) about that next week, and nagging everyone for fresh feedback once it's available.
7. The indenting/threading system is currently limited to exactly 3-levels of depth. There are good arguments for increasing that maximum level, and also for trying a flat-format instead, like bugzilla(which will require a better "backlink" and "quoting" system, to indicate who we're replying to). It's due to be re-examined by the Product Manager soon. There's a good list of external examples for comparison and contemplation, at Wikipedia talk:Flow/Archive 6#Request for your feedback: Let's talk about nesting! This is one of the most difficult and potentially-subjective design decisions, so further experimentation is guaranteed.

(Then your numbering resets a few times, and there are overlapping points so I'll revert to bulletpoint.)

• The aesthetics will change significantly in the upcoming front-end overhaul, including making the font-sizes match what we have everywhere else. Regarding density, I'm still advocating for "user options", as I personally prefer a very dense wall of text, but I completely understand how other users find that less usable.
• long comments getting vertical scrollbars: Hmm, I don't recall where this design decision came from, or what the limit is before it kicks in. example post. I'll ask on Monday.
• The mouseover links: For usernames, these are intended to provide a balance between the current signature default [Name (talk)], and the most used poweruser requirements (or newcomer insight device) of getting to a user's contributions; additionally, admins get a link to [block user] added to the list of links. For timestamps, I'm still advocating for this to be a user-preference - personally I prefer the "exact/absolute" timestamps, but I completely understand how some people (eg. bugzilla:30857 and elsewhere) will want the "elapsed/relative" timestamps, and that 'elapsed' might be a better site-default.
• Usertalkpage: Good point - I'll probably have to compile some examples of this. (Sending me links, would be appreciated!) We do already have the Header Area at the top of each Flow Board, but I'm not sure how easy reskinning the rest of it would be, nor how page-edit-notices will integrate.
• Usertalk archives: See above. But also, they're planning on re-examining Newsletters and Echo, to see how that might be improved for everyone.
• General: If I understand correctly, you're commenting here on the aesthetics and the threading? As described above, these aspects are definitely still in the experimental phase.
• Flow is a long long way from being 'ready' to convert entire namespaces. It's being trialled at a few locations that volunteered at the moment, and the plan is to get enough feedback and new features implemented, that in the future, all us power-users will want Flow, because it will be a clear improvement to the many complexities and problems of current talkpages. That will take time, and continued requests for new/better features from us.

Hope that helps. Quiddity (WMF) (talk) 20:49, 1 June 2014 (UTC)

• "Archives: Flow is auto-archiving." And then you go on to describe that Flow doesn't archive at all, because it isn't needed (in the opinion of the devs). Somehow, the page will cope with infinite amounts of info, endless discussions, and so on. It totally doesn't at the moment (even the history can't cope with it, dropping older entries), but this will be solved someday. Perhaps it will, but this is not "archiving", this is "we don't archive because it isn't necessary". Calling it "auto-archiving" is newspeak, which should be avoided. Fram (talk) 07:22, 2 June 2014 (UTC)

  @Fram: I didn't word that clearly, thanks for pointing it out. I've struck and rewritten, above. Re: the incomplete history pages, that's bugzilla:65088 and bugzilla:65090 (basically the same issue, but described in 2 ways). Re: future scaling issues, I'll ask what specific testing/planning there is for this. Quiddity (WMF) (talk) 21:31, 3 June 2014 (UTC)

  Thanks. Fram (talk) 06:23, 4 June 2014 (UTC)

Responses are nice, though there are a few clarifications. With reagrds to the timestamps, editors would sometimes want to change them such that they become relative to their timezone (mine is UTC+8). Do JavaScripts and CSS sheets work in Flow? Also, it may be a nuisance for power users to hover over the mouseover links instead of seeing them at an instant. And how about comments that contain anything other than text, such as links to other Wikimedia pages, images, barnstars, templates, and the like? Also, how about the fate of the archival bots? Is there a way for users to choose what archival convention they will want (month, size, number of threads, no specific, etc.)? Japanese Rail Fan 12:56, 2 June 2014 (UTC)

@Japanese Rail Fan: Re: Timestamps - They do follow our user-preferences for "Time offset" (just checked), so that's a nice change from current UTC-only signature timestamps - As I mentioned, I am pushing for "Whether to show the Elapsed or Exact by default" to become a userpreference itself, for exactly the reason you describe. Re: JS/CSS - I still need to ask/investigate details; Our personal CSS/JS will definitely function, but I'm not sure if/how custom styling that others would see will work (e.g. coloring the entire background bright green). Re: wikimarkup, it almost all works exactly as usual, with the one major bug being image thumbnails/captions not displaying properly yet (bugzilla:61786 and related, they're working with the Parsoid team to get this straightened out). Re: how many topics are displayed on the page by default, and forced- or time-based- 'archiving' (removal from default page), that's still being explored. HTH. Quiddity (WMF) (talk) 21:31, 3 June 2014 (UTC)

Changing timestamps is more fluff with no value. It is sometimes useful to refer to earlier comments by identifying a timestamp, which is not possible if everyone sees different stuff. Who cares what my wall clock thinks about the time you posted your comment? Johnuniq (talk) 22:35, 3 June 2014 (UTC)

@Quiddity (WMF): Thanks for the responses. I will give another feedback later this year. Japanese Rail Fan 13:33, 4 June 2014 (UTC)

@Johnuniq: That one timestamp will do, but it will trouble editors editing in adjacent timezones, especially if the topic concerned uses the editors' timezones. Japanese Rail Fan 13:33, 4 June 2014 (UTC)

@Johnuniq: I think I'm personally in agreement with you; "exact/absolute" timestamps are what I want to see by default - especially so, for anything that happened more than a few hours ago. However, other people see an exact timestamp and their first reaction is to mentally convert it into a "elapsed/relative" timestamp. cf. bugzilla:30857, especially so for very-recent actions.

For example, StackOverflow seems to display "relative" times for recent actions, eg all the posts in this thread currently say "7 min ago" and similar (with mouseover for "exact" times), but in older threads (anything more than 1 week?) "exact" times are given by default. Gmail does something similar.

Sidenote: I grumbled at my colleagues today, because I'd read a comment somewhere that referred to "relative" timestamps as "human-readable", a term which irks me for obvious reasons - one of the devs (which surprised me!) replied, "I find x days ago is more human-readable. When I see May 20, my mind is auto converting it to 14 days ago". So even devs can prefer fuzzy timestamps!

Sidenote2: re: "... if everyone sees different stuff" - We do already see different stuff in some places, if we've customized our "Time offset" in preferences - it only works in History/Contribs/RecentChanges/Watchlist feeds currently - not with our subst'd signature timestamps - which is why I (and probably many people) don't take advantage of that particular preference option (and consequently have to mentally convert UTC to my local timezone, on occasion. In both discussions, and watchlists/histories/etc). So, yes, it would be simpler in some ways if we all used UTC, in all places; but we currently don't. We could either expand the options we currently have, or keep the imperfect current mixture, or remove the Time-offset options completely (unlikely!).

To get user-options, which are more complicated for devs to write/test/maintain, I need a list of use-cases to help convince the Product Manager that an option is a necessity (either immediately, or at some point in the not-too-distant-future). Hence keeping an eye out for processes that require an editor to examine a set of "exact" timestamps, is one of the things that I'm currently working on - If anyone has perfect examples, I'd be grateful if you'd send them to me. (here, or my talkpage, or email :)

HTH. Quiddity (WMF) (talk) 04:07, 5 June 2014 (UTC)

@Quiddity (WMF): There's a big problem with relative timestamps, though: they change literally all the time. If you only care about the distance with respect to now (such as assessing how much time did an editor reply to your latest post) then yes, I agree those are more readable.

But in threaded conversations it's often useful to compare the relative times of disparate comments among other editors, maybe even between different talk pages. In such cases, the only meaningful way to do such comparisons is to have the fixed absolute timestamp for each comment; requiring the user to hover over all timestamps and keep them in their short-term memory would kill the possibility to make such comparisons.

If relative "x minutes ago" dates are shown by default, instead of a user preference that is set one time and forgotten I'd rather have a "show all timestamps" button that made all timestamps absolute until the page is refreshed. Diego (talk) 11:53, 5 June 2014 (UTC)

@Quiddity (WMF): It's essential that Flow allows completely freeform archiving, at the discretion of individual editors as to how and when it happens - much like the situation is now. If that option is not available, it'll actually be a downgrade from current talk page functionality. — Scott • talk 13:44, 4 June 2014 (UTC)

@Scott: Yup. There's a whole mountain of complexity to replicate and improve on, in regards to the existing manual and bot style archiving possibilities. Like everything wiki, it'll start simple but with an eye towards future complexity. Quiddity (WMF) (talk) 04:07, 5 June 2014 (UTC)

Like — Scott • talk 08:26, 5 June 2014 (UTC)

History rather crowded

looking at the Flow page history[10], I get before my "edited a comment" no less than seven links, which is total overkill. Of course, this is partly caused by the 4th[11], 5th[12], and 6th[13], which all return the exact same result. Not the same URL, but the thing you get to see is the same. I can imagine you testing which links are the best, but then please provide us with different results to choose from... Fram (talk) 06:59, 21 May 2014 (UTC)

Agreed, and a re-examination of the items in the full history is coming soon. Both aspects: the elements contained in each line/type, and whether some of separate lines could be merged/bundled together (eg. the currently separate "created a new topic, and made a new post within that topic" by 1 person). I'll post more about that, later. Quiddity (WMF) (talk) 00:11, 23 May 2014 (UTC)

Is there any need to change the format of the history tab at all from what is existing? What problem is being solved by reinventing that wheel? VQuakr (talk) 17:47, 8 June 2014 (UTC)

@VQuakr: The software is not a pure wiki-page, and there are many new aspects/possibilities that wiki-pages don't have, hence many of the old-functions need to be re-created, and new-functions (can or should be)fitted in alongside them. Just as LiquidThreads has a different style to its entries in watchlists/rc/etc, so too can Flow. Whether we can collectively suggest & decide upon an improvement to the elements, is up to all of us. The easiest option is "just recreate what we're used to", but hopefully we can do better than that. I'm used to watchlists as they are, but many editors don't use them at all for a variety of reasons. (Hence the voluminous mw:watchlist wishlist). How might you change watchlists, and talkpage topic entries, and notifications? Quiddity (WMF) (talk) 05:11, 13 June 2014 (UTC)

Table of Contents

Yeah the "no table of contents" thing makes long pages pretty unusable. Is there a timeline for when that is going to be addressed? I didn't see it in the list of open bugs. --Cneubauer (talk) 18:49, 9 June 2014 (UTC)

@Cneubauer: Thanks for the feedback. There's an innovative design for a ToC with many new features (which I personally really like, for it's tuftian complexity and meta-data payload), but the product manager wants to re-examine whether that is too complicated, both visually and code-wise. There's no current ETA, but it is a fairly high priority feature, so, "soonish" I think. I'll ask for an update. Quiddity (WMF) (talk) 06:18, 13 June 2014 (UTC)

Undelete

Standard undeletion doesn't seem to work: [57026627=1]. The integration of Flow solutions with the standard interface is lacking (here, history, watchlist, ...). Fram (talk) 09:55, 12 June 2014 (UTC)

@Fram: They plan to implement standard revdel functionality. Here's the trello link, which is related to a few other cards, e.g.. I'm not sure if there's an ETA; will ask. Quiddity (WMF) (talk) 06:54, 13 June 2014 (UTC)

Automatic archiving

Is it the case that all talk pages will be archived when Flow is turned on? And will the history of the talk page show the archive history? It doesn't seem to at the moment. See my post at [14]. Dougweller (talk) 08:43, 11 June 2014 (UTC)

I hope you get an authoritative answer, but meanwhile my understanding is that a page like User talk:Dougweller would stop existing if Flow were introduced. Instead, that link would go to a Flow page. By archiving, I guess they will move your talk page to some subpage, so the contents and history would end up elsewhere. That can be seen at mw:Talk:Beta Features/Nearby Pages where there is a link to /Archive 1 which looks like a moved talk page, with a history. There will be lots of points like this that need documentation—I'm wondering about a few things myself, such as the fact that I often use my browser's Ctrl-F to find stuff, and I suspect that won't work any more. Johnuniq (talk) 09:50, 11 June 2014 (UTC)

@Dougweller: Indeed, Johnuniq is correct, that the current plan and method is to "move-archive" any existing talkpage, before Flow-enabling the location. I'm currently doing it manually, a few minutes before the page is converted. (Hmmm, perhaps we should automatically add an archive-box link to the history page, if there exists an "/Archive (n)" subpage...? That'd probably be handy, for non-Flow locations, too... It's not easy to tell whether a wikitext page has been using the "cut&paste archive" or "page-move archive" method, without manually checking. So we should make that checking easier.)

@Johnuniq: Yes, the documentation does need an update/overhaul. I've asked the team to help me compile a list of changes over the last few months, for both doc pages and a new Newsletter. (They've been doing so much work on the backend lately, that whilst it appears to not be moving forward, there are structural changes in place now that should make future growth far smoother.) I won't promise a deadline for update/completion, but it is near the top of my priority list, once I get back from travelling this week. As for ctrl-F, that's one of the main points against using infinite-scroll (which is still being hotly discussed by the team). HTH. Quiddity (WMF) (talk) 06:35, 13 June 2014 (UTC)

Quiddity (WMF), do you realize that this will break en.wiki guidelines on user talk pages? There are things that must not be removed, eg existing sanctions and open unblock requests. Have you actually looked at our user page guidelines? As for article talk pages, they have headers that must stay - will your method remove the headers? Dougweller (talk) 07:10, 13 June 2014 (UTC)

There will still be an editable space at the top of every Flow page, so people can add headers and notifications. DannyH (WMF) (talk) 17:22, 13 June 2014 (UTC)

Feedback

Just some

1. No table of contents?
2. Doesn't fill whole screen, on Firefox fills ~1/2
3. When I type in this box the bottom jiggles up and down
4. Couldn't easily find how to edit a section

<nowiki>Thanks, ~~~~</nowiki>

Found how to edit. No signing? That is weird...

1. Page history is a disaster. The current page history is fine, why change it? Thanks, Matty.007 16:31, 9 June 2014 (UTC)

@Matty.007: Hi, thanks for the feedback. :)

1. There's definitely a Table of Contents coming in some form. It's complicated by two main factors: 1) because they've been planning (and are now in the midst of creating) a feature for "a button to re-order the topics by most-recent-activity" as well as the default "order topics by order-of-creation". 2) the infinite-scroll (still an experimental-feature) makes a 'complete' ToC harder to deal with. There are solutions for both problems, but they require more research and prototyping-time, hence we don't have one yet.
2. See my response to #My feedback above, for the answer to this.
3. That's either bugzilla:58657 if it's jumping by a large amount, or bugzilla:61077 if you're only seeing a 1 or 2 pixel sized movement. Please let me know which? (I think the latter has been solved, and that you're seeing the former, but I'd like to confirm.)
4. Do you have any suggestions for how to make it more intuitive?
5. Posts are auto-attributed ("signed" in essence) so we won't have to teach newcomers to write "~~~~" anymore, nor use {{unsigned}} or rely on sinebot (and their equivalents, or missing-equivalents, at other wikis).
6. See the thread #History rather crowded above, for details.

Hope that helps, thanks again. More feedback would be welcome/appreciated. :) Quiddity (WMF) (talk) 06:07, 13 June 2014 (UTC)

Just a couple of pixels. What will happen to signatures? Will Flow be able to be disabled on pages where it isn't wanted, such as on user pages? Thanks, Matty.007 17:41, 13 June 2014 (UTC)

On Flow, posts are signed and dated automatically, sparing us from the unsigned template forevermore. We're still working on the enabling/disabling part. The goal is to make a feature that everybody finds useful, on user talk and article talk, but there's a list of features and improvements to work through before we get there. DannyH (WMF) (talk) 18:34, 13 June 2014 (UTC)

Redirects

Can someone please clarify the behaviour of redirects with Flow, specifically:

1. What happens when a Flow page is moved?
2. Can an existing Flow page be redirected without moving the Flow board?
3. What will happen in the conversion process to talk pages already redirected (such as User talk:ClueBot III and Wikipedia talk:WikiProject Articles for creation/Reviewing instructions)?

Thank you, BethNaught (talk) 21:00, 18 June 2014 (UTC)

Those are all features that we haven't built yet, but I'll tell you what the current plans are. When you move a page that has an associated Flow board, you'll get the same option on Special:MovePage that you do right now with talk pages -- a checkbox that says "Move associated Flow board".

We're also planning to create the ability to move a discussion thread from one Flow board to another, and possibly to have the same discussion surfaced on multiple Flow boards at once. That's a little bit further down the line.

I'm not sure about your third question -- I'll make sure to include that use case when we work on creating the ability to auto-archive a talk page. Thanks for bringing it up! DannyH (WMF) (talk) 21:12, 18 June 2014 (UTC)

Up, up and away!

Wikipedia talk:Flow/Developer test page, fully collapsed view (well, it happens in all views, this is just by far the fastest to use), scroll down, wait, scroll further down (if you're lucky, this feature is very unpredictable), until you reach "Caption not showing? This topic was deleted by Fram" Click on the three dots (right side of the gray box) to open this or access the options, and hey presto you are back at the top of the page. This is, well, unexpected. Fram (talk) 13:05, 24 June 2014 (UTC)

Similarly (or not?), in collapsed view, I can open all threads until "size issues", but everything below can't be opened when in collapsed view... Oh, and clicking on "older topics" brings me back to the top as well, in any view.

Probably unrelated, but in the thread "Where does the text at the top of the page come from?", I inserted a navbox, Template:Rebbie Jackson. In Flow, this one now gets 31 "show" options. I'm pretty sure these weren't there when I added this some months ago. I readded the template as a new topic, to see whethre it deteriorates as well (perhaps one "show" per new topic on top of it? Hurrah, we have a topic counter!)

I've understood that the further release of Flow has been postponed to at least 2015. This seems for the best. At least the trial at the two semi-dormant Wikiprojects continues to get some green "ticks" on deadline reports... Fram (talk) 13:18, 24 June 2014 (UTC)

And sure enough, when I add a new topic above my navbox template one, the "hide" or "show" on that one gets duplicated. Funny and sad at the same time, this one. Far from ready anyway. Fram (talk) 13:55, 24 June 2014 (UTC)

Thank - bug

The "thank" button does not warn you. Normally you get a "Do you want to thank XYZ for this edit?" Christian75 (talk) 11:39, 26 June 2014 (UTC)

Oh, thank you for pointing it out. We've got a new version coming soon and unfortunately we had to drop the Thanks functionality temporarily; we're planning to add it back in later. On the bright side, that means the problem you're describing won't happen anymore, but I admit that's kind of a "throw the baby out with the bathwater" type situation. DannyH (WMF) (talk) 16:49, 26 June 2014 (UTC)