User talk:LilaTretikov (WMF)/Archive 5

Metrics, mobile use, editor retention - some thoughts

Lila, I just read an interesting summary by Aschmidt (in German) of the issues discussed at the Metrics and activities meeting. He isn't very enthusiastic about the priorities that seemed to transpire there, neither am I, so here are some thoughts:

• Maybe, access stats aren't that important. Wikipedia doesn't need to be one of the top 5, 10, or 20 websites - the project is about creating free knowledge that can be used by anyone without restrictions, for a long time to come - it doesn't need to be directly at the Wikipedia platform. The recent drop in direct access to Wikipedia may very well have to do with Google now displaying an infobox with some basic data gathered from Wikipedia for popular searches, so people who were just looking e.g. for the dates of birth and death of Einstein don't visit Wikipedia anymore. But is this a bad thing? Not necessarily - if we view Wikipedia not as a project to create a "successful website" (with "success" determined by measuring website traffic) but as a project to create widely available free knowledge.

• From Aschmidt's report, I gather the impression that the WMF currently sees improved mobile access as a top priority. Well: Firstly, it's very sensible to improve mobile access for readers. It's important that our content is easily accessible for as many people as possible, on as many devices as possible. Also, making mobile contributions easier isn't a bad thing, but more problematic - as we have seen with the mobile upload debacle at Commons (most mobile uploads had to be deleted as useless trash or blatant copyright violations, very stressful for the community), making things too easy may have its dangers. Wikipedia (and Commons) simply isn't a social networking platform where one can upload whatever they feel like - it's a platform for free educational content. The "social networking" aspects of Wikipedia serve the encyclopedia.

• This also means: If mobile contributions are made easier, it's crucial that "traditional" editing of Wikipedia isn't hampered in the process. The core content is still produced that way. The main trend in Wikipedia's existing contributor community in the last 10 years was a move towards more quality, more in-depth encyclopedic content. I have taken an active part in this and experienced it closely in German-language WP, also as a bystander and occasional contributor in English WP. It is this trend that has made Wikipedia successful, as readers view the content not as the arbitrarily changed product of some social network platform, but as a trustable, even authoritative work of reference. That's too much trust, of course, we know Wikipedia isn't (and doesn't want to be) authoritative - but this often unquestioned trust in the content creates also great responsibility. So, the importance of literature and reference works has grown all the time for the existing community. If you want to write an article that is seen as of a good standard nowadays, you might be switching between a dozen tabs/windows with literature while writing, and you might still have a pile of printed books at your side - as often writing a Wikipedia article involves incorporating knowledge from printed sources that still aren't available in digital form (thus finally "liberating" the knowledge and making it available to a wide audience). You rather don't want to do this kind of work on a mobile device.

• Most of this work is done by a core community of a few hundred editors in each big language version. They're not easily replaced, and I'd like to point to the essay Don't break the community by Aschmidt in this context as well as to my thoughts regarding a "next generation" here. If these people were to leave, I'd fear a spiral of death for the projects: An influx of vandalism, promotional content and other rubbish not held in check, the quality deteriorating more and more, leading to the platform not seen as trustworthy and serious any more, losing readers too, and finally becoming not more than another kind of social network - maybe perfectly accessible through mobile devices, but no longer a place for free knowledge. So, my appeal to you is: If you want Wikipedia to be still worth visiting (directly or through re-users of data) ten years from now, you have to support the existing community, of course also trying to get it to grow - but don't try to replace it with some phantasmal new mobile community.

Gestumblindi (talk) 15:22, 6 September 2014 (UTC)

Thank you for your feedback -- I sincerely appreciate it. I do think we need to understand our editors and allocate time and resources to improving your experience. I am spending time editing myself and I have asked all of the WMF staff to do so (if they have not already) so we can all have the experience necessary to relate to editing issues. I am working with the product team to improve our methodology for collecting, identifying, setting and communicating success criteria for features. I want us to be thinking through complete experiences: I've mentioned this as "systemic analysis" in the meeting. This does not mean that we don't experiment, but this means that we need to understand the downstream effects of the changes we introduce even if they are not directly targeted towards editors and anticipate challenges. We need to be doing it for all changes we implement. The image example is one change that did not go through the full systemic analysis. To set the expectations, this will not be an overnight change, but it is a high priority. -- LilaTretikov (WMF) (talk) 06:14, 8 September 2014 (UTC)

Lila, i can just give you the advice to listen very carefully to what is said above by Gestumblindi. And i also would advice you to try to write a good article about 20-30kb on your mobilde device. Those are the articles the readers stop by to read, not Twitter messages. And for your obsession with metrics. You allowed, according to what is whispered, Google easy access to data that is now displayed on the search results. Honestly, I myself don't click to the Wikipedia article if I just wanted to find out the birth date or antioanlity of a person. But you in the Foundation are so obsessed with the Alexa rank that you forgot what is our mission, how we serve best our mission and how you shoudl treat your volunteers. All i read about the rank and the mission said by you and other Foundation staff up to the highest member of the Board is so full of misunderstanding of your own position in the movement and arrogance that it honestly makes me sick. --Julius1990 (talk) 15:37, 6 September 2014 (UTC) PS: And because of the last bit of trust i have lost in the WMF, it's way to interpret data and its structures, i would recommand you to get extern control. All the commitees and subcommitess, the bad performance on software developing and so on let me loose my faith that the donor's money is handled with the care and respect it deserves. The way that data you gathered is presented with sometimes pretty kind of "making them fit" just lowers my faith more. And I also would recommand you to take Erik Möllers position into view and control. I really don't like to put failures of the system WMF on single people. But his performance is so bad that there needs something to be done. You still keep the threat of superprotect existing on teh German community, even with all your nicer words you amke it sound sweeter. Erik has just recently for the second time this year threatend an Admin on the English wikipedia with action. That seriously can't go on. I can't see a situation where a whole lot of people still wants tow ork together with him, and he just keeps isolating himself and in the end the WMF more and more from the editing communities. --Julius1990 (talk) 15:44, 6 September 2014 (UTC)

Earlier on this page, Jan-Bart de Vreede, chair of the WMF Board, though speaking in a personal capacity wrote [1] All of this is going to require change, change that might not be acceptable to some of you. I hope that all of you will be a part of this next step in our evolution. But I understand that if you decide to take a wiki-break, that might be the way things have to be. Even so, you have to let the Foundation do its work and allow us all to take that next step when needed. I can only hope that your break is temporary, and that you will return when the time is right. So, he at least is happy for you to leave: in fact, quite prepared to dissolve the people and elect another. It would be interesting to hear whether this is preferred directon of travel for the other Board members and for Lila. If it is, if they are happy to lose the long-standing content contributors and replace them with others, then that is their decision to make, and making changes unwelcome to those people will not be problematic for them. If they do wish to retain their long-standing contributors, then they need to hear what they are saying. But right now I cannot tell which of the two strategies they are trying to execute. — The preceding unsigned comment was added by Deltahedron (talk) 16:11, 6 September 2014 (UTC)

I think, we get to the point, thanks to Gestumblindi & Aschmidt. Kein Einstein (talk) 16:36, 6 September 2014 (UTC)

VE, MV and Flow as software products

It would be interesting if Lila were to give her assessment on Visual Editor, Media Viewer and Flow as software products. In other words, setting aside, if we can, for a moment whether or not we like them, or whether they do what we want them to do, let's look at the question: do they do what the people specifying them wanted them to do? I think the answers might be interesting. From my perspective, the answers would be different in each case.

• Media Viewer is more-or-less successful: it largely does what it was supposed to do. It has some infelicities in its user interface, and possibly fails to be fully compliant with certain legal requirements but by and large it works and does what the designers intended it to do. It may be considered a success.
• Visual Editor is a project which is partly successful. It can cope with some but not all of the requirements of editing complex Wikipedia text. It cannot cope with the full range and so cannot be regarded as a finished product. It is reasonable to expect that at some point, with an appropriate injection of resources, it may do what it was intended to do, although it does not do so now. To have taken this long to get to this point must be considered less than satisfactory.
• Flow is currently a failed project. After a year, its design process has had to be rebooted and there is no realistic timescale for the software product. There is no evidence of the huge amount of research needed to capture and scope out the various workflows it is supposed to support, let alone feed that into any design process. The current status, after this much time and effort, is completely unsatisfactory.

Please bear in mind we're talking about these as software projects, not looking at the customer requirements, if folks other than Lila want to comment. Deltahedron (talk) 11:04, 7 September 2014 (UTC)

Erik's at it again

Lila, you might want to get in front of the brewing next public relations disaster. w:Wikipedia:Administrators'_noticeboard/Incidents#Inappropriate_threats_by_User:Fram NE Ent (talk) 22:44, 5 September 2014 (UTC)

Erik's request for action against Fram was closed with no action (by experienced sysop TParis). It seems relevant to quote the closure summary here, paying special attention to the second half:

