Meta:Requests for comment/Enable flow in the Research talk (203) namespace

The following request for comments is closed. As the proposing user, I (EpochFail (talk)) am withdrawing this RFC for now. It seems like we should determine the long term status of Flow first and then re-open a new RFC if Flow is planned to continue to be supported by WMF engineering. Thanks for your participation, everyone.

Statement of the issue

I propose that Flow be enabled on the Research_talk namespace. This namespace is used to document and list projects involving original research of Wikimedia projects and technologies. See Research:Index.

I have been working on developing the research community around Wikimedia wikis as well as performing my own research projects. As a result, I have been very active in the "Research" namespace writing new content and discussing projects with others. It's clear to me that our work in this space will benefit from adopting Flow for discussions. Many researchers of Wikimedia projects do not engage on-wiki often and they find Flow to be more intuitive than talk pages. Flow topics are also much easier to track with notifications (a benefit I hope to reap). Further, the "Research" namespace content on meta is still new enough -- and under active development -- that we are poised to adapt to Flow-based conversation patterns.

Note that I am the most active editor in this namespace. I have written our core templates (e.g., Template:Research project), category pages (e.g., Category:Research projects) and documentation (e.g., Research:New project). So this change will primarily effect me and those who I work most closely with. As I have been developing templates and other mechanisms to support navigation in this namespace, I accept responsibility for making sure that workflow problems around such a transition are resolved. After all, given that I'm the most active editor in this namespace, most of those problems will be my own.

Note that I am proposing this under my volunteer account, but I also work as senior research scientist for the Wikimedia Foundation. See User:Halfak (WMF). --EpochFail (talk) 17:36, 8 September 2015 (UTC)[reply]

Comments

Support I know my way around Flow, am active in the Research namespace, and will also help maintain and watch for issues that may arise. Implementing Flow in this NS will make our research portal more inclusive. I'm also with WMF. Jtmorgan (talk) 18:10, 8 September 2015 (UTC)[reply]

Oppose quite strongly enabling Flow. I simply do not like it. What it can be done with just one click, with Flow requires three. Not to talk about deleting threads and messages or even oversighting stuff. I've done some interaction with it at mediawiki.org, and I'm even less convinced. Slow to load and pretty rough IMHO. Not to talk either about multiple Topic: pages for each thread. It might appear more user friendly for newbies, but let me be clear here: Wikimedia should not be Facebook, nor its talk pages Facebook walls or Twitter feeds; nor the admins here should be placed under the burden of managing this new system I hope never see the daylight, not completly at least. I'm sure that the proposer has the best of the intentions, I know EpochFail is a tremendously hardworking guy, but I think Flow is a failure and I don't want it at Meta. —Marco Aurelio 18:17, 8 September 2015 (UTC)[reply]
I think you'll find the most important moderation functionality is already there. You can delete or oversight (Flow using the term 'suppress', which is also used sometimes on Wikipedia) threads and messages already if you have the appropriate rights. Can you elaborate on "What it can be done with just one click, with Flow requires three." and "Not to talk either about multiple Topic: pages for each thread."? Flow only has one topic page per topic/thread. I agree with you about the purpose of Flow. The Collaboration team's goal (the team that works on Flow) is to help people collaborate more efficiently and effectively on building educational projects. That's the reason for the team name. Some admin/functionary tasks are actually easier in Flow. For example, rather than reverting an edit that e.g. dox-es someone, then oversighting each individual page revision where it was visible, you can simply click one to oversight the post, write a reason, click again, then you're done. Mattflaschen-WMF (talk) 18:52, 9 September 2015 (UTC)[reply]
Oppose I like to comment research topics, but if this suggestion was implemented I'd be forced to stop: I don't want to be a beta tester of this product, for the well known reasons. --Nemo 18:48, 8 September 2015 (UTC)[reply]

Hi Nemo. Are there technical/work-flow challenges that you see activating Flow on all research talk pages can bring on us? If yes, can you list them or expand on them here? You are an active part of the research talk pages I contribute to (Thank you for that, btw,

) and I'd like to understand what won't work for you if Flow is activated in 203 namespace. It would also be good if you share your thoughts on what will be an improvement in your opinion, again from the technical pov. --LZia (WMF) (talk) 17:33, 11 September 2015 (UTC)[reply]

Oppose, I find it hard for me to accept all that subjective reasoning, just because it's good for you doesn't means it will be good for us.--AldNonymous^Bicara? 18:53, 8 September 2015 (UTC)[reply]
- I think you misunderstand. I've been a Wikipedian for nearly a decade and I program for a living. I'm a WikiText die-hard and I have no problem finding my way around talk pages. I see very clearly how talk pages support complex workflows that Flow does not do well yet. But we lack these complex talk page-based workflows in the Research namespace. So, I'm not speaking from my own experience so much as what I have observed working with the researchers who I am trying to draw towards Meta and Open research practices. --EpochFail (talk) 22:17, 8 September 2015 (UTC)[reply]

How could you say that? I came from developing country and often I use old computer when I traveling to some remote place with bad internet, I once use flow like in translatewiki, it's slow and often not loaded at all, I became frustated and stop doing anything at all. Do you have any proof that Flow will work well with older generation computer?--AldNonymous^Bicara? 02:38, 9 September 2015 (UTC)[reply]

I'm sorry. I didn't realize that when you said "doesn't mean it will be good for us" that you were referring to performance issues. Is this well documented somewhere? I'll raise the issue with the Flow Team and post back. --EpochFail (talk) 13:49, 9 September 2015 (UTC)[reply]

I've just learned that Flow isn't installed on TranslateWiki. I think you might be talking about LiquidThreads. See Special:Version. --EpochFail (talk) 16:52, 9 September 2015 (UTC)[reply]

