Wikipedia talk:Flow

Community engagement strategy

... is up onwiki. We want to be transparent about:

• our plans for the development and deployment process of Flow, and how the community can take part in it
• how we're planning on incorporating community feedback
• specific milestones and goals for the next 3 months

Have a look and see what you think! Maryana (WMF) (talk) 22:17, 3 October 2013 (UTC)

Your first problem is that you commit to treating user comments "with the same weight" as feedback from team members. In general, comments from a user community are considered to be more important than comments from developers.

I'd also like to see you say something that addresses the little problem we have above, where a WMF member committed to a feature, WMF forgot the commitment, and then, upon being reminded, we have WMF staff members commenting that it would be a good idea to experiment with reneging on the commitment. It really should not be surprising to you that people have difficulty taking WMF at their word.—Kww(talk) 22:27, 3 October 2013 (UTC)

In general, comments from a user community are considered to be more important than comments from developers. If all we want is a wishlist of community features, let's just enable Liquidthreads :) But seriously, most community members are not software developers or designers. If you asked a random Wikipedian, I don't think he or she would feel comfortable being responsible for developing a discussion system that will be used by hundreds of thousands of people all over the world – not just the people using Wikipedia today, but current and potential new users for the next 5-to-x years. As the doc mentions, we have different skills distributed among us, and we will need to balance community knowledge with visual and interaction design best-practices, technical feasibility, patterns from other products, research and data analysis, and many other things that the WMF has the staff and resources to do. I'll add a note about that.

As to your second point, clearly somebody needs to make the {{draft}} template much more flashy... perhaps blink/marquee? :) Maryana (WMF) (talk) 23:05, 3 October 2013 (UTC)

I don't think it's practical to say that user feedback should be prioritised above all other concerns, for a couple of reasons.

First: in a lot of situations, we need comments from developers to take priority - comments about what is possible, what is feasible, what is scalable, for example. Second: comments from inside the power user community taking precedent over all other thoughts only makes sense if you posit that features for existing users are the only things we should be building. Now, if you genuinely believe that, I would genuinely advise that you disengage from Flow entirely, because Flow - indeed, most of our features - are not exclusively about making life better for existing users. They're also about making things better for all users, including new ones who don't currently get a voice on conversations like this, and potential users who don't get to participate in any of our things full stop. And existing users (including me!) are not necessarily the best people to decide what "all users" need - we have a vested interest and a vested perspective.

That's why we have people tasked with looking at what is needed overall - not developers, but Product people like Maryana, designers like Brandon or May. Because we need to synthesise all perspectives in this conversation, be they from people who represent the experienced user (us) or people who represent those who don't have a seat at the table yet. If you genuinely believe the WMF's task with software development is to build things exclusively for and dictated by the existing users, like you or me, then we have a fundamental conflict here, because that's not something we're ever going to do. We should have a cooperative relationship, not a master/servant one (in either direction). Okeyes (WMF) (talk) 23:07, 3 October 2013 (UTC)

It was a direct commitment from a staff member. Fixing the draft template has nothing to do with the basic concept of honest communication and viewing commitments as commitments. The only reason given so far for reneging on the commitment has been that Maryana, personally, dislikes the way we are able to edit comments. Why do you think her personal dislike for something should be imposed on each and every version of Wikipedia, as opposed to making it configurable so that each Wikipedia version can set its own policies independent of the WMF?—Kww(talk) 23:15, 3 October 2013 (UTC)

We're not talking about policy, here, we're talking about software; let's be clear. And, no, that's not the reason that's been given - the reason that has been given is that our designers believe it is inconsistent with user expectations and web standards. I want to again underscore that we are not talking about "oh, that thing we said, ignore that thing, here's no-comment-editing ever". What we're saying is that it's trivial to build a system that does, say, no-comment-editing and then switch it over so that it's configurable on a per-wiki basis. Because of that, it costs us almost nothing to experiment - and when we say experiment, we mean "deploy one version to the talkpages of two wikiprojects, in a couple of months, and see what they think, and switch if they really don't like it and can point to tasks it inhibits".

Yes, it was a direct commitment from a staff-member; that staff member was wrong. What you're asking for here is for us to always back up any statement made by any individual staffer, and that's not going to happen (I could say, right here, "I promise wholeheartedly we will experiment", and then his commitment conflicts mine. You see the problem). What I'd rather is that we maintain a consistency of communication from hereonin, and in future projects, and experiment with different variants on comment editing to see if there are useful use cases for allowing different user classes to edit the comments of others. If you want to help convince us that we should allow for comment editing by other users, you should contribute to the list of use cases linked above. Insisting that we as an org commit to anything any one staffer promises is not going to help (and, given the things individual staffers have said you undoubtedly disagree with, probably wouldn't make you happy any more than it would us). Okeyes (WMF) (talk) 23:24, 3 October 2013 (UTC)

I think you'll find that it is not only Maryana who does not want comment editing. I think you'll find that's pretty much a unanimous consensus among Foundation staff, for many, many reasons. So please don't single her out for your frustrations.--Jorm (WMF) (talk) 23:26, 3 October 2013 (UTC)

I agree with you that we should not single people out. But I think at least part of the point was about where WMF staff may be imposing their views on the community, so having other WMF staff agreeing does not address editors disagreeing. I like the way the most recent descriptions of the planned rollout include lots of respectful community consultation. I simply ask that WMF people not go into that consultation having already made up their minds. --Tryptofish (talk) 23:44, 3 October 2013 (UTC)

That's reasonable, and I don't think we have. I can't speak for everyone, mind, just myself, but: I get the impression that while people have preferences (just like volunteer members of the development process have preferences), they're not committed to doing something if the evidence says "this is a terrible idea". That's why we're trying to keep things rather loose and experimental and hunt for that evidence. On my part, at least, I'm kinda..wavery. I don't use comment editing that much myself as a volunteer, and I get the UI argument, but I'm looking at workflows like GAN and talkpage reviews, and the problem of people using incorrect wikimarkup and damaging their comment, and inwardly flinching. Okeyes (WMF) (talk) 23:52, 3 October 2013 (UTC)

The question as to who should be allowed to edit comments under what circumstances is a policy decision, not a technical one. It is something that each community of users could reasonably be expected to come to a different conclusion about. Simply taking it away takes it away from everyone, giving it out carte blanche keeps each community from regulating it. Your point above is well taken: it's trivial to make it configurable. It's your conclusion that's dead wrong: it's not each community's obligation to convince you what you should hardcode the setting to, it's your obligation to provide control of that setting to each community.—Kww(talk) 23:34, 3 October 2013 (UTC)

And again, that principle makes perfect sense if you think the community of long-term editors, such as you or I, can bring every necessary perspective on something with UI and user experience implications to the conversation. If you genuinely believe that, again, I'd advise you to walk away from Flow, because we do not. We believe that we can't succeed with this without experienced users' perspective - otherwise we wouldn't be asking for and including feedback - but we can't succeed exclusively with experienced users' perspective, either. I've already explained we're not taking it away as an option, just noting it as an option rather than a dead certainty. If you want to convince us it should be a dead certainty, add use cases to the document mentioned above. The discussion as it stands now is circular and not a useful way to spend your energy or mine, because we are not shifting from the position that small-scale experimentation is superior to picking the first option that comes along and ignoring others. I'm going to go back to adding the use cases; you're welcome to join me :). Okeyes (WMF) (talk) 23:42, 3 October 2013 (UTC)

I'm flabbergasted. I'm trying to tell you not to decide at all and that it isn't your decision to make, and your response is that you won't "pick the first option" that comes along. Please, don't pick an option. Please, don't make a decision. I'm begging you not to decide this issue. Simply implement the tools that allow people to decide for themselves, and potentially change their minds for themselves. The mindset that you have that I'm objecting to is way above this particular issue of comment editing. It's the mindset that WMF should make decisions about things when decisions don't need to be made. WMF never needs to decide when comments should be editable and by who. If your mindset is that you should make rigid decisions about features when they are easily made configurable, then I beg of you to walk away from Flow. Make decisions only when you absolutely have to: don't hard-code things when you know that there's disagreement.—Kww(talk) 23:54, 3 October 2013 (UTC)

Let's see if I can draw a conclusion from the raw data.

Data point 1: A while back we had a discussion about naming pages "Talk Page", "Discussion", "Comments". "feedback" etc.

Data point 2: It was determined that this would be a configuration option, (which it pretty much has to be for the different language wikis) and thus the WMF doesn't know, doesn't care, and doesn't have to decide what to call it.

Data point 3: This ended the discussion. Go ahead and try to bring it up again and see what happens.

Data point 4: We also had a discussion a discussion about who can edit talk pages.

Data point 5: Some of us were under the impression that this would also be a configuration option, and thus the WMF wouldn't know, wouldn't care, and wouldn't have to decide who can edit comments.

Data point 6: Unlike the case with the names, various people on the WMF side are still talking about it as if they have something to do with making the decision.

Conclusion: The WMF still doesn't "get it". Kww tried to explain it above, but doesn't seem to be getting through despite his explanation being quite understandable.

My opinion: This has the potential of devolving into open warfare with many hard feelings and misunderstandings. I really don't want to see that. --Guy Macon (talk)

Well, no. If you look at the conversation that was part of data points 1-3 (or at least, the bits I remember) you'll see we said that it was per-wiki configurable and so we could discuss it later without having any problems, and that we probably wouldn't care but obviously reserve the right to step in if (somehow) a ludicrous conclusion is reached. So it's somewhat different. More importantly, the fact that it was settled back then is...somewhat secondary, in the sense that it's not a factor; I agree (I can't speak for the team overall) that per-wiki configurations are appropriate. The fact that there was a discussion, pre-proper-discussions-about-Flow, that agrees with me, isn't really a factor.

I agree it has the potential to devolve - this is why I've tried to shift users' attentions to (1) actively contributing to the discussions about comment editing using arguments on the pros and cons of comment editing, rather than what was said by one staffer before the rest of the team was involved, and (2) keeping us honest in future discussions. I can't promise that anything agreed to by any one staffer in the past will be honoured, no. I can promise that, unless there are pretty substantive exigent circumstances (which we would explain and discuss), our statements can be relied on hereonin - and that our statement in this case is not "no comment editing" but instead "let's experiment with different solutions and see what works". Okeyes (WMF) (talk) 04:45, 4 October 2013 (UTC)

But why is WMF doing the experimentation and reserving the right to make the decision for all projects forever? What would be the reasoning for ever making this hardcoded? The issues of voiding previous agreements and expecting us to believe that you won't void agreements again aside, why aren't you simply defaulting to make things like this configurable? The various communities are quite capable of experimenting for themselves.—Kww(talk) 06:04, 4 October 2013 (UTC)

I keep trying to parse these issues, and I keep running into the fact that different WMF people, if not exactly saying different things, certainly have different styles of saying them. I accept that WMF is very interested in "data" about what potential new users – who, by definition, are not commenting here – are going to benefit from. At the same time, experienced users have opinions based upon experience and not upon personal whim, that I hope and expect will be taken seriously during the forthcoming rollout and consultations. I think that the dividing line resides where the "data" might conflict with community consensus. Editors here, not unreasonably, are worried that there will be "data" that appears flawed to us, but WMF will insist that they have evaluated the "data" correctly and are drawing the correct conclusions. WMF reserves the right to draw their own conclusions. The community worries that WMF will draw conclusions that ring false to the community. --Tryptofish (talk) 15:29, 4 October 2013 (UTC)

Kww; because, again, the existing communities do not necessarily have a wide group of voices in the conversation.

Tryptofish; I think that's fair - we all have different comms styles as different people (my last post, sent late at night, has potentially contributed to this problem; I was rather tired. Let me know if you want clarification on any point.)

I think your assessment of the data question and the worries people might have about data from our end is fair - I know Maryana has some thoughts about what we mean about data that she'll hopefully post soon, that heavily biases what we're initially interested in towards the type of qualitative data that existing users are great at providing, so hopefully a lack-of-factoring-in will not be a problem. I obviously can't speak to potential flaws in an unknown pool of future data, except to say that nobody questions data more than I do ;p. Okeyes (WMF) (talk) 17:24, 4 October 2013 (UTC)

To your first question, no, not at all. I feel like your communications on this talk page have been amongst the most helpful, and I thank you for it.

To the second point, let me put it this way. Sometimes, we have RfAs that fall in the discretionary zone, where bureaucrats have discretion to either pass or fail the candidacy, and where editor opinions are strongly divided. One or more crats will close the RfA, and explain how they arrived at their decision. Often, they will state that they gave less weight to some comments, and more weight to others, basing their explanation on policy and community norms. That has the effect of a few arguably privileged individuals, the crats, deciding to agree with some editors and disagree with others, even though those editors on the losing side may have felt very strongly. Similar outcomes happen with closures, typically by administrators, of very contentious RfCs. The community accepts this, even though some community members are disappointed by the outcome. The reason that the community accepts it is that we can see how the decisions are based on agreed-to principles, and we can see that the closers are not simply using their positions of privilege to impose their personal preferences on the community.

That is what you folks at WMF need to strive for. If there are reasons to say that you are discounting the advice of experienced editors because of what you know about the needs of inexperienced editors, you need to convince us that you have good reasons, consistent with community norms, and that you are not just imposing your personal whims upon the rest of us. In discussion with a larger section of the community than what you have on this talk page, you will get acceptance if you succeed at that, and very strong pushback if you fail. --Tryptofish (talk) 17:41, 4 October 2013 (UTC)

That seems both reasonable and rational. I'm not sure if community norms are necessarily what we need to be striving for, insofar as there are going to be differences between "an optimal relationship between editors" and "an optional relationship between developers, designers, researchers, product people and editors", but I agree we need to aim for some kind of normalised set of principles - based, presumably, on movement-wide rather than community-specific values (since the WMF and community both fall under movement, but don't both fall under community). I think that's what Maryana is aiming at with the statement of principles on the Flow page, and with the community engagement principles that follow from it - including the one that states that staffers, too, are required to follow the movement norms. If there are specific things you think could help (eg, "explain why you are discounting things" being called out explicitly rather than implicitly), we can discuss them and factor them in if nobody has a problem, although I'd like to avoid seeing it turn into something the size of Raul's Laws. Okeyes (WMF) (talk) 18:19, 4 October 2013 (UTC)

