Talk:User groups

Active discussions


clearly there is a natural hierarchy. can people re-sort this list so i can figure out where i can fit in?

Page titleEdit

Any objections to moving this page to User groups? Referring to these groupings as classes seems a bit out of sync with our principles and has strange connotations. Thoughts? --MZMcBride 06:14, 2 October 2008 (UTC)

I'd support that, especially considering as it is labeled as "user groups" in the relevant special: page. —Anonymous DissidentTalk 08:44, 2 October 2008 (UTC)
"User groups" is more technically correct, so   Done  — Mike.lifeguard | talk 12:01, 2 October 2008 (UTC)

Models fashion style Yendritraugutt (talk) 19:14, 28 October 2016 (UTC)


What about autoreviewers? Kayau 10:40, 24 February 2010 (UTC)

Staff expanded text & expanded chartEdit

Staff expanded text & expanded chart should be extracted into separate page named Staff users, as example. Please make this before starting translations. --Kaganer (talk) 07:13, 1 May 2013 (UTC)

Wikimedia Foundation staff permissionsEdit


Moved from User talk:MZMcBride#Guillom


Do you know why Guillom's staff permissions were removed? Is he no longer employed by the WMF? 14:23, 13 April 2013 (UTC)

Guillom is still a valued staff member at WMF; as part of a routine process, the WMF is constantly evaluating who has access to that user right, in order to minimize the proliferation of those very specialized tools if others may more directly fit needs, if someone is expected to not need them for a period of time, or if there is something that triggers during a risk assessment. This is not the first such instance, not will it be the last. Its just good security practice. In this case, I fully expect that Guillom will have his rights restored soon. Philippe (WMF) (talk) 16:30, 13 April 2013 (UTC)
wmf:Staff would be just about the most up-to-date index for determining whether guillom still works for the Wikimedia Foundation, I think. According to the log, his staff rights were removed about a week ago on request from Philippe.
It's been my general impression that: guillom has too much clue to be working at the Wikimedia Foundation (or too much clue to be working for the people he's working for), who does and does not have staff rights is arbitrary, and within the staff global user group itself there seem to be few protections against abuse or misuse. Just recently, apparently, the "edituserjs" and "editusercss" user rights were given to staff; who knows why other than a "request from Philippe." Helpful.
I deeply question the virtue of having a "restricted" global group with an arbitrary membership and arbitrary user rights assigned to it, all based on the say-so of Philippe and others. It would be nice to have a chart, perhaps, listing each user right assigned to the staff group and what specific purpose each user right is providing. (Whose user CSS and JS needs to be edited by staff, exactly?) It would also be great if the stewards stopped acting like the Wikimedia Foundation's slaves and required a demonstrated consensus before adding new user rights to the global user group. Philippe hopping on IRC and asking a steward to modify the global group offers only security theater. --MZMcBride (talk) 17:00, 13 April 2013 (UTC)
As a followup, you may wish to note that Guillaume's staff rights were restored today. To the process questions upon which MZ pontificates above....
*"Who does and does not have staff rights is arbitrary..." - When I took over the rights assignments, I totally agree - it was arbitrary. I've moved to formalize the process since then, to protect against exactly the types of abuse that you seem to fear. There is now a formalized process within the WMF to speak to that. For instance, I can not just assign staff rights to anyone that I like, as I used to be able to. Instead, the process that I wrote requires second level sign-off, (meaning that for a new employee in a department, director level signoff is required. For a new manager, c-level signoff is required) a formal written use case, which is kept on file and routinely reviewed to determine whether it is still necessary, a brief training session, and an acknowledgement (in writing) of the rights and responsibilities that come with those permissions, and their appropriate and inappropriate use.
*"Within the staff global group there are few protections against abuse..." - I would also agree that this was the case several years ago, but no more. There are a number of checks and balances built into the system now. On enwiki, for instance, the AUSC reviews all logged actions and routinely refers questionable actions to me for review. In addition, where there is no comparable committee, my team audits and reviews employee actions. This has resulted in employee disciplinary action on occasion. These are not toothless protections.
*"edituserjs and editusercss..." This was done for a couple of reasons. First, we have had times when we saw a user insert some code in their own user.js and user.css files that really shouldn't be there, and then propagate that code out to the wikis by adding a transclusion from their own user files to, for instance, Mediawiki:Common.js of a smaller wiki, and thereby add google tracking code, for instance. This allows staff to easily (and in a logged fashion) remove such code. Second, in order to include a script for those users who hold staff rights which colors red the interface buttons for things that they really shouldn't touch without a REALLY good reason (ie, the execute checkuser button). You can see that script in my own userjs file. This is a reminder for new staff who didn't come from the community that these are specialized rights, and not everyone has access to them, and serves as a mental "speedbump" against using them.
*"all based on the say-so of Philippe and others..." Well, yes. Any process is going to have a decision maker. For this one, that's me, and the second-level manager of the person requesting the rights. But at least now it's not solely resident in my hands.
*"it would be nice to have a chart..." Such a chart does exist, but can not be shared in its current format publicly, because it includes employee actions (terminations, warnings, etc). I'll see if there's a way that we can, in a low-impact fashion, create a version that can be shared publicly.
Hope this sheds some light on current internal processes. Philippe (WMF) (talk) 19:45, 15 April 2013 (UTC)
Update: I believe that I've found such a way to share the data from the chart I mentioned using a combination of black majik and Google-docs foo. Unfortunately, I won't have the time to tinker with it until after I've returned from the chapters' conference, most likely. I will endeavor to do so at some point in the relatively near future, however. Ask and ye shall receive. Sometimes. :) Philippe (WMF) (talk) 21:09, 16 April 2013 (UTC)
Hi Philippe. Thank you for such a thorough and thoughtful reply. I appreciate it, particularly as my reply to was rather brusque. I'm going to work on expanding and clarifying User groups#Staff today. --MZMcBride (talk) 15:22, 18 April 2013 (UTC)