Oppose Flow was the future whether or not we liked it (personally I was wary, had major problems with Liquid threads before, and after bad experiences testing V/E had avoided anything Flow related). But just a few days ago it was "deprioritised" so now seems to me very bad timing for a proposal to implement it here. If it was just a matter of the need for admins to moderate stuff and to be able to revision delete I'd be less bothered than on EN wiki, I don't believe vandalism is such a big problem here, and I'm not an admin on meta. PS to MarcoAurelio; Originally with V/E we had the problem that it was written to utilise the latest chips and ran very slowly on old kit. Early this year that went from a won't fix to something they actually made some progress on. Is the slowness of Flow related to that, or is it just like V/E now, you have to accept some drop in performance for an allegedly prettier result? If it has the same problem of very slow running on old kit that afflicted V/E then I would oppose it for the same diversity/inclusiveness angles as I used to oppose V/E. WereSpielChequers (talk) 19:05, 8 September 2015 (UTC)[reply]
Flow already supports older browsers (which are given the no-JS experience) and running without JS in general (which tends to be faster). There is more potential, though. Mattflaschen-WMF (talk) 18:52, 9 September 2015 (UTC)[reply]
Thanks for that partial reassurance, ever since I discovered the philosophical divide amongst WMF developers my first concern in any new development is whether it has been written for our current user base or just the technoscenti, happy to be reassured that Flow is not one of the most flawed WMF developments. WereSpielChequers (talk) 11:53, 10 September 2015 (UTC)[reply]
- While they used the word "deprioritize" in the announcement, the follow-up messages made it clear that the Collaboration Team still plans to continue maintaining Flow and integrating it with other tools. As soon as I saw the announcement, I went straight to the team for clarification to ensure that Flow would not be forgotten before moving forward with this proposal. I think that the user research on the subject refutes your concerns about inclusiveness. --EpochFail (talk) 22:12, 8 September 2015 (UTC)[reply]
  - A focus group of ten users is a useful thing to do, but I wouldn't take it as refutation of my concerns. My worst experience of liquid threads was returning to the strategy wiki after a real life gap of a few months to have Liquid threads crash my PC by trying to update it with all the threads that I had been following that had been updated in the meantime. A focus group such as that would not identify such problems, it is a good way to get superficial first impressions, but not necessarily much more. WereSpielChequers (talk) 11:53, 10 September 2015 (UTC)[reply]
    - The reason I bring up the user study is because it is the best objective evidence that we have about flow either way. Your speculation about what might happen, while interesting, should bend (but not break, of course) in the face of such evidence. Further, I find it curious that so many people are bringing up Liquid Threads in this discussion. You are aware that they are different pieces of software born through very different engineering processes, right? --EpochFail (talk) 02:26, 11 September 2015 (UTC)[reply]
      - The study may be evidence as to how newbies experience their first few Flow edits. It doesn't tell us anything about people making extensive use of it and being in multiple threads. Happy to take your assurance that Flow is a fresh start and the code is different, though I suspect the concept is the same. WereSpielChequers (talk) 14:17, 14 September 2015 (UTC)[reply]
Support I would like Flow enabled in the Research namespace. I think Flow is easier to use for those who do not have experience using talk pages, and for those new to contributing to wiki projects in general. The reason I say this is that we did user experience research to better understand new users experience with talk pages and with Flow pages in November, 2014. Overall, it was easier for the participants of that study to navigate, respond and generally to use the flow pages than to use Talk pages. Maybe having Flow enabled in the Research namespace will allow a wider group of people to more easily participate in the Research namespace conversations. --ARipstra (WMF) (talk) 20:52, 8 September 2015 (UTC)[reply]
Neutral I think Flow is a great extension in enhancing the talk pages, but I think for now, it need more user acceptance and need improvement based on user feedback, hence I think it is wise to not rush in implementing it into a certain namespaces. I think the current steps of enabling it for certain WikiProjects or certain pages is a good way to start this feedback process. Kenrick95 (talk) 05:06, 9 September 2015 (UTC)[reply]
Neutral I'm not sure if Flow really like me or not, I have a Flow user talk page (mw) and I interact with other many Flow pages. In my opinion Flow has aparently the same number of pros and contras, but in fact I think that traditional talk pages are a better option because I think that the most important things on talk pages are speed and flexibility. On the other hand, if Flow will be implemented on all wikis in the future it would be a good idea for Meta users who still have not used Flow to begin being in contact with it on these talk pages.--Syum90 (talk) 10:57, 9 September 2015 (UTC)[reply]
Support essentially per Jtmorgan. Ironholds (talk) 14:10, 9 September 2015 (UTC)[reply]
Support. As a Collaboration team engineer and someone who has worked with EpochFail on research experiments, I agree with EpochFail that Flow's current capabilities are a good fit for Research_talk, which in my experience is mostly free-form discussion. If there are specific issues that people think would pose a problem in Research_talk, we would be glad to discuss them. Mattflaschen-WMF (talk) 18:52, 9 September 2015 (UTC)[reply]
Support To mention another aspect: We are frequently pointing outside researchers to reviews of their papers in the research newsletter here, and it would be great if they were able to leave their reaction on that issue's talk page more easily (many of them, despite their research, are not familiar with wikitext talk pages).
On a general note, while I think every opinion above is valuable and worth to be listened to, it's also worth being aware that among the "Oppose" statements there are users with zero or a single-digit number of edits in the Research and Research talk namespaces, whereas the initiator has a four-digit number. Such aspects should be considered when evaluating the outcome of this RfC - and I'm not super certain this is an "issue of wider significance for Meta-Wiki" (quote from the RFC page). Like with the enabling of Flow for certain WikiProjects or village pump pages on other projects, I think the editors doing most of the actual work in an area (alongside those peope who have actually studied usability issues) will have the most valuable input on how to organize that work. Regards, Tbayer (WMF) (talk) 02:17, 10 September 2015 (UTC)[reply]
Support. Flow is far from perfect, but so are wikitext-based talk pages. I support enabling Flow within subcommunities that would like to use it. On Wikipedia and sister projects, those subcommunities are organized in WikiProjects, and on Meta they're sometimes organized in namespaces (like the Research, Iberocoop or Grants subcommunities). I appreciate that not all admins and patrollers like Flow, but if the Research subcommunity wants to use Flow, they implicitly agree to the potential penalty of not everyone being willing to help with anti-vandalism in that area. I think that's a fair compromise. Guillaume (WMF) (talk) 15:50, 10 September 2015 (UTC)[reply]
Strong oppose We do not need this ugly unfunctional crap, which WMF recently admitted was a failure to develop, on Meta. --MF-W 19:19, 10 September 2015 (UTC)[reply]
The WMF didn't "[admit] it was a failure to develop"; that email was ambiguous but the rest of the read cleared it up quite nicely, ime. If you find it unfunctional I suggest you solve for this by not using it, which won't be much of a struggle. Ironholds (talk) 19:53, 10 September 2015 (UTC)[reply]
That's not nice Ironholds. MF-W, is a steward, admin and an active member here for almost 9 years with several thousand contributions. He is absolutely entitled to have an opinion on this matter, and not be mocked. By the same virtue of - you can turn it off, it won't be much of a struggle...., I can also ask you to avoid meta all together, I assume that won't be a struggle? This isn't the right way to have a constructive discussion. Theo10011 (talk) 20:40, 10 September 2015 (UTC)[reply]
He's absolutely entitled to his opinion, and I don't think I said he wasn't - but it's also worth making explicit, again, that what we're talking about here is enabling it in the research talk namespace. If you have objections to Flow, that's fine, but if we're not talking about deploying it anywhere you have shown any indication of contributing, that's worth bringing up. "Doesn't work for me" doesn't mean "doesn't work for anyone", and if it's not being talked about in a space you contribute to there's no cost in enabling it for others. Ironholds (talk) 20:49, 10 September 2015 (UTC)[reply]
Why do you always say the same things? When I say he is entitled to his opinion, I mean he is entitled to oppose here on the RfC, he is even entitled to hate flow. I never said that you are not letting him express his opinion - it's your mocking of an opinion that I found questionable. This discussion invariably leads to, why is this even here? - This is a public wiki. It existed long before a research department, dare I say, even a WMF, in its current incarnation. There is a community here that has and will continue to outlast most staff members. If the only people who are asking for this and supporting this request, are all paid employees, why not take it to one of your private wikis? or the wmf wiki fishbowl? I assume you want it on a public wiki for some reason, as such you have to work with the admins and community members who have been here for almost a decade - they can disagree with you on new changes. It's not that hard to follow. And saying, it's not deployed anywhere I or anyone else has shown indication of contributing - is again, a judgement you are making - assume I intend to comment everywhere on meta whenever I want - please understand, this is not a decision for you to make or mock anyone for. Theo10011 (talk) 21:11, 10 September 2015 (UTC)[reply]

