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: . while i
thought originally "who cares", i do think now beeing sorry is
expressed best by gesture not words.


On Tue, Aug 19, 2014 at 9:37 PM, Martin Rulsch
<> 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 <>:
>> Hi folks,
>> This is a response to Martin's note here:
>> .. 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:
>> 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:
>> 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]
>> [2]
>> [3]
>> [4]
>> [5]
>> --
>> Erik Möller
>> VP of Engineering and Product Development, Wikimedia Foundation
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> Unsubscribe:,
>> <>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> Unsubscribe:, 
> <>

Wikimedia-l mailing list, guidelines at:

Reply via email to