Wikipedia talk:Moderators/Proposal

See also the proposal and the straw poll of this proposal.

technical rights bundled

I'm going to boldly strike out redundant rights that the group should not need to duplicate (because they are already included in "user", "autoconfirmed", "extended confirmed"). — xaosflux ^Talk 21:26, 8 July 2016 (UTC)[reply]

Please review - then they should just be able to be removed. The only good reason too keep these double-listed would be if we planned on revoking these from everyone else (at which time they could always be re-added). — xaosflux ^Talk 21:34, 8 July 2016 (UTC)[reply]

I was told (granted this was literally years ago) that there was something technical with "editprotected" that required "autoconfirmed" to be in the same package. I added the other two (extended autoconfirmed and skipcaptcha) in that vein. If they are not needed, I'm fine with the removal. : ) - jc37 21:41, 8 July 2016 (UTC)[reply]

As far as I can tell, duplicating the permissions is no longer required. — xaosflux ^Talk 21:52, 8 July 2016 (UTC)[reply]

For ease of discussion and comparison (not every commenter is going to go through the userrights like you or I : ) - let's leave them there for now, the redundancies can easily be removed upon implementation on the technical side. Also, if things ever do change, this at least allows for this consensus to apply to them as well, if deemed necessary. - jc37 21:56, 8 July 2016 (UTC)[reply]

You may want to include: Edit protected templates (templateeditor) — xaosflux ^Talk 21:37, 8 July 2016 (UTC)[reply]

The above notwithstanding, I was/am trying to not be redundant with the admin-granted user-rights. But otherwise, I would be fine with the addition. - jc37 21:41, 8 July 2016 (UTC)[reply]

For that one, as you are giving the editprotected, it is a "higher" level - and the most high risk templates are that level already.

To make sure I understand, "it" applies to editprotected or templateeditor? - jc37 21:56, 8 July 2016 (UTC)[reply]

editprotected>templateprotected>extendedconfirmedprotected>semiprotected. It doesn't make sense to give out editprotected and make the users request template-editor as separate action. (I'm pretty sure it doesnt automatically override). — xaosflux ^Talk 22:01, 8 July 2016 (UTC)[reply]

Ah ok - things have developed since I last proposed this : )

No problem with adding them, then. The idea is to allow editing but to not allow for adding said protection. Is that possible in the others? or does extendedconfirmedprotected (for example) allow both? - jc37 22:07, 8 July 2016 (UTC)[reply]

@Jc37: As I understand it, the sysop flag protect allows edit/move/create/upload (not autoaccept) protection of pages at all levels, which is separate from the protection levels templateeditor and extendedconfirmed. So this moderator group has no protect / pending changes abilities as proposed.

It's generally agreed that templateeditor > extendedconfirmed, but it isn't strictly true, because a week-old 100-edit account that happens to be granted templateeditor cannot edit a page like Israel (which is ECP'd). — Andy W. (talk · ctb) 00:16, 9 July 2016 (UTC)[reply]

Thank you very much for the clarification : ) - jc37 00:22, 9 July 2016 (UTC)[reply]

Also: (mergehistory) (related to page move/delete). — xaosflux ^Talk 21:43, 8 July 2016 (UTC)[reply]

Added, thank you : ) - jc37 21:51, 8 July 2016 (UTC)[reply]

Name

I think the forum definition of "moderator" is a very common interpretation of the word. I.e., someone who (1) monitors discussions and deals with any misbehavior, including blocking, or (2) looks at each post before adding it to the thread. So there is that potential for confusion. Then there's the fact that we may decide to have an unbundled function like (1) for talk spaces at some point in the future—even pipe dreams come true occasionally—and moderator would be the obvious name for it.
I'd suggest something like deputy admin. ―Mandruss ☎ 22:08, 8 July 2016 (UTC)[reply]

I seem to recall "content-admin" as one proposal in the past. But I think we really should avoid "admin" in the name to avoid any chance of newbie confusion. - jc37 22:12, 8 July 2016 (UTC)[reply]

How about implementer? - jc37 03:23, 9 July 2016 (UTC)[reply]

granting criteria?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Would the granting process be the same as the existing RfA process, or something else. If same process, same (0-65%; 65-75%, 75-100%) result bands? — xaosflux ^Talk 22:17, 8 July 2016 (UTC)[reply]

Out of my hands : )

Please see this

So, as I understand it, whatever the criteria is for a successful RfA, this must have the same. - jc37 22:27, 8 July 2016 (UTC)[reply]

Thanks. — xaosflux ^Talk 22:35, 8 July 2016 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Well actually, that was 4 years ago, and no doubt Geoff is back from holiday, so it would be worth checking again. Johnbod (talk) 02:24, 9 July 2016 (UTC)[reply]

