Wikipedia talk:Main page editor/Archive 1

Started

Hi Valereee. I've thrown some stuff onto this user subpage, where we can develop it into a full-fledged proposal. Feel free to ask any other Sane Editors who may be interested to join in drafting it. Please also feel free to modify my text as necessary, this is a draft, and there's no deadline. Vanamonde (Talk) 19:39, 25 September 2019 (UTC)

Unbundling edit-protect

Hi Xaosflux. Valereee and myself are planning to propose the creation of a new userright to allow main page regulars to work on main page content while it is protected. I know you've participated in some related discussions before (I know we had a conversation about it, though I cannot now find it); would you be interested in collaborating? Also (and irrespective of your answer to the above) would you help me understand your comment at this discussion, where you listed the rights that would have to be unbundled? I was under the impression it was only edit-protected and and protect; am I wrong about that? Best, Vanamonde (Talk) 19:11, 25 September 2019 (UTC)

@Vanamonde93: this is certainly something that you should workshop up before throwing to the wolves at VPP! I'd be open to consulting on it, in general I'm open to unbundling (though it's not really UN bundling, it is just creating an additional lesser-included group - you are not really trying to remove access from admins). There are several technical hurdles that would need to be dealt with depending on how you want to go about accomplishing the change. Once those are determined, there will be the usual pile of "community" hurdles, but all good things in time. So first things first: our main page is "cascade protected", which means it has "full protection" and anything transcluded on it (including nested transclusions) is also protected. A side affect of this is that you can add protection to any page by adding them to a transclusion. From a pure mediawiki perspective, there is one primary "permission" that allows this type of editing right now: (protect) which allows access to Change protection levels and edit cascade-protected pages. At the very least this would require developers to create a new permission such as "(editcascadeprotected)". Then a group could be used to assign both the existing "editprotected" and this new permission - allowing people to edit all those pages. It would also allow editing of things such as a protected template that was used in a system message (which normally required editinterface) so we'd have to at the least decide on what the "rules" were and accept that risk that someone could break the rules. Depending on what "rules" we make and how you want to go about implementing this I may be more or less supportive - but I'm still generally supportive of letting the proposal get a fair chance to be evaluated by the community at large. There are also a couple of "cheap" (in terms of developer time) ways to do this, though they have their own risks and may not get much community support:

1. Lower main page protection, at least by uncascading protecting it and using less protected transclusions for primary "content" sections controlled with existing groups (e.g. templateeditor or extendedconfirmed). This is how the Romanian Wikipedia (rowiki) does it for example.
2. Allow for "limited admins". This would give people access to the full admin tool set, but they would have a rule that "limits" them to specific things, breaking the rule could result in loss of access or other sanctions. This is an option at meta-wiki for example (c.f. meta:Meta:Requests_for_adminship#Other_access).
3. Create a new usergroup that adds existing mediawiki permissions of (protect) and (editprotected), along with rules for what they may be used for. (Like limited admin above, but with more tech controls - this is a very minor tech change unlikely to get developer pushback). Rules could be like "you may not use action=protect", "you may not edit pages transcluded to mediawiki space", etc. Such a group could possibly be used to do normal protected editing, such as processing approved edit requests on articles - or not, depending on what rules you want to use.

Does that help? — xaosflux ^Talk 19:55, 25 September 2019 (UTC)

Ping also to Valereee. — xaosflux ^Talk 19:55, 25 September 2019 (UTC)

@Xaosflux: yes, that's very helpful, thank you. I'm glad to see my technically ignorant self was not entirely wrong on most of it. My intent was to follow option 3. Option 1 has been shot down before, and has people yelling "security!". Option 2 is possible, but it a) seems complex and b) is going to give access to viewing deleted content, which isn't logged, and therefore cannot be monitored, and which the WMF won't give out without an RFA-like process, and so cannot be handed out without such a process without monitoring...so I think it's less likely to get anywhere. If it's okay with you, I will copy this discussion over to the user subpage I just made, so we can continue discussion in a single location. Vanamonde (Talk) 20:01, 25 September 2019 (UTC)

@Vanamonde93: oh sure that's fine. Option 3 above is about as easy to do as creating some of the other more recent groups such as extendedmover and Wikipedia_talk:Page_mover/Archive_1#RFC_-_Proposed:_"Page_mover"_permission_to_be_created is a fairly decent framework you may be able to reuse. It is a good idea to start with a clear definition of the problem, and a proposed technical solution - possibly even ruling out why other not-yet-existing tech solutions are not a good idea. Leaving a lot of the "rules" open to comment helps encourage people to contribute (e.g. the "criteria for granting", "criteria for revoking" sections). As well as if you want it to "be more" (e.g. not just limit it to one problem). — xaosflux ^Talk 20:08, 25 September 2019 (UTC)

Copied over from [1] by Vanamonde (Talk) at 20:09, 25 September 2019 (UTC)]

@Xaosflux: (moving over here, as discussed) Thanks, yes, that framework is helpful. I'm glad to see I was thinking along similar lines to Xeno, although the user page is still in its infancy. I will work on it over the next few days; please feel free to edit or comment, and expect that I will have a couple more technical questions for you :) Vanamonde (Talk) 20:13, 25 September 2019 (UTC)

MPP only?

Worth exploring if expanding to "Protected content editor" would be better. Still bound by the rules of the protection policy, but not just for "main page content". I think that may be so niche that it may get shot down. Approving very-tiny groups doesn't get a lot of support (the last one was probably WP:EFH). — xaosflux ^Talk 20:34, 25 September 2019 (UTC)

