User talk:LilaTretikov (WMF)/Archive 4

Location of this discussion

Somewhere above Lila said she's not sure where this discussion should happen. The solution is rather simple, she can move the whole content of this page at Requests for comment/On a scale of billions or similar and continue operating in the same way but in a more "official" setting. --Nemo 07:10, 19 August 2014 (UTC)

I think, you don’t mean "move", but copy and paste it there, do you? Because it wouldn’t be good to move (with the function "move") a user talk page to an RfC page, there were also other personal comments on the talk page (also archived ones) before this discussion which shouldn’t end up in a version history of an RfC. But as the comments here all have signatures (or should have), so the authors are clear, there wouldn’t be a problem with copying and pasting the whole discussion to the target RfC page. It would be best, if the RfC page will link to the version history of this user talk page afterwards. The RfC is a very good idea for this discussion, better than here. --Winternacht (talk) 21:23, 19 August 2014 (UTC)

Feel free to copy this if you think the new page is a better place. Note the new process page we are pulling together as well. -- LilaTretikov (talk) 21:51, 19 August 2014 (UTC)

Pete F can you please copy not delete. Also could you please not copy the Working Together section as it is septate. Thank you! -- LilaTretikov (talk) 22:26, 19 August 2014 (UTC)

OK -- I think having the discussion happen in two places will be really confusing but...I'm happy to revert everything I just did. -Pete F (talk) 22:28, 19 August 2014 (UTC)

@LilaTretikov: Sorry if my move wasn't the way you wanted it to work -- I've reverted, and will let somebody else handle it -- as far as I know there really isn't any perfect way to do it, and I don't want to mess it up. -Pete F (talk) 22:31, 19 August 2014 (UTC)

Sorry Pete, my bad. I am not 100% up to speed on talk page mechanics... -- LilaTretikov (talk) 00:00, 20 August 2014 (UTC)

Not to worry! I just realized that there was a potential for it to become a big mess, and wanted to revert what I did before it was too late. It looks like @Winternacht: has done a better job of it now. If I could suggest, finding somebody to mark the RfC for translation ASAP would probably be a really good step. -Pete F (talk) 01:05, 20 August 2014 (UTC)

If there are any sections in the RfC that don’t fit there, they can also be placed here again instead.

Translation would be a good idea, I just don’t know how that could be done with these lots of comments there. Or do you mean, the initial statement On a Scale of Billions and Lila’s questions shall especially be translated? That would be a very good idea, because they are essential to the RfC. --Winternacht (talk) 01:24, 20 August 2014 (UTC)

Could you create sections for those here so they are visible in the TOC please? In all honesty thought it is easier for me to watch this -- more pages strain my bandwidth for sure. -- LilaTretikov (talk) 15:19, 20 August 2014 (UTC)

I think it’s better to copy and paste the discussion, meaning that the content (not the page itself) will move to the RfC. If it is only copied (but not deleted here), then the same discussion will be on two different pages which isn’t good. So, now the question seems to be, which parts of this page shall get into the RfC and which ones should stay here. Perhaps, it would be best to leave the first section #WMF superblocks its community here and start the RfC with the second section #On a scale of billions which shall be the title of the RfC. And as Lila said above, the #Working Together shall also stay here. So all other sections can get into the RfC (copy and delete here and paste it there). Is that ok? --Winternacht (talk) 22:46, 19 August 2014 (UTC)

And, not mentioned, this section should surely also stay here. In the beginning of the RfC, there can be placed a permanent link to the top section here, so that the connection to it will be clear and that it was a response to the questions raised and the discussion there. --Winternacht (talk) 22:59, 19 August 2014 (UTC)

So, I’ve tried to do this. Now the content is at Requests for comment/On a scale of billions. I hope, this is ok this way. If any section shall be at another place now, it can also be copied and pasted this way. --Winternacht (talk) 00:23, 20 August 2014 (UTC)

Perhaps the top of the RfC could clarify a bit more about the RfC, I don’t know. I tried to put some initial information into it. If you or someone else have a better idea for that, please improve it. --Winternacht (talk) 00:55, 20 August 2014 (UTC)

How do you guys do this???

I am just SOOOO amazed you all are able and willing to make your way through these pages. This takes serious dedication! I am even more amazed how new editors survive this antique experience. This IS the stuff we've got to focus on. MV is such peanuts, we should really not be spending our joint mental cycles on. It will take all of us a lot of time to make this basic stuff work: conversations, data normalization, messages, etc. work... -- LilaTretikov (talk) 15:19, 20 August 2014 (UTC)

We (the users) spend a lot of our time and knowledge in this project. And we were proud to be part of the knowlege project. We are not happy with the MediaViewer at this stage and didnt want to use it in the DE:WP. You will be able to get a true translation of the "Meinungsbild".
But we are really upset and agry, that the developer of this tool can overrule the communities just because he can, in his own case. I called that "Führerbefehl" on this discussion page, which is something that the Americans tried to eliminate from Germany. Perhaps thats the reason for the strong reaction from the DE:Community.
You have to put the superprotect back in the garbagebin. Then we will discuss further on the MV, its merrits (yes he has some) and his deficits. --Eingangskontrolle (talk) 15:45, 20 August 2014 (UTC)

Eingangskontrolle; BITTE! Godwin’s law. Das muss doch nun wirklich nicht sein! ...Sicherlich ^Post 16:06, 20 August 2014 (UTC)

@LilaTretikov: its far less about the MV then about the force you use ...Sicherlich ^Post 16:06, 20 August 2014 (UTC)

LilaTretikov, that's exactly the wrong attitude. This does work. It works well. We've communicated this way with each other for a long time and have very few complaints about it (well, until WMF broke sections of it with Echo, very few ... now just "few"). Telling us that everything about the way we communicate is wrong, the things we are upset about are "peanuts", and your highest priority is to make us do everything differently is exactly why we get angry and frustrated with the WMF. Kww (talk) 16:06, 20 August 2014 (UTC)

I did not mean to say it was "wrong", I said it was "hard", especially for new people. Big difference in those two. And I also did not say that you are upset about "peanuts", but that maybe lost in translation, I said that MV should be low priority when we have really major issues to work on. Does that make more sense? -- LilaTretikov (talk) 16:11, 20 August 2014 (UTC)

Actually, you said it didn't "work". I agree with you that MV should be a low priority: since it isn't useful for much and isn't critical for anything, there's no reason for the WMF to insist on it being on the German Wikipedia against their will. It's creating a battle over nothing when there are important things to work on, and alienating an important core group of editors for no purpose.Kww (talk) 16:53, 20 August 2014 (UTC)

This was a rhetorical question :) Editors should be spending time on content, right?, not on learning (or dealing with) antiquated software -- I hope we agree there. And we should have clear parameters for "good enough" and strive for an objective Meinungsbild (if I understand the word correctly). What I am saying is that some things are not worth spending OUR (community, which includes the WMF) time... But I understand the anger -- as unintended as it was and, as I mentioned, we are working to lift the superprotect and create a process around managing changes, which we need. Frankly I think that's the real issue, MV is...well... just a symptom that is consuming more time that is due for it. -- LilaTretikov (talk) 16:08, 20 August 2014 (UTC)

But that is a matter of point of view. When i want to programm something, i have to learn the coding language. And for Wikipedia youa lso have to learn certain things, what is quite easy since a technical not very understanding guy I learned to edit Wikipedia well. And we see every day that new users can cope with it. A certain level that must be reached also prevets people who are not able to really contribute to our mission to take part. Your own research signifies this: what holds readers back from becoming editors is their lack of interest in this possibility and their lack of knowledge, technical problems are far less important than the WMF likes to pretend always.

If you want to help people joining technical: Make a good turtorial where they learn the basics from setting a link to using refernces and so on. Every little computer game uses this way, here it would help also. For the rest of the questions we have a mentoring programm at de:wiki and other place where newbies can reach for help and support. But you have to understand that the goal the everyone takes part is neither realistic nor would it be good. --Julius1990 (talk) 16:17, 20 August 2014 (UTC)

Yes, of course it should get better, and your passion for making it better, and knowledge about technical options, are going to be a great asset. I suspect that the skepticism you hear from @Kww: is a reflection of the dynamics @Theo10011: brought up. "These things could be better" is a very positive sentiment, and should be applauded. But it can be a very small step to "I know what is better for you, and here is how it will be." Especially in the wake of superprotect, I think you may find that many people respond as kww did. -Pete F (talk) 16:18, 20 August 2014 (UTC)

I worry about that use of the term "antiquated". I favor well-chosen software improvements (in fact, I'm donating huge amounts of my time to that end), but not all new software is an improvement on old software. I'm pretty appalled by Flow, for example; I don't think anyone around here has yet come up with anything as good, for general discussion, as directly editing the wiki markup of a talk page. (I've also remarked elsewhere, I think VisualEditor is likely to seriously damage the long-term future of the wikimedian movement, exactly because it prevents the user from working direclty with wiki markup, and thereby cripples their ability to see the markup others have written.) So, depending on what you mean by "learning (or dealing with) antiquated software", you may find we won't all agree. --Pi zero (talk) 16:52, 20 August 2014 (UTC)

Pi zero, VisualEditor is in no sense intended to replace wikitext. For example, there are some places where using VisualEditor makes next to no sense and the wikitext editor will be the default (e.g. the editing of pages in the template namespace). But, more generally, wikitext is not going anywhere, and in fact the Editing team has recently taken on ownership of the wikitext editor as well, so that the editing experience can be looked at and improved holistically. You can ask James Forrester for more information about this topic, if you like. --Dan Garry, Wikimedia Foundation (talk) 19:52, 20 August 2014 (UTC)

That's what I'd call 'tentatively reassuring'. And yet, I've actually seen the phenomenon of a user baffled by how to do something they've seen others doing on wiki pages, because they've been using VE so they couldn't see the wiki markup. --Pi zero (talk) 20:22, 20 August 2014 (UTC)

I might clarify, that it's tentatively reassuring in the sense that it isn't as bad as it could be. However, there is really no situation in which it wouldn't be better for the wiki to not divert users from experiencing the wiki markup itself; reducing exposure to wiki markup is always damaging. Perhaps the editing experience can be improved; but I believe doing so to be less of an issue in new-editor retention than other issues that nobody wants to face up to because they're 'too hard'. --Pi zero (talk) 21:11, 20 August 2014 (UTC)

To echo what Kww said, the way these talk pages work isn't really the problem. Editing encyclopedias, correcting typos, arguing for weeks over hyphen, em-dash and en-dash, is not a task everyone excels at for a good reason - very few do, even fewer enjoy it. Editors don't mind the antiquated software - some enjoy it, some specialize in it. A good majority of tools, bots were built by those community members before there was this version of WMF - I'm sure they are still more qualified than your staff at it. The learning curve here is steep but most get a hang of it in a few days - you will too. You see this was never meant to be facebook, all our communication is incidental to the larger task. Of course, this seems antiquated, and it is - but that's why we're here. One can argue encyclopedia itself are a pretty antiquated thing, or typing away and researching pages and pages of text about obscure topics for nothing in return. Those new editors that you do bring in who treat this like FB, will not do the "curation" work that rebuilds wikipedia daily. I'm sure, you can "hip it up" with a slick interface which makes everything look quick but you might alienate more than half the community that built it. A slicker system of communication will not change people's opinions - there will still be mountains of tomes to work through when WMF disrespects them openly. If you limit that, then again, off they go with a fork - it's quite easy to mimic this antiquated system too. Anyway, you are probably headed in the wrong direction if you are undermining MV and want to replace the underlying software all together. Theo10011 (talk) 16:57, 20 August 2014 (UTC)

Drifting a bit right? :D - I think the idea of the visual editor is quite okay. For new users it might be more easy; if it works properly! - While earning my money I do that with WYSIWYG-software as well so why not in WP. ... Of course, and I include myself, experienced wikipedians might not use it as they dont need it. But as long as an editor can choose; why not giving the option? ... Becuase wasted money? Maybe but we (actually not us but WMF) has more then enough. so spending some on software might not be the worst idea :o) ...Sicherlich ^Post 17:11, 20 August 2014 (UTC)

"This was a rhetorical question :) Editors should be spending time on content, right?, not on learning (or dealing with) antiquated software -- I hope we agree there.

Hi, thank you for getting involved in the discussion. However, I'm afraid we don't agree on that point, for two reasons:

1. There is already one assumption (that the software is "antiquated") leading to one implication (that it is no longer fit for purpose). I do not feel that is a fair representation of the current state of the software--it is quite possible that it needs some improvements, but those should be evolutionary rather than "revolutionary". On a project of this scale you don't really have much choice (take a look at Unix/Linux) for an example of a project were change is "done right", i.e., a small bit of change at a time, and mostly following demand rather than making it up.

2. I realise than in order for the WMF to stay relevant and keep raking money in (which is your job, after all) the project needs to attract some new blood. However, I will posit that you do not want to lower the barrier to entry too much--there must be some moderate level of effort that a candidate editor should have to go through in order to show his motivation to contribute meaningfully to the project, least you end up trading quality for quantity. For example, learning wiki syntax (about twenty minutes) is in my opinion appropriate for someone who wants to make some entry level editing--perhaps correcting a few typos or adding a few links, categories, etc. Someone a bit more advanced and willing to dedicate more time will naturally want to interact with other editors and will end up having to learn about the mechanics of Talk pages and the like (I agree those should not be too arcane, but I don't think they currently are: I'm not even an editor myself and can figure them out just fine... except on some pages where some template tries to make them look like discussion forums, I get lost there actually). Eventually anyway, you are going to end up getting to a point where even the easiest editing / chit-chatting tools in the world are not going to be any help: if you get involved too much you will end up needing to learn about all the (constantly changing) policies and idiosyncratic stuff that more or less governs this whole thing. People are going to have to invest time learning those too.

But the most important point is: the WMF should not be there trying to second-guess Wikistuff users. The WMF should limit itself to 1) running the day-to-day technical and administrative bits and 2) acting upon community requests for improvements to the project and, perhaps very occasionally, new developments. Let us not forget that this project was built not just for users: it was built by users too. Trying to take it off their hands is just begging for trouble.

So, my apologies for being slightly long-winded, but in answer to your question ("How do you guys do this?"), I suspect the answer is: they are a bunch of motivated people who are willing to invest the time to learn how to participate. You would have to ask an editor, which I am not, however. — The preceding unsigned comment was added by 2a00:1028:83a0:291e:762f:68ff:fe2d:429e (talk) 00:18, 21 August 2014 (UTC)

@LilaTretikov: You wrote "MV is such peanuts, we should really not be spending our joint mental cycles on." - If it is such "peanuts" for you, then why do you not just switch it to "opt-in" in those 2 wikis? All the wasting of time will be immediately reduced to a minimum! --92.226.45.154 09:13, 21 August 2014 (UTC)

+1. However, i am a bit astonished that, you, Lila, seemingly still not realize why such "peanuts" caused such well-grounded uproar. First, as was explained several times already, it was not caused by MV in itself, but by the behavior of WMF, where on enWP e.g. threating admins and on deWP, superprotect was merely the last straw. This "peanuts" was thus seen as a clear manifestation of an attitude by WMF that we will not accept. Now, we see that we were right in this perception, as Jan-Bart and others are currently laying out their vision for WMF's "future" clearly. There simply will be no more "OUR (community, which includes the WMF)" in this "future". The current "WE" was based on principles such as the 4th mentioned several times here, the rules for WMF office action excemptions and so on. By breaking and ignoring those rules (Jan-Bart: it "applies to some degree"), you have killed this "WE". You also seem to have no idea of how the software you call "antiquated", being software that actually works, relates in comparison to what you spend your money on.

