Jump to content

Talk:Special global permissions

Add topic
From Meta, a Wikimedia project coordination wiki
Latest comment: 8 months ago by Xaosflux in topic cleanup please

Both Proposals

[edit]
  • Comment Regarding the previous proposal, we didn't actually have unified login then so thats why it never eventuated and right now I will actually agree with both proposals because I believe both can now be put to use and new class "staff" and "developers" would be useful and the ombudsman commission was a great idea and it will only have 3 members and probably the staff class will also have 3 members, such as Cary-bass, Mike Godwin and Jay Walsh.--Cometstyles 03:07, 7 July 2008 (UTC)Reply
    Yeah, support obviously. The staff proposal should just be implemented now as we already have consensus. The dev one should be uncontroversial.  — Mike.lifeguard | @en.wb 03:49, 7 July 2008 (UTC)Reply
    Indeed, sounds good to me :) SQLQuery me! 04:25, 7 July 2008 (UTC)Reply

Ombudsman global role

[edit]

I had gone ahead and created this role, because it's a perfect test case for global rights. I did not actively remove the local roles for the ombudsmen for two reasons:

  1. Not all the ombudsmen (persons) have completely unified their logins.
  2. I wasn't sure which rights (such as enwiki for two of them) were in fact earned external to the ombudsman role.

That being said, I'd be grateful if someone assisted the two ombudsmen (persons) who have not yet managed to unify all of their accounts to do so; as well as allow the suggestion that extra local rights (checkusers on wiki not earned) be removed by an interested steward. Cary Bass demandez 15:25, 7 July 2008 (UTC)Reply

Mackensen is nearly done. I don't know Rebecca's status, but if there's anything I can help with, let me know, k? Kylu 02:51, 9 July 2008 (UTC)Reply
Thanks Kylu. I've renamed Rebecca on the wikis in which her username had no edits (apologies to dawiki and fiwiki for not following their procedures). She still has several wikis in which there are a single edit from a long time ago which will have to be taken care of at a local level. Cary Bass demandez 21:09, 22 July 2008 (UTC)Reply

What permissions do they really need?

[edit]

Now that bugzilla:14839 is fixed, we should revisit which permissions this group should have. The right checkuser-log allows them to view logs; the right checkuser lets them actually perform checks. I'm not sure they need to have the checkuser right. The log is a tad funky, I think - what other rights do they currently have?  — Mike.lifeguard | @en.wb 05:13, 3 September 2008 (UTC)Reply

Only CheckUser and chckuser-log for now, this was discussed previously, and we are not sure about which permissions they actually need..--Cometstyles 05:44, 3 September 2008 (UTC)Reply
You may be misunderstanding here. There used to be only the checkuser right - this allowed users to perform checks and view the log. bugzilla14839 split that right off into to rights: checkuser (allows the actual check) and checkuser-log (allows user to see the log). This was done specifically so the Ombudsmen could see the log only, and not run the check. It may turn out to be the case that they will need more rights, which is fine. I'd argue they should have the minimum necessary, and if/when they begin an investigation they could request more rights to do so (ie they may need the checkuser right to see the actual checkuser information). This has nothing to do with $wgCheckUserLog, which is a setting for the location of the checkuser log file.  — Mike.lifeguard | @en.wb 14:19, 3 September 2008 (UTC)Reply

Sysadmins

[edit]

We definitely need input from the system administrators with this role... they may need more rights than that (possibly all and the ability to manage global groups) so that they can test individual bugs with the rights. (This is why Brion has traditionally had these rights.) Cbrown1023 talk 18:50, 7 July 2008 (UTC)Reply