Tone aside, Ironholds point shouldn't be dismissed. Of the 14 people who have contributed to this RfC so far, only eight of us have made more than 10 lifetime edits to the Research or Research talk namespaces. Guillaume and Tbayer have raised similar points, which have also not been addressed. By necessity (if not design), Meta serves a variety of different functions for a variety of different local communities. So far, some of the strongest opposition to this proposal has come from people who don't participate in the research community. Of course they, like everyone else, are entitled to an opinion. But why do those of you who don't participate in Research care whether or not those of us who do, use Flow? Jtmorgan (talk) 22:54, 10 September 2015 (UTC)[reply]

Tone is very important. A change in tone can make a world of difference in our daily interaction - online and off. Anyway, if you'll run your query again or see my last contributions, you'll notice I've made about a dozen edits in that namespace. It took me about 30 minutes or so in whole. At some point it should occur to you how facile your argument is, and how thin that line is between those who participate and those who don't. I don't mean to be difficult on this, but this current line of discussion stretched solely from Ironholds' comment and tone which wasn't constructive - nothing else. Thanks. Theo10011 (talk) 23:52, 10 September 2015 (UTC)[reply]

Sorry, I did not mean to dismiss your objection to Ironholds tone, and I agree that tone is important. In fact, these kinds of discussions are rough on me and I generally avoid them, regardless of which username I'm editing under, precisely because of the background noise of incivility that permeates our community discourse. I'm also very aware of the line between who edits and who doesn't: I know many external researchers who don't participate in on-wiki discussions because editing talkpages is cumbersome. I also know that for many of them, modern forum software would be less cumbersome to use. Flow will serve the needs of those users, in this context, better than wikipages. These are the people I want to design for, because their voices are currently missing from important research conversations. I know from my work on the Teahouse that reducing technical barriers to participation works. And I know from my experience using Flow that switching to these boards will not unfairly marginalize experienced editors, or hamper them from participating in on-wiki research discussions, if and when they choose to do so. Cheers, Jtmorgan (talk) 01:37, 11 September 2015 (UTC)[reply]

That may be your interpretation, but to me there is now even less reason for a community to ever want Flow to be introduced than before; as I dislike its current state (cf. MarcoAurelio) and that state won't be changed much anymore. — Your suggestion is not a solution. Just because I have not yet commented in Research_talk doesn't mean that I never will want to, nor that just because I am not active there, I can be OK with cumbersome "features" being introduced there. Soon enough someone will come up and propose Flow ("flow"?) to also be enabled on some other namespace, because, e.g., it is already in Research talk. Cf. Vogone's comment below about what happens on Wikidata. --MF-W 01:46, 11 September 2015 (UTC)[reply]

Thanks for your comments, MF-W. You have a very strong opinion on this subject and that is something I appreciate very much. However, I am struggling to understand your objections. You've suggested that I cf arguments to support your position, but those posts are also fail to cite specific issues. What is it that you dislike about Flow's current state? I'd like to file bugs/feature requests and talk to the team about getting them addressed. I think that you have misunderstood the Collaboration Team's announcement. When a piece of software enters maintenance mode, we tend to consider it "stable". As someone who writes a lot of software and deals with other people's in-development code, "stable" is awesome and desirable -- but certainly that's only true if it works. That's why I want specifics about your concerns. We should fix these issues before the Collaboration Team picks up the next thing.