I think, there would be a very time-efficient way to shorten nearly all of these discussions you find so astonishing. I freely translate from User:Micha L. Rieser:

I have a proposal for all current and future WMF members: They all have to write 9 articles of high quality, applying our state-of-the-art rules and methods [i take this to include image upload and inclusion]. The topics will be preselected. They will only research and write the contents for themselves. 3 articles they have to write in the "classical" way. The next 3, however, with VisualEditor. 3 they have to write with the new editing functions of the mobile apps on iPhone/iPad. For the last 3, they are only allowed to upload images with the commons-App. Of those 9 topics, 3 might be irrelevant. It will be guaranteed that some will be proposed for deletion. They will have to provide successful defense in these deletion discussion. For 3, there are sources, but hardly so. When they have done so, and all 9 articles are included in article space, and by that time none of them has been blocked because of rude behavior, they may go on and develop and maintain their software. Let's just see, what kind of software we will then have to expect and how priorities for development will then look. -- Micha 00:39, 20. Aug. 2014 (CEST) PS: in the US, people could call it "eating your own dog food" ...

I suggest Jan-Bart should start first... Ca$e (talk) 09:37, 21 August 2014 (UTC)

---

Dear Lila,

I had the honor to see you in London. I saw with (positive) surprise, how you are responding here. My deep respect for that. Thank you.

I have to admit, that I am very straightforward. But after reading Editors should be spending time on content, right?, not on learning (or dealing with) antiquated software, I can not hold back anymore and have to share my thoughts.

• in fact, learning (and teaching) is a big motivation for me volunteering at Wikipedia
• here are a lot of people, becoming good photographers because they are contributing to Commons, dealing with the difficulties at hand
• here are a lot people, becoming good software developers (you are even temporarily employing some without a high-school diploma) dealing with antiquated software
• here are many people editing code the first time in their life.

Erik asked in London if there are any editors without a certain background, who ever edited templates... I am one of these. I did it, because I saw others were able to do it. 12-year-olds were able to do it. (Because they are aloud to play around.) I experienced a lot of encouragement of my colleagues. So I tried... Doing it the first time it gave me a boost of motivation. Motivation a little "thank you"-notice would never be able to produce, because I had learned something knew. I was able to do something new...

I am spending time on content, to learn... The time I won't learn something new anymore, will be the time I do leave this project and spend my time somewhere else...

I am here, because I was treated with some earnest respect, not as a dump editor, contributing some low-cost-content to an online paper, like The Huffington Post. Wikipedia gave me something back - education, knowledge, self confidence, even some friends. I never wanted to become a regular Wikipedia-editor, but I am. I never wanted to organize an event, cause I did not know how to do. I learned. My second WikiConvention, nevertheless my second one as a member of the organisation-team, will take place 3. to 5. October. The first meeting of Austrian, Czech, German and Polish editors took place in May... followed by a second one with Czech, German and Slovakians in Poland[1]...

Nothing of that would happen, if Editors should be spending time on content, and on content only.

All about Wikipedia and other projects is about learning. Not only about reading a text and contributing text. Taking this away with "hipper software", this experience of doing something new, of helping each other, of seeking and getting help, will do a lot of harm to the movement.[2] More harm, than seeking help of the WMF and getting nothing back, will ever do.[3] The last one is a longtime everyday experience of "just editors", so we learned to expect nothing, the only thing we are hoping for: don't make it worse. Even one click more to be able to edit[4] is worse. A development a company would never tolerate, because it costs time of employees[5] and therefor a lot of their profit.

Today, some of us are feeling used like beeing Charlie Chaplin in Modern Times.[6][7] The only advantage we have: we don't have to build the Tin Lizzy to feed our kids.

Software has to be changing, to improve, not to do the same a different way or to build Potemkin villages and leave the mess behind. New software has to be inviting. 19% of our "future editors" are unaware anyone could edit. Only 6% are not comfortable with tech.

If new potential editors are worth the effort (advertisers are not), today we do start with something people are comfortable with: writing e-mails, encouraging them to use the talk page, showing changes to improve articles, inviting them to edit-a-trons and meetups. It took me months to get a donation of photographs. Time I am willing to spend, writing e-mails, explaining copyright, cc-licenses and the upload-wizard - only to be uploading these pictures myself, waiting for the OTRS-ticket to arrive, half the time. The other half I get nothing. I'd be aloud to use it on Wikipedia, but not with a free license (too much to read). To be able to start a cooperation with a GLAM-institution is a highlight.

The problem we are facing is not an old-style-talk-page or an immature MV. The problem we are facing is: people do not know that there is a talk-page at all. Most readers do not know that there is a history. Readers do not know, that they are able to view a picture with higher resolution by clicking on it. The only thing, most readers do know: there is an article to read. (I got this information while talking to people face to face. People watching me editing and asking questions on a train, in a hotel bar or a library - experiencing for the first time: "I can edit Wikipedia!")

The biggest problem is not the antiquated software at hand. The biggest problem of potential new editors is the unawareness of the possibility to contribute. --Anika (talk) 18:54, 21 August 2014 (UTC)

How we do this

tl;dr: Please don't let Flow make the problem worse as a reaction as to how broken this is now.

You're in a maze of twisty little passages, all alike

--The "Alike" maze in the Colossal Cave Adventure, Will Crowther

We do this with mild annoyance and a lot of experience. Yep, that's a pretty bad thing, and ought ought to be fixed really. I'm going to write a fairly long story about wikis and wikitext here; If you want to be involved in improving that, I think it's important to know some of the background, the prior work, and potential pitfalls along the way. Wikitext - and wikis in general - were created to be able to edit documents collaboratively online. Nothing more, nothing less; see something on a website you think can be done better? If that website is a wiki just go ahead and fix it - without any reading, discussion, red tape, approval committee, delay. Just go in, click edit, change the thing, click save, done. On this foundation Wikipedia was built, and it served us extremely well, at least up until fairly recently.

You have probably noticed that with this model, discussion is just not part of the equation. It doesn't exist. This is very much by design. Be bold! Don't discuss it, just do it! Action before discussion. At Wikipedia we noticed that this does indeed work great in quickly moving forward, but becomes difficult in cases of conflict, and for sharing thoughts, opinions and ideas behind edits. The found solution was simple. Attach a second page to each page, call it a talk page, and use if for discussion. Here, two things went wrong. First, pages of wikitext are not tailored for discussion, and secondly, cross cutting problems that affect multiple pages have no place now.

The first problem was annoying, but not completely impossible; you can construct your own discussion structure on top of wikitext. The advantage is that everyone who wades into a discussion - remember, discussions are secondary to editing the wiki, so by the time you get involved in discussion, you aught to already have a decentish grasp of wikitext - already knows the formatting works, and lo and behold: it actually worked! Plus, it has all the tools we're used to in wikitext! Bonus! Sure, it's not the best software for discussions, but with the added bonus of it being wikitext, and thus being able to discus pieces of the actual article text, it beat the alternatives already present, plus, it can be done with what we have, so no complexity overhead in either the mental model, or the software stack. Double win!

For the second problem, cross cutting concerns, we created a meta namespace to centralize discussions. As the wikimovement grew, and cross-wiki concerns needed to be addressed, we created an entire meta wiki; that is this wiki. It worked, sort of. But discoverability was a problem that was never addressed, and keeping track of which discussion is where, especially once they get moved proved to be a major problem, one we never solved. Meta wiki is fairly small; through recent changes it's possible to keep track of pretty much everything. It's a hack, but a hack that works. It's not, however, a hack that scales. On English Wikipedia for example, it's pretty much impossible to keep track of what's happening through recent changes, even if only the recent changes of the meta namespace are considered. On top of that, there is the overhead of needing to follow meta and your home wiki if you want to keep track of everything. Oh, and if you're interested in what software might be coming to you soon(tm), also keep track of the recent changes on MediaWiki. And the mailinglists (home wiki, mediawiki, wikimedia, wikitech and design) of course, that goes without saying. And better keep an eye on Bugzilla too. Though some projects primarily use Mingle and/or Trello, so those too. Soon the situation will be better if everything switches to Phabricator though. That migration is still in early stages, so for now, while it's a good idea to also keep track of Phabricator for some pilot projects, don't leave the old channels just yet.

But that's insane! I hear you think. Nobody could possibly keep up with all that, and remain productive in writing on the wiki. And you'd be quite right. We don't, generally, keep on top of everything, because there is too much to keep track of. We try to keep track of the important stuff, and let the rest slide. To keep track of the important stuff though, you would have to know what the important stuff is. How do we know? Well, we don't really. Or we notice too late. It should be noted that while the lack of structure and discoverability increases the problem, the problem itself is the sheer volume of meta discussion. There is no real fix for that. The WMF software teams are acutely aware of this problem, as their struggle with it is real. I would easily wager you that if you asked anyone from any software team that had a troubled deployment what went wrong in communications, they would give you an answer that comes down to that there are no universally monitored channels to efficiently communicate in, and that getting conversation started is a major difficulty. Also, that once they find channels have at least some people in it, it turns out those channels are full of unreasonable reactionary critics that don't speak for the entire community. How the people who care greatly about the software correlate with people who are critical of the software, and people who navigate most of the above mentioned maze of different discussion and announcement venues I leave as an exercise to the reader.

The discussion problem hasn't gone completely unaddressed. A community member created Liquid Threads(LT), which addresses some of the shortcomings of the discussion format issue. It had some inherent problems though, was picked up as a WMF project to initially guide and later take over development, iterated to LTv2, needed even deeper refactoring, started to iterate towards LTv3, and was eventually abandoned as ultimately nonviable without re-designing from the ground up, while a competitor that had some similar goals (Flow) which represented the shining light in the glorious future was being also being developed.

Flow, in the mean time, is deeply flawed in its premises. I won't go in to it very deeply here, because that's not what I'm writing about here, but Flow seems to be designed primarily as a means for leaving comments and replying to comments. It reminds me a lot of Disqus, which is absolutely great for leaving comments and replying to comments, and I think Flow, despite having some rough edges at first, will succeed in this goal. Having a discussion meanwhile has very little to nothing to do with leaving comments and replying to them. As such it's no replacement for talk pages. If nothing drastic happens it will be the next major shit storm, and I will take absolutely no pleasure in saying "told you so" when it happens (but I will). I hope I'll be proven wrong.

There is a reasonble line of thought that goes roughly like this: "We have problems with discussions" -> "These problems are large, and need priority" -> "Flow fixes problems with discussion pages" -> "Putting more resources towards implementing flow will help our goals". That reasoning is mostly wrong though. The major problems with discussions is keeping track of them, archiving them transparently, and not overwhelming the potential reader with their quantity. It primarily fixes the wrong problem (and as I explained earlier fixes the wrong problem in the wrong way IMO)! Just take a look at https://www.mediawiki.org/wiki/Flow#Rationale : All expectations that are violated can be viewed as reasonable expectations, that should reasonably be honored (except IMO that it supposedly is a problem conversations can currently nest to infinite depth. Deep discussion require, well, depth), but they are hardly the greatest problems we currently have with discussions. Just take a look at yourself; you started editing here, and got stuff wrong initially: problems with signatures, problems with where to reply and put your post/reply, what to social conventions are with indentation as a marker of who replied to what, and the good old turn-off called wikitext. Flow will fix all of that. But ultimately all of that is a hurdle that can be fairly easily taken. The penalty for doing that stuff wrong is extremely small: someone will say "hey, you did x wrong. I fixed it for you, you can do it like y in the future". Remember that a fundamental part of a wiki is that if you do something valuable, but do it wrong, someone else will fix it, retain the value, and no harm is done.

edit: I forgot this paragraph, which I inserted after Ca$e replied. As such Ca$e may no longer support everything they wrote (though I doubt it). Sue me ;) The real problem however occurred after the discussion was moved off your talkpage. Where is it now? Where is the context? Where is its history? Are there related discussions somewhere? Where would that be. Are there other discussions elsewhere that are important to the same issues? Where should this discussion be held in the first place? Are there people who would want to see that discussion, but don't see it now? How do you drive this damn thing? Isn't that the problem we need to solve, rather than having signatures inserted automatically, automatic indentations, or limiting maximum thread depth? I would be inclined to say it is. Flow doesn't do a thing to help that.

I lied though. The real stinker here in my opinion is that flow also fixes some of the problems of keeping track of discussions. So it does help with the original greater problem! Pinning our hopes on Flow to at least assist us in making the situation less terrible hinges on Flow actually getting implemented, and because of all of the other stuff, I doubt that will happen in any overseeable time frame - at least without forcing it and/or using superprotect to ensure it. That's a situation nobody wants to find themselves in, and I think we're already made a fair bit of headway into that road. If that happens (again: it will) all the good things in Flow will have an even harder time of finding their way to the wikis and being accepted as the way forward. When people will reject it, or find their way around it, they will find their way around all of it.

It would be really nice if I didn't just have all the questions, but also had all the answers. I don't, I wish I knew how to fix this problem. I can tell you Flow isn't it though, and that it can, in fact, hurt to try. Martijn Hoekstra (talk) 10:05, 25 August 2014 (UTC)

Thanks, Martijn, i agree with almost all you of your explanations and hope that they will shed light on critical aspects many WMF employees obviously neglected. In addition, i already commented on Flow on this page: "Flow definitely will impossibly ever work. People who stand behind Flow have evidently no idea how e.g. the actual moderation of discussions works in a very fluent collaborative project that is trolled more every second, that by the minute needs to move discussion threads from here to there, that needs frequent and convenient cutting and pasting of subthreads, on-the-fly indentions, adaptions of signatures, almost all and much more of that also to be done by bots, etc etc. If Flow could be made completely backward-compatible and then also serve a special opt-in role might be open for discussion, but i severely doubt it, maybe subparts of its code could be reused within a proper project design." Just have a look at https://www.mediawiki.org/wiki/Flow#Rationale and subtopics like "How will Flow handle spam and vandalism?" as well as "Will we be able to edit other people's posts?" and then go and follow a few days how we actually manage high-impact discussion pages, how many subthreads we have to modify, move, rearrange, etc, sometimes on a per-hour basis, and of course not only by admins. All of this already is a very unwelcome business for us, who would much rather focus on direct content creation and improvement, but every single additional click or wasted second in managing discussions would scale immensely. We will never take it upon us to moderate discussions with Flow, which for many cases would already be impossible from the start. Hence, if Flow would become implemented across WP talk pages, this would simply stop our involvement. In a few months, you could then simply freeze or trash WP, as without usable talk pages - and unmanaged discussions become useless in all cases of higher discussion volume -, there would be no more means to resolve conflicts and direct content development from quality erosion to improvements in quality. (We already explained all of this and much more several times and years ago, but, as with other stubborn WMF behavior, we are simply ignored!) Ca$e (talk) 10:45, 25 August 2014 (UTC)

Well, my outlook isn't as bleak as yours. I suspect that Flow will just go largely unused, and more discussion will move to WP: space, which are not talk pages, so won't have any Flow involvements - like ANI, RFARB, and all other noticeboards already are. Possibly Flow will have positive attributes, and the "comment" style can actually work for articles in conjunction with normal talk pages. Time will tell. When confronted with a choice to leave a comment or to edit the article, I fear there will be more readers who do the former, and less who do the latter, and while bleeding out reader/editor conversion, even the comments themselves will barely be used to improve the article. Things like third opinions and small RfC's, smaller move discussions, content disputes, etc. etc. that are now done on an articles talk would move over to WP: space, which would make things less transparent for the reader rather than more inviting to get in to. I would regard that as a mostly failure, and I don't want that to happen. We could actually use something better than current talk (though I maintain that it's not as important as it's made out to be), and there are good parts in Flow. In short, the wiki won't explode, due to the terribleness of Wikitext we're accustomed to working around stuff that doesn't work for us, and I expect that to happen with Flow. But I can hardly call that a positive outcome, especially if it will cause the useful parts of Flow to be dismissed as "just another part of the thing we don't want to use". Martijn Hoekstra (talk) 12:05, 25 August 2014 (UTC)

