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)

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)

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)

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

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)

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

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)

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)

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)

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)

@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)

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

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

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

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)

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)

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

I had the same thoughts on seeing the term. Moderator is commonly associated with those who deal with forum behaviour. Funny enough, admin would be the better name for the proposed group, and moderator for those with the tools to deal with behaviour issues, but nobody would accept a complete switch around. How about some variation on gnome? That's the name we already give to those who do small tasks, avoiding the glare of drama, but quietly protecting and repairing the project. SilkTork ^{✔Tea time} 07:20, 24 July 2016 (UTC)

I think it is eswiki that calls +sysop "librarians", maybe along those lines? — xaosflux ^Talk 13:12, 24 July 2016 (UTC)

librarian is also an "authority figure" (the exhorter of 'quiet please', in days gone by...) - So I dunno if that would fly, based upon what we're seeing so far.

Wikignome is interesting, but I hesitate to wade into the WikiFauna, even though I believe Wikignome and Wikifairy far predate the rest.

That said, I'm all ears on naming ideas.

I've been looking atConsensus decision-making, and such, but I don't think variations on "exec" (like executor) would fly either.

facilitator might work, except that such an individual doesn't quite "sound" neutral to my ear (as a closer would need to be).

I suggested implementer, above, which is pretty much what this is, I think.

But as an alternative, how about clerk? - jc37 15:11, 24 July 2016 (UTC)

Jc37 "clerk" is used on many other enwiki processes already, how about: curator or archivist ? — xaosflux ^Talk 17:30, 24 July 2016 (UTC)

"Curator" is a good word for the function(s). But there are so many WP words a new editor must try to learn. "Junior admin", (jr.admin) would be self-explanatory. Or "mini-admin"? --Hordaland (talk) 22:00, 25 July 2016 (UTC)

Curator sounds good, since it doesn't imply any sort of involvement in personal conduct issues. Titoxd^(?!?) 20:16, 26 July 2016 (UTC)

I like Curator, but as I noted below, there seems to confusion over whether such users should be considered "admins". I think if I work on proposing this sometime in the future, it'll be something with admin in the name. Hence the example below, content-admin. Maybe Curator can be its alternate name, like admin and +sysop. - jc37

Some alternatives that came to mind: Attendant, Aide, Para-admin (along the vein of paralegal) Blackmane (talk) 12:25, 26 July 2016 (UTC)

For the tools and responsibilities given, someone with this pkg should be considered an admin, not something lesser, junior, or minor, simply due to the fact that they do need to go through the rfa process.

I was avoiding having "admin" in the name due to confusing newbies, but maybe, by not having admin in the name, this is less-than-clear to all. (Looking over the oppose section, I think this is showing as a misunderstanding throughout.)

With that in mind, maybe this needs to be a name to match "what's in the tin" directly, and we should come back around to content-admin. - jc37 19:29, 26 July 2016 (UTC)

Sounds good to me, FWIW. Donner60 (talk) 04:20, 28 July 2016 (UTC)

This right should not be called "Moderator"

A "moderator" is usually defined as "a person given special authority to enforce the rules on a [discussion] forum". This user group explicitly does not include any traditional 'moderation' rights like protection and blocking of other users. Something like "janitor" would be more appropriate. This is really what "administrators" should have been called in the first place. Maybe we can abolish the "administrator" package in the future by splitting it into a "janitorial" package (what is being proposed here) and a "moderator" package (block + protect). —Ruud 14:54, 26 July 2016 (UTC)

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)

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)

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

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)

Have you seen the WMF's annual leave entitlement...?! _Muffled ^Pocketed 11:34, 9 July 2016 (UTC)

So applicants for this permission group would have to go through a full RfA to get half the admin tools? Why wouldn't they got through the RfA, get ALL the tools and just use the ones they were interested in? Not getting the point of this at all. for (;;) (talk) 17:51, 23 July 2016 (UTC)

Please see Wikipedia:Moderators/Proposal#So_why_would_anyone_want_to_request_this.3F and #Have people actually been requesting this kind of a user-right?, below for some reasons/examples. - jc37 00:11, 24 July 2016 (UTC)

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)

• 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)

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)

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

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)

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)

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

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)

One place where there is rarely a backlog is the Cat expired PROD. I've seen them deleted at the rate of 1 every two or three seconds - that's even faster than I can load and read some of them. I'm sure some admins even hover over them with a mouse waiting for the clock. Kudpung กุดผึ้ง (talk) 11:32, 10 July 2016 (UTC)

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)

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)

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)

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)

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)

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)

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)

• 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)

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 is "only" to entrust "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)

• 1. No disrespect intended, guys, really not, but this is all beginning to look like a video game: 'Pick up the trophies here, then move up to the next game level'. A boon for the hat collectors and those who love Wikipedia because it's the biggest MMORPG in the world.