Unless Erik plans to take a WMF Staff action, then no other action is going to result here. We arn't going to block/desysop Fram over a threat. An actual block by Fram may result in something wholly different though - who knows?

Erik should probably take the results here as a sign that his current deployment strategies don't have a whole lot of support and he won't find a tremendous amount of sympathy from the community. Efforts to strengthen the relationship between the WMF and the Community should be sought - clearly what happened on both sides hasn't improved anything.

--Fæ (talk) 06:28, 6 September 2014 (UTC)

This is the same issue as the one I mentioned yesterday on en:WT:Flow. I think it's fair to say that there was a confusion between rolling out Flow to the en.wp Teahouse proper, which was rejected by consensus, and was not done, and creating a sandbox within the Teahouse pages for test purposes, which was requested offline and that is what was done. So it was a bit of a storm in a Teahouse. Deltahedron (talk) 06:57, 6 September 2014 (UTC)

Unbefuckinglievable. Does he really get absolutely nothing? After the open declaration of war against deWP (and heavy threats against enWP about MV by WMF, now they go further with this other piece of pet software next to nobody outside the ivory tower of WMF wants, flow. "Community engagement" doesn't mean to shove all shitty software down the throats of the community against their explicit will, but communicate, argue, discuss and convince them. But therefore this pure power game by those in SF has to stop asap, or they will just be seen as "those villains that suppress us". --♫ Sänger - Talk - superputsch must go 07:58, 6 September 2014 (UTC)

I will take the blame here for not ensuring it was clear that this was an isolated test. The page in question is an empty test page that was put together by our PM to allow volunteers to test and provide feedback on Flow. It is not a production roll-out and it will be removed/cleaned up. It looks like Fram may have though this would affect regular pages and hence locked this? In any case, my apology for any confusion. I'd be grateful if you can help convey that this is just a one-page test to let people play with the feature. -- LilaTretikov (WMF) (talk) 23:03, 8 September 2014 (UTC)

It's honorable that you take the blame and that you fill your position as you are supposed, but you seem to miss the point here. Indeed there was again bad communication leading up to that incident. But the real problem here is that Erik Möller again has choosen to abuse his position and to make again a threat against a community member/admin. The first time on en:wiki maybe still could be handled as maybe just a stupid incident, the power abuse on German Wikipedia makes the second incident of that kind and two incidents show that there is a pattern. The third incident of this kind now shows that there is a deep underlying problem that needs to be adressed (and since in everyone of these three cases it was Erik Möller involved, it seems that this is not just a problem of the system). You sure don't want to do that in public, and that is more than just understandable. But i would ask you - no, in the interest of the movement (consisting of both: the communities and the foundation) i beg you - to adress this problem directly and sharply and take precautions that there won't be any more incident like this happening: not next week, not next month, not next year or anytime in the future. This kind of power abuse has to end, now and forever. --Julius1990 (talk) 23:49, 8 September 2014 (UTC)

Palaver

Sorry, I feel reading User talk:LilaTretikov (WMF) is getting tiring because there is no solution in sight. I cannot see any structure that leads beyone this persistent conflict into the future and to a new developement – WMF and “iCIV” (international Community of Individual Volunteers) together. Wikipedia needs a structured way of consultion. Sorry again, User talk:LilaTretikov (WMF) is a Palaver. WE (WMF + iCIV) can do better in a new structured way of coordination and cooperation .

QiOP – how to contribute in a structured order

challenges / Questions Herausforderungen / Fragen	solutions / ideas Lösungen / Ideen	concerns / Objections Bedenken / Einwände	informations / Points of view Informationen / Sichtweisen
	42	31÷3

The Austrian Federated state Vorarlberg officially uses en:Dynamic Facilitation as a methode in the participation processs which could also be applied to Community Engagement (Product)/Media Viewer consultation and successors.

Please add your contribution in the suggested order starting with keywords or a short summary like a headline. A suggestion and my Cheers, --Edward Steintain (talk) 19:41, 6 September 2014 (UTC)

Every contribution written on Lila´s discussion page has a right to be taken seriously. But I cannot discover any balance nor an overview of these contributions as an precurser of cooperation. --Edward Steintain (talk) 19:46, 6 September 2014 (UTC)

To be fair to Lila, I have found it a useful way of comunnicating with her directly on subjects of interest, possibly even importance, to the community generally. I appreciate the time and effort she puts into it, even though the answers are not always those I would personally want. Deltahedron (talk) 19:53, 6 September 2014 (UTC)

true. WMF and iCIV are a community under developemnent - certainly in future. Thanks, --Edward Steintain (talk) 20:11, 6 September 2014 (UTC)

I certainly think that an impartial forum where the various parts of the community (in which I include WMF of course) can come together and evolve mutually acceptable goals and ways of working would be a great idea. I wonder whether this is an issue for the ED, or possibly whether it's an issue for the WMF Board, at Wikimedia Foundation Board noticeboard? Deltahedron (talk) 20:40, 6 September 2014 (UTC)

Would you mind also adding this to the process page here -- we can use these ideas as we work to improve the process. Thank you. -- LilaTretikov (WMF) (talk) 17:25, 8 September 2014 (UTC)

I explained in a previous section why I do not feel able to make any more proposals at that page. However, it is effectively covered by Community_Engagement_(Product)/Process_ideas#Triangulum. Deltahedron (talk) 18:17, 8 September 2014 (UTC)

Suggestion: a different metric, and a systemic problem

Lila, here's a systemic problem that may be difficult for you to see from your perspective. It seems like something the Executive Director may be able to affect, once aware of it.

Consider the value of the labor that wikimedians donate to the wikimedian projects. This is hard to estimate, but one natural approach would be to estimate how much time contributors donate to the purpose, and multiply by some estimate of the fair market value of their labor. For example, just to illustrate the concept (and yes, I mean to flag out a particular error in these numbers), if you have 1000 experienced volunteers, donating an average of 100 hours per year, and you value their labor at ten US dollars per hour, that would be a million dollars' worth of labor donated per year.

The error I particularly want to point out in that estimate is ten dollars per hour. That's roughly what you'd pay unskilled labor in the US — and the people I'm talking about, the core users who make a project like English Wikipedia work, are skilled labor, worth several times that 10-dollars-per-hour.

Which brings me to the systemic problem I mentioned at the start. A lot of Foundation employees are thinking of "the users" the way tech personnel would think of users at a social-media site like Facebook or Twitter. I know this attitude, I've seen it from both sides. It's the same attitude that causes tech support people to mutter "RTFM" under their breath: the expectation that users are clueless pests who need to be placated. Which, in this context, is a disastrous attitude, because the users are not only clueful, they're also a major financial asset of the Foundation that can be lost by mistreating them.

This isn't an alternative to the other things discussed. Naturally, better processes are desirable. I'm also quite impressed by the acuity of Gestumblindi's recent remarks. But this widespread (though by no means universal) attitude by staff, treating the skilled labor on the wikimedian projects as if they were users of something like Facebook or Twitter — that's a hemorrhage that needs to be stopped quickly, so the patient can last long enough to act on these other things. --Pi zero (talk) 03:09, 7 September 2014 (UTC)

I agree with this to a point. There are some staff, certainly not all, who seem to assume that Wikimedians are less educated, less knowledgeable, less socially skillful, and/or less technically capable than they are. That generalization is questionable. --Pine^✉ 07:05, 12 September 2014 (UTC)

I should acknowledge that we have some volunteers who are difficult to work with, and I'm sure frequent encounters with difficult users wears on the employees. Also, volunteer-on-volunteer conflict is pretty common and quite possibly has a major effect on our active editor statistics. I think this is something we may want to address in the Strategic Plan. --Pine^✉ 18:26, 12 September 2014 (UTC)

MV update

I don't come to Meta much, but I am back today to post on a Privacy issue.

I just checked #My_quick_response_.28Rich_F.29 above and I am wondering if this was read, as MV still seems active. I tried out the latest MV and it (I.E. the WMF) is still breaking copyright law and arguably contract law. Moreover anyone creating (or editing) a page on any project using more than one image risks doing the same. In other words the Foundation is putting editors in legal jeopardy.

I have notified Luis on his talk page.

Note: With copyright law, as with most laws, it is no defence that "the vast majority" of pages are not breaking the law.

Rich Farmbrough 21:49 7 September 2014 (GMT).

Can I ask you to comment on my Stockphoto discussion as well: Commons VP ? —TheDJ (talk • contribs) 15:58, 11 September 2014 (UTC)

Rich, I refer you back to previous comments by Wikimedia Foundation's Deputy General Counsel, Luis Villa. [2] [3] [4] You are unlikely to persuade the organization to disregard the opinion of its own legal department in matters of legality, so I suggest we focus on matters of best practices instead.

We absolutely agree that any automated re-use of files (in Media Viewer, in PDFs, in mobile applications, by third parties, etc.) should properly attribute authors. The team has already gone to great lengths to get this right in the viewer and small additional fixes (small because when machine-readable data is present, the viewer generally does the right thing) are forthcoming. More importantly, for files without machine-readable data, we've just started preparing for a file metadata cleanup drive, targeting the hundreds of thousands of files that have only free-text descriptions which cannot be predictably parsed by software. To be clear -- we welcome and seek volunteer participation (we believe the goals of having solid structured metadata are widely shared, independent of this application), but will also ourselves actively move this forward.--Erik Moeller (WMF) (talk) 07:51, 12 September 2014 (UTC)

I'd like to add -- making Media Viewer a stellar example of how attribution and re-use should be done, with great UX and clarity, would be a huge milestone for the free culture community and for Wikimedia Commons. This is a hard problem that no other organization has solved adequately yet, and it is compounded (in our case) by the messiness of our data. I don't think we're there yet, but I think we're closer than we've ever been. If you want to have a constructive conversation, please take a look through the must/should-have list here and let us know if we made the wrong call in over-looking a specific major issue in the viewer itself (template/file-level issues should be handled as part of the cleanup drive and you can prod Guillaume directly about these if you notice them but don't know a solution). Thanks,--Erik Moeller (WMF) (talk) 08:06, 12 September 2014 (UTC)