If I may, I'd like to ask you to consider the other side of the edits-a-bunch-in-this-namespace argument. I've worked as a volunteer on research of Wikimedia stuff for longer than I have been a staff member. That means I've been building in this space for a *long time*. I understand that you might like to one day contribute something here, but this is where I live -- in the Research namespaces of Meta. And it's not just my edits. I also do a lot of offline community building activities like the global research hackathons that I run. I am the primary mod of the #wikimedia-research IRC channel. I'm also the primary developer of a bunch of software that makes research of Wikimedia projects easier. See https://github.com/mediawiki-utilities I do my work out in the open (see one of my worklogs for example) because I think that the scientific process and open knowledge is more important than the embarrassment I might suffer for making a mistake in public. So, it's not really the amount of edits that you should consider when I argue that I think Flow will work better for us Wikimedian Researchers. The large amount of edits that I have made in this namespace is just the tip of the iceberg for my experience working with the research community around Wikimedia. You might point to this and say that it is my job, but it is not. I do 95% of this in my "volunteer time". I "work" evenings and weekends because it is my hobby and it is something that I believe in. I know that none of this forgives me for being a staff member and that's something I regret as it suggests bad things for the future of both the WMF and the movement. It's not a problem that we can solve here in this RFC, but I hope you'll consider looking who my employer happens to be and see the super-active volunteer who happens to also have an awesome day job. --EpochFail (talk) 02:57, 11 September 2015 (UTC)[reply]

Oppose Per MarcoAurelio, and MF-W. Also, I'd like to bring attention to the fact that most people requesting/supporting this are staff members and for all we know, physically present in the same office, merely agreeing, instead of making a judgement call. I like how Epochfail stated his activity, goal, declared and delineated from his staff role while making this request - Thank you for that. I'd ask other staff members should take his lead so it's easier for us to follow and look at the discussion procedurally in a condensed form while formulating our opinion. Theo10011 (talk) 20:27, 10 September 2015 (UTC)[reply]
Of the staffers who have commented here, 3 are SF based and 3 are not (and none of them in the same location). Ironholds (talk) 20:49, 10 September 2015 (UTC)[reply]
Thanks. So far, 6 supports, all from staff members. Theo10011 (talk) 21:12, 10 September 2015 (UTC)[reply]
Theo10011, I don't see any staff members giving this proposal a cursory +1. Except perhaps for Ironholds' original post, which he has since expanded upon. What else would you like to hear from the staff members who have participated in this discussion, that you aren't hearing? Jtmorgan (talk) 23:02, 10 September 2015 (UTC)[reply]

Absolutely nothing. There is nothing I want to hear from anyone and I don't want them to think they are beholden to me to offer reasons or justification. But do I have the right to my disagreement? or it has to be beaten in to submission by someone eventually. There are others here with stronger opinions than mine. If they can be brought to reason and there was assurance this wouldn't create a mess for the admins - I'd support this. Again, I understand your position and I'm not trying to make things difficult for your team. Theo10011 (talk) 23:52, 10 September 2015 (UTC)[reply]

Theo10011, I think we should all be held responsible to offer reasons or justifications for what we say in here as soon as we make a comment. We may do otherwise (that's our right) but in general, when we make comments publicly, we should expect questions/feedback, and we should engage in follow-up conversations, as much as we find them helpful. We cannot say x was my comment, and you asked for comment, and I'm not going to say more.;) Of course, we can, but that's not the point of having a conversation. This is my personal take on RfCs: they are there for people to discuss ideas/opinions, not for people to just vote. (If voting was the only goal, allowing users to see other people's votes before voting would be problematic.) With this long intro and given your first comment on this part of the thread, I think it helps if you engage with staff members who have left a comment by asking them questions, staff can do the same. The opinions raised here should not be set in stone, we are having a conversation and once I learn more from you, I can change my opinion, you should also do the same. Let me know if I can help. --LZia (WMF) (talk) 21:35, 11 September 2015 (UTC)[reply]

Heh LZia (WMF), see this is why I said you seem smarter. ;) You seem to have figured out the goal of an RfC and the core of consensus building perfectly fine on your own. I agree with your stated points to some extent actually, but I can also argue that people do have the right to disagree without going in to their reasoning - some opinions can be above reproach. Even stating their reasoning openly is a right every individual reserves or exercises. Someone can just dislike something without offering an explanation, and if explained, still has the right to not change his/her mind. However, in this case I won't argue that. I thought the debate above is quite unhelpful, between rhetorics and focusing on individuals, we really weren't discussing flow as much and its benefit here. If you read below, I suggest an alternative approach. The staff has asked the community members about their opposition, I want to ask why the staff is so interested in flow - its perceived benefits. Do you expect it to revolutionize your work or stop it in its tract without it? We should have a discussion about realistic merits and demerits and not make this personal and vitriolic as it was getting. I hope you and other staff members supporting offer their reasons and engage below. Thanks. Theo10011 (talk) 22:09, 11 September 2015 (UTC)[reply]

Thanks, Theo10011. I'm undecided myself so I'll continue reading the responses (to my earlier questions whenever they are in and your new thread), just want to thank you for trying a new approach. We will all benefit from this. --LZia (WMF) (talk) 22:21, 11 September 2015 (UTC)[reply]

Oppose I don't want meta to turn in another flow sandbox just like Wikidata recently did. The feature doesn't look ready to me yet and thus is better enabled in test environments, which metawiki certainly is not. --Vogone (talk) 20:35, 10 September 2015 (UTC)[reply]
Oppose As long as this weak forum impersonation is as unflexible and incompatible with normal wikiediting as it is now, it should not be enabled on any page where anything beyond blahblah is to be expected. --Grüße vom Sänger ♫^(Reden)_{superputsch must go} 20:42, 10 September 2015 (UTC)[reply]
I'd like to discuss this more before making a decision on my end. I have two questions (one of them I mentioned to you this morning, in a separate channel EpochFail, hence, sorry for repeating myself):

From the technical point of view, can we have Flow enabled in an opt-in/opt-out basis per page, i.e., if Flow is set by default on all talk pages, can a user with no special privileges revert that decision? If not, who can, if anyone at all?
What happens to the old talk page messages, whether they are archived or not at the time Flow goes live based on your proposal?

As a side note: I know that you have meant to start this conversation for quite some time now, EpochFail. I think the fact that this conversation is started now, after the announcement about Flow's next steps, makes it harder to not have a polarizing discussion here since many interpreted the announcement as the discontinuation of Flow and now this RfC may be interpreted as the WMF wants to push something that won't be actively developed to everyone through different channels, even though you started this at your volunteer capacity. The polarization is unfortunate, I know that you have good intentions, and I hope we can all work together to make the right choice. Some more clarification by someone who knows more about Flow and the next steps on the wikimedia-l thread can also help bring everyone to the same page about where we are with Flow and where we're heading and why. Keeping the conversation here solely on a technical but not ideological level can help, too. --LZia (WMF) (talk) 22:34, 10 September 2015 (UTC)[reply]

