I have long held that the Wikimedia Foundation’s flawed approach to software development and deployment, culminating in the sudden release of the draconian “superprotect” software feature last year, would be the central issue in this year’s election for three of the organization’s 10 Trustees. As I reported earlier, all three incumbent candidates were in fact voted out, which I interpret as a sign that the international community of Wikipedia volunteers will not tolerate such a ham-handed approach to governance.
Today, Andrew Lih published an op-ed piece in the New York Times: Can Wikipedia Survive? Lih, a longtime Wikipedian and author of The Wikipedia Revolution, highlighted superprotect as a significant issue in the election, and stated:
The real challenges for Wikipedia are to resolve the governance disputes — the tensions among foundation employees, longtime editors trying to protect their prerogatives, and new volunteers trying to break in — and to design a mobile-oriented editing environment.
The nature of the election Q-and-A pages (in which 20 candidates addressed 39 questions) makes it rather impenetrable for those wishing to evaluate the themes. A few people have contended that superprotect was not such a significant issue in the election; but along with myself and Andrew Lih, a number of respected colleagues have agreed that it is, in both public and private venues.
In order to better inform that question, I am presenting below the answers all candidates gave to the question about superprotect. (The question and all answers are available under the CC BY-SA 3.0 license.) I have highlighted the answers of the three successful candidates in green, and the answers of the three unsuccessful incumbents in red. I have also included my own answer at the bottom (I had answered during my brief candidacy, which I withdrew before voting began). Readers may also be interested in my analysis of all candidates, in which I focused on this question more than the others. See the question and answers below the fold:
Use of Superprotect and respect for community consensus
|Please explain whether you believe it was the right thing to do for the WMF to disregard community consensus on the English and German Wikipedias regarding MediaViewer, and to forcibly prevent the German Wikipedia community from disabling MediaViewer by implementing Superprotect. If you are a current Board member, then please explain how your actions on the Board in supporting WMF’s decision were consistent with your duties to support and represent the community. —Pine✉22:30, 2 May 2015 (UTC)|
Houcemeddine Turki (Csisc)
I think that the issue is more than controversial. Anyone can tell you that working in a wiki should involve respect to the global community decisions and thoughts. You cannot add something within a wiki that is refused by the global community… However, wikis are regulated by Wikimedia Foundation and this regulation involve some adjustments to the policy of the projects… If a project is affiliated under the Wikimedia Foundation, its members should respect any adjustments and regulations to the policy of the considered wiki. We cannot adopt an adjustment for some versions and neglect it for other versions. But, I think that major regulations should be based on a consensus on MetaWiki in order to avoid such matters. We can even do a Wikipedia Council constituted of the admins of all Wikipedias who discuss and adopt such consensus… We can also do this for Wiktionary and other projects… —Csisc (talk) 09:01, 4 May 2015 (UTC)
Sailesh Patnaik (Saileshpat)
I think Superprotect is a bad idea and even conterversial too. (Why?) Without any information of the community, WMF employees can not implement such decission. Whereas, there should be detailed & well planned guidelines for implementing Superprotect, and community need to get informed about it.– Sailesh Patnaik(Talk2Me|Contribs) 11:40, 16 May 2015 (UTC)
Dariusz Jemielniak (Pundit)
TL;DR version: I am against Superprotect.Longer: I’ve briefly addressed this issue in my previous answer. While I believe that the community consensus sometimes may need to be overthrown (I can imagine a situation in which one community makes a decision in stark contrast to our values as a movement), I believe that we lack procedures, which would allow some form of arbitration when a given community disagrees with the WMF’s decision. Especially in cases where software implementation has to go as scheduled (not to be considered a failure), and an under-baked product is released, or when a tool concept is generally liked by some communities, but disliked by the others, there should be a way to seek a non-forcible solution (obviously, in the described case the community consultations should have been conducted much earlier). The WMF may be very often right in its actions and general strategic oversight. Still, I think that especially in such cases, when communities disagree with a certain tool, it should not be WMF’s prerogative to make the final decision. As suggested previously, I believe that ultimately a decision should be up to the Board, but the Board should consider such cases only after receiving an opinion from a community-driven committee, similar to the FDC or ombudsman commission (I know, another committee… and yet, I don’t think it is realistic to assume that the Board will convene an emergency online meeting to consider ALL cases, there has to be a social filter somewhere). Pundit(talk) 06:35, 3 May 2015 (UTC)
- @Pundit:: You still need to actually answer @Pine’s question: Please explain whether you believe it was the right thing to do for the WMF to disregard community consensus on the English and German Wikipedias regarding MediaViewer, and to forcibly prevent the German Wikipedia community from disabling MediaViewer by implementing Superprotect. Thanks, odder (talk) 06:47, 3 May 2015 (UTC)
- Odder:: Hi Odder, apologies for being unclear, I’ve assumed I made my point explicit. I believe it was not the right thing to do. I think that irrespective of arguments and reasons, and even if the WMF was 100% right in their approach to MediaViewer (which I’m not certain they were, as communities differ and may have different needs, and also may sometimes have better, or at least alternative insight into their readers’ preferences, although may also sometimes just be wrong – veteran Wikimedians rarely can imagine an average user or reader’s perception), the whole process was flawed. It lacked proper community consultations, as well as proper dispute resolution methods. Both can and should be introduced in the future and it is up to the Board to do so. Pundit (talk) 08:23, 3 May 2015 (UTC) (added TL;DR version to avoid further confusion) Pundit (talk) 08:25, 6 May 2015 (UTC)
- Added: After reading Maria’s and Phoebe’s replies, in which they both state that SuperProtect was/is not the Board’s matter, I want to strongly emphasize that I disagree with this viewpoint. SuperProtect is not just some trifle UI change, it is a technological tool that goes against our culture, tradition, and values. Disrespecting community’s consensus cannot be used to roll out virtually not consulted changes of wiki-mechanisms, that a given community disagrees with. This is entirely different than not giving a priority to some whim or undesirable change to the mechanism a community may demand. I think that SUperProtect was definitely something the Board should be consulted about, and if it wasn’t, then something the Board should spend some time discussing and clarifying, rather than treating as something not pertaining to its mandate. Pundit (talk) 08:30, 10 May 2015 (UTC)
Mohamed Ouda (Mohamed Ouda)
no response yet.
Josh Lim (Sky Harbor)
We could argue all day on whether superprotect is justified. On my part, I think it isn’t, and it’s reprehensible that we’ve gotten ourselves into a situation where communities have to be strong-armed into accepting the way of the Foundation where before this was unnecessary. But let’s face it: it’s there. We have to mitigate then the risk of it being used again and ensure that the community has the ability to maintain oversight over the Foundation’s use of that function.
This is a prime example of the disconnect that exists between communities and the Foundation. We need to rebuild those connections, and the only way we can do that is if we’re able to talk to one another as equals. The entire Media Viewer fiasco has destroyed that equal footing, and the only way we can make it right is to both commit to extensive community consultation processes before rolling out features, and curtailing the use of superprotect only to scenarios where there is broad consensus warranting its use, if not removing it entirely. —Sky Harbor (talk) 03:57, 6 May 2015 (UTC)
David Conway (Smerus)
My understanding is that Superprotect has been invoked only once, to intervene in a local war between administrators. It is not unreasonable for the Foundation to have a supreme sanction in reserve, but the conditions in which it can be invoked and exercised need to be clearly defined, understood and agreed between the different Wiki communities. It should be the responsibility of the Foundation board to ensure that such a consensus is developed. —Smerus (talk) 17:13, 6 May 2015 (UTC)
Francis Kaswahili Kaguna (Francis Kaswahili)
Hello, Pine✉, as well as you know that Wikimedia is a gateway to user enabling them to post or viewing, commenting and discussing conscientiously, and according to the question posted you optioned to believe or mot, I can’t to ignore your point but let me tell you one thing Pine✉ The Wikimedia has a millions of user with different calibers. The important here is now for those who seek positions as board of trustees members to undertake their responsibility with accountability, as I have already explained on my previous answers if I get a luck of being elected as a board member I promise to collaborate with my colleges on the change for better future. Francis Kaswahili talk, 19:46, 04 May 2015 (UTC)
Cristian Consonni (CristianCantoro)
I think that superprotect is a bad idea and it should have not be implemented, I think that the projects have already shown in several ways that you don’t need that kind of superpowers to manage them. More than that, I am much more concerned about why and how we arrived at a situation where some WMF employees felt it was necessary to implement Superprotect. Why there wasn’t enough communication with the community? Was this reaction from the community completely unforeseeable? I remember that a result of that discussion was putting in place some mechanism that would increase the community feedback (at earlier stages of development). I think that this would help the community and also the developers.
Peter Gallert (Pgallert)
The Board is of course not micromanaging WMF’s daily affairs. I very much assume that the Board discussed these matters after the horse had already bolted. That said, it is never the right thing to do for the WMF to ignore community consensus. Such actions are at the core of the rift between WMF, communities, and Chapters that I alluded to in my candidate statement. I am concerned that an action like the creation of the
superprotect right seems to have happened ad hoc, without seeking much input from either the community or the Board. I am further concerned that none of the responsible WMF employees had an inkling about what damage the creation of such user right and its immediate application on a contested page would do to the relationship of the Foundation and the editing communities. Whatever the merits of MediaViewer and other recent software development projects, if WMF cannot convince the community of their usefulness it needs to engage in more dialogue rather than forcing them down the volunteers’ throats. I believe the Board should have made a clear statement in this regard.
- @Pgallert: Can you answer @Pine‘s question specifically by providing an unambiguous answer rather than dealing in generalities, ie. state whether you believe it was the right thing to do for the WMF to disregard community consensus on the English and German Wikipedias regarding MediaViewer, and to forcibly prevent the German Wikipedia community from disabling MediaViewer by implementing Superprotect? As a follow-up to your answer, the Board – on which @Raystormand @Phoebe were sat at the time – published a pretty clear statement supporting that decision, so perhaps knowing this could help. odder (talk) 15:35, 3 May 2015 (UTC)
- Sorry to have disappointed you with my answer, I believed it was sufficiently clear. Here it is: I do not believe community consensus should have been disregarded in this or any other manner. The German wp community should not have been prevented from disabling MediaViewer. The block of Eric Möller was entirely justified. Superprotect should not have been created in this context, and not have been used for this purpose. And I would not have endorsed the Board statement.
- Do you really belive, Superprotect was one of WMF’s daily affairs? Really? Such a slap in the face of the Volunteers by those who live from the Volunteers work?Marcus Cyron (talk) 17:08, 11 May 2015 (UTC)
- No, Marcus Cyron. What I wanted to say–apologies if I didn’t say it clear enough—is this: Sometimes a small technical workaround is applied to solve an issue. The Board should never be involved in that, those are the daily affairs. In this case, the “workaround” could easily have been foreseen to be the shit that is about to hit the fan. It should not have been done that way, with or without Board involvement. That the Board ex post facto approved of it is all the worse and one of the reasons you find my nomination statement here. —Pgallert (talk) 22:15, 18 May 2015 (UTC)
María Sefidari (Raystorm)
Hi Pine. I think most people are aware that operational decisions such as adding an additional protection level in the Mediawiki namespace are not Board decisions. The Board does not go into this kind of detail, and so had no role to play in the decision of implementing superprotect. After establishing that, I think the timing was bad. This all happened when Wikimania was ending, while we were celebrating our new ED who just days before at the Board meeting had been talking about how her vision was to involve the community at each step of product developments, communicating sooner, prioritizing smarter, testing more. Something I believe everyone would endorse. Then this happens. It is true that MediaViewer was released without such a level of noise in the other projects, and there was mention that in German Wikipedia some users didn’t get a chance to test MediaViewer because a link to Beta features was previously locally disabled by an admin. But still. Product development cannot be a battleground between staff and community members, this is not sustainable across all our projects. Today, a new editor in Spanish Wikipedia has to activate Visual Editor in their Preferences, because veteran editors find it preferable to do that than to have it by default and let people who don’t want to use it opt-out. I use this as an example for the line of thinking within our movement that some communities have become so change-resistant and innovation-averse that they will fight any Beta features which are released. We now have a new Community Engagement department which will hopefully be able to develop an innovative relationship between communities and WMF. At least one of mutual respect and empathy, where the most important thing is not to be right or wrong. I don’t want it ever to be the right thing to do for the WMF to disregard community consensus. Neither the WMF is right all the time, nor the communities are right all the time. Does anyone think MV needed to be the line in the sand for either the WMF or communities? But there are community members with strong interests to promote a confrontational relationship with the WMF, as if only they cared about the projects. I think that’s exactly the wrong kind of approach and the kind of small thinking that can make the projects stay stuck in 2006 while the rest of the internet is thinking about 2020 and the next three billion users. Superprotect will go away, it has to, because forcing features on communities like on German Wikipedia is not okay, it’s battleground mentality, and the ED has been working really hard to improve product development including the testing and release processes so that this never happens again, and I hope succeeding at this will make superprotect go away (again, it is not the Board role to micromanage at such a level of keep/remove an additional protection level in Mediawiki).
As for the second question, remember that (a) there’s only three community seats in a Board of ten. There probably should be more, I for one think so. (b) Also, I feel it important to mention that the assertion that the community-elected members represent the community (or that chapter-selected seats represent the chapters, for that matter) is inaccurate. Board members represent the WMF when they join the Board, this should not be a surprising statement. The community elected members, among other things, can try (and do try) to inject a community perspective into Board decisions, statements, and thinking (see (a) again). At the time of superprotect we were available & willing to interact with concerned community members. Generally speaking, at least for the Board incumbents you have the advantage of checking how we have voted in Board resolutions for the last two years since they are publicly available, and decide in your opinion if we support the projects, communities and WMF. I encourage you to do so.
- @Raystorm: I would like to ask a follow up question. You claim that the Board had no role to play in the decision of implementing superprotect; however, Erik Moeller has admitted publicly that the Board were briefed on the intention to implement superprotect ahead of time. Can you confirm whether this is true, ie. whether the Board had known about the plans to enable superprotect before it was enabled and used on the German Wikipedia? Thanks, odder (talk) 19:59, 9 May 2015 (UTC)
- The Board does not go into this kind of detail – and THIS is the problem. For what we need the board, if they not able or willing to do anything elso then cruising about board issues? So, I say, we don’t need a board. It should control and lead the WMF. But as long such “details” are not interesting for the board, why do you think, the board should be longer interesting for us volunteers? Marcus Cyron (talk) 17:12, 11 May 2015 (UTC)
- Hey there. Sorry, between the Q3 Board meeting, the FDC meeting and the Wikimedia Conference all happening simultaneously, time has been scarce. So, Odder, I think SJ has given a good reply. Marcus, the Board cannot be comprised of ten executive directors: being a Board member is different from being an ED. The Board oversees the ED and the organization, it is a safety mechanism. And we care about volunteers: all of us are volunteers, and most of us are contributors to the projects. Raystorm (talk) 07:52, 22 May 2015 (UTC)
Phoebe Ayers (Phoebe)
This is a loaded question, and no wonder: it’s a loaded issue. On the one hand, it’s surprising that this incident did get so hot: at face value it was a revert war in a project over a non-critical (but potentially helpful, though that’s disputed) UI change. Not pleasant, but not exactly a life-or-death matter. On the other hand, though, it’s not surprising at all: the dispute over what say a particular editor or community (or community subset) should have over the project interface, and whether the WMF as website operator gets final say on how the project software works, raises questions of community autonomy, how decisions are made, the relationship of editors to software design and vice-versa, and the role of the WMF in setting the appearance of each of the projects. These are big questions.
To be clear, this specific case is not a Board matter; we don’t monitor what changes are rolled out when or what specific changes are made to MediaWiki, nor should we; this is not our purview. It arguably *became* a Board matter when we spent time discussing it, when people asked us what we thought, when philosophical questions were raised, and when it generally caused community uproar, but that does not mean we are going to become the final arbitrators of some sort in this case. But since you asked what I personally thought…
In a nutshell: I support the creation of superprotect as a tool. I wish that it hadn’t been used in this case, however.
To elaborate: I support the creation of the tool because the ability to lock which software version a project is running is useful in a world where we’ve got 280+ independent websites all running *ever so slightly* different and customized versions of MediaWiki, with all the resulting complexities, dependencies and conflicts that creates. We can (and must) develop some basic guidance about when such a protection level might be used; hopefully not often, hopefully not in contentious situations. It’s useful because of the larger picture: we need to and will change lots of aspects of MediaWiki in the coming years, everything from making citing sources easier to adding discussion features. And consistency across projects is important, because having projects with a consistent interface and having new tools available to all editors is important. There is an imbalance between projects currently, with some smaller projects in particular getting shortchanged, and some larger projects unable to come to consensus on new tools (and editors on those projects sometimes unable to even access features, as happened on de.wp).
I wish superprotect hadn’t been used in this case, though, because the resulting drama obscured a central point, which is that WMF, as operator of MediaWiki and the projects, must be able to make software changes — but, to be supportive of the projects and editor community, those changes must be well-done and useful improvements. That is our social contract.
I want to see our software rollouts be smooth enough such that arguments like this won’t happen — that individuals won’t feel the need to revert new features to protect a vision of how the wiki looks or operates. We must therefore improve how we develop and deploy software — especially since we need to make a lot of software changes in the near future, to fulfill our other goals and meet our current challenges. The WMF Board has given strong guidance on this point and the Board and ED are in agreement, and the WMF is currently focusing on this; we’ve already made a lot of progress. And, for this specific case, we’ve also addressed many of the problems that were raised with MediaViewer; it’s better than it was when all this happened. And that, too, is important; addressing bugs and rolling back software changes that cause problems should not be a dramatic matter, but simply part of daily work.
Denny Vrandečić (Denny)
Implementing superprotect in order to forcibly prevent a community from acting on their consensus was a mistake. Still not having rules on how Superprotect can be used is another mistake. We can and should remedy the latter.
It is often claimed that the Wikimedia communities are averse to change or stuck in the past. While introducing Wikidata, I have to say that this is not the experience I have made when introducing Wikidata. Actually, I am afraid that the preconception of regarding the community as conservative and change-resistance is actually a possible factor in leading to not properly listening to them. But we have to listen to them. The German contributors did not oppose MediaViewer merely because it was new, but because it had some major flaws (such as licensing issues). It sometimes can be hard to recognize such valid concerns amongst the sea of arguments which are less valid, but if there is such a massive pushback, then there is often a valid underlying concern in it.
Wikidata was not perfect, and still is not, and there are many, many valid concerns with regards to it. And yet, the project was designed and developed in a way that allows to be helpful nevertheless, while the existing problems are gradually being resolved. We have listened in particular to the critical voices, and have tried to find the underlying reasons in those that might need to require changes in what we do. And this helped make not only Wikidata, but the Wikimedia projects as a whole better.
The experience I have made with Wikidata, and the skillset I have demonstrated with it, this is what I think might be my most important contribution to the Board in case I get elected. I would obviously not control the day-to-day work of the WMF, but I would provide support and advice in planning, evaluating and performing deployment of new features to the Wikimedia projects. There were alternatives to handling the situation around MediaViewer’s deployment that did not involve the implementation of Superprotect. It’s not MediaViewer which was fundamentally broken – it was Superprotect as an answer to the reaction of the community which was, and is, deeply broken. If you consider how big the change is that MediaViewer brought, and compare it to how big the change is that Wikidata embodies, you will see that Wikidata is a much larger change – and yet, it never came to a situation which was comparably heated.
I think that the Foundation has not only to continue introducing changes to our projects, but should even increase the speed and the boldness of these changes. I think MediaViewer as a concept is a step in the right direction. I absolutely think that VisualEditor is an important step in the right direction. And there are many, many more things that need to happen. But all these deployments have to be done with care and proper communication (which doesn’t just mean ‘inform the communities early enough’, but actually means ‘discuss it with the communities and listen to their concerns’). I think that a Board member with a deep understanding of our communities, the technical infrastructure of Wikimedia, and the different software components that power our site, can be a huge benefit for communicating between the Board and the Foundation, for exercising the duty to oversee the Foundation, and for providing the Foundation with help towards deploying the necessary changes to our projects. I am confident to be the right person to fulfill this role.
Ali Haidar Khan (Tonmoy) (Ali Haidar Khan)
I think it was not the right thing to implement the ‘Superprotect’ and the way it was implemented & exercised was a mess. There are two elements in it: 1) creation of ‘Superprotect’ as a special right above the existing user rights of Wikimedia project and 2) use of this feature by WMF. I don’t like the idea of Superprotect. There may be some arguments in favor of Superprotect where it can be argued that it is sometimes beneficial to overturn a community consensus for the greater benefit of the movement, but it can be contested in many front at the same time. In general, however, I believe it is very important to have enough community consultation before implementation of any such sensitive feature and community feedback should take place right from the planning stage. In ideal situation, there should be a discussion with the global community and WMF should convince the community members regarding the usefulness of any such new feature. In addition, there should be detailed & well planned guidelines for the use of such features incorporating the community feedback so that everyone has a clear understanding of what do and expect. Unfortunately, no such thing was done in this case.
Nisar Ahmed Syed (అహ్మద్ నిసార్)
Consensus of the global community should be taken into consideration. To bring the consensus, community consultation on the issues are to be taken place. Both the WMF and the communities should see that the features like superprotect is really bring what Wikipedia aims to. Ahmed Nisar (talk) 07:32, 13 May 2015 (UTC)
James Heilman (Doc James)
Superprotect is a bad idea. It should be exceedingly uncommon for the WMF to take actions without and against community consensus. The WMF should work to get community support and maintain community involve throughout the entire software development process similar to what is required from those within the community who propose new changes. If this would have been done it likely would have prevented this issue from arising. Rollout of new technology generally needs to be done slowly and with plenty of discussion. Additionally listening to the many great ideas coming from the editor community will substantially increase the chances that development time will not be wasted on non supported efforts. Doc James (talk · contribs · email) 14:10, 5 May 2015 (UTC)
Tim Davenport (Carrite)
I commend fellow candidate Pete Forsyth for his activism on the issue of Super Protection and urge everyone to note his statement on the matter below.
Super Protection as put into use against the German Wikipedia was a symptom of an illness — a growing apart of the paid professional staff of WMF in San Francisco from the volunteers around the world who actually build and maintain the encyclopedia. Software development was undertaken with little care or concern for the actual needs of the volunteers at the core of The Project. The Visual Editor debacle led to escalation with the unilateral launch of MediaViewer, exacerbated by a “screw you, we know what’s best” attitude emanating from San Francisco.
I think, I hope, I believe, I presume that Executive Director Tretikov has identified this fundamental error in WMF’s software development process and that changes moving forward will not require either the “nuclear option” of community hacking of the software or of “super protecting” such alterations. I was in solidarity with German WP in their assertion of right to accept or reject changes of the fundamental editing environment. I did believe that the controversy was a tad overblown and that Media Viewer was more or less an improvement and a workable piece of gear at the time of launch — certainly fixed now. Still, it is our duty as community-elected board members to represent our constituents in such matters, and to make sure that San Francisco does not attempt to foist faulty, broken, defective software upon the core editing community merely to “meet a timetable” or “show results” for expenditure of donor funds. Carrite (talk) 21:58, 7 May 2015 (UTC)
Samuel Klein (Sj)
It is never healthy to ignore strong community consensus – a rare and useful occurrence. We should build a movement that welcomes this wherever it occurs and learns from it.
‘Superprotect’ was a poor idea, in name and concept. It opposed our wiki values, distracted the projects, and did not solve any pressing problem. It will likely never again by used. In the end, MediaViewer was improved and the deployment process was fixed, but it took longer and was more painful thanks to this super-intervention.
The idea was mentioned to the Board as a possibility, a few days before it happened, as a way of responding to technical wheel wars. I advised strongly against it, noting that it was unnecessary and out of touch with our wiki norms. But not everyone agreed, and this was an implementation detail, not up for line-item approval.
After it was done, many more detailed concerns were raised with the ED. The Board discussed ways to avoid any future disastrous deployments, and to preserve our community values while experimenting with tools, in two following Board meetings. But a Board should not micromanage staff: they must be free to make their own plans and decisions, take responsibility for the results, make and fix their own mistakes. Like the fundamental problem with ‘superprotection’ itself: forcing an unwanted change rarely works; far better to listen and facilitate change from within.
On the Board’s letter: The new ED was still settling into her role, and asked the Board for public support. That would focus discussions on her work to find a better way forward, and to fix what was broken, rather than on internal differences within the Foundation. This led to the public letter from the Board, supported by a majority of trustees. Finding a better way to roll out MediaViewer was likewise taken up by staff.
In the same spirit of unity and focus: now, months later, we should also encourage publicly admitting failure and learning from it. We should encourage everyone involved to recognize what went wrong and why, and the changes made as a result. I don’t know if keeping the legacy code as a reminder is a good idea, but it may not hurt.
Planning for the future: the timeframe of Board guidance and decisions is usually measured in years, not in months.
Since last fall, the Board’s engagement around deployments has been in strategic discussions about how to make community feedback and buy-in an integral part of the development cycle. The WMF has seen two recent steps in that direction: the creation of a separate Community Engagement department, and the collaborative rollout process developed by the new VP of Engineering.
Syed Muzammiluddin (Hindustanilanguage)
no response yet.
Edward Saperia (EdSaperia)
It seems very strange to me that this should have happened at all. To me, the community arguing with the WMF is like someone complaining at their car for going in the wrong direction. The community itself develops strategy. If the strategy was put into place and the outcome was rejected by the community, then obviously the community did not reach consensus on its own strategy. This should look the like the community arguing with itself, rather than the community arguing with the WMF – this strongly points to a lack of transparency in WMF decision-making. If there was a subset of the community that tried to override the consensus, then the WMF ought to indeed take appropriate measures to stop it, and it should be obvious that that’s what is happening.
Mike Nicolaije (Taketa)
thank you for your question. Superprotect is a bad idea. Using superprotect showed a lack of understanding of community processes. This was not an emergency. There was no reason to use advanced rights. Implementing software against community consensus showed that there was a lack of previous discussion. The WMF should get community support for software proposals. New software will have a better reach and usefulness if we discuss it together. Effort should not be wasted on software that does not have community support.
Pete Forsyth (Peteforsyth) Candidate withdrew before voting opened
My thoughts on this matter are well known: I wrote Letter to Wikimedia Foundation: Superprotect and Media Viewer, which was signed by 1,000 people, and which has elicited zero public response from its recipients (every Board member, and the Executive Director) — even in this question, the three incumbent candidates (Phoebe Ayers, Samuel Klein, and María Sefidari) are not among those who have responded. This is the central reason for my candidacy: I believe none of those three should be reelected by the community, after declining to even address an issue important to 1,000 of its members.
Superprotect, in the absence of clear policies for its use, is a bad idea. I am open to the idea that Superprotect might be a worthwhile software feature. But look at its page, linked here. Approaching a year after it was deployed, there is still no statement about what conditions the Board or the Staff feels might justify its use, or what conditions it should not be used.
- This issue must be resolved one way or another. The cleanest way to address it would be to disable it, and articulate the reasons why it should be re-enabled, and how it should be used. A good proposal should be easy to sell to a broad constituency; then, it could be re-enabled with clear buy-in from both WMF and the volunteer community. This would be a victory for all parties. It is attainable.