User talk:LilaTretikov (WMF)

Archives

---

1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13

Closing the loose ends of the Article Feedback Tool

Hi Lila. Glad to hear you are making a deep review of Flow, and that communication is on top of your list. With regard to that, when AFT5 was shut down on English Wikipedia, we were promised (back on March 4) "In coming days, we will archive the feedback data in a public hub, so it can be accessed without the tool. We will post on this thread as soon as that data archive is available. ... To be continued." -- and then there was no follow-up there, nor here either. Not that I really think having the feedback data in a public hub is that important, it's just that I've neither seen it, nor an explanation of why it won't be forthcoming. It's a little frustrating to have to make edits that paid staff should be making. I think a lot of editors, probably at least a plurality of editors, are convinced that Flow in anything resembling its present form will be D.O.A. and will meet a similar fate as the Feedback Tool. Which is why we are not keen on wasting too much time to help the developers debug it. Your deep review cannot come soon enough. P.S. The one thing that AFT5 database might be most useful for is some sort of big data (i.e., computerized) analysis for a high-level "big picture" overview of what our readers have to say. It's just way too much data for your relatively small core of active volunteers to manually wade through and make much sense of. Regards, Wbm1058 (talk) 18:58, 1 October 2014 (UTC)

@Wbm1058: Quick note: I've asked about the AFTv5 data, and they do still plan to put that data online, but higher-priority tasks had gotten in the way of cleaning and documenting the data. It might take a few more weeks, but I'll keep nudging away at this one. Thanks. Quiddity (WMF) (talk) 00:42, 3 October 2014 (UTC)

I have asked the team to respond where the original comment was made. In general I requested that we always close a loop on any externally set expectation like this going forward, even if we fail to accomplish it. If you see this not being the case going forward, please bring it to my attention. -- LilaTretikov (WMF) (talk) 18:43, 8 October 2014 (UTC)

Why is Flow DOI?

I understand that AFT did not take into account the output and how it would affect the normal editor pipeline (I will ask about the plans of it). As we test ideas we now keep them away from normal editor flows. That said.. why, in your opinion Flow is D.O.I.? What is it missing? -- LilaTretikov (WMF) (talk) 02:40, 3 October 2014 (UTC)

It's a discussion tool, not a collaboration tool. Wikitext talk pages, because of their freeform nature, are both (but because of that nature also have some disadvantages). Any replacement for current talk pages will need to provide basically the same possibilities and functionailities. One of the many unanswered questions on enwiki FLow talk page was a commant I made about the funamentally flawed nature of how Flow was presented to us. What the Flow page has, is a list of things that current talk pages lack or do badly, and that Flow would solve (a debatable list, but that's another discussion). What the Flow page doesn't have, is a list of things current talk pages do well or very well, and that Flow must retain at all costs. While this may seem logical, the end result is that Flow at the moment is completely geared towards those things missing in current talk pages, but has little or no functionalities currently available in talk pages, which are necessary for a smooth functioning. Basically, the WMF tells us "look at all the nice things Flow can do which current talk pages can't" (and even more "look at all the nice things Flow may perhaps eventually do!", while the editors tell them "look at all the nice things current talk pages can do which Flow can't".

Now, it looks as if they are coming back slightly from their original "let's discard everything" position, where they declared that things like undo, move, ... wouldn't be necessary anymore. But they have a very long way to go before Flow will indeed be a potential replacement for current talk pages, if ever, and they will need to show a thorough reconsideration of the goals and requirements of Flow if they want it to succeed instead of going the way of the AFT. Fram (talk) 06:33, 3 October 2014 (UTC)

I agree with Fram. Flow in it's current state is just a useless babble tool, and has nothing whatsoever to do with current talk pages. They are called "talk" pages, but are far more, talking is just a very tiny bit of it.As Flow is atm completely incapable of doing anything useful besides implementing a non-wanted forum-like gadget, nobody will help develop it with any enthusiasm, it's lost time to invest in this crap. Maybe there are some uses for such stuff outside the Wikipedia universe, but that's irrelevant, WP and derivates are what's important, the other stuff is just nice-to-have and has to deal with solutions developed for the real project.

Up to now there's no indication that Flow will even remotely be able to replace the collaboration page needed for article improvement, what is the prime goal of that page. It could be used as a third layer besides articles (article itself, current talk page and new forum), and will be useful to attract trolls and the like for it's troll-friendly look and feel, so it could be used as a troll-space and ignored by real editors, but I suspect that's not the use you might want and invest a lot of time and money in.

As I again forgot to sign: The only good thing about it is auto-sign, but that should be possible to implement in the normal editor as well. --♫ Sänger - Talk - superputsch must go 12:04, 3 October 2014 (UTC)

These comments seem to be saying much the same, in a different way, as my remarks in a thread above on why I characterize Flow there as having failure built into its core concept.

"Troll-space" is a common nickname, on en.wn, for our opinions pages, which are entirely separate from the collaboration pages we reserve for coordination of development and maintenance of the article content. Readers discuss the article on its opinions page, and that was kept entirely separate from collaboration on the article even in the early days of the project when the opinions pages were ordinary wiki pages. Now the opinions pages use Liquid Threads; the community agrees that Liquid Threads is better for the non-wikimedian readers who want to discuss the news, and the community also hates Liquid Threads with a passion and agrees that it would be utterly useless for other purposes. We've discussed Flow, and the current sense of the community is that in its current form Flow would be less useful on opinion pages than Liquid Threads. It seems that with major improvements Flow might be made an actual improvement on Liquid Threads for use in troll-space, but only for use in troll-space.

This is ironic since it's pretty universally recognized at en.wn that the Foundation wouldn't lift a finger to provide Wikinews with any new software no matter how desperately we needed it; yet we may be one of the few sisters who might have a productive use for a major Foundation software development initiative. --Pi zero (talk) 13:05, 3 October 2014 (UTC)

As a gesture of goodwill and appreciation, I hereby grant Wikinews the exclusive and perpetual right to be the sole users of Flow. :-D Fram (talk) 14:35, 3 October 2014 (UTC)

I basically agree with all that's been said above. Talk pages need to be flexible enough to support volunteer-developed technical solutions such as en:Wikipedia:Requested moves, a system which, as the current Chief Operator, I can tell you works very well, thank you. Flow, in its present form, would completely break it. There may be room for incremental changes on certain, special-case talk pages, but Flow is attempting to bite off way too much at once. Perhaps allowing editors to optionally turn on "Flow mode" in a specific section of a talk page might be useful. The editors working en:Talk:Main Page are fighting something of a vandalism or "clueless edit" problem, as a large proportion of edits on that page are reverted. That could be understandable as it is the first place a reader coming from the website's homepage is actually able to edit. Perhaps clicking the talk tab on the main page shouldn't bring up the usual talk page immediately, but rather some sort of non-editable wizard that forced the reader to respond appropriately to a number of yes/no questions before actually activating the talk page. A trade-off between convenience for those wanting to post legitimate messages there, versus convenience for those responding. I'm thinking spammers won't find it worth the effort. Just an example of finding problems and then designing solutions for them which are compatible with existing systems. I still don't have a clear handle on the problems the Flow designers think they're trying to provide solutions for. Wbm1058 (talk) 19:26, 3 October 2014 (UTC)

The claim in en:Wikipedia:Flow that "free-form wikitext talk pages present a significant barrier to new users" failed verification. I just took a look at mw:Flow/Research/User Test Data and watched the two videos there. It would be nice if these test subjects were also asked to do the same tasks using the free-form wikitext version of that page, so we can confirm whether or not they thought that Flow was an improvement. I noticed that despite the claims that Flow is a more intuitive interface, the word "confused" occurs 16 times on the user test data page. I also note that to answer the question, "Can you find an overview of all discussion topics?", rather than finding and clicking the button to collapse the discussions to just show the title, and then count them to find that there are a total of 8 discussions on that talk page, all a reader of the free-form wikitext version needs to do is take a quick glance at the numbered table of contents at the top of the page. -- Wbm1058 (talk) 17:39, 4 October 2014 (UTC)

What is (Flow) missing?

1. It lacks BRAKES.
2. It lacks Community Support.
3. It lacks all of the power and flexibility of all pages being equal. Article Space = Talk Space = Every other Wikispace, all tools and all skills and everything we create seamlessly transfers across all of Wikipedia.
4. It lacks a natural filter that mostly avoids people-with-no-intent-to-edit from causing seriously disruption. This is especially critical when hyperpartisan website with substantial traffic twice LINKED DIRECTLY TO ONE OF OUR TALK PAGES because it wanted its own ATTACK-PIECE inserted into our BIO OF A LIVING PERSON. Only a handful of non-editors posted there, but is was still enough to significantly disrupt and inflame the talk page, damaging our effort to properly and safely manage a living person's biography. If the Talk page were replaced with a Flow CHATBOARD we'd have been screwed. The only "solution" I've heard is the new moderation development to fully vanish "Hidden" content from Flow pages, which would only have made things worse. It is utterly toxic to an atmosphere collaboration and consensus building. Anyone hit by Vanishing, or anyone siding with them, WILL view it as censorship and start screaming louder. Any new potential editors hit by censorship are likely to feel bitten and get run off. Anyone wanting to push their own policy-violating agendas will be enraged by censorship and become even more disruptive. Alsee (talk) 13:09, 5 October 2014 (UTC)