I certainly hope that this isn't becoming a retread of that tired "power users are taking away things that newbies need because they are just great big meanies and the WMF has to come to the rescue" argument. Options should default to being under community control, and the WMF should eliminate local configurability only in extreme cases.—Kww(talk) 18:01, 4 October 2013 (UTC)

I observed earlier that some WMF staffers have different communication styles than others, and it occurs to me that the same is true of editors. Kww and I just said those things in different ways, but my opinions are fundamentally the same as Kww's. --Tryptofish (talk) 18:07, 4 October 2013 (UTC)

@KWW: I thought we (power users) were generally accused of adding too many options, and thereby overwhelming newbies! (I want more preferences. I love firefox's about:config page, and am frustrated by linux-gnome's current move towards oversimplification.) - Anyway, my take on the issue, is that it will be configurable, by the communities, but the staff are planning a short experiment with a different configuration than the one we asked for, because it might lead to interesting insights. Ie. They want to test some of our assumptions. The same goes for some of the design-choices in the initial versions (with which I disagree personally, but I'm willing to test out different options). When Okeyes says "qualitative data" above, he means direct feedback from us (the community). In the long-run they're definitely not going to force settings on us that don't work.

@Tryptofish: "All people are the same, only their habits differ." (attributed to Confucius) :) Quiddity (WMF) (talk) 18:41, 4 October 2013 (UTC)

--Tryptofish (talk) 21:04, 4 October 2013 (UTC)

Quiddity: bear in mind that I've been publicly accused of selfishly disabling critical software and endangering the stability of Wikimedia servers because I was insensitive to the needs of newbies. The meme that I did so because as a "power user" I'm unable to understand the needs of inexperienced users and that RFCs should be ignored because they don't truly represent the community is one that I'm growing exhausted by, but it has been popular recently.—Kww(talk) 19:06, 4 October 2013 (UTC)

Re: power users adding too many options and thus confusing newbies, we don't allow newbies to see the configuration options that set what each user group can do. (BTW, who does have permission to change those settings? I have never seen that defined.) --Guy Macon (talk) 23:16, 4 October 2013 (UTC)

Kww, I would be a lot happier if you stopped saying "configurable per wiki" when you actually mean "configurable by any local admin" (e.g., by you or any other admin here who believes himself to have local consensus for the change).

"Configurable per wiki" includes "the English Wikipedia and the German Wikipedia can have different settings, but to get any change made, you have to file a bug report and get a dev to implement it". Flagged Revisions—which is turned on there and turned off here—is "configurable per wiki". Although you ignored my direct question about this above, you seem to want "any admin can change the setting any time he feels like it" (I assume that no admin would do so without community support; our admin corps is overall quite good that way).

I've got no objection to that kind of system, but it is far more specific than just "configurable per wiki". You want "configurable by local admins", not merely the possibility of different wikis having different settings. It would reduce confusion if you'd start using the clearer language. WhatamIdoing (talk) 23:21, 5 October 2013 (UTC)

Actually, WhatamIdoing, I'm quite willing to deal with "configurable by bureaucrats" or even "configurable per wiki by devs" so long as WMF commits to honouring RFCs (or similar community processes in other versions of Wikipedia) over how the individual flags should be set. That's generally been how things like this have worked in the past, and, despite the recent conflict, a reasonable model for how things should work in the future. The administrative structure of a Wikipedia version going into open revolt should be a rare occurrence, and the WMF saying "we don't care what the result of your consensus seeking process is: we will inflict this upon you anyway" should be equally rare. What's being said here is that no one will commit to making any mechanism to adjust the behaviour of a setting despite it being fairly obvious that there is no single agreed-upon value for the setting and it being extremely likely that different versions of Wikipedia would, given the choice, select different configurations. I don't understand the rationale behind the present argument that the conditions for "who can edit another editor's comments?" should be fixed, as opposed to configurable, unless the plan is to disable the feature completely.—Kww(talk) 23:41, 5 October 2013 (UTC)

Then perhaps you'd like to try "controlled by each community" as a phrase that might make your concerns clearer. So far as I can tell, it will be configurable per wiki (for essentially technical reasons). This has been expressed as the designed intention, and it has never been contradicted by anyone. The only open question that I can see is who gets to decide what the configuration will be. WhatamIdoing (talk) 23:48, 5 October 2013 (UTC)

WhatamIdoing:They've explicitly repudiated honouring Jorm's commitment to make it configurable on a per-wiki basis. Okeyes's statement it "What we're saying is that it's trivial to build a system that does, say, no-comment-editing and then switch it over so that it's configurable on a per-wiki basis. Because of that, it costs us almost nothing to experiment - and when we say experiment, we mean 'deploy one version to the talkpages of two wikiprojects, in a couple of months, and see what they think, and switch if they really don't like it and can point to tasks it inhibits". That's a pretty explicit statement that they will build a version where the ability to edit comments is not configurable in any fashion and only change it if those particular wikiprojects can persuade Maryana's group that it's a problem. If that's not what Okeyes intended to say, it's not me that requires education in how to communicate more clearly. I do my best to read everything the WMF says carefully and respond only to things that have actually been said. As a corollary, I do sometimes get insistent that people actually say something and make some commitments because of how badly trusting people to make reasonable decisions about VE turned out.—Kww(talk) 00:21, 6 October 2013 (UTC)

You seem to have missed Maryana explicitly saying that wikiprojects refusing to use it would constitute it not being viable. Anyway; at this point we're clearly not having a productive conversation - I would suggest we all split off to more productive things (like; providing pros and cons and use-cases for different levels of indenting, above). Okeyes (WMF) (talk) 16:57, 7 October 2013 (UTC)

I certainly hope that it doesn't have to get to the point of communities refusing to use Flow at all before Maryana will consent to implement obvious and trivial options that allow the tool to be tailored to each community's preferences. That's establishing a "we won't cooperate unless the community goes on strike" model from the beginning, and I think that's what we are all trying to avoid. If the conversation is unproductive, I think it's pretty clear as to why. We are in a situation where everyone agrees the option is trivial to implement, but WMF staff are refusing to commit to implementation without providing any substantive justification for their refusal. And no, "other discussion formats don't permit it" isn't a substantive justification for removing an existing capability.

The capability exists. We've requested it be retained. Everyone has been willing to compromise by putting constraints on it, such as requiring specific user rights. Why does the WMF have to get so confrontational by refusing to commit to implementing it?—Kww(talk) 17:24, 7 October 2013 (UTC)

I read the same comments that Kww read, and came to the same conclusion. Yes, I am hearing some voices say that it will definitely be configurable with the configuration decisions in the hands of the local Wikipedia, but I am also hearing other voices that are implying that they just might make it so that the the only way to get control of the configuration option -- or even to insure that it will exist -- is to completely reject Flow unless it has the option. The problem with that is that if (as seems likely) Flow turns out to be far better than the present system in a hundred ways, it might be very difficult to get consensus for rejecting it over this one issue. Picture someone trying to control a room foll of preschoolers when the only tool they have is a 12 gauge shotgun. What if I really want Tommy to stop stealing Suzie's pencils, but I am not willing to blow his head off over it?

Please note that additional assurances from those at WMF who have already assured us that it will be configurable are of little value. We need assurances from those at WMF who have stated or implied that it might not be. --Guy Macon (talk) 23:16, 7 October 2013 (UTC)

Okay, there seems to be a misunderstanding here; we're not talking about rejecting on a wide scale here. The workflow goes something like this:

1. We produce the prototype version
2. We ask a wikiproject to try Flow, having them play around with the prototype to see what it's like
3. The wikiproject says "are you kidding? Without comment editing? That's not workable for X, Y and Z reasons"
4. We go "okay!" and introduce configurable comment editing.

We're not talking about project-wide consensus on every point, here; we just want to make sure that users have the opportunity, with experimental features or decisions where there are a lot of pros and cons in both directions, to try alternatives before returning to the default. If the alternatives work, great! We've made an improvement. If the alternatives don't, the cost of experimenting (in editor time, in staffer time) is tiny. Okeyes (WMF) (talk) 23:43, 7 October 2013 (UTC)

Gosh, Okeyes, if you want us to try alternatives, why don't you make it configurable so we can try alternatives? It would be interesting to experiment with only allowing admins to edit comments, or allowing only autoconfirmed accounts to edit comments, or only bureaucrats to edit comments, or making it an independent user right granted by community consensus and bestowed by admins. There are numerous configurations we could try. But we can't if you refuse to make it configurable.—Kww(talk) 00:01, 8 October 2013 (UTC)

Why do we need to fix something that works fine already with this? Bwmoll3 (talk) 23:50, 5 October 2013 (UTC)

I think Flow might be a good thing as long as certain critical aspects are met.

1. First, it must be able to use templates. Consider that a requirement in the design phase. If Flow cannot handle templates, then you may as well not even deploy it here and keep it for other Wiki's who don't rely on templates.
2. Next, it really needs to be used on all talk namespaces not just one or two. Its fine to start out testing on one or two, but we absolutely should not maintain multiple talk page platforms on one wiki. Its confusing and pointless. If its not going to work for all talk pages, then don't do it.
3. TEST, TEST, TEST....BEFORE you release. Don't rush it and do the job half-ass like Visual editor. Test it on Wikiproject banners and a variety of templates. Does it work with Twinkle and AWB (I admit theh WMF isn't on the hook to fix these but they should be aware of problems and get the appropriate devs engaged). No more of this gunslinger mentality, we know better than you attitude like we saw in Visual Editor.
4. Absolutely no red or green text boxes.
5. Take community input seriously. We are not as stupid as we seem and can help if you allow us and listen to our input.
6. Be original, we do not need too and should not be copying facebook or some other site. 71.126.152.253 (talk) 23:54, 5 October 2013 (UTC)

Red and green text boxes? And: yeah, we're going to test extensively. If you look at the deployment plan and such you'll see that we're deliberately rolling out on an incredibly small scale to start with (read: two wikiprojects) and incrementally after that. This should allow substantive bugs to be surfaced. Okeyes (WMF) (talk) 16:57, 7 October 2013 (UTC)

I take it you've never done UI design for the color-blind, Okeyes? When I used to design alarm displays, one of the key steps was to ensure that the system state was instantly recognizable for people that could not distinguish green from red. It holds for computer interfaces as well: green or red backgrounds or text tend to make systems difficult to use for a large percentage of males.—Kww(talk) 23:26, 7 October 2013 (UTC)

No, I've never done UI design for the colour-blind - this is because I'm not a UI designer. Instead I listen to the ones we have. I was not asking "what's wrong with colour?" I was asking "what red and green boxes do we have?" Okeyes (WMF) (talk) 23:39, 7 October 2013 (UTC)