@Xaosflux: here's my reasoning. The number of users is small, yes; but the requests for assistance are frequent (at ERRORS and ITN/C in particular) and, often, shrill. Addressing those requests is a skill set that regulars at ITN/C or elsewhere already have. The number of requests for editing fully protected pages is not that high. More importantly, those pages can be absolutely anything, including stuff plagued by edit-warring. A skilled content writer, which is the category of editors we're looking at here, may not be much help in addressing a protected edit request on a disputed page, and indeed the category of editors we're looking at may well steer clear of those disputes. What I'm getting at, I guess, is a niche userright for users with a niche skillset that shouldn't have to run the gauntlet of RFA. Expanding it to "protected content" would increase the pool a little, but increase the required skill set, too; and make it perhaps harder to judge. That said, I'm open to persuasion. Vanamonde (Talk) 20:57, 25 September 2019 (UTC)

@Vanamonde93: sounds fine - technically there is no difference since this is an "administrative control" (a rule) for usage. It could possibly be expanded later once activated by a new referendum. On the "back end" we should reuse the standard group name that is used else where (e.g. eswikinews) of "editprotected" , but we can localize it to what ever we want "e.g. Main Page editors". I think "editors" is a better local name than "protector" since it more reflects what the people would use the access for. — xaosflux ^Talk 21:43, 25 September 2019 (UTC)

@Xaosflux: *sigh* I got three hours of sleep last night. I know for a fact I intended to create this at "main page editor"... Fixed now. As to the rest; yes, precisely; I think if this were to pass, and someone wanted to explore expanding the scope of the userright, it could be expanded. I named it "main page editor" to make it clear what the function was; if it were expanded, renaming the right shouldn't be that difficult, either. Vanamonde (Talk) 22:17, 25 September 2019 (UTC)

Creation procedures

I've been looking into precisely how one goes about creating policy, and I've only gotten more confused. First, some of the pages for userrights are policy, and some are guidelines. Second, I'm seeing a bit of a chicken-and-egg problem with writing the policy page, because the details are often going to be finalized depending on what users say at the RfC, but the whole page needs to be approved at the same RfC; or do we have to iron out every kink beforehand, and have people only approve/disapprove at RFC? Vanamonde (Talk) 23:04, 25 September 2019 (UTC)

@Vanamonde93: so, it is by RfC. Good news, I don't think you have a lot of "policy" to make here. Most of the policy around this would be in when and how users in this group may use this access, so it is mostly a continuation of the protection policy. As far as codification goes, this would likely be a Category:Wikipedia procedural policies just like how Wikipedia:Page mover or Wikipedia:Edit filter helper is. A good way would be to mock up the proposed page, then discuss it until it is agreed to. It would need to be advertised at relevant venues, left open for a decent amount of time (e.g. a month), and well attended by editors - then it just comes to life. — xaosflux ^Talk 23:16, 25 September 2019 (UTC)

Xaosflux, Well that's the essence of it, I suppose, but my questions is whether it needs to be finalized before it goes to an RfC? Or can it be modified during? With other proposals we tend to play fast-and-loose, modifying non-controversial stuff as we go; but I was wondering if this had to be different. Vanamonde (Talk) 23:31, 25 September 2019 (UTC)

@Vanamonde: Ah as for that, patience is key on these. I suggest work shopping a bit more here first, then making the new page - mark it as draft proposal, then invite some people to help work it over for about 2 week ("Input welcome on a draft proposal" type) - only advertise at like WT:PERM and maybe some of the main page related forums. After it is good and drafted up, then start the rfc with heavy advertising and room for people to endorse or work on changes. — xaosflux ^Talk 00:23, 26 September 2019 (UTC)

Makes sense. I'm in no hurry. Certainy I need to draft, walk away for a bit, and come in and redraft, and do that a few times. Vanamonde (Talk) 00:53, 26 September 2019 (UTC)

Xaosflux, you think the request needs to be open a month? --valereee (talk) 17:51, 26 September 2019 (UTC)

@Valereee: a month is pretty standard for an RfC related to user groups. RfC's can certainly SNOWball though, but that determination is best left to uninvolved closers. — xaosflux ^Talk 18:02, 26 September 2019 (UTC)

Oh, duh. I had just been working on the draft and had the user rights request in my brain. :D --valereee (talk) 21:15, 26 September 2019 (UTC)

What is a successful request

I've changed the wording for this to "The discussion will be closed by an administrator, who will grant the right if there is consensus that the editor will use the main page editor userright within policy." This is to avoid grudge matches, and make it a burden of proof on those opposing. Thoughts are welcome. Vanamonde (Talk) 00:23, 4 October 2019 (UTC)

No blocks or sanctions

On the one hand, this seems reasonable; on the other, it will immediately eliminate the editor who would otherwise be the most prolific user of this right, and is likely to engender drama as a result. Valereee, I'd particularly appreciate your thoughts here. Vanamonde (Talk) 00:34, 4 October 2019 (UTC)

I think we can remove the no sanctions part. The penalty for violating a sanction deals with that concern. We can deal with it by discussing in the RfC. --valereee (talk) 18:34, 4 October 2019 (UTC)

Those are my thoughts, too. I don't see how any existent sanctions need to disqualify someone a priori; objections based on sanctions, and more importantly on behavior that led to sanctions, can be brought up during the discussion. I will remove this point. Vanamonde (Talk) 20:16, 4 October 2019 (UTC)

Actually, hang on; you're referring to just the sanctions part? Honestly, I think a TBAN from ITN/C, for instance, is more disqualifying than an edit-warring block; I think we can remove this condition altogether, and trust that editors will bring up relevant stuff when commenting on requests. Vanamonde (Talk) 20:18, 4 October 2019 (UTC)

