thank you erik, and martin for this! currently more than 600 persons express that this story should be resolved by reverting to the state before it started: https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz . while i thought originally "who cares", i do think now beeing sorry is expressed best by gesture not words.
rupert On Tue, Aug 19, 2014 at 9:37 PM, Martin Rulsch <martin.rul...@wikimedia.de> wrote: > Thank you, Erik, for your clarifications and understanding. Personally, I > hope that most anger will calm down now although not everyone will agree > with everything that was said or done (e.g. ignoring RfCs under some > conditions, using superprotect instead of counting on local procedures to > stop wheel warring) and we all can concentrate again on “working together > to make Wikimedia projects are more welcome place for readers, authors, and > anyone”. As this can only be done with mutual discussions, I'm looking > forward to the intensified inclusion of the communities for future software > developents as announced. Whether stewards can help here, I cannot tell, > but I would abstain myself from getting involved for obvious reasons. > > Cheers, > Martin > > > 2014-08-19 21:12 GMT+02:00 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 resolution process. The goal would be to make a final, >> cross-wiki determination regarding this specific feature, in >> partnership with the community, within at most 90 days. >> >> With regard to the German Wikipedia situation, we’d like to know if >> stewards want to at all be involved in this process: In a situation >> like this, it can be helpful to have a third party support the >> conversation. Stewards are accountable to "valid community consensus >> within the bounds of the Foundation's goals" [3], which seems to be >> precisely the intersection of concerns at issue here. We would like to >> suggest an IRC meeting with stewards ASAP to talk about the specific >> question of stewards’ involvement, if any. If stewards prefer not to >> be involved, we understand, but it's probably a good idea to have a >> sync-up conversation regardless. >> >> I hope we can move forward in good faith from here, and find better >> ways to work together. As Lila has expressed, we believe there is a >> need for a clear understanding of our role. It is as follows: >> >> Managing software development, site configuration and deployment is a >> core WMF responsibility. The community leads in the development of >> content; the Wikimedia Foundation leads in the development of >> technology. >> >> Because these processes are deeply interdependent, we need to develop >> better protocols for timely feedback and resolution of disagreements. >> At the same time Lila’s and the Board’s statements make it very clear >> that the WMF will not accept RfCs or votes as the sole determining >> factor in global software deployments. >> >> This means that technology and UX changes should not be decided by >> vote or poll and then disabled at-will: where we disagree, we need to >> talk to each other (and yes, that means a more judicious application >> of RESOLVED WONTFIX on our end, as well!). We need to ensure a >> process where the community voice is heard earlier at critical >> junctions in the product development. All of this is consistent with >> the principle of "shared power" articulated in the Guiding Principles >> [4] approved by the Board of Trustees. >> >> At the same time, as noted above and earlier, the superprotection >> feature should be replaced with a better mechanism for code review and >> deployment in the MediaWiki: namespace. This is discussed in [5] and >> ideas and suggestions are welcome. Let’s be upfront about control >> structures for production changes to avoid misunderstandings and >> ambiguity in the future. >> >> We are exploring options on how to improve dispute resolution >> mechanisms -- whether it’s e.g. a standing working group or a better >> protocol for responding to RfCs and engaging in discussions. We've >> started a brainstorming page, here, which we hope will usefully inform >> the process of conflict resolution regarding German Wikipedia, as >> well, so we can arrive at a more concrete conflict resolution process >> soon. Your thoughts/suggestions are welcome, so we can (in NPOV style) >> look at different possibilities (e.g. workgroups, committees, votes, >> surveys) that have been discussed in the past: >> >> https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas >> >> We’re absolutely not saying that WMF simply wants to be able to >> enforce its decisions: we completely understand there need to be >> mechanisms for the community to influence decisions and outcomes at >> all stages of the development and release of software. We need to >> arrive at this process together. >> >> Again, we are sorry that this escalation occurred - and we hope we can >> move forward constructively from here. >> >> Sincerely, >> >> Erik >> >> >> [1] >> https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014 >> >> [2] >> https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&diff=132938244&oldid=132935469 >> >> [3] https://meta.wikimedia.org/wiki/Stewards_policy >> >> [4] >> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shared_power >> >> [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445 >> >> >> -- >> Erik Möller >> VP of Engineering and Product Development, Wikimedia Foundation >> >> _______________________________________________ >> 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> > _______________________________________________ > 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> _______________________________________________ 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>