I read the IP's comment as providing guidance, Okeyes, so I was explaining it. There were some red/green issues with the Notifications feature, which is probably why he chose to bring it up.—Kww(talk) 23:47, 7 October 2013 (UTC)

That makes sense; thanks. Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

Yes, that is correct and the reason I say test Okeyes is because the WMF has a history of not doing proper testing. The community are not guinea pigs, there should be significant testing before it is thrust upon the community. A lot of the problems with Visual Editor were so blatant and obvious it was easy to tell that testing was an afterthought. I would also be interested in knowing how Flow differs from Liquidthreads. Maybe that has been explained somewhere you could point me too. 71.126.152.253 (talk) 01:55, 8 October 2013 (UTC)

It hasn't to my knowledge, but that sounds like a good thing to go in the FAQ - Quiddity, what do you think? Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

There's a brief mention in the meta FAQ (which is out of date in other places), but I'll work on getting more details added. Quiddity (WMF) (talk) 18:09, 8 October 2013 (UTC)

In case it's been forgotten, other minimal features required for Flow to be usable are:

1. Copy/paste between Wikitext and Flow messages, or between Flow messages. (Adding copy/paste with VE would be helpful, as VE should not be considered acceptable without it, but, that's a matter for another talk page, as copy/paste between VE windows is not yet implemented.)
2. Including arbitrary Wikitext (not restricted to mw:Parsoid) in any Flow message. (Some projects might be able to get by without this, but if it is not intended to put it in eventually, Flow will not be usable on article talk pages or user talk pages.)

Note that it doesn't have to be "native" Flow text, but it has to look the same as if it were on a talk page.

Have you any criteria for selecting WikiProjects which might be interested in Flow? — Arthur Rubin (talk) 02:33, 8 October 2013 (UTC)

Any WikiProject that puts itself forward as a volunteer, will be welcomed! We're just planning on a very limited number at first (see the updated WP:Flow#Roadmap), but aim to add more locations as the bugs and issues are resolved over the following months. We're slowly getting a list of locations that have discussed it and are interested. Quiddity (WMF) (talk) 03:31, 8 October 2013 (UTC)

Copy-paste between wikitext and Flow could be complex; since we're planning on having a wikitext editor for Flow it may not be necessary. I agree that VE copypaste and copypaste within the Flow instance of VE will be required for it to be perfect, but those things are out of our hands to some degree - the VE team has to work on them. Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

If there is a wikitext editor for Flow, which doesn't block normal copy-paste functions of the user's OS, then copy-paste between wikitext and Flow will be available. I didn't necessarily mean that you (WMF) have to provide it. — Arthur Rubin (talk) 10:06, 9 October 2013 (UTC)

Aha, gotcha. That seems totally reasonable - I can't see us blocking the functionality (at least, I hope we don't. I use copy-text-fragment-and-find to match things between read and edit mode.) Okeyes (WMF) (talk) 16:43, 9 October 2013 (UTC)

The use case here is for the convenient incorporation of fragments of text, including advanced markup such as mathematics, from articles into Flow discussions, then from one Flow comment into another, possibly modified, then when agreement is reached, back into articles. This would appear to me such an important aspect of building the encyclopaedia that I find a mere "hope" somewhat lukewarm. Indeed, I had thought that we already had agreement on that case. Perhaps I was misinformed. Spectral sequence (talk) 15:57, 10 October 2013 (UTC)

Yes. Article text must be copyable to discussion posts. That is agreed. (The engineers are currently working on importing many of the templates and extensions that are necessary for things like <math> to work properly in the prototype. Not today, but it will work soon. But {{citation needed}} alone has 88 dependencies, and the import tool didn't appreciate being given the top 500 templates last night, so it's not simple and easy.) Quiddity (WMF) (talk) 19:09, 10 October 2013 (UTC)

I noted that there were three relevant directions for copying text including advanced markup in the use case: article -> Flow; Flow -> Flow; Flow -> article (the logical fourth, article -> article, not being relevant here as not involving Flow). You mentioned just one, article -> Flow, as being agreed. Could you let us know what the decision, if any, is on the other two directions, please? Spectral sequence (talk) 08:41, 11 October 2013 (UTC)

I have provided feedback after my first encounter with Flow here. Please don't plan on releasing this in the the next few months, this is so far removed from a community testable stage that I don't know whether to laugh or cry. If I didn't know better, I would guess that development on this had started one, at most two months ago. If you need to release this, do it on MediaWiki only, where the "ommunity testing" will mostly hinder devs and WMF people and not so much regular editors. But it would be better if you would not bother us with this... thing for the next six months or so, make sure that both Flow and the implementation on Labs are working correctly and as expected (by the devs and WMF), and then ask us to test it (preferably not on Labs with its dreadful privacy strategy, but that's a different discussion). As it stands, the "interactive prototype" simply doesn't work at all. Fram (talk) 14:24, 8 October 2013 (UTC)

Can you provide substantive criticisms please? (of the design, of the functionality...). Note that this is by no means the actual design - it's a placeholder.

If you've read the engagement plan you'll know that the first deployment is planned for a sandboxed Labs instance where it can't impact on anyone, and where users will be invited to test - the second is for two wikiproject talkpages, with both of them opting in to having it enabled and with substantial testing and consultation there in advance. If you haven't read the engagement plan, you might like to :). Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

@Okeyes (WMF): He did give substantive criticism, over at the linked diff! (which I'll reply to momentarily). Have some more coffee ;) Quiddity (WMF) (talk) 21:08, 8 October 2013 (UTC)

Thanks, Quiddity. Okeyes, these two Wikiproject talk pages, I suppose they will be on en-wiki? Any reason why you don't test first on MediaWiki? The roadmap seems to lack an internal testing phase, before the community testing phase, to get at least the technicla bugs removed first. And any reason why yuo are directing people to a poor placeholder instead of posting a "please don't test yet, a first testablke version will be available on date X" text instead? My visit to the Labs was basically a waste of my time. Fram (talk) 07:28, 9 October 2013 (UTC)

Bah, sorry; didn't see that. Consider my comment struck :/.

So, in order; yes, they'll be on enwiki. I think we'll deploy to mediawiki too (I'll find out), and we're going to be doing internal testing along the way (it's part of S Page's duties). These aren't in the engagement plan or release timetable, as you noted - as the author of the former I felt they'd probably not be of interest to most people, and I can't speak to Maryana's thoughts on the latter. But I'll ping her so she can address the questions :). Okeyes (WMF) (talk) 16:59, 9 October 2013 (UTC)

The 0.5 release will be to Labs, which is a Mediawiki environment – hence, a lot of bugs can be caught there. We probably will release to Mediawiki.org as part of this or subsequent releases, but that's not really all that much better than Labs; it's not going to provide us with the kinds of feedback we need to actually make this work on Wikipedia. To answer your second question, we're not actively directing anyone to Labs. The link is there, and anyone who's really interested can check it out. Transparency :) Maryana (WMF) (talk) 17:15, 9 October 2013 (UTC)

Ugh, Labs. Why direct people to a place with such a terrible privacy policy? I have visited a few times now, but am not inclined to test anything there.Why not the TestWiki? And I don't see why using two Wikiproject talk pages here would give so much more feedback than testing it on MediaWiki. Plus, it simply gives a better impression if you show that you have tested it in your own home environment first, MediaWiki of (perhaps even better) Wikimedia Foundation. Any reason why en-wiki is used again instead? Fram (talk) 10:10, 10 October 2013 (UTC)

I would've thought the advantages of trialling it here would be obvious; people use wikiproject talkpages. When we say testing we don't just mean "making sure it's not broken" (that's obviously of primary importance, but I'd hope a lot of those bugs would be found before any on-wiki deployment) we mean "making sure it does what people need it to". If we throw it out on mediawiki.org and invite people to test there then, ignoring the problems with an increased barrier to participating there, people will be testing for bugs. People won't be testing for "does it support X workflow based around Y template" (or if they are, won't have any luck) because mediawiki.org doesn't have, in this case, templates. It also doesn't have newcomers or message delivery or all of the other things we'll encounter if we deploy the software on a wiki people actually use. If your interest here is finding things that are bugs under the strictest sense of the word, that's great and I hope we can do it through the Labs instance and mw.org, but when it comes to on-wiki releases we're looking to find gaps in used functionality as much as actively broken things. Okeyes (WMF) (talk) 16:15, 10 October 2013 (UTC)

I agree with Fram here. If your going to start developing this use the lessons learned and base code from Liquid threads version 3. In fact what is the difference between Flow and Liquid Threads besides Flow being led by Jorm and Flow being a massive step in the wrong direction? 71.126.152.253 (talk) 16:37, 8 October 2013 (UTC)

I don't respond to questions phrased in bad faith; please refer to our engagement guidelines. Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

Dodging the questions isn't a good way to get off to a good start with the community. That was one of the problems with the Visual Editor implementation. 71.126.152.253 (talk) 20:38, 8 October 2013 (UTC)

I wouldn't have answered you either. You are clearly looking for a fight and Okeyes (WMF) was entirely correct to refuse to knock the chip off your shoulder. Try rephrasing your question to reflect the blindingly obvious truth that we are all in this together and we all want to do what is best but have some disagreements to work out concerning what exactly is best. Putting "(WMF)" after your name does not mean that you have to be a doormat or a punching bag. --Guy Macon (talk) 21:14, 8 October 2013 (UTC)

For what its worth you all are reading more into the comment than what it was intended. Its a simple question that IMO deserves an answer. The WMF stopped development on Liquid threadss because no one liked it. Now they are doing the exact same thing but calling it Flow. I have asked the question three times what the difference is besides who is leading it and have yet to get a response. So at this point I am going to infer that there is no difference, its just a name change for the same project. As it stands now the Flow implementation is going to be another Visual Editor bomb. 71.126.152.253 (talk) 22:08, 8 October 2013 (UTC)

No. In your opinion they are "doing the exact same thing but calling it Flow". In your opinion Flow is "a massive step in the wrong direction". You are entitled to your own opinion, but you are not entitled to your own facts. And you are not entitled to a response to your loaded questions. I have an opinion as well, based upon what I have seen and read so far and on many years of managing large and small software projects, several of which used Agile. My opinion is that WMF is basically on the right track. Yes, I disagree with some things -- but that doesn't mean that I am right. Yes, we do need better communication, but you are not helping. If you continue trying to start a fight, I am simply going to ignore you and advise others to do likewise. --Guy Macon (talk) 00:43, 9 October 2013 (UTC)

First, I have already stated on a couple other forums that Flow might be a good thing..if its done right. I didn't even have a problem with Liquidthreads other than a couple of things that could have been easily worked out. What I am saying, is that if these 2 software platforms aren't that different, which it appears is the case, then they shouldn't reinvent the wheel. They should look at the comments made by the community on it and build out from there. You keep inferring conflict where there is none. I a simply trying to get the WMF to answer one simple question and they aren't willing to do that. Stop making me into the bad guy for asking a simple question. The WMF has a long and clear track record of telling the community they want our input and they are going to do better next time and then when next time comes along they just ignore it. Indications are they will do the same thing here and you are not helping Guy Macon. 71.126.152.253 (talk) 01:13, 9 October 2013 (UTC)

Anon: Two of the developers who worked on Liquidthreads, werdna and jorm, are working on Flow, so yup, they're well aware of the problems that LQT ran into, and will be able to avoid many known problems. I won't speculate on whether they're reusing code. (Afaik developers reuse code constantly, and reinvent the wheel constantly. That's how they work from school till death!)

I hope we can all agree that Flow might be a good thing if it's done right! And work together (slowly, patiently, calmly, with a dusting of friendliness because we're all err-full humans) to make that happen, over the next 6-24 months. I do appreciate Guy's attempt to communicate, that the way some editors have been phrasing things occasionally comes across as quite combative - I keep looking at this talkpage and thinking of the Monty Python sketch about the man looking for an argument! Also, note that we're a separate group of people from every other team at the WMF, and will probably make completely different mistakes than those other people did... By which I mean: writing things like "the WMF has a long and clear track record" is inherently problematic, because the WMF is made of people - people can make decisions/mistakes, and teams of people can make decisions/mistakes, but beyond that the generalization is flawed.