Yes, I was referring to just the sanctions part, but I get your point. Maybe we should add TBAN to the inappropriate uses and remove recent blocks from the criteria. I'm also wondering if we should remove the ext autoprotected and the 50 edits within the last year part? Those are too low, really; no reasonable person would think either was enough. So are they even helpful? --valereee (talk) 21:08, 4 October 2019 (UTC)

Technical clarification

@Vanamonde93: are you intentionally referring to this as a new userright (underlining added) as opposed to a usergroup? A user right is the specific technical ability, like block or noratelimit, while a group gives members of the group the rights specified for that group. --DannyS712 (talk) 00:16, 27 October 2019 (UTC)

@DannyS712: That's a subtletly I simply hadn't considered. Based on your comment, I suspect what I mean is "usergroup", but I'm going to ping Xaosflux, whose knowledge of things technical is far superior to mine. Vanamonde (Talk) 18:15, 27 October 2019 (UTC)

It's just wordsmithing - from what I've read above yes - you are looking to create a new usergroup, and to give that group some permissions. — xaosflux ^Talk 18:17, 27 October 2019 (UTC)

I've cleaned it up accordingly. If and when this RfC is closed as successful, if someone could ping me I'll submit a patch on gerrit to create the group and associated messages DannyS712 (talk) 18:29, 27 October 2019 (UTC)

Grant by crats

Concerns allayed --DannyS712 (talk) 23:46, 27 October 2019 (UTC)
The following discussion has been closed. Please do not modify it.
Hi. I can elaborate further via email if desired (beans), but I'd like to suggest that this right only be grantable by crats, while still being removable by admins (and crats). I'm reminded of Wikipedia:Village pump (technical)/Archive 174#Weird new user account - if an admin account is compromised and vandalizes the main page, it will be reverted and dealt with. If an admin is compromised and grants vandal accounts this right, and then covers their tracks, it'll be a bit harder to deal with. --DannyS712 (talk) 18:33, 27 October 2019 (UTC) @DannyS712: To be blunt, I don't think that's much of a concern. Userright changes are logged, and are searchable by performer. The set of users holding this permission can be checked within seconds. We're not looking at thousands of users, like rollback, either. Finally, compromised admin accounts are usually noticed within hours. For this to be a danger you would have to have a compromised admin account that isn't engaging in obviously bad things to grant this permission to other users who wouldn't obviously be a red flag; and even then, they wouldn't have long to muck around. Vanamonde (Talk) 18:46, 27 October 2019 (UTC) @Vanamonde93: and yet, if you look at the example above, it was only noticed because I happened to be practicing my sql DannyS712 (talk) 18:48, 27 October 2019 (UTC) @DannyS712: That was an account that hadn't done any damage; that's why it remained undetected. A compromised admin account that is sneaky can do a lot of bad things that aren't immediately disruptive. But this userright won't increase the risk much, because if main page disruption actually happens, there isn't much difference between stopping a compromised admin account and stopping a vandal account given this permission by a compromised admin account. Vanamonde (Talk) 18:53, 27 October 2019 (UTC) @Vanamonde93: Emailing you now DannyS712 (talk) 18:54, 27 October 2019 (UTC)

There is existing precedent for administrators granting one of the big three (page deletion) in the form of the page mover, who can technically delete a page via moving it and not leaving behind a redirect. So I don't think this is a major concern or change in our current user granting framework. I would appreciate if bureaucrats could also add and remove the permissions, but this is a selfish request. –xeno^talk 18:18, 30 October 2019 (UTC)

Xeno, I'm not sure I'm following -- you're saying you'd like crats to be able to also add/remove the main page editor permission we're discussing? Why would they not be able to? Oh, are you just asking that we include that in the proposal so that's it's clear that's what's intended? --valereee (talk) 18:40, 30 October 2019 (UTC)

Valereee: There is, at present, one non-administrator bureaucrat who would like to re-gain the technical ability to grant and remove all local user groups. So if the proposal would also grant bureaucrats the permission to add and remove these userrights, that would be nice. –xeno^talk 18:48, 30 October 2019 (UTC) (Something like this: Special:Diff/923780381)

Lol, got it. Sorry, I didn't realize that was even a thing. I can't imagine what objection there'd be to it, so I'll add it! --valereee (talk) 18:55, 30 October 2019 (UTC)

I took it back out in Special:Diff/923932640, simpler. Short discussion at User talk:Xaosflux#vestigial abilities on the subject. –xeno^talk 18:25, 31 October 2019 (UTC)

Request advertisements

Should re-visit if advertisements, especially if they will be held on a new backwater venue - since this gives out powerful technical permissions. Listing at SIX places that are also somewhat specialty may not be the optimal place. May consider requiring WP:AN as well here. — xaosflux ^Talk 04:57, 29 October 2019 (UTC)

No issues with requiring cross-posting the request to AN. Vanamonde (Talk) 17:17, 29 October 2019 (UTC)

No objection. --valereee (talk) 11:28, 30 October 2019 (UTC)

Oauth

DannyS712, I think by this edit which adds as well as the ability to activate two-factor authentication (oathauth-enable). you're indicating that this technically requires adding this? Do we need to address any repercussions? --valereee (talk) 19:52, 30 October 2019 (UTC)

I think DannyS172 was being bold, and adding it because they believe MPE's should have 2FA and therefore would need to be able to activate 2FA. I don't think they have to have it. If it's going to be a sticking point, then we shouldn't; I'm a little concerned about the length to which this page has grown. Vanamonde (Talk) 20:00, 30 October 2019 (UTC)

We would absolutely not require these editors to activate 2FA. We may encourage them - and this access would allow them to voluntarily opt-in. — xaosflux ^Talk 20:04, 30 October 2019 (UTC)