"It lacks BRAKES." I was just making this analogy in my head last night.

• Cars are too hard for teenagers to drive. They don't want to take driver's ed classes or any driving tests, so let's just make it easier for everyone to get around by dismantling our road infrastructure and start rebuilding it from scratch. Everyone knows how to walk, so we'll start with a nice foot-path system.
• Would you want to drive a car that literally anyone can build? Would you trust it to keep you safe? Wbm1058 (talk) 16:34, 5 October 2014 (UTC)

So what I am looking for are the requirements for this project: what do we want to improve, what are we willing to let go to get those improvements. What I am seeing in this thread is that there are no improvements that are worth any loss -- i.e. we are not willing to give up any flexibility. Am I understanding right? -- LilaTretikov (WMF) (talk) 16:49, 5 October 2014 (UTC)

I too have become increasingly sceptical watching (and sometimes contributing to) the Flow talkpage on enwiki. Some technical changes that have recently been announced for the near future may change this again a little. The Flow development currently seems (to me and apparently others, but that impression might be wrong) eager to build an easy to use discussion medium focussing on the needs of new editors, while procrastinating on issues many experienced editors deem essential. And yes I too think, that particular approach, something along the lines of let's build an easy to use discussion software for newbies and worry about collaboration among experienced editors later, is doomed to fail. Detailed collaboration on content (not restricted to formalised venues such as e.g. those linked from d:Q5950048) is something very central to our mission and something that sets us apart from (other) social media sites and discussion fora. Measured in volume it might appear negligible on most talk tapes, but just building yet another discussion software and screwing everything else back on later is in my opinion not a solution to our problems. The original idea behind Flow (as far as I understand it) has more potential, namely making building blocks for work flows (only one of them being discussions sensu stricto). We need a better collaboration tool for experienced editors that is also easier to grasp for neophytes (and yes I see the desperate need for the latter), not an easy to use discussion medium that also decently works for other purposes. I guess, the editor communities might be willing to accept trade offs and sacrifice some flexibility in exchange for gains in other areas. But some of the areas in which trade offs might be accepted appear to be currently very high on the priority list for the developers. --HHill (talk) 19:16, 5 October 2014 (UTC)

Personally, Lila, yes, I am not willing to give up any flexibility. Wikitext is too versatile to ever replace all its functions and even with Flow people would have to learn a new way of creating workflows – you're simply replacing template syntax with a system which has not yet even started to be built. And the staffers think it's ready for even a partial rollout? BethNaught (talk) 21:24, 5 October 2014 (UTC)

Lila, I think this point was made during the mailing list discussions after the MediaViewer blowup, but first, not everyone reads or follows the mailing list, and second, there was a flood of traffic at that point. The core functionality of talk pages that must not change, the absolute critical component, is that anything possible on another page is possible on a talk page. As a sampling, you can paste in an edit you wish to make to a protected page and ask that an admin make it, you can post in parts of the article formatting you're having trouble with and someone can fix them for you, you can insert an image under discussion while it's being talked about, you can refactor the page to put the discussions in any given order, you can transclude another page, you can utilize any template...in short, the talk page can do absolutely anything possible on every other page. The preceding examples are a tiny sample, and you could not account for those few cases (or any few cases) and say "Alright, we're good now." The talk page must be able to account for any edge case, and less hardcoding and more being a wiki is the only way that will work. Any system for which that does not hold true is not acceptable. Erik did, during the above-mentioned discussion, talk about building some "Flow-like" functionality on top of existing talk pages without fundamentally removing them. That is a good way to look forward. Removing the flexibility that can come only from the talk page still being a wiki page is not a way forward, and no matter how pretty it is and how cool of things it does, it won't be accepted. So not no loss, in answer to your question, but that core flexibility must remain. That one's not negotiable, and not just to me. Seraphimblade (talk) 05:21, 6 October 2014 (UTC)

"So what I am looking for are the requirements for this project: what do we want to improve, what are we willing to let go to get those improvements. What I am seeing in this thread is that there are no improvements that are worth any loss -- i.e. we are not willing to give up any flexibility. Am I understanding right? -- LilaTretikov (WMF) (talk) 16:49, 5 October 2014 (UTC)"

While some may not want to loose anything, and others are willing to drop some things (I have e.g. no problem with autosigning and not having custom sigs, but I understand that others feel different about this, and that for e.g. people with names in Chinese characters an alternative signature at enwiki is preferable), I think the problem is that the Flow team has not made any indication at all of what they want to keep, and which things they believe can be dropped. The strong impression they give (or gave) is that everything will be dropped, and a new system will be build that adresses some of the things missing in wikitext talk pages, but without any indication of what will be kept. The logical reaction to that is one of extreme defensiveness, as people are quite attached to the system which had many aspects that worked extremely well.

If people (established editors) don't get the strong impression that the Flow team understands what talk pages do now, what is good and needs to be kept in some form, and only take into account complaints or remarks about what is missing (autosign, auto-indent, the occasionel need to have talk pages across wikis) and use those as the central components of the new system they develop, then many people will dismiss Flow right from the start, as it doesn't address their needs and isn't build around what is most needed, but around some fancy extras. Comments like those made by Jorm that Flow is built for mobile use ("The Future!") and that desktop use is apparently a secondary thought, something that also needs to work but isn't central to it, only make things worse of course. See en:Wikipedia talk:Flow/Archive 10#Wiki misconceptions: "Jayen466: Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past. --Jorm (WMF) (talk) 00:47, 30 August 2014 (UTC)". Also see the next subsection on "Misconception: Mobile editing is the future for talk pages". And note the total lack of any response from Jorm about his statements, despite being pinged by different editors. Making "ex cathedra" statements and then ignoring any feedback is typical of the interaction between some WMF staffers or devs and the wiki-community, and is another reason why the WMF gets such a backlash for many of its releases.

So, your questions are good ones, but perhaps they should have been asked at the very start of the analysis of Flow, not a year and a half (or how long is it?) into the development process, when much of the damage is already done. Fram (talk) 06:50, 6 October 2014 (UTC)

Yes they should. That is a fundamental thing about building products. This is why I believe that making a public, understood process is the number 1 on the priority list for our product team. It should specify how we decide what we build, what it means to be successful with it and how we know when it is ready for mass-consumption. You can help get us all there by engaging early, giving advice and keeping an open mind -- we won't get it right every time and it will take time, but we are working really hard at raising our own standards. -- LilaTretikov (WMF) (talk) 22:20, 8 October 2014 (UTC)

What I am seeing in this thread is that there are no improvements that are worth any loss -- i.e. we are not willing to give up any flexibility. Am I understanding right?

I do not see that as accurate at all. I am staggered when you say you think we're not willing to lose anything. You don't seem to appreciate the pervasive loss involved. The fact that ArticlePages = TalkPages = AllPages carries a million implications. Our entire Wikiworld has been built around the simplicity, power, and flexibility of that fact. Countless posts have been made on what we'd lose, but those discussions probably haven't been filtering up to you. Should I post a large section here, detailing the loss? Considering the importance, I could even initiate an encyclopedia-style executive summary for you. We're good at building that sort of thing (chuckle).

Aside from the loss of Wikipages itself, I think your valuation of the upside of Flow is overly optimistic, as well as failing to consider problems it could create.

You view Flow as an enormous value in exchange for insignificant loss. We view Flow as questionable value in exchange for a pervasive loss.

You are misreading me I think.. I am asking if we are willing to have trade-offs (I did not say anywhere that I believe that Flow is an enormous value). It sounds like the answer is a yes. If so it would be great to have a list of what we are willing to give and what we want to get. And it would be critical if there were *a lot* of editors agreeing with/supporting that list. You may say I should have this already... but unfortunately I don't. If you can help bubble it up -- it would be really awesome. Getting to something like that would be instrumental to improving our software. -- LilaTretikov (WMF) (talk) 22:11, 8 October 2014 (UTC)

I think it would be very difficult, if not impossible, to make a list of all the features of wikitext talk pages we're using. There's just been too many functions and workflows and use cases growing on it in all those years. Even more difficult would be to come to an agreement on which of these things are essential, which should be made easier, in which cases we could live with cumbersome workarounds, and what we could or should drop entirely.