It may make more sense to have a sysadmin group with access to everything, but to give it no initial members. Then we can add ourselves to it if we need to use it. I very rarely need to use steward-like web permissions these days, and some of the sysadmins have never used them. -- Tim Starling 02:47, 9 July 2008 (UTC)Reply
Seems a good approach to me. ++Lar: t/c 02:59, 9 July 2008 (UTC)Reply
Yeah, that sounds fine. Glad I don't have to list all the permissions that group will get - it is a bigger list than one thinks :D  — Mike.lifeguard | @en.wb 03:13, 9 July 2008 (UTC)Reply
I figured, give them userrights and userrights-interwiki, then they could use those to give them whatever other rights they needed, wherever they needed them. Potentially centralauth-admin right away also, but more so because it's something that's likely to warrant their attentions at the moment. Kylu 03:16, 9 July 2008 (UTC)Reply
You are completely correct, Kylu. That would work out very well, because with those three rights, they could get *all* of the other rights. :-) Cbrown1023 talk 03:20, 9 July 2008 (UTC)Reply
Come to think of it, "developers" is really a bad choice of name but "sysadmins" is fitting, though I'm not sure who will be given the rights, like for "ombudsmen" only 3 people qualify and so maybe for developers, this right will go to those devs with root and shell access because MediaWiki does have a lot of Developers.. ;) ...--Cometstyles 03:56, 9 July 2008 (UTC)Reply
I was using "Developers" in the sense of the traditional permission on Wikimedia sites, not SVN-commit developers. Sysadmin would be a more accurate title, certainly. Please don't mistake the title as a sign of ignorance, more as a keeping with tradition. Kylu 04:10, 9 July 2008 (UTC)Reply
seeing people confuse Mediawiki with Wikimedia all the time.. :) ..I'd say "sysadmins" should be used with the new global group (if accepted), and well 1000 of years ago when Mediawiki was created (not !! :p), the word 'developer' would have been a great name, but looking at all the changes since then in terms of toolserver access, svn-access, general application developers such as Pywikipediabot, API , minor extensions, the word developer has become a bit too ambiguous :)... I hope the "developers " can decide for themselves which name they prefer, though I will strongly disagree with "Brion and his merry men" :P ... --Cometstyles 04:22, 9 July 2008 (UTC)Reply
That's not until the RPG plugin goes live and we start earning experience points for stopping vandals and editing articles. Kylu 04:58, 9 July 2008 (UTC)Reply
OMG I would have been a Level 8 Warlock by now.. but sadly Wikipedia:Wikipedia is not a MMORPG, but no one said anything about WikiMedia ;)..--Cometstyles 05:06, 9 July 2008 (UTC)Reply