I was saying that they should be able to - as Xaosflux points out above, we shouldn't be requiring it. This merely grants them the ability to activate 2fa. --DannyS712 public (talk) 20:04, 30 October 2019 (UTC)

Oh, I'm sorry, I misunderstood. I thought adding the edit protected etc. permissions meant that these editors would be able to enable two-factor FOR OTHERS. That the ability to do these two things were somehow technically bundled together and couldn't be separated. Nevermind, I'm an idiot --valereee (talk) 20:22, 30 October 2019 (UTC)

Wugapodes from WT:DYK

@Wugapodes: Pursuant to your thread at WT:DYK#More_preps?, your idea there of adding Special:ListUsers/templateeditor would add 175 people who could edit the main page (if I understand you), might be of interest to those discussing the Main Page Editor idea here. Pinging @Vanamonde93: and @Valereee: My own opinion, experience at being an admin over there, is that the best of intentions, skills and knowledge, does not make an admin immune from becoming a human pin cushion. Burn out happens. — Maile (talk) 02:18, 8 October 2019 (UTC)

Oh wow, this is great! I've got a train ride coming up soon, so I'll read through this then. At first glance, I think a point of contention will be granting protect. I'm no expert (probably the opposite) but I can take a look at the phabricator ticket Vanamonde linked further up about splitting edit-cascade-protect and protect. If that can be done, I think it will be easier to build consensus since people won't have to worry about someone going on a page protection spree. Wug·a·po·des​ 02:34, 8 October 2019 (UTC)

@Wugapodes: I would love for those rights to be split, but see the discussion above; there seems to be some resistance to doing it without a community discussion, which seems silly to me, but which I haven't the time or energy to pursue. Vanamonde (Talk) 03:37, 8 October 2019 (UTC)

@Wugapodes:, check the project page, too, if you haven't, as we're trying to address such objections as this right conferring the ability but not the right to edit protected pages; it's a trust position and would only be given to those who we trust not to, for instance, go on a page protection spree. In fact the 'innappropriate uses' section specifically calls out protecting, unprotecting and changing protection levels and editing through full-protection as behaviors that would result in removal of the right. We're trying to come up with ways to address most of the possible objections before we even start workshopping. --valereee (talk) 12:31, 8 October 2019 (UTC)

Personally, I'm fine with that, but (and I'm happy to be wrong) I think people will be suspicious with giving the ability even if not the right. As much as I prefer meatball:SoftSecurity, I appreciate that for some people and in some situations, technical restrictions are preferable to social restrictions. Block-delete-protect seem to be pretty core to admins and spinning out any of those will be contentious. Even just looking at the RfC on resysop criteria, I think this will get a similar response as there: just nominate more DYK/ITN/TFA/etc regulars. And especially so if the technical ability to protect pages is included, even if not the right; if the user is trusted enough to not abuse protect, they should be trusted enough for adminship, etc etc. It's not an argument I particularly buy, but it's one I'm sure will come up and could be addressed by technical restrictions.

There might be a solution in edit filters. If we can set up an edit filter that prevents taking ?action=protect for users not in the administrator user group, or even just logging it for easy monitoring, I think it would be easier to convince people to give protect since there would be technical restrictions on its use. @Xaosflux: would you be able to say how feasible such an edit filter would be? Looking at the documentation it doesn't seem the action variable handles protection; is there a reason why, and how hard would it be to get that added? Wug·a·po·des​ 21:26, 8 October 2019 (UTC)

@Wugapodes: not "easy", the abusefilter does not hook on to the protection table so it doesn't have any visibility to that type of action (just like it doesn't hook on the the block table or lots of other things). I think if developer time was going to be spent building technical controls that it would be better spent splitting protect and editprotected. — xaosflux ^Talk 21:57, 8 October 2019 (UTC)

RfC for allowing page movers to move protected pages

The discussion at Wikipedia_talk:Page_mover#RfC:_Should_Page_Movers_be_permitted_to_move_move-protected_pages? may be of interest to us, as it involves almost this exact situation, only from the opposite direction: allowing page movers to move protected pages would require giving them the ability to edit protected pages. --valereee (talk) 10:02, 17 October 2019 (UTC)

Protection toolset

I don't have a remote expectation that the community will un-bundle the permission of protect (which is vital to edit cascade-protected pages) thus allowing non-admin folks to fiddle with protection levels on all pages. ∯WBG^converse 09:41, 27 September 2019 (UTC)

@Winged Blades of Godric: as written above it won't "allow" them, only "enable". I'm enabled to use protect, but I'm not allowed to just "fiddle" with it. But I agree, it is a risk that would have to be evaluated. — xaosflux ^Talk 12:28, 27 September 2019 (UTC)

There's a valid point that anybody who is trusted enough to deal with main-page shall be expected to not go rogue and disrespect bright-line boundaries about not using the protection tool-set, absent an IAR justification.

I expect the community to not be supportive of such measures but on some re-thoughts, this section title is too negative than the reality. So, I will re-title. ∯WBG^converse 12:54, 27 September 2019 (UTC)

@Winged Blades of Godric: I think it may be contentious as well and would prefer to see phab:T71607 get made first. — xaosflux ^Talk 13:18, 27 September 2019 (UTC)

Xaosflux, a fix (commited by MGChecker) was merged but was since-reverted by a staff-engineer due to lack of any test-case.

That ain't a problem anymore and I am paging MGChecker about whether the patch needs to be re-written prior to a re-submission and all that. ∯WBG^converse 13:38, 27 September 2019 (UTC)