Flow breaks the possibility to include tables into discussions, it breaks the both the (different) publishing processes in English and German Wikinews, it would also makie it neary impossible to discuss category structures using trees (with asteriskses) and tables, it also hinders the collaborative editing of tect proposals (like in case when article page is full protected, e.g. due to editwar). Flow is just another dead end project and should be abandonded ASAP. --Matthiasb (talk) 17:09, 29 August 2014‎ (UTC)

Hi all, I'll keep my answers somewhat brief, in the hopes that you come discuss Flow in greater detail, over at mw:Talk:Flow. Overall, Flow is a long way off from being ready for wide-deployment. They need and want your feedback/suggestions/bugreports/feature-demands/questions, so that Flow will eventually grow into something that we all want.

@Matthiasb: Tables and lists work completely normally in Flow, as does almost all wikimarkup; see this topic for example. There were some statements about Flow a year ago (from staff and volunteers), that were either inaccurate at the time, or are no longer accurate. There are still a few missing or buggy elements (categories and <math> at the moment), but they're being worked on. Tables, templates, refs, and markup, all work as expected.

@Ca$e: The usergroups that are able do certain actions can all be changed (even per-wiki, and possibly per-namespace or per-page). It could all be opened entirely, or tweaked based on specific needs.

Moderation actions are getting re-examined soon - they're adding (rollback|undo) links to the history pages soon (so we'll have feature-parity there) - the additional/new buttons in the dropdown menu can be adapted/improved based on our feedback.

Move/Split/Merge features are all planned, and are crucial elements before it is widely deployed.

Most importantly, the Flow API is fully functional (albeit not very well documented yet), so bots can work with Flow content already. In the future, with more feedback and development by everyone, bots and scripted-tools should be even more powerful than they are with wikitext, because each person's Flow post is a distinct chunk rather than potentially spanning many ::::indents, and each topic is distinct so it can be categorized (or #tagged as some people have suggested) or used in multiple places (eg. a deletion discussion could be inserted into the article-talkpage itself, as well as a central deletion board, plus any wikiproject-specific boards).

@Martijn Hoekstra: Your explanation starting this section is great. Thank you.

Re: "[...] after the discussion was moved off your talkpage [...]" - The Flow devs are collaborating with the Search devs, now that Cirrussearch is stable and widely-deployed. Helping people to find existing/old discussions, is one aspect that Flow should easily handle. It could (potentially) work like bugzilla's "possible duplicates" suggester, when we start typing a new topic title. It already does keep the Topic's history separate from the Board's history (as well as duplicating it into the Board history, for consistency with the regular wikipages), so when we move/archive/etc a topic in Flow, the history will follow right along (unlike our usual cut&paste archives).

Flow should eventually end up, (imo) as powerful and useful as gmail crossed with yahoo pipes, for working with all the elements of collaboration that it needs to eventually handle. But it needs a lot of time, and more importantly a lot of (forward-looking, large-scale & fine-detail feedback/experiment loop) input from us, for it to get there.

I hope that helps, and that you'll become regular collaborators over at mw:Talk:Flow. Quiddity (WMF) (talk) 04:52, 30 August 2014 (UTC)

Sorry, so that Flow will eventually grow into something that we all want hopefully it will not. If you're talking of the version history. It's confusing, simply not practicable. I don't want Flow, and I hope that most other Wikipedia users share my opinion. --Matthiasb (talk) 13:37, 30 August 2014 (UTC)

Thanks for your commments @Quiddity (WMF):. It's never fun when somebody is critical about something you're putting a lot of passion in making, and I appreciate you're responses. My two main concerns still stand though; firstly that the main discussion problem we have is one of tracking and discovering discussions, and that Flow currently does something, but little to remedy that, and secondly, because to me it still feels mainly as a commenting system (in that regard it suffers the same problems as LT). Keeping track of who is replying to whom in a complex discussion is just hard. The "Disqus" way out, limiting reply depth is far better UX for brief comments and replies than what we have now, but that is the case we need reform for the least; it's the complex, deeply nested, deeply intertwined discussions that are a mess now, and I'm not seeing Flow make it better, or that better coming from the "discourage complex discussion, because complex discussion makes for terrible UX" model. When it comes to organizing discussions, apart from all the non-wiki venues, for which flow doesn't really help much either, I'd much rather see bug 3525[8] (links from mw m w) (from 2005!) solved, than a completely new way to approach talk pages. I see no mention of Flow in that bug, nor in bug 64475[9] (links from mw m w). The main point I was trying to make with this post is that while Flow does some great things, it will not solve the general communication problem, and solving that problem seems to be an afterthought compared to easier comments - in a workflow that is not currently part of our workflow, and stand to debate whether or not it should be - and prettier design. At the same time I can guess (though honestly this is just guesswork at this point) that Flow is being sold as a great way to reduce the complexities mentioned here, and I think that's an unreasonable representation of Flow. That is basically what this post was about. @Mathhiasb: if you're saying it's confusing and simply not practicable, the goal of making it into somthing we all want is obviously to fix that. I don't find your objection to making it better because you don't like how it is now reasonable. wheras I find mine completely reasonable. Obviously Martijn Hoekstra (talk) 16:36, 30 August 2014 (UTC)

To clarify: I don't want to rise the impression that I do not appreciate you work, Quiddity (et.al.), it even seems that compared with other WMF software projects we saw in recent time the Flow project workers pay really attention to user feedback and develop a software feature with trying to avoid to rollout a prealpha version all over Wikipedia – this is quite an achievement for itself. For an, as Martijn pointed out, "Disqus" alike usage it seems to be good, stable and pretty, but it isn't a feature usable in Wikipedia. I think it is very adequate for pages where mostly (if only) not-editing users ("readers") comment, for ex. within the "opinion" namespace in English Wikinews (equivalent to "Meinungen" namespace in German Wikinews). But not in article talk pages, project talk pages and the like. One reason is that talk pages ever are also a kind of sandbox/tutot area for teaching new users how to edit articles. Talk pages also are used as area for drafting parts of articles collaboratively in cases in which the article itself is protected (perhaps due to an editwar). --Matthiasb (talk) 19:25, 30 August 2014 (UTC)

On the last sentence: this use case for talk pages being used to collaboratively draft article text was already flagged up just over a year ago, and was at least seen by developers [10]. Incidentally part of that thread provides an interesting insight into how WMF paid staff viewed the attempts of volunteers ("these people") to discuss their requirements. Whether the use case was accepted by developers and integrated into the design and code, I couldn't say: shortly after that I decided I was wasting my time trying to engage with the design process. Deltahedron (talk) 19:58, 30 August 2014 (UTC)

(after edit conflict) @Martijn Hoekstra:: True, I don't like it. Or better said: I don't like the imagination that Flow changes the way how we were discussing in Wikipedia for years. And I cannot imagine Flow when discussions get out of hand like German Wikipedia:Kurier talk page (caution! at this moment about one megabyte of length) with hundreds of contributions by several dozens of contributors in tens of more or less active threads and sub-threads. I understood that Flow at this moment would not be able to handle such discussions at all, but I even can't imagine to scroll through the page if that page was already done Flow-ish. At my screen resolution I counted 201 page downs to reach the end of the page. Can you imagine how many screen pages would it count if that talk page would have been edited in Flow?? (Note that in German Wikipedia it is rather unusual to archive subthreads on its own but not before the whole thread can be archived.) I also cannot imagine special cases like tables and preformatted texts in Flow, which are not rare even in category deletion discussions. (Note that the linked page shows both examples but technically is not a talk page; I used it because of both examples appear on one page. An example where tables have been used on a real AfD page ist this page. This example shows both lengthy comments and tables on a user talk page.) --Matthiasb (talk) 20:00, 30 August 2014 (UTC), 20:28, 30 August 2014 (UTC)

We were assured a year ago that the Flow team "have a pretty good idea of what our existing users need" [11]. So there's nothing to worry about, is there? Deltahedron (talk) 20:17, 30 August 2014 (UTC)

Your statement is meant ironically? --Matthiasb (talk) 20:19, 30 August 2014 (UTC)

Yes. Last year's discussion was an instructive experience for me, but not, I think, a good model for user engagement. Deltahedron (talk) 20:23, 30 August 2014 (UTC)

@Matthiasb: that is a fine example I think of the way where the WMF struggles with communicating with the rest of us. It's fine IMO to say you think you don't see it changing into something we all want. It's fine to say which inherent problems you see with it. But saying that you don't want it to change in to something we all want to use because you don't like what it's now is simply not helpful, and I understand engineerings tendencies to stop listening to such complaints and stop engaging. Reacting like that makes the problem - and the delivered products - worse, because they should listen to our concerns. Phrasing them in a way they can work with to address those concerns, even if there is (justifiable) anger and frustration in it (for example Deltahedrons persistent insistence on acceptable math support and rendering) should be a no-brainer. Martijn Hoekstra (talk) 09:55, 31 August 2014 (UTC)

@Martijn Hoekstra:: Not really. The foundation actually has to deal with two different problems. One side is, that proposed features are not useful as seen by the community (that is what you refer as inherent problems to, bugs and/or misunderstandings/misknowledge how Wikipedia works), but on the other hand it is also a valid point, that people don't like changes in the interface. If there were no bugs and no misunderstandings and no misconceptions and no misknowledge at all they still have to consider if the value added by the change is balancing the costs and the prices to have be paid. And there are costs and prices aside that what paid developpers earn as wages and need as working instruments, such as loss of users who don't want to change (or cannot). For example, surely, throwing out old browser support makes programming more effective and also more error-prone but what if there is one user somewhere over the rainbow providing Wikipedia with a specific special interest content no other Wikipedian can deliver because of that Wikipedian has not the possibility to update? In such a case the price we pay for making programming more error-prone ist more than tremendous. And the mistake in all considerations and arguments the Foundation presented in the last time is that they calculate with users who potentially could edit. That is wrong, because of they don't have them and it isn't for sure they would gain them if the software is changed. But they have to take in mind those users they already have. It is more easy and much more important to keep the stock of stale users than to try to find new users of which we do not know nothing, more than ever not on their capabilities to even provide content. Yes, the raw aptitudes and desires of the communities are points to take in consideration, for sure. --Matthiasb (talk) 09:14, 7 September 2014 (UTC)

You asked what if there is one user somewhere over the rainbow providing Wikipedia with a specific special interest content no other Wikipedian can deliver because of that Wikipedian has not the possibility to update? The answer to that is already known: it is part of the price the WMF is ready to pay for moving the projects in their chosen direction. Deltahedron (talk) 10:50, 7 September 2014 (UTC)

Since you mention my efforts, perhaps I'll describe them briefly, although I'm sure Lila knows all about them. My early, individual, efforts were not very successful, as you might expect, and I met with reactions from WMF staff ranging from accepting some points, through a regetful lack of resources, via patronising, condescension and on to deliberate obstruction, childish sulking, outright hostility, personal attacks and dishonesty. At Jimmy Wales's suggestion a group of mathematics editors put together a set of proposals for what might be done in the short term, and how we might work with WMF to improve communication, plan future work, align volunteer effort and get mathematics support appropriately included in the WMF roadmap. Jimmy was enthusiastic and actually forwarded to Lila and the WMF Board with his support. Unfortunately Lila decided that she was unable to allocate resources to any of our proposals. That is her decision to make and I for one am not going to try and change it, although others may wish to do so. As far as I'm concerned, the question is what to do next. I will continue to remind people of the existence of mathematics, but perhaps more out of habit than as a reliastic strategy for actually getting anything done -- it may occasionally help things at the margin and postpone the final catastrophe. For volunteer developers, of whom I am not one, their next step may well be to put together packages of work that WMF would permit them to do, or possibly even fund -- unfortunately WMF does not (yet) have satisfactory processes that would allow that to happen, and indeed it was one of the proposals Lila rejected. In the absence of support and improvement, or any plans or resources, the current and likely future state of Wikipedia and other WMF projects for people like me who want to write and edit mathematics is declining and likely to become unsustainable. For mathematics writers, I fear that the answer is almost certainly "leave". Without mathematics, Wikipedia's claim to represent the sum of human knowledge would be, I think, quite ludicrously false, but that is a risk that I assume Lila and the Board have assessed and are happy with. Deltahedron (talk) 11:02, 31 August 2014 (UTC)

This is Lila's talk page, and so I think it only fair to highlight the issues that she needs to be interested in, which are not the specific details of any bugs, deficiencies or missing pieces in Flow. I think the issues for her are probably along the lines of

• was the overarching vision for Flow the right one, and is it compatible with the way people work, or want to work? is that vision still valid?
• did the initial Flow requirements capture and design processes work adequately, and what lessons about engagement with the community could be learned from them?
• is Flow on the right track? will it deliver what is wanted, on time, and to budget? does it need more or different resources of any kind?
• what further engagements with the community are required to flesh out the vision of Flow as a workflow engine across the language communities and projects? how should those engagements be structured? can they be achieved?
• should Flow as a project be continued as is, modified, or terminated?

I think that's the sort of thing Lila will need to consider. Deltahedron (talk) 20:33, 30 August 2014 (UTC)

The problems of retention and training, new editors and veteran editors, are a big part what I've long had in mind when I've said that en.wn is key to the wikimedian sisterhood because it tackles head-on, day-to-day, in concentrated form, problems that the rest of the sisterhood would eventually realize it desperately needs to address. Why the problems are so concentrated at en.wn: we have a very short timeframe in which we require an article to go from nothing to something comparable to English Wikipedia's confirmed good article status — and it doesn't get published until and unless it gets there within the timeframe. Any veteran wikimedian contributor could probably write up a tolerably accurate list, off the top of their head, of major logistical difficulties with doing this. The thing is, over the years English Wikinews has learned a great deal about how to address the problems; we implement some of it routinely, which is why we still exist at all, and for other parts of it we've been developing software for several years, which is now on the brink of serious deployment. Key to the design of the software, both in its creation and in its intended use, is that good software design decisions for a wiki project are expected to come from experienced project contributors.

What the software is: machinery that acts, behind the scenes, to let users specify, in wiki markup, interactive wiki pages that amount to interactive wizards for doing... anything the wiki community wants a wizard for. The point is that these wizards are edited directly by the community, using the markup language they already know (so that there's no language-differential barrier to moving smoothly from content editing to wizard editing); as a long-time wikimedian contributor, it had, to be honest, seemed obvious to me that the wiki community ought to be directly creating these wizards since 100% of the knowledge needed to design the wizards resides in the community — and "cutting out the middleman" is one of the key concepts that make wikis work. (There's a fascinating contrast between this strategy, which came naturally to me as a veteran wiki contributor, and the strategy behind VisualEditor.)

How does this help (beyond the obvious, of wizards making things easier to do and the software making wikards easier for the community to grow)?

1. Wizards for newcomers allow the newcomers to produce higher-quality contributions from the start. Newcomers are less often frustrated as their contributions are less likely to warrant simple rejection, and veterans are less burdened in coping with low-quality contributions.
2. Wizards for veterans allow them to vet more material, not only faster and with less effort, but potentially with greater accuracy and quality control, and provide more prompt, helpful, and encouraging feedback. Interactions between newcomers and veterans are more useful and more satisfying for both sides.

--Pi zero (talk) 13:23, 31 August 2014 (UTC)

Working Together