Only one of those diffs is relevant

• Your quotation of that section of the license cut out the "reasonable manner" part which immediately precedes your quote ("The credit required by this Section 4(c) may be implemented in any reasonable manner..."). See my analysis above for why, given the inconsistent state of metadata on the projects, some inconsistency in attribution - especially inconsistency that people are working to remedy over time - can be compatible with a "reasonable manner" of giving credit.

This is, I'm afraid just wrong. Luis talks about the "reasonable manner" part which immediately precedes your quote and omits the two important words provided however - the additional part he quotes does not affect the sense of the part I quoted. The full sentence says:

The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors.

• The language you quote is intended to cover the case of a combined list that credits all authors of the Collection in one place, not scattered credits all over. That is why it says if "a credit for all ... authors" and "as part of these credits". (Remember, a Collection is a thing like a collection of poems, where you might put all the poets in one list in the front of the book.) Mediaviewer doesn't have such a single list, so this language doesn't apply.

This is just "making it up as we go along" how do we know what the language is "intended to cover" - definitely not by guessing! Luis is arguing that "if a credit for all contributing authors of the Adaptation or Collection appears" means a single list because it says "a credit", but later on it says "these credits". This claim also requires us to accept that the Media View of a page is not a "single place", which I would be reluctant to do without case law.

Moreover an article is also a collection, (as is each WMF hosted project), nominally one click takes us to the attribution of the text, similarly one click used to take us to the attribution for each image. Now it takes two clicks to get to some attributions, and one to others.

@ Erik: I would be interested in fixing these issues by working on the Commons pages to ensure that MV can pick up the attributions, but I am wary of this philosophy that if the "vast majority are ok" we should just ride roughshod over the rights of the remainder. Decreasing the problem in this environment makes it more likely that the MV will stay grimly in place, I would rather see it pulled, we fix the attribution problem, then reinstate it.

Rich Farmbrough 22:10 13 September 2014 (GMT).

Invitation

Hello! As there is a Wikipedia article about you, you are cordially invited to contribute a short audio recoding of your spoken voice, so that our readers may know what you sound like and how you pronounce your name. Details of how to do so, and examples, are at Wikipedia:Voice intro project. Please feel free to ask for help or clarification on the project talk page, or my talk page. --Vera (talk) 13:19, 14 September 2014 (UTC)

Flow at enwiki

TLDR version of the below. Hi, there are major problems with the people responsible for Flow (especially DannyH and Erik Moeller) at enwiki, as can be seen by browsing WT:Flow and Wikipedia:Administrators' noticeboard/Incidents#What the heck is this?. Main problems are a lack of responsiveness, a seeming total disinterest in the opinion of the editors, and a presistent "we know better than you" attitude. Many fundamental questions remain unanswered. Some admins already threaten to hand in their tools if Flow is rolled out, and many other regular editors seem equally disenchanted by Flow and its managers. Thanks to VisualEditor, MediaViewer, AFT and so on, patience with Erik Moeller cs is rapidly wearing thin. Fram (talk) 12:32, 12 September 2014 (UTC)

Hi, I'm Fram, editor at enwiki, I have been discussed above a few days ago.

It would be very useful if you would take a more active (or visible) role wrt Flow. Not whether the product is good or bad, ha a future or not, that is a separate discussion (worth having as well of course). But the actions (and lack of them) by the two responsible people, User:DannyH (WMF) and User:Erik Moeller (WMF).

DannyH has consistently refused to (or neglected to, whatever) answer to lots of pertinent and direct questions, mainly on en:WT:Flow. The only tims he answers is when he can deliver good news or when the problem is so minor that he can be magnaminous about it. It started out well enough, around 27-28 August, but after that, when more and more problems came in and more and more of his statements were questioned, he just ignored every slightly tougher question or bug. This starts at the very end of the section "Problems accessing mediawiki flow page - and too many Echo notifications". It continues in sections like "Deletion", "Move doesn't work", "History and watchlist", ...