The larger problem there is to reach consensus whether this makes sense or not. If you are able to edit a cascade protected page, you would of cause be able to protect other pages as well, by just adding something like <div style="display:none;">{{:PageToProtect}}</div>. In my opinion, there are semantic differences large enough to split this though, as I outlined before. I believe that there would have to be a consultation with the mw:Core Platform Team to get this through (or not, depending on their decision).

One technical note: There can be multiple layers of cascade protection. For example, you could allow cascade protecting pages on extendedconfirmed level and grant that permission to this group instead, which would effectively create a new protection layer for people with protect, but no editprotected permissions.

Have you considered alternatives? There are wikis like nlwiki, which do not use cascading protection for the main page, but just semi protection. At dewiki, most rubrics can be edited by editors (300 edits/60 days). Separate pages for each weekday, to which is copy-pasted, are used for this. Maybe cascade protections is no must-have here. --MGChecker (talk) 15:14, 27 September 2019 (UTC)

@MGChecker: I noted that above with an example too (nowiki uses template editor for main page), I think due to our huge internet visibility not using cascade is a non-starter. As far as the "someone could do something disruptive" with div transcludes etc, yup they could - they could also be blocked/degrouped or otherwise sanctioned for breaking policy. — xaosflux ^Talk 15:18, 27 September 2019 (UTC)

I do not really see a difference to other language versions there, they have just the same vsibility for their respective languages. And rollbacking changes and demoting people who would abuse their extendedconfirmed permissions is easy, it is not like you would have a vandalized homepage for several minutes. As the templates transcluded into the homepage should be quite contstand, their protection can be done manually, instaed of by cascade. --MGChecker (talk) 15:33, 27 September 2019 (UTC)

@MGChecker: 500million views/30 days (enwiki) to <1million (nowiki) or ~4million (nlwiki) is the difference. — xaosflux ^Talk 16:05, 27 September 2019 (UTC)

dewiki has at least 40 million. However, we seemingly disagree if this is an important metric anyway.

I would be willing to support any motion to split these permissions, anyway. For a start, the protect button could be hidden via CSS for this group. --MGChecker (talk) 19:19, 27 September 2019 (UTC)

@MGChecker and Winged Blades of Godric: Apologies for a delayed response. My logic here is as follows. The purpose of this exercise is to get some users additional tools that will ease the burden on administrators who do main-page related activities. If getting this through requires me to make a proposal on meta to first split two permissions, I'm just going to drop the whole issue, because Wikipedia would be better served if I spent my time elsewhere. This is especially true because I simply don't understand the logic behind "this user right allows a user to do X, which they are qualified to do, but also Y, which they are not qualified to do, so we cannot give them this userright". This is true for EVERY user right on Wikipedia. I have the technical ability, as an admin, to block anyone I disagree with. I am prevented from doing that not by technical restrictions, but by policy. We can apply administrative controls to prevent abuse of this userright in the same way. Now splitting the userright would reduce the technical possibility for such abuse, and as such it would be quite nice; but I don't think anyone here is going to go to the trouble of proposing something on meta just to improve the chances of passage for a proposal that will grant additional userrights to a few editors here on en.wiki. Vanamonde (Talk) 22:03, 3 October 2019 (UTC)

WBG, what kinds of objections would you expect? I feel like if we can identify the reasoning behind potential objections and try to deal with them up front, it could help. --valereee (talk) 15:57, 27 September 2019 (UTC)

I figure one problem might be that the "protect" user right cannot really be restricted. Normally, when we give people extra permissions we give them full access to said extra permissions, not "you have now X permission with buttons A-E but you are now allowed to use buttons C and D". Jo-Jo Eumerus (talk, contributions) 16:59, 27 October 2019 (UTC)

If assigning the "protect" userright is not acceptable...

Right now, one potential sticking point with this user right is that you need the "protect" permission to edit cascade protected pages such as the Main Page. If that is unacceptable, one might consider removing cascading protection from the Main Page and replace it with either:

• An edit filter that prevents edits from non-admins and non-main page editors to the Main Page and the transcluded pages.
• Some kind of hard-coded protection for the Main Page and perhaps selected templates that can't be altered by the "?action=protect" function (but perhaps through a MediaWiki namespace page?)

Such a change is technically outside the scope of discussing this permission, but it might become a necessary ancillary change. And since edit filters and other unusual protection methods are less straightforward to undo than a cascade protection, they might provide a more robust protection than cascading against e.g compromised accounts. Jo-Jo Eumerus (talk, contributions) 17:07, 27 October 2019 (UTC)

@Jo-Jo Eumerus: We have a bit of a chicken-and-egg problem here; under the current system only sysops need to edit the main page; so the motivation for changing the system of main page protection doesn't exist unless coupled with this proposal, which might make it too complex. Nonetheless, it's a good point; and my current thinking is that if this fails, and the +protect right is a substantial reason for the failure, then a proposal along the lines of what you suggest might be necessary. Vanamonde (Talk) 18:30, 27 October 2019 (UTC)

I can create a database report of any main page editor that alters the protection of a page (already approved in Wikipedia:Bots/Requests for approval/DannyS712 bot 59). That being said, it'll be hard to verify if it is working if no-one breaks the rules... --DannyS712 public (talk) 18:59, 30 October 2019 (UTC)

• The "best" way to do this would probably be to push to get phab:T71607 done, then just add "editprotected" and "editcascadeprotected" to a new group which frankly could be used for other types of protected editing (might even allow us to downgrade an adminbot too). — xaosflux ^Talk 19:20, 30 October 2019 (UTC)

  @Xaosflux: I agree with you, but see the above discussion. I don't want to create a proposed on meta just for this; I haven't the time or the stamina. Vanamonde (Talk) 19:27, 30 October 2019 (UTC)

  This wouldn't really be a meta-wiki concern @Vanamonde93: - its a mediawiki one :) That is: this would simply be software development for mediawiki core, which is used by more than just WMF wiki's (though we are the biggest 'customer'!). — xaosflux ^Talk 19:33, 30 October 2019 (UTC)