Oppose I'd proclaim anathema to everyone who supports that ugly flow thing. WMF should create a sandbox wiki somewhere independently and play there as much as they wish. Preferably using money from their own pockets rather than wasting donors' money on developing that stupid stuff. --Base (talk) 20:44, 16 September 2015 (UTC)[reply]
Weak support (at this time). I although don't like the automatic edit summary for every new thread to [at least] trusted users. Tropicalkitty (talk) 05:28, 19 September 2015 (UTC)[reply]
I share LZia (WMF)'s questions above on per-page configurations and archiving. Other points that I would like see addressed are:
1. As a commentator and lurker, I would like to be able to use full-text search to search over discussions. Flow topics don't seem to be searcheable, at least not yet with the built-in full-text search: phab:T62493. If Google indexes them in a reasonably short time, that might be workable, though.
2. As a participant to different corners of Meta, I would like to be able to filter Flow topics by their associated namespaces (such as Research-topics, Grants-topics, etc) within tools I use to keep me updated (such as Watchlist, RecentChanges, Notifications). Is it supported by Flow, or perhaps is it a phabricator task to create? This won't be a problem until another namespace on Meta gets Flow, though. whym (talk) 02:43, 21 September 2015 (UTC)[reply]

Mattflaschen-WMF, could you comment on these and LZia (WMF)'s questions? --EpochFail (talk) 23:39, 23 September 2015 (UTC)[reply]

Oppose Am significantly concerned about the WMF presence in this RFC. --Rs chen 7754 00:55, 11 October 2015 (UTC)[reply]

Is it redeeming that many of us operate substantially as a volunteers after hours or does our employment status render us and our input inherently problematic? Does it matter that we also represent the vast majority of activity in this namespace? I encourage you to find ways to assume good faith and consider the points that have been raised. --EpochFail (talk) 17:18, 11 October 2015 (UTC)[reply]

No, considering that many of the staff didn't even bother to switch to their volunteer accounts, but used staff accounts clearly denoted WMF. --Rs chen 7754 21:03, 11 October 2015 (UTC)[reply]

Oppose, Flow in general might be useful for discussions with newbies and various simple discussions, but in no way it can work with complex discussions that can happen in Research talk. Just two examples: Research talk:Increasing article coverage became so messy that author had to reorganise discussion into groups of topics (which was helpful and worked, but which is not possible with Flow where topics cannot be re-arranged) or Research talk:Active editor spike 2015 where there were comments with graphs that are not quite supported by Flow (or at least they will not look the same way as on the Research page, obviously because Flow is twice more narrow than article pages). Thus no, Flow is not suitable for Research talk namespace — NickK (talk) 02:35, 11 October 2015 (UTC)[reply]

Thanks for your comments that address the functionality of Flow. I disagree that Flow would not be sufficient for supporting the complexity of the discussions you have used as examples. I'll comment on both examples.

Re. the Research talk:Increasing article coverage example, were it to happen in a threaded discussion, we would start new threads with "<new subtopic> (was Re. <old general topic>)" as a subject header. In the case of flow, I would suggest also including a link to the old topic to make the conversation easy to follow in reverse. In my experience with other threaded mediums, this works very well. This pattern is actually quite common to talk page discussions as well. For example, see mw:Talk:Code_of_conduct_for_technical_spaces/Draft.

Re. the Research talk:Active editor spike 2015 example, I do not see the column width as a limitation. For example, it is very common in scholarly publications to use a narrow column format because it aids in reading because your eye doesn't need to track so far line-to-line. I could throw a bunch of peer-reviewed research confirming this. Here's one: [1]. In many cases, columns in research papers are much narrower than the width used by flow. See [2] as a relevant example. Further, due to the paper medium, the images can't be hyperlinked in a paper, so the reader is limited to the included image size. In MediaWiki, clicking on an image allows one to access a higher resolution version. If for no other reason, that should render this concern irrelevant. --EpochFail (talk) 17:18, 11 October 2015 (UTC)[reply]

In the first case, could you please explain how would you do that? It is completely unclear how this can be done and your link is red. The issue with this page was a great number of small sections with same statements in different parts of the page, but I do not see how creating more new threads would help (it would just make situation worse, as the goal was to organise threads in a more efficient way).

In the second case, I am perfectly aware that some journals organise text in two columns (and {{Columns}}) can do this anywhere on wikis). But this is not the point, the issue is that in Research images one might have to copy graphs/tables/diagrams etc. to illustrate their point. Thus it would be at least odd and at most impractical that these graphs/tables/diagrams will look different in Research and Research talk namespaces, and it is strange to make graphs or tables twice as narrow as on normal pages. If graphs are scalable, tables are not, and tables like at Research talk:Newsletter would just fail with Flow — NickK (talk) 00:32, 12 October 2015 (UTC)[reply]

Link fixed. I just narrowed my browser to 500px wide and was able to read the table (that should not be a table) that you referenced. We have quite complicated discussions on mailing lists and in threaded discussion forums and yet seem to get on just fine. I don't see anyone else climbing over themselves to switch their discussion format to a freeform document like talk pages. --EpochFail (talk) 22:49, 13 October 2015 (UTC)[reply]

Well, you convinced me to moce to

Strong oppose. I tried to test and copy this table to Flow. Not only I could not find any way to add atribution, not only it looks weird (it is really narrow, just see column headers), not only it is not functional (my test is at mw:Talk:Flow, I found out it is a wrong page but I did not find a way to remove my comment or move it to mw:Talk:Sandbox), but it simply did not work! Yes, I was using another PC this morning (it has IE8, but still...), and once I pasted the code of this table Flow window became three screens high and refused to save my edit. Thus I had to wait until I came home and use my laptop with Chrome to try... It would be very disappointing if I would be unable to comment on Research talk when I have to use IE8, and this cannot outweigh any advantages, hence strong oppose — NickK (talk) 21:58, 15 October 2015 (UTC)[reply]

