[Wikimedia-l] [Wikimedia Announcements] The Signpost -- Volume 10, Issue 33 -- 27 August 2014
Featured content: Cheats at Featured Pictures! http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-27/Featured_content In the media: Plagiarism and vandalism dominate Wikipedia news http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-27/In_the_media News and notes: Media ViewerâWikimedia's emotional roller-coaster http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-27/News_and_notes Traffic report: Viral http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-27/Traffic_report Single page view http://en.wikipedia.org/wiki/Wikipedia:Signpost/Single PDF version http://en.wikipedia.org/wiki/Book:Wikipedia_Signpost/2014-08-27 https://www.facebook.com/wikisignpost / https://twitter.com/wikisignpost -- Wikipedia Signpost Staff http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost ___ Please note: all replies sent to this mailing list will be immediately directed to Wikimedia-l, the public mailing list of the Wikimedia community. For more information about Wikimedia-l: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ___ WikimediaAnnounce-l mailing list wikimediaannounc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l ___ 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
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Hi all, Thank you Erik for your mail. It shows that the WMF is willing to discuss rather than to impose its solution. I am really shocked that the dispute reaches that level of confrontation, and although some community members have a hard stance, this is largely due to WMF actions, specially the creation of the superprotect right. This is the worst possible step the WMF could make to find a solution for this issue. Initially I was quite neutral about the MediaWiever, but I became increasingly skeptical. IMO it is hardly a priority, even for readers. Even if I am a long term contributor of Wikimedia projects, I am also a heavy reader of Wikipedia. I think that if a feature is refused in masse for the most active contributors, there is something wrong either in the feature itself, or in the way it is proposed to the projects. The WMF can certainly bring useful new additions in term of software development, but the implementation has to be done in a partnership with volunteer contributors. I cannot understand that the WMF in spite of its multi-million dollars budget is not able to convince volunteer contributors that the new feature is beneficial to the projects, either because it is technically very good, or that even with some shortcomings, it would improve the reading experience. I am quite willing to test beta software, and I think there is no urgency to impose the MediaWiever now to everybody. I could be done after some time, when all issues have been sorted out. In term of media management, the most urgent and important thing is to fix the UploadWizard. Viewing images with Mediawiki may not be optimal, but it is not broken. The UploadWizard is broken. Regards, Yann 2014-08-20 0:42 GMT+05:30 Erik Moeller e...@wikimedia.org: Hi folks, This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html .. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward. I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it. I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page. Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a better hack to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint. 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. We’ve been listening to feedback, and we’ve come to the following conclusions: - 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. - As the WMF, we need to improve the process for managing changes that impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users. - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Legal position: I have seen it claimed by legal and repeated here by Erik that the reasonableness criteria means that we do not have to worry about the CCBYSA-3.0 clause that says all copyright holders need equal attribution. This is simply not so: The credit required by this Section 4(c) may be implemented *in any reasonable manner; provided, however, that *in the case of a Adaptation or Collection,* at a minimum such credit will appear*, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and* in a manner at least as prominent as the credits for the other contributing authors*. There is no wriggle room here. * provided however that* means the following is compulsory, and not subject to the lenience of the previous phraseology. On 31 August 2014 16:59, Yann Forget yan...@gmail.com wrote: Hi all, Thank you Erik for your mail. It shows that the WMF is willing to discuss rather than to impose its solution. I am really shocked that the dispute reaches that level of confrontation, and although some community members have a hard stance, this is largely due to WMF actions, specially the creation of the superprotect right. This is the worst possible step the WMF could make to find a solution for this issue. Initially I was quite neutral about the MediaWiever, but I became increasingly skeptical. IMO it is hardly a priority, even for readers. Even if I am a long term contributor of Wikimedia projects, I am also a heavy reader of Wikipedia. I think that if a feature is refused in masse for the most active contributors, there is something wrong either in the feature itself, or in the way it is proposed to the projects. The WMF can certainly bring useful new additions in term of software development, but the implementation has to be done in a partnership with volunteer contributors. I cannot understand that the WMF in spite of its multi-million dollars budget is not able to convince volunteer contributors that the new feature is beneficial to the projects, either because it is technically very good, or that even with some shortcomings, it would improve the reading experience. I am quite willing to test beta software, and I think there is no urgency to impose the MediaWiever now to everybody. I could be done after some time, when all issues have been sorted out. In term of media management, the most urgent and important thing is to fix the UploadWizard. Viewing images with Mediawiki may not be optimal, but it is not broken. The UploadWizard is broken. Regards, Yann 2014-08-20 0:42 GMT+05:30 Erik Moeller e...@wikimedia.org: Hi folks, This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html .. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward. I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it. I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page. Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a better hack to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint. 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. We’ve been listening to feedback, and we’ve come to the following conclusions: - 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
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue. WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis. Pine ___ 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
Re: [Wikimedia-l] Understading power in the Wikimedia context
Hey, interesting take - will think on this. If we accept that there might be a duality, the points made in the video could help. Perhaps it might be intersting to look into this as a possible solution (see Council of Stellar Management - CCP/EVE Online) and get over the bi-polar phase (simplification: anarchistic with attributes of a collective on the one side to use your characterisation and legal entities on the other) to a truly multi-polar community with equal partners... And it's important to get the community integrated in a more formal way into decision making processes... something like the ChapterDialogue by Nicole, the voting idea for the wikimedia engineering team by gryllida or the steering group for software dev proposed by Anders might be a great tool for regular feedback and participation (?!) - interesting times. That said, we are again at the duality that Gerard said does not exist. His last post detailing his thoughts on the community are rightlycharacterising the volunteer part of the community as an ever-changing ad-hoc group while not taking into account the form of the WMF and the organisational legal forms of local chapters as hierarchically structured legal entities with charters clearly stating a pre-defined goal (etc). This weakens the characterisation of the wikipedia family in it's entity as a collective (changes of objectives common in collectives are either not possible or too wide to be achievable). Further, the legal documents of the local legal entities also have to state a clear purpose, voting proceedings and more, which might be used to find out what people want and what they would agree to, if community voting by users does not have enough representational force in his or Magnus' opinion (Magnus' argument being that the numbers are too low to truly represent the community). These points should be adressed or at least defined e.g. what a possible representative majority of the users should be (magnus uses edits for example). Cheers, gh Thursday, August 28, 2014, 9:28:02 PM, you wrote: Hi all, I just saw this nice video on Why ordinary people need to understand power http://www.ted.com/talks/eric_liu_why_ordinary_people_need_to_understand_power#_=_, by Eric Liu, from Citizen University http://www.citizenuniversity.us/. Although my personal interest goes beyond the wiki-world scope, I'd like to recommend this video for it covers some important subjects that might be related to some tensions we see so often in the Wikimedia movement (WMF vs. volunteers, Chapters vs. WMF, online vs offline volunteers, lack of leadership at some crucial moments and places, tirany of the structurelessness https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness etc.). Thoughts welcome. Tom -- Best regards, ;mailto:b...@gmx.at ___ 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
