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:Meinungsbil… [2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&a… [3] https://meta.wikimedia.org/wiki/Stewards_policy [4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Sha… [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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

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:Meinungsbil… [2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&a… [3] https://meta.wikimedia.org/wiki/Stewards_policy [4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Sha… [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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>