Erik Moeller wrote: >I am -- genuinely -- sorry that this escalation occurred. We would >have preferred to avoid it.
I think making amends requires cleaning up the mess you've made on the German Wikipedia and throughout the Wikimedia ecosystem. I don't think many German Wikipedians or other Wikimedians will be willing to accept your apology until super-protection is disabled. I hope you've been following <https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz>. >Our processes clearly need to be improved to avoid these situations in >the future. We recognize that simply rejecting a community request >rather than resolving a conflict together is not the right answer. For sure. Thank you for this write-up. But I continue to get the sense that the Wikimedia Foundation is looking for ways to ask (and re-ask) "how much would you like to pay for this horse?" and the editing community is responding with "no thank you, but we would perhaps consider a car." In the specific case, I think there's a common interest in improving file description pages. Wikimedia readers and editors would certainly benefit, as would MediaWiki users. File description pages could certainly use design love, but rather than properly integrating with and improving MediaWiki, we ended up with some JavaScript slapped on top via an extension. There's a fundamental design flaw here, isn't there? * The situation without MediaViewer: user clicks on an image, all the other content goes away, user is presented with a larger version of the image, its history, editing capability, and user can click the browser back button to return to the other content. * The situation with MediaViewer: user clicks on an image, all the other content goes away, user is presented with a larger version of the image, no history or editing capability, and user can click the browser back button to return to the other content. This is not really an improvement. Finite design and development resources are being invested in new tools and what's the end result? And of course MediaViewer came with an even higher cost given subsequent events. In the general case, I think there are plenty of multimedia-related areas in which Commoners and others would love design and development resources: improved search (by file type, file size, color, content, etc.), an in-browser SVG editor, an in-browser rasterized photo editor (even basic support for cropping or rotating an image), the ability to easily rename a category, and so on. I'm not sure why MediaViewer was worth the steep cost. But more to the point, I think it would be helpful if the Wikimedia Foundation could articulate a clear message about why these types of "reader-focused" features are a worthwhile investment. I talk to a lot of people about Wikipedia and the one complaint I _never_ hear is that Wikipedia has a readership problem. It's a fact that the Wikimedia Foundation typically embraces at every opportunity ("top-five Web site"). When I see reader-focused features such as ArticleFeedback and MoodBar and MediaViewer being given substantial priority, urgency, and visibility, I wonder what the rationale is. These types of features almost certainly aren't attracting more readers and anecdotally they seem to be damaging editors' relationships with the projects. Not exactly a great investment. Despite the events of the past few weeks, I continue to trust you and I'm hopeful about the path forward you and Lila have laid out regarding community involvement in product development. Though it leads me to wonder what the status is for hiring a VP of Engineering so that you can focus exclusively on being the VP of Product Development. MZMcBride _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