Thank you everyone for the insights and arguments you’ve shared with me and each other over the past week -- I am continually using them to inform my thinking. Your passion is undeniable, and I want you to know that my passion for this movement is too. I’ve read what you’ve sent my way these past few days. In return I want to share with you my thoughts on where I think we are, and where we need to be.

The Board brought me into this project in order to lead a transformation at the WMF. I accepted the challenge because I believe you’ve created an incredible project that has changed the way the world experiences knowledge. However, I also believe both your contributions and our movement’s mission are at risk of being lost as a result of changing technologies, much as Encyclopedia Britannica was in the 90s.

This means we must make some changes. And we must make them together. I spoke about this at a high level at Wikimania, but in action this means we must:

• Improve our process for software design, user and community feedback, and operations;
• Learn how to work together through disagreements and make decisions that have global impact with objectivity;
• Improve our product consistency globally and think of ourselves as the world’s source of free knowledge;
• Increase the responsiveness and speed at which we develop and deliver product; and the rate of innovating; and
• Do this with mutual understanding and respect.

This weekend I posted a set of questions here, on my talk page. They represent the issues I am grappling with, and the things I wish to understand in order to assess the specifics of changes we need to make. I appreciate the responses you’ve shared so far, and look forward to receiving more. I would like to quote Martijn Hoekstra, who stated on this page that it is “the burden of the person with the initiative to initiate the dialog. In case of WMF software projects, that's the WMF.” We are going to do that.

I want you to know that I hear you, as different as you all are. Everyone has legitimate concerns about the current situation: not just the recent issue involving the WMF and the de.wp community, but the ways in which we work together overall. I actively engaged with you to solve this. We need to transform our conversations into an ongoing and improving process with common goals.

While we are all part of a larger community, we have different tasks. Of our movement entities, the Wikimedia Foundation is in the unique position to lead the continued development of the technology making these projects possible. This means we understand ourselves as a technology organization. This also means we are a global organization responsible for technology powering 800+ projects.

Yet many of you need to be able to influence and affect the direction our projects take -- this means being heard and taken into account even on things you don’t directly work on. We need to find a way for all of the contributors from all of those 800+ projects to participate. You need opportunities to review the development of product earlier and during critical junctures. Our approaches need to evolve and mature. We need to find a better way to collaborate.

The WMF is a part of our community -- the part that is responsible for developing and maintaining software and servers. We all want to want to participate in deciding which features get implemented and how, but the current approach of voting on them post-rollout is disruptive and inefficient. We need to change our processes so that they are iterative, incremental, and inclusive of feedback throughout. We understand that our recent decision to restrict edits to site-wide JavaScript on German Wikipedia was a surprising move that upset a significant number of people - we’re sorry for that. At the same time, it gave visibility to an important issue: we need a better mechanism for managing changes that impact all users -- the way the MediaWiki: namespace works right now is not sustainable. Let's use this opportunity to improve.

At the WMF, we’re preparing to unprotect the disputed page on German Wikipedia, but we need to do so within a framework that allows us to come to reasonable resolutions -- giving everyone a voice and a say in the process, but also understanding WMF’s leadership role in technology. We will post thoughts on how this can be accomplished (and in what timeframe), in partnership, in coming days, starting with a brainstorming process.

As part of this process, we have heard feedback that WMF employees should have distinct accounts for their WMF-related actions as opposed to their personal actions on the projects. We accept that feedback and will put in place such a system within the next month.

In summary:

• You have my commitment that we will work towards a constructive resolution of this current and any future disputes together and in good faith.
• We intend to undertake a review of our present processes immediately and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices.
• We will establish improved centralized communications for all wiki software changes.
• All future updates and current developments will be based on this new process.
• For the purpose of additional clarity regarding roles and responsibilities, we will put in place a clear distinction between work and personal accounts for all WMF employees by September 15.

I hope we can agree to exercise restraint in this transformative time so we can work together in good faith and in concert. As Magnus Manske said in his recent blog, “the house that is Wikipedia cannot stand without a foundation, and a foundation without a house on top is but a dirty pond.”

Thank you, -- LilaTretikov (talk) 16:22, 19 August 2014 (UTC)

Working Together Comments

Dear Lila, thank you very much, i really appreciate this notice. However, i cannot agree with your proposition "the current approach of voting on them post-rollout is disruptive and inefficient". This should rather read: The current approach of WMF of ignoring important (among them legal) issues, clearly and repeatedly voiced months ahead, and nevertheless rolling out broken und unfixed software, is disruptive and inefficient. Also, i do not agree that establishing "product consistency globally" would be in every case fortunate. Especially, communities should decide on the status of critical new software (beta/opt-out/opt-in) and also, opting-out should always be possible when proposed new software does not include all capabilities of working software (please - as has already been spelled out above - keep this in mind for future software projects). Again, please check out Jimbo's principles: "Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by the Wikimedia Foundation, in full consultation with the community consensus." This implies that you should never, ever, find yourself in a position to enforce critical software changes, and especially not broken software like MV, against evident community consensus. Can we agree on this principle? (Else, the conditions for "working together" would have to be rewritten from the start, and it would be very open which part of current communities would accept the outcome. I suspect: not very many!) Ca$e (talk) 17:07, 19 August 2014 (UTC)

We are looking in the particular issue of potential legal implication. If it is a legal issue -- it will be treated as a blocker. If not, we will attempt to fix. From what I understand the issues is affecting about 1% of the images, but I have asked to confirm. -- LilaTretikov (talk) 21:41, 19 August 2014 (UTC)

CC-BY_SA-3.0 requires 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. [4.c.iv]

Legal issues are two-fold:

1. By breaking this term we are breaking copyright law on around (by your 1% estimate) 220,000 images. (Of course some are PD.)

2. By selectively breaking copyright the Foundation is not acting neutrally, and hence could loose DMCS safe harbour protections under section 230.

Rich Farmbrough 15:23 20 August 2014 (GMT).

Hi Rich,

No, you are not correct that the failure to support the {{Credit line}} template in its current form represents "attribution breakage" for 1% of content. Please take a look at how this template is actually used. Here is an example that includes more than an author name. Both the credit line template and the media viewer attribution include the link to http://www.poczta-polska.pl/mw (which is a 404, but that's a different story). Why? Because that link is cited as a source, and Media Viewer always includes the source in the attribution info.

There are very few cases where the credit line template includes information that's not included in any of the other fields. In addition, it repeats information like author name and license. The license is sometimes not hyperlinked, which is actually inconsistent with licensing requirements and best practices. The template as a whole violates the software design principle of Don't repeat yourself -- repetition introduces error. It also does not emit its machine-readable data in parts (only for the content of the template as a whole), so it cannot be rendered consistently with other forms of attribution.

Here's an example invocation, which is not atypical. Some licenses are linked, others aren't, and the GFDL link goes to the Wikipedia article!

In our view, the template should probably be deprecated in favor of a better solution, e.g. an "other credit" field in the information template that is added alongside author name and source in the rare cases where that is desirable. Supporting a poorly conceived template would perpetuate its use, which ultimately is not in the intrerest of the community.

I suggest rather than focusing on layman's interpretations of licensing terms and safe harbour provisions, we focus on what the desired behavior is/should be, and how to deal with the (as everyone acknowledges) messy templates we need to parse, because this enables us to help all re-users of our content to do not only what's legally defensible, but what's right.--Eloquence (talk) 05:10, 26 August 2014 (UTC)

Erik, surely these issues about the legal requirements for MV, and the legal advice you took, and how in the light of tha advice MV was going to get the information it needed to be licence compliant, and where from, and how to capture and parse the data it needed from the various media-related templates, were all resolved during the design phase? Rather than taking up your valuable time explaining them, why not just post, or point to, the design documents in which those issues were addressed?

BTW, while I myself am certainly a layman in the field of intellectual property law, which is why I don't comment on it, it's probable that the community contains people who are much more expert than me, and possibly even than you, on that or indeed any other given subject. Why not find and make use of that expertise rather than dismissing the entire discussion? Again, if you know on the basis of the legal input to the design process that the discussion is indeed misconceived, then again all you have to do is exhibit it. And if these issues are being discussed for the first time ever, then something is wrong. Deltahedron (talk) 06:44, 26 August 2014 (UTC)

A few quick points:

• We of course did ongoing legal discussion of the design for mediaviewer before it went into production. The mediaviewer team has been quite good about reaching out to the Foundation's legal team.
• CC requires that attribution be "reasonable to the medium or means You are utilizing" (3.0 BY-SA 4(c); similar language in 1.0, 2.0, and 4.0). This flexibility is granted so that users of the material can innovate while still respecting the spirit of the license. (This is how we can use Flickr-imported pictures in the encyclopedias without in-line license statements, for example.)
• Given the vast diversity of license templates on the projects, and the varying quality of the metadata available, we made a good-faith effort to combine design with the metadata we had (including links to the license), plus a fallback of links to the original image source. I was comfortable approving that design as having attribution that was compliant with CC in a way that was "reasonable to the medium". (In practice, I actually think the more prominent and clear licensing and attribution information is often more compliant with the spirit of the license than the average File: page.)
• It will, of course, be more reasonable if there is post-release improvement of data and code- any good measurement of reasonableness will include an assessment of the intent and activity of everyone involved. In this case, that means it is important for all of us to keep working to improve both the code and the metadata. Thanks to everyone who has helped with this so far - I'm very glad to see so many people pitching in to help improve the situation. (By the way, the people who are helping improve the metadata are not just helping mediaviewer - as I mentioned in my talk at Wikimania, I am expecting many other automated tools, like Commons Machinery, to be popping up in upcoming years, and the more we can standardize and clean up our metadata for them, the better.)
• We did not review every single licensing-related template; there are literally thousands, often used in very complex ways. (The credit line template is only the 247th most used template on Commons, and roughly 26th for purely-license-related templates.) The right approach, when faced with an engineering problem of this scale, and flexible legal constraints like those in CC, is not to demand legal perfection. Instead, we have to be fair and be bold, and work to find and address problems as they come up. And that is what is going on.

That's the analysis in a nutshell. —Luis Villa (WMF) (talk) 09:05, 26 August 2014 (UTC)

IANL, so my question may seem a bit pragmatic: Why not simply disable the MV for files, where the licence can not be read in a proper way, and show only media with up to date licence templates in the MV? Sounds quite simple to me: Is there a machine readable licence? Use MV. Is there no such thing? Go to ordinary media page.

Same could be applied for long and elaborated descriptions, like legends for maps etc. If it could be shown in an appropriate way, use MV, if not, don't use it.

Maps without the legend are usually useless, pics without the proper licence are perhaps against some laws.

--109.235.137.238 12:06, 26 August 2014 (UTC)

@109.235.137.238: Yes, something like that would be manageable, as would letting MV explicitly state its imperfection in such cases be (as e.g. i told Erik previously on this page). @LuisV: Thanks. It is a noteworthy idea that serving incorrect license information could be simply covered by being "bold". In what capacity do you conclude that this solves the legal problems especially for mislead re-users? I wonder, will they, when indicted, also be able to say they were just "bold" and MV told them that is was alright? A subset of the problems are, btw, the same as described in another context here. Among others, note cases where MV does not advice re-users to state the license but only the creator. Ca$e (talk) 14:22, 26 August 2014 (UTC)

Of course, I didn't say that being bold solves problems. I said that being bold is an acceptable approach when you've analyzed the license, made strong efforts to address as many problems as you can, and are committed (as we are) to solving new problems that are identified after you've taken action.

In the specific case of attribution problems, I agree that this is something we need to be careful about. But this is not a new problem. In many current Commons pages it is extremely difficult for mere mortals to understand how to do proper attribution- I've struggled with it myself in making slides, for example, and answer questions about how to do attribution all the time. For example, some of the DRY problems that Erik has pointed out are also confusing to regular users visiting File: pages. Improving our metadata will hopefully have the side-effect of making the situation better for those who visit File: pages as well. —Luis Villa (WMF) (talk) 16:22, 26 August 2014 (UTC)

The suggestion to disable MV for those pages that have a problem parsing license or attribution information is, I think, actually a great idea. I love it because it sets a clear course and managble workitems. If we can do that, and make a list of images of which the metadata can't be properly parsed we hit two birds with one stone. First, it takes all doubts and concerns about copyright issues off the table (regardless of their juridical merit, or if they are primarily moral concerns or juridical concerns - personally, I tend to be more worried about the former). Second, it gives the community a list of items to work on the meta data on, which is not only useful for MV but also for other projects. I'm still not without concerns about MV, but if we can take one of the concerns that resonate with many people of the table, that's a great win. We could ask the de.wiki community what they think. How do we gauge if this is acceptable for the WMF? (It just occurred to me that this question and all answers I can reasonably come up with all end in irony). Martijn Hoekstra (talk) 17:33, 26 August 2014 (UTC)

Not a crazy question- thanks for posing it respectfully. As I said, as a lawyer, I don't think that the license is actually being violated in the vast majority of cases. As an engineer, we know that on a data set this varied and complex, actually deploying the code is one of the best ways to discover bugs and to encourage people to fix them. (It isn't ideal, as I said above, but individually assessing thousands of templates is also not very practical.) So that's the basic rationale.

If, at some point, there remains a very large number of intractable problems, then I expect that disabling the tool automatically for those problematic files will be one of the options on the table. But this will also prevent functionality for other automated tools, so we should really strive to improve the metadata of those files to the greatest extent possible, not just for mediaviewer, but for other purposes in the future (both internally and externally).—Luis Villa (WMF) (talk) 16:22, 26 August 2014 (UTC)

But wouldn't that have been the duty of those, who so desperately wanted this bling-thing, that they even went as far as putsched against the community by deploying illegitimate weapons of might (superprotect)? The concept of "Shove the rubbish on the populace, and see what's all going downhill" that you propose is imho not really a good one, definitely not, if the populace in some bigger substructures (enWP, deWP, Commons) is clear against it.

I completely fail to see any urgency here, I even fail to see any try to look after this problem beforehand (Erik made some far too late attempt to cover his tracks of negligence here, nearly two weeks past his Putsch), not trying to lock the stable after the horse has bolted. It was known since at least November, is there any track record what has been done by the fan-boys of this bling-thing to deal with the problem in the reality, not some imagined fairyland of machine readable templates?

If the mentioned restrictions to only suitable media files would have been used, perhaps even with a "ping" to the devs every time the MV didn't get used because of unsuited reality for the desired feature, the scope of the problem, whether it's really just some minor fringe problem, as you seem to proclaim, or whether it's more widespread, as deWP thinks, would be better recognizable as well.

You just sweep the problems under the carpet, to get nothing in the way of the newest pet project of the WMF, even use brutal force against the communities that dare to disagree, and seem to think everything's just fine.

No, it definitely is not! --Sänger S.G (talk) 17:17, 26 August 2014 (UTC)

Specifically with regards to CC BY-SA 4.c.iv, which Rich raised above:

"CC-BY_SA-3.0 requires 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. [4.c.iv]"

If I understand correctly, the complaint here is that the group of images that can be shown in the gallery/slideshow mode is a Collection, and any inconsistency in attribution of this Collection violates this clause. Assuming that's the complaint (and please correct me if I'm wrong!) there are several problems with the complaint.

• 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.
• 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.
• Tangentially, most (though not all) slideshows, in our context, will not be Collections, since there will not be enough "intellectual creation". (In the US, groups of four or fewer images - which would be the slideshows for many, if not most, articles - never qualify as a creative work.) But we wouldn't want to focus too much on that, since certainly some particularly large galleries might qualify.

Again, I'm not saying this is perfect - I do think it would be ideal to make the attributions as full and consistent as possible. But while all of us (both those helping clean up metadata and those writing code) are working towards that goal, it is not a violation of the Creative Commons licenses to have an imperfect attribution system, as long as the key elements are present in a reasonable way. And they are here. —Luis Villa (WMF) (talk)

