On 10/07/2014, Brion Vibber <bvibber(a)wikimedia.org> wrote: Whole heartedly agree that this is a known and recognized limitation of the RfC process, apart from where we are talking about Wikimedia Commons, not the English Wikipedia. Of course it does not invalidate the RfC as a survey of users that do log in, edit and hear about RfC pages. Was there a report from a survey that supported having a MediaViewer specified as rolled-out and better represents the majority "user base" rather than the volunteer community of contributors? Fae -- faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae

On Jul 10, 2014 10:36 AM, "Isarra Yos" &lt;zhorishna(a)gmail.com&gt; wrote: of the understanding, on some level, that everything they do, that the entire encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the site exactly as this audience would, simply taking things a step further to edit as well. comment, do not discount them. No more than you discount yourself when you try to speak for the users who never log in, never edit, and never comment. https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> Yes. Exactly this. I am beyond tired of hearing that those who have volunteered hundreds or thousands of hours per person toward building the greatest educational work in history do not have at heart the interests of those who would use it. If I didn't care, there are plenty of other ways I could spend my free time. We should value those volunteers, and quit belittling their concerns. They made this thing and they keep it running day to day. They deal with readers who get upset or confused about something. They do it for no pay and often very little thanks, for no other reason than that they care deeply about the project and its goals. To say we don't care for the end users of that work is nonsensical and insulting. We differ with you on how to serve those users and our volunteers, who also greatly matter. Stop handwaving that away. Todd

This is exactly why there is an opt-out for the feature. We don't expect everyone to like everything we make. That's a reality. So take 10 seconds to go to your preferences and disable it, and you'll never see it again. Dan On Thursday, 10 July 2014, Pierre-Selim &lt;pierre-selim(a)huard.info&gt; wrote: -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

In order to anticipate and meet the needs of readers, you have to have a theory of what those needs are, and what will meet them. The RfC process is one way of getting toward such a theory, and the kind of work done by the WMF's Multimedia Team over the last year or so is another. The pros and cons of RFC-based consensus have been pretty well covered by others in this thread, and I won't go through them all again -- but I do want to strongly endorse the point Todd Allen made, that many regular volunteers DO care about the experience of readers, and many of us DO have important insights into how readers, new contributors, etc. experience the site, and what would work for them. The Multimedia Team's approach, on the other hand, seems at this point to be all "con," no "pro." Many people in the discussions on ENWP, Commons, and MediaWiki have elaborated on the many problems in the methodology. English Wikipedian Nyttend's comment, while phrased a bit more harshly than I would choose, summarizes the points fairly well: "Here at Wikipedia, we have a term for [aspects of the Multimedia Team's gathering of statistics]: votestacking <https://en.wikipedia.org/wiki/Wikipedia:Votestacking>, which is a form of inappropriate canvassing <https://en.wikipedia.org/wiki/Wikipedia:CANVASS>. Discussions affected by canvassing are not considered to result in consensus, and those engaged in votestacking are shown the door <https://en.wikipedia.org/wiki/Wikipedia:BLOCK>: we do not accept their ideas." -Nyttend https://en.wikipedia.org/w/index.php?title=Wikipedia:Media_Viewer/June_2014… So -- if we are to eschew the RfC process, what better process is available? How are we going to develop a clear shared understanding of the needs of readers, and the best methods to meet those needs? -Pete [[User:Peteforsyth]] On Thu, Jul 10, 2014 at 10:13 AM, Brion Vibber &lt;bvibber(a)wikimedia.org&gt; wrote:

On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim &lt;pierre-selim(a)huard.info&gt; wrote: Also, try ctrl+click (cmd+click on OS X) or right-click then "open link in new tab". You'll find it opens the Commons description page just as always. (I'd generally expect power users to be using multiple browser tabs already.) -- brion

On 10 July 2014 17:36, Isarra Yos &lt;zhorishna(a)gmail.com&gt; wrote: OTOH, typical mind fallacy is rampant everywhere and the results of an actual decent user survey would probably surprise everyone. - d.

On 10 July 2014 19:23, Isarra Yos &lt;zhorishna(a)gmail.com&gt; wrote: I concur that there's a bit much reasoning from no data, and we could do with some. Anecdotally, (a) I don't mind the new viewer (b) I know a lot of people who've said they love it (c) I know a few who've said they hate it. So yeah, real user surveys needed! - d.