Philippe is so helpful! <3 Killiondude (talk) 05:32, 18 April 2013 (UTC)

Thanks, I think. :) Philippe (WMF) (talk) 22:57, 24 April 2013 (UTC)

Looking for inputEdit

Hi MZ,
As promised, I spent some time on this on the plane to the chapters conference, and would like your input on the current iteration - I want to be sure that it at least attempts to answer the questions that you have. If the output were a spreadsheet that included the following information and looked sort of like the below, would that be a step in the right direction? What else would you like to see included?

Username Use case received Use case status Use case Rights approved Rights Approval Date
Philippe (WMF) 2/2/2013 Approved Philippe manages (and is a primary responder for) the emergency@ response team, which includes the need to checkuser and view deleted revisions to determine the credibility of various threats. He also executes DMCA takedowns and other legal actions at the direction of the legal team, and makes necessary interface changes (changes to legal notices, etc). Staff - per Geoff Brigham 2/2/2013

While I obviously can't promise to meet every request, I'd like to try to meet any reasonable ones. Your input would be much appreciated. Thanks, Philippe (WMF) (talk) 22:57, 24 April 2013 (UTC)

I personally don't need this level of detail, though others might like it. I was more concerned with the current practices being documented, which they didn't seem to be. Your edits to user groups looked fine. (Splitting that page out to staff user group might make sense if it continues to grow.) I think if you try to finish your chart, you'll have difficulty writing a use case for a few people, but don't let that stop you. :-) Even having just a list of members and a less than a tweet about why they have staff rights would be fine. (If log summaries weren't so useless, we could use those. Alas.) --MZMcBride (talk) 23:54, 24 April 2013 (UTC)
This would be nice to have if you have the time to do it, there were a few people when I glanced at the list a couple of weeks ago who I knew would have a good reason for having the right, but couldn't think of what that reason would be myself. Thehelpfulone 00:07, 25 April 2013 (UTC)
The beauty of this system is that it's data I'm already collecting. So I could just share particular columns of a google doc and result in almost no extra work. :) Philippe (WMF) (talk) 01:21, 25 April 2013 (UTC)
Philippe could you give us a status update on the progress of publishing this document? Thehelpfulone 16:27, 11 May 2013 (UTC)
Just following up on this @Philippe (WMF): did this document ever get published? Thehelpfulone 15:41, 4 April 2014 (UTC)
I staffed it out. @Jalexander:, status please? :) Philippe Beaudette, Wikimedia Foundation (talk) 21:20, 7 April 2014 (UTC)
  • @Thehelpfulone: (I assume MZ will auto ping). I think we're set, I've created an auto updating site link that pulls from our google doc. It does not include sysadmins (which, while some go through us because they originally ask for staff rights, are mostly handled by Engineering directly) but all other rights that we consider 'staff' granted rights should be listed along with the use case that was given for why they need the rights. You can see it here. I know we had a page where we were going to put this... where was that? I seem to be blanking. Jalexander--WMF 21:48, 7 April 2014 (UTC)


実は私がこの執筆を始めたのは2005より前なのです。 とうに削除されいぇいますが。 私が大学を出てインターネット民間に解放されていなったこときにこうなる時代を考えて準備を始めました。1990年ごろの日本で。 私は2000年からパーキンソン病におかされていますにで常勤の役員とはいかないでしょうね。 資格はあんなにもんるCreeiteve Commonsをご覧いただくと資格はそろっているのですが。

これだけの被害は賠償されなければなりません。 又いわれのないブロックと削除があってもここにいるのです。 本来ならどの地位か理解可能でしょう。

報酬はいただきます。賠償分を合わせて。 立場は常勤は不可能ですがどのお手はずで考えてもらいたいものです。 これが満たされるならことを大きくはしません

Expatriate participation in UGsEdit

Not sure if there's a discussion on this aspect, but I've worked in the diversity committee in the 2019 Wikimedia ESEAP meetup in Bangkok, and one aspect I brought up was encouraging expatriates (generally non-citizens who reside in countries other than their citizenship, who have no intention of immigrating to that country) to join these UGs. One user did caution that the UGs should not be dominated by non-citizen participants. I thought about this for several months and decided to post some possible guidelines:

  • Expat users should generally allow the control and direction of the group to be lead by locals; exceptions may be in territories were most residents are foreign anyway, such as Dubai (UAE). Expats may be a liaison for and/or the board of a local UG, at the UG's discretion.
  • Expat users should learn or be in the process of learning at least one of the local languages and show an interest in the local culture. Some foreign expatriates only move to a location to make more money, but not being interested in the culture may make it harder to work with locals. While the UG may communicate with the user in a global language like English or French, learning at least one local language gains favor and goodwill from the locals.
  • Expats should retain cultural knowledge specific to where they are and document it, so they may teach newer international UG participants. For example if Kevin, a non-Brazilian in a UG for Brazil, finds that his new coworker Chantal (also non-Brazilian) is interested in joining, he may teach her relevant aspects such as the local culture on the Portuguese Wikipedia, Portuguese terms for Wikipedia terminology, etc (of course locals may also help teach Chantal as well!)
  • If expats change locations, they may exchange information from one UG to another: Say an expat was in the user group in Berlin, Germany: if he/she/they get a new job in India, he/she/they may share with the Indian UG what he/she/they learned while being in the German UG.

WhisperToMe (talk) 15:10, 7 December 2019 (UTC)

Return to "User groups" page.