There's surprisingly little about community engagement in your analysis. At what point did you engage with the community, especially the people who wrote and use those templates, to discover what the issues were between the proposed MV interfaces and the then-existing templates and licensing-related data? How much use did you make of their experience of the complexity of licensing data that occurs in practce? Surely by now there should have been some convergence between the MV requirements for input and the data output by templates? Deltahedron (talk) 17:02, 26 August 2014 (UTC)

As there again are a few postings beside the crucial points below (not of course by you, Rich!), i want to make sure you, Lila, or the legal consultants you are asking, get at least aspects of the basic problem: Check out examples like https://de.wikipedia.org/wiki/Datei:2014_-_Olympic_Stadium_(Athens).JPG#mediaviewer/Datei:2014_-_Olympic_Stadium_(Athens).JPG . Neither copyright holder nor correct license information are given via MV and especially not with the function to provide a re-usable inclusion code. It has been pointed at many times, but i should probably state it even once more: CC-by-sa 3.0 requires to give appropriate credit, provide licensing information, e.g. by a link to the license, and indicate if changes were made. Omitting the link to the correct license is also a breach of licensing. Ca$e (talk) 15:10, 21 August 2014 (UTC) PS: Also, check https://bugzilla.wikimedia.org/show_bug.cgi?id=69496 . Ca$e (talk) 10:04, 22 August 2014 (UTC)

Dear ca$e, the way the viewer works (the only way it can work) is by extracting machine-readable information via an API. There's a standard for such machine-readable info that the community has developed, here. It's evaluated by the CommonsMetadata API. We made efforts to reach out to the communities as early as November to collaborate on the adaptation of templates [12] [13]. However, I'll acknowledge that these efforts didn't go far enough. The viewer links through to the File: page as a fallback with a clear "View license" label, and for cases where there isn't even a standard template on the file page, it's hard to do better. Really in those cases the only way to fix this is to fix the descriptions -- this doesn't just affect tools like the viewer, but practically any automated re-use. So we really have a shared interest in addressing any remaining cases irrespective of what you think about the viewer. We just posted a fix for the German {{Information}} template here and are happy to apply it ourselves if desired. This should do the trick, but we'll help if there are still are problems after it's applied.--Eloquence (talk) 16:55, 21 August 2014 (UTC)

My own opinions do not matter. I would just switch it off. I am concerned for our users. What you should do in case you cannot give necessary information is say so. This especially holds for the function where re-using users should get a working URL with author + linked license info. When MV cannot give it, it should not misleadingly suggest so. This, however, is only my personal opinion. On a completely different point stands the deWP community consensus and the way you reacted to it. Ca$e (talk) 16:59, 21 August 2014 (UTC)

Regarding your mail from November 2013: In relation to your colleague's misinformation that "announcements are posted through a number of channels" (see below), posting it to only an obscure mailing list is rather ridiculous. Further, am right in taking this as clear proof that 1) you knew especially of this problem since November, that 2) you knew that you communicated it unsuccesfully, that 3) you knew that communities had not yet themselves provided means so that MV could serve correct license information in those cases, that 4) you knew that we knew of this and warned you especially explicitly in our Meinungsbild, but that 5) you nevertheless chose to ignore this Meinungsbild and enforce a software of which you knew that it would cause legal problems. 6) Did you sufficiently inform your superiors of all that mess before they chose to back you in this matter? A simple yes or no would suffice. Thanks, Ca$e (talk) 10:12, 22 August 2014 (UTC)

You're confusing several things. First, the Meinungsbild (poll) decision had no legal implications, it was just about a software configuration change. So the WMFs rejection of the poll also did not have legal implications. Second, Eriks superprotect action was embarassing, but did not (yet) enfoce anything wich concerns the Meinungsbild: Erik superprotected de:Mediawiki:Common.js, but this file does't matter regarding the Meinungsbild, because it cannot by implemented via Common.js (but e.g. via de:MediaWiki:Gadget-MediaViewer.js). Please don't build legends here, we should stick to the facts. --PM3 (talk) 12:35, 22 August 2014 (UTC)

You're confusing several things. Stick to what i wrote and don't build legends here regarding what i could have written. Ca$e (talk) 12:43, 22 August 2014 (UTC)

Also, and this does only in part concern legal problems, below you find my quick translation of the relevant parts of the deWP "Meinungsbild" that WMF chose to ignore and aggressively overrule.

The "old" page for the file description, which included way more information than can be shown via MediaViewer, can now be reached only via detours. This includes most toolserver-expansions and commons-templates. A few examples of a list that could easily be prolonged as there are quite a low of useful templates and tools on commos:

1. While the short version of the license identification is shown, e.g. CC-by-Sa, elucidating templates (e.g. {{Cc-by-sa-1.0}}) of the file description page are included only if mentioned in the "license" parameter of the template {{Information}}. According to the Template Information, however, bigger license-information, that make up their own section, should explicitly not be included there, the field should then rather be kept empty! The omission of templates for summarizing licenses and warning in MediaViewer is promoting "wrong" re-use. For example, {{PD-Pre1978}} warns that a picture should probably not be used in germany following the Rule of the shorter term. One example, where the warning is missing with MediaViewer, thus suggesting that the file would without restrictions be usable everywhere: Stones ad 1965.JPG; especially misleading in this context is the text below "Bedingungen ansehen" (view conditions) and in the bar below the image the term „Gemeinfrei“ (public domain). As MediaViewer invites users to re-use the file, without having checked the file description page first (via the button to re-use, that provides download and inclusion of the file and sharing of the URL independently of the file description), this handles templates that warn of certain conditions for re-use as if they were unnecessary accessories. The provision of an option to download and include without those warnings is in some cases wantonly negligent.
2. 5 years ago, the Credit line-template was introduced on Commons in order to facilitate the correct attribution for re-use cases. It is currently used for more than 194.000 pictures. However, it is completely ignored by MediaViewer (example: Arena AufSchalke Innen bei Konzert.jpg; the Credit-line-content is normally given in the field „Namensnennung“ (name of contributor)). WMF's developers have been warned of this problem May 17th. Since then, nothing has been changed. As the requirements of the author are legally binding, by omitting the credit-line-content, WMF puts re-users into higher risks to provide illegitimate attributions and breaching of licensing and their effects - and this knowingly, thus wantonly negligently.
3. Detailed file descriptions, such as are necessary to understand the caption for maps, are not shown; example: EU member states (using the template {{Legend}}); also, the citation of the historical original text of the map, not being included in the template {{de}}, is not included.
4. In cases where the descriptions are all in template parameters that are ignored by MediaViewer, the misleading information "No description available" is given. Example: Mona Lisa (Commons) vs Mona Lisa (MV). In this case, the informations regarding the original title of the image, the painter, painting technique, current place, inventary number and place of production are actually descriptions, however.
5. Information that appears on mouse-over, such as can be provided on Commons as annotations to images, are practically lost (see c:Help:Gadget-ImageAnnotator/de). Example: historical image of Dresden, which should show descriptions for individual buildings on mouse-over.
6. For images with geo-data, the file-description-page gives links to 4 systems of maps. 3 of them include markings with further Commons-images, enabling the user to discover the surroundings, see building of Berlin Reichstag.
7. Only via detours the ZoomViewer can be reached, which provides targetted, gradual zooming into bigger images like maps. MediaViewer, however, being intended for improving image viewing, lacks such capabillities. Example: below the image, the link to ZoomViewer on Commons and in ZoomViewer.

I hope this concludes a view pointless discussions that have developed especially below. Keep in mind that those are only a quick selection of many more problems caused by MediaViewer. Ca$e (talk) 15:39, 21 August 2014 (UTC)

+1. I appreciate the communication by Lila, but the software features like Visual Editor and Media Viewer were far from being ready to be rolled out since essential problems were still existing. And the communities get ignored on that (still they are). Also i agree with Ca$e that this "consistency" is not a valuabel goal for cultural projects like encyclopedias. This might be nice for Facebook et al, but every Wikipedia should be sensiblel to it readership regarding its cultural background (also on questions of design). The way to go is to build a module based technical infrastructure from which the communities can decide how to serve their respective readership best. And that is not a matter of money as often voiced in the discussions. The WMF has likely more money then it should have (much growth which was not thought through properly happend just because money was there), and there will be more coming in if it doesn't keep on discuraging the people who make such great products that sell so well to the donors. --Julius1990 (talk) 17:25, 19 August 2014 (UTC)

In terms of "ready" we need to define an objective definition of readiness. We can do this together. Current RfCs are not objective, but, by the same token neither is the WMF. So let's find a better solution. Consistency is important from both user experience and cost standpoint. We are a global site with local communities. Technology needs to provide a consistent and predictable foundation for all of them. -- LilaTretikov (talk) 21:41, 19 August 2014 (UTC)

Lila, this is no science. As long as the Media Viewer is not able to display every media file with the right attribution and liscence there can't be a full roll out. Same on the Visual Editor: As long as it was not able to perform at least the mayority of tasks like editing tables and so on but is just useful for typography edits and with saving even caused many deletions of texts as it was during the roll out last year, it was not ready. And I seriously doubt it is now. And instead of taking those concerns seriously I heard developers complain that our editor is simply too complex. Now, our editor works for all the tasks needed. As long as they can't develop something that does the same, no readyness for roll out is given. Beta means fixing up the details to me, not that software features with problems at the core are put to all users. And with doing this, forcing features with core problems on the editors you (meaning the Foundation) destroyed the good faith of many editors in the last years. And with the good faith it is like with the trust that especially Erik Möller destroyed in the current case. The destroying takes short time, building it up again takes much, much longer. That's why you should take us more seriously than you did before and do right now. Even if, as I said your communication right now is good (I haven't seen Sue ever engaging this deep with community memebers online, no offense to her, but a cudo for you) and you still have more trust than the "Community Advocate" or Erik Möller because you didn't destroy it so far. I just can recommand you to act wisely and not to destroy it. Because what is destroyed takes long to be rebuildt. And that'S also a reason for many offensive speech on that. There is so much bitterness caused by the WMF in the last two, three years ... and by Superprotect you gave the people teh feeling of authoritarism and insults are also a form of resistance when you feel overpowered by a much more mighty institution who doesn't seem to want to act anymore according to its Mission Statement, Values and Jimbos Principles. According to Jimbos Principles you should comply to the bug report that asks for your acceptance of teh German Wikipedia vote. A vote that is not against the MV itself, but against teh full roll out while still core problems around teh attribution and license exist. --Julius1990 (talk) 21:54, 19 August 2014 (UTC)

Let's decouple some of the issues: we have painful history, let's look forward and try to improve how different parts of the community complement each other. I believe that is important. And it does take time and effort to understand you guys :) Now, on the software side... Actually saying that every corner case needs to be satisfied is a huge product design fallacy. You might be familiar with the 80/20 rule, where you get 99% of the benefit from satisfying 80% of the requirements. This also means that hitting every corner case is completely inefficient from cost standpoint. This is where the tough decisions need to be made. Between us here, no article and no piece of software is ever perfect, but it has to be good enough and we need to decide what that means. I know this is all product mumbo-jumbo, but this does not come from me. So unless we truly have a legal issue, not every corner case should be solved. On the other hand there are other creative ways to solve these corner issues. Since some of them come from template typing we may do better writing a script to convert that specific template over to something more typical. Especially as we move closed to a normalized way to view data with Wikidata project. I am not going to problem solve here. Just outlining the options. And again -- thank you for the feedback (and, frankly, for encouragement) as this can get really tough to stomach! -- LilaTretikov (talk) 22:04, 19 August 2014 (UTC)

But Lila, that the Media Viewer doesn't violate our licences and attribution is not a corner case. It is the most central point according to our free licenced media files. It is at the very core, not some halflid corner ... And the same goes for the Visual Editor. A VE that isn't able to work on most of teh tasks needed to write our articles, but basically is just good for correcting typography has not some pretty unnecessary corner cases that would be nice to be fixed. It has problems at the very heart. And both were because of this not ready for such a roll out as it took place. And the Wikidata has also a core problem: Many data sets are without valid source, because bots simply putted them there before any clear policy was established. A Wikipedia version like the German with its focus on quality won't be able to accept Wikidata as a working tool until this is solved.

The problem basically is that apparently noone at the WMF seems to have any idea what is core case or corner case when it comes about software for the different projects. Maybe everyone of you should be encouraged to use half a workday per week to work on one of the projects, writing articles, doing clean-up work, whatever ... so you can understand the projects from within. Or you need to listen when one or in this case three mayor projects (Commons, de:wiki, en:wiki) tell you what are the core problems to them and what needs to eb fixed before they can accept on their projects a full roll out. Especially since people told on the mailinglist already in spring that this problems would occur.

The very core are also the actions that happend right now and how you deal with them. You do as if this is a pointless looking in the past. But if you don't resolve it, such things will remain and poison all your efforts. I ask you: Do en:User:Jimbo Wales/Statement of principles still exist? Then why did the WMF especially Erik Möller violate principle 4? Do the Mission Statement and the Values of the Foundation still exist and have meaning? Then why is the Board backing up such actions that clearly violate such three chartas of principles that to em were the fundament of the WMF-communities relation? This needs to be fixed before there can be a moving on from my side. Yes, i could say "let's move on, everything fine", but this would be a lie and this issue would remain in me, decouraging me from further work in the Wikipedia. --Julius1990 (talk) 22:19, 19 August 2014 (UTC)

Internet lawyer, is not a good use of any anons time. In the few "corner case" files, attribution is given in the link, that satisfies attribution. This has to be so, because on the face of wiki articles, where we display the image in content, we do not identify the CR owner there, either. At any rate, you're not the WMF's lawyer. Alanscottwalker (talk) 13:07, 20 August 2014 (UTC)

Do I claim that? No. But that is the critic of many in de:wiki and the Foundation is not able to convince us otherwise. And to us it is the core case of the feature. You can make it easy and label it different to a corner case. But that won't convince for obvious reasons. You have to take the issues raised by the communities as core case seriously or you can just openly confess that you don't care and go for leading the projects in an autocratic way. Then just say it and I won't bother any more with my comments here and my articles on Wikipedia. Heard there are many other nice hobbies around, but then the Foundation will mourn again the loss of more editors and all the classical "we need more editors" stuff starts again ... --Julius1990 (talk) 13:16, 20 August 2014 (UTC)

Taking it seriously means analyzing the compliant. You have made a legal complaint, but without competence or responsibility to do so, and moreover are wrong -- that's what taking it seriously looks like. Alanscottwalker (talk) 13:50, 20 August 2014 (UTC)

Yes, yes, surely the German Wikipedians with interest in this aspect and expertise have to be fully wrong. Just sad that users with a certain profession on it proofed the complaints to be serious. But you can do the Pippi Langstrumpf version of handeling things. But it's not the way you seriously handle the problems that occured and it certainly is not convincing the German Wikipedia community. --Julius1990 (talk) 13:55, 20 August 2014 (UTC)

The expertise you claim is inaccessible to everyone but you, that's what is meant by 'on the internet no one knows who you are'. Your claimed inability, indeed refusal, to consider, with competence or responsibility, demonstrates you are being unserious. Alanscottwalker (talk) 14:09, 20 August 2014 (UTC)

Sure ... the points were made on the German Meinungsbild and convinced the voters. The Foundation didn't proof otherwise and you do neither but claiming. The same you say applies to your own comments. I tell Lila what for the German community is the core problem and that it believes that this is not solved. If it would be, you easily can show and concvince with arguments, not with your claims. I don't claim to be wrong or right, i just claim to say what for the German voters was one of the core problems. And as i said before: denying this and labelling it to a "not core" problem won't change anything on this tied up situation. --Julius1990 (talk) 14:18, 20 August 2014 (UTC)