Oppose I do like the idea behind this feature, but IMO it is not suitable for Research talk namespace now. Needs more improvement, per NickK concerns above. Muhraz (talk) 17:04, 11 October 2015 (UTC)[reply]
Oppose I do kick flow pages from my watchlist. --Atlasowa (talk) 09:53, 12 October 2015 (UTC)[reply]

Different approach

I feel bad for EpochFail and the rest of the research team here, well the non-ironholdsy part of the team. I read Epochfail's reply above, about his past work, to his goals and his reasoning - he seems to have good intentions all around, and does a lot of good work. In fact the other members too - Lzia, Morgan et al seem to want this feature as well because they believe this will make their jobs easier. I also want to assure the team that the community members opposing here, have nothing but good intentions towards them and their work. It might not seem like it right now, but I don't think anyone wants to impinge upon your work in any way. We all want to do our thing in our little corners and not create too much trouble in the process at the end of the day, and reasonably get along with each other through it all. We also don't want meta to be another testing ground.

So, since the staff has been writing their concerns and asking us why we are against flow - I wanted to take this opportunity to ask why do you want it here so badly? Allow me to elaborate - we have seen a lot of different features over the years, some horrid, some were effective but we have seen through a few of these requests. A lot of us saw Liquidthreads up close on strategy wiki and felt it was unpleasant, to say the least. So much was wasted and lost, it made a mess in a lot of places. Flow, is the next iteration for a new discussion system - the opinions against it here seem strong. The staff, on the other hand, seem to be so in favor of Flow that it's almost surprising, given the strong opposing reactions. I want to ask why that is? What benefit do you think it will have? How will it make your work easier? Have you had some specific exposure to flow where you thought it was particularly effective? If so, sharing those examples might help. Dare I say, the flow team developers might not be as gung ho as you seem to be here, about its benefits. At the end of the day, it's a slick new discussion system. It is not going to revolutionize your work or bring it to a complete halt - be realistic about its benefit. You are not going to be drowned in comment and feedback just because flow is active. If anyone wants to continue this discussion then lets talk on merits and perceived benefits and demerits of this system. The discussion above was not constructive and far more emotional/ideological - instead of focusing on individuals opposing and their reasons, try and focus on the need itself and make your case without directing it at anyone. Even then, if it still fails, please have the best intentions for each other folks. Regards. Theo10011 (talk) 21:53, 11 September 2015 (UTC)[reply]

+1; I don't doubt the good intentions of anyone involved in this discussion nor question their work, which is valuable. My concerns are just with Flow as Theo said. Best regards. —Marco Aurelio 22:14, 11 September 2015 (UTC)[reply]

(EC) Thanks for your re-framing Theo10011. Story time! So, just today I was in a meeting with researchers who I am working with on one of the research workshops I was discussing above. See our draft here: Research:Infrastructure for open community science. So, in the meeting, I was asking about feedback that people had on the draft. One of researchers had emailed me her notes a couple of days ago (which was fine). But when I asked about it, she told me, "I couldn't figure out how to post a comment on the talk page." I offered an explanation that "talk pages" are full wiki pages and you need to format your post as though it were a forum -- but you'll be editing the page with everyone else's comments. She couldn't believe that *that* was what she was supposed to do. I think that Flow will substantially mitigate undesirable situations like this one. I suspect that if Flow were enabled on that page, she would have known what to do. Further, I'd like for most of our working groups' discussion to be on that talk/flow page, but I think we'll end up using private emails. That's lame. It should be better. --EpochFail (talk) 22:21, 11 September 2015 (UTC)[reply]

This is helpful EpochFail but honestly, I was expecting a bit more. I'll wait a few days before commenting in case anyone else has anything to add. Thanks. Theo10011 (talk) 22:44, 12 September 2015 (UTC)[reply]

I'm not sure what "more" you're looking for, so here's a stab in the dark:

I can speak to the types of entry barrier I think that I think Flow lowers. I lay out three levels of barriers to participation in a recent talk I gave about VE. TL;DR: When you're doing community building, you want to be able to welcome every productive newcomer that you can. So entry barriers that make it more difficult are a primary concern. I see three primary barriers to participation in Wikipedia, but I suspect that they are really general to any computer-mediated community. (1) permission, (2) literacy and (3) social/motivational. Permissions are not a problem here. The software would not prevent my colleague from using a wikitext talk page. Literacy, on the other hand, is more about knowing how to achieve a goal. My colleague wished to communicate about a research project. But she didn't understand how to do that using the wiki, so she chose to use a more familiar medium. I think that we can bring down technical literacy barriers with technologies like Flow and that doing so would help me bring researchers to this medium. That's why I want to enable it in the Research namespace. As for social/motivational stuff (which is essentially, "Did you find the work rewarding?" and "Did you make friends?"), I don't see Flow helping there. That's mostly our responsibility.

I told you just one story above, but I have many others that go about the same way. Part of the reason I have such a high edit count in the Research_talk namespace is because of my years of insisting that Researchers use the space to discuss their projects. If you want more reason than I have given you, can you please clarify what you think is lacking in my argument. --EpochFail (talk) 00:34, 13 September 2015 (UTC)[reply]

Hi EpochFail, I think you misunderstood me. I didn't mean you, I meant more comments - from other members who supported. You are certainly the originator of this request but others voted above and defended the vote - I assumed they had their own reasoning and example, apart from yours. Regardless, this is a constructive move - I would also clarify that there is no need to get defensive, if I gave you the wrong impression anywhere then I apologize. You or your arguments don't have to prove anything. I know this is important to you and we all tend to get passionate about our little corners, I respect that, and your request is absolutely valid and you have the complete right to discuss with your fellow metapedians.

I don't know if it helps, but I tend to look at the big picture, which might offer perspective at times. So, at the end of the day, if we had flow or slow or any other system here - how much would it impact your daily life? - will it save wikipedia? will it instantly make everything better? or save a hundred kittens? or cure some disease or end world hunger? most importantly, would you or anyone else be happier?- we both know, it would just make it incrementally easier for people you are already talking with, to comment on these pages. Sure, It might make your job a little easier - but please look at it in perspective, the big picture. Even if we don't get consensus for flow, would the world end? Getting negative, or defensive or protective is not going to help. So, Relax, have a cookie or a Stroopwafel (we hand them out a lot on meta ;) ).