This place has been my dysfunctional family of choice, for almost 8 years. I want to help improve it, and to get more of my intelligent acquaintances involved with Wikimedia projects. I love (because I'm used to?) the way the interface all works currently (with all the scripts and gadgets I use), but I'm hoping we can collectively (continue to) improve hundreds of aspects. </ramble> I hope that answers the questions, and resolves this tangent/thread. Quiddity (WMF) (talk) 23:09, 9 October 2013 (UTC)

Speaking as someone who has actually used LiquidThreads, it would be interesting to know what were the lessons learnt from that project and how they have been incorporated into the design of Flow. Spectral sequence (talk) 15:52, 10 October 2013 (UTC)

That's a very interesting question. From the conversations we've had internally I think there are substantive differences, both architecturally and in a user-facing way, but I'll let Jorm (ping!) chip in with his thoughts, as someone involved in both to some degree. Okeyes (WMF) (talk) 16:17, 10 October 2013 (UTC)

The subsection at Wikipedia:Flow/FAQ#Why not use LiquidThreads? (written by Jorm) has just been added. (Note that the rest of the FAQ is still outdated, per the note at the top). Quiddity (WMF) (talk) 07:21, 12 October 2013 (UTC)

A comment on engagement

Please when engaging with the user community could we all engage with the comments that have actually been made rather than replying to some exaggerated version. For example:

• Comment: "In general, comments from a user community are considered to be more important than comments from developers."
  • Response 1: most community members are not software developers or designers
  • Response 2: I don't think it's practical to say that user feedback should be prioritised above all other concerns
  • Response 3: comments from inside the power user community taking precedent over all other thoughts only makes sense if ...

None of these seem to address the comment as actually made. Could we agree not to do this in future? Spectral sequence (talk) 16:25, 10 October 2013 (UTC)

Speaking for myself: I try to answer everything as clearly and thoroughly as I can, without making TL;DR posts, and without spending excessive amounts of time phrasing things absolutely perfectly. I do struggle with phrasing, as there are so many word choices and combinations, and especially in a written context the tone or desired-intonation/emphasis is very hard to get across in an guaranteed way. I try not to misinterpret a statement/question, but often do. I try not write statements/questions/answers that over-generalize or over-simplify or could be understood in a different way than I intended, but often do. If someone asks a question and demands a black/white answer, but the reality is a spectrum of greys, then I'll try to explain that. If it were possible to have communication that was error-free, the human part of the planet might be a lot more peaceful.

In regards to the comment in question: Yes, the people who use the software are clearly the most important voices, in many many aspects. But an individual community member doesn't get a blunt veto card - for every aspect of the product, from database design to color choice, no matter what the developers or designers suggest - simply by being a community member - that's what the "Comment" seems to potentially imply (to me, depending on how I interpret the very short sentence), and what I guess the "Responses" were trying to address. TL;DR: The more provokingly/argumentatively a question is phrased, the more defensively-phrased the answer is likely to be! So yes, we can agree to all be as clear as we can, and to understand that misunderstandings can/do/will occur given the limitations of humans communicating via snippets of text. Quiddity (WMF) (talk) 19:08, 10 October 2013 (UTC)

Another ground-rule for discussion I would propose is, please don't answer a question with a question. For example, the following exchange is not helpful.

Is there pre-existing research and development to build on?

Into things like what the workflows are, or what capabilities the workflow system will need?

Spectral sequence (talk) 18:40, 14 October 2013 (UTC)

I'd say here you are being too hard on them. If they do not understand the question, there is nothing wrong with asking for clarification.

Anyway, perhaps the worst thing about communication from WMF side is much harder to define. It is the slight - but almost constant - belittling of the opposing side, coupled with self-righteous outbursts when opponents do not show them the respect they seem to expect. I am sure they do not even notice that (unfortunately, such level of social competence is rare). That is not going to be changed by any "ground rules"... It's the question of attitude: WMF representatives seem to be acting as if they were masters of Community members or (when they feel generous) their equals, while in fact they are supposed to be their servants... --Martynas Patasius (talk) 19:29, 14 October 2013 (UTC)

And there you're wrong, and this may be why you seem to have difficulty communicating. Let me disabuse you of a notion: We are not your servants and never have been. --Jorm (WMF) (talk) 01:09, 15 October 2013 (UTC)

I would have supported this response by Jorm (WMF) if he had confined himself to answering the point about "servants". However, the gratuitous "why you seem to have difficulty communicating" is a good example of what Martynas Patasius describes as "belittling": it is a personal comment which does not help to take the discussion forward, and I for one have no difficulty in understanding MP's comments, even though I do not necessarily agree with them. And in this case I believe there is some validity to MP's point about attitude: I have already stated elsewhere that on occasions I have found WMF staff too ready to argue down points made by users rather than discuss them. Spectral sequence (talk) 06:43, 15 October 2013 (UTC)

I disagree. This part is true: nobody at WMF is my master or servant, but rather is a respected partner in a cooperative relationship. What I disagree with is taking Jorm to task over a rather mild expression of opinion while completely ignoring far worse from our side. Joining WMF does not imply that you are a doormat or a punching bag. Also, as a working engineer I know that there is one truth that will never change; you can have diplomatic and inoffensive communications or you can have developers be part of the conversation, but you cannot have both. Please try to cut those of us with technical skills a bit of slack; we try, but sometimes we are a bit blunt. --Guy Macon (talk) 07:00, 15 October 2013 (UTC)

I hope we all agree that all the conversations between WMF staffers and editors should be on the basis of a common standard of collegiality and collaboration. I am surprised by the "truth" enunciated here: it is simply not the case that developers and working engineers are incapable of collegial and constructive discussions, and as I say I think we all agree that everyone should be held to the same standards. Being blunt is not the same as being personally offensive, and the former is not an excuse for the latter. Spectral sequence (talk) 16:36, 15 October 2013 (UTC)

Well, there is a sense in which WMF is supposed to serve Community and not vice versa (just in case, I will clarify that I did not mean any kind of "personal" masters and servants). As the mission statement of WMF (m:Mission, [1]) states: "The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally. In collaboration with a network of chapters, the Foundation provides the essential infrastructure and an organizational framework for the support and development of multilingual wiki projects and other endeavors which serve this mission. The Foundation will make and keep useful information from its projects available on the Internet free of charge, in perpetuity.". In "scholastic-speak", the final cause of WMF would be to make it possible for the community of Wikipedia (and not just Wikipedia) to function. But that is not symmetric: the final cause of the Community is to build the encyclopedia, not to help WMF do something.

So, WMF is providing services to the Community. And in that sense they do serve it (there is nothing demeaning in being a servant; a title of Pope is Servus servorum Dei - "servant of servants of God"). For example, WMF is developing software for the Community, not vice versa. And thus we have another non-symmetric relationship: programmer - customer. And while The customer is always right might be a hyperbole, WMF seems to act according to "The service provider is always right" a little too often...

Thus, sure, there is a sense in which we all can be (and should be) equal partners. But that is not the complete story, and WMF would do well to pay a little more attention to the other part...

Also, I concur that "blunt" is not supposed to be synonymous with "unnecessarily insulting"...

P.S. Did you notice that I am using the same post to answer more than one post..? Will it be possible in "Flow" without workarounds..? --Martynas Patasius (talk) 21:39, 15 October 2013 (UTC)

I'm just going to leave this here... :) --Guy Macon (talk) 08:17, 16 October 2013 (UTC)

back to the original topic; I'm sorry if answering questions with questions is unwanted; I was trying to ascertain what precisely you wanted me to answer :). I'm happy to do a sort of...brain dump, of everything I know about a specific topic, in reply to a question about it that I find ambiguous, but that seems like it would be less productive than trying to get the language we're all using to line up so we can answer the questions as asked. For what it's worth, the engineers on the Flow team are sort of...disturbingly chill and calm about everything, but I think Guy is right that there are different standards of communication and interaction in engineering and non-engineering environments (that's probably a different conversation, however, and one only tangentially related to Flow). Okeyes (WMF) (talk) 17:51, 15 October 2013 (UTC)

Planning the communications

The Community engagement plan seems heavier on what you're going to do than what you're going to say (the comms part is really about groundrules). Do you have a plan for the messages you're going to put out, and when and how you propose to put them out to the various communities? For example, it was only by some fairly heavy engagement on this page that I realised just how ambitious the plan was in terms of capturing and codifying the workflows and discussion structures. I haven't really seen anything about that in the wider communications so far. It seems to me that that is a message you need to be getting out now to prepare the various communities for all the work you're going to ask them to do. And you must not underestimate just how much uphill work you have on the comms front right now. Spectral sequence (talk) 20:52, 15 October 2013 (UTC)

Re: Messaging: Slow and steady to begin. We need more basic functionality in place before we can start inviting hundreds of people to comment. We also need to work out how to structure and/or summarize the information that is needed to understand the "whole picture", in a way that appeals (as in, is not an offputting TLDR wall of details) to the most number of editors (so many different archetypes and demographics to communicate with!). (When I first learned about Flow, I skimmed through all the links in/from the navigation box. Hence mw:Flow Portal/Use cases was one of the first things I encountered, which gave me a good understanding of the scope. But not everyone works like that...). So yes, wider and wider notices and requests will be sent forth, but in a gradual buildup. Quiddity (WMF) (talk) 22:12, 15 October 2013 (UTC)

Too much chrome

I have problems with the default theme, it's too noisy and heavy (assuming this is the look you're planning to release), despite the steps taken to make it subtle. Can you assign your visual designer to iterate the design and make a lighter theme that removes all the distractions? Making a control light grey isn't enough to give it less visual weight (specially when it's a bold solid box covering the screen from side to side), it only makes it harder to read. The stripped bars effect is distracting, as it produces too much vertical rhythm and movement.

Please, take advice from Edward Tufte and remove every pixel that doesn't convey useful information. The bar to match is the current mediawiki Talk page - with its Vector default theme, which is extremely minimalist (and also what editors are accustomed to look at, for years). The Article Feedback Tool is better in that regard, as its uses a small grey line to identify each editor and separate one post from the next. For Flow, maybe a small grey line to the left of each post would be enough to signal indentation.

I think aligning comments text to the left and action controls to the right (including the balloon and the huge and too much repeated "click to reply") would also help to make the conversation easier to read. The focus of the design should be the content (even if you are proud of the dynamic controls and interaction, they should be receded - interaction is secondary to the main task, which is just reading). Diego (talk) 17:21, 8 October 2013 (UTC)

Uh? Have you recently changed the style? The Sandbox has now a different look than the one it had in my browser a few minutes ago. The new one still has too big Reply and Thanks buttons and the text has been made light grey and harder to read, but at least it doesn't have the huge distracting bars for each comment (only for each topic). Diego (talk) 17:38, 8 October 2013 (UTC)

The code (including the design) on that site is changing constantly (sometimes daily, sometimes more), as code changes are made. It will not be stable for a while yet (and will continue to change as we give feedback). I've given some FAQ type questions to the design team, and will put those up when they've answered them. I'll also pass along / point at your comments. Quiddity (WMF) (talk) 17:47, 8 October 2013 (UTC)

Thanks Quiddity :). I think the dynamic controls are likely to be mouseover or click-activated for the desktop view, which should help. Okeyes (WMF) (talk) 19:02, 8 October 2013 (UTC)

Ok! The Wikipedia:Flow/Design FAQ (initial questions that I threw at the design team) has been answered.

I'm hoping we can split the feedback into 2 parts, with Design comments/collaborations at Wikipedia talk:Flow/Design FAQ, and discussion about How Flow Works (functionality/features) on this page. There will inevitably be some overlap, and some people will continue to mix the two topics in a large post of feedback, but it's a start.

[Mixing the discussion of form and function, are what made many of past "redesigns" I've been involved with (eg the Main Page in 2005, and attempts in 2008/2011), drastically more complicated than they should've been.]

Emphatic reminder: The current prototype is not even close to complete! There is a cohesive design growing in there, but it's not visible yet. Feedback on anything is welcome anytime, but we know there are oodles of things that are missing/broken at the moment. Once a more complete design is available (and can be tested out properly), will be a better time to start giving detailed feedback. (I have no guesstimate when that will be, but will enthusiastically let everyone know!) Quiddity (WMF) (talk) 23:49, 10 October 2013 (UTC)

Who speaks for the WMF?

The WMF has decided to implement Flow but has stated that it needs the help of the community to do so. Some weeks ago I pointed out that this put members of the community under the necessity of assessing their position in terms of the amount of effort they were prepared to continue to invest in helping to develop and implement VE and Flow effectively and continuing to contribute content during the transition. At that time I was quite clear that members of the community could and should be involved in design decisions early, and that there were members of the community willing to involve themselves. The response I got from various members of WMF staff was such that I for one found no difficulty in deciding what the level of my own personal contributions should be for the next few months.