On Jul 10, 2014 12:42 PM, "David Gerard" &lt;dgerard(a)gmail.com&gt; wrote: directly may rather But the https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> I agree that's sorely needed. We would need a few things to ensure it would work: --A neutral question. "Do you prefer A or B for...?". Half the takers get the new stuff as A, half get the old. No front loading of the results. --No self selection of participants. That's not easy but is necessary. People who take the time to self select may be more likely to perceive a problem. --Getting real feedback and actually analyzing it. Why did people like A or B? Is it for reasons that make sense to default it for logged in editors as well as casual readers? A lot of friction could be reduced if editors' workflows were not unexpectedly disrupted. --Publishing full (anonymized) results (not a summary only) and methodologies prominently. If we can do that, I'm all for the survey. Otherwise, it's useless.

2014-07-10 17:53 GMT+02:00 Brion Vibber &lt;bvibber(a)wikimedia.org&gt;rg>: I don't intend to bother you when you are making an encyclopædia, Brion, but if this is the stance the Wikimedia Foundation takes it's time for me to leave the project. I expect the Wikimedia Foundation to respect a community consensus. If you think you have another community of crowdsourcing workers then go ahead. I won't tolerate this. Regards, Jürgen.

I don't see any office action at all here. All I see is an administrator acting per what a WMF staffer has said. The code added as explained on the page; disables the feature fully and does not allow any opt ins. John Lewis On Thursday, 10 July 2014, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: -- John Lewis

On 10/07/2014, Todd Allen &lt;toddmallen(a)gmail.com&gt; wrote: Wow. This has fallen apart quickly. However the WMF's "no" position has been made extremely clear to all of us unpaid volunteers. That's a good thing I guess, as there is no point in us volunteers wasting more of our time having an opinion, or expressing our opinion. Fae -- faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae

On 10/07/2014, David Gerard &lt;dgerard(a)gmail.com&gt; wrote: Dear David, Get off my back please. I suggest you get your facts straight before making false allegations. Fae -- faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae

I am aware they are the same. John Lewis On Thursday, 10 July 2014, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: -- John Lewis

Erik Moeller wrote: Thanks for the reply. :-) If your feature development model seemingly requires forcing features on users, it's probably safe to say that it's broken. If you're building cool new features, they will ideally be uncontroversial and users will actively want to enable them and eventually have them enabled by default. Many new features (e.g., the improved search backend) are deployed fairly regularly without fanfare or objection. But I see a common thread among unsuccessful deployments of features such as ArticleFeedbackv5, VisualEditor, and MediaViewer. Some of it is the people involved, of course, but the larger pattern is a fault in the process, I think. I wonder how we address this. MZMcBride

On 11 July 2014 00:40, Erik Moeller &lt;erik(a)wikimedia.org&gt; wrote: Problem. Existing workflow broken is my being aware of what new users are seeing when they want to know how to do something. -- geni

On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg &lt;jayvdb(a)gmail.com&gt; wrote: In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information. This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use: http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information. Where no license is detected, Media Viewer still falls back to a "View license" link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data. Can you give a specific, current example? It takes exactly one click using the "View original file" button. Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

I agree with Erik here. Media Viewer may have some bugs that need to be fixed. But there are plenty of issues in other places too (like license tags). They also need to improved. See this ongoing discussion. [1] See my comment on RfC on Commons. [2] Jee Links: 1. https://commons.wikimedia.org/wiki/Commons:Village_pump/Copyright#Propose_t… 2. https://commons.wikimedia.org/w/index.php?title=Commons:Requests_for_commen… On Fri, Jul 11, 2014 at 1:20 PM, Pine W &lt;wiki.pine(a)gmail.com&gt; wrote:

