Jesus Risker, get your tongue out of the WMF's ass...
Even the most trivial change of appending _(WMF) is too much for this brainless harridan.
Admin accounts aren't labeled so employee accounts shouldn't be!
Some thoughts: We do not require that any enwiki administrator, bureaucrat, checkuser, oversighter, template editor, reviewer, edit filter manager, or person with any user rights identify their rights on their userpage. As well, you do not clarify why such an expectation should be project-specific when you are talking about global user rights.
I'm the first to agree with the separation of accounts (despite the greater-than-usual difficulties in switching accounts, and the strong emotional attachment that most users have with respect to their username), but one needs to keep in mind that some of the applicable accounts are essentially impossible to SUL at this point, and thus are not eligible for global rename. Staff work on hundreds of wikis, not just enwiki. A global perspective is required here. Risker (talk) 10:22, 4 August 2014 (UTC)
You can't force employees ot wear nametags!
That's when the software is due to be drafted, Wnt. However, the discussion of hierarchies of who gets the right to usernames, plus the discussion of what names to move accounts to, has yet to take place; all the stuff that was suggested before is not in place and is not enforceable. While some staff accounts may be fairly simple to unify and then rename to a "WMF" username, some are apparently quite complex and will require negotiation in a few different places. (I've not personally looked into it, but I'm aware some of the staff couldn't SUL before.) I'll just say it's not only appropriate but very important that a tool that will affect only registered users, and registered users potentially from every WMF project, should be the subject of extended and vigorous discussion; while I don't think there's much question as to the value, I think we can all recognise how personal usernames are, and that forcing someone to change usernames against their will (in deference to some other user who may never have edited their project or even projects in their language) is going to take some pretty significant diplomacy. Given recent history, I'm sure you'd agree it is not something that should be rushed, and that there should specifically be outreach to the people who will be most directly affected. Risker (talk) 22:53, 4 August 2014 (UTC)
Anne Clin, friend of the little man!
Absolutely they do. Bad code is bad code, and has no place on a major website. You've neglected to include performance issues, adverse effects to readers (as opposed to the editors and admins who seem to think they own the site), and code that has been inserted without proper review and discussion. Whether or not the RFC close was appropriate does not mean that the code itself was appropriate. Risker (talk) 10:11, 4 August 2014 (UTC)
Cause you were all over Flow and VisualEditor when that bad code was released!
I'm sorry, Pine, but I do not actually care if someone from the community eventually got around to undoing what was clearly an improper edit. And I genuinely believe that any admin who did so ran a very serious risk of getting himself or herself involved in an edit war. It had every earmark of being a 'true believer' issue rather than a practical one. I also disagree with you about alienating readers; there is a significant segment of the community (unfortunately one that includes a lot of administrators and longtime editors) who place "community rights" over and above benefit for readers. Whether or not that group want to admit it, Media Viewer is a lot closer to what readers want than being taken to a weird page that is full of all kinds of information that's irrelevant to 99.8% of readers (just like the history page of an article is). And there's a problem with your theory of community consensus, in that it seems you believe it only occurs in RFCs. That's patently wrong, and always has been. RFCs are only one method of determining consensus. The fact that somewhere between 9000 and 14,000 editors *chose* to enable Media Viewer before it became default is also a consensus, one that far, far outweighed the number of editors who participated in the RFC, let alone the even tinier number who supported removing the default. (At the time of the switch, there were approximately 5000 users who had selected "all beta testing" - even if all of them are discounted, that still leaves 9000 editors who chose to enable MV.) Risker (talk) 23:10, 4 August 2014 (UTC)
Still hoping for a job?
Even the WMF isn't that desperate.
I believe that there are multiple other pages that refer to the use of staff rights, but they are workplace policies that are not public. (This is appropriate - very few organizations publish their workplace policies, particularly if they refer to the potential for disciplinary action.) I note that nobody has actually asked that question, so there is no reasonable way for the committee to comment on this, nor does the committee have a place in determining workplace policy for the WMF. Risker (talk) 10:15, 4 August 2014 (UTC)
Never mind the fact that this is a public charity and that the WMF *IS* publishing their employee handbook soon.
The stupid... IT BURNS!!!
The point that all of these numbskulls are dancing around is that Erik Mo:eller and Fabrice Florin have said that they (and by extension the WMF) will not allowed MediaViewer to be turned off by default. Ever.
Everything else is a sideshow.
They are the best "hasten the day" people I've ever seen.
Legends of the folk heroes who led this putsch, though clouded by anonymity, will be legion. Their associated images will be many and varied (though eerily familiar to some). Songs will be sung.