No. No one of any responsibility or seriousness is going to put legality to a vote. Alanscottwalker (talk) 14:46, 20 August 2014 (UTC)

You try really hard to miss any point i make. Noone voted if there is legality or not. But the argumentation refered often to legal concerns that the WMF neither could solve with arguments nor did it with actions on its product to make those worries loose their substance. --Julius1990 (talk) 16:22, 20 August 2014 (UTC)

You just said it again, they voted on "legal concerns" -- and that makes no sense. Alanscottwalker (talk) 17:22, 20 August 2014 (UTC)

I imagine that Lila's statement probably is a huge step forward for the WMF, regarding what had happend before during the past week. But what strikes me is that it seems that the superprotect right still will not be abolished. If I got this correctly, I don't think this will bring us much "forward" after all.--Aschmidt (talk) 18:20, 19 August 2014 (UTC)

haha yeah. But sorry Aschmidt; "we’re preparing to unprotect the disputed page on German Wikipedia, but we need to do so within a framework that allows us to come to reasonable resolutions" - means nothing else then; if the german wikipedia does as WMF wants, then WMF will unprotect the page. If not, then not. That is not a step forward. its the same situation since the superprotection was put in place. Just nicer wording :) ...Sicherlich ^Post 18:38, 19 August 2014 (UTC)

So I got it right again. Thanks for confirming, Sicherlich. (I didn't want to be that cynical.)--Aschmidt (talk) 18:52, 19 August 2014 (UTC)

All we are doing is asking everyone to hold the current state until we jointly find a better way to make decisions on product. This includes lifting superprotect. -- LilaTretikov (talk) 21:41, 19 August 2014 (UTC)

You ask us to accept the dagger in our chest until the argument has been sorted that has led to the fight. Sorry, but the most pressing issue is not software deployment. It is the superprotect mode and the mindset it stands for.---<(kmk)>- (talk) 22:31, 19 August 2014 (UTC)

+1. The "current state" is strictly not acceptable and also goes against the principles that govern the relationship between WMF and communities. There is no ground for discussion or cooperation unless this issue is resolved. You notably did not answer my question from above: Please check out Jimbo's principles: "Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by the Wikimedia Foundation, in full consultation with the community consensus." This implies that you should never, ever, find yourself in a position to enforce critical software changes, and especially not broken software like MV, against evident community consensus. Can we agree on this principle? (Else, the conditions for "working together" would have to be rewritten from the start, and it would be very open which part of current communities would accept the outcome. I suspect: not very many!) Ca$e (talk) 22:38, 19 August 2014 (UTC)

But "the current state" is the one imposed by the WMF against German Wikipedia's will. You are, indeed, saying "we won't remove the superprotection until German Wikipedia has agreed on a version of Media Viewer that it will accept as default", which is basically "we won't remove the superprotection until German Wikipedia agrees to lose the dispute." Why not remove the superprotect, set Media Viewer back to opt-in, and turn it to opt-out only after German Wikipedia agrees you've done a good enough job with it for it to be default software? Why is a feature that we did without for over a decade worth forcing on one of the communities? Why is it necessary for you to hold the software in a state where you have effectively won the dispute instead of yielding gracefully?Kww (talk) 23:01, 19 August 2014 (UTC)

For what it's worth, I wouldn't view this as being about winning or losing, prevailing or yielding, but rather about reestablishing trust in a partnership and working towards a win-win. Unfortunately I currently don't see this happening for the reasons you and Ca$e state. I don't understand what the foundation's problem is. Lila: What stops you from switching MV to opt-in for the time being as requested in the German Meinungsbild and enwiki's RfC and remove the superprotect right until we (the communities and the foundation) have established proper guidelines on how, where, when and by whom it shall be set and unset? Then we have all the time in the world to discuss visions, goals, products and processes to implement them. Cheers --Millbart (talk) 23:29, 19 August 2014 (UTC)

We don't have that much time as those guys have to discuss and we don't have the money to buy huge Conferences with glamorous key notes of outstanding testimonials. Please just stop disruptive sanctions for now. The readers will be thankful, promised :-D --Sargoth (talk) 18:39, 19 August 2014 (UTC)

My two cents on the key points.

• Improve (...) user and community feedback (...). -- There already was feedback galore. Rather than feedback, more feed forward is needed. Communicate to the community early and often. Sell your plans to us before the first line of code is written, persuade us, make us part of the process from day one.
• Learn how to (...) make decisions that have global impact with objectivity (...) Improve our product consistency globally (...). -- That is, ignore the explicit wish of local communities in favour of global uniformity? Since when is global uniformity a necessity? German Wikipedia has sighted revisions in effect and is happy with it since a digital eternity. This is a rather far reaching difference in the UI. Still, the wikipedia as a whole does not seem to suffer tremendously.
• Increase the responsiveness and speed at which we develop and (...) -- I couldn't care less for speed of software development. Do it fast, or do it slow, whatever you feel appropriate. What I do feel, though, is that bugs need to be less long standing. See for example the problems with SVG. The contents are sufficiently accessible with current software. Eye candy is nice to have but in the end it is just that. The fundamental asset of the wikipedia is its content, not its presentation.
• Do this with mutual understanding and respect. -- I hope, these buzz words translate to "Embrace the community. Do not even think to fight against it"

---<(kmk)>- (talk) 22:17, 19 August 2014 (UTC)

"we jointly find a better way to make decisions on product." - we means WMF? ... and the better way means a better technical way to prevent the community to do changes? ... or it really about the decision making? By the community? De-WP had a straw poll on the MV so you want something better? And de-WP has a poll against the superprotect - you ignore it as well. ... So it leaves me to the conclusion that the opinion of the community is not what you accept as a good way. ... Interesting. ....Sicherlich ^Post 07:23, 20 August 2014 (UTC)

(BK) Rather embarrasing to read Lila's responses overnight. I second the critical remarks from my fellow German editors. I also would like to add that we are here to write an encyclopædia, not for giving feedback to software development.--Aschmidt (talk) 07:27, 20 August 2014 (UTC) To make it absolutely clear: This is not about lifting superprotect, but about doing superprotect away, abolishing superprotect.--Aschmidt (talk) 08:38, 20 August 2014 (UTC)

If we are here to write encyclopeida and not give feedback about software -- why there is so much commotion about it? -- LilaTretikov (talk) 16:41, 21 August 2014 (UTC)

I'll answer that, although I suspect it may have been rhetorical. Firstly, the volunteer encyclopaedia writers use the software; secondly, the set of volunteer encyclopaedia writers includes most if not all of the set of volunteer software developers; thirdly, most of the software was written by those volunteer developers for and in cooperation with the volunteer writers; fourthly the volunteer writers have largely not been consulted by or involved with the work of the paid developers; fifthly the volunteer writers experience is that the work of the paid developers is not always fit for purpose; sixthly, the volunteer writers have been sent the unwelcome message that in future they are to be made subordinate to the paid developers. I hope that helps. Deltahedron (talk) 16:53, 21 August 2014 (UTC)

because you (as always: not you in person, but WMF, of course!) are enforcing upon as dysfunctional software that causes problems for us in writing an encyclopædia as we intend to, given, among other concerns already voiced on this very page, we are writing (and illustrating etc etc) with the intention to produce free and quality content. You enforce software that encourages breaking free licenses, that leads to an overflood of unusable pseudo-content we then have to filter again etc etc. You misuse developer resources for unwanted broken pieces of software, while we are waiting for years for these developers to repair critical bugs, to provide much needed functions, etc. We also want to write within a working community, encouraging others to join the effort, while you enforce software that makes recruting fellow editors harder and harder, and, even more hazardously, you severly harm our community e.g. by breaking previous rules of our relationship with you. We e.g. now extensively have to deal with how to react to this misbehavior of WMF, and also to radically unwanted tendencies such as laid out by your head of board on this very page. Given that several fellow colleagues, among them people who did very critical jobs that can hardly be replaced by anyone else, already left us because of your aggressive misbehavior, you already have destroyed very critical parts of our community, and that will hold for quite some time! What is more, many others have already declared, that, should such a "vision" for WMF's "future role" as laid out by our head of board prevail, they will want nothing to do with it! All this in effect stops us from what we would rather do. Ca$e (talk) 16:56, 21 August 2014 (UTC)

Because when the WMF makes a change that is disliked or broken, they refuse to disable it. That's what causes the fuss, LilaTretikov: it's not that anyone expects the software to be perfect upon initial release, it's that we expect you not to make it the default software until there's a consensus that it is ready, useful, and an improvement over the current state. Instead, we get new rights invented in order to force the software to stay in place before the repairs are made and threats made against administrators that disable it.Kww (talk) 20:22, 21 August 2014 (UTC)

On Working together: Well, you got your requested comments, when are we going to get our single issue here fulfilled? Please remove superprotect and never use it again. It is an unnecessary (existing means of dispute resolution were not used), previously undocumented and massively unsocial feature for a commons-based community like ours. --Ghilt (talk) 08:24, 20 August 2014 (UTC)

By the way, not only because of reasons already explained, i do not see any basis to discuss in a platform like Community_Engagement_(Product)/Process_ideas. The "status quo" there is not only described with an ridiciulous bias, but simply wrong. "announcements are posted through a number of channels" - that may be your perception, our perception is that they more often than not do not reach us in time and when they do, our input is ignored anyway. "Significant-scale rollouts are staged from smaller wikis to the largest ones" - that is often untrue. "After deployments, ad-hoc straw polls and RFCs/votes are sometimes organized by community members" - that is also misleading. See above where i corrected your own phrasing: The current approach of WMF of ignoring important (among them legal) issues, clearly and repeatedly voiced months ahead, and nevertheless rolling out broken und unfixed software, is disruptive and inefficient. "When following a defined process, these requests sometimes culminate in a request for a configuration change via Bugzilla." - that is also misleading. It should rather read: "Oftentimes, critical and high-priority problems are many months before rollout highlighted by expert community members via several channels, among them Bugzilla, but get ignored or handled with utmost neglect." Also, there is a very criticial point not mentioned about status quo: Oftentimes, WMF produces broken and decidedly unwanted software, and, when it is even after rollout remembered that communities voiced months before that they will not accept anything as broken (and causing technical and even legal issues, not to speak of problems for recruting new editors) as that, this is not even recognized, but the unwanted software change is just stoved down the throat of communities, while WMF-employees threaten admins with revoking user rights and even implement new user hierarchies and superblock their community to enforce such unwanted implementations of broken software. Something like that would fairly describe the status quo. "the editors think the readers can be ignored" - i will not even go into details as to why that is not only untrue but an inacceptable affront in itself towards almost every editor (see Kww above on this topic e.g.). You cannot expect community members to discuss anything 1) before the current unacceptable situation, uniliteraly created by WMF, is resolved by WMF, 2) in a not only highly biased put pullulated with untrue descriptions, environment established by members of WMF, being the party who caused and not yet resolved the affrontation against communities. Ca$e (talk) 09:30, 20 August 2014 (UTC)

Dear Lila, I would also like to express my gratidue for the time and effort you take to address this problem - it makes me feel that you take our concerns seriously and this is definitely a good first step. A problem that I see here is that two issues are closely intermingled: The question of how to move forward with the MV in particular and software development in general on the one hand, and the problem of the relation between the foundation and the communities on the other. Concerning the former, you are right, we need to talk with each other and think deeply about issues of speed, direction, uniformity vs. diversity etc. And this probably takes some time and we should not rush our fences on it.

But the other issue is much more pressing right now, and it requires quick and determined action from your side. It all boils down to the matter of trust: The foundation has lost a tremendous amout of trust in the German community over the past few years because many in the community feel that the foundation doesn't listen to their concerns and doesn't respect their specific needs and generally moves on to be something that uses the content we generate to make money, but is not willing to give anything back. Whether this view is justified or not is another question, and I'm probably not the right person to judge this. But that is the prevailing view in many discussions about the foundation.

On the other hand, the use of superprotect makes a very strong impression that the foundation, in turn, has lost their trust in the community, in particular in our ability to resolve wheelwars as the one that happened there. Just in case you don't know: RfC are generally considered as binding for the German community and DaB's edit was not covered by the RfC on the MV. Thus, I am pretty sure that this change would not have prevailed long. The fact that now he is getting a lot of approval for this action is precisely due to the unfortunate action of superprotecting the page. You guys unintentionally put him into the role of the rightful avanger against the evil system, to exaggerate a little (but just a little - that is the sad part).

To make a long story short, I would heartly recommend you to take one step after the other, that is: First unprotect the disputed page without any conditions, just to show that you are willing to trust our ability to resolve possible edit/wheelwars ourselves. Then, start/continue the discussion on the relation between foundation and communities, involving the question of how to deal with similar situations in the future, and the discussion about software development. In the current situation, I'm afraid that most of the community is not able or willing to discuss about content, when feelings are still being hurt. But a clear sign of goodwill could well put a beneficial dynamic into running.

Best wishes, Darian (talk) 09:50, 20 August 2014 (UTC)

@Lila: You say: From what I understand the issues is affecting about 1% of the images, but I have asked to confirm. No, it affects every single media file. If author and licence are not immediately and intuitively accessible especially for the un-experienced user, violations of authors' rights and licences are bound to occur, due to the failure of WMF. This is definitely a legal matter. Moreover, further information about the media files should also be readily and easily accessible (which is not a legal issue but an issue of our mission as an encyclopedia, and as such no less important).--Mautpreller (talk) 13:10, 20 August 2014 (UTC)

1) Incorrect and outside competence, see my comment above. 2) Further information is available. Alanscottwalker (talk) 13:45, 20 August 2014 (UTC)

No, it's simply correct. It took me, as a truly experienced user, enough time to find the information relevant, due to the misleading buttons and arrows. There are other problems as well (zoom!) but these are the most important ones. And who should be a competent judge as to intuitive accessibility but a user?--Mautpreller (talk) 13:52, 20 August 2014 (UTC)

No, your first legal point is incorrect and without competence. As for your second, it is your intuitive feeling -- that's fine but your intuition, is your intuition. Alanscottwalker (talk) 13:59, 20 August 2014 (UTC)

.:Thanks a lot, I see now what you (a least) mean by "working together" and "feedback". As to legal issues, the point is not that the MV itself violates law but that it is apt to promote violations of law because it fails to give easy and immediate access to the information relevant. As to intuition, look at the results of the RfCs on en.wp and de.wp as well as the reader experience collected by WMF. Seems that my "intuitive feeling" is shared by a good many users, editors as well as readers. Maybe a software developer shouldn't discard such user experiences as irrelevant?--Mautpreller (talk) 14:11, 20 August 2014 (UTC)

"Apt to promote" -- that's rather nonsensical, when you look at this page [14] and see how it identifies no rights holder. Apparently, you admit that MV gives easy access for 99%, but you focus on the 1% -- now if one looks at that objectively that is a mountain out of less than a molehill (and the molehill is largely fictitious). Alanscottwalker (talk) 14:43, 20 August 2014 (UTC)

In order to compare, you should better have a look at this one.--Mautpreller (talk) 16:04, 20 August 2014 (UTC)

Actually no, in order to compare you should look at it in media viewer where the rights holder is named in the immediate window, unlike what you are linking to where the rights holder does not appear on the screen without manipulation. Moreover, you are fixating on a 1%, which is either a matter of misplaced angst or hypocrisy: (rights holder not identified) Alanscottwalker (talk) 17:22, 20 August 2014 (UTC)