Have you seen the WMF's annual leave entitlement...?!

_Muffled ^Pocketed 11:34, 9 July 2016 (UTC)[reply]

Have people actually been requesting this kind of a user-right?

The proposal mentions that: "Believe it or not, such a user-right group has actually been requested repeatedly for a very long time".

Is there some data to back up this statement? Or at least some specific examples of such requests? If yes, could you (meaning the proposal's author) please provide the relevant links? Thanks, Nsk92 (talk) 23:31, 8 July 2016 (UTC)[reply]

Since you ask, while there have indeed been several comments in similar discussions in the past, I suppose the easiest answer would be to check out several commenters in the support section. There's also a comment from an OTRS person here; and Quinn1's comments further down the page; and Guy macon left some comments here as well. I'll leave it to you to assess the various comments. - jc37 23:17, 30 June 2012 (UTC)[reply]

The above was my response to a similar request in a previous proposal of this. Please feel free to read that (albeit lengthy) talkpage for more examples. Besides this, I'd have to dig, but I remember this coming up whenever toolset subset discussions happened, like a a VP discussion ages ago concerning those who call themselves wikignomes not wanting to have any part in the behaviour-related responsibilities/tools. - jc37 23:47, 8 July 2016 (UTC)[reply]

OK, thanks. Nsk92 (talk) 00:02, 9 July 2016 (UTC)[reply]

Technical question - expired prod delete only

I have a technical and somewhat tangential question. Is it technically possible to create a user-right that will only allow a user to delete pages with expired prod tags (but not to perform any other kinds of deletions)? Nsk92 (talk) 11:38, 9 July 2016 (UTC)[reply]

That is extremely unlikely to be supportable - the primary reason is that the software doesn't know what a "prod" is (it is just edited text) - and more challenging - it would not actually keep tack of it it is really expired or not. — xaosflux ^Talk 12:26, 9 July 2016 (UTC)[reply]

Hmm, OK, thanks. Pity that the software does not provide this option. Nsk92 (talk) 15:51, 9 July 2016 (UTC)[reply]

A left-field option would be to make a page to list expired prods that have been reviewed - the page would be protected and require editprotected to edit (or something else that is agreeable to others) - then an adminbot could process it, the bot would be able to check the revisions and perform the delete. That being said, that is a lot of work for someone who could have instead just pressed "delete" if they had permission. — xaosflux ^Talk 18:02, 9 July 2016 (UTC)[reply]

Simple question

Doubtless this shows my complete ignorance of rights and levels, but would the ability to see and undelete deleted material mean that these moderators would be able to see Revdelled stuff? Or even have the ability to Revdel themselves? Happy days, Lindsay^Hello 12:56, 9 July 2016 (UTC)[reply]

Yes they can see deleted material with the 'browsearchive' (page name of a deleted page), 'deletedhistory' (deleted page histories) and 'deletedtext' (text of deleted pages) rights. They can also material and delete material which has been revision deleted with the 'deleterevision' right (but that would be needed to deal with things like copyright vios (see WP:RD1). Callanecc (talk • contribs • logs) 13:55, 9 July 2016 (UTC)[reply]

Note, this would not apply to "suppressed" items deleted by oversighters (which admins can also not see). — xaosflux ^Talk 18:03, 9 July 2016 (UTC)[reply]

Revision deletion

In the section above the inclusion of revision deletion was raised. While I see that it might be useful for dealing with copyright vios I'd rather it wasn't included in this package given it's primary used to deal with behaviour (BLP/bad personal attacks etc) I'd prefer it stayed in the admin package. No issues with moderators being able to see revision deleted material, but I don't see that they'd have too much of a need to use it. Callanecc (talk • contribs • logs) 14:02, 9 July 2016 (UTC)[reply]

Just to make sure we're talking about the same thing, there's a difference between "deleterevision" and "supressrevision". (See mw:Help:RevisionDelete and mw:Manual:RevisionDelete).

From what I read, one is what admins can do and see, the other is for oversighters.

That said, if "deletedtext"/"browsehistory" would allow to see the text of said deleted revisions (the admin version) then I suppose there would be little need for the Mod to have the deleterevision userright. (copyvio is one, as you mention).

- If that's clear as mud, I apologise. I'm finding that the help files aren't clear on this point. (Wikipedia:Revision deletion isn't much better.)

Also, technically, if you can delete, you can delete revision - just delete the whole page, and restore only selected revisions. So I'm not sure if there's a point to separating the userright out, since it's mostly just a convenience?

I wonder if there's a dev out there who might know the concrete answer to all of this? - jc37 16:00, 9 July 2016 (UTC)[reply]

Yes, suppressrevision is for Oversighters and hides the content from admins. RevDel'd content can be seen without deleterevision; only deletedhistory/deletedtext is needed. Deletion with selected restoration does not preserve attribution in the page history, so it shouldn't be used in most cases. Exceptions include history merges and splits. — JJMC89 (T·C) 22:28, 9 July 2016 (UTC)[reply]

Alternate approach

I've been thinking about an alternate approach that is many ways similar to this one. Currently there are several task focused permissions that sort of fall between extended confirmed editor and admin. These permissions can be granted and removed by an admin. But full admin permissions require being able to being able to view deleted content which requires a process equivalent to RfA. One of the big concerns to RfA is that it can get focused down on excessive criteria. What about setting up group of permissions above this level which would all effectively be types of admins. For example their could be a Janitor Admin ( similar to the permissions proposed for here, just no blocking / unblock for example ), and a Moderator Admin ( one that can block and unblock ). The various types of admin would be all just considered admins ( and really in most thing and discussions admins are just other editors ). To be able to get any of the roles a perspective admin needs to pass RfVD ( request for view deleted ) which would replace and be the equivalent of the current RfA process, but more focused on the key issues on if the editor should be trusted to view deleted content. Once an editor has pass RfVD they should be able to make requests for permissions similar to how page mover or template editor are requested but those would be granted by bureaucrats. This has the advantage that it keeps mostly the RfA process but refocusses it to a more clearly defined question while allowing candidates that are intimidated by things like not wanting to worry about the stress of dealing with behavior issues such as blocks. PaleAqua (talk) 20:58, 9 July 2016 (UTC)[reply]

How this might work: suppose User:Example decided/(or more likely got convinced) that they should help out with some of the admin backlogs.
- Example would run an RfVD and optionally indicate they they are seeking the Janitor permission.
- Other users would support/oppose/neutral based on how trustful Example would be admin like privileges. Criteria for individual permissions could also be discussed but would not be the focus of the RfVD.
- A bureaucrat would close the RfVD.
- Example would either then request Janitor permission or would have as part of the RfVD. A bureaucrat ( possibly a different one ) would consider if Example meets any required criteria and takes comments made during the RfVD etc. into account before granting it.
- Later, Example encounters a regular troll that they end up good at spotting and are convinced to try to get moderator to help block the trolls socks.
- The would post a request for moderator and a bureaucrat would evaluate it and likely give the permission.
- Suppose however example started causing trouble. A single bureaucrat should be able to easily just drop them back down to only the view deleted permission or lower if warranted and then a discussion could be held or it could be brought to arbs etc. for a long term solution.
PaleAqua (talk) 21:21, 9 July 2016 (UTC)[reply]

If I read the above correctly, there are a couple issues.

First, per the WMF, the process needs to be just like RfA.

Second, telling the community that the discussion us "only" to "view deleted", but then handing out the block tool, would appear to the community as to be dishonest.

Third, every discussion I've seen concerning the block tool, the community wanted the editor to be able to have other abilities in conjunction with block, such as view deleted, in order for the blocker to make informed decisions of when to block, and to have other options as appropriate, such as protect.

Fourth, if I remember correctly, having a bureaucrat have sole discretion to remove admin tools has been tried and has failed consensus.

Ok, so we know the issues with this, here are some possible solutions:

First, you'd want to go through all the user-rights and figure out the bare minimum for a blocker user-right package. Due to point #3 above, if would likely need to go through an rfA-like process to be handed out.

You can try, in the proposal, to have it potentially removed by one or more bureaucrats, but as I mentioned in the fourth section above, that likely won't fly.

As for removal, check out WP:RRA, my last attempt to put together something that allowed for the community to remove adminship more directly. I may re-propose it at some point.

If it helps, I've been there. I actually tried to propose something very much like what you're proposing, but found out through the discussions that that wasn't going to work.

But who knows, WP:CCC, work something up and start a proposal. What I am proposing here doesn't prevent a blocker userright package being approved. (They are not mutually exclusive.) I hope this helps. - jc37 22:36, 9 July 2016 (UTC)[reply]

Editing cascade-protected pages

I just want to point out that with the currently proposed permissions, moderators wouldn't be able to edit cascade-protected pages. That includes anything transcluded on the Main Page, such as Template:Did you know, Template:In the news, etc., and also any templates transcluded on Wikipedia:Cascade-protected items. This would seem to reduce the usefulness of this user group for answering protected edit requests. It is a bit counterintuitive, but to edit cascade-protected pages you need the protect user right. This is because if you can edit a cascade-protected page, it is possible to protect any other page simply by transcluding it there. — Mr. Stradivarius ^{♪ talk ♪} 03:18, 10 July 2016 (UTC)[reply]