2. Bureaucrats are adverse to anything that would force duties on them beyond the terms of theitr current mandate: "We weren't elected for that, and it's not in the job description er ran for'.

3. WP:RRA probably wouldn't fly, because like BARC which was run due to a spate of complaints a) It's too difficult to desysop a badmin, and b) That's why not enough admins are being promoted, it turns out that it wasn't what the broader community wanted at all, and most importantly, where they had the chance, nobody came up with an alternative proposal. All they did (particularly the ones known for anti-adminism and general vociferous belligerence), was to massacre the GF intentions of the messengers. I'd list the names, but it would be a gross indiscretion and probably cost me my bit. They come out of te woodwork for every RfC of this kind though.

4. It's actually very rare for consensus to change - you have to wait for user attrition for that. I still say: Fix the voters and RfA will ix itself, and then we'll have enough admins to work on the backlogs but no one yet has attempted (or dared) to start an RfC on those lines. The real reason for the failure to create more admins is the most open secret on Wikipedia, but the community acts like ostriches.

5. I'd help if I could, seriously, folks, but after all these years campaigning for RfA reform, I've run out of ideas. I sadly only know the ones that probably won't work just as someone else's GF WP:RFA2015 didn't achieve anything spectacular and there is even growing concern that it actually multiplied some of the negative features it was intended to combat.

Kudpung กุดผึ้ง (talk) 12:32, 10 July 2016 (UTC)

1.) for video game hat collecting, look no further than WP:PERM... sigh

2.) nod, we've asked them follow up on that several times and they've re confirmed that several times (Which is part of why I restricted RRA to be as much like an RFA discussion as possible, so it reflected what they currently do.)

3.) pretty much true of jut about anything regarding anything related adminship or any userirghts related to admins. I mean look at this straw poll - I wonder if in this environment that the concept of bots would have ever gotten consensus. Much less bots being able to run at RfA for fewer abilities than the whole admin package: "If I trust them with some, I trust them with all". it's probably one of the most ridiculous arguments around. we have researchers, importers, checkusers, oversighters and so on, this is no different. And follow that up with: "I won't approve anything unless RfA is changed". Thing is, we still have RfA requests, will we stop any new requests because RfA is broken? We haven't so far. So would we stop a bot owner for doing an RfA for less user-rights than the whole admin package, because of the current state of RfA? We haven't with that either. So with all due respect to all involved, I think I'll just WP:AGF and just presume that they aren't thinking this through. The state of RfA has nothing to do with this proposal. Honestly the devs could easily create this usergroup (it's easy in the software), this is merely whether we'll allow people to ask for this package (which the WMF said must be through an rfa-like process). If someone doesn't like the proposal, fine, that's their right to express in the consensus model. But opposing because of some process which will be there whether this passes or not, is ridiculous imnsho...

4.) you made me chuckle @ ostriches : ) - Personally, I'd add the anti-admin/anti-rules factioneering to my list of reasons of why I think RfA is what it is, listed here.

5.) No worries. In my opinion though, sometimes we need to continue to tilt at these windmills. If we don't continue to try consensus it won't stay the robust living thing it is to be on Wikipedia, and what's more, developmental change will never happen : ) - jc37 20:58, 10 July 2016 (UTC)

Re: #4, it's not one faction. There are editors soured on the adminship concept because of enmity with some particular admins, but others observing serious problems with the system who have professional or other deep experience with organization governance. There are also "wiki-anarchists" offended by the idea that someone else has more editorial rights/privileges here than they do. Others are elitists and want to see stricter regimentation in this regard. The majority probably recognize that the system has problem, but are afraid to try anything different for fear of making things worse. These are all different angles. Then there are those who don't like that WP has rules, those tho appreciate the rules, but don't like that we have an admin class instead of just ANI enforcing them, those who hate centralized rules and want all or many rules to set by wikiprojects on a topic-by-topic basis, and those who want more rule centralization and an end to wikiprojects and topical guidelines, and the majority who think our rule system works fine as-is. These are all also different camps. The intersections can happen at any of these points. E.g., one can be a big fan of WP having centralized rules but be thumbs-down about the adminship system because it is malfunctional. Another can be wiki-anarchist across the board, opposed to both rules and admins. Another can be a decentralizer of rules, yet also an elitist (i.e. someone who wants more admins punishing more people for violating some wikiproject's rules), etc. There's a habit among both admins and admin-reform proponents here to suppose that there are a) those who support the current system and want to entrench everything about it, and those who would tear it all down, and they cast aspersions on each other's motivations. This is a false dichotomy, an illusion that leads to a lot of chest-beating and nothing practical.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:07, 15 July 2016 (UTC)

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)