To clarify, since there seems to be some confusion, this proposal is basically superfluous in a strict sense. All sysadmins have root database access and can add or remove any groups from themselves or anyone else whenever they want, without using the web interface at all. (Look at edits like this: you'll find no trace of log entries promoting Domas to sysop, because he just gave himself that status by running a PHP script and removed it after he was done.) So if a sysadmin actually needed to test something, they could do whatever was necessary themselves without stewards having to create any group for them.

So giving them userrights and userrights-interwiki by the logic that they could then assign themselves to any other groups they needed is a little redundant. If any group is created it would be purely a matter of convenience, to save them a few clicks/lines of typing. As Tim says, the most convenient thing might be to create a group with all permissions on all wikis, because that's going to give them everything they could possibly do through the software with one edit to the global groups table. Of course, if any of them felt a pressing need for this they could create it themselves.

As for who would get it, those with root database access are the ones with shell or root access. Anyone with just commit access (like me, say) should not generally be given any kind of elevated rights on typical wikis. (Well, I wouldn't have any objections, but I doubt it would get consensus. :P) But I wouldn't recommend consulting any lists to decide who to promote, since all the lists are rather outdated and subject to change. Again as Tim says, the group should just be empty. Anyone who is in fact a sysadmin can add themselves to it by typing a few lines in a terminal. —Simetrical (talk • contribs) 13:26, 9 July 2008 (UTC)Reply

I think that sort of situation (admin actions, no log entries of the user ever having the bit) is exactly what we're trying to avoid. I'm perfectly happy letting sysadmins do that sort of thing, but instead promoting themselves through the wiki so the appropriate log entries are made. After all, that's what the logs are for. All actions on the wiki should be traceable - that's the main purpose I see here.  — Mike.lifeguard | @en.wb 23:53, 9 July 2008 (UTC)Reply
It seems the rfc page has already been updated to reflect the consensus regarding the group name. The other permission (ombudsman) is basically current policy, so it rather seems to me that all this requires is a developer (preferably) or steward to implement the changes regarding the Sysadmin global permission and remove the extraneous local permissions. One of the syadmins could perform this action themselves if they see this, or we could pop a request up on bugzilla for the developers to view. Sound about right? Kylu 00:03, 10 July 2008 (UTC)Reply
I guess you could ask the sysadmins to use a web interface instead of a command line if you like. I don't know if all of them would listen. Obviously, the Meta community can't force them to do anything they don't want to. I don't think Brion is going to mandate that everyone has to use the web interface when promoting themselves. It's fairly obvious what happened, to those in the know, if a sysadmin takes a sysop action somewhere that they aren't a sysop. It might be moderately confusing to someone who didn't know they were a sysadmin, but it's not like there's a big lack of transparency here. Clearly they shouldn't do more confusing things like promote other people without leaving a log entry, of course, or tampering unnecessarily with histories, but they already don't do that. Anyway, I'd suggest asking Brion what he thinks if you want to pursue something like this. —Simetrical (talk • contribs) 13:17, 10 July 2008 (UTC)Reply
I'm flexible. ;) It's handy to have a visible permission marker indicating that we're Super Magical People, though, so those not familiar with the members of the tech team can see how/why we're able to use our powers. --brion 22:45, 31 July 2008 (UTC)Reply

Final Comments

[edit]

Ok, it seems we have a total support for both the "staff" idea as well as the "sysadmin" idea..what next?..I don't think it needs a guideline but may need a policy page atleast for future references and will need a final approval from Brion regarding the "sysadmins" group..--Cometstyles 03:45, 21 July 2008 (UTC)Reply

Well, before you do anything with the groups, we need input on what those groups can inherently do. Personally, I see the sysadmin group to be the same as "Steward" with the siteadmin functionality added, though Brion may have other ideas. Consensus seems to be, so far, "Sysadmins can do whatever they want" whereas they tend to be reserved about stepping on community toes, I think.
The ombudsman group is completely done and really doesn't need any more input from us.
The role of Staff, as limited to those performing duties on-wiki and under the direction of the Board, should likely be granted the 'userrights' permission alone, with clear instructions regarding logging of any actions at Meta (or office/internal, if sensitive) as an extension of en:WP:OFFICE policy, which seems to be missing from Meta, given that it's understandably a global policy, regardless of location. Kylu 22:02, 22 July 2008 (UTC)Reply
That'd be a good transwiki to do.  — Mike.lifeguard | @en.wb 22:59, 31 July 2008 (UTC)Reply
I think userrights will be enough for staff - they may give themselves whatever they need to fulfill their role.  — Mike.lifeguard | @en.wb 23:18, 31 July 2008 (UTC)Reply
Given the sensitive nature of oversight and checkuser work that originates from the office, those rights should be inherent (i.e. the rights are not logged for granting and removal). This does not preclude logging the data on the wiki in question. The ability to delete would accompany oversight, and the necessity to view deleted files as well. I can't think of what else is important at the moment. Cary Bass demandez 17:52, 27 August 2008 (UTC)Reply
How about you just give staff userrights-interwiki? That way they can decide for themselves -- if it's very sensitive they should give themselves the appropriate permissions on officewiki (so they're logged there) and if not they can give themselves the permissions on metawiki. That being said, you could just give every staff member the CU/oversight permissions and delete/view-deleted permissions right off the bat, but I thought we agreed that was less than favorable. However, it's your decision. :-) Cbrown1023 talk 03:31, 28 August 2008 (UTC)Reply
Yes, I'd say these rights changes should be logged (on meta). I can't see why oversight or CU would need to be more secret than they already are!  — Mike.lifeguard | @en.wb 10:06, 28 August 2008 (UTC)Reply
I disagree with your clarification — Cary just said that sometimes they need to do things privately, in which case we'd rather it be logged and officewiki would be a fair alternative. However, if they can Meta is always the place to log it. Cbrown1023 talk 14:21, 28 August 2008 (UTC)Reply

cleanup please

[edit]

@Pppery: not sure if you are still working on this, but the page is a bit of a mess right now with duplicated sections, etc. Will need to be re-marked for xlate, but the source should be clean first. — xaosflux Talk 14:41, 8 February 2024 (UTC)Reply

Wasn't planning to do any more work on this, but I've fixed the duplicate issue. * Pppery * it has begun 14:42, 8 February 2024 (UTC)Reply
Thanks, marked for xlate. — xaosflux Talk 14:51, 8 February 2024 (UTC)Reply