Maybe we should tackle the problem the other way around: In the current plans for Flow, which features are missing? Which details need to be implemented and is there anything crucial that can't be done at all with the current architecture and needs a change in that?

I personally don't think it's impossible to turn Flow into something that can eventually replace wikitext talk pages. It will take time and effort and discussions, sure. But the kind of people who shy time and effort and discussions don't take up the task to build an encyclopedia. — HHHIPPO 22:43, 8 October 2014 (UTC)

I am asking if we are willing to have trade-offs... It sounds like the answer is a yes. If so it would be great to have a list of what we are willing to give and what we want to get.

We're talking specifically about Talk-Flow, right? If so there still seems to be a miscommunication. There's only a single item available to put on the "give" list. The only "give" is to completely destroy the identity-relationship between ArticlePages and TalkPages and AllPages. There would have to be some pretty huge upside to justify destroying that identity. We can move anything from anywhere to anywhere. Anything that works in one place works in all places. There's only one skillset and it works everywhere. When I found this awesome article analysis tool on wmflabs.org I immediately used it to gain insight into editor-dysfunction on a TALK page. It didn't even cross my mind that it was an "article analysis tool", all I saw was a page analysis tool. We don't have Article pages and Talk pages and User pages, we simply have Pages. A page is a page is a page is a page. And yeah, I tested that analysis tool on a Flow page. It crapped out showing nothing, because Flow is not a page. Alsee (talk) 08:29, 9 October 2014 (UTC)

One way you could instantly defuse the conflict would be to firmly establish that Flow is merely a new page-type you are making available. That would mean not caring whether individual wikiprojects decided to use Flow. You'll get zero pushback on anything, if the local community gets to decide whether to activate it. Or you could reverse your approach: Instead of building a discussion system and trying to bolt everything else on to it, start with our current pages and try to bolt better discussion support onto that. Alsee (talk) 23:01, 7 October 2014 (UTC)

Are you saying this should be a new page around an article in addition to the talk page? What would be the main problem that it would solve and how would it be different from the talk page? -- LilaTretikov (WMF) (talk) 22:03, 8 October 2014 (UTC)

We might need that for a while, indeed. We can't transfer all our workflows from wikitext to Flow over night. So having both pages, with Flow taking over more and more tasks, but the old talk pages still being available for things not migrated yet, and as a safety fallback if the new version fails, could be a solution. There's more to say, but I need some sleep now, hope to get back to this soon. — HHHIPPO 22:43, 8 October 2014 (UTC)

Maybe I was a little unclear. I was trying to suggest:

LocalWiki.Config(Flow); and LocalWiki.CreatePage(PageName,PageType);

It would definitely calm people's fears if that were firmly established. If a Wiki doesn't like Flow they could Config it off, and if they do like it they can decide which pages are created as Flow. Alsee (talk) 08:29, 9 October 2014 (UTC)

I agree. Perhaps Lila would be well served by reading some of the lengthy discussions on Wikipedia about flow for perspective and at the same time, see some of the provocative comments from members of the WMF about it and the communities concerns. Having a tool like flow isn't the problem, the problem is the leadership at the WMF's refusal to hear the communities concerns and charge ahead with zero regard for the people actually doing the work on the project. I for one do not see Lila, Jorm or eben Eloquence (aka Erik Mohler) doing much editing on Wikipedia outside discussion topics. So I am left with the feeling that teh leadership of the WMF really doesn't care about the volunteer workforce or whether we have concerns about the tool. The appear to view the volunteers as a burdon and a replaceable and expendable resource. With that said, there are obvious improvements that are needed of the WMF insists on forcing Flow onto the community unless they want the community simply turn it off as they did With Visual Editor. I won't go into them here, because they are available in multiple locations. All Lila or anyone else needs to do is look and keep an open mind. As recommendations go though, if the WMF wants to use Flow then I recommend they start by using their own talk pages. Lila, Jorm, Eloquence, etc. That way, they can see first hand the good and the bad about using the tool and it won't be the community complaining, they will get to see it. Reguyla (talk) 20:44, 8 October 2014 (UTC)

You mean like this? — HHHIPPO 21:51, 8 October 2014 (UTC)

Yep, thats one. Thanks for pointing that out. I wasn't aware that he was using it. If they did that as a standard implementation on their userpages across all namespaces where they are active, then that would allow them to see how "functional" the app is. For example, I am using an older version of IE and it does not display well on this machine. I realize that IE isn't popular and old versions of software are easy to hate for a variety of resaons. But there are no, or very few display problems, with these older browsers with the wikitext versions of the talk page. Another good example is the "Wall" concept on Wikia. If you use older browser versions it doesn't work, so many users cannot comment. So in the process of making things more pretty for some users we alianate others. Thats not something we should be doing and as developers of an "encyclopedia" we need that information to be available to readers and other editors. Its less important from that aspect that the text be in text bubbles of different colors with rounded corners if it means a lot of people cannot use it. That does not mean that the WMF shouldn't develop these changes for other users of the Mediawiki software, it simply means they shouldn't be forcing it down the communities' throats. Reguyla (talk) 14:00, 9 October 2014 (UTC)

Having the WMF deploy Flow on Wikimedia won't help. They don't use these pages as a workspace, their work doesn't involve building stuff out of wikitext, they have 0% of the use cases that we do. They use these pages strictly as a message board. From that point of view Flow is a nicer message board than Talk pages. Alsee (talk) 17:53, 9 October 2014 (UTC)

Your absolutely right and it won't show all the use cases, but they will see some of the problems and it will allow some testing to be done on the tool without sacrificing the important stuff to do it. Most of the WMF folks don't edit, so whatever conversations happen on their talk pages are things like this and don't really pertain to "building an encyclopedia" so that won't be affected. I also wouldn't be opposed to making it opt in for those users who "want" to use it (which it may already be, but I don't think so). The fact is though, its a long way from being ready for implementation and I would not want to see another Visual Editor/Mediaviewer debacle because they released it a year too early just so they can meet some imaginary internal milestone and keep a bonus at the expense of the project. Because that is very much the perception that many have about these projects. I have no doubt that the WMF is irritated with all these comments and discussions, but the fact is, if no one cared about the project in some way, then they wouldn't care about these changes and the effect they have. The fact that so many people are commenting and giving feedback shows that in some way, right or wrongly, they care about the projects. I would also add that it's infrequent that me, Fram and Seraphimblade agree, we are like North, south and East in terms of viewpoints, so that we all are in some kind of agreement here speaks a lot about the issue at hand. Reguyla (talk) 18:22, 9 October 2014 (UTC)

Re: what we are willing to give and what we want to get

I am asking if we are willing to have trade-offs (I did not say anywhere that I believe that Flow is an enormous value). It sounds like the answer is a yes. If so it would be great to have a list of what we are willing to give and what we want to get. And it would be critical if there were *a lot* of editors agreeing with/supporting that list. You may say I should have this already... but unfortunately I don't. If you can help bubble it up -- it would be really awesome. Getting to something like that would be instrumental to improving our software. -- LilaTretikov (WMF) (talk) 22:11, 8 October 2014 (UTC)

Good news! Unlike Hhhippo, I think this is possible. :) LiquidThreads has existed for years and thousands heroic users suffered the pain of using it in order to provide us with this information. Bugzilla has a convenient list of 693 issues, of which 284 unfixed; you can even filter by number of votes. That's a treasure trove of insight, completely unexplored so far by those who imagined yet another discussion system. Hire someone to compile a summary of the LiquidThreads component (and translate it to WMF-speak), if needed... and you'll mostly have what you asked. I'm afraid asking the community members to do your homework won't bring you very far, though it might have worked 2 or 3 years ago before the project started. --Nemo 15:44, 9 October 2014 (UTC)

It would also have worked 2 or 3 years ago because the WMF hadn't yet burned all their bridges with the community. It really boils down to this: Is the WMF willing to sacrifice a large chunk of its current editor base to implement Flow/MediaWiki/Otherprograms by force in order to maybe gain a few others? If that is the case and the WMF really doesn't care about the volunteer community, then feel free to ignore every comment that we are all saying to the contrary and implement all these things. If the WMF does actually care about the Wikipedia and other projects success and view the community as an asset and a partner rather than as as an opponent, then they would be better off listening to the advice and complaints from the community. The only reason the community is now pushing this hard and being as terse and frank as they/I/we are, is because the WMF has shown time and time again that it doesn't care what we think. If they want to change that perception, then it will take time and actionsn rather than just words. Reguyla (talk) 18:16, 9 October 2014 (UTC)

What would an improvement look like?

Lila, you said (somewhere up there in this thread),

So what I am looking for are the requirements for this project: what do we want to improve, what are we willing to let go to get those improvements. What I am seeing in this thread is that there are no improvements that are worth any loss -- i.e. we are not willing to give up any flexibility. Am I understanding right? -- LilaTretikov (WMF)