Now back to your point - You suggest the biggest barrier is that your fellow researchers had a hard time finding the talk page and posting it on it. Literacy as you said, is the biggest barrier, true, but there are inherent benefits to it. System like Flow aim to be no better than FaceBook, Twitter and other social media platforms - but they all come with their own minimum inherent level of literacy that people pick up. Registering an account is a universal barrier we can agree there I believe, but then things like - liking, feed, hashtags - are all platform specific things people are expected to pick up - and they do. Why is that any different here? I have a bit of experience with giving real life tutorial to new users at meetups - the barrier of entry to getting them to post will still be there with flow, it would just be lowered. People can still overlook the talk page with Flow, or not register an account - leaving everyone to guess who commented what. Flow might not be the panacea for all your woes. I have my own questions to your example -

Did the researcher mention not being able to find the talk page? or not posting to it? overlooking it completely I mean. Then, visibility is a big problem.
Did they create an account at any point? they would need a little bit of instruction. Then, Instruction or guidance is needed.
Was it more difficult to find the edit button or the talk button? they both have equal visibility.
Was the markups the thing that got in their way? then something like Flow might help, but getting to this point means the last 3 were easily bypassed, I doubt that.
Sometimes, people new or unfamiliar just don't want to be open or exposed. They would rather choose to hand off their work to a third party and move on. This a choice, even if it's not admitted.

Even if the researchers somehow found their way to the edit section of a talk page, and only thing that deterred them was the markup then flow has a case. But I highly doubt that. Even if they left just the most incomprehensible, jumble of text and comments on a talk page, it would still be visible to us all. In fact, people like Nemo and several others here would have already cleaned up and fixed things for them without asking - as curators. There isn't a shortage of content curators here, what we need is just someone to make an effort and leave their thoughts. I don't know how to push people to do it, but I know, flow alone won't do it. Anyway, here are a few suggestion, I and other here would be happy to help you with. I believe the biggest technical barrier here is either literacy or visibility. -

In case you missed it have a look at the Signpost - the comment section. They had a similar problem. So, they made a template, and transcluded the talk page content at the bottom of the main page. You get a prominent, visible position with +Add a comment button that reduces the overhead of finding and posting and guides people through the commenting process.
If you are limiting things to your namespace, you can make the talk page more prominent. There's a lot of hacks and settings to change if I'm not mistaken. You can also just put a comment here link at the bottom of the research page that automatically directs people to the editable talk page. Grants team built specific templates if I recall that were very advanced, maybe checking their approach out might be worth it.
Attribution/signing might still be a problem with flow.
How about getting a designated person on staff to guide the researchers or post their notes on talk pages while giving them a brief tutorial. A brief tutorial would be highly advisable in my opinion (link to a video how-to or one of the simplest guides we have, might suffice).

As I said flow might not be the panacea we need. If it makes things easier for researchers, It would also lower the barrier for vandals - and we have our share on meta too. How do you plan on dealing with that? I can also make the argument, researchers working with our projects have a bit of onus on them to learn the most basic of our editing practices. We try and teach editing to random visitors - academics, consultants, staff, teachers, children, everyone and their grandmother at every occasion. Is it so difficult to ask they learn the most basic of our editing practices? A small tutorial including the time to set up an account would take 10-15 minutes. This might have long term benefits if they get used to it and choose to remain engaged. Also what about content before flow? will it be archived or lost? I hope my perspective helps. Thanks for engaging. Kind regards. Theo10011 (talk) 19:59, 13 September 2015 (UTC)[reply]

EpochFail, I made a horrible attempt at customizing the template signpost uses for the research project. Please have a look at my userspace, it took 5 minutes to customize, and I'm probably the least knowledgable person here on these things. You, and others on your team, not to mention regulars on meta, are all much much more knowledgable than me, and can do a 100 times better job at a template like that given more time (pretzel on en.wp redesigned things for signpost, maybe he can offer some help too). The intention is to just give you an idea and get some perspective from your team. Will something like this help? Imagine it at the bottom of every research page to give your talk section more visibility- it could be made more formal, research oriented. Theo10011 (talk) 20:47, 13 September 2015 (UTC)[reply]

I agree with EpochFail's points about the barriers that talk pages present for newcomers. My rationale for enabling the tool in Research_talk is the same as his, and the story he shared about an external researchers' hesitance to post on talkpages resonates with my own experience working with external researchers. Hacks like the ones that Theo10011 proposed can help, but they are (as that term 'hack' implies) workarounds. Flow is designed to support threaded conversation, and provides discussion-support functionality beyond what is available through the proposed workaround. I don't believe that Flow is a panacea. The problem it is supposed to solve is making it easier to participate in discussions. I have led edit-a-thons and conducted interviews with new editors from many different walks of life over the years, and editing with Wikitext is one the primary technical barriers to participation that newcomers face. Flow addresses that issue directly. Teaching external researchers good editing practices will be easier if they are comfortable communicating on-wiki with people who can provide them guidance and support (see WP:Teahouse). As for vandal fighting, as I said in my original post I will help maintain and watch for issues, which includes incidences of vandalism. I will monitor the namespace and revert & warn as necessary. Jtmorgan (talk) 00:56, 14 September 2015 (UTC)[reply]

The problem with Flow is: It supports only threaded conversation, it's completely disconnected from the normal wikiverse. So, if there are only conversations, no other "use cases" like on article talk pages, it may be OK. It could be fine to have both side by side: Flow just for conversation, not real collaborative working, and another page for collaborative working in the same environment that's everywhere else in the wikiverse. IIRC that's done with LQT and a normal talk page somewhere, in wikivoyage or -source, I don't remember yet, where the LQT-part is internally calle "troll-space". --Grüße vom Sänger ♫^(Reden)_{superputsch must go} 07:09, 14 September 2015 (UTC)[reply]