Why not adminship?

I know I said I'd comment a few weeks ago, but I've been stewing on this for a while. The question I can't shake is what group of users would meet this level of trust but not pass an RfA? I think this has been discussed above, but not in its own section. Given some of the comments at merging the NPP and AFC rights, I think this will be a significant question about whether a new user group is warranted. There are definitely people who do not want admin tools, but are there enough that it makes a new user group worthwhile? Are there other situations I'm overlooking? Wug·a·po·des​ 00:12, 29 October 2019 (UTC)

Well, adminship has a lot of ancillary requirements (experience with deletion etc.) that is not really germane to maintaining the main page. Jo-Jo Eumerus (talk, contributions) 07:04, 29 October 2019 (UTC)

Wug, one of the most experienced and committed workers at DYK has been approached multiple times and does not want to run, and that's just to my knowledge. I suspect there are other regulars at DYK who would be willing to request this permission but aren't interested in adminship. It's not that they couldn't pass an RfA. It's that they aren't really interested in adminship. But some of them probably would be willing to do this one task that currently requires admin status. I only ran for admin because I couldn't do this one DYK task that was often backlogged. --valereee (talk) 12:48, 29 October 2019 (UTC)

@Wugapodes: I can start listing names if you like; but I think you may be convinced more easily if you look through DYK and ITN talk pages, looked at the number of people who could do good work on the main page, and then asked whether they would be able and willing to get through an RFA. Vanamonde (Talk) 17:15, 29 October 2019 (UTC)

Besides, I can think of one good candidate who failed RFA just a while ago. Jo-Jo Eumerus (talk, contributions) 17:32, 29 October 2019 (UTC)

@Vanamonde93: (et al) it's not that I don't think there isn't a use case rather I see "why not more RfAs" as a main point of contention and having a good answer before it gets brought up will be useful in building consensus. At a lot of recent RfCs (de-sysop and expanding page mover rights are two that come to mind) a common objection is that we should be encouraging more people to run for RfA rather than modify our existing policies or user groups (e.g. Beeblebrox in the page mover RfC: we already have ... too many levels of user rights, we should only be adding more when there is a demonstrable, serious problem that can't be resolved with the current tools at our disposal.). While it's maybe obvious to us that there are many DYK regulars who don't want the bit or potential candidate who would or have not succeeded at RfA, making clear that there is a group we trust to work on the mainpage but who will not be admins any time soon is important to stave off the "solution in search of a problem" or "if you trust them with protect have them run an RFA" !votes.

To be a little more constructive, I think the rationale should focus more on the mainpage regulars who do not want adminship and why trying the "recruit more regulars to RFA" has failed.

• Why do these regulars not want to become admins? The rational section says these editors don't want to go through what RfA has become, but some people will say it's become a lot better in recent years.
• Even if they just don't want to (we can't force someone through RFA), how would this process be more amenable to them?
• Is there a ballpark estimate of how many mainpage regulars have turned down an RFA? That could help show the magnitude of both potential use but also how other efforts have been tried and so far unsuccessful.
• Are there specific declines that would be useful to point to, or are there any "testimonials" about how this scheme would be more amenable that could be pointed to in the rationale?

There's an obvious success in Valereee getting the bit, but presumably a fair bit of work went in to getting just one regular through an RFA, and Jo-Jo Eumerus brings up a counter example of someone (I assume we're thinking of the same person) who would be trusted with protect but maybe not block or revdel. Being more explicit about what got us to the point of viewing a new user group as the only option, I think, will go very far in preventing knee-jerk and pile-on opposition to a new user group. Wug·a·po·des​ 21:41, 29 October 2019 (UTC)

FWIW, I just suggested an RfA run to a DYK regular. They said no because RfA is daunting and they really aren't sure they want to be an admin, are more focussed on content creation. --valereee (talk) 13:47, 31 October 2019 (UTC)

Revocation processing

Should probably be at WP:AN since it's going to end up there anyway in most cases. — xaosflux ^Talk 04:57, 29 October 2019 (UTC)

Is there a way to transclude sections of a talk page? I get the need for more eyes; I also think it would be very very useful to have the history of the userright be located in one place. Vanamonde (Talk) 17:17, 29 October 2019 (UTC)

The history of rights changes should be in the rights log, preferably with permalinks. — xaosflux ^Talk 18:29, 29 October 2019 (UTC)

No objections to having revocation processing be at AN. We could just put a notice at the other? --valereee (talk) 11:15, 30 October 2019 (UTC)

xaosflux, would you be willing to revise the proposal to reflect what you're thinking of so others can react? I don't feel like I know exactly what you're proposing well enough, but I'd like to get the section updated before we start actively workshopping. --valereee (talk) 13:56, 31 October 2019 (UTC)

In most cases, involuntary removal of user access is done at WP:AN (and normally that is also where a user would request self-removal). These are for-cause, and having wider input on those situations is generally warranted. — xaosflux ^Talk 14:06, 31 October 2019 (UTC)

Okay, I took a stab, lmk if I didn't get it! --valereee (talk) 15:01, 31 October 2019 (UTC)

Request venue

I don't think yet another permissions requesting venue is a good idea here, perhaps just roll this in to WP:PERM. — xaosflux ^Talk 04:57, 29 October 2019 (UTC)

My concern is that PERM is designed for request at admin discretion, at the moment. It doesn't handle other requests; see Wikipedia:Requests_for_permissions#Handled_elsewhere. As such I think it would be preferable to handle this at a specialized noticeboard, with an addition to that list I just linked pointing people to this noticeboard. Vanamonde (Talk) 17:20, 29 October 2019 (UTC)