I now see that there is a "legacy of previous comms issues", that "statements made back then about what Flow will or will not have as a feature should not be relied on", that a statement "was a direct commitment from a staff-member; that staff member was wrong". This situation is frankly inadequate for the task of designing and testing a complex and inter-related set of software systems. I would earnestly suggest the following:

• WMF state exactly who is authorised to make decide, and report decisions, about design and implementation;
• WMF state exactly who is authorised to make statements about the technical aspects such as feasibility;
• WMF staff not on those list do not make statements that could reasonably be interpreted as being made on behalf of WMF;
• WMF staff expressing non-official or personal opinions do so from person accounts;
• Users do not take unauthorised statements as anything other than personal and do not attempt to hold WMF to them or complain if they are not acted on.

Spectral sequence (talk) 15:33, 10 October 2013 (UTC)

It sounds like you might benefit from checking out our team roles and responsibilities :) Here's the breakdown:

The Flow team operates on consensus. We are a large, cross-functional team of engineers, designers, product analysts, and community liaisons – and everyone has a say in decision-making. I'm the product owner on the team, which makes me sort of like the closing admin/uninvolved user. Everybody (and that includes anybody from the community) is encouraged to take part in discussions on Flow development and design, even if they disagree with me or others on the team (and I don't want to discourage that at all, not even onwiki), but no official decision has been made until I close the discussion. Maryana (WMF) (talk) 17:22, 10 October 2013 (UTC)

It is not about how WMF makes its decisions internally, it is about how it conveys them to the community, and how it deals with the areas in which no decision has yet been made. Do you regard it as acceptable that a member of WMF staff can make a statement to the community here which appears to be a commitment but which is then revoked with the comment "that staff member was wrong"? I do not. Spectral sequence (talk) 21:25, 10 October 2013 (UTC)

Changing a !vote

A common style of discussion which we see, for example in !votes such as RFC, RFA, AFD, runs like this (a typical RFA exchange)

• Delete as not notable. A.B

followed by an indented response

I have added three independent sources. M.N.

followed by a response

OK, I'm convinced, changing to Keep. A.B.

followed by striking the original comment to

• Delete Keep changed my mind A.B.

The resulting discussion looks like this

• Delete Keep changed my mind A.B.

I have added three independent sources. M.N.

OK, I'm convinced, changing to Keep. A.B.

It's well understood how to read such an exchange. Will Flow be able to cope with this particular case? Spectral sequence (talk) 16:35, 10 October 2013 (UTC)

This doesn't exactly fall under the scope of the first release (WikiProject talk), since that's not a place where AfD or RfA discussions are held (there may be cases of RfCs held on WikiProject discussion spaces, but I've never actually seen one). When we get to building for those discussion spaces, we'll definitely think specifically about how to support !votes, straw polls, and other decision-making processes with Flow. Right now, we're focused only on the peer-to-peer content discussion side of things.

But if you're just asking whether Flow will support things like editing your own posts, bolding, and strikethrough, the answer is yes :) Maryana (WMF) (talk) 17:31, 10 October 2013 (UTC)

I think it rather likely that decision-making processes are taking place at WikiProject pages and Flow will need to support them from the outset. It would be useful to start the process of collecting those requirements as soon as possible. The usecase I describe, one of many, at the workflow level is to be able to change one's !vote in a structured discussion in some way which makes it obvious to the reader what has happened and easy to read the current state of the discussion: a convenient way of instantiating that sort of process is to edit one's own comments, as is the current convention, but this need not be the only way, and I am trying to articulate requirements not solutions. Thank you for the assurance that the usual formatting will continue to be possible: that was not my concern. Spectral sequence (talk) 21:43, 10 October 2013 (UTC)

In a structured system, there isn't a need to edit your own comment to change your !vote. A structured system would store the value separate from the comment (if any) and you'd only need to modify the value of a pull down. No editing of wikitext necessary. Indeed, I think the idea of running !votes through wikitext is archaic.--Jorm (WMF) (talk) 21:47, 10 October 2013 (UTC)

Maybe so, but there is a need to make the history of the discussion clear. To take a more generalised example, it happens quite commonly in free-form discussions that a contributor makes a trivial mistake, for example, gets a URL wrong, and wants to correct it. Simply changing it silently, or with a <small> comment at the end, is quite unexceptionable. However, difficulties start to multiply when the error is meaning-changing. If I wrote that your comment was "good" and then realised that I should have written "goo", or the other way round, it would be courteous to people who might have read it to explicitly acknowledge the change. The current idiom for this is the strikethrough. An even harder case arises when another contributor has replied to the first version of the comment. If I write that your idea is "goo", and someone else writes "I agree with that" and then I go back and change "goo" to "good", I have materially altered the meaning of the other user's comment without actually touching it. In this case it is imperative that the system either prevent my doing that, or make it clear by an visible warning. For example, one might suggest that it a comment has been specifically replied to, it cannot be changed, or, better, that every dependent reply has a line added saying "This is a reply to an earlier version of the the previous comment dated foo and which may be seen at permlink bar" Spectral sequence (talk) 06:47, 11 October 2013 (UTC)

Minimum requirements for Flow

Will there be minimum requirements for browsers, operating systems or machine specifications needed to run Flow? This is clearly related to, but seems a different question to, the corresponding question about VE. Spectral sequence (talk) 16:40, 10 October 2013 (UTC)

We've discussed them briefly internally, and the need to cope with things like a lack of javascript: obviously since we'll support both VE and wikitext we'll have the option to support non-JS browsers for the main functions of a discussion system (although it may be pretty ugly). In terms of specific browsers, we haven't set those down in stone yet, although it's a conversation I've been encouraging us to have. MW as a whole doesn't have a coherent browser matrix anyway - also a conversation we need to have. I appreciate it's not the ideal answer, but it's the one I've got :/. Okeyes (WMF) (talk) 17:00, 10 October 2013 (UTC)

You'll need to support all browsers and OS and whatever though, if you want to follow your Wikipedia:Flow/FAQ: "New users will be automatically be given Flow"[sic]. It is not clear, after reading this and the above discussions, whether Flow will be implemented on a page by page base, or on a user by user base. The FAQ suggests the latter, but everything else (and logoc) suggests the former. According to the FAQ, "existing users will have to choose to upgrade.", but how one will be able to participate at e.g. WT:MILHIST without "upgrading" is unclear, and whether once someone has "upgraded" he will still be able to participate in "downgraded" old school discussions is equally unclear if one believes the FAQ. In reality, it seems to me that no one will have the possibility to opt-in or opt-out wrt using Flow, people will (at most) have the possibility to decide whether page X or Y uses Flow. Perhaps this is what the FAQ tries to convey, but it fails rather badly... Fram (talk) 19:57, 10 October 2013 (UTC)

Fram, I just updated the FAQ with a huge "this is out of date! please stand by" header, because it hasn't changed substantially since it was created 6 months ago, and our thinking about the first release has shifted pretty drastically in the last few months. Please consider WP:Flow/MVP and the roadmap on the Flow main page the definitive documentation for now; we'll be working to gut and update the FAQ in the next few weeks. Maryana (WMF) (talk) 20:10, 10 October 2013 (UTC)

Thanks. I had also started a thread about the FAQ at MediaWiki, perhaps you can make the same comment there (if you already did, please ignore this of course). Fram (talk) 20:13, 10 October 2013 (UTC)

Accessibility is not an option, so it would be a good idea to start off with a minimal list of browsers that must be supported if only to include those that are required for users with various accessibility needs. Spectral sequence (talk) 07:10, 11 October 2013 (UTC)

Thinking about this, never mind what the FAQ says; if you change a few Wikiproject talk pages to Flow, then Flow has to support every slightly popular browser version / OS version / device / ... combination, or your attempt to reach more people will backfire when people who are now technically able to use talk pages will be excluded from discussing things for purely technical reasons. With VE, people could choose at every page whether they wanted to use VE or wikitext; but "once you go Flow, it's the end of the show" for them... This is one of the reasons why "testing" this on "live" pages on short notice is a bad idea IMO. You need to know quite well that these things are supported before thinking of bringing it here. Fram (talk) 12:01, 11 October 2013 (UTC)

I think that might be mixing up a different aspect. There's the question of browser-support for the fully-featured javascript Flow, and then there's the separate (and not much discussed yet) question of browser-support for the "other version" which ought to be as all-encompassing as the current system is. I'm not sure what the timeline is for the other version, but I assume it's what folks like Graham87 will use - he's one of my favourite characters around here, so I'll be constantly checking and prodding at all that. I've also got a (very) short list of editors who don't use javascript, who I'll be asking for specific feedback when it's ready for that. (If you, or anyone, knows of other editors with special setups, or needs, let me know. I started a thread for folks with vision impairment, and would appreciate assistance finding other specific editors/groups that need to be kept in mind.) Quiddity (WMF) (talk) 07:06, 12 October 2013 (UTC)

<Sigh>

This edit is problematic. The edit summary essentially accuses anyone who does not believe that the current talk page is a barrier as being directly opposed to the principles of the movement. It is an unnecessarily confrontational, and inappropriately conflates agreement with WMF principles and the development of this specific software. I am very disappointed, and I hope that there will be a refocusing of the message that the WMF wants to send out; it would be a shame to see a repeat of the messaging faux pas that have led to the widescale deprecation of VisualEditor across major WMF projects to happen with another new idea. Please reconsider the manner and the words which are used to communicate things. Bottom line, not immediately jumping up in support of Flow has absolutely nothing to do with whether or not one subscribes to the WMF principles. Risker (talk) 18:07, 10 October 2013 (UTC)

Ah; no, it doesn't; the preceding edit removed a quotation from the movement principles. That's what that was a reference to. Okeyes (WMF) (talk) 18:17, 10 October 2013 (UTC)

See now. This is what I mean. That is not all you reverted, as you are well aware. Now, stand back and pretend that you're reading that same sentence on the website of some other organization. Is that really, truly, the message that the WMF wants to convey? That people who question the assertions made (i.e., that Flow is the solution to a crippling communication problem) are actually opposed to WMF principles? That's what your summary reflects. It doesn't much matter what the heck you're reverting. Perhaps some thinking about the way the actual text is written would be useful, as it too suggests "if you don't agree with us, we're not interested in talking to you", but that is secondary to your own edit summary. Now, perhaps your edit summary is entirely on message, and it really is the philosophy of this particular product team that anyone who disagrees with their vision should be isolated, ostracized and ignored. I don't think that's the case; I think it's just a case of borderline product marketing that gives the impression of being written for a target market that isn't paying attention, but is being read by a market that assumes it's not the target. Risker (talk) 18:40, 10 October 2013 (UTC)

Here's the jist of what I want to get across in the community engagement doc and the Flow main page blurb:

1. We're building a structured discussion system for Wikipedia.
2. If you think Wikipedia doesn't need a structured discussion system and the current implementation of talk pages is just fine, you're still welcome to give us feedback/criticism. But if your only feedback/criticism is that Flow is terrible, talk pages are great, and we should stop this project and go home, that's not advice we're going to take – we want to make that clear once, so we don't have to respond to it with a justification for why we're doing what we're doing every subsequent time.
3. If you do think Wikipedia needs a structured discussion system, whether or not you believe the direction we're taking with Flow is a good one, you're on the team. Welcome :) We're listening – please help us understand how we can do a better job of making Flow into a discussion system that's ideal for you and every other Wikipedia user, current and future.

I appreciate that there are levels of nuance that these bullet points don't cover and still a lot of outstanding ambiguity – the point of that doc was to try to work those out, so I suppose this discussion indicates that we've hit one wall right here :) Risker, I have absolutely no intention of giving off the impression that "anyone who disagrees with their vision should be isolated, ostracized and ignored." Where are you getting that impression from, and how can the messaging be changed to make sure nobody could possibly interpret it that way? Maryana (WMF) (talk) 19:21, 10 October 2013 (UTC)

Not wanting to speak for Risker, but I am getting that impression from things like "if your position is that the movement principles aren't something you want to follow, and that improved software won't help discussions, you're not going to be able to participate effectively" as a reply to an edit that made a text shorter, easier to understand, without losing any actual value for the reader. And the section is labeled "How can I help?", but the text is "Why do we do this?". The sentence I removed had "zero" value on "How can I help?"Fram (talk) 19:43, 10 October 2013 (UTC)

