Wikipedia talk:Flow

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)

Examining contributor's histories

I need to be able to rapidly view things by hovering over the relevant text. If I look at contributors' contributions to Flow enabled pages, I can't do that, I actually have to click on Comment and go to that page. This seems a step backwards and slows me down. Dougweller (talk) 12:27, 6 February 2014 (UTC)

What do you mean? Are we talking about NavigationPopups or something similar? Okeyes (WMF) (talk) 17:05, 6 February 2014 (UTC)

When I hover over a diff I can normally see several lines of the edit. That makes it much easier to check to see if it is vandalism, worth reading, etc. Dougweller (talk) 17:25, 6 February 2014 (UTC)

I'm...pretty sure that's a gadget. Can you check your preferences for NavigationPopups or something similar? If it's not a gadget, it's not mediawiki functionality I've seen in my years on the site (which is always possible). Okeyes (WMF) (talk) 17:33, 6 February 2014 (UTC)

Yes, that is a gadget and not part of the default preferences. --HHill (talk) 08:08, 7 February 2014 (UTC)

Then I will need a gadget. It is a lot quicker being able to few several lines by hovering then having to open the page. Dougweller (talk) 16:28, 16 February 2014 (UTC)

I'm a Navpopups user too. This is on my list of things to follow-up on. Quiddity (WMF) (talk) 01:21, 19 February 2014 (UTC)

Great. Dougweller (talk) 09:57, 19 February 2014 (UTC)

How will we close discussions?

We normally use the 'archive top' and 'archive bottom' markup to close a discussion. How will we do this with FLow? Dougweller (talk) 11:59, 11 February 2014 (UTC)

Something like this, apparently. Partial archiving of discussions doesn't seem to be in scope (closing down tangents, subsections, ...). Fram (talk) 12:57, 11 February 2014 (UTC)

That doesn't seem enough. We need to be able to easily read through a closed discussion (at the moment we can't easily read through any discussions - are there no speed readers on the design team?). And we need it to look more like closed discussions look on normal pages. Dougweller (talk) 17:21, 11 February 2014 (UTC)

Also, sometimes discussions are wrongly closed and someone rightfully reopens them. This needs to be a use case that is supported. — Scott • talk 18:06, 11 February 2014 (UTC)

@Scott Martin: Yup. Being able to reopen a discussion, and to change the summary, is on that trello card's acceptance criteria. Quiddity (WMF) (talk) 21:20, 11 February 2014 (UTC)

@Dougweller: Which aspect(s) is insufficient in the spec, in particular? The "collapsing" ideas (this would act like the click-to-expand Topic Titlebars do), or something else?

Secondly, which of the visual elements of the current 'archive top' system do we find most useful? (So that we can think about how to apply them to the Flow design). Sidenote: There was some discussion about this yesterday in a meeting, and I believe there are newer design mockups coming soon (with clear attribution of the user/time of closing, and other tweaks). Quiddity (WMF) (talk) 21:20, 11 February 2014 (UTC)

I'm now ok with the example I've been shown. Dougweller (talk) 13:52, 12 February 2014 (UTC)

No I'm not. That was not actually a 'discussion', ie not a thread. We need to be able to close long threads, will we be able to do that? We do it all the time with RfCs for instance. Dougweller (talk) 16:26, 16 February 2014 (UTC)

@Dougweller: Please see my 2-part question above, thanks. :) Quiddity (WMF) (talk) 23:52, 18 February 2014 (UTC)

@Quiddity (WMF): I'll need to see an example, but the criteria look good. However it is important that collapsing is just an option, and with for instance an RfC would rarely want to collapse a discussion. I like the way 'archive top' shows the summary/decision and visually makes it clear that the discussion is closed. Dougweller (talk) 09:56, 19 February 2014 (UTC)

I would like the following two acceptance criteria to be added:

• "I can see the content of the closed discussion (i.e. expand it) without re-opening it."
• "I can undo both close(+summary) and re-open actions and go back to previous state." So that we can go back to any previous summary if the topic was re-opened (and possibly closed again) either by mistake or by a vandal.

Klipe (talk) 14:50, 19 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)

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)

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 [2] 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)

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)

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)

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)