Perhaps we could use Talk:Main Page? Seeing as it is the discussion page for the page that this is all about; also I suspect there won't be that many requests for this permission. Jo-Jo Eumerus (talk, contributions) 17:31, 29 October 2019 (UTC)

Maybe only Talk:Main Page and WP:AN? — xaosflux ^Talk 18:28, 29 October 2019 (UTC)

Talk:Main Page is something I am amenable to, but I don't want to open the proposal to "oppose; not the purpose of Talk:Main Page". I honestly don't see much problem with creating a new discussion venue that will be centralized for all things related to this usergroup. I'd like to hear more opinions about this; I don't feel too strongly. Vanamonde (Talk) 19:04, 29 October 2019 (UTC)

I don't have a strong feeling about having the noticeboard, but I guess I don't see the harm. Do agree that there likely won't be a lot of requests for this permission. Talk:Main Page seems like the wrong place, though. Maybe an initial notice there, but we're talking about a page with like 114,000 watchers, the vast majority of whom will have no interest in these requests. Having the discussion there turns a request into something incredibly public as every tweak to every typo then duly goes by on 114,000 watchlists. Honestly that would make it scarier than RfA, I'd think. --valereee (talk) 11:25, 30 October 2019 (UTC)

Adding: I think this might be something that could benefit from workshopping? --valereee (talk) 13:58, 31 October 2019 (UTC)

I think you make a good point, Valereee. At least a part of the need for this process is driven by people not wanting to be admins because RFA is so nasty. I think an open discussion at AN is going to be perceived quite differently than a discussion at WT:MPE with a neutral notification at AN. Unless this is a make-or-break issue for you, Xaosflux, I'd prefer to keep things as they are, at least until we've had more comments about it. Vanamonde (Talk) 15:30, 31 October 2019 (UTC)

@Vanamonde93: I really not sure how behind the proposal I am, but am still open for helping on it. Personally, the venue is not that big of an issue for me at all provided that there is an advertisement made at WP:AN to where ever the discussion is taking place. It could even be at something like WT:MPED/Username. — xaosflux ^Talk 15:36, 31 October 2019 (UTC)

Rules for granting

From a technical perspective, we would need to define what user groups may "add" and "remove" this group from others. That isn't quite the same as our "rules" again. Most of these rights are "administrator" is the one who can do that, and it seems fairly reasonable. Our rules would be if it required some process to be followed, or if it was just "admin discretion" - if rules are needed and admins don't follow them they can be sanctioned just like for breaking other rules. — xaosflux ^Talk 22:19, 25 September 2019 (UTC)

With respect to user groups, admins was what I was planning, and requests at WP:PERM as the default, although I don't see why admins adding it at their discretion to users who meet the criteria would be a problem. With respect to criteria, I'm going to go read some of the other criteria, but I'd like to leave it fairly open: along the lines of "Users who have demonstrated experience and judgement in curating content that appears on one of the following areas of the main page, and who are able and willing to work in those areas." Or something. We don't want editors trying to collect this as a hat, which definitely happens with rollback and NPP, IMO. Vanamonde (Talk) 22:28, 25 September 2019 (UTC)

@Vanamonde93: personally, I'd prefer that it goes through at least something like Wikipedia:Edit_filter_helper#Requirements_for_granting (i.e. that is has a public ask and discussion period, though there isn't a requirement that the discussion is participated in - as opposed to just "because I said so" from admins) - but that should be an RfC question, not a tech problem. I think such a process discourages hat collecting. Most WP:PERM discussions are fairly easy going - nothing at all like RfA. — xaosflux ^Talk 22:53, 25 September 2019 (UTC)

Hmm, that's an interesting idea, yes. It would also make it less prone to accusations of cronyism. My issues with hat collecting were more with respect to specific numbers of edits, etc; I think we should avoid that even if we create an EFH-like process. We could even propose both and see which gains consensus. The other requirements at EFH are common-sense, and wouldn't be controversial, I think, but are definitely a good idea (no blocks, etc; probably a minimum of 30/500 tenure). Vanamonde (Talk) 23:00, 25 September 2019 (UTC)

I think there's a benefit to having there be a public ask/discussion in that being able to edit the main page is something that probably needs input from editors/admins/commenters who are active at main page projects, rather than any random admin who may not be familiar enough with the project processes and the individual work of a given requestor. Even an admin who works on these projects using their own sole discretion seems like a recipe for encouraging cronyism. --valereee (talk) 16:45, 26 September 2019 (UTC)

@Valereee: Okay, you've persuaded me. Feel free to write something like that up; I'm a little busy at the moment. I'll get to it later if you're not keen. Vanamonde (Talk) 17:20, 26 September 2019 (UTC)