Okeyes, If you're not with us, you're against us? The sentence I removed was completely superfluous. Nothing of value was lost by removing that sentence. The whole section should be rewritten actually, "How can I help?" should contain something concrete, not a rehash of the WMF principles, as if the current situation doesn't follow these principles or that Flow is the only solution, and more importantly that reading those two things are in any helpful for someone looking for "How can I help"? These two quotes belong in "Why do we do this", not "How can I help".

You claim "if your position is that the movement principles aren't something you want to follow, and that improved software won't help discussions, you're not going to be able to participate effectively". Please don't use confrontational, divisive and incorrect edit summaries. My position is that so far, Flow isn't improved software. I can believe that improved software will help discussions and at the same time not support Flow, or aspects of Flow, or the current proposed version of Flow. I can perfectly follow and support the movement's principles and oppose Flow. I can also be completely neutral about Flow and just wanting to help with testing, and make up my mind after I have actually tested it. Apparently this isn't allowed in your world. Please, next time, use some less aggressive and more helpful edit summaries if you feel the need to reverse an edit, or better yet, don't reverse without thinking about it. Fram (talk) 19:43, 10 October 2013 (UTC)

@Fram and Risker: I'm not going to single out an editor or diff, but there have been a few comments here and elsewhere along the lines of "I hate this entire idea, the talkpages are fine the way they and should not be changed a single bit, you should stop working on this software immediately". There have been some assumptions of bad faith, and personalized attacks. There have also been comments along the lines of "I don't want more of the seething masses to join Wikimedia, if they're not smart enough to learn wikimarkup and current talkpage conventions, then they don't belong here". That is what the Wikipedia:Flow/Community engagement document is about, and is (I assume) what Okeyes meant by not following the "movement principles". (See also Maryana's reply above, for additional perspective on that).

We (staff and community) want active discussion/suggestions/criticisms/comments (but slowly/calmly/patiently and with AGF in all directions). We (staff and community) don't want needless hostility, or unresolvable arguments. I think everyone active on this page right now agrees with all that, so we're just arguing with phrasing. Phrasing will never be perfect (See my reply to Spectral Sequence above, for a ramble on that point), but if you can retain that broad intent, with some tweaks to the word-order/word-choice, then go for it. Quiddity (WMF) (talk) 20:10, 10 October 2013 (UTC)

"There have been some assumptions of bad faith, and personalized attacks." That's basically the problem I (and it seems Risker) have with Okeyes revert (and especially the edit summary, the revert in itself is not the problem). The section is "How can I help?" Please put yourself in the position of an editor (newbie or not), not too well versed in WMF matters, who has heard about this new discussion system and truly wants to help. From that perspective, read the section. Only the very last line, "See our community engagement strategy to learn more.", has actually anything to do with the section; the rest is, well, promo talk. It may be included in its own section if you (WMF) think it is necessary ("Why do we do this?"), but it is completely misplaced as it stands now. I tried, with a minimal action to make it a little bit less top-heavy and a bit more truly open and without requirements. "You have the power to shape the development process of Flow." is short, simple, and true, without the "ifs" that were included before. There should be no "ifs" in an invitation for people to help discuss, test, shape this. If you are welcome to edit here, then you are welcome to join the discussion. That was what my edit tried to promote. Fram (talk) 20:21, 10 October 2013 (UTC)

@Fram: most of that is fair; as Maryana says above, some nuance gets lost. However, I would suggest that writing that off as 'promotalk' is similarly confrontational as an edit summary. I'm going to do better with mine (or, as better as 255 characters will allow!) but it's a two-way street. Okeyes (WMF) (talk) 20:16, 10 October 2013 (UTC)

So basically what I am getting from Maryana and Okeyes comments are that Flow is coming and we can either choose to get on board or get out of the way. Not a great way to garner the support of the community IMO. So basically we have another Visual Editor fiasco in the making. The WMF builds something half ass, releases it early, we complain, they ignore us and the cycle continues. There is absolutetely nothing in this that is anything new. And I am saying that from the point of view of someone who actually kinda liked Liquid threads and thinks that something like Flow might be a good thing. But if the WMF isn't going to take input from the community seriously and just ignore what they don't like, then there is no use in even wasting the communities time in asking for it. 138.162.8.59 (talk) 20:17, 10 October 2013 (UTC)

I'm not sure where you're getting that from, Kumioko. What we're saying is "A replacement for talkpages is coming, and if you don't think a replacement for talkpages is needed then you're welcome to give us feedback about how to make Flow better, but 'nothing needs to be replaced' isn't constructive". If your feedback is "I disagree with fixed width", that's fine. If it's "I disagree that any changes are even needed", well, that's not going to be massively helpful. I'd again ask you to stop making assumptions about the quality of the software, having not actually seen it, and refer to our deployment plan before making pronouncements about that. Okeyes (WMF) (talk) 20:24, 10 October 2013 (UTC)

Well I guess we'll have to see how it works out. 138.162.8.59 (talk) 20:35, 10 October 2013 (UTC)

(ec)Okeyes, I don't agree. Like I said above, read the section "How can I help" from the position of someone interested in, well, how they can help. Only the last sentence actually has any useful information, and the sentence above qualifies it with some "ifs" and "thens", with totally irrelevant promotalk ("improved", "better", "help eliminate"). The question was "How can I help". The reply is "You have the power to shape the development process of Flow. See our community engagement strategy to learn more." Not "if this and that, then you have the power". No. You have the power. Nothing of the divisive promotalk that was there contributed anything to that section. Fram (talk) 20:26, 10 October 2013 (UTC)

Better? More improvement suggestions welcome; it's a wiki! :) Maryana (WMF) (talk) 20:52, 10 October 2013 (UTC)

Thanks. I'm off to bed, will take a look tomorrow! Fram (talk) 20:55, 10 October 2013 (UTC)

There's a nuance to if your only feedback/criticism is that Flow is terrible, talk pages are great, and we should stop this project and go home. If that is literally the only feedback, with no justification or reasoning, then of course it is not particularly useful, given that there is an imperative to make Flow happen. However, I would prefer always to see a positive angle. The attitude should be "if you think that Flow is terrible, talk pages are great, and we should stop this project and go home, then tell us why, what you think is bad about Flow and we will try to make it better, what you think is good about talk pages and we will incorporate it: Flow is going to happen and we are all going to make it work". Same position but putting the naysayer on the spot to explain and give something useful, and trying to be inclusive not divisive. Spectral sequence (talk) 06:53, 11 October 2013 (UTC)

Having read the new "how to help" section, it is a lot better. I would personally not include the second bullet point (no need to diss the current discussion system to invite people to help with a better one), and would provide some more info on concrete possibilities to help (testing? Brainstorming?), but basically it is a lot closer to what I had in mind. Getting more editors involved and removing barriers is easier if you don't have too many barriers in the invitation :-) Fram (talk) 08:51, 11 October 2013 (UTC)

"How you can help" to me has two possible sorts of content. One is along the lines of "Turn up at this place, between these times, wearing old clothes. Oh, and don't forget to bring your aardvark". The other is "We need help with the bricklaying, with algebraic topology and another saggar-maker's bottom-knocker with double-jointed thumbs". The current answer seems to have the first, the logistics and process, nailed down. What about the second, the content and the work? What do you want people to actually do to help? Not a complete list, perhaps, but some examples to give the flavour. Spectral sequence (talk) 09:07, 11 October 2013 (UTC)

That's a really good point, Spectral sequence. There's a ton of work we need help on; it's just a matter of structuring it so people who are interested can stay updated and participate if they want to. I'm chatting with Okeyes (WMF) and Quiddity (WMF) about some ideas for taking our huge to-do list and divvying it up into more satisfying chunks. Stay tuned... Maryana (WMF) (talk) 20:13, 11 October 2013 (UTC)

There's admittedly a huge amount of work to do to document and codify (in all senses) the various discussion structures in use or likely to be needed in the future. Two thoughts arise. Firstly, why is that work not under way right now? Instead of letting the various communities focus on the minutiae of what Flow software might or might not do, challenge the communities to start documenting their own processes. (In passing, to do this you will need a lot of work from "power users", so it's probably a good idea not to be quite as scornful of their comments as has been seen at times on this page: WMF badly needs to repair quite a lot of its relationships). Secondly, the design of the software cannot proceed entirely in a vacuum. There are already a few random discussions here about what sort of capabilities are inevitably going to be required in some structures and workflows, even if not the earliest ones to be codified. That discussion should probably be formalised. Spectral sequence (talk) 09:06, 13 October 2013 (UTC)

I agree; this is work that needs to be done. In terms of "why isn't it being done now?" - because, well, we've got a heck of a lot of work to do all at once :/. I'm a big fan of setting up a framework so that we can get users involved to document these workflows, but it's taking a bit of time to get everything up to speed. There's also an argument (and it's one I agree with, but I'm prepared to be disabused) that supporting every use case anyone can think of is not necessarily what we want to do - we want to support every use case that is actively used. So we might take the "have people document all the processes" process and pair it with the small-scale release onwiki so we can see what processes are used, as well as what processes are available. Okeyes (WMF) (talk) 18:09, 15 October 2013 (UTC)

There's an argument that when I said "in use or likely to be needed in the future", I said, and meant, something different from "every use case anyone can think of". Spectral sequence (talk) 20:58, 15 October 2013 (UTC)