See e.g. the section "Updated information": he makes an announcement, gets a reply, totally ignores it. Or "Wiki misconceptions": he starts to respond, but when things get tougher, the whole of the WMF gest silent (I cound three pings to DannyH, one to Jorm, and one to Erik Moeller (5 pings by four different people that is, that all remained unanswered).

The section "Deployment venues": no answer. "How to inform about new topics": no answer. "Seeing changes since the last visit" no answer. The section "Deployment" started off with a large misunderstanding, and then nothing, even though again others pinged DannyH as well. "Why roll this out to other pages at enwiki?" No answer. "The Law of Unintended Consequences": no answer. "New topic notifications change": a reply acknowledging that they have to think about it, no follow-up when the questions get more embarassing.

"Get lost, WMF": Quiddity starts incorrectly, but has the good grace to correct his mistake and to stay in the discussion. No DannyH or Erik Moeller of course. "So funny it hurts" no answer from anyone until three days later a patch is written.

"Strike", a section started by two admins (not me) stating flat out that they will go on strike / resign the tools if Flow goes life. Not a peep from DannyH or Erik Moeller. Probably not important enough to warrant a reply.

Erik Moeller then finally appeared with "To Flow or not to Flow". He starts answering some questions, until some harder questions arrive, and people start pointing out inconsistencies between his story and reality. Pings by me, Diego, Victoria, and Seraphimblade, plus unpinged questions by multiple others, got no answer from Erik or anyone from the WMF.

Section "Effort justification" gets no answer. And "Reference does not support contention". "Can Wikipedia talk:WikiProject Breakfast be easily switched back?" gets an answer, but it is wrong. "Communication and action", no answer. "Notifications icon not disappearing", no answer.

Then we come to "Formal request to roll back the change that introduced the "messages" to Echo". DannyH leaves an answer. Questions about his unsatisfactory answer are ignored.

"Deletion of Wikipedia:Teahouse/Questions/Flow test" is one of the worst bugs reported. No answer from anyone at WMF, not even after a ping was added. "A possible fundamental reason for many of the problems", no answer. And so on, and so on.

You already know about Wikipedia:Administrators' noticeboard/IncidentArchive853#Inappropriate threats by User:Fram. Now we have Wikipedia:Administrators' noticeboard/Incidents#What the heck is this? and its subsection, where DannyH once again succeeds in completely ignoring the actual question, and Erik Moeller starts making incorrect claims, then finally answers the question, but succeeds in both missing the point and making it clear that community consensus is of no importance, only they (WMF) can decide whether bugs and problems at enwiki are serious enough to end the test.

Just take a look at how the interaction works, not with me but with others. Notice also the amount of people already seriously pissed off by Flow and the way it is being handled (and discussed), vs. the number of (not WMF) people actually welcoming Flow and its tests on enwiki. Take then into account that Erik Moeller already has estranged a large section of the regular editors by his previous involvements with VisualEditor and MediaViewer. I think it is time that some serious reconsideration is given to the total approach to Flow and the communication around it. Continuing the way things are going now will only create huge conflicts and bad blood on all sides, and will make virtaully certain that Flow will never get accepted by large portions of the existing editing community. Fram (talk) 10:17, 12 September 2014 (UTC)

There's not much to add to Fram's post in terms of the dynamics of that talk page, so I will add my personal experiences by way of illustration.

When I asked these questions, which were about basic functionality, I got a prompt reply which basically said "we are in the middle of building this, details are a bit vague at the moment". The same situation occurred here. However, when I began the en:WT:Flow#Wiki misconceptions thread, I got an initial reply, but when other users gave further questions, including extremely important use cases such as the need for custom sigs so non-latin-script users can sign intelligibly to English speakers, were stonewalled despite pings. With regard to the poorly explained rollout to a Teahouse subpage for testing (en:WT:Flow#Get lost, WMF), User:Quiddity (WMF) explained the situation, and was apologetic and reassuring that it would not happen again, but despite a ping to DannyH no-one seems to have adequately responded to the ton of bugs raised when Fram attempted to delete the page (see en:WT:Flow#Deletion of Wikipedia:Teahouse/Questions/Flow test for the conspicuous absence).

In short: in simple situations we get a competent explanation (usually Quiddity) or vague promises of action. In complex cases - and Flow is complex - we get evasiveness or nothing. That benefits nobody in the long run. BethNaught (talk) 14:32, 12 September 2014 (UTC)

I too am an en.wp editor and I think that a lot of people are engaging in hyperbole and jumping to conclusions. Answers are vague, because no one has them yet. Situations seem complex because they ARE complex. Some people demand answers to questions that simply cannot be given guarantees on at this phase. Some people are demanding the city plans before it is known how to build a house... Unless you are Qatar, most of the time that's now how cities get build. We need houses. We aren't sure how to build them. We might end up with 3 cities at some point. —TheDJ (talk • contribs) 11:53, 13 September 2014 (UTC)

"admins already threaten to hand in their tools if Flow is rolled out" - yes, that was, sadly, to be expected (and has been, e.g. on this very talk page, several times in the last weeks actually). I also note that our explanations that WMF is completely mistaken in focussing on mobile editing have been aggressively ignored, check this talk page against e.g. https://en.wikipedia.org/wiki/Wikipedia_talk:Flow#Misconception:_Mobile_editing_is_the_future_for_talk_pages . What admins should do, is not, of course, to hand in their tools, which have been handed to them be the community depending on them, but first warn and then block disruptive WMF accounts. In this vein, i strongly endorse examples like https://en.wikipedia.org/wiki/User_talk:DannyH_%28WMF%29#Only_warning . This disruptive WMF behavior goes completely in line with what we have seen regarding Superblock and MediaViewer. Our decisions regarding both still stand and neither has SP been revoked nor MV been set to opt-in. We will simply not tolerate being ignored like that.

"Real communities aren't your cheap labor force. They are real people with passions, hopes, and dreams. Your job is to help them do what they want to do, not to extract labor from them."

That was Jimbo, April 2013. Now view WMF's recent misbehavior in the light of this exchange:

"If you’ve contributed for years to Wikipedia you must now accept a new political economy: you have permanent lower-caste status, and have simply been working hard for other people to get rich." Opined Wales [(talk) 12:29, 29 August 2014 (UTC)]: "[T]hat's just sheer unmitigated bullshit".

bullshit it may well be, yet it is evidently the new WMF policy. Ca$e (talk) 08:32, 14 September 2014 (UTC)

• Ah people have threatened to hand in their tools have they ? I actually HAVE handed in my admin tools over the community's response and hyperbole. So shit like this works two ways. —TheDJ (talk • contribs) 07:11, 16 September 2014 (UTC)

August Board Meeting (London)

In the minutes of the August 6 WMF Board of Directors meeting, it is stated:

"Lila talked about characteristics that she expects for technology in the future, including more integration, mobile and short-form interactions, and predictive software. She discussed some of the challenges that the Foundation faces as the internet follows these and other trends. The Foundation's mission to facilitate collaboration and share knowledge will require better integrated knowledge, with delivery of service on any device and an active participation from a large number and diversity of users. * * *

Board members thanked Lila for sharing her reflections. The Board discussed the presentation, including the integration of Wikimedia projects, the value of predictive content, the importance of focusing on proper metrics, and the impact of product changes on users."

What specifically is the "predictive content" referred to here? Are we speaking of software generation of data that will indicate a tendency to further participation at WP, towards donations to WMF, or something else entirely? Carrite (talk) 14:20, 15 September 2014 (UTC)

Yes, i noticed that too and i find that choice of words worrying. Look up en:Predictive analytics. I (and i think most Wikipedians) really hate being treated like a guinea pig that can be manipulated to do this or that. For instance today on german WP (de:Wikipedia_Diskussion:Kurier#Empfehlungen), very experienced users were given the unsolicited mw:Task recommendations by WMF to edit article X and these recommendations were way off. These were +10year editors that were targeted by mistake while WMF was experimenting with newbies. (Earlier similar experiments had rather poor results en:Wikipedia:Geo-targeted Editors Participation/report.) --Atlasowa (talk) 16:35, 15 September 2014 (UTC)

Right. This was yet another example of WMF without consultation implementing a "feature" that is 1) totally unwanted and, what's more, 2) totally disruptive against our efforts to recruit new users of the sort we desperately need - and are still losing more and more in protest against WMF's continuing, disturbing misbehaviors! We are seeing crap like that, if i may quote from Aschmidt, "Because the WMF does not understand why someone joins Wikipedia in the first place. It's because you want to work on a particular subject that's missing from Wikipedia up to then. So, the idea of making random suggestions to work on misses the point completely and is even apt to drive newbies away because they feel being patronised by the software. That's not what they've come in for. Remember, this is not Facebook, or Twitter. And this is not America either. They also fail to understand that we have different habits and expectations. There cannot be one solution that fits every community around the globe.--Aschmidt (Diskussion) 11:34, 12. Sep. 2014 (CEST)" WMF has sufficiently proven that it lacks critical understanding whatsoever about what is actually going on in the projects it currently is disturbing on a daily basis! Please stop this, immediately! Then roll back all the other unwanted crap, MV, SP, etc, and get your priorities straight! Our job is difficult enough already without WMF ruining things completely! Ca$e (talk) 16:52, 15 September 2014 (UTC)

Staff account names

This is a follow-up to my previous note on English Wikipedia, cross-posted here for additional notice. We committed to move all staff to defined and marked "staff accounts" and to transfer any work-related user rights to those accounts by September 15th. As of today, I believe that all accounts with the exception of employees traveling or on vacation throughout the entire period have been migrated. The remaining accounts will be migrated as soon as the traveling employees return.

We are doing the final review of the accounts over the course of the next few days, but I'm pleased to say that the rename process is now substantially complete. While all WMF employees adjust to these new policies, if you notice a staff member posting from the wrong account, a gentle comment would be greatly appreciated. Philippe Beaudette, Wikimedia Foundation (talk) 04:12, 16 September 2014 (UTC)

MV consultation

Was there any intent to actually follow up on negative feedback on the Media Viewer consultation? It's painfully clear from the discussion that only comments that affirmed the basic design and intent of Media Viewer were heeded. The majority of the feedback you received was that the tool should be disabled, returned to opt-in status, or completely repurposed, yet the only things being done are to tweak minor features while keeping the original functions. Kww (talk) 16:59, 16 September 2014 (UTC)

I seems it was all just deception of the community. They never intended to do anything substantial, just superficial surface cosmetics. It was created to divert the discussion from the use of brutal force against the communities and to let this real issue die off. --♫ Sänger - Talk - superputsch must go 11:23, 17 September 2014 (UTC)

The distraction scenario was always one of the major possibilities (realistically, given the history, the most likely of the major possibilities).

Lila appeared, as seen from the wikimedian community, to have had a golden opportunity at the start of this crisis. If she had immediately had superprotect removed from the software, with an abject apology and statement that of course the Foundation had no business overriding community consensus on the deployment, she might have made herself hugely popular with the community, politically well-positioned to heal rifts and broker deals between the Foundation and the community. Potentially, supposing sufficient political deftness. Though still the best course of action, its immediate payoff diminishes day by day. Three theories come to mind for why she didn't.

• She simply didn't realize that was the thing to do. Plausible since she's been inside the Foundation echo-chamber (though plausibility doesn't make it less problematic). If that's the explanation, it seems she still doesn't realize, and as time goes on she'd have to do more, during and after the action, to convince the community of her sincerity.
• She wasn't politically capable of doing it, given the internal power structure of the Foundation. Has some plausibility, since she's a newcomer within the power structure and would need to smooth the ruffled feathers of people who've been there for years. If this were so, there are various political reasons, both internal and external, for her not to say so; but then, if she wanted to do it and needed to play internal power games to arrange it, one has to ask whether her public words would match what she's actually been saying.
• She sees it as her job to help the Foundation dupe the community into not screaming too loudly while the Foundation's will is foisted on them. That's a rather emotionally charged way of putting it, of course; but however you put it, there wouldn't be much point in dwelling on the possibility on this page —really, this page is only useful in the first and some branches of the second scenario— except perhaps to point out to her that because this third scenario looks increasingly likely to the community as time goes on, really substantive action would be needed to make it look less so.

It's sad to think individuals within the Foundation might mistake a tapering off of the initial level of vocal outrage as a good sign, rather than a sign of damage they've caused becoming increasingly difficult to redress. --Pi zero (talk) 13:44, 17 September 2014 (UTC)

What's even worse was the shameful behavior of the so-called "community liaisons" who repeatedly tried to hide feedback the foundation wanted to ignore while the "consultation period" was ongoing. Then in the end, the Multimedia team refused to even mention the #1 piece of feedback in their summary of the feedback. When community members added it, it was removed three separate times by three separate WMF staffers (including the VP of Engineering, yet again!). This was a consultation in name only if the WMF isn't going to even acknowledge the #1 request from the community. Shameful. Shameful. Shameful. --98.207.91.246 16:00, 17 September 2014 (UTC)

email

Hi Lila,

I emailed you with the subject line "From L"

Would you please read it and respond? If you don't see it would you please check your "spam" folder?

Thanks. 195.154.91.100 18:58, 17 September 2014 (UTC)

Out of office -- back

It would be nice if people with a job like yours wuld use some kind of "out-of-office" function / indication on their user page or talk page. At the moment, it is totally unclear whether you are not working, not reading this page, or not responding. You obviously don't have to respond to everything, but with this post included, there will now be 50 posts stretching nearly ten days here, without any reply by you. It gives a very strange impression. Fram (talk) 09:26, 18 September 2014 (UTC)

When I configured archiving for this page (see above), I used a conservative horizon of 21 days. Lila indicated about half of the material was archivable at that time. At least half of what was there then has now been archived, so although I'd adjusted the horizon down slightly (17 days), I've now put it back up to 21.

I agree, Lila would do well to catch up on the backlog here. I'm not really sure whether to intervene, in another few days, to prevent archiving of old stuff not responded to (and that's supposing that the massive 80k section archived last night didn't have subthreads that ought to have been responded to). --Pi zero (talk)

Looking at the recent purging action by one of her lackeys it seems she doesn't want to communicate any longer with the unwashed masses. The archive was set again to the last time she posted anything at all here on meta. that's imnsho a clear sign to the community to bugger off and leave the bosses alone in their wisdom, don't disturb them with facts, let alone dissent. I hope it was just some overeager lackey, who misread her intent, and not the obvious contempt that these actions seem to imply. --♫ Sänger - Talk - superputsch must go 10:13, 21 September 2014 (UTC)

Just to make clear to the casual reader of the above diff, the bot did not override the template parameters on its own initiative -- it's easy to miss the note "(3 intermediate revisions by one other user not shown)". An examination of the intermediate revisions reveals the identity of the human editor. Admit I was initially fooled by this, and nearly asked the bot operator what the heck their bot was doing. Wbm1058 (talk) 18:03, 29 September 2014 (UTC)

Thanks for the hint, I included one too many diffs, I now changed the link to the right diffs. Sorry for that. --♫ Sänger - Talk - superputsch must go 18:17, 29 September 2014 (UTC)

Well, that's a pessimistic interpretation of events. It's not hard to come up with less negative explanations, but by this point she's used up her 'holiday' as a newcomer, so as a practical matter if she wants people to give her the benefit of the doubt she needs to earn it with actions. --Pi zero (talk) 12:44, 21 September 2014 (UTC)

It's hard to come up with optimistic interpretations after the WMF acted so ruthless and with such contempt for the deWP- and enWP-communities in the last months. Nothing so far indicates that they have learned anything over there in their high-paid ivory-tower in SF, this non-answering here speaks volumes. --♫ Sänger - Talk - superputsch must go 13:09, 21 September 2014 (UTC)

This was just meant as an opportunity for people to let off steam, nothing more. After being on en:wp almost 10 years it's hard to avoid the conclusion that WMF's definition of "communication" is "give them a chance to vent, then go ahead with whatever we had planned." Short Brigade Harvester Boris (talk) 17:24, 21 September 2014 (UTC)

All -- I am out of office at a conference and a fundraiser until end of this week. I have also been very busy internally with some urgent items. To clarify, I am not going away from this page. I DO want to communicate here, I find it an extremely helpful way to keep in touch, to learn about what matters to you, and to communicate/get feedback on my own thoughts. Please don't be upset with me being spotty in my responses -- I want to make sure I give your posts due attention (not just a brief response) and I am thinking over some of the notes before I respond. Best from NY. -- LilaTretikov (WMF) (talk) 02:44, 22 September 2014 (UTC)

Lila, the really strong reactions here are not because you haven't gotten around to responding to some things yet. They are because, after someone inquired whether you were away, the apparent response was this edit, which changed the archiving threshold downward to only 14 days. That means anything here that you don't respond to within 14 days gets archived despite the lack of response. I had the threshold at 21 days, and was wondering whether to make it even longer; so making it shorter came across as a decision not to respond to things.

Archiving isn't quite like anything else I'm familiar with on any other sort of discussion forum, so I can see how you might not have yet have fully assimilated its implications. It is however basic to wikimedian culture, providing a clear distinction between discussions still active and discussions that have been retired (so that raising the topic again would usually involve a new section, perhaps with a link to the archived discussion(s)). --Pi zero (talk) 11:04, 22 September 2014 (UTC)

The last two items the archiver bot moved out of sight were without any answer by you, Lila, and were started shortly begfore you stopped editing anything at all here. If you need more time inbetween, simply set the time frame for the bot to something more fitting to your agenda, not this obviouly too short 14d. --♫ Sänger - Talk - superputsch must go 11:17, 22 September 2014 (UTC)

As more and more items are vanished into oblivion by the bot, it seems fair to draw the conclusion, that all the WMF gives a flying fuck about it's communities, and nothing has changed whatsoever by the new board member Lila, she has absorbed the communityphobia by her pals quite fast. --♫ Sänger - Talk - superputsch must go 16:07, 29 September 2014 (UTC)

I am working backwards as much as I can to catch up. -- LilaTretikov (WMF) (talk) 05:37, 30 September 2014 (UTC)

Introduce the few good things developed for VE into standard wikitext editing

During the years that VisualEditor has now been under development (and the year that it has been the default editor at most wikis, getting some 10 to 20% of the actual edits only though), a few usable things have been developed for it. To make better use of the money and time invested in this, and as a sign of goodwill towards the majority of editors who use wikitext editing, it would be good if these things were introduced in standard wikitext editing as well.

• The file selector: in wikitext editing, you can insert a file, but you have to know the filename. In VE, you get a decent (far from perfect) File suggestion screen, showing files that match the article title. It would be useful if that was possible in wikitext editing.

• The template inserter. In Wikitext editing, we only have optional reference inserters (which are good), but no general template inserter. This has been developed for VE, and ha cost a serious amount of effort from the different language wikis to add Templatedata (which is far from finished). To make optimal use of the time invested by all these volunteers, and the money and time invested by the WMF, it would be very good if this template inserter would be introduced in wikitext editing as well. While it may be hard to turn it into a template editor on wikipedia articles, it would already be very useful if the initial entry was facilitated in this way.

There will probably be some comments about this being impossible due to Parsoid or some such. But the logic has been developed, the TemplateData (which is a lot of work) is in place, so much of the work has been done. Converting this so it is useful in wikitext would go a long way to show that the WMF is willing to spend effort on the tool the vast majority of editors use and are going to use for the forseeable future. At the moment, many people have the impression that the only develoment is being done on VE, Flow, Winter, ... but not on the actual central tool, wikitext editing. Fram (talk) 12:09, 25 September 2014 (UTC)

Hi Fram, thanks for pointing out the VE "file selector" (article page -> edit beta -> insert -> media)! I just tried it for the first time and, wow, really nice! Not yet perfect, but good direction (complaints: 1. No way to access the file's page on commons where the description is, 2. when writing the image caption a tiny thumbnail of the chosen picture would be helpful, 3. no "insert gallery" feature to curb excessive picture sprees but that can wait). BTW, is there no way to leave the VE mode without saving except closing the browser tab/reload? No exit button?

The most important VE feature is the reference dialog mw:VisualEditor/Design/Reference Dialog, IMHO. Insert URL or ISBN or DOI... and click autofill, then edit the values for the ref and click insert, done. Perfect, can't wait. There is a "proof of concept"/alpha/beta whatever user script to use citoid (underlying the VE dialog) for wikitext editing. See en:User:Salix_alba/Citoid and note the version 0.01 remarks by User:Salix_alba, still: Awesome, hope to see this service included in the standard ReferenceToolbar soon :-) --Atlasowa (talk) 14:44, 25 September 2014 (UTC)

I haven't really looked into the latest incarnation of the reference dialog, but if it is better than what we have in wikitext editing, then yes, please, introduce it there as well! Fram (talk) 12:31, 26 September 2014 (UTC)

There is a lot of work that could -- in theory -- get back ported. But that means doubling effort to have it implemented in two places. Typically in cases such as VE/WikiTest where two features are meant to do the same thing -- some amount of maintenance continues as new tools get developed -- so it's not completely out of the question. But it is a matter of deciding how much effort we want to spend on maintenance and in what places. -- LilaTretikov (WMF) (talk) 05:34, 30 September 2014 (UTC)

While it is true that this would probably mean double effort, the reality is that now all that effort is done at the place (or for the tool) where it has the least effect (as it is being used by a much smaller number of people, even of those who registered after VE became the default at e.g. frwiki or itwiki or ruwiki), and not in the place where it would have the maximum result. If such developments are being created for only one of the two editing environments, then it should be the wikitext editor, with the VE coming second. The question should no longer be "what can we add to VE?", but "what can we add to the wikitext editor, and can we also add it to VE as well or afterwards?" The opposite only reinforces the image that for some people, pushing VE is more important than helping the editors in the best possible way. The two don't necessarily exclude each other, but the latter should be the top priority, not the former. Adding one of these tools to the wikitext editor would be a nice olive branch towards the communities. Perhaps first check with e.g. the German editors which they would most like to have though, that is obviously not for me to decide. Fram (talk) 07:52, 30 September 2014 (UTC)

Wikitext will stay the editor of choice for quite some time, so it has to be maintained, and good features been implemented for that time. Neglecting the current editor for some future Fata Morgana is a waste of resources. As long as VE is not capable of doing everything the normal editor is doing, not breaking any wikitext and layout on existing pages, it's not fit for coming out of beta, and thus the normal editor has to get quite some resources as well. If you want to starve it to look bad just to keep the VE more attractive: don't! --♫ Sänger - Talk - superputsch must go 04:22, 2 October 2014 (UTC)

+1. With Wikitext we achieved what we have now, quite impressive, isn't it? And it is also a matter of respect for us editors to maintain it in a good way. If one day a big majority not uses Wikitext anymore (and i really mean >90%+) then you can think about not keeping up the developing effort for it. But until that moment you do good on supporting us editors on it. After all that is your Mission Statement to empower us to be able to work in the best way. And VE doesn't do that job properly and won't for a long, long time. But sure you can kind of blackmail us to relinquish Wikitext. It is sad to see that you still didn't change the WMF's attitude away from the forcing to products to convincing with good products and empowering the editors the way the need and wish and not the way you want to dictate them. The donations come for the work we do, so our wishes have to count more, than yours. --Julius1990 (talk) 07:17, 2 October 2014 (UTC)

Community-facing roles

Some of the roles for WMF staff are specifically community-facing. I see such descriptions as "My job is to help make sure the team understands what the community wants and needs, is focussed on the things that matter, and is engaging with and understood by the community"; "ensuring that our community is represented in the decision-making process and that our planned software adequately reflects user needs"; "facilitate communication between staff and all the communities in every project under the umbrella of the Wikimedia Foundation"; "facilitate communication between the Foundation staff and the many diverse editing communities and editors that make the project work"; "empower volunteers to assist their communities with the development and deployment of software"; ""ensure open lines of communication between our editing community and the team, and surfacing issues that are important to our editors" and so on. Might I suggest that each memeber of staff with a specifcally community-facing remit publish their detailed terms of reference, so that we may understand exactly what we, as community members, should and should not expect them to be able to do? It would probably also be helpful to have a prominent link on the front page to a list describing briefly which of the community-facing staff has responsbility for which areas. Deltahedron (talk) 11:19, 7 September 2014 (UTC)

A very good suggestion.--Keithbob (talk) 21:28, 7 September 2014 (UTC)

Thanks, --Edward Steintain (talk) 21:38, 7 September 2014 (UTC)

@Deltahedron: does it need to be done by each individual, or would a department level roll-up be useful for you? For instance, I'm wondering if something like this, which was written for last year's annual planning process (and describes the work of my team) is useful for your purposes. Philippe Beaudette, Wikimedia Foundation (talk) 08:34, 17 September 2014 (UTC)

Does this in any way fit to the demand of "Might I suggest that each memeber of staff with a specifcally community-facing remit publish their detailed terms of reference, so that we may understand exactly what we, as community members, should and should not expect them to be able to do? It would probably also be helpful to have a prominent link on the front page to a list describing briefly which of the community-facing staff has responsbility for which areas.", especially to the last sentence? Beside that i also find it somewhat disrespectful instead of answering such a reasonable wish of a community member (that also on the long term could help to advance the contact with the community members) to kind of hope to get away with linking to an old paper. But that is maybe my personal problem since i see such disrespect everywhere on the Foundation or at least you do nothing to correct that image. --Julius1990 (talk) 09:40, 17 September 2014 (UTC)

Julius, I think perhaps I wasn't clear. I was asking if something along those lines (tweaked to meet the original request) would be adequate as a starting point, or whether it wouldn't work at all. It sounds like, for you, it wouldn't work. That's fine. I wasn't suggesting that it was in any way a completed product - just trying to clarify the requirements. Philippe Beaudette, Wikimedia Foundation (talk) 05:40, 21 September 2014 (UTC)

@Philippe (WMF):, i simply have no faith left anymore for any of you at the WMF. I can't see how you can think that this list on that page comes any close to the community-faced employees telling what exactly is their respective job, what we as the editors can expect from any single of them, i likely would also like to hear if they would work against the will of the communities by your bosses demands ... but I personally think that it doesn't matter at all if you will ask such questions. You, meaning the WMF, made pretty clear in the way things get handled that we - the editors - anyway don't matter. Okay, message recieved. --Julius1990 (talk) 00:26, 22 September 2014 (UTC) PS: Just to show you how easy it is, and why i doubt on the Foundation's staff abilities: First step would have been setting up a page "community-facing employes" or something similar, the second step would have been to advice everyone of them to go there and then write "i'm xy, my role is xyz. You can expect from me help in this field. It's not my task do engage in this ..." Doesn't sound like anything that would require nobel prize winning abilities, does it?

We are thinking about how to best clarify who does what -- I agree that it would help doing so. We currently have a few very small community-facing teams that are spread around the org. They often share responsibilities. It is a function of growth (one person ends up doing many many roles). But it also creates confusion. Good suggestions. Will take this input as we calibrate our community teams -- LilaTretikov (WMF) (talk) 17:07, 5 October 2014 (UTC)

One followup comment. It confuses me when WMF employees say they are speaking as themselves or as a regular community member in some communications and as a representative of the WMF in others. That makes no sense. If they are an employee of the WMF, they represent the WMF in all their communications with the community, period. If they express disdain as is often the case when they claim to be speaking as something other than a WMF employee, they are affecting the communities perception of the WMF no matter what hat they tell us they are wearing. -wʃʃʍ- 05:47, 8 September 2014 (UTC)

Ah, employed people are not allowed to have opinions of their own and are not allowed to participate after working hours.. Someone like brion, who has spent dozens of weekends, implementing a decoder for our for the browsers that don't support our libre-format videos... Because he is a dedicated community member with WMF employment he no longer allowed a voice of his own. classy.. —TheDJ (talk • contribs) 16:23, 11 September 2014 (UTC)

TheDJ it is not a matter of what is permitted but what is possible. Those listening to a WMF staff person speaking will not generally distinguish whether the words reflect a personal or a professional opinion, and will assume professional, regardless of whether such a (non-credible) disclaimer is made. Same goes for the employee of any organization speaking in a matter that relates to their professional role. WMF staff can choose to acknowledge this reality, or they can pretend that it doesn't exist -- those are the choices. -Pete F (talk) 16:47, 11 September 2014 (UTC)

Active projects

The archiver bot has moved out a question about success/failure of projects currently under development.

We need to go through and finish the work on getting clarity on what a product process needs to look like: how and when we decide what to work on, how we prioritize, how do we decide on the feature set, etc...from the very beginning to the very end it needs to happen in partnership with our users. And most importantly we need to be clear what we mean by "improvement" and "success" from the moment we even think about moving forward on implementing something. Today this is not clear -- even for the big features (like VE or Flow). So no, I cannot consider them a success today, especially since we have not even defined what success means. This does not mean they are not/cannot be. It does mean that I am reviewing all of the large user-facing features and asking those questions before future user-facing roll-outs take place. WRT Flow -- I am planning a deep review. -- LilaTretikov (WMF) (talk) 06:36, 30 September 2014 (UTC)

Not sure which comment particularly you refer to, but, some general remarks.

<squeeze>This one's the particular comment, made by Deltahedron. It would be easy for any slightly skilled editor to get it back here ;) There's more unanswered stuff "hidden" by the overeager archiver bot in the 5 archives, mainly in #5, it could as well be answered over there or transferred back here. --♫ Sänger - Talk - superputsch must go 17:58, 2 October 2014 (UTC) </squeeze>

It would seem hazardous to answer on an archive page, as things would get very fragmented very quickly and it'd set a bad precendent that would be awful to maintain. People who watch this page wouldn't see the answer unless either specifically pinged, or directed there from here; and thereafter one would have to watch all the archives rather than treating them as, well, archival. Of course, for years I've wanted a feature that would extend watchlists by allowing the user to mark a page as an ancestor of interest; all subpages at that moment would be automatically added to the user's watchlist, and any newly created descendants thereafter would be automatically added to the user's watchlist at the time of creation; any descendant could later be unwatched, of course. Every project would have different uses for that, including Wikibooks that's always wanted the ability to watch an entire book. But I digress. (It also occurs to me to ping Deltahedron since, as you point out, this was their question.) --Pi zero (talk) 00:53, 3 October 2014 (UTC)

While there's no doubt, I think, process reform (to put it mildly) is desperately needed, it isn't by itself reassuring, for two reasons that seem worth pointing out.

• A good process can still be brought to grief by poor judgement that sufficiently dominates institutional decisions. Take Flow (please). The core concept of Flow has failure built into it; and it's not at all certain that a better development process can compensate for a really profound lack of understanding of what makes wikis work.

(Aside: Why does the Flow concept have failure built into it? Besides, that is, the crucial need for talk pages to use the same medium as articles, so that anything possible in an article automatically does the same thing on the talk page, and vice versa? Well, a foundational property of talk pages is the infinite maleability of their structure; not a matter of how things are normally done, or even of several ways things are normally done, but that at any moment in any discussion, spontaneously for any unanticipatable reason that might come up, one can call on any aspect of the full flexibility of a medium — wiki markup — unprecedently well-suited to expressing the full spectrum of human knowledge. It's not a coincidence wiki markup is the medium for a grand open-source encyclopedia, and it's not incidental that beyond the "usual" usage patterns of wiki discussions is the full power of wiki markup at the commenter's fingertips. Any project that tries to replace that flexibility with a rigid structure, and then add things to recover particulars once they are missed, has fundamental failure built into its core concept.)

• The wikimedian core community is made up of the sort of people who would donate a lot of labor to a radical concept like an anarchically crowdsourced neutral encyclopedia of all human knowledge. Such people are likely to have a buried (or overt) radical streak themselves, and are likely to be familiar with, and sensitive to, the sort of guerilla bureaucracy tactics commonly used by institutions to prevent the general public from interfering with institutional plans. A major such tactic is to talk about "improving the process". Often accompanied by a "moratorium" that freezes things in a state favorable to the institution. Hence, that combination of actions isn't reassuring to such people.

--Pi zero (talk) 17:17, 2 October 2014 (UTC)

There is a lot in your comment, so I will attempt to answer some of the points. I agree that a process in itself is not a panacea, but it is one of the things we desperately need to at least have some sort of mutual understanding of steps we take in the development and prioritization of software. The goal here is to actually hold us accountable to not skipping important steps in validation of what we do and measuring improvements. It may sound like a big borg making a conveyor belt -- but that is not the intent. It is actually to help us all get on the same page and answer some basic questions about where we are in the process with a given feature and how do we know we are doing the right thing. Vis-a-vis your point on moratorium -- that is not what I have requested -- I just asked for a pull back on major roll-outs until we have data that shows that users are more successful with the new tool than the old one. An example of that with VE, for example, could be comparing the number of successful edits that do not get reverted per editor (this is just an illustration). -- LilaTretikov (WMF) (talk) 16:58, 5 October 2014 (UTC)

Complaint about some employees of the WMF

As an unhappy contributor, I would like to make a complaint about some WMF employees.

• User:Erik Moeller (WMF): he has single-handedly alienated more Wikipedia editors (all languages) than the rest of the WMF combined. I don't think I need to rehash all his problematic decisions, communications, and actions wrt VisualEditor and MediaViewer, which were basically the culmination of years of problems. Please, if you can't or won't get rid of him, then at least make sure that there is no more interaction between Moeller and the projects, and no more communications from Moeller.

• User:Jorm (WMF) is the proverbial example of a software designer who is not interested in what people need, only in what he can make. His work on Flow, and his communications about it, emphasized the gap between his vision and what was actually wanted or needed, and his inability to grasp this and act accordingly. Perhaps he is a good developer, but then make sure that he only produces things for which others have written the specifications, and keep him away from interactions with editors.

• User:Jdforrester (WMF), doing his best to make the exasperation over VisualEditor worse at every possible moment. Together with Erik Moeller and Jasper Deng (not a WMF employee) the main reason I refuse to edit at Mediawiki any more. A very poor communicator when things go wrong, and the manager of a completely botched product launch. See e.g. en:Wikipedia:VisualEditor/Feedback/Archive 2014 3#Testing report from Wbm1058 for a typical passive-agressive example of his lack of clue (also here).

• User:Whatamidoing (WMF) is trying her best, but is just completely incompetent in her work as a community liaison (I go with incompetent, as the alternatives are worse). She is not a community liaison but a crony of the WMF, incapable of seeing problems, incapable of understanding needs, wants, or even basic posts, making up things to defend her (or the WMF's) position, and more often than not a total waste of time. It's always hard to find when things started to go wrong, but where it for me definitely went downhill, never to recover again, was at en:Wikipedia:VisualEditor/Feedback/Archive 2014 1#Feedback request: VisualEditor special character inserter, with unforgettable statements like "I know that some people find the Agile approach irritating, but since you systematically search for incomplete features, you are consenting to it and supporting it. Whatamidoing (WMF) (talk) 23:21, 29 January 2014 (UTC) " Discussions further down that page (e.g. "Empty <ref /> tag added by VE" or "Advanced image settings? More VisualEditor rubbish.") illustrate similar problems with Whatamidoing and JDforrester. These are old, I use them to indicate where things went wrong and for how long these user interaction problems persist already. The current VE feedback page on enwiki shows the ongoing problems with Whatamidoing. See also e.g. en:Wikipedia:VisualEditor/Feedback/Archive 2014 3#Utter waste of money. Another good example is en:Wikipedia:VisualEditor/Feedback/Archive 2014 3#Category additions with VE are FUN!, where Whatamidoingis doing everything but helping. Her attitude is "it is a local enwiki non-VE problem unless you prove to me otherwise", not "hmm, I wonder if this is enwiki only, let's try it out". In many disucssions, she makes categorical statements, which give the impression of her being knowlegeable when they are correct, but only make her look foolish when they are wrong, which happens way too often.

Other editors may have other experiences of course, but for me it really has gone to far for much too long. Fram (talk) 09:31, 25 September 2014 (UTC)

Communication is an item that is on top of my list. I want to say however that we are all trying to work in good faith; nonetheless there is always ways in which we can improve and I -- for one -- am learning ways to do so every day. I don't communicate perfectly, but I work on improving. I can tell you with 100% certainty that am asking the same of everyone at the Foundation as well and now providing resources for doing so. -- LilaTretikov (WMF) (talk) 05:51, 30 September 2014 (UTC)

Thanks. I am not convinced that all of them try to work (for the improvement of Wikipedia) in good faith, at leat one comes across as a power-hungry bully only interested in his own success-rate (product is delivered!), not in the actual result or in what the editing communities want or need; but most of the above are probably good faith workers in the wrong position. Fram (talk) 07:45, 30 September 2014 (UTC)

There are plenty of IRC logs made public from the first two that would have led to them being fired if the WMF used standard practices found in other non-profits and businesses. The WMF pretends they care about retaining editors and attracting new ones, when it is clear that a PR professional would have instantly pointed to them and some others with advance user permissions as the main reason why talented people are driven off. The WMF is and always will be just a scheme to steal the work of others and give a tiny few money and power. You can prove that wrong by cleaning house - you already know who the problem people are and you know how desperate they are to stay in their cushy positions without producing anything worthwhile. 99.198.74.249 17:05, 5 October 2014 (UTC)

Introducing VP Engineering, WMF

It has been a busy few weeks. Today we announced a much sought addition to our executive team, VP of Engineering. Please see more here. -- LilaTretikov (WMF) (talk) 05:09, 30 September 2014 (UTC)

Although I certainly wish Damon well and hope things work out well for all of us, two things about this announcement appeal to my inner pessimist. One, the description of his qualifications doesn't mention him having extensive experience contributing to wikimedia projects. Two, it says Erik was centrally involved in choosing him. (Well, okay, three things about the announcement, if you count that the photo looks oddly as if he's in a fall catalog ad for either sweaters or possibly sunglasses.) --Pi zero (talk) 19:26, 1 October 2014 (UTC)

And of course that Community Engagement remains the responsability of Erik Moeller... He is very good at uniting the community as never before, the only bad thing is that the WMF as a whole and he in particular are usually the target of the community's rise to action. Fram (talk) 19:51, 1 October 2014 (UTC)

You guys are never pleased, are you :) I recommend we judge Damon by his actions and judge then. -- LilaTretikov (WMF) (talk) 17:02, 5 October 2014 (UTC)

Oh, I have no objection on juding Damon only when he has gotten some time to familiarize himself with the environment and actually taking some actions. I was only judging someone with a slightly longer track record here. Fram (talk) 06:36, 6 October 2014 (UTC)

Scale of billions reminder

I realize you're probably pretty overloaded, I just wanted to post a reminder. There's no indication that you have looked at anything from this point or below. Alsee (talk) 14:01, 8 October 2014 (UTC)

At least no-one implemented a bot to shove all stuff in the back room ;) --♫ Sänger - Talk - superputsch must go 14:03, 8 October 2014 (UTC)

Thanks for the reminder, I actually am reading through these especially as we are working to define how we build our products in the future so they are vetted early on. There is a lot of very valuable information there that I have been internalizing. -- LilaTretikov (WMF) (talk) 18:34, 8 October 2014 (UTC)

The fact that you call it valuable information, and that you're internalizing it, sounds promising. But I fear I may be projecting optimistic interpretation into it. It would be appreciated if you could give us some idea of the direction of your thinking. Alsee (talk) 00:26, 9 October 2014 (UTC)

The Netherlands Stalking Incident

Hi Lila, the recent incident where two administrators, JurgenNL and TBloemink, from Netherlands Wikipedia ([5]) used their tools to find the privacy information of a third, MoiraMoira. They then prank-telephoned her home, laughed about it on official Wikimedia IRC, and then actually took a train trip to go look at her house. When it all was found out, MoiraMoira said she now feels afraid in her own home. Much more information here: [6].

It occurred to me that because of WMF's administrator anonymization practices, MoiraMoira would not be able to get the identification of JurgenNL and TBloemink sufficient to sue them civilly, neither to pursue criminal charges. Since it is WMF that allowed these two access to her personally-identifiable information, don't you think it is time to change the policy? Is there some reason why WMF would want to protect these individuals' ability to do these atrocious acts?

I hope that you are as bothered and outraged by this stalking as any decent person would be, that you will work to change the policy, that the WMF will identify and know to whom it accords the privacy information of editors. Colton Cosmic (talk) 16:02, 8 October 2014 (UTC)

This behavior is completely unacceptable; our support and legal teams have stepped in to help and to work to prevent this in the future. -- LilaTretikov (WMF) (talk) 18:39, 8 October 2014 (UTC)

As Lila says, this behavior was unacceptable. Luckily, MoiraMoira has shown every indication of being willing to move on, so I think talk of a lawsuit here (even a theoretical one) risks being inflammatory. If, however, that had not been the case, we have published documentation that we would point her attorneys to that shows the best practices for working with us to get the information that she would need. Philippe Beaudette, Wikimedia Foundation (talk) 20:07, 8 October 2014 (UTC)

Well, wait, the "information that she would need" would be the identifications that you, Mr. Beaudette, have in the recent past pointedly pledged to destroy all trace of. You said "We've made it very clear that we destroy documents submitted for identity verification" (18:56, 7 March 2014 (UTC)). These documents are the very ones that the police would seek to court-order and MoiraMoira's attorneys would seek to subpoena. Is there some other information you're thinking of, or are you just trying to obfuscate things in secretive, bureaucratic language? I'm also very unimpressed with your comments in the RFC that TBloemink and JurgenNL should be eligible for reinstatement in just one year, or even six months. Colton Cosmic (talk) 21:22, 8 October 2014 (UTC)

Reading that page I guess they mean IP(s), user-agent(s), XFF (given by CheckUser) and e-mail (not given by CU; I guess they take it from the server logs). Basically they're saying they'll give the feds anything you send to the servers (and CU-L probably if there's stuff about you there) but that the identity verification documents are indeed destroyed. User2975 (talk) 01:57, 9 October 2014 (UTC)

Fwiw, although I would identify to the Foundation if officially told I had to, I find it reassuring that, as of right now, if somebody got hold of all information the Foundation has, there's a decent chance they mightn't automatically know where I live. I don't trust centralized databases of personal information; they invite mass security breaches, which we hear about rather frequently. --Pi zero (talk) 02:30, 9 October 2014 (UTC)

Unfortunately, unless you are rich enough to spend serious money and take the WMF to court, as a volunteer you will never know for sure what information the WMF is keeping on you in their databases, and there are no plans to ensure the WMF becomes more transparent by telling you what information is being kept about you. I have no doubt that the WMF has my home address and phone number along with plenty of other personal information in its records and databases. Refer to "Access by Wikimedia volunteers to WMF records about them" which resulted in a firm "no" from WMF legal. --Fæ (talk) 11:54, 10 October 2014 (UTC)

You are, perhaps, a special case though Fæ as your real life identity is widely known given your involvement in Wikimedia UK. If the WMF has information about you somewhere it is unlikely to have been gathered from private sources. That doesn't invalidate your point of course that disclosure of what data is held ought to be something the WMF does as a matter of course. QuiteUnusual (talk) 15:08, 10 October 2014 (UTC)

Care would need to be taken that if somebody hacked an account, they wouldn't then automatically be able to get their hands on what the Foundation has about the account's owner. Presumably one could reveal which information the Foundation had on the user without actually revealing the information itself. --Pi zero (talk) 15:26, 10 October 2014 (UTC)

Hi, again, Colton! We of course take problems like these very seriously, but as we've explained to you in the past, how much data we collect from admins, and how long we retain it, is a difficult balancing act with no easy answers. In this particular case, the process and information you're advocating for would not have changed the outcome - the personal information was never requested nor necessary. And of course as others have pointed out, if government action had been requested and justified, other information is often available, such as IP addresses (for the times given in the data retention guidelines). Given that, we don't think this situation changes the balance we've already struck in the current policy.

We'll of course continue to monitor the situation: how often these sorts of things occur, what kinds of options are available for reliable verification, secure storage, etc. And if one of those variables changes significantly, we'll revise the policies. —Luis Villa (WMF) (talk) 19:12, 10 October 2014 (UTC)

Media Viewer RfC

You're probably aware by now, but there's an RfC at en:Wikipedia:Village_pump_(proposals)#Media_Viewer_RfC. Alsee (talk) 05:54, 8 October 2014 (UTC)

Everything we do is based on self-selected volunteer work. There's a million things to do, and we use a swarm strategy to do it. Everyone is invited, and those who show up are the ones who do the work. Those who show up are generally the ones best equipped to do it. When there is concern that self-selection is producing a warped result then we have procedures for calling in additional random uninvolved individuals. Spamming an RfC is normally considered disruptive due to the volunteer-time wasted. All of this applies to our high level decisions as well. Everyone is invited, and by our standards this RfC has been well advertized. If it makes a difference to you, if it will increase your view of the legitimacy of the RfC, exceptional steps can be taken to increase advertizement and participation by your request. Alsee (talk) 13:45, 11 October 2014 (UTC)

Blarg. I was just trying to address concerns about the number of participants in RfCs. I hope that didn't come across as insulting for over-explaining stuff along the way. Alsee (talk) 23:48, 13 October 2014 (UTC)

Flow Materials

Hi all -- I am reading through the Flow information above and will post some thoughts later in the week. This is helpful, I am especially looking to understand editor workflows (i.e. how Talk is used in article creation context vs. a place like this page, where it is more request/response). Thank you all for your insight so far and your answers. -- LilaTretikov (WMF) (talk) 15:43, 14 October 2014 (UTC)

If you want to see how a talk page works in relation to the article creation process may I suggest taking a look at the talk page of any of the Featured articles. Perhaps the talk page of Audie Murphy? Much of the information from its development to FA has been archived in subpages though so you would need to look through those in the archives. Reguyla (talk) 19:16, 14 October 2014 (UTC)

Fwiw, it has often struck me that the experience of being part of such a development process is generally different from looking at the archives. Perhaps to do with the difference between seeing things change, step by step, in real time, and looking at the accumulated result afterwards. Just something to keep in mind. --Pi zero (talk) 20:55, 14 October 2014 (UTC)

Talk pages of articles of ongoing events currently in the news are probably instructive as well, for an older example see e. g. (among many many others) Diskussion:Nuklearkatastrophe von Fukushima with its archives. Another area Flow will have to excel in are talk pages of heavily contested (e. g. because of clashing world views) articles which repeatedly need page protection, often leading to extensive text drafts (with lengthy pertinent discussions) on the talk page. --HHill (talk) 01:09, 15 October 2014 (UTC)

Besides article creation and policy discussions with community and WMF representatives, another use of talk pages is to report problems to bot operators. I see the term "refactor" has already been used twice above; see en:Wikipedia:Refactoring talk pages for more on this. The flexibility to refactor is a real assset of talk pages. For example, multiple reports of bugs can be refactored to consolidate them into a single talk page section. Wbm1058 (talk) 02:08, 16 October 2014 (UTC)

Ciao to Alessio Guidetti

Dear friends,

Some of you have already learned that a dear community member, Alessio Guidetti (Cotton), has passed away on October 16th. Alessio was incredibly loved by Wikipedians and I would encourage everyone to reach out and support community members that are deeply affected by his death.

You can reach them on his talk page: w:it:Discussioni utente:Cotton#Ciao

And here: w:it:Wikipedia:Bar/Discussioni/Una brutta notizia

He will be incredibly missed. Thank you for sharing your heart. -- LilaTretikov (WMF) (talk) 04:36, 19 October 2014 (UTC)

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)