Theo10011, I'm not sure what 'defensiveness' you are picking up on, but know that I only read your comment ("This is helpful EpochFail but honestly, I was expecting a bit more.") as asking me to explain my reasoning better. I accepted the challenge and did so happily, so what made you feel the need to ask me to calm down? Did I not follow up with a useful framing and a reasoned argument? Please don't ask me to calm down or you might end up making me upset with your assumption! I'm sure none of us are looking to make anyone upset, so I think we're done with this particular meta conversation.

The researchers in question knew there there was a discussion mechanism and they had gone to the talk page looking for it, but did not see something familiar to them, so gave up. It's not the markup that is the problem (though that is a small part of it). It's in knowing what to do. This is what I mean by literacy. When there's an explicit "Post" and "Reply" mechanism, people who are familiar with threaded discussion will know what to do. Just like people are familiar with the idea of registering an account and filling out a captcha. These things have become a common literacy of the internet. Markup-based talk pages, however, only exist in the context of MediaWiki. How does anyone know that they are supposed to start new threads on the bottom? How does anyone know how ":::" results in an indent and that "~~~~" results in a signature (and it's up to them to sign)? They learn it here. How does anyone know how "post" and "reply" works? They learn it in email, PHPBB, facebook, researchgate, github, or basically anywhere else on the internet where discussions take place.

Now, I'd also like to address a bar that you have set here. You ask about Flow: "will it save wikipedia? will it instantly make everything better? or save a hundred kittens? ..." Why does it need to? Can it simply be a better discussion mechanism in this context? Do we need to save hundreds Wikipedia Kittens in order to change anything in the Research namespace? "most importantly, would you or anyone else be happier?" Yes. That's why us researcher Metapedians are here asking for it. I think I've made that point clearly. --EpochFail (talk) 16:13, 14 September 2015 (UTC)[reply]

I forgot to mention one more thing. One of my current projects aims to bring intelligent quality control tools to all Wikimedia Wikis (fun story if you care about how this converted from a 'volunteer time' project to a 'staff time' project if you care to hear it). See Research:Revision scoring as a service and ORES. If you feel overloaded with vandalism here on Meta, we can prioritize getting models online for this wiki in the short term. --EpochFail (talk) 16:19, 14 September 2015 (UTC)[reply]

I think we are done here. You think you were handling this well before I came along, so do whatever you want. Theo10011 (talk) 18:39, 14 September 2015 (UTC)[reply]

I'm sorry you've gotten frustrated. We're only trying to engage with you with on the discussion points you have raised. I'm a little bit frustrated too that you have chosen not to address the points that I raised, but know that I deeply appreciate your work to return this conversation to a civil tone. I hope that you'll reconsider engaging in this conversation and driving it towards civil discourse. --EpochFail (talk) 21:43, 14 September 2015 (UTC)[reply]

On the contrary, I think you were the one getting frustrated. After saying things like, "...don't ask me to calm down or you might end up making me upset." and, "I'm sure none of us are looking to make anyone upset, so I think we're done with this particular meta conversation." I was trying to avoid acrimony and making things worse, so I disengaged. I was, and still just want to help. You also took quite a condescending tone in your reply in the last two paragraph. I don't know how you misconstrued "more comments" or "more" - I meant more people. (English isn't my first language, I'm a non american/european. I asked if someone else besides you had anything to say originally - that was all). You've mentioned your "volunteer time" and "staff time" more than a few times, but please understand all we have is just one thankless "volunteer time" and I'm using mine to make shitty templates and suggest alternatives and discuss things out, for the benefit of those reading. I honestly don't feel strongly about Flow either way.

I really didn't mean that you had to prove anything to me or defend anything - I'm sorry you got that impression. In fact, you need to take me out of the picture completely. Talk to everyone else through me, not to me. Get a conversation going again - just on the facts. I was trying to light heartedly suggest that this isn't the be all and end all that you need - you misunderstood my intentions. And if we can't get consensus, It's not the end of it all - you still have to work here, even with us - let's not ruin a civil, working relationship over a disagreement. You owe it to your work and we owe it to each other.

Lastly, ask yourself, if my intention was to do anything but help, would I be reasoning as hard as I did up there (those walls of texts aren't fun to write either, man ;) ) or suggest alternatives or set up templates for you? It's quite easy to just ignore it all, you know. I thought maybe we could find a middle-ground, or alternatives. Yes, hacks and templates aren't pretty or what you need but how about you try them out - maybe they help in the mean time? You can try them out from tonight without anyone's interference. It's not constructive to think you or your team know better while everyone else is either wrong or biased (I've been in that mindset a lot myself so I speak from experience) - maybe their concerns have legitimacy, hear them out. But most importantly, give this time and please don't make it about individuals. Regards. Theo10011 (talk) 23:26, 14 September 2015 (UTC)[reply]

I'm sorry to have offended you. I think your template idea would be a great one if we were trying to drive people to the talk page -- which I think is a fine idea, but not the problem I'd like to address with Flow (technical literacy). I'm sorry that this wasn't clear in my earlier responses. --EpochFail (talk) 22:31, 15 September 2015 (UTC)[reply]

I'm not offended man. It's fine, EpochFail. As someone else mentioned, this probably might not be a good time for this debate - given the discussion about flow's future and viability going on elsewhere. Also, RfC's here are slow - they take time. I guess you can try other approaches in the mean time but that's your call. Either way, ping me if you think I can help out in any way. Kind Regards Theo10011 (talk) 20:37, 16 September 2015 (UTC)[reply]

Research/analysis of Flow spam?

I just looked at mw:Talk:Beta_Features/Hovercards and it's full of spam. And this not new, i saw a lot of those on flow pages (+notifications). And i have never seen so much spam on Wikipedia talk pages (maybe i missed out on some pages?). Looking at the last 100 edits in the page history, i count 28 deletions (for the last 500 it is >100 too). Is someone looking into this? phab-link? --Atlasowa (talk) 16:09, 15 October 2015 (UTC)[reply]

At phabricator i learned that we don't even know/track how many Flow pages exist (T115110 Track Flow activation). This somehow starts to remind me of the selfie-pocalypse. --Atlasowa (talk) 16:20, 15 October 2015 (UTC)[reply]

Inactive RfC, time to close?

This RfC has been inactive for more than a month as of today. I'd suggest any uninvolved admin have a look and close it. —Marco Aurelio 01:18, 27 November 2015 (UTC)[reply]