It wasn't intended to be - more that demonstrated uses > potential uses. Again, this is something we should set up a framework for, but we're very early on in development (workflow development hasn't even started); we have time. Meanwhile we've got office hours on thursday and a deployment in december-ish - those we can't wait on so easily :). Okeyes (WMF) (talk) 21:21, 15 October 2013 (UTC)

There is obviously a way in which it is not wrong to keep the ones who do not share the goals of the project away from it. I have even written an essay about it (Wikipedia:Wikiheresy). There is nothing wrong with, for example, not wanting me as a programmer on the "Flow" team - instead, it would probably be wrong for me to try to get into that team (not that I want to). There is nothing wrong with demands to stay away from the project, somewhere where it would have little impact. But in this case we have "What we're saying is "A replacement for talkpages is coming, and if you don't think a replacement for talkpages is needed then you're welcome to give us feedback about how to make Flow better, but 'nothing needs to be replaced' isn't constructive"." ([2] - by Okeyes (WMF) 20:24, 10 October 2013 (UTC)). Thus, unless that gets called off, the only place that does not get affected by "Flow" is outside of Wikipedia. So, are representatives of WMF ready to say that the ones of us who are sceptical about their project should leave Wikipedia (and other Wikimedia projects), as consistency would require..? By the way, that would be OK with me (consistency and clarity are good). Honest "Go away. We do not value your opinion." is much better than all kinds of "Sure, we do value your opinion. Just not really.".

Oh, and speaking of "constructive criticism", I have written an analysis of research methodology that, apparently, was used to conclude that "Flow" is necessary. I intend to write analysis of the test results as well. Do you (WMF) count that as "constructive criticism"..? Or is it "destructive", because it could lead to conclusion that "Flow" (as intended) is not necessary..?

And one more thing, since it looks like I was asked ([3]) about rewording of what now is "freeform wiki talk pages are a barrier to participation for new users and provide a bad user experience for many existing users." ([4]) - if the goal is to find a formulation everyone can agree with, then a simple "current wiki talk pages have some flaws and could be improved upon." would do. Of course, if the goal is to say "If you do not hate the current talk pages with all your heart, go away.", that would be a worse formulation. --Martynas Patasius (talk) 19:33, 13 October 2013 (UTC)

Discussion structures

The previous section on modifying one's own comments yielded an interesting insight. It seems that Flow is moving towards a set of structures for discussions which will codify (in all senses) practices. This is an ambitious undertaking. Is there already a taxonomy in place of the sorts of discussions which Flow will permit? How many are there? Is there significant difference across the 287 language communities? Are there any structures which it has been decided to deprecate, to change and are there any new structures proposed? It is certainly laudable to want to replace the arcane undocumented social structures with intuitive and well-documented technical structures: is there any of that documentation in place yet? Spectral sequence (talk) 07:21, 11 October 2013 (UTC)

Well, so the precise plan isn't to replace all of the informal structures with formal structures at our end; while that's a desired goal it would be incredibly difficult to provide every necessary structure here. We're not going to pretend it's possible for, well, 4 or 5 engineers to build every possible thing that every community could want, and then indefinitely maintain them. We're not approaching this with hubris.

Instead, we're approaching this with the idea that Wikipedia exists due to the fact that many people making small contributions is greater than a small number of people making many. We may as well extend this to the software. So, what we're hoping to build is some kind of structured workflow language that can be used to define non-standard formal methods of interaction on talkpages; individual wikis can build the ones they need as the use cases arise, and modify them as the use cases change. In the long term, we hope this will also allow for things like Page Curation to be more easily adaptable to other projects and to changes on this one. I hope that makes sense.

In terms of documenting that, Adam Wight (one of the fundraising engineers) took a stab at drafting out what it could look like here. None of that has been built yet (it's a pretty long-term project) but, thankfully, rolling Flow out to a lot of pages is also a long-term project. So we have time to discuss the problem and work out what workflows look like - once we've built the Flow structure, of course, which is the current priority. Hope that's helpful :). Okeyes (WMF) (talk) 20:17, 11 October 2013 (UTC)

I see. That's ... ambitious. Is there pre-existing research and development to build on? Spectral sequence (talk) 21:14, 11 October 2013 (UTC)

Into things like what the workflows are, or what capabilities the workflow system will need? Okeyes (WMF) (talk) 21:37, 11 October 2013 (UTC)

Either or both. Or indeed, in developing any generalised workflow description language of the scope and complexity required to capture the Wikipedia decision processes and simplicity and ease of use required to make it useable by the communities of editors. This is a very challenging task you have undertaken (nd asked us to undertake with you) and it would be useful to all of us to know what if anything like this has been thought about before. Spectral sequence (talk) 06:42, 12 October 2013 (UTC)

Actually, the larger software development community solved this years ago. The solution goes back to the introduction of the FORTH programming language. Letting the user do anything she wants by providing a markup language works, but not well. Making and enforcing rules is a poor substitute for the software not letting you do disruptive things. Trying to force everyone into one way of doing things also works poorly; you end up playing Whac-A-Mole because you cannot anticipate everything. The solution is to create a mini-language that defines what a user can and cannot do, and make the language flexible enough so that "what a user can and cannot do" can be pretty much anything. Then you let someone local deal with the question of what a user can and cannot do. It's more work up front, but it makes the system self-maintaining. --Guy Macon (talk) 19:29, 13 October 2013 (UTC)

Just to expand upon the above, let's consider signatures.

Under the markup paradigm, you ask the user to remember to sign his posts. Then you tack on a script that looks for "~~~~" and replaces it with a signature, hoping that nobody will need to use "~~~~" for some other purpose.

Under the structure paradigm, you hard-code a signature in a fixed format at at the end of each post. If you later decide to, say, put the date before the name, you go back to the developers and ask them to change the code.

Under the minilanguage paradigm, there is a file that contains a string of commands like "insert user name", "insert nickname", "insert year", etc. with a select group of users allowed to change that file. Now if you later decide to put the date before the name you simple put the date command before the name command. Or you can put the date at the top of the post and the name at the bottom or pretty much do anything else, all without bothering the developers. --Guy Macon (talk) 23:17, 13 October 2013 (UTC)

@Spectral sequence: I rounded up some of the prior discussions about workflows, and I've now added all the technical notes (preliminary research, drafts, etc) at the top there. The mw:Flow Portal/Use cases page in particular, might be what you're looking for. Although as you saw and noted at Maryana's talkpage, it's definitely a fantastically complex idea, full of potential ramifications. Discovering the correct balance between too-complex and too-simple, will take time - hence we're not rushing anything! Quiddity (WMF) (talk) 19:56, 14 October 2013 (UTC)

Actually, what I was looking for was a simple statement along the lines of "yes there is" or "no there isn't", in the former case possibly amplified by "and here's a reference to it / the name of it and we are / are not going to make use of it". Possibly split along the lines of "yes in the case of what the workflows are but no in the case of what capabilities the workflow system will need" (or whatever). Presumably the people working on the project know perfectly well whether they are building on something already in existence or starting from a completely clean sheet, and are capable of articulating that in a few words? Pointing readers of this discussion to a mass of documentation is not the most helpful way of answering the question. Please bear in mind that WMF is trying to persuade readers to take part in a demanding project and can reasonably be expected to demonstrate that they are making best use of their collaborators valuable time and energy. Spectral sequence (talk) 20:31, 14 October 2013 (UTC)

Sorry I wasn't clear. What I was trying to say is: Yes there is pre-existing research (as linked). No there aren't any rigorous specifications or code-written yet, because that aspect is still in the discussion/brainstorming/research phase. (afaik). Quiddity (WMF) (talk) 20:59, 14 October 2013 (UTC)

Thank you for clarifying that. Spectral sequence (talk) 21:14, 14 October 2013 (UTC)

Er, so, when Community demands something as users of the software, their wishes can be ignored, because, "But seriously, most community members are not software developers or designers." ([5] - by "Maryana (WMF)", 23:05, 3 October 2013 (UTC))..? And now those same "community members" are actually expected to develop the software..? Really..?

And "wikitext" elements like colons supposedly "are a barrier to participation for new users and provide a bad user experience for many existing users" ([6]), but making "statecharts" for "workflows" in unclear language is supposed to be a great experience for everyone..?

Now seriously, can't you (WMF representatives) hold a couple of team meetings and reach an "official" position that is at least consistent (if "reasonable" is too much to ask)..? --Martynas Patasius (talk) 18:20, 13 October 2013 (UTC)

I don't think that's quite fair. It seems clear that the work of documenting the workflows and discussion structures is going to be done, if at all, by experienced users and admins. It may not be precisely one-off, but presumably isn't going to need to be done very often after the initial investment of time and effort, and needn't be done by novices. Spectral sequence (talk) 19:02, 14 October 2013 (UTC)

They were not using those excuses to ignore opinions of newbies either (most newbies do not know about "Flow" and thus do not oppose it).

As for reprogramming - it is hard to say how often that will have to happen. We would have to know how it will work in order to know that. What can be said before that is this: it is not going to be a pleasant task. It will be far less pleasant than counting colons for indentation.

P.S. Isn't if funny that we both tried to "defend" WMF from each other in parallel ([7])..? --Martynas Patasius (talk) 19:42, 14 October 2013 (UTC)

So, a couple of points. The first is that part of this work is not new. Let's take the workflow of...closing a discussion, say. For me to close a discussion, I add templates to it - templates that can incorporate (extended) parser functions, which technically constitute a Turing-complete language we had to turn off, iirc, looping, because massive drain. So our implementation isn't Turing-complete, but the language is and are maintained and structured by the editor community. What we're talking about here is ambitious, in the sense that we've never had a language users can write in that actively interacts with the software before - that creates workflows which integrate with MediaWiki properly. But part of the work (users being willing to write and then maintain these workflows) is not new; it's something that happens all around us, right now. It just isn't something MediaWiki really knows about.

In terms of pleasantness, these are not things most users will have to interact with, much like the process of writing templates (as opposed to the process of using them); as Spectral sequence writes, the initial implementation process is likely to be handled by experienced users used to dealing with this sort of thing, as is the maintenance. Okeyes (WMF) (talk) 18:22, 15 October 2013 (UTC)

Indeed. And since this is work that has already been done, you'll be asking users to do it all over again, so you'll have to explain pretty convincingly why it's so important. The first step seems to be getting the workflows documented since that's of value in itself and a good halfway-house towards the codification. Spectral sequence (talk) 20:44, 15 October 2013 (UTC)

To some degree. I mean, I think there's a difference in the work that needs to be done - just not a difference in the mentality needed to do it. Getting workflows documented is indeed crucial, if only to see what capabilities the system will need - I'm going to throw it up on our Mingle instance now as something that needs to be done, but don't expect movement immediately: as said above, there are more imminent tasks that need to be done :). Okeyes (WMF) (talk) 23:34, 15 October 2013 (UTC)

Well, I think that's a mistake for several reasons. Firstly this is largely work being done by other people, so can be carried on in parallel with design and development; secondly, it gets the community on board and thinking about what it wants to achieve with the software when it arrives, so it doesn't all come together as one huge change; thirdly, it may tease out requirements that it would be important to know about at the design stage but which you don't happen to have thought about; fourthly, it's work worth doing in itself and of high value independent of the ultimate fate of the project. But it's only my opinion of course. Spectral sequence (talk) 06:48, 16 October 2013 (UTC)

That is, not doing it immediately is a problem? We have very limited bandwidth at this end - the team is maybe 8 full-time staff (including the part-timers) and that includes all the engineers and designers. I'm going to work on it, but it's not something of imminent importance and it does require setting up (working out precisely what we're asking people to document, and why). Yes, it can happen concurrently with design and development, but the people who need to be working on it at this end aren't the designers or developers, so that was never going to be a factor. Yes, it can get the community on board, but we need to be reaching out to people about Flow in the first-place for that to be viable - and that sort of task is what I mean when I mention things we have to get done soon :). Okeyes (WMF) (talk) 16:41, 16 October 2013 (UTC)

No, what I said and meant was, the earlier you start the better. You introduced the words "immediately" and "problem": I do wish that we could agree not to exaggerate other users' comments like this. Spectral sequence (talk) 17:32, 16 October 2013 (UTC)

Please provide indexing "table-of-contents"-like functionality

I read with dismay at the design FAQ that you've decided in your initial design to pass without the table of contents, open only to experimentation if "the search system is insufficient"; this is what I feared the most since the very first moment that Flow was announced. I can tell you right now that lazy loading of content through scrolling breaks most of my reading habits for talk pages.

I use the page index to get an overview of all the available topics, performing a quick scanning of the titles, deciding which ones to read and which ones to skip. "Infinite history" scrolling is a design that prevents this scanning, as there's no way to get an overview of the titles available. It's not true that "the concept of a table of contents doesn't scale" - you can easily paginate the TOC, or even lazy load it; the key differences that make it useful and are not available in Flow (but might be) are: 1) that topics are shown in a compact table format, and 2) that only the titles are loaded - the topic contents are loaded upon request for only the particular topics selected from the table (thus not polluting the page with any topic that I skipped).

My usual workflow is to enter a talk page, scan the TOC and open the topics I see interesting in new browser tabs, to read later in random order and jumping back and forth between them. The current Flow design makes this workflow impossible; even if all topics were collapsed and only loaded upon unfolding them, I'd still need to keep scrolling the page up and down to find the next topic I want to read. Having a TOC ordered by creation date also provides a sense of temporal and spatial relation between topics (i.e. an earlier/later ordering), which is essential to track which topics I have already processed (either by reading them or by deciding that I don't want to read them); the "flowing text" paradigm where topics are reordered every time someone updates them makes it very difficult for me to track what I've already processed and what I didn't.

Every HCI textbook shows that searching and browsing have complementary strengths (related to the recognition vs recall abilities of the brain), and you can't wholly substitute one for the other except for the most trivial tasks. When Aza Raskin popularized the infinite scrolling, it was designed as a solution for search results. It may also be a reasonable technique to apply to blogs, with usually have a separate column organized by date (i.e. a TOC), but it only works well when items in the list are unrelated and you may be potentially interested in seeing all them, in order, without skipping chunks; therefore I believe it is a bad general solution for the kind of content available at Wikipedia talk pages in my experience, where each topic is usually related to other topics above and below.

The main problem with infinite history is that it prevents scanning of titles - my experience is that it forces you to load all the intermediate content by manually scrolling before showing the titles of later posts, which is a slooow process (Wikipedia long talk pages are essentially paginated by the archive tools, so it's easy to skip to certain dates and pre-load selected reasonable sized chunks of content -in the 30Kb to 200Kb range - for quick scanning', without manually scrolling through them all while waiting for new topics to load).

So please, PLEASE make sure when iterating the software design that the final solution can build indexes for all the topic titles in a range of dates (ordered by topic creation) and that one can jump to any topic in random order.

I hope this text is enough to explain the reasons for why a solution providing the functions of a TOC is needed; if you need clarification of some point, please ask for it, and I'll gladly elaborate. Diego (talk) 09:12, 11 October 2013 (UTC)

Would it be feasible to provide each Flow with a "watchlist" so that new discussions, or discussions with new comments, are highlighted. Possibly in a table of some kind? At the top? With contents? Spectral sequence (talk) 09:35, 11 October 2013 (UTC)

As I understand the design, Notifications take care of highlighting new content. Though that only solves the case of being updated of new additions, but sometimes you also want to review old content; Wikipedia talk pages have high archival value, being often referenced and consulted either to find unresolved requests for the page or discussions where some particular consensus was achieved. The Flow structure doesn't seem at all adequate to support those use cases, as the only tool to dig into the past are permalinks to specific topics (not to the whole ordered page contents at a particular time) and maybe keyword search. Diego (talk) 09:49, 11 October 2013 (UTC)