The crucial difference is between https://de.wikipedia.org/wiki/Datei:Freiberger_Dom_11.JPG and https://de.wikipedia.org/wiki/Gottfried_Silbermann#mediaviewer/Datei:Freiberger_Dom_11.JPG. It is easy to see how different the accessability to vital information is. You know youself that pictures (and videos), having only one author and forming a separate file, are a much more problematic issue in terms of licence and authors' rights and other information than texts (or the interface of Wikipedia articles as a whole). Comparison obviously requires the status-before and the status-after.--Mautpreller (talk) 18:16, 20 August 2014 (UTC)

And the media viewer puts the rights holder and licence in the immediate screen (unlike what you apparently prefer) -- and everything else is accessible in MV. Alanscottwalker (talk) 18:31, 20 August 2014 (UTC)

So how will an un-experienced user will find all the information (including licence text, description, date and so on) that exists for this file and that he will need for using it? He never even is informed about what the picture shows!! The absolute minimum would be a clear link to the description page on Commons, visible immediately for everyone without any extra activity, stating: if you want to know something about the picture (e.g. what it shows ...) and possibly use it, click upon this link. I prefer to jump right to Commons but that may be an individual feature. But it is absolutely indispensable that you can find your way there as an unexperienced user.--Mautpreller (talk) 19:32, 20 August 2014 (UTC)

It says "Freiberg Cathedral" right there (should I Use !!) in the immediate MV window right over the rights holder's name. If you want to know more on the licence, point to where it says exactly what the licence is, right there in the window (!!) Alanscottwalker (talk) 19:43, 20 August 2014 (UTC)

The picture does not show "Freiberg Cathedral". The object of the picture is named in a description line on the Commons page but not on the MV page (and hardly to find from there). What you need is a link to all relevant information including full licence text, viz. a link to the Commons page right there in the window. This is far better in the old version (and best if you immediately jump to the Commons page). The picture looks fine in the MV presentation but that's all, you have no indication where to find context information (even the meaning of the licence is not evident, you haven't even a hint that you should click upon it). To put it otherwise: presentation seems more important than information (in an encyclopedia! an absurd idea to my thinking). One could improve the way of presentation of the information relevant, good idea; but the media viewer does not do that. It hides the information so that you do not know where it is or even whether it exists in the first place.--Mautpreller (talk) 22:20, 20 August 2014 (UTC)

The picture shows a part of Freiburg Cathedral, and because that is what the rights holder named his composition. It's his composition, remember. The specific description is there in the Media Viewer -- sure it's below the fold, which is the exact same position as on the Commons page (below the fold), but the media viewer is superior for information because it has more information above the fold. What's important is all there. Alanscottwalker (talk) 23:18, 20 August 2014 (UTC)

Dear Lila Tretikov. Please recommend to the international Communtity of Individual Volunteers (iCIV) the developement of a Charter of Coordination in coordination with the Wikimedia Foundation. Bylaws Article II (Statement of Purpose) mentions the coordination of WMF and the iCIV but does not say how. In On a Scale of Billions it was stated: „This process must have multiple opportunities for community feedback. We realize that has not always been the case in the past, but this will be one of my top priorities as Executive Director.“ and you have discribed further details in Working Together. In terms of "coordination" we need to define an objective definition of how to coordinate.

Please support this recommondation and please compare the Code of Good Practice for Civil Participation in the Decision-Making Process adopted by the conference of international non-govermental organisations (Council of Europe). There has been spent very much and useful work with a high level of agreement – some of it could be copied easily for ccordination, you might call balance, too. --Edward Steintain (talk) 15:07, 20 August 2014 (UTC)

____

All we are doing is asking everyone to hold the current state until we jointly find a better way to make decisions on product. -- Lila, the current state is hurting the dewiki community, because it says: "We don't trust you." WMF has driven a bolt into the community's delicate machinery. Here you wrote: I care and am sincerely sorry for any hurt feelings stemming from this. Then, please stop hurting us! Every "day under superprotect" deepens the scars and damages the community's trust into WMF. There is an increasing group of users starting to hate WMF for that. Are you not aware of this, or do you deliberately accept it?

Though the community is hurt and still angry, it just unlocked Eriks account de:Benutzer:Eloquence, because it realized that this was wrong and as a sign of goodwill. Please do the next step and unlock de:Mediawiki:Commons.js. --PM3 (talk) 19:17, 20 August 2014 (UTC)

My quick response (Rich F)

• "From what I understand the issues is affecting about 1% of the images" Lila

• "[A]s a lawyer, I don't think that the license is actually being violated in the vast majority of cases." Luis

• "the way the viewer works (the only way it can work) is by extracting machine-readable information via an API." Erik

• " If it is a legal issue -- it will be treated as a blocker." Lila

These four statements show that the attribution problem alone means that the MV should be disabled.

Once this is done there are many ways forward.

But the executive decision is: do we stay legal or not?

Rich Farmbrough 14:56 29 August 2014 (GMT).

I really appreciate the substantive comments. From what I've read, clear action was not always easy to obtain under previous leadership, and Lila is making at least one clear commitment. We have to hold her and the WMF to it. Lila, we're coming up on 9/15. Have all WMF employees created clearly distinguishable accounts for use as employees of the WMF?

Also, I have a few suggestions with regard to such accounts:

• Distinct formatting might help call out comments from WMF personnel. Perhaps WMF employee accounts should use a signature format called out by colors and/or typeface. Admins are probably monitoring new accounts that might spoof WMF accounts by name and/or sig text; they could monitor sig formatting for spoofing, as well.
• Consider extending this policy to Wikipedians in Residence. Oftentimes their WiR and personal roles are less than distinct in their comments.
• The user pages of employees should have at a minimum some information about their position at the WMF and what issues the community can address with them, so that we can engage in more direct, point-to-point communication where appropriate.
• WMF'ers should be encouraged- but not required- to post photos of themselves and some interesting personal facts, so that we can all get to know them better. It always helps to remind everyone that we are addressing other people and not just usernames. This may be even more difficult to keep in mind when addressing "official" accounts.

Thanks for keeping your promises.

-wʃʃʍ- 09:06, 12 September 2014 (UTC)

Welcoming encouragement

Hi Lila, Welcome Aboard! You've got your work cut out for you, as no doubt have already discovered with Media Viewer.

A decade ago, unilateral action like the Superprotect would have made me quite angry-- and even now, I certainly can certainly understand the emotions of those who are presently upset with the process.

But the simple fact is-- we must change. Wikipedia is dying. Our community is dying-- Newbies no longer convert into veterans. Our software looks antiquated in compared to the modern web, pictures and videos are still too hard to upload and include. There used to be a philosophical debate between "Inclusionists" and "Deletionists", but that debate is now over and the deleters do much to discourage newbies.

For-profit sites that lack our values have taken over the innovation we once prided ourselves on-- people routinely choose Wikia or private hosting for specialist Wikis. My father, a genealogy aficionado, shells out $20 a month, EVERY month, to a for-profit company-- renting the 'right' just to access public historical records-- records that WMF could host at little or no cost, if we had the will. I see so much good WMF could do-- if only we could regain the flexibility to innovate once again.

Standing in the way of innovation are two main obstacles. One obstacle is that our existing communities are quite happy with existing system, which seems to works well for them, even if it's toxic to newbies. The other obstacle is that Wikipedia is now mission-critical: our planet is not prepared for a day without Wikipedia. We can't make dramatic and bold changes the way we could during the early days-- too many people depend on us.

Potential Solution

My own humble thinking on the problems is that we need new projects, and hundreds of them. If I want to create a new subreddit or a new FB group or a new Wikia project, I can do so with a few short clicks. But here, it's still 2002-- we only allow one community per language-- we permit only one way of doing things per language.

So long as there's only one project per language, change is nearly impossible. Look at all the backlash even a relatively minor change like MediaViewer is causing-- if the ED can't get consensus for even minor innovations, what hope does the average user have?

I think the solution is to allow new "feeder" projects. When Nupedia was too closed to outsiders, we created Wikipedia as a feeder project. Now that Wikipedia has become Nupedia, perhaps its time to allow new feeder projects to grow.

This would allow our existing community to keep the status quo that works well for them, but it would also allow the Foundation and others to build a better project without having to consult anyone, without having to ask permissions for every change, however small. Those of us who want change could be free to change, without stepping on the toes of those who like things as they are.

Thanks

Welcome aboard, Lila! It is my sincere hope that your joining the foundation will usher in a new era of innovation and the end of our stagnation. --AnonymousCoward8222104 (talk) 10:41, 22 August 2014 (UTC)

Where there is discord, may you bring harmony. Where there is error, may you bring truth. Where there is doubt, may you bring faith. And where there is despair, may you bring hope. --Arcudaki (talk) 11:33, 22 August 2014 (UTC)

Who can forget those stirring words from Margaret Thatcher? RomanSpa (talk) 06:00, 23 August 2014 (UTC)

Thank you for your thoughts -- I know this is tough for all of us. But I love the fact that there are so many opinions. We indeed have a lot to do. There is the basic issue with the cost of development -- I've spoke about the 80/20 rule elsewhere, there is the issue with changing user experiences (i.e. users are trained to expect different things), issue of new form factors, issue of keeping our current editors happy while engaging new, issue of getting access to records (why do others host elsewhere, when they can share knowledge here, free), issues of embedded content (through search engines and OSs -- so dramatics changes are happening to us, elsewhere), issues of consistency and technical debt... MV is a canary in the goldmine -- we need to be clear on the role and responsibilities of the Foundation within the overall user community in understanding the needs of the users and the changing environment of the world. It is not trivial and it is critically important to our project. . -- LilaTretikov (talk) 16:05, 24 August 2014 (UTC)

I used a Thatcher analogy - You used a mining analogy. Sound like fun. Anyway, you also used the 80/20 rule I hear all the time from power pointers in elegant suites. It says that you can achieve 80% of the aim for 20% of the effort. Trouble with implementing that is that now your aim is to use 20 % of the effort and your original target is outside the scope. Ergo you miss.--Arcudaki (talk) 07:32, 25 August 2014 (UTC)

I think you know why people host elsewhere by now! Rich Farmbrough 21:23 7 September 2014 (GMT).

Archiving this page

Unless I'm behind the times on the archive bots (which of course I might be), you need a declaration at the top of this page to instruct an archive bot to archive inactive threads on the page after some chosen number of days. Either that, or you have to do the archiving by hand, in your copious free time. --Pi zero (talk) 20:47, 27 August 2014 (UTC)

Lila, I'm pretty sure this page is now much too big for users with, say, mobile devices to access. I certainly wouldn't feel right about putting an archive-configuration template here without your permission, but it really should be done, so the size of the page gets back under control. --Pi zero (talk) 17:54, 8 September 2014 (UTC)

If you could help me with that -- I would greatly appreciate this. I have not yet responded to the newer discussions, so maybe archive only about the top 50% or so? Thanks so much for this. -- LilaTretikov (WMF) (talk) 18:16, 8 September 2014 (UTC)

I have (I hope) configured the page to archive sections that haven't been updated in 21 days. That figure, 21 days, is adjustable by changing the number in the template call at the top of the page.

21 days will probably only archive a few of the oldest sections, for now. Perhaps you'll want a shorter fuse than that, and wish to adjust the number downward. I don't want to be responsible for causing a bunch of premature archiving, though; I tend to approach these things with what I hope is a very safe setting. (Of course we can repair the damage if something did get archived while still wanted.) I'm guessing that over the next few days, a number of the oldest sections will get archived, and the size of the page will slowly get more manageable, hopefully leaving you safely well ahead of the bot. --Pi zero (talk) 19:55, 8 September 2014 (UTC)

Hm. I've trimmed it down, slightly, to 17 days. --Pi zero (talk) 07:12, 13 September 2014 (UTC)

Mathematics under Flow

I just tried this out and discovered to my surprise that a year after starting discussions with the Flow developers, mathematics still does not work properly on Flow. Given our previous discussions about the absence of WMF resources for mathematics, could you let us know what your plans are for mathematics formulae under Flow? Should we assume that they are unlikely to be fixed? No need for you to reply in person, if you would get the person responsible to do so, that would be much appreciated, thanks. Deltahedron (talk) 20:03, 29 August 2014 (UTC)

I am not yet up-to-speed with Flow requirements -- I will forward to the PM. But really quickly priority-wise -- I was under the impression that VE improvements were higher on the list. Could you confirm, please. -- LilaTretikov (WMF) (talk) 20:19, 29 August 2014 (UTC)

In terms of the proposals that you turned down, rendering came first, but sustaining mathematics on VE comes before Flow, because VE is already with us, and Flow isn't. But the strategic question, which I think is for you, is: if mathematics doesn't work, or is hard to get working, under some new product, such as Flow for example, is there effort to make it work, or should we assume from your previous answers on the subject, that it will be best endeavours? Oh, and thanks for passing the specific question on! Deltahedron (talk) 20:26, 29 August 2014 (UTC)

(Copying my reply from the Enwiki talkpage) Yes, <math> should be working. It was working a week ago, as you saw at mw:Topic on Talk:Sandbox, so this is a new bug. I've filed bugzilla:70187 after replicating it and discovering some details. Thanks as always for the pointer. Quiddity (WMF) (talk) 20:46, 29 August 2014 (UTC)

Thanks for the prompt response -- as I said, just my bad luck to come back a year later and find it not working again. Deltahedron (talk) 20:50, 29 August 2014 (UTC)