I'll take that to mean improvement to wikimedia.

As others have remarked, what Flow breaks isn't merely a "specific" feature, or even any particular set of specific features, but the primordial property that talk pages are pages of exactly the same kind as their articles. There's simply no substitute for having both pages use wiki markup; it's not a matter of degree; if the talk page isn't a wiki page, then it isn't. I guess that's an important principle, worth spelling out.

An improvement doesn't break the wiki-ness of pages. If it breaks wiki-ness, it's not an improvement. An improvement might change what things look like (probably subtly rather than drastically, but there I'm speculating). It might change some aspects of what things do (speculation is difficult, on that). It might add to wiki markup.

So this is true IFF we exist in the universe of discourse that assumes that wikitext exists in perpetuity. In this case it may be that we don't want to make changes to Talk -- at least no significant ones. Yet, we already know what wikitext presents a barrier of entry for a large portion of some less technical, but very important users: educators, scientists, historians, women, emerging regions, etc. We are often effective at blocking those people on entry to our universe (or making it really really hard to get a visa). And as the changes in technology progress this chasm is becoming wider every day: a half to two thirds of world's population will not have access to a PC, but will be connected to the internet in 5-10 years. What does this mean to how people will be contributing in that timeframe? -- LilaTretikov (WMF) (talk) 15:55, 10 October 2014 (UTC)

And again, this ideology is wrong: If i want to do archery, i need to learn to shoot the bow. If I want to swim, i need to learn the technic or I will die in the pool. If I want to contribute to Wikipedia I need to learn some basic mark-ups. I know many women and scientists who would actually get offended by this way of thinking as if this would be a barrier that they couldn't take if they wanted to ... And about the global south: Again try to write a good article around 30 kb on a mobil device (letting beside that there would be a lack to the basis ressources that we use at the core: books). You just see a number of people with moble phones and think "uh, they can contribute", but there is much more about contributing to Wikipedia than just the internet access. Really, please write one good, middle long article, do the research in different sources that is needed, organize the information in a god way, put it on the "paper". And then you will see why Wikitext needs to remain at the core. That doesn't mean that you can't offer an alternative, but if you want to keep the quality level you can't go without it. And please, don't put sand in our eyes: You have the money and workpower in San Fracisco to maintain both ways parallel. And if you can't do it right now then it is a matter of mismanagmenet, not of fundamental causes that speak against it. --Julius1990 (talk) 16:29, 10 October 2014 (UTC)

The question isn't if you want to do archery or swim. The question is: you want to get food or get to the other side of the river and there are many ways towards that goal. Archery and swim are just two of them. -- LilaTretikov (WMF) (talk) 17:14, 10 October 2014 (UTC)

And I was very clear that it is not a barrier for ALL audiences and it is not a barrier for the lack of intelligence by any stretch of imagination. And it is not the only barrier (and may not even be the worst). It is nonetheless a barrier to engagement as the data shows. That said, I think it is important to keep in mind the true objective: engaging users in productive editing (new and old). If we keep that in mind, we can figure out the best way to get there. -- LilaTretikov (WMF) (talk) 18:09, 10 October 2014 (UTC)

Sorry, Lila, but the last big research poll indicates that those technical hurdles are the minor ones letting people not participate. And no, editing Wikpedia is not even close to get the ressources needed to survive. The analogy to getting food or water or crossing a river is being able to read our encyclopedia, not writing it. And if you get in contact with the people that don't edit, but just use Wikipedia as i get on a daily basis, then most will tell you that "not knowing how to edit" is not the issue at all that doesn't let them write articles. --Julius1990 (talk) 18:22, 10 October 2014 (UTC)

That's not what I was trying to say in the analogy. It got lost in the writing. I mean to say our goal is to write the wikipedia. Talk, wikitext, etc. are tools, not the end goals. -- LilaTretikov (WMF) (talk) 18:41, 10 October 2014 (UTC)

Can you supply the link to the research you are siting? -- LilaTretikov (WMF) (talk) 18:41, 10 October 2014 (UTC)

Sure, it is this chart of the 2011 survey. And honestly, it lets me question much of the action of the Foundation. Not that I would oppose an alternative, easy way to change maybe a typography mistake. But if you would actually be an editor, you would know that the technical skills make maybe 5% of the work and are easy to learn. Like everything needs to be learned. If you want to write encyclopedia as hobby you have to learn certain skills, like you have to do on everything else. And as long as we don't get paid it always will remain this pretty nerdy, conservative hobby, but you in San Fracisco seem to have lost that Wikipedia is and will remain something people will do in their free time (instead of sports or another hobby). And also the other points in this chart are quite intersting. The second biggest group after "happy to read" is the lack of knowledge for being able to contribute. And yes, with out ambition to provide reliable knowledge you have to make sure that the global south gets a good libarry system, gets access to research databases and so on, before they can start to contribute substantially and not just be editing typography and maybe layout. And if you would know what work it is to write a good, medium long article, you would know that this never will be the work to do on a smartphone. As regretful this may seem to some people in the WMF. --Julius1990 (talk) 20:21, 10 October 2014 (UTC)

All this has nothing to do with Flow but with VE. Regardless what system you use, you somehow have to use some kind of formatting syntax, be it html, BBCode, wikitext, or whatever. You only have to make it as easy as any office program to use, that's all.

<NB:> Why can't I use VE on this page? I don't get the option to use it.

Flow is something that breaks the look-and-feel of the wikiverse. It's completely detached from all other pages and all other working here. It's a forum system for something that's only in part something like a forum, but more important a collaboration tool for working on the article, where you test stuff and discuss this without getting into edit wars first off. --♫ Sänger - Talk - superputsch must go 18:40, 10 October 2014 (UTC)

"Flow is something that breaks the look-and-feel of the wikiverse." Do you mean aesthetically? How so? Is that a brand issue or something else? -- LilaTretikov (WMF) (talk) 18:47, 10 October 2014 (UTC)

Aesthetically, in working on it, in behaviour, in nearly everything. It's simply nothing you come around anywhere else in the whole wikiverse. It has nothing to do with branding but with consistence. Now all pages are generally the same, are workable in the same way, behave in the same way, it's totally easy to work on any of them if you have managed to find the "edit" button and write on. Now we are on the brink of a change like the one from DOS to Windows with the intended switch from wikieditor to VE. The secretaries in my university refused to use wysiwyg for years, as they were accustomed to the old white-on-blue-with-colored-markup and keyboard short-cuts. We students used the wysiwyg version, it was just a question of taste and habit. The text we worked on was marked and stored in the same way, just like with VE and normal editor.

Flow breaks with the same-ness of all pages. Not only in the look-and-feel, but the complete layout and workability of the page. It's just a dumb forum system and you can't even learn from other posts how to use wikitext correct, as they are hidden from you syntax-wise. If you want to test something about the article layout, like what table layout looks best, what title structure is better, it doesn't fit in the very restricted Flow layout and work scheme.

There may be some use-cases, where something like LiquidThreads, Flow or such can be useful (for example as the honeypot and trollspace mentioned several times on WikiNews), so it may be implemented in those restricted cases, but in general it's not useful. --♫ Sänger - Talk - superputsch must go 19:10, 10 October 2014 (UTC)

Additions to wiki markup are high-risk, because once you add something you take on a moral obligation to keep it in for a large chunk of forever. For these changes to come out right, you have to simultaneously envision a technical feature and its systemic consequences. The technical feature needs to be easy to use (which includes not making things complicated, a common mistake) and easy to implement (including ongoing maintenance). The systemic consequences should be vast and beneficial, to justify both the changes to the interface and the effort of implementation. You're likley to get into serious trouble if you neglect either half of this, technical or systemic; you can't get every systemic effect you might dream of, and many technical changes won't do anything sufficient to justify them. Finding things that work at both levels at once is an art, which I realize may be an unwelcome thought since it implies you can't produce such designs on an assembly line.

Art to me... is a byproduct of an investigation, a learning. So I'd say it is art in that sense. This is why I insist that we cannot assume that we will come out with the "perfect" design out of the gate. That we have to make some assumptions, test them, improve them. Again here, I am not thinking about wikitext as the end goal. Wikitext is the means to an end: a meaningful conversation that results in the scrupulously written article. Is there only one path to that result? -- LilaTretikov (WMF) (talk) 15:55, 10 October 2014 (UTC)

For example, here's what I came up with, after a few years of meditating on wiki workflow.

Technical (low-level): a small(ish) set of templates are provided for adding interactive elements to a wiki page. Most basically, you can add text input boxes, and buttons that do things. A button can take data from the input boxes on the page, and pass it somewhere — the receiving page can transform this data and put it into other input boxes, substitute it into the page (for display purposes), or using it to perform more substantive actions like editing a page, renaming a page, etc.

Systemic (high-level): using these tools, a wiki community can build software assistants, such as wizards, for performing pretty much any function the community wants to perform. Do they want to provide a button after each comment in a discussion, to automatically insert a reply to that comment with appropriate indentation? If the community wants to do that, it should be possible to cobble such a thing together. Likewise, a button to perform a complicated setup of a nomination of some kind, or a complicated closure. A wizard to help a newcomer plan out and create a new encyclopedia article, or a new book, dictionary entry, news article. A wizard to help an experienced member of the community review any of those things.

The key here, to my mind, is that all these wizard-like assitants are being written by the community using wiki markup, which opens up a whole new world of wiki contribution, playing to a great strength of wikis: they cut out the middleman, enabling the community to just do what the community knows how to do, rather than trying to coax a high priesthood to do it for them. Those who maintain the wiki software are only enabling the community to decide for itself what wizard-like assistants it wants and how they should behave.

So I think what we are getting at here what wikitext gives us: an infinite flexibility to create new things, without having an army of developers. A platform to invent new methods. Now here is the challenge: how can we preserve that aspect AND create an experience for an uninitiated user can understand and engage with. How we can get the this user to learn and get far towards the expert level as they want/can? So that instead of having a huge wall when they enter, they have a ladder they can walk up to. So that is our challenge. The two versions (Talk and Flow) we have now seem to be sitting squarely on the opposite sides of this challenge. -- LilaTretikov (WMF) (talk) 15:55, 10 October 2014 (UTC)

Ah yes, the myth that wiki markup is a problem. You can use that to justify any number of bad ideas. --Pi zero (talk) 17:58, 10 October 2014 (UTC)

It is a problem for *some*. The data shows that 9 out of 10 clicks on edit button (and this is not holding for new users only, the ratio here is even higher) drop off when faced with wikitext. We need to to more analisis to understand why that is, but this is definitely not a healthy ratio. -- LilaTretikov (WMF) (talk) 18:05, 10 October 2014 (UTC)

Lila, of course its a problem for "some", everything takes time to learn. Its like saying that using Microsoft word, excel or even windows is a problem for some. Contrary to what some may say, basic wikicode isn't really that hard. sure its a challenge to make some of the templates and the mediawiki pages and the like, but those aren't what these things are targetting. Also, you say the data shows that 9 out of 10 clicks on edit button drop off. Does that include blocked users, ip's and the like? I suspect it does. There is a massive number of IP's and users that are blocked for a variety of reasons. A lot of them are blocked for no reason other than its a proxy. So this causes a huge amount of collateral damage in terms of not being able to edit. If you do some analysis on the data, I recommend determining where the high numbers of edits are coming from with regards to blocks. I suspect you will find a lot of edits at some libraries and universieties that are currently blocked eventhough the WMF says they are trying to recruit more college students and GLAM folks at libraries. Its very contrary to what the WMF is trying to do though when there are a few admins on Wikipedia that are blocking more and more IP's and users and those blocks are going to throw off that edit button click count. Reguyla (talk) 18:29, 10 October 2014 (UTC)

Everything takes time to learn, indeed. Therefore should we not continually make it easier for people to learn though? That is the promise of technology And should we not focus on teaching people how to write good articles rather than learning syntax? -- LilaTretikov (WMF) (talk) 18:52, 10 October 2014 (UTC)

I will check on the blocked users ratio. -- LilaTretikov (WMF) (talk) 18:52, 10 October 2014 (UTC)

My experiences with Wikipedia learners: wiki markup definitely is a huge problem, for some learners more, for others less. Some, who are old enough to remember the old times, feel like using WordPerfect again... A good working VE is for many years on the wish list of the movement, and for good reasons. Ziko (talk) 19:10, 10 October 2014 (UTC)

I agree with both of you. We should make it easier, but I don't agree we should do that by sacrificing not only functionality, but the processes and standardizaions by doing it. I especially don't think it should be forced on the community if they don't want it. I will be the first to admin the community has a lot of problems and I am pretty well known for being hypercritical of the community and admins in particular. But to me, if the visual editor requires the user to click multiple icons or it takes more work in general for the graphical interface than it does for wikisyntax, then your not making it easier just by adding an icon representation of the function. Learning basic Wikisyntax is really only about 15 commands. Of course there are more advanced ones and sometimes its useful to understand some basic html, but they don't need to know that right away. It actually takes a lot longer to learn the editing rules guidelines, policies and essays than it does to learn the wikicode. If we just make the wikicode translation easier to find, like on the left hand nav bar, that will fix that. But IMO its more important to keep the talk pages as consistent with the article and other spaces as possible. Otherwise the users have to learn that talk pages work differently than article and other pages, Visual Editor only works with some page types and not others, VE and flow don't allow all templates and functionality to be used, but which ones? Does this really seem easier than using basic Wikicode? I will admit I some improvements with flow and VE, but I just don't think those improvements offset the negatives at this point unless you want to completely reengineer all the procedures and policies WP has in place to do things. Reguyla (talk) 13:15, 11 October 2014 (UTC)

The old markup-versus-wysiwyg argument is, well, old. For serious technical purposes, markup wins; and wikimedia is a very serious technical purpose. That said, it also doesn't follow that the only way to improve the editing interface is to go wysiwyg; so, even if one accepts the quoted nine-of-of-ten statistic is "correct" (whatever that means), and even if one sets aside the question of whether it constitutes a "problem" (whatever that means), it doesn't follow that the observed effect is caused by something intrinsic to wiki markup. --Pi zero (talk) 19:20, 10 October 2014 (UTC)

"For serious technical purposes, markup wins" -- what are those use cases (as applicable to Talk and Edit)? -- LilaTretikov (WMF) (talk) 19:24, 10 October 2014 (UTC)

I see a pattern here. We've been telling you that the fatal flaw of Flow is a big-picture property that can't be broken down into specific features, nor into use cases, and honestly you seem to still be missing the point we're making. Here I'm making another one of those sorts of big-picture observations, this time about markup versus wysiwyg, and again you're trying to look at use cases. It seems we're looking at the forest and you're looking at the trees. This stuff we're discussing here is big-picture, shape-of-the-forest stuff, and if you fixate on the trees you're going to miss key aspects of the situation.

It's a "well-known secret" in academia that serious mathematicians use LaTeX (or in some cases TeX). A few years ago, in relation to yet another claim to have solved... one or another of the greatest outstanding mathematical problems of the day, one mathematician blogged a general answer to the large number of questions he'd gotten of the form "what makes you think this result isn't right?" with a short-list of reasons to disbelieve a mathematical claim. One of the items on the list was, the authors didn't write the paper in LaTeX/TeX.

Rewriting history is a popular pastime. There's a popular mythology about the wikimedian movement that its success was a purely social phenomenon — not even explicitly claiming the technical properties of wiki markup weren't important, but simply writing them out of the story. Not so. The technical properties of wiki markup were the irreplaceable element, the enabling technology, and the social aspects of the movement (some of which are grossly overrated, but that's another story) seized the opportunity provided at that moment in history by the technology. Some other technology wouldn't have served the purpose then, and won't serve it now; every generation wants to believe that everything has changed, but fundamental dynamics don't change much, nor quickly. --Pi zero (talk) 21:40, 10 October 2014 (UTC)

For example, wikitext makes it possible to write a draft (of an article or of a message) in a text file on one's own computer and to edit it as long, as necessary, without publishing. That means that, for example, one can finish writing a response when one is less angry (I hope I don't have to explain why that is good). Copying the formatted text is going to be much harder. --Martynas Patasius (talk) 20:52, 12 October 2014 (UTC)

Yes. The same principle applies to all manipulations: because the entire page is ultimately a text string, your ability to use it isn't limited by the format. Text is the fully accessible/flexible/versatile format, which is why it's so heavily used in the UNIX world. I remember a few years ago observing someone ranting about how UNIX had proven itself unable to mature as an environment because after all these decades its software still didn't have its own data formats but represented everything as text, and I thought, wow is that person ever completely missing the point. --Pi zero (talk) 01:16, 13 October 2014 (UTC)

(Another major design challenge here is that the tools have to be resistant to the emergence of exploits. You want something that feels natural and is tremendously powerful yet whatever you do with it won't lead to disaster — keeping in mind that disasters are something computers are good at.) --Pi zero (talk) 20:59, 9 October 2014 (UTC)

(I suppose I shouldn't omit a link to what my tools look like, after several years of development: n:Help:Dialog.) --Pi zero (talk) 21:43, 9 October 2014 (UTC)

The big picture

I'm starting a new subsection, because I don't think Flow has to be DOI. To stay in that metaphor, I think it still has a chance to learn to fly before it's attempting the big jump.

By 'big picture', I here mean the rather technical question "What's the best database structure for storing discussions?". I don't mean details of the current iteration of Flow (that we can't see the source of other people's posts is a bug in Flow, not an argument against using any post-based data model). I don't mean political questions on who makes which decision, or who mistrusts whom and why. And I don't think that Lila should be disallowed to ask questions like "Why do you prefer A over B?".

By 'discussion' I mean any workflow happening on our talk pages, from a free-form conversation like this one to the more structured ones like RFx, xFD, etc.

So what kind of database structure is most efficient for storing the data shown on our talk pages? Is it a data model that is aware or the discussion structure, storing revisions of posts, topic headers, board headers and the like individually, or is it the current page-centered database model where we store revisions of a whole page, and keep any additional structure within the wikitext on that page? In principle, both data models can support the same user experience. As long as all the data needed is somewhere in the database, this is only a matter of programming the interface. However, depending on what tasks and features we want the interface to support, one or the other underlying structure might be more efficient to use.

For article pages, it's obviously most efficient to store revisions of pages rather than subsections or entire wikipedias, since viewing the latest revison of an article is by far the most common use case. But even there we don't dogmatically follow a "one page, one database entry" model: we have templates, which transclude data from different pages, we have a caterorization system with it's own database structure, and we have wikidata, transcluding data from another wiki. On talk pages, the main focus is not on the overall page as a collaboratively edited, single document, but on individual posts and their respective relations. Here it is not at all obvious that a page-centered data model is the best choice.

Now, what features do we we want for the user interface? Obviously, it should offer convenient ways to perform the most common tasks, but without making the less common tasks too difficult or even impossible. Some of the main use cases I see for talk pages are:

Reading an existing discussion

This can be helped by navigational tools like graphical indications of the discussion structure or options to collapse parts of it. Some more detailed ideas are here.

Following an ongoing discussion

I'd like to see which comments are new or updated since my last visit without reading diffs and rendering them in my head, or jumping back and forth between a diff of the source code and the rendered page. Some ideas are here, to be expanded.

Contributing to a discussion

Especially in longer threads, and for new users, having a reply link at each post would make it much easier to contribute at the right place in the discussion structure. Being able to see the previous posts, in either the source or the rendered version, while typing a reply would also help.

Finding a discussion

requires mainly a useable table of contents and an archiving system (or a combination thereof), but also search functions with various scopes (in particular if the browser's search function should be inhibited by infinite scrolling).

In my view, all this will be easier to implement and maintain with a database that is aware of the discussion structure.

Other features we need include

Wikitext

Obviously, the discussion system should support the same markup language as article pages, since it is often just that markup that is discussed. This doesn't necessarily mean that the overall structure of a talk page has to be defined by local wikitext, but it means that wikitext must be supported within posts, headers, etc. Flow already does this to a large extent, but some aspects need further attention (e.g. limitations due to parsoid, categorization, limited page width).

We don't need to have talk pages working technically exactly like article pages, since they're conceptually different in may ways anyway: on article pages there's no signing, indenting, archiving, pinging,... On talk pages, we rarely remove or edit text we disagree with, the main use case is to add another post that explains another opinion.

Refactoring/moderation

This includes: editing existing posts; changing relations between posts, e.g. when accidentally replying to the wrong one; splitting topics (moving a side chain to a different topic); splitting posts; various kinds of hatting, including collapsing, adding head and foot notes, boxes around topics, disallowing further edits to a (sub)thread, various levels of moving posts out of sight or even out of reach.

Some of these tasks require additional software functions when using a post-based data model, while they're naturally possible (though not necessarily obvious how to do) with a page-based model. For Flow there's still some development to be done here, and some design decisions to be made regarding what should be possible, how, and to whom (see also here and here).

There's probably more use cases that I didn't think of now, or that didn't come up at all yet. Both post-based and page-based data models have their strenghts and weaknesses in such an environment, but in principle, they both can do it. Obviously, Flow isn't done yet. It will need some work before it can reproduce the essential functions of the current system. But there are also functions the current system is lacking, and which would be easy for Flow to provide. So I think it's worthwile to keep working on it (whithout making at this point any definite decision on where and when it should be rolled out). — HHHIPPO 11:21, 12 October 2014 (UTC)

One of the core mistakes being made in thinking about Flow, I suggest, is that the Foundation shouldn't be trying to provide software to enable doing things that can already be done. All this focus on workflow is misplaced because it buys into the premise that you throw out the existing system that's capable of pretty much anything, in order to build from scratch a system that can't do anything except what's specifically built into it, and at first it's envisioned doing very little in comparison to the old system that's to be thrown out. Asking "what else should be supported" is missing the point. Flow is inherently a special-purpose system, wiki markup is inherently a general-purpose system, what's needed is a general-purpose system, and you can't turn a special-purpose system into a general-purpose one by incrementally adding stuff. --Pi zero (talk) 11:56, 12 October 2014 (UTC)

Except that that's how the current talk page system was created. A system designed for collaborative editing of a document was turned into a discussion system by incrementally adding stuff, through templates, conventions and also software features. Flow's purpose should be general enough to support everything going on on talk pages, no matter if you call it "workflow", "discussion" or whatever. But at the same time it can be somewhat specialized: it's not Flows purpose to edit article pages, so it can focus on talk page activities and do that job better than a system designed for article pages. The choice is not infinitely general vs. infinitely specialized, we won't manage either and we don't have either now. The optimum lies in between these extremes, in the right compromise between general purpose and special abilities.

And of course we shouldn't "throw out" the old system (how would you actually do that, ban everybody who posts a comment on a non-Flow page?). Of course we shouldn't use Flow for anything it can't do yet. I don't see that anybody is planning that, and I'll stick to discussing the pros and cons of data models here rather than hypothetical future actions of the WMF. — HHHIPPO 13:22, 12 October 2014 (UTC)

I disagree that there's any useful comparison between the evolution of the current talk system and the history of Flow. Writing templates is something you do within wiki markup. We've made the point about the article and talk pages being pages of the same kind. That's all territory that was gone over in the previous subsection, about what constitutes an improvement.

I've been trying to find another way of putting this, in the awareness that some folks (including, so it seems, Lila) evidently haven't been fully grokking... something, here. My latest attempt to capture the missing element:

The task at hand is improving a general-purpose language, which is fundamentally different from constructing software for performing a specific task. The closest thing I know is programming language design —markup languages are in the close penumbra of programming languages, at least for design purposes, I'd say— and programming language design is still largely a black art. Programming languages designed by committee are widely ridiculed. Language design has completey different dynamics than the sort of software engineering practice being invoked here. Using use cases as the basis for language design is like using a wind tunnel to design a better mouse trap: a wind tunnel is a great design tool for some purposes, but isn't relevant to the problem it's being applied to. --Pi zero (talk) 18:35, 12 October 2014 (UTC)

I din't mean to say that our current talk system and Flow have the same history. The point is that the current system has evolved from something not designed for discussions, and this evolution included software changes. I would like our discussion space to be powered by a software that is a general-purpose system for managing discussions and therefore easier to adapt to our various (and developing) needs than a general-purpose system for editing documents. I'm aware that discussions must use the same markup as articles, that's why I wrote exactly that in my original post. But I disagree that this has to be one single blob of wikitext for a whole discussion page, or that discussions ned to be strictly organized per page at all. We have already discussion pages where the actual content is stored on subpages (e.g. AfD on enwiki), and apparently that works. Thus killer-arguments along the lines of "we need exactly one wikitext page to store the data of one discussion page, everything else is useless" are already refuted by existing processes. Of course that alone doesn't mean that a future Flow will be better than our current talk page system, but it means we need to more carefully weigh up the different possibilities. Both Flow and the current system have a number of properties to a certain degree, and those properties all have pros and cons and a complicated interplay. Painting a black-and-white picture that assigns certain properties 100% to one and 0% to the other system, and postulates for each property a usefullness of either 100% or 0% is, in my opinion, not the best way to reach a decision.

I don't think improving a language is necessarily the task at hand. The topic of this subsection is the evaluation of the suitability of different data models for a whole spectrum of tasks. Using one of these models and adding improvements to the language it hosts is your suggested solution, and a good one. But not the only one. We're looking for the best one, and for finding it we should all question our current premises (and I'm happy to include myself here).

I agree that a wind tunnel is not useful for testing a mouse trap. But mice are. And if we want to catch a whole range of animals, it does make sense to think about what species those are. We could of course say "we used a shotgun so far, why do we need a trap?", but that's not how mousetraps got invented. — HHHIPPO 18:51, 13 October 2014 (UTC)

According to the current EN:WP:Flow#Release_and_features_FAQ "we may mandate Flow on all discussion pages". So yes, the plan as it currently stands is EXACTLY to "throw out the old system" and effectively "ban everybody (from posting) a comment on a non-Flow page". Alsee (talk) 00:13, 14 October 2014 (UTC)

I was replying to concerns that the WMF will replace talk pages by Flow before Flow is ready for that. The FAQ you linked reinforces my impression that the WMF's plans are the exact opposite. In any case, the deployment schedule is not really an argument for or against one or the other data model. — HHHIPPO 06:40, 14 October 2014 (UTC)

There's a problem with trust in that regard. The WMF has proven with other stuff (VE, MV) that it sometimes has a very disturbed mindset in regard of readyness for anything. The definition of "Flow is ready" by the WMF may be miles (or better years or months) away from the definition of ready by those doomed to use it. And the experience with MV shows, that the WMF tends to use force against the communities instead of arguments, that's as well not really trustbuilding. --♫ Sänger - Talk - superputsch must go 09:40, 14 October 2014 (UTC)

"By 'big picture', I here mean the rather technical question "What's the best database structure for storing discussions?". (...) I don't mean political questions on who makes which decision, or who mistrusts whom and why." — HHHIPPO 11:52, 14 October 2014 (UTC)

I believe designing a language is exactly the task at hand. One difference between designing a language and designing an "app" is, more or less —and looping back around into other themes of the discussion— that flexability/versatility is a fundamental value for a language, whereas an app is designed for a specific purpose (or a specific set of purposes). This was a point I also made, some time back, at w:WT:Flow (partway down in this archived thread).

Although language design is still a black art (as I remarked earlier), here's a principle that's pretty widely respected, I think — even though there's not always accord on exaclty how to approach it. (This was written into one of the early Scheme revised reports, and was such a good line it's been repeated in all the later revised reports, even as the actual practice of the revisions hasn't lived up to it.)

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. — Rees and Clinger, R³RS, 1986.

The emphasis on use cases is broadly trying to list features to add; my point in the above-linked archived thread was that by shifting from language view to app view you give up something you can never fully recover by adding specific features. --Pi zero (talk) 14:22, 16 October 2014 (UTC)

Some background and history

I'm not quite sure where this should go, so I'm going to just start a new section. Back in June, there was a discussion on the Wikitech-L mailing list nominally entitled "LiquidThreads - how do we kill it?" that quickly morphed into a discussion about Flow. At that time, I pointed out that Flow wasn't what communities had asked for, and that everything communities asked for was do-able in MediaWiki, if someone was actually willing to do the work. The four discussion page features that have been pretty consistently thought desirable by a range of communities over several years are:

• Automatic signatures for posts/edits
• More efficient method for indenting that is not dependent on arcane wikicode knowledge
• More graceful handling of edit conflicts

Tracked in Phabricator:
Bug 70163

• Ability to watchlist an individual thread or section of a page

Tracked in Phabricator:
Bug 738

The first two have been available for years: bots have been available to autosign posts, and adding an "indent" button to existing editing toolbar gadgets/extensions would be child's play; I understand some people have personal scripts that do this. They don't need anything more than to have the underlying software brought up to standard and then incorporated as MediaWiki extensions. There's been a huge amount of work on the handling of edit conflicts and many of the lessons learned in building VE can be incorporated everywhere in MediaWiki; this remains an issue on *every* type of page, not just discussion pages. Finally, the fourth - ability to watchlist threads or sections - remains a significant challenge in MediaWiki, and would require some very skilled and focused work that would probably include cleaning up more code than just the "how to watchlist" info. (The recent attempts to "watchlist" Flow threads through the Echo system were pretty much awful, and show a fundamental misunderstanding about the purpose of watchlists.) It's become increasingly obvious that MediaWiki is considered something to be avoided by a pretty big portion of the WMF engineering/product staff; it can be hard work to improve software that's been patched by thousands, and it's a lot more fun and interesting to write completely new software that only vaguely references the old.

Flow has been designed with assumptions that seem to come from rather serious misunderstandings about the reality of editing on Wikimedia projects. For example, the "feature" of not permitting editing of the posts of other users didn't come from the community, and it's taken almost two years of work to get the product team to concede that maybe that's not the best idea. (Corrections of links or removals of links leading to inappropriate locations, removal of "outing" info, are routine daily occurrences, and cannot be limited to "administrators". Smaller communities have few admins and are dependent on community members (including global non-admin patrollers) to help clean up these things.) The inability to remove posts is inherently anti-social, and would force users to have to be reminded every time they went to their "talk page" of the abusive posts that had been made. Again, it's taken us almost two years to get the product team to understand how really harmful this is. And that doesn't even get to the heart of the matter, which is that Flow pages are designed to attract comments, not to encourage discussion. It's actually very hard to have a multi-person discussion on the current test examples of Flow; with its (intentionally) extremely limited indenting, it's really hard to tell who responded to what statement by whom. After the rather horrible experiences we had with the AFT-5 system ("suggestions" and "comments" from readers and others that were almost completely unhelpful in article development, were often abusive or nonsensical, and were a big time sink for editor attention) we should have already figured out that it's not necessarily a net positive to make it really easy to make comments about the content. We have a limited pool of volunteers (it's even more limited on small projects than it is on large ones) and we don't need to stick them with having to patrol even more junk posts while also taking away the majority of tools they already have to address inappropriate editing/posting. Flow may be a great piece of software for...well, some other website. It isn't designed to respect the needs and uses of Wikimedia projects; in fact, from everything I've read, discussed, and seen with Flow, it's explicitly meant to "change" (or "disrupt") those needs and uses. Unfortunately, what we're being offered in exchange for this disruption is software that doesn't come close to meeting existing needs, let alone future needs.

Bottom line - it's taken a huge amount of investment of the volunteer time of some community members (up to 2 years) to get the product team to accept that some of the major design features of Flow will create more problems than they will solve. There continues to be an apparent belief that Flow will be a magic wand to change the nature of discourse on Wikimedia projects, without demonstrated evidence that better discussions/decisions result from the Flow system - the real proof of whether or not the system is useful. It doesn't matter how hard or easy a system is to edit if it doesn't result in useful discussion or decisions. Risker (talk) 17:11, 12 October 2014 (UTC)

Where are we

As you know I am holding back planned roll-out of this feature pending internal review. What I am seeing above is that many requirements requested are satisfied by it at the expense of loosing features some of you consider critical. I am asking for a full list of use cases that are to be/not covered and clear roadmap of those and will invite you to review. -- LilaTretikov (WMF) (talk) 18:32, 5 November 2014 (UTC)

Word

This time round I only have an analogy. Emacs scares away new users with it's complicated command structure and scripting. Word is much friendlier text editor in that regard. Question to the community: what do you feel is lacking in Word that you currently have access to in Emacs? We'll take your wishes seriously, and prioritize accordingly. Martijn Hoekstra (talk) 19:06, 23 October 2014 (UTC)

I know of nothing in wikimedian realms to which emacs-versus-word is even remotely relevant. --Pi zero (talk) 20:41, 23 October 2014 (UTC)

The more relevant debate is emacs vs. vi(m). Word and emacs have very different purposes; for example, you can't use Word to code, and emacs is much more extensible. On the other hand, Word users are less likely to get RSI. ;) I don't see how this is relevant to anything on-wiki, though, except perhaps the VE vs. wiki markup debate, which is a stretch. PiRSquared17 (talk) 20:52, 23 October 2014 (UTC)

"Word and emacs have very different purposes". Yes. That was rather the point. (I also named Emacs rather than vi(m) because Emacs has always been billed as the self-scripting editor which tied in nicely with wikitext augmented with templates.) Martijn Hoekstra (talk) 21:46, 23 October 2014 (UTC)

Word and emacs have different purposes. VE and wiki markup have different purposes. One contrast has no bearing on the other contrast, though. --Pi zero (talk) 00:16, 24 October 2014 (UTC)

We are addressing different problems with one tool. I am reading through many, many different requests for what Flow or Talk should do. Neither on those tools does or could do all of those things really really well. This means we either have to live with one tool that does a lot, but marginally. Or with a few specialized ones. In the analogy above: both tools are needed. Word is for editing text. Emacs is for writing code. -- LilaTretikov (WMF) (talk) 04:40, 27 October 2014 (UTC)

Avoid that "analogy", which lacks useful parallels between the supposedly analogous situations.

That's a false choice between a general tool that does a lot, but marginally, versus a few specialized ones. Setting aside that a bunch of specialized tools is inherently inferior because generality is a fundamental need here, there is no reason to suppose that the general facility cannot be made to function more smoothly. Of course, improving wiki markup requires three things.

• It requires someone to be trying to do so. The Foundation is clearly not trying. It is technically true that it's not possible to do such a thing if one is determined not to try.
• It requires someone to have deep intuitive understanding of wikis and wiki markup. It is necessary, but alas not sufficient, for them to acquire extensive experience with wikis and wiki markup.
• It requires someone to have the right sort of mind to do so. This is not at all a trivial statement. Different people have different sorts of mental skills, some of which can be acquired and others of which are innate (nurture versus nature). I would rather not have included this on the list, but the brutal truth is, no amount of experience with wikis and wiki markup will provide deep insights to someone who just doens't have the right sort of mind to support the right sort of insights.

Wiki markup has evidently undergone various changes in the past intended to be improvements, but the measures taken were often ill-advised, and it seems the Foundation, instead of inferring that those things were the wrong way to go about it, apparently decided it couldn't be done. --Pi zero (talk) 13:26, 27 October 2014 (UTC)

Case in point, Microsoft office comes with several "different" tools because none of them is all inclusive, Word can make Tables, but not as good as Excel, Outlook can do word document type stuff, but not as good as word and neither Excel nor word are good at making Powerpoint presentations or sending Email. Same thing applies here. Wikitext is a powerful and easy to use tool that has low bandwidth and browser requirements. It requires almost no computer experience to learn the basics and there are no hardware or software requirements to speak of. With things like Flow and VE, you have severe limitations of Internet browsers, highspeed internet is nearly a requirement, it takes multiple steps to do something that requires almost no effort with Wikitext. So when you add these changes with the argument of making it easier to use, you are really just preventing 2/3rds of the world from using the service at all. VE all but discourages the use of citations because it adds multiple steps to create a citation. All that VE and Flow do, are add functionality to the Core Mediawiki software, they are are and should be optional addons/improvements that are available for use by the consumers of the Mediawiki product. They should not be forced to use them as is the WMF's apparent intent and the WMF should not be forcing the volunteer communities to act as an unpaid software tester. If they want to volunteer to help test the software, and many will, then that is one thing and that is awesome, but many will not and Wikipedia and her sister projects should not be used as Guinea pigs to test the WMF's unfinished and so far poorly designed and implemented software. If your intent is to say the hell with the communities we are going to implement the tools anyway wether they want them or not, then at least have the decency to finish building it first and make sure it works with the communities processes and culture. Reguyla (talk) 14:53, 28 October 2014 (UTC)

That is a good point. I guess it is worth emphasising that, contrary to the claims of WMF, wikitext is extremely easy to use for beginners. They can simply write the plain text - and many do so every day (many new articles and talk messages are just that). In almost all cases that is good enough. And if it is not - that's why other users are there.

So, when Lila is saying that "Yet, we already know what wikitext presents a barrier of entry for a large portion of some less technical, but very important users: educators, scientists, historians, women, emerging regions, etc." (Special:Diff/10158275), that is simply not true. And I think she must be reminded not to think that badly about "less technical" users. The only users to whom wikitext truly presents a "barrier of entry" are illiterate. Not "computer illiterate", just illiterate. --Martynas Patasius (talk) 00:20, 31 October 2014 (UTC)

Just can support that point. An assistant teacher from the university chair I work for made her first edits to Wikipedia and found Wikitext extremly easy, even to apply footnotes. She was very surprised since she also had heard the bad mouthing of Wikitext by the Foundation and some parts - lous parts - of the editor community. I think a reality check of the Foundation'S arguments would do good ... --Julius1990 (talk) 17:07, 31 October 2014 (UTC)

Well, same here, I'm training several librarians and some told me seeing the templates as they are in wikitext is more comfortable: I had to "force" them to use VisualEditor! Then they told me VE has its benefits too. But they're librarians, we know their quirks. --Nemo 17:45, 31 October 2014 (UTC)

I have to say that as an "educator" and "scientist" I find the characterization above to needlessly patronizing. Not to mention inaccurate, as others have noted above. Short Brigade Harvester Boris (talk) 04:45, 1 November 2014 (UTC)

For the record: I've been using Emacs and LaTeX for all my writing since 2001, and I've written all my Wikipedia articles offline. I would never use a browser window for texts as long and as complex as that. Neither would you use Microsoft Office for writing. I did not install these programmes when I set up my latest system because I had not used them for over ten years. As to flow, I don't remember it having been requested by the community. On the contrary, it will make encyclopædic discussions all but impossible because we do not live on threads and smartphone devices, but on archives you can search and read easily. Wikipedia is text, and Wikipedia badly needs a memory. As to the visual editor, I think it is fit by now for minor edits, but, again, I would not use it for writing articles, because you don't do this in a webbrowser window. Both flow and visual editor take away the soul from the project, as both discussions and editing articles is at the very heart of what a Wikipedian does.--Aschmidt (talk) 00:20, 29 October 2014 (UTC)

Flexibility

It occurs to me there may be some misunderestimation going on here regarding the significance of flexilbity. Not just how important it is, but why. The Foundation's mandate is to enable the community to make knowledge available. The Foundation doesn't, must not, tell the community how to do that. Forcing the community to do things a certain way is a violation of the Foundation's reason for existing; and rigid tools force the community to do things a certain way. It's not just that forcing the community to accept such tools is itself a violation of the Foundation's mandate (though that's true too), but that the tools themselves are a violation of the mandate. --Pi zero (talk) 15:44, 30 October 2014 (UTC)

You're the right person

You're the right person to run WMF, Lila. You've already learned one of the most important skills that every WMF employee should poses. I mean ignoring emails. Way to go! 59.151.103.44 18:33, 31 October 2014 (UTC)

I will only say this once: responding to sarcastic, non-productive comments like the one above will not be my priority. Communicating with good-faith, positive, engaged community members and ideas is. Thank you. -- LilaTretikov (WMF) (talk) 17:58, 5 November 2014 (UTC)

Will you engage in any way with the communities? I mean on the different project pages here and elsewhere, not mailing lists or other more or less hidden and/or nerdy stuff? If I look at your posting history, you're rather silent (168 edits found in 7 projects). --♫ Sänger - Talk - superputsch must go 18:14, 5 November 2014 (UTC)

Charter of Wikimedia Movement (WMM)

WMF. Matrix of Participation by iCIV
Levels of participation and influence of iCIV		Six circular steps of a WMF-process
Partnership	+++	Agenda setting  ► Drafting     ▲   ▼    Reformulation  ↻  Decision    ▲   ▼      Monitoring  ◄  Implementation
Dialogue	++
Consultation	+
Information	0
This figure is a derivate of an adoption by the     Congress of International Non Governmental Organisation (CE)

The Wikipedia Movement (WMM) is an out-standing project and its developement must be out-standing too to stick to the successful basic idea: Testing new proposals of cooperation beyond existing limits. In Working Together Lila Tretikov as the Executive Director of Wikimedia Foundation (WMF) has anounced an approach of a new Wikipedian Life at New Frontiers (0 days to go till publishing). Wellcome to all explorers on the new track of cooperation, diversity and subsidiarity, the future Guiding Principles of Wikimedia Movement (WMM) – This shall be On the Scale of Billons. Next - let´s try a Request for Comment (RfC): Charter of Wikimedia Movement (WMM-Charter) - with Lila´s new proposals as a solid base to develope further requirements and on-going interests of the international Community of Individual Volunteers (iCIV).

Hongkong, San Francisco. You name it! WMF has responsibilies to develope the free knowlegde of the world and its own organizational conditions so people can contribute in a ballanced way of mutual interests and diversity growing - in a world changing day after day, fate by fate. --Edward Steintain (talk) 05:25, 3 November 2014 (UTC)
P.S. Please, don't give people instructions but set new trends how to cooperate as partners at every level.

The Wikimedia Foundation has no rightful claim to speak for the movement, and —sorry to be blunt— has certainly abrogated the right to talk about 'working together" since their recently demonstrated policy has been to tell the community to go screw themselves. --Pi zero (talk) 14:12, 3 November 2014 (UTC)

I declare: The term Movement (WMM) and its definition are in possession of the Movement of the international Commutity of Individual Vontunteers (WMM of iCIV) participating with Wikimedia. iCIV as the community and movement shall write the Charter of Wikimedia Movement applying the good idea of Bylaws: ARTICLE II - STATEMENT OF PURPOSE too. iCIV shall coordinate contributions of WMF – to be fair to WMF while iCIV is developing the Charter of Wikimedia Movement (WMM). I tend giving to check the idea of cooperation, diversity, and subsidiarity a chance - despite of … (please teach me what I must do to forgive.) --Edward Steintain (talk) 18:15, 3 November 2014 (UTC)

What is really important here is that Edward is looking forward into what needs to be done, vs. what has been done. We have a rich and important history, yet my (and yours if you choose to accept it) job is to ensure we are healthy and relevant in the future -- in the world that is rapidly evolving. With that, I am watching for those who are willing and able to engage in looking forward. -- LilaTretikov (WMF) (talk) 17:53, 5 November 2014 (UTC)