Talk:Software
The attached page seems to be written from a perspective that is not clear about what is involved in a MediaWiki installation.
1. To install and configure MediaWiki, one needs access to the domain host. This is highly privileged access. It allows direct database manipulation, typically. Normally, there would be direct access to server logs. This is present "developer access." A developer can, in theory, actually delete material directly from the database, so that it's gone, not retrievable. I.e., this is more intrusive, possibly, than oversight. A developer can, with logs and database access, see anything that a checkuser sees, and can assign or revoke any privileges, etc. Privileges can be assigned directly in the mediawiki setup php script, as well as directly in the database.
2. By tradition, those with that level of access stay completely out of ordinary deletion and other actions. One might notice that superprotect was not implemented using direct developer access, rather a tool was developed to make it a logged action, so it would be transparent.
3. Ordinary sysops have far less access. Developer access is what is involved in "configuring" a MediaWiki installation. A skilled developer could modify the wiki and leave no traces of the action behind. They have access to the computer, basically. Like a hacker might have.
4. We trust sysops, but we don't trust most sysops with oversight and checkuser and bureaucrat privileges.
5. Rather, this kind of access is, for all wikis, reserved for the site owner and designees. So I have a wiki and I have that access, as the owner. I can decide to trust someone else, and I'd better be sure I can trust them! I can be held legally responsible for what they do.
6. The WMF exists primarily to hold these kinds of keys. They have an additional function as a MediaWiki developer, i.e., some are paid for that by the WMF, though MediaWiki is also open source software and has a volunteer developer community. I do not consider MediaWiki development to be a core WMF function, it is secondary. But operating the servers, which includes configuration, is a core function.
7. Then the question arises as to guidelines and restraints on that function. Legally, the wiki community *cannot* be in charge. Rather, someone must have legal responsibility. Basically, if the site damages someone, there must be somebody to sue! So nobody questions the right of the WMF to take certain protective actions.
8. Superprotect arose, however, without any such overriding necessity. This was the WMF deciding to improve the user interface, according to its own understanding, contrary to a strong majority position of the community. The WMF was clearly taking a position of "we understand the needs of the readers better than you do."
9. The WMF Mission, as stated, is to empower and enable the community to create educational resources. That is, the WMF explicitly exists for the community, to support the community, not to control it. So superprotect arose because WMF staff took on a view of the mission that deviated from what had been clearly laid out and understood. And it's obvious that this wasn't understood as a deviation, that it was thought that, of course, the WMF should improve the reader experience, they had spent a lot of time and money on it, and that shouldn't be wasted.
10. Over the years, I've seen software developers decide that they know the needs of the users better than the users. Sometimes there is some truth to this, but get too far ahead of your users, they reject you. And sometimes -- maybe most of the time -- the users actually do understand their own needs better than developers. Hence sophisticated developers engage with the users, and listen carefully, and will bend over backwards to avoid alienating the users. One is lucky when users take the time to describe their experience and understanding. So this "runaway" was something that happens with software developers, it's a normal hazard, it takes no malevolence, and it's also something that happens with nonprofit organizations.
Where nonprofits develop staff, they develop entrenched interests that can then deviate from the original purposes of the organization. It's common, and long-term dangerous to the mission. It can take sophisticated management to avoid this problem. The solution is not to blame people for doing what comes naturally. It is to ensure that there is full and respectful communication, so that those interested remain in cooperation and collaboration.
Where it broke down the most, in the superprotection affair, was where WMF staff clearly said, "this is our decision and we are not going to change it." Lots of users called this a "fuck you." I wouldn't use those words. I'd prefer to call it unskillful and untrained negotiation. Turns out that software development skills may not correlate well with people skills. Are we surprised? --Abd (talk) 02:17, 18 August 2014 (UTC)