• @Valereee and Xaosflux: I now agree with you that we need a request that other editors can comment on; but I'm not sure we need the other criteria from EFH, so I've trimmed them. I'm open to discussion if we still need a) a way for admins to give it out at their discretion, and b) need to make that process a one-time only thing; as in, if you screw up and have it taken away, you can't regain it ever via the discretionary process. Vanamonde (Talk) 00:16, 4 October 2019 (UTC)

  Vanamonde Is there a reason you're thinking of that we'd need admins to be able to give this out at their discretion without a request/discussion? Like are you thinking someone so gnomish and confrontation-averse that even though they'd be great at this, they couldn't face the discussion period? (Pinging you only once, though I've made replies in other sections) --valereee (talk) 17:53, 4 October 2019 (UTC)

  Ugh...pinging you correctly: Vanamonde93 --valereee (talk) 17:54, 4 October 2019 (UTC)

  @Valereee: I'm not sure. I think it's a tradeoff between making it partially discretionary, and having more people use it but possibly attracting more opposition during the RfC, and making it "safer" from abuse (and therefore more likely to get support) but possibly less likely to be requested. I'm going to turn this question around to you, as someone who was in the target audience for this right not very long ago; would this have affected your decision to request this? Maybe I'm just overthinking it; in the absence of a reason for complexity, simpler rules are better, and so a request-only system is best...Vanamonde (Talk) 20:30, 4 October 2019 (UTC)

  Vanamonde93, honestly, if I'd had the option to request this, I likely would not have run an RfA. The prospect was terrifying; when Ritchie approached me my response was something like, "Thanks, very flattering, but I don't think I have the competence." And I am a person who in general can deal with confrontation and criticism. I just thought an RfA would likely be humiliating, with people dragging in every dumb move I'd ever made, every dumb question I'd ever asked, and asking me tricky policy questions I'd have no idea even where to go to find the answers to. I guess in the end what I'm saying is that, yes, it would be a good thing if someone who would be GREAT at this but who is just not up for the request process could be given the tools. But I can't think of any way to set that up without hamstringing the RfC. Maybe it's something that could be added via a later RfC after we've proven the user right is valuable? --valereee (talk) 21:39, 4 October 2019 (UTC)

  I quite understand the stress of not wanting to be put in the stocks for everyone to throw tomatoes say what they like about you; my RFA was none too pleasant. That said, I think you're right in your assessment of the chances of this passing, and I'm quite certain that even if candidatures attract some determined opposition, they are not going to be nearly as bad as RFA, because they are not going to be advertised site-wide. So let's leave it out for now. Also; the way I've phrased the consensus question, I think we've left ourselves a lot of room for throwing out silly opposition. Vanamonde (Talk) 23:42, 4 October 2019 (UTC)

  Vanamonde93 Returning to the question of someone so gnomish and confrontation-averse that they couldn't even face this process...would it be worth considering allowing 'crat discretionary granting? Pinging Xeno and Xaosflux with apologies for the double ping, the page has gotten very long and this section is old. --valereee (talk) 14:05, 31 October 2019 (UTC)

  valereee: Hm, you mean to allow bureaucrats to grant on the basis of a talk page or private request? –xeno^talk 15:26, 31 October 2019 (UTC)

  @Valereee: Actually, I'd rather remove all the 'crat component of this all together. If the primary responsibility for managing the group is with administrators, then leave the 'crats out of it. Crating a "crat X said so" override to the entire process isn't really what we have 'crat for. — xaosflux ^Talk 15:38, 31 October 2019 (UTC)

Xeno, yes, that's what I was wondering. Whether a second way to request was worth considering. I'm just thinking out loud here, though, don't have a strong opinion on it. Xaosflux, having crats (as well as admins) able to determine consensus and close was to allow non-admin crats to do this task. --valereee (talk) 15:49, 31 October 2019 (UTC)

Building this out for that one weird guy is a bit overkill (notably we don't do this for almost the entire suite of usergroups). — xaosflux ^Talk 15:53, 31 October 2019 (UTC)

I've always wondered why bureaucrats can grant, and revoke, only certain usergroups instead of them all. It seems in the beginning someone had the mind to give them separate ability to revoke/grant certain things and it tapered off at some point. I think valereee is asking something different here than what I asked below, though. –xeno^talk 16:14, 31 October 2019 (UTC)

Should editcascadeprotected ever become available

@Vanamonde93: Should phab:T71607 ever be accomplished, we should have a provision to preauthorize changing (protect) to (editcascadeprotected). That is unless the issue I'm going to raise in the next section needs attending to...... — xaosflux ^Talk 15:46, 31 October 2019 (UTC)

This, I agree with. Vanamonde (Talk) 16:19, 31 October 2019 (UTC)

(in)appropriate use

The section is somewhat lacking if it should be considered appropriate use or not something like 'literally editing the "Main Page" page, for example: removing or adding a section, promoting a alternative design, etc. In general more "structure" type edits and less "content" type? If these editor will actually only need to edit the transcended primary content sections (e.g. DYK, TFA, TFL, etc, etc) and not literally "Main Page" we could block such edits with an edit filter (e.g. private filter Special:AbuseFilter/943). — xaosflux ^Talk 16:04, 31 October 2019 (UTC)

So maybe add to inappropriate use:

• Editing outside the transcluded primary content sections of the Main page.

Not sure we need to use an abuse block filter, unless we're worried about a compromised account? But heck that could still happen with me because following your instructions (thank you) for 2FA is my tomorrow's goal.--valereee (talk) 16:17, 31 October 2019 (UTC)

It really depends on what you want the goal to be, if you want it to really be about updating the sections only then sure - if you want them to be able to change the "layout" of the main page then it is different. The filter could be useful to prevent accidental changes as well. — xaosflux ^Talk 16:24, 31 October 2019 (UTC)

Well the filter might be a good idea anyway; but nobody mucks around with the actual formatting, and anyone who did (MPE or admin) would be in trouble if they did, because they'd be acting against established consensus. So I don't know that we need explicit mention; it's covered by existing consensus, and if consensus changes it's a non-issue. Vanamonde (Talk) 16:29, 31 October 2019 (UTC)

True, preventing an accidental change is a good idea. I don't see this as a permission that would be used to change format; that would be a long discussion with plenty of admins chiming in and would never result in some urgent change. This permission is intended to reduce admin workload and increase timeliness of updates/corrections to Main page transcluded content by allowing a small group of trusted non-admins to do tasks they're completely qualified to do, nothing more. --valereee (talk) 17:18, 31 October 2019 (UTC)