On Fri, Jul 11, 2014 at 4:21 AM, John Mark Vandenberg &lt;jayvdb(a)gmail.com&gt; wrote: This happens to be the file's name, which is also the first thing users see when they visit the File: page. Media Viewer uses filenames for the titles because there is no consistently short description/label available. It's been suggested to potentially move the caption (when available, which it often won't be, or not in the correct language) below the image instead, but this would lead to a more inconsistent experience and would require making the font size significantly smaller. In any case, it's something we can continue to discuss. Fabrice's preference is to wait for the implementation of structured data support for file description pages, and to then use a multilingual "title" field (similar to the label for Wikidata items). In this case it's doing the right thing -- pulling the only description that has a language tag set. Pulling the surrounding text as the default would likely be worse in far more situations. Media Viewer respects the ?uselang= parameter and will show the description in the desired language if available. You mean like it is here? https://en.wikipedia.org/wiki/File:Prabowo_wapres.jpeg The Wikimedia Foundation mission statement is not "to show broken wikitext to as many eyes as possible". Wikitext is a tool - and ultimately this file metadata should be managed using a more appropriate tool. Whether or not Media Viewer should show _all_ licenses or just highlight the most usable one is a reasonable discussion to have. Right now, it attempts to do the latter. IMO it should probably recommend a default license above the fold, and show all others below the fold. GFDL is a license that requires re-users to include a full printed copy of the text of the license with an image. It's nice that we're offering it for some images in addition to CC-licenses, but except for some very obscure cases, it seems unlikely that any user would actually ever _need_ it. So offering this information in a less prominent fashion seems appropriate. Media Viewer will pick the most suitable available tagged language and render it. It might be useful to identify a non-English language as such to guide viewers -- I'll file an enhancement request for that. As noted previously, because Indonesian is the only language that was tagged, it will pick that one. I've edited the file description to tag English: https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg#mediaviewer… And here it is in Indonesian: https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg?uselang=id#… The fade-out indicates that the text is abbreviated and can be expanded. Yes - we definitely want to offer editing functionality in the viewer down the road. This is directly tied to the work on structured data. When fields like titles are stored as structured metadata, we can potentially make them editable with a simple click action -- even translatable! However, it would be unwise to build such functionality now on top of wikitext. (We should determine whether we really want to expose editing functionality to all readers in the viewer; as we've seen with image annotation on Commons, we'll likely get a lot of nonsense. But we can make that decision when we get there.) It's very unusual to have photographic images repeated in articles in this fashion. MV should probably collapse the sequence, but that's a minor and rare case. The flag only shows up because the template doesn't use the "metadata" or "noviewer" class that exist for the purposes of excluding images from the article sequence. Like other examples, this is a case where clear machine-readable information can only be added incrementally, but when it does get added, it helps us for other purposes as well (e.g. any other process which extracts a sequence of representative images from an article). See: https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer#How_can_I_disab… Media Viewer is not the File: page, intentionally so. It provides a summary view, not all information. We can discuss the inclusion boundaries, but that will always be an ongoing process. See above -- images can be excluded from the MV sequence by tagging them with the "noviewer" or "metadata" CSS class as appropriate. I still don't understand the issue you're describing. There was always a method to obtain a full resolution copy, it just took two clicks instead of one. The main concern was that the full resolution original file may be in a format the browser doesn't know how to render (correctly), or may be extremely large, so the team wanted to avoid selling that as a "zoom" feature. So they ultimately went with "View original file" which is intentionally a bit technical. Long term we'd like to implement a proper zoomviewer-like zoom feature in MV. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

Hey guys, I use MediaViewer, I like it, and I am happy to trust the WMF product team to build stuff. I didn't know about the RFC, but even if I had I would've been unlikely to have participated, because I don't think small opt-in discussions are the best way to do product development -- certainly not at the scale of Wikipedia. I think we should aim on this list to be modest rather than overreaching in terms of what we claim to know, and who we imply we're representing. It's probably best to be clear --both in the mails we write and in our own heads privately-- that what's happening here is a handful of people talking on a mailing list. We can represent our own opinions, and like David Gerard we can talk anecdotally about what our friends tell us. But I don't like it when people here seem to claim to speak on behalf of editors, or users, or readers, or the community. It strikes me as hubristic. Thanks, Sue On 10 Jul 2014 16:13, "MZMcBride" &lt;z(a)mzmcbride.com&gt; wrote:

While I'm not necessarily disagreeing with you, Todd, there were 14,681 users on English Wikipedia alone who had enabled MediaViewer using the Beta Features preference before it became the default. That's a huge number of people who were all using it every time they clicked on an image in the weeks and months beforehand, and every one of them had to make a conscious decision to turn it on. The 64 users who want it disabled as default pale in comparison to the number of people who were actively using it beforehand. I've asked for some better statistical information because I don't think the Limn graphs that have been referred to in the discussion of the RFC are really accurate; it's my understanding that about 1600 registered accounts have opted out of MV in total (this should be a linear graph of the cumulative total, not a "daily number of people who opted out" graph which is what we seem to see now). As well, somewhere in the neighbourhood of 500 "logged out" users a day are disabling it - this needs to be a daily number, not a cumulative one, because logged-out disabling is linked to the individual browser session; those who aren't logged in don't have the chance to set preferences. There are between 4 and 5 *million* clicks on image thumbnails every day on enwiki, with only around 500 of those viewing the images disabling the MediaViewer (excluding logged-in users who have turned it off in their preferences). I suspect that at the end of the day, MediaViewer is going to be more like the switch to Vector skin: there will be plenty of people who choose to disable for reasons that work for them, but the overwhelming majority of users will be entirely fine with the default. It's having nowhere near the impact that VisualEditor had when first enabled as default; in the first 48 hours there were hundreds of "how do you turn this off" queries and complaints about functionality, not to mention pretty much automatic reverting of edits done by IPs because there were so many VE-related problems associated with them. We're not at that level at all here. I agree with John Vandenberg's comments that a clear roadmap and prioritized list of next steps is probably required for MediaViewer. Risker/Anne On 11 July 2014 00:56, Todd Allen &lt;toddmallen(a)gmail.com&gt; wrote:

There's a easy, clearly accessible, one-click option for disabling MediaViewer, Todd. Scroll to the bottom of the screen. Click "disable". Done - it automatically changes your preference. Risker/Anne On 11 July 2014 02:44, Todd Allen &lt;toddmallen(a)gmail.com&gt; wrote:

On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen &lt;toddmallen(a)gmail.com&gt; wrote: up the images without immediately seeing the license requirements and author information. To the contrary, Media Viewer displays the license, author and source as an always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability <http://www.nngroup.com/articles/scrolling-and-attention/> that relatively little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things above it.) Also, many people might not use file pages simply because they are so slow. A famous experiment by Google <http://googleresearch.blogspot.com/2009/06/speed-matters.html> showed that lowering loading speed by 200 ms resulted in 0.3% less interactions (on the English Wikipedia's scale, that would be about 20,000 thumbnail clicks a day). MediaViewer improves image loading time by a full second for the median user.

On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza &lt;gtisza(a)wikimedia.org&gt; wrote: George has made a useful contribution here, in that his points appear to be actually testable. Could the WMF or someone else look into user-testing how the MediaViewer (and variations on it) affects the average reader's perception and consciousness of the licensing information? Thanks, Pharos

I have requested that the Board clarify WMF policy about office actions with regard to the software features of wikis. https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Requ… Pine On Sat, Jul 12, 2014 at 1:05 AM, Pine W &lt;wiki.pine(a)gmail.com&gt; wrote:

On 10/07/2014, Erik Moeller &lt;erik(a)wikimedia.org&gt; wrote: Folks following this discussion, and the problematic "tone" we have seen from some parties, may want to chip in with their views for the English Wikipedia Arbcom to consider: https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Requests/Case#MediaView… Fae -- faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae https://en.wikipedia.org/wiki/User:Fae

Hi Gryllida, As I said on the Arbcom case page, RfCs result in changes to Wikipedia on a regular basis despite having a small numbers of participants in each RfC, and current English Wikipedia policy does not require a minimum number of participants beyond what is necessary to establish consensus. Furthermore, any assertion that the MV RfC was invalid because of its advertising or because it had too few participants would open up countless RfCs to being challenged for the same reason. I believe that the form of the MediaViewer RfC and participation in it were sufficient to establish a legitimate consensus. I am still thinking through the effects that this situation has on the WMF-community relationship. I'm pretty discouraged, and I know others are too. Pine On Sun, Jul 13, 2014 at 2:36 AM, Gryllida &lt;gryllida(a)fastmail.fm&gt; wrote:

I'd agree with Risker more or less wholeheartedly - communication is a multilateral thing not a unilateral thing, and I think we dropped the ball on handling this discussion properly. This certainly isn't new - holding a large-scale community discussion is *hard* and both the community and WMF tend to have problems instigating and managing it - but this could have been a lot better. I've been mostly offwiki for the past few weeks (and had my attention sapped by a different RFC), but I'll also put my hand up and say I should have done something - I normally try and make sure discussions like this get advertised at a suitable level and I was vaguely aware this one was going on. Mea culpa. I've been doing some thinking about this over the past year or so, bubbling away in the back of my mind, after a talk at last Wikimania - would there be any interest/usefulness if I sat down and tried to dump it into a "how to run a large project RFC, and what doesn't work" page somewhere? Andrew. On 14 July 2014 09:04, Risker &lt;risker.wp(a)gmail.com&gt; wrote: -- - Andrew Gray andrew.gray(a)dunelm.org.uk

On 14 July 2014 09:55, Michael Snow &lt;wikipedia(a)frontier.com&gt; wrote: Me too, Andrew. I think we actually do need some sort of checklist or guidance document on how to deal with these sorts of issues. In this particular case, it had the added element of affecting readers possibly even more so than editors, so some thoughts on how to involve readers in discussions that affect their usage of the site would be good. Risker/Anne

On Mon, Jul 14, 2014 at 1:40 AM, Pine W &lt;wiki.pine(a)gmail.com&gt; wrote: The common practice is that the wider the effect of the change called for in an RfC, the larger and more representative the group of participants must be for the result to be binding. So for something like MediaViewer, the pool of people responding should be quite large. In this case, it wasn't.