This is the kind of interaction I am hoping for: have we thought through all the usecases? What is the minimum we are willing to live with in revision 1? in revision 2, 3, etc.. Is it working pre-release? What are the things we *must* support vs. *should* (keeping in mind not everything can be a must in the first revision, or we won't ever get anything to the finish line). In VE, references clearly were a must, for example... We are brainstorming on that here. On Flow -- keep in mind it is under active development, so you are likely looking at an unstable version. -- LilaTretikov (WMF) (talk) 21:07, 29 August 2014 (UTC)

Well, quite a lot of work was put into the use cases almost exactly a year ago at en:Wikipedia talk:Flow. At that time, mathematics under Flow was not yet working. That's why it is disappointing to come back a year later and find it still not working. We're told that it had been working but somehow got broken again, and that's exactly what's worrying people like me -- the wider point is, given that there is no effort for mathematics, and you declined to allocate even a point of contact for it, what will happen if it breaks again as a result of some other change? There won't be anyone whose job it will be to fix it, or even to advocate for fixing it, or to talk to the community about fixing it. So I have to assess that there is a realistic chance that it will in fact break and just not get fixed? Now that it's not on the roadmap, you can understand my apprehension. Deltahedron (talk) 21:25, 29 August 2014 (UTC)

This is actually a fairly simple bug to fix -- as Nick said, it was working a week ago, but something in the latest release caused a fatal error in that function. So while this is definitely annoying, it's not something that's seriously broken and needs to be redesigned -- just an error in the code somewhere that we can find and fix. I'll talk to the Flow team about adding some automated browser testing for the Math function, to make sure that we catch any future Math-disabling bug before it goes out into production. We've started investing more resources in building browser tests like that -- we're not completely caught up, but we're getting better, and we make sure to write tests when we see a process fail like this. I'm sorry that you caught this just when you came back! That's frustrating. If you see any further problems with Flow, you can let us know either on the Flow feedback page on Mediawiki or on English WP. DannyH (WMF) (talk) 21:53, 29 August 2014 (UTC)

Thank you for that explanation. I'm glad to hear it's only a bug. My question for Lila is more about what commitment she can give to making sure that effort is available to make sure that bugs like this are caught and are fixed when caught: I don't to trouble her with bug reports, but do want to hear a little about the strategic direction. By the way, should I assume that it's up to the users to find this sort of bug? Deltahedron (talk) 07:48, 30 August 2014 (UTC)

This is what we would call a *regression* bug. This means that we have it in the spec that the "version 1" of the feature must support this use case, we implemented it, and then we broke it as we are building other things. It is a fairly common case in software development, although undesirable, and there are ways to minimize this. No, it should *not* be found by users (unless you are testing -- as in this case -- an interim build). Since testing is a non-deterministic problem it is useful to establish some goals around regressions. Keeping regressions under 1% rate (this is for software, hardware/firmware is much less tolerant) is a target I used before (which means roughly that out of 100 bugs that were previously fixed at most 1 may come back in any given release). When it happens it is an "must fix" blocker bug. -- LilaTretikov (WMF) (talk) 20:55, 31 August 2014 (UTC)

That's good news, thank you. I'm sure you'll understand my apprehensiveness. Deltahedron (talk) 21:10, 31 August 2014 (UTC)

I hope that Flow will never come. And I won’t edit on a now-being Flow page, because this thing is much too buggy. There are problems which should have been fixed, before Flow is being used on any page. Can’t say more about this. That noone notices this after one year, makes me very pessimistically that Flow has ever been checked at all (with more than one or two browsers or usecases) before using it onwiki. And that anyone shall report bugs on that on a talk page which itself uses it, doesn’t make this better. You better shouldn’t use a buggy software on pages, where people shall report you any bugs. That’s the main error for that. And you should always have a page here on Meta without Flow for reporting errors. Not every user can report on enwiki, where perhaps another user has already an account with his user name. Because the SUL finalization hasn’t come yet. Why is it more important to force new software which make Wikipedia another social media thing instead of an encyclopedia than to fix the main problems here? Why does it take that long (years) for the SUL finalization, and why are some important things never being fixed? There could be so many things done with the money, but instead you force things onto the communities which are buggy, which don’t like many people. I can’t understand that at all. And now, this buggy Flow is already in the preferences here on Meta? Why? Why is it in use, while everyone is seeing that it is „an unstable version“? I can’t see, how this thing does anything useful. And why shall people report problems with itself on Mediawiki wiki by using this buggy, unstable software? I don’t get this at all. --Winternacht (talk) 15:20, 30 August 2014 (UTC)

Flow in general

Just to be extra sure: When you ask "What is the minimum we are willing to live with in revision 1?" you really mean "What is the minimum the community of authors is willing to live with in revision 1?", do you? And the WMF will communicate the benefits of the flow to the community on a time scale that reflects the potential disruption a complete overhaul of the discussion technique can cause, will it? ---<(kmk)>- (talk) 00:08, 30 August 2014 (UTC)

Correct -- as in "We the Users". And yes, we need to clearly state what we are trading off here. I do want us to be clear that we are trying to go from what essentially is a text editor that allows for any type of text manipulation and very little pre-defined structure (except by convention) to a more structured conversation format, which by definition means creating constraints. I think that is probably the biggest source of discourse. Yes? -- LilaTretikov (WMF) (talk) 22:17, 2 September 2014 (UTC)

Probably so, yes. The problem is that there's no particular benefit to creating those constraints, so most of us view the loss of flexibility as more of a problem than any trivial benefit that Flow could provide. It's especially disconcerting that the Flow team seems intent on not actually acting on negative feedback, no matter how polite and well-reasoned. Kww (talk) 22:30, 2 September 2014 (UTC)

Flow looks like it might become the best discussion system I've ever seen anywhere on the internet. We need a collaboration system, and if the devs listen to us maybe it can be both. But those details don't belong on your talk page. I have a bigger concern that does belong here. Lets say Flow turns out perfectly. Flow gets fully deployed as an awesome discussion board next to every Wikipedia Article. Have you considered that the chat boards will be flooded by posts that have nothing to do with improving the article? Any remotely controversial topic will be flooded with people arguing over that topic - not arguing edits - people just plain engaging in flame wars with each other over the topic. I'm guessing the WMF could handle the flood of pointless traffic to run those message boards, but I don't think we could manage to work under those conditions. I don't think we could prevent the article from getting trashed under those conditions. Have you thought about this sort of thing? I pondering an idea, I haven't worked it out fully yet, but maybe add an item to the roadmap. Let us (Community) pick one or more pages on English Wikipedia, and we slap an early version of Flow on there (Article+WikitextTalk+Flow). The earlier the better. It doesn't need scratchpad or anything. Just something to give all of us, the WMF and Community, a peek at what happens if we go where you are planning to take us. Alsee (talk) 17:22, 3 September 2014 (UTC)

@Alsee: You mean, something like the way en.wn has been set up for years (only using Flow instead of LQT)? --Pi zero (talk) 17:42, 3 September 2014 (UTC)

@Pi zero: I hadn't seen en.wn before, yeah like that but keeping the current Wikitext Talk too. Maybe put it on a quiet non-controversial page as pre-test, but the real test would be putting it on something like en:Expelled:_No_Intelligence_Allowed back when it was a fresh release. Something with hot-news high traffic, highly controversial, but non-serious. In the Expelled incident the good editors were at the breaking point trying to keep the article sane in the midst of the Creationist PoV warrior influx. It would have been utter disaster if we had ten thousand people storming in there to use the place as a public chat board. Alsee (talk) 19:48, 3 September 2014 (UTC)

I think there may be an ideological gap here. Some people see Flow not as a way of holding exactly the same discussions that we currently have only in a fancy-looking format, but rather as a way of organising and managing the workflow (hence the name). Perhaps if such unmanageable discussions became impossible under Flow that would be the desirable and intended outcome? Deltahedron (talk) 20:29, 3 September 2014 (UTC)

I may have confused things by not being clear, so I'll try to straighten myself out. On en.wn, each article has two pages associated with it: a "collaboration" page, internally "Talk:", which is an ordinary wiki page for discussion of the composition of the article, and an "opinions" page, internally "Comments:", which is an LQT page for discussion of the topic of the article. Community use the collaboration page; readers use the opinions page. We colloquially refer to comments-space as "troll-space"; almost anything goes there, necessarily. An oft-cited case is, we've published interviews with neo-nazis; now, it wouldn't be fair to publish such an interview, and then not allow neo-nazis to stand up for their positions on the comments page. So, as I said, almost anything goes in comments space.

Again, the collaboration page, for discussion of the composition of the aritlce is emphatically not an LQT page, it's an ordinary wiki page.

I think we've got strong consensus at en.wn for three things:

1. It is a very good thing that the collaboration page is an ordinary wiki page, rather than using LQT.
2. It is a very good thing that the comments page is not an ordinary wiki page; we had experience of what that was like before LQT, and it was dreadful; the non-wiki readers commenting on the article didn't know how to use wiki markup, and members of the community had to put a lot of labor into cleaning up the botched formatting and lack of signatures.
3. We all loathe LQT, even though we agree it's a good thing it's used for comments space.

I don't think we know a lot about Flow at en.wn; so, although I think we'd have a solid consensus that collaboration pages should be ordinary wiki pages, rather than using any sort of comments system, I'd only be speculating if I suggested we'd have a "strong" consensus on that. --20:46, 3 September 2014 (UTC)

• As far as I can tell, the most active Flow discsussion is being held at en:Wikipedia talk:Flow. Perhaps the most obvious venue would have been mw:Talk:Flow but that seems unpopular as a venue. I can't say why, but it is a Flow-enabled discussion page ... . Deltahedron (talk) 06:29, 4 September 2014 (UTC)

We should avoid using Lila's Talk page to discuss Flow details, but the above discussion makes it clear that some of us (maybe me) are very confused about WMF's envisioned end point for Flow. Does the WMF envision editors continuing to use current Talk pages for our discussions while Flow is added as a public troll-chatboard which we ignore? Or does the WMF envision Flow as our place for discussing work on articles, with "scratchpad" to support the case where I want to allow others to make edits to my post? Alsee (talk) 17:30, 4 September 2014 (UTC)

I wish I knew the answer to that question.

It's worrisome to have doubts whether WMF really groks the difference between these two profoundly different possible uses of such a tool. It seems WMF doesn't start by deeply studying the workflow of projects before planning and investing in big software development that may actually interfere with, rather than complementing, various projects' operations — VisualEditor, MediaViewer, and Flow come to mind — and that seems a fair topic for discussion here. --Pi zero (talk) 18:08, 4 September 2014 (UTC)

My understanding is that the Flow team were going to undertake significant research, in conjunction with the community, into that very topic: see [15], dated 16 October 2013. Deltahedron (talk) 18:32, 4 September 2014 (UTC)

It's presumably better that they said they were going to do that than if they hadn't said they would. Did they actually do it? If so, that would be even better. Frankly, though (hey, I'm a Wikinewsie, I'm supposed to be frank), the very idea of Flow shouldn't have existed yet if they were saying they were going to do that. Getting into a project and then saying, gee, we should look into its impact on workflow, suggests to me a profoundly broken process. --Pi zero (talk) 19:01, 4 September 2014 (UTC)

I asked [16]. I think the point for Lila here is, there seems reluctance on the part of the various product teams to expose their design and planning documents to the community, even when they are actively engaging. For example, there should be a year's worth of research into workflows available somewhere. Since the Flow team are still discussing models with the community, perhaps they could publish that research? Deltahedron (talk) 06:36, 5 September 2014 (UTC)

A fundamental difficulty, which I suspect Lila may find herself struggling to get a handle on as it may be quite different from what she anticipated when taking on the position (wasn't there something in her keynote about wikimedia being unlike anything else?), is that each of the projects is a subtle entanglement of social dynamics with enabling technological medium. A self-organizing system whose formative rules include social momentum, explicit policies, and software behavior ranging from large-scale characteristics to small details (and maybe other things I'm forgetting or missing). Making this organic mix thrive is like caring for houseplants; some people have a green thumb, others don't. The best way to tell who has a green thumb and who doesn't is to disregard the details of what they do, and look at the condition of the plants under their care. From what I understand of the history, WMF kicked into a higher gear in 2007; that was the year they created the position of Executive Director. Don't try to analyze things in terms of personalities or specific decisions, just look at the projects. Broadly speaking, they peaked around 2007 and have been going downhill ever since. I'd like to think if I were part of the WMF structure I'd be deeply worried about that. Does it suggest a course of action? Well, it suggests that any possible solution would have to fundamentally change the dynamics of how WMF affects the communities (and, ultimately, everything the WMF does affects the communities); fine-tuning things won't be enough. --Pi zero (talk) 11:57, 5 September 2014 (UTC)

• I think that detailed conversations about Flow should be held at the pages I mentioned above. Perhaps a better use of Lila's time would be to make a statement about the status of Flow. Comments at en:Wikipedia talk:Flow suggest that it is effectively being rebooted. Perhaps Lila would tell us whether WMF is still committed to a radically new discussion page structure; whether that will be Flow in some form; if Flow is being rebooted; what issues which were apparently decided will be reopened; how she wants to take the community involvement forward; what timescale she is thinking of for the design, development and deployment. Deltahedron (talk) 18:56, 4 September 2014 (UTC)

I don't want to seem importunate, but in view of the statement by Erik at en:WT:Flow, it would probably be a good idea to make an official statement across the full range of projects about the status of Flow right now. Deltahedron (talk) 11:12, 6 September 2014 (UTC)

• Another thing Lila might need to look at pretty soon is the row blowing up at en.wp over the sudden roll-out of Flow to their TeaHouse: see en:WT:Flow. Deltahedron (talk) 16:51, 5 September 2014 (UTC)

Courtesy Message

Dear Lila Tretikov,

This message is a courtesy message to inform you that proceedings have been initiated with the Privacy Commissioner of Canada with regards to WMF's refusal to allow the termination of accounts & removal of their personal information (not contributions). Why WMF ever believed that, once you signed up, you could never terminate that relationship and individuals would be forever forced to agree to every change in the terms and conditions... is well, quite beyond me. I sincerely hope that the process results in better privacy/deletion process for users. JMJimmy (talk) 02:16, 3 September 2014 (UTC)

Legal and Community Advocacy would have been a more appropriate place for this posting. --Túrelio (talk) 16:17, 3 September 2014 (UTC)

@User:JMJimmy: I am not familiar with your concerns, but maybe the following information could be relevant: local guidelines usually consider privacy as appropriate cause for user renaming and in cases of legitimate concern regarding privacy/breaches of anonymity, edits would be deleted by admins / oversighters (see especially guidelines on "courtesy vanishing"). Can you refer to the case in question? Thanks, Ca$e (talk) 06:45, 8 September 2014 (UTC)

Why I can no longer help you with Community Engagement (Product)/Process ideas

After the struggle I had to get our propoals in front of you, and the disappointment of having you reject them, I thought it might be a good way forward to try to contribute constructively to some of the discussions around Process, such as Community Engagement (Product)/Process ideas, and use some of my experiences to help inform and stiulate the discussion. One of your staff members suggested on the talk page that the current process, which she summarised as "whenever you have a great idea involving something technical, that you share the idea with the rest of your community at one of the Village Pumps (or some other centralized forum). If the rest of the community is interested, they'll point you to the right place" and described as "the standard, community-based process" was all that was necessary. (I pass over whether this is a "process" in any meaningful sense.) I said that I had found it did not work, and that statement of mine was entirely correct. I had to follow a quite different process, as you know from your own direct experience, which involved getting Jimmy Wales to pass it on to you and the Board, direct involvement by you, and a private email exchange between us. So in other words, the standard process failed, and to get an answer I had to do something completely non-standard. (I assume that you would not regard it as "standard" to have every such suggestion go via Jimmy,the Board and yourself).

I was very upset indeed to find that my comment that the process had not worked discounted, indeed contradicted, by the entirely false assertion that the process worked and that I simply did not like the answer. I hope that our exchanges have convinced you that I am capable of distinguishing between a process and its result, and that when I say the "standard" process did not work I meant exactly what I said: I got no answer at all from the "standard" process , and only got an answer, albeit not the answer I was hoping for, from an entirely non-standrd process. I was further upset to find that when I tried to explain the difference, the staff member in member continued to be rude and dismissive. I would go so far as to say that dismissing my comments on these entirely spurious grounds even after I have rebutted them is dishonorable, if not actively dishonest.

This is not what I expected when trying to help you develop new processes. If a comment critical of the existing process is shouted down in this way on entirely spurious grounds, by staff with a vested interest, then clearly no genuine discussion can be entered in to, and presumably no genuine discussion is intended. It seems that you and your staff can afford to reject the honest constructive if critical suggestions of your users. That makes it clear that there is no longer any point in my trying to help you improve your processes. I will probably make one more attempt to contribute to improving relationships between the WMF and its users, but I have to say that right now I regard your task as deeply unenviable, possibly now actually impossible. Deltahedron (talk) 19:32, 5 September 2014 (UTC)

I am sincerely sorry you felt that your opinion has been discounted, I hope you can come back to participate in the future. Would you mind pointing me to the conversation? I want you to know that I appreciate recommendations and feedback on what is/not working. -- LilaTretikov (WMF) (talk) 02:04, 6 September 2014 (UTC)

Lila, with respect, Deltahedron's account indicates something more serious — and more entrenched — than merely having one's opinion discounted. --Pi zero (talk) 05:29, 6 September 2014 (UTC)

Lila, thanks for that. The relevant diffs are [17], [18], [19]. However, I want to emphasise that I am not complaining about individuals, so much as saying that I think that the process at Community Engagement (Product)/Process ideas cannot work f your staff argue with contributors who are trying to give their opinion. In fact, it's also rather disturbing that your staff are also editing other peoples' comments at the brainstorm because they disagree with them [20], [21], [22] -- and again that a member of staff who is contributing to the brainstorm is also going to be reviewing the results. This is not a picture of a constructive engagement. Deltahedron (talk) 08:03, 6 September 2014 (UTC)