That may be a good thing - protects pages like Module:Yesno that could be very disruptive... — xaosflux ^Talk 03:21, 10 July 2016 (UTC)

Indirect unprotection

There is an unwanted side effect from the proposed user group including delete and undelete but not protect. If you delete a page and then restore it, then its protection status is reset. This would effectively allow moderators to unprotect pages, even though they are not supposed to be able to alter protection settings. — Mr. Stradivarius ^{♪ talk ♪} 03:32, 10 July 2016 (UTC)

I obviously can't speak for the rest of the Committee, but I'd see this type of intentional gaming the system to be cause for removal of the permission. Callanecc (talk • contribs • logs) 03:40, 10 July 2016 (UTC)

Sounds incredibly dicey. I'm assuming this resets edit, move, upload, and create settings? And autoaccept too? (pending changes reset) — Andy W. (talk · ctb) 04:53, 10 July 2016 (UTC)

I have just tested it. Edit, move and upload protection is reset after deletion and restoration, but pending changes status persists. Create protection is also reset on page creation and deletion, so moderators would also effectively be able to unprotected create-protected pages. — Mr. Stradivarius ^{♪ talk ♪} 05:39, 10 July 2016 (UTC)

well, if pending persists, then I presume this may be fixable by devs? That aside, as Callanecc, notes above, any mod intentionally abusing the tools that way is likely to lose the tools. Presumably easy enough to restore protections and warn, and if necessary, tool removal. - jc37 06:58, 15 July 2016 (UTC)

Yep, protection level could be made to persist after deletion/undeletion, but I'm guessing that it not persisting might be regarded as a feature, not a bug. It might also be possible to make the persistence a setting which could be set differently for different wikis. If any change in this area is desired, that would probably be something to be discussed on the wikitech-l mailing list. — Mr. Stradivarius ^{♪ talk ♪} 03:04, 16 July 2016 (UTC)

Thoughts on feasibility

I think this would probably be a good idea in theory, but there are two issues I would like to see addressed before I will be convinced it is feasible:

1. Would moderators be able to delete any page they wanted (or at least any page admins can, i.e. those w/less than 5k revisions)? If not, how do you prevent them from deleting pages they shouldn't?
2. Would the process of becoming a moderator be less rigorous than that for becoming an admin, consistent with this role being a sort of ersatz admin who has some but not all of the rights of an admin? Everymorning (talk) 15:50, 23 July 2016 (UTC)

What's to stop them from abusing the tools given? The same thing that stops admins and anyone else given additional tools and responsibilities by the community - a.) loss of community trust, and thereby, loss of said tools. and b.) nearly every action (including deletion) is undo-able/reversible.

As for your other question, see #granting criteria?, above. - jc37 00:02, 24 July 2016 (UTC)

Try an option as a trial?

This is obviously a significant move on which there are enough opinions on each option to question if a consensus will be reached in any significant timeframe. Rather than make a once-and-for-all decision is it not possible to allow an option to be put in place for a period of time to get enough data, then deliberately step back and remove that option, and then have a discussion about how ECP worked in that timeframe / should that option be allowed permanently? (Or at least as permanent as anything in Wikipedia is...) I pulled back from listing that on the main proposal page, but maybe this belonged there instead? LaughingVulcan 13:01, 25 July 2016 (UTC)

Delete content viewing rights

How does this proposal square with the WMF's position that the access to deleted content should only be granted to administrators selected by a rigorous vetting process? Ruslik_Zero 20:29, 3 August 2016 (UTC)

@Ruslik0: It would be fine with the WMF, because, as proposed, this usergroup will go through a similar (if not identical) process that potential admins go through, i.e. RfA. — Andy W. (talk · ctb) 20:34, 3 August 2016 (UTC)

...this proposal requires the basically the same process as RfA, so that part is ok. — xaosflux ^Talk 20:35, 3 August 2016 (UTC)

If the process is the same, why anybody would want to go through the same process but not to get the full set? Ruslik_Zero 20:40, 3 August 2016 (UTC)

Most looking at this subsection then? — Andy W. (talk · ctb) 21:03, 3 August 2016 (UTC)

Thank you

I just wanted to say thank you to everyone who commented here and positively joined in the discussion(s).

I definitely now have some food for thought. I think what I was most surprised at is that the word moderator was a more a poison pill to the proposals than I had initially realised. You learn something every day : )

Again, thanks to you all, and happy editing : ) - jc37 11:20, 25 August 2016 (UTC)

"Wikipedia:Moderator" listed at Redirects for discussion

A discussion is taking place to address the redirect Wikipedia:Moderator. The discussion will occur at Wikipedia:Redirects for discussion/Log/2020 December 29#Wikipedia:Moderator until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Aasim (talk) 11:45, 29 December 2020 (UTC)