Diego Moya, I added your comment to Wikipedia talk:Flow/Design FAQ – we're trying to keep design-related discussions mostly on that page, and reserve this one for general questions/discussion about Flow features/strategy/rollout, etc. (it's totally okay to have some overlap, but I think it helps to have a separate page where we can get into the nitty-gritty implementation detail discussions). Maryana (WMF) (talk) 19:08, 11 October 2013 (UTC)

I'm curious, how do you classify and separate between design and discussion of functions? For me, having a table of contents is a feature / required functionality. A design discussion would be how to style that table of contents when available, how many items to show, which controls, etc. Diego (talk) 21:54, 11 October 2013 (UTC)

Not speaking for the team, but: I'd classify that as design in the sense that functionality is "the ability to do a thing" versus "how that thing is implemented". So "a heuristic for deciding what I should/should not have to pay attention to" is a feature/functionality. "Oh, we can use a TOC for that" is a design thing. Okeyes (WMF) (talk) 23:01, 11 October 2013 (UTC)

I probably would've posted it here, thinking of it as a "feature" not an "aesthetics" aspect, but it's an abstract/subjective distinction, depending on definitions/interpretations. Huzzah for confusing/complex language! Quiddity (WMF) (talk) 06:50, 12 October 2013 (UTC)

In such case, wouldn't "being able to communicate with others" be the only "feature", with everything else counting as "design"..? --Martynas Patasius (talk) 19:36, 13 October 2013 (UTC)

The features aren't just "being able to communicate". People also use talk pages to:

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

Give such a wide range of uses I wonder whether we're paying sufficient attention to the volume of data on talk pages. For example, imagine the last nine years of Village pump (technical) ported to Flow. There's the current page with 42 topics on it, plus 168 archived pages (A–AX plus 1–118) with (average) 108 topics per page. That's over 18,000 topics. If that was presented as a "table of contents" on my screen it would be 438,000 pixels high, which is over 300 feet at 120dpi. There's no way a TOC can cope with that. - Pointillist (talk) 21:52, 14 October 2013 (UTC) Oh, by the way, if you're thinking that user talk pages don't attract many topics, check out User Talk for Iridescent, SandyGeorgia, Newyorkbrad, Eric Corbett, DGG, and Jimbo Wales. - Pointillist (talk) 22:07, 14 October 2013 (UTC)

Good point. It raises the question of what the unit of presentation would be for a Flow structured discussion. That applies both to the table of contents and also for the results of searches. Spectral sequence (talk) 20:40, 15 October 2013 (UTC)

Oops, minor correction to my last: When I referred to "the volume of data on talk pages" I was of course intending to include discussion pages in the "Wikipedia" space too. It would be rather strange to enable Flow on the "Wikipedia talk" pages without using it in new-editor-oriented places like Help desk, Teahouse questions, Editor assistance requests, Media copyright questions, and the Village pumps. - Pointillist (talk) 12:43, 16 October 2013 (UTC)

Only replying to the original post, and no possibility to have subsections?

The current version of the Labs Sandbox implements what some comments already hinted at. It only allows replying to the original post, not to any replies to it. This is no longer a discussion but a "post your opinion and disappear" format. The ability to have subsections seems not to be incorporated into Flow either, which seems counterproductive. Grouping related discussions (related in time and topic) is one of the benefits of section/subsection. Why remove this? Fram (talk) 11:43, 11 October 2013 (UTC)

At least you can reply to the main comment -- I can't. It allows me to enter a reply, but nothing happens when I click the green Reply button. Similarly I can't add a new topic. And yet strangely I can change the title someone else has given to a discussion. That seems odd. Spectral sequence (talk) 16:22, 11 October 2013 (UTC)

The hazards of watching development work happen in real time :) Replying to posts/other replies is just a separate chunk of code that got finished but hasn't yet been deployed on ee-flow... should be there by the end of today! Maryana (WMF) (talk) 18:46, 11 October 2013 (UTC)

A comment on language

It seems that we need a more precise language to hold the various conversations about Flow. Without a clear understanding of what it is we are talking about those conversation are likely to go nowhere. Indeed, I think we have seen examples of that happening here already.

Even "Flow" has several different meaning:

• The overarching project broadly conceived to formalise a set of structures for discussion and user interaction across the various Wikipedia and Wikimedia communities
• The formal project as a structure within the WMF work programme
• The group of people within WMF working on that project
• The software which will generate the discussion structures
• The software which will deliver the discussions to the users
• The user interface for the discussions

All of these might reasonably be referred to as "Flow".

Also referred to as Flow are

• Discussion structure, that is, a formal description of a discussion within a workflow, occurring in both in "source" and "executable" form

One might imagine that these would have names such as FreeFormDiscussion, GeneralRFC, AFDDiscussion, ... .

• Structured discussion, that is, an instance of a discussion with a given structure thought of as actually taking place somewhere.

It would be considerably clearer if we said, for example

• "Flow software will be implemented on page Foo, and the discussion structures allowed will be FreeFormDiscussion, GeneralRFC." rather than "Flow will be implemented on page Foo"
• "What discussion structures are needed for AFD and how should they work" rather than "Will Flow work for AFD"
• "In what discussion structures, if any, would editing another user's comments be useful" rather than "Should Flow allow a user to edit other users' comments"
• "Some discussion structures will allow users to modify their own comments. How will the Flow user interface present the changes in an easily understood format and what constraints does that put on the sofware" rather than "How will Flow cope with user changing their own comments"
• "Some discussion structures will allow certain subgroups of users to modify other users' comments. How will the Flow user interface present the changes in an easily understood format and what constraints does that put on the sofware" rather than "How will Flow cope with user changing other users' comments"
• "The overarching Flow project is over-ambitious in scope and the project team is under-resourced" rather than "Flow is too big and Flow is too small"

Maybe this will help structure our own discussion here. BTW please note that these are examples of topics already being discussed, not my personal views! To discuss any specific topic, whether using this wording or not, please start another thread! This thread is for discussing and hopefully agreeing a useful terminology. Spectral sequence (talk) 07:06, 13 October 2013 (UTC)

I like this a lot! I'll try to incorporate this lexicon into the main Flow portal page. Maryana (WMF) (talk) 23:11, 15 October 2013 (UTC)

Flow software questions

Will the Flow software be freely available? What licensing conditions will be imposed? Is open sourcing likely in the future? Spectral sequence (talk) 06:23, 14 October 2013 (UTC)

A condition of employment with the Foundation is that all software is released under an Open Source license, so yes. Flow is licensed under the GPL, as is most of our software. --Jorm (WMF) (talk) 17:59, 14 October 2013 (UTC)

Thanks for that -- I think it's a point well worth emphasising in this project, even if applies more generally, because it will be relying on a significant amount of work by the community. Spectral sequence (talk) 18:35, 14 October 2013 (UTC)

It's a good point to make. I just had a sit-down with both Brandon and Maryana (well, I ran over to their desks and went "what do you think of...") about the idea of crediting people who help with the process of building, say, the workflows extension, in the extension documentation proper so there's a tangible outcome for users who help with this (beyond Flow working). Looks like that's what we're going to do :). Okeyes (WMF) (talk) 18:15, 15 October 2013 (UTC)

Glad to hear it. It's also consistent with the spirit of CCA on attribution, so would be what contributors primarily of content might be expecting. Spectral sequence (talk) 20:38, 15 October 2013 (UTC)

Flow updates - Oct 15

A few quick notes:

• Signup at WP:Flow/Newsletter if you'd like occasional condensed overviews of updates and requests for specific input.
• We'll be holding an IRC office hours session in #wikimedia-office at 18:00 UTC on 17 November to talk about Flow as a whole. (And more, in the future).
  • The most uptodate documentation pages are currently WP:Flow/MVP and WP:Flow/Design FAQ. Looking through those (if you haven't already) before the office hours, would be ideal.
• Oliver and I are still putting together a list of action items, per the request/suggestion from Guy Macon and Spectral sequence and others, to put in something like a {{to do}}. Ie. Items that particularly need community feedback, or items that we'd love assistance with such as populating example discussions - for the latter example, we're just waiting on a few core features to be fixed/added in the prototype, such as "reply-to-a-reply" (which should be in the next day or two), and waiting for me to transwiki more templates.

More news, and more specific details, soon and often. Quiddity (WMF) (talk) 21:54, 15 October 2013 (UTC)

MVP questions

Thanks for putting the MVP together, having a tl;dr is always great. I should mention that I haven't really bothered reading any other flow discussions, so if my questions have been answered elsewhere, please trout me and I'll find them on my own. :)

A few things I didn't see in the MVP and was wondering about:

• Search: I assume everything will work normally?
• Moving "topics": if a user starts a discussion at AN, that should be on AN/I, how would a user move it?
• Under "Parsoid compatibility", it states that "most templates" would be usable. I'm not sure how it would work technically, but what is the planned distinction on a template that will work and that won't work?
• Opt-in/out: LQT had a #useliquidthreads function thingy to turn it on or off. Will flow have something like that?

Thanks, Legoktm (talk) 22:19, 15 October 2013 (UTC)

Help prepare the Flow sandbox

Hey all

So, as the deployment/engagement plans both say, the first release is going to be in a sandboxed environment - probably a MediaWiki copy on Labs. We're doing a lot of work to try to make it as close to enwiki as possible - copying things like site-specific CSS and JS over, the relevant extensions, gadgets, so on and so forth. Obviously one thing here is copying templates.

We've made a list of the top 250 templates in the Wikipedia talk namespace and copied them over: that's done. There are going to be some that are just as important for discussions, but maybe not used so commonly. We'd be most grateful if you could let us know of any you're aware of so we can import them to the Labs machine :). The existing templates (and the space for the ones we missed out) are both here; thanks in advance! Okeyes (WMF) (talk) 23:46, 15 October 2013 (UTC)

As long as you use Labs with its terrible privacy policy, I'm not going to help a lot, and certainly not test it there. Why not the testwiki instead? Fram (talk) 07:38, 16 October 2013 (UTC)

What's the privacy problem? - Pointillist (talk) 12:45, 16 October 2013 (UTC)

[8]: "By creating an account in this project and/or using Labs Services, you agree to comply with the Labs terms of use for Labs Services and acknowledge and agree your IP address will be made publicly available and not be treated as confidential regardless of whether you create a user account. You also agree that Labs volunteers will have access to any data you submit. This can include your IP address, your username/password combination for accounts created in Labs services, and any other information that you send. Labs volunteers are bound by the Labs terms of use, and are not allowed to share this information or use it in any non-approved way. Since access to IP address and other information is fundamental to the operation of Labs, these terms regarding use of your data expressly override the Wikimedia Foundation's privacy policy as it relates to the use and access of your personal information."(bolding mine, the rest isn't much better). There is no reason that people helping to test Flow should be treated like this, certainly when they may well be unaware of this (it isn't easy to find a labs pruivacy policy, I have to say). Fram (talk) 13:17, 16 October 2013 (UTC)

Thanks - very illuminating. - Pointillist (talk) 13:28, 16 October 2013 (UTC)

You're welcome. In the meantime (literally!), the privacy policy has been added to the main page of Flow at Labs[9], so at least the concern of "it isn't easy to find" is somewhat reduced. Fram (talk) 13:30, 16 October 2013 (UTC)

It should probably at least be added to or linked from [10] as well (hint for the unknown Flow editor :-) ). Fram (talk) 13:33, 16 October 2013 (UTC)

This is certainly a lot wider than is ideal :/. I'm going to try and hunt down someone to explain precisely why it works that way. Okeyes (WMF) (talk) 16:20, 16 October 2013 (UTC)

So, that privacy policy is evidently to deal with the fact that some instances on Labs are going to be run by volunteers, and it's possible to reconfigure MediaWiki to make such data publicly available. It shouldn't be interpreted as relating to the EE-Flow instance - technically it applies, but you're not actually at any more risk, in the sense that the people maintaining that instance (and, therefore, the people with access to that data) are precisely the same people who maintain and can access, well, enwiki. Okeyes (WMF) (talk) 17:00, 16 October 2013 (UTC)

English Wikivoyage as a test for Flow?

If you need a medium-sized community to test Flow, how about the English Wikivoyage? We are quite close to Wikimedia and probably know Bugzilla/Gerrit/etc more than other communities. We were the first non-Wikipedia content wiki to get Echo, and early adopters for Wikidata too. Nicolas1981 (talk) 09:45, 16 October 2013 (UTC)

That sounds fun to explore :). @Maryana (WMF): what do you think? Okeyes (WMF) (talk) 16:21, 16 October 2013 (UTC)