Jump to content

Wikipedia talk:Main page editor/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

requirements for retaining/regaining

I'd like to rethink these a bit, after discussion at 2019 resysop criteria. Arbitrary edit counts are probably a counterproductive measure for removing or regaining the right. I'd rather see removing the rights based on no edits at the main page or its various talks/work pages for a year as being the critical factor for removal, and a period of productive activity at those pages as being the criteria for regaining. Policies and procedures change, and if all we're basing it on is 50 mainspace edits, an editor could have missed a lot if they haven't edited that section at all in a year. Also this shouldn't be a hat to collect; people with this right should be actively using it, probably should be people who are interested in at least potentially using it during a typical week of editing.

Also not sure about just 'any uninvolved admin' to regrant -- that could be by email. Maybe the request to regain needs to be made at Wikipedia Talk:Main page editor with a waiting period of 24 hours, then if there are no objections any uninvolved admin can regrant? I'm trying to avoid the kinds of issues caused by automatic resysopping. --valereee (talk)

@Valereee: Agreed about the problems with an arbitrary number; I'm happy with basing the criterion on activity in main page areas; but I do think we need a number rather than a "period of activity", because we cannot remove the userright for inactivity without defining that precisely. Vanamonde (Talk) 15:42, 7 October 2019 (UTC)
Vanamonde93, does 'have edited the main page or its section work/talk pages within the previous year' work? --valereee (talk) 16:02, 7 October 2019 (UTC)
@Valereee: That is enforceable, yes, but a single edit is a rather low threshold, surely? Vanamonde (Talk) 16:03, 7 October 2019 (UTC)
Vanamonde93, it is a low threshhold, I agree. I'm open to a number, but I wonder if we're getting too picky. If this person does the work of moving one prep to queue, that's dozens of edits almost by default. None of them show up as main page edits except the move. So if we require 50 main page edits, in the case of DYK we're saying this person better be moving a prep to queue once a week or we boot 'em. --valereee (talk) 16:08, 7 October 2019 (UTC)
@Valereee: Well, not quite; 50 mainspace edits, not 50 main page edits; but I just realised your suggestion is still stricter than the activity requirements for admins. So, okay. We may get more feedback about this when we solicit comments, though. Vanamonde (Talk) 16:15, 7 October 2019 (UTC)
Oh, wait...that wasn't the question. Hm, right now it's 'Additionally, any user who previously held main page editor rights, and had them removed solely for inactivity, may have their rights restored to them via request at Wikipedia Talk:Main page editor; after a period 24 hours if no valid concerns are raised, any uninvolved administrator may restore. No recent work at any Main page section as detailed in requirements for granting is explicitly considered a valid concern.' Does that work? valereee (talk) 16:04, 7 October 2019 (UTC)
This, I have no problem with; I might wordsmith a little, later. Vanamonde (Talk) 16:15, 7 October 2019 (UTC)
  • The "must meet" criteria are almost all subjective, but they are "required" - are you proposing that the consensus discussions must demonstrate that there is a consensus of each of the requirements? Also, there is an imbalance, if you originally "intent to work" on only one section, you don't have to demonstrate requirement 2 on the others - however you don't have to request this again if your intentions later change. — xaosflux Talk 05:03, 29 October 2019 (UTC)
Hm. It's a valid question. I think in reality that someone who is a fab worker at DYK and has never shown any interest in another area requests this permission, we'd need to agree that we trust them not to muck about in those other areas unless/until they had worked enough in those areas to be helpful there. I have the ability to do a ton of things I should never consider touching, and the community decided they trusted me enough to believe that indeed I wouldn't muck about in any of those places until/unless I figure that stuff out. This permission just says 'we trust this person to work in main page areas they understand and also not to muck about in other main page areas they don't understand.' Do we need to explicitly add that in somehow? --valereee (talk) 17:39, 31 October 2019 (UTC)
@Valereee: I'm thinking along the lines you are - that this is a general 'trusted to work on this stuff according to established standards where you are competent ' - but as written it requires a showing of each competence instead of general competence in the area (just like how we don't ask RFA candidates how they may handle Special:TimedMediaHandler management - but trust they will only use it approriately. — xaosflux Talk 17:54, 31 October 2019 (UTC)
I could just be getting picky though - some parts of this proposal I think are too narrow, and some too broad :) — xaosflux Talk 17:54, 31 October 2019 (UTC)

Upload protection

So regarding Wikipedia:Protection_policy#Upload_protection, @Vanamonde93: how would you see this working for MPED's that add an image to the main page? Cascade protection does not protect these from upload vandalism. — xaosflux Talk 15:48, 31 October 2019 (UTC)

I think our current wording implies that MPEs should not be uploading new versions of protected files, because that would be editing through protection; and I think that's the way it should be. Image rights are a fiddly business; I don't trust myself to upload things that would be seen immediately on the main page. MPEs can use things proteted by the bot at commons, and I think that's sufficient (though we may have to make it clear that WP:CMP is an exception to "editing through protection". Vanamonde (Talk) 16:09, 31 October 2019 (UTC)
Yes, uploading to enwiki and protecting, in the case of Krinkle not protecting. --valereee (talk) 16:19, 31 October 2019 (UTC)
@Vanamonde93: I'm thinking of a MP content situation like updating the ITN picture, something that can happen in the middle of the day if the ITN changes or if there is a better image available. — xaosflux Talk 16:22, 31 October 2019 (UTC)
When was the last time we had to use a locally protected image, though? The reason I ask is that I don't want people who could hold this flag to be grilled, and perhaps opposed, over their knowledge of image licensing. Vanamonde (Talk) 16:27, 31 October 2019 (UTC)
I think this is a good point. Given how infrequently we have to do something like this, and that there are plenty of admins who are willing to pitch in in case of some emergency, the likelihood that this permission would be need to be used this way is pretty slim. --valereee (talk) 17:14, 31 October 2019 (UTC)
@Valereee and Vanamonde93: The directions explicitly say: NOTE: Do not use an unprotected Commons file. Our cascading protection will not apply. Either upload a local copy or list it at WP:CMP and wait for the bot to protect it at Commons. See WP:ITN/A for full instructions. So you may at least need to specifically list out Wikipedia:Main Page/Commons media protection as "in scope". I'm pretty sure I've personally done this before. A quick look at the protection log shows this has been used as recently at 3 days ago. — xaosflux Talk 17:18, 31 October 2019 (UTC)
So something like
? --valereee (talk) 17:50, 31 October 2019 (UTC)
@Xaosflux: Oh I agree; I've made image switches a number of times, and CMP is the way to do it. So clarifying that CMP is within scope is a good idea. I just don't think we ought to be including actual uploading, because only a couple of admins do that in the first place. I, for instance, am never going to upload something, protect it, and place it on the main page, unless I took the image myself and am dead certain of its PD status. So yes, something like what Valereee suggests. Vanamonde (Talk) 18:02, 31 October 2019 (UTC)

General Comment

@Vanamonde93: @Valereee: @Xaosflux: Just some passing thoughts, not intended to duplicate anything said above. But that's a lot to read through. I'm neutral on whether or not this happens. But if it does, there should be a process for a formal request for the right, and a linked access to the record of same. The drawback of the RFA process is that anybody can support or oppose, regardless of when their account was created. This should restrict input to, perhaps, admins, or some other way. — Maile (talk) 18:12, 5 October 2019 (UTC)

We almost never have processes that exclude input of all editors, so not sure about that. That doesn't mean something like this should be a "vote" either though, we run lots of requests at WP:PERM that aren't votes. — xaosflux Talk 19:00, 5 October 2019 (UTC)
In the style of WP:PERM would be a good account of the granting of the right. There would be a specific page for the request, who granted it, and it would be archived. This would circumvent (hopefully) personal requests directly to individual admins. Whether or not such personal requests were in good faith, I can see admins (and I would be one of them) not feeling comfortable with such a request on their talk page, or via email. All the requests should be on one centralized page. — Maile (talk) 01:23, 6 October 2019 (UTC)
@Maile66: About a WP:PERM method of granting vs the one currently outlined; see the discussion above. Valereee has largely persuaded me that given the level of scrutiny on main-page issues these days, leaving granting of the right to a single admin's discretion may be a problem. As to your concern: I think limiting a voting pool always becomes a very messy discussion, and would decrease the chances of this passing. However, I think I have phrased that part of the page in a way that makes it clear that only substantive objections will be considered; just mudslinging isn't going to affect the outcome. Finally; may I ask why you would be neutral about this? I would have expected you to support; so if you have any other reservations, perhaps we can discuss them. Vanamonde (Talk) 23:00, 6 October 2019 (UTC)
@Vanamonde93: I'm neutral, because I haven't had time to mentally digest how this would unfold. Also, I'd like to see comments from other admins if you workshop this. My main page editing has been limited to DYK, so I've never paid much attention to the details of how the other sections are behind the scene. I'm semi-familiar with TFA, and that has a lot to do with @Dank: and a small handful of FA admins. I'd just like to see more input from those who daily deal with the other sections. — Maile (talk) 23:54, 6 October 2019 (UTC) P.S. I guess this talk page is the work shopping of this. — Maile (talk) 01:27, 7 October 2019 (UTC)
Thanks for the ping. I don't have any objections to starting an RfC on this userright. - Dank (push to talk) 03:04, 7 October 2019 (UTC)
Pinging David Levy, @TFA coordinators , Valereee, and anyone watching: TFA is ... well let's not call it stressful, let's say it's in a state of flux ... there's a lot more discussion going on on blurb talk pages. There's no telling how having two big changes at the same time would interact. Thoughts? Would it bother anyone to put off the discussion of how this affects TFA for the moment? - Dank (push to talk) 13:42, 7 October 2019 (UTC)
@Vanamonde93:I think this discussion here could also benefit from input of TFL, TFP, ITN and OTD people. My understanding of what you are proposing, is that it would affect all such areas. We should not be assuming they have the same ongoing kind of issues as DYK. One thing that has always concerned me about DYK, either direction including WP:ERROR, is that there are issues that are merely stylistic differences. Something to think about in granting this privilege. — Maile (talk) 13:53, 7 October 2019 (UTC)
I think I agree. The scientific method includes the Law of One Variable: data from an experiment can be useless, if it's determined that the data resulted from two things being changed at once, because you might not be able to tell whether the data resulted from one change, the other change, or an interaction between the two changes. So if any of these Main Page sections is currently adjusting to some new reality, then it might not be the right time to change who's editing those subsections. (TFA certainly is; I'm not taking a position on which other sections this would apply to.) - Dank (push to talk) 14:06, 7 October 2019 (UTC)
I can't think of any reason a particular main page project shouldn't be able to opt out of inclusion in this right, whether for a period of time or permanently. One of the factors we're dealing with is that the right confers some technical abilities that aren't authorized uses. --valereee (talk) 14:15, 7 October 2019 (UTC)
@Maile66: I think I can lay claim to being an ITN person, FWIW; more importantly, though, we're not at the workshopping stage yet. Valereee and I are still drafting. Once we're finished, I fully intend to invite comment from more main page regulars before posting this as an actual RFC. @Dank: We would, of course, be able to propose this without including TFA, but I'm quite certain that if we did so the proposal would be sunk, and I for one am not particularly interested in pushing this forward if it's clear that the TFA coordinators oppose it at the outset. I don't see why this is an experiment at TFA, really; in principle, this is no different from electing a new administrator, which we have done 15 times this year (14, excluding Floq's resysopping). All of them can come and much around at TFA as much as anyone with this userright. More generally, when proposing this, I expected TFA to be one of the main beneficiaries, alongside DYK and ITN (TFP, OTD, and TFL are largely one-man shows; if we ever become interested in fixing that, this would help there, too); it would allow, for instance, many more of our FAC regulars to participate productively at TFA/ERRORS; and even become coordinators. I recall @Mike Christie: was once a coordinator without having the admin bit; surely this tool would have helped him? Vanamonde (Talk) 15:52, 7 October 2019 (UTC)
Taking this feedback on board, I still stand by what I said, with one clarification: I'm reasonably optimistic that TFA is sturdy enough to deal with increased traffic on blurb talk pages, and also to deal with (say) tripling the number of people who are routinely making edits to protected pages. But it would still be a bad idea to do both at the same time, for the reason I just gave: when unexpected stuff happens, people would have a hard time correctly figuring out what's going on and why, if too much new stuff is happening at the same time. - Dank (push to talk) 16:17, 7 October 2019 (UTC)
@Dank: Thanks for the clarification, but I'm still a little confused. Admins, and any putative main page editors, would be responding to concerns raised on the blurb talk pages, or at ERRORS. It's extremely rare, as far as I know, for admins to muck around with blurbs of their own accord (which was my point above); so I see no reason to be concerned that main page editors would do the same. The only difference should be the number of people able to respond to a request for a change; and under this scheme, some of those new people could be FA regulars who have no desire to become admins. Vanamonde (Talk) 16:28, 7 October 2019 (UTC)
Vanamonde makes a very good point. All this really represents is an additional someone who could theoretically do admin edits at TFA, which would really only be those non-admins currently working at TFA who other TFA workers supported for this as there is no way on earth I or any other reasonable person would want to foist someone on TFA that their colleagues felt was problematic. If a TFA regular requested, and I saw people raising valid concerns and few TFA regulars supporting, I'd oppose for cause. And if some DYK-regular went rogue and decided to go muck around at TFA, we have a revocation process, including an instant emergency one, in the proposal. Whereas if a new admin just decided to wade in with no experience or previous warning, TFA'd have to figure it out. --valereee (talk) 16:26, 7 October 2019 (UTC)
Responding to Vanamonde's ping. I don't have a strong opinion either way about the idea of making this a new right; I have only glanced through the arguments on this page so far. As far as my own experience as a TFA coordinator is concerned, I don't remember a point at which I needed the admin bit but didn't have it, but perhaps it did happen. I'm pretty sure it was never a major hindrance to getting my work as a coordinator done. Mike Christie (talk - contribs - library) 16:34, 7 October 2019 (UTC)
Fair enough. Vanamonde (Talk) 16:42, 7 October 2019 (UTC)

I can't predict how much trouble we'll run into this month, but I can promise to report back at the end of the month. Hopefully the waters will be calm by then. - Dank (push to talk) 22:30, 8 October 2019 (UTC)

So far, so good. Ealdgyth is scheduling November at the moment. - Dank (push to talk) 20:57, 26 October 2019 (UTC)
I'm not on board with the current rewrite. I don't think it's accurate to say that TFA frequently has requests that go unactioned for long periods of time. We don't have frequent requests, and the ones we do have usually aren't time-sensitive. We're more likely to have a problem with things moving too fast than with things not moving fast enough. I'm not opposed to giving the recruits access to TFA, but only if we're clear with them about what the job is. - Dank (push to talk) 23:21, 26 October 2019 (UTC) Okay, I removed the redundant sentence; that deals with the problem I just brought up, though there's still the problem that we're not being clear about what the job is (in the TFA sections, anyway). - Dank (push to talk) 02:59, 29 October 2019 (UTC)
Dank, what would be a clear statement of what the job is in TFA? I don't know enough about how you guys work to try to tweak this, but I do want us to get it as right as we can before we start workshopping. What (if anything) would be helpful to TFA admins if trusted non-admins experienced at TFA could help out with? At DYK it's easy; checking prep sets and moving them to queue would be incredibly helpful. Correcting mistakes in DYK at WP:ERRORS would be often very helpful. --valereee (talk) 17:28, 31 October 2019 (UTC)
I just had to make a tough decision this morning to stop replying at blurb talk pages ... the problem is that the FAC community is acting in some ways (IMO, I could be wrong) as if they're worn out with the increased level of post-promotion activity ... at least at WP:ERRORS and on blurb talk pages, and maybe it's a general thing, I don't know. So, as of today, my recommendation would be to remove TFA from this RfC ... in part because people who are more concerned with TFA than with the other Main Page sections might tend to vote against the proposal. Up until about 4 years ago, I was active in RfA discussions, and I generally saw the advantages in giving more rights to more people ... so, in theory at least, I'm not against this proposal as it concerns TFA, I think pulling in more people is great in general, but it's my judgment that the timing is wrong ... this won't go over well with the voters. Maybe it would be best if they have a chance to see how it's working out in the other Main Page sections before they have to vote on it. Having said that ... I think of TFA as a relatively small part of Main Page dynamics, so I won't actively oppose the proposal, even as it's currently written. I don't want to get blamed, basically :) - Dank (push to talk) 18:47, 31 October 2019 (UTC)

recent tweaks

Vanamonde, those had been to address the concerns at User_talk:Vanamonde93/Main_page_editor#requirements_for_retaining/regaining which were about whether people had to have all the competencies? --valereee (talk) 20:00, 31 October 2019 (UTC)

@Valereee: I know; but my reasoning is simply that the "appropriate use" section is defining what a user may do, not what they should. Their competence doesn't enter into this section. To address the comment in that section, I tweaked it to "Editing in compliance with content policy and main-page specific guidelines in any of the following areas:"; and I think the "any of" covers the "you may only be working in one area" question. Vanamonde (Talk) 20:14, 31 October 2019 (UTC)
Vanamonde93, the concern was whether people would be expected to be able to answer questions about sections they'd never worked in, if they're ostensibly applying for permission to edit "any of" them rather than "one or more" of them. I'm fine with most of the revert, but I do think it's a good idea to use something along the lines of "one or more" to prevent that. --valereee (talk) 20:22, 31 October 2019 (UTC)
@Valereee: Okay, I see what you mean; it's semantic, but it's also important to send the right message, so. I've changed "any" to "one or more". My objection was more about the rest of the stuff you added, which I felt was more relevant to the requesting the userright section. Vanamonde (Talk) 20:45, 31 October 2019 (UTC)
That works for me! Yes, definitely just semantics. --valereee (talk) 22:03, 31 October 2019 (UTC)

Some reading material

Throwing together some old discussions that might be relevant. To the best of my knowledge, this proposal hasn't been tried before; past proposals have focused on a) broader unbundling, or b) using template-editor or something similar to perform an end run around the cascade protection. Vanamonde (Talk) 19:53, 25 September 2019 (UTC)

  • Link. October 2012 proposal to unbundle protection altogether. Closed as unsuccessful.
  • Link. October 2014 proposal to unbundle several tools. Didn't really go anywhere.
  • Link. May 2017 proposal to allot template editors to do DYK admin tasks. Consensus clearly against. A belated proposal to create a new userright was added eventually; it didn't get much attention.
  • Link. Similar proposal from October 2017; unsuccessful, mostly because it was using TE for something it wasn't intended for.
  • Link October 2010 proposal to create a number of new userrights. Didn't get anywhere.
  • Link. June 2016 discussion that explored unbundling. Nothing came of it.
  • Link. October 2012 discussion about unbundling that didn't get anywhere.
  • Link. Phabricator ticket initiated in 2014 (!) about separating "edit-cascade-protected" from "protect" (ie changing protection levels). No action so far.
  • Link. April 2016 proposal to create the pagemover userright. Successful; relevant as possible framework.

Successful discussions

The following RfCs and discussions successfully reached consensus to alter user groups and user rights. Some are already linked above, but this is only a list of those that were successful. --DannyS712 (talk) 23:45, 27 October 2019 (UTC)

Other discussions

Some other discussions about user rights, etc. Included to provide easy links to see what are common objections or sticking points. --DannyS712 (talk) 06:51, 18 November 2019 (UTC)

Bureaucrat ability to revoke admin rights (and bureaucrat rights)
Splitting admin powers
Other user groups / rights

Time for workshopping?

Aside from the question of venues for requesting and removing access (being discussed above), I don't see any burning issues being raised; so I'm wondering if we're close to moving towards a broader workshopping phase, perhaps by next week? There's a little more tweaking I'd like to do to the "potential concerns" section of the RFC, but otherwise, we haven't made substantive changes to the page in a while. @Valereee and Xaosflux: thoughts? Vanamonde (Talk) 19:14, 29 October 2019 (UTC)

Any time you want - more opinions are welcome. — xaosflux Talk 19:15, 29 October 2019 (UTC)
For the initial stage of workshopping, maybe post to DYK talk and see if the folks there would be interested in chiming in? Some of them could help answer Wugapodes' question above. If no one there would even be interested in this permission, then we're probably just wasting our time anyway. --valereee (talk) 11:34, 30 October 2019 (UTC)

Look at all you creative folks hiding away... Move to WP space of course! –xenotalk 18:15, 30 October 2019 (UTC)

@Xeno: I know I've raise quite a few concerns that could have easily shot this down quickly if it went wider first, just added a few more below. I'm not sure how much I agree with on this proposal yet, but do think that having clear answers to things that can be confusing ready is a positive. — xaosflux Talk 15:50, 31 October 2019 (UTC)
I was more talking about an idea lab posting/phase - I found this page entirely by accident. –xenotalk 16:36, 31 October 2019 (UTC)
@Xeno: The intent is to invite broader comments after we've worked out our own differences (or failed to; if I cannot persuade Xaosflux, Maile, and Dank that this is a good idea, I see no purpose in expending my limited time on a community-wide discussion). The larger the body of people discussing something, the more unwieldy the discussion gets, and the more polished I would want a proposal to be before it went there. Vanamonde (Talk) 16:56, 31 October 2019 (UTC)
Do we want to try to get some feedback on this? --valereee (talk) 12:34, 13 November 2019 (UTC)
@Valereee: My apologies, RL caught up with me, and of course ACE coordination took priority. I'd like to go through the thing one more time, to make some adjustments to the RfC wording in particular. Then, I think we should remove that section; it's confusing, and we don't need community-wide input on the wording thereof; and then solicit feedback at WT:DYK and elsewhere. To be quite honest, I'm not sure that we'll get to the proposal stage; I fully believe this is the right step to take, but if we can't convince the DYK regulars (such as Maile66) and the TFA coords (such as Dank) that this is a good idea, I don't see how we can convince the broader community. I intend to do my best with the former, though. Vanamonde (Talk) 15:53, 13 November 2019 (UTC)
Wehwalt will start to schedule the December TFAs in two days ... I'll read this through again after all those blurbs have been dealt with. - Dank (push to talk) 15:57, 13 November 2019 (UTC)
Vanamonde, no apologies necessary, I know you've been busy with arbcom elections, and I'm not actually in a major hurry, just figured we could either ask for broader input or tank this. If it gets tanked, I'm pretty concerned about the ongoing fairly major lack of admins at DYK. We'll have some hard decisions to make if DYK can't get this help. --valereee (talk) 16:31, 13 November 2019 (UTC)
  • Okay, Valereee, I feel ready to post to WT:DYK, WT:ITN, etc, soliciting workshopping input. If you'd like to work on anything further, I'm happy to hold off (you've been enormously patient with me, so thanks for that). In particular, I think we ought to ask folks whether they are opposed to this from the outset, because if there is substantive opposition from the people who would be expected to see the need, I don't know that I'd like to go ahead to the full RfC, which is of necessity time consuming. Cheers, Vanamonde (Talk) 15:31, 6 December 2019 (UTC)
    Vanamonde93, no thanks needed! I was happy to let this percolate. Based on my recent tour of the main page thanks to Coffeeandcrumbs I've seen what looks to me like real need for this due to overwork/understaffing at multiple projects. I'm hoping we'll get some support even from TFA. I think let's just go for it; maybe post to DYK first? If we don't even get support there, we might as well pack it in. --valereee (talk) 16:28, 6 December 2019 (UTC)
    ugh reping Coffeeandcrumbs --valereee (talk) 16:30, 6 December 2019 (UTC)
    Excellent, thanks. Will post there shortly. I think that and ITN will be the sources of most feedback, so I don't know that we've to wait on asking elsewhere either. Vanamonde (Talk) 16:38, 6 December 2019 (UTC)

Feedback

  • I have read earlier drafts of this proposal and have now re-read it. I fully support this proposal and would be the first to "volunteer as tribute". --- C&C (Coffeeandcrumbs) 19:13, 6 December 2019 (UTC)
  • I think it is an excellent proposal and hope it finds support in the wider community. Cwmhiraeth (talk) 06:22, 9 December 2019 (UTC)
  • Under "Inappropriate use" it lists "changing protection level of pages by transcluding them onto cascade-protected pages". This should be tweaked. For example, adding {{`s}}, which normally has template (but not full) protection, to a cascade-protected page would be considered inappropriate as currently written. MANdARAX • XAЯAbИAM 08:58, 8 December 2019 (UTC)
    @Mandarax: That's a valid point; I'm wondering if there's a cleaner way to phrase it than just adding a sentence along the lines of "transcluding templates that are necessary for main page formatting are an exception to this rule". Vanamonde (Talk) 04:50, 9 December 2019 (UTC)
  • In the interests of soliciting widespread feedback before we go forward, I'm pinging all of those who've previously been involved in some discussion about this proposal: @Dank, David Levy, Maile66, Xaosflux, Xeno, Tryptofish, Mike Christie, DannyS712, Winged Blades of Godric, Jo-Jo Eumerus, and Wugapodes:, as well as a few other folks who've been active at DYK, ITN, or ERRORS: @Yoninah, Bluemoonset, Amakuru, Gatoclass, Casliber, Sca, Masem, MSGJ, Stephen, Killiondude, Jayron32, Hut 8.5, Bagumba, Kees08, Art LaPella, Floquenbeam, Howcheng, Khajidha, Gerda Arendt, Ravenpuff, Serial Number 54129, and Alanscottwalker: you're thoughts would be much appreciated. Please feel free to ping any others; mine were solely based on my seeing your name in recent history at ITN or ERRORS. Vanamonde (Talk) 06:57, 9 December 2019 (UTC)
    I think the proposal has merit and would support it. Cas Liber (talk · contribs) 07:47, 9 December 2019 (UTC)
    Adding pings to @Ritchie333, BlueMoonset, Davey2116, 331dot, Zanhe, LaserLegs, Banedon, Nixinova, Martinevans123, and Ad Orientem: after browsing through ITN/C; your thoughts would be appreciated. Vanamonde (Talk) 17:03, 9 December 2019 (UTC)
  • I was expecting this to be a proposal to create a new protection level, use that on the main page, and create a new user right with the rights to edit this protection level. In fact it's a proposal to create a "full protected editor" user right and which is only supposed to be used on the main page. Anybody who gets it would have the rights to edit all the other fully protected pages though, and some of those are very sensitive. The idea that you might be able to get it just after extended confirmed status is a bit worrying. Hut 8.5 07:58, 9 December 2019 (UTC)
    @Hut 8.5: Extended-confirmed status is necessary but not sufficient; the primary criterion is supposed to be experience with curating main-page content. If this isn't clear in the proposal, I'm all ears as to how we can clarify it. Vanamonde (Talk) 08:18, 9 December 2019 (UTC)
    @Hut 8.5: Given that only a small number of editors will seek this userright, a policy-based restriction seems fine to me, without introducing yet another protection level. Also I believe there was some discussion elsewhere on the page about a bot monitoring for fully-protected edits outside the main page areas from main page editors. –xenotalk 16:37, 9 December 2019 (UTC)
  • I was pinged to here and have no time. What is the propoosal? It has to somewhere on this page, if you want my interest. --Gerda Arendt (talk) 09:03, 9 December 2019 (UTC)
    @Gerda Arendt:It's on this page. It would allow some non-admins, but not everyone, to edit the Main Page. Art LaPella (talk) 14:52, 9 December 2019 (UTC)
    @Vanamonde93: just to reply to your comment below that he considers some specific articles more sensitive than the main page itself, there is much more damaging stuff that you could do with this user right than editing the main page, or any single article. For example full protection is used to protect highly transcluded templates. {{Reflist}} has 4.9 million transclusions, for example, and {{cite web}} has 3.4 million. Somebody who knows a bit of HTML/CSS who has the right to edit one of those templates could replace every one of those millions of pages with whatever they wanted. So if a technically sophisticated vandal managed to get this user right then they could replace all our articles with a penis picture for at least a few minutes. It would be a lot easier to get than adminship, I imagine a few thousands edits focused on, say, DYK would do (and we've had vandals work their way up to adminship in the past). The user right ought to have criteria similar to the conditions for granting edit filter manager to non-admins, which are much more stringent. Hut 8.5 18:55, 9 December 2019 (UTC)
    @Hut 8.5: Okay, fair point. How are the criteria actually more stringent, though? Only because they include some language about "highly trusted users, when there is a clear and demonstrated need"; which isn't a particularly objective criterion; the rest of our process is essentially based on the EFM process, after all. That language I'm open to including (pinging Valereee for thoughts); are there other places you would tighten the requesting process? Vanamonde (Talk) 03:46, 10 December 2019 (UTC)
    I think we ought to have something saying that the right is very sensitive and should only be given to highly trusted users with a strong track record. I would also get rid of the extended confirmed criterion, at best it's redundant to this and at worst it implies that you can get the right not that long after becoming extended confirmed. At the moment the criteria basically amount to "knows policy, works on something related to the main page and has made 500 edits", which doesn't seem nearly enough. Hut 8.5 07:59, 10 December 2019 (UTC)
  • Inappropriate use: Edit warring? Improper edit summary? -- Alanscottwalker (talk) 09:13, 9 December 2019 (UTC)
    Alanscottwalker, I'm not sure what you're asking -- edit-warring and misleading edit summaries don't require this right? And a habit of either would pretty much disqualify someone from gaining this right. Are you thinking that simply having this right would make an editor who had never such thing more likely to do them? --valereee (talk) 15:31, 10 December 2019 (UTC)
    Valereee for the admin permission we have ADMINCOND, for this user permission, we should have it clear in the documentation that using it while editwarring, posting improper edit sums, etc. is in contravention of the permission. Before the permission is granted, fine but so what, mis-conduct with a permission should still be clear. -- Alanscottwalker (talk) 16:05, 10 December 2019 (UTC) Valereee Alanscottwalker (talk) 16:16, 10 December 2019 (UTC)
    Quite honestly I'd find exhibiting either of those behaviors prior to requesting this permission as disqualifying for it. No one who has a history of edit-warring or leaving misleading edit summaries should be requesting this permission, and I'd oppose them if they did. --valereee (talk) 17:08, 10 December 2019 (UTC)
    Valereee, Again that is fine, but that is actually another thing to document, in the 'getting-this' permission' section.
    But my comments were about when a person already has the permission. That still should be spelled out in the 'inappropriate use' section. Alanscottwalker (talk) 18:58, 10 December 2019 (UTC)
    Alanscottwalker, so for granting, something like 'a thorough understanding of and history of adherence to Wikipedia behavior-related policy'? How would you word it to add to inappropriate use? --valereee (talk) 19:07, 10 December 2019 (UTC)
  • I think that Hut 8.5 does cover a potential issue; a lot of people are probably not going to be willing to accept "only supposed to be used on the main page" as the sole criterium. I was thinking that maybe creating a new protection level might work better, but since the right to protect pages is connected to the right to edit cascade protected ones, it'd be a problem from a programming perspective. Perhaps some kind of "special" hard-coded cascade protection of Main Page would work? Jo-Jo Eumerus (talk) 09:12, 9 December 2019 (UTC)
    @Jo-Jo Eumerus: Essentially, in crafting this proposal we believe that anyone who can be trusted to edit the main page properly can also be trusted not to misuse their right to edit other full-protected pages. Conversely, if they cannot be so trusted, they ought not to be editing the main page at all. Hut 8.5's objection suggests he considers some specific articles more sensitive than the main page itself; that is an argument I do not buy. Still, this is a pretty fundamental disagreement (reduce protection level versus increase number able to edit present protection level) so if it's going to lead to opposition, there's not much to be done besides dropping the proposal and taking a different tack altogether. Vanamonde (Talk) 10:00, 9 December 2019 (UTC)
    If the software does not allow a userright that only works on a certain page, I would rather prefer a solution that does not rely on people just abiding not to do something. Full protection currently means that only editors who went through RFA can edit the page and if the community wants to unbundle this from the admin-package, it should be done for all pages, not just a single page. Since the Main Page mostly consists of templates anyway, can't we just consider decreasing protection to the already existing WP:TPROT?
    Also, for DYK especially, I vaguely remember proposing a while back that the problem could probably addressed by modifying the code for DYKUpdateBot to recognize other editors' names in {{DYKbotdo}} besides admins (based on a list in an appropriate subpage) without any need to change the actual protection of the DYK template. Regards SoWhy 10:43, 9 December 2019 (UTC)
    @SoWhy: With respect to DYK; that's an interesting idea I'd never heard of before; I'm ignorant about bots, so I'm going to ping @Shubinator and Wugapodes: to see if this is feasible. If it is, it might help a decent amount. With respect to other protection levels though; I don't disagree that we'd be trusting these folks a good deal; but as I said to JJE, if we're trusting folks to edit the main page, we're already trusting them a good deal. Do you see it differently? I'm not personally opposed to downgrading protection on the main page if it will allow us to fix this issue; but two different VPP proposals about downgrading it to template-protection went exactly nowhere. Vanamonde (Talk) 12:09, 9 December 2019 (UTC)
    @Vanamonde93: DYKUpdateBot's source code currently only contains a check whether the {{DYKbotdo}} template exists and uses the parameter for the signature of the user notifications but it does not currently check whether the template was placed by someone who should be able to place it, since it assumes that the queues are fully protected. Not sure how much work it would be to have the bot instead check who added the template and whether that person should have done so but I don't think it's too complicated. Regards SoWhy 16:52, 9 December 2019 (UTC)
    Regarding TPROT, it is not possible to cascade protect by tprot so we'd lose a layer of protection. Although one could use an abuse filter to add an extra layer, I guess... Jo-Jo Eumerus (talk) 16:59, 9 December 2019 (UTC)
    @SoWhy: Oh I see what you're getting at. That, I suspect, is going to be somewhat less popular; because we'd have to unprotect the queues, meaning that any editor could vandalize the main page by tweaking the queues minutes before they are loaded onto the main page by the bot. What we'd need to do is establish some way of allowing a very specific set of editors to edit the queues; probably through an edit-filter, or some such. Which may be an option if this fails, but given the relevance for ITN and OTD, I'd rather try this first. Vanamonde (Talk) 17:00, 9 December 2019 (UTC)
    @Vanamonde93: Either edit-filter or by lowering the protection to template editor, then assigning that right to the set of editors that should be able to do it. Since the queues don't need to be cascade protected and the main template will stay fully protected, it could solve the problem without creating a new usergroup.
    @Jo-Jo Eumerus: Sounds like a bug that needs fixing, but if an edit filter could be used to handle such edits, couldn't we just unprotect the Main Page and its subpages and set an edit filter to disallow any edits by non-admins except a few explicitly hardcoded individuals? That too could solve the problem without having to create a new usergroup. Regards SoWhy 17:11, 9 December 2019 (UTC)
    A whitelist could probably work. I'm not familiar with the update bot's source code, but if the {{DYKbotdo}} template needs placed on the queue page, then a whitelist wouldn't work without lowering page protection. I believe the mainpage already has some special code after the incident, so it might be possible to do as Jo-Jo suggested and implement some kind of special protection or permission checks for main page edits. I'll read through the mediawiki code and see what might make sense; most likely a wikiglobal in mw:LocalSettings.php that toggles this special main page cascade protection but, unlike regular cascade protect, allows users with some additional permission to edit without the ability to protect pages or edit through protection. Wug·a·po·des​ 23:45, 9 December 2019 (UTC)
@Wugapodes: The template needs to be on the queue pages for the bot to know that it is "allowed" copy the queue to the actual template. So only the protection of the queues would have to be decreased for this to work but yes, it would require the bot to actually check who put it there instead of just assuming it was an admin. If I read the code correctly, theoretically any admin when placing the template could add someone else's name as its parameter and the bot would just use that name, which sounds a bit silly anyway. However, now that I think about it, since the bot does not actually check whether the template was put there correctly, a mix of edit filter and protection could handle it as well. I'll ask at WP:EFN if this is possible and if so, will propose it at WT:DYK. Regards SoWhy 12:00, 11 December 2019 (UTC)
  • If this right was introduced, I would apply for it. I don't have strong opinions on the technical implementation or approvals process, though granting permission to edit all protected pages does seem like it would spark opposition from the wider community. Modest Genius talk 14:02, 9 December 2019 (UTC)
  • I support this proposal and agree that if someone is trusted enough to edit the Main Page, they can similarly be trusted to not edit the pages to which they are not entitled to edit. I would be interested in applying for the right (for ITN postings).-- P-K3 (talk) 14:10, 9 December 2019 (UTC)
  • From my relatively short experience (~4months) working with DYK and ITN, I have seen quite a few times of the need for preps to be promoted, RD's to be promoted, and such, and the idea of trusted users being able to do this sounds good to me. I would support this proposal. However, I do think that the standard for granting needs to be (relatively/very) high to prevent abuse. Taewangkorea (talk) 19:34, 9 December 2019 (UTC)
  • I don't like the idea at all. If there are people who want to edit the Main Page and can be trusted to do so, they should be made admins. I can't imagine trusting a user to edit the Main Page but not trusting them with the rest of the buttons. If this is implemented, I suggest to immediately send anyone who has held the permission for a day and not messed up to RFA, and to disallow holding the permission without adminship for more than a month. —Kusma (t·c) 20:56, 9 December 2019 (UTC)
    One specific thing I don't like about the proposal is that Main Page editors won't be able to do their job properly if commons:User:KrinkleBot goes down, unless they have the ability to protect images. And again, that means they should be admins. —Kusma (t·c) 09:12, 10 December 2019 (UTC)
    Kusma, not everyone wants to be an admin. That doesn't mean they can't be trusted to do adminny things. Probably the most frequent prep builder we have has turned down multiple suggestions they run an RfA. --valereee (talk) 14:40, 10 December 2019 (UTC)
    Valereee, every user who can trusted to do adminny things should be an admin. If adminship is broken, we need to fix it, not constantly invent new workarounds for special areas. —Kusma (t·c) 15:55, 10 December 2019 (UTC)
    Kusma, sorry, not following...why would the fact not everyone wants to be an admin mean adminship is broken? --valereee (talk) 16:32, 10 December 2019 (UTC)
    Valereee, it is fine if not everybody wants to be an admin. But if people want to do admin tasks but not be admins, something is wrong. —Kusma (t·c) 16:43, 10 December 2019 (UTC)
Kusma, moving preps > queue and correcting errors on the main page don't even get counted as admin actions. :D --valereee (talk) 16:54, 10 December 2019 (UTC)
Valereee, speaking of "moving preps to queue": allowing trusted non-admins to do that (SoWhy seems to have some ideas about the technical implementation) is something I could support, but nothing that allows direct Main Page editing by non-admins. —Kusma (t·c) 13:22, 11 December 2019 (UTC)
Kusma, yes, I see the difference there. ERRORS is full of contentious argument by people who might browbeat others into making not-helpful changes to main page sections they aren't familiar with. --valereee (talk) 13:40, 11 December 2019 (UTC)
  • I would also support this proposal and would volunteer myself as a main page editor - because frankly, I would never stand a chance at RFA.--WaltCip (talk) 21:16, 9 December 2019 (UTC)
  • Thanks for the ping. My reaction to the draft proposal is quite positive, and I would be likely to support it. I've thought about the concerns raised by other editors in this section, and I do think there will be a lot of valid concerns about misuse. I have two suggestions in that regard. In the section about "Inappropriate use", I would add a bullet point before all of the others, saying "Using rights for any purpose unrelated to the main page." And in the section about "Requirements for granting", I would add a numbered point saying something like "A demonstrated track record of editing without disruption." --Tryptofish (talk) 21:23, 9 December 2019 (UTC)


Gatoclass comments

This is a good idea in theory, but I'm not sure about the practice. To start with, I can see it leading to a lot more errors getting to the main page, at least at DYK, because very few people have the time or patience to thoroughly review DYK sets as I and one or two other admins do, and even if they did, experience shows that many people are not actually terrifically good at identifying errors. And I'm not even sure of the need for this - how many DYK sets have been posted late in recent months? I can't recall any.

But while I'm still sitting on the fence with regard to this proposal, here are a few issues we might want to think about beforehand. Firstly, I think 3 days is too short a time to grant the user right, IMO seven would be better. Second, I'm wondering who isn't going to end up with this user right just by virtue of being regulars at the various projects. We have a constant stream of badly written or erroneous hooks getting approved at DYK (though admittedly I think there's been an improvement in recent months) so it's not as if the overall competence level is through the roof. If users in general are not terrifically good at identifying dud hooks, how are they going to identify those with genuine hook-writing abilities as opposed to those without?

Secondly, what if the user with the right continually posts erroneous sets, or errors or makes suboptimal changes? Is there going to be a way of removing the right?

Thirdly, it may encourage edit warring on protected pages. WP:WHEEL covers that for admins, but what about non-admins? I would suggest that WHEEL be made inapplicable for all associated pages except edits that directly affect the main page. This has actually been a bit of a grey area for some time and I've considered proposing this change for a while, because DYK queue pages for example, though they are protected, are not actually mission-critical like other protected pages, and there is no reason why WP:BRD should not apply to them as for any other non-critical page. For edits pertaining to the main page itself, I think WHEEL would have to be extended to include those with the new user right.

Other than that, I admit I have a degree of COI here, because as an admin active at DYK I have long enjoyed the privilege of making changes to hooks in the queue without having to worry about some well-intentioned but less experienced user coming along to undo them. But I guess if BRD is implemented for these pages as suggested above, it would be less of a potential issue. But I also have to wonder whether I will bother to continue working at DYK at all if this proposal gets up, because the little bit of job satisfaction I now get in promoting sets that I have thoroughly error-checked may be sharply reduced if the queues are always full courtesy of less rigorous promoters. Gatoclass (talk) 09:35, 10 December 2019 (UTC)

Gatoclass, I'm one who is currently feeling pressured to do more than I'm happy to do. I've had a busy week both at home and with other WP stuff, and I've been feeling guilty because I haven't moved a prep to queue in probably a week even though I know we're understaffed. This is how burnout happens.
If the user with the right continually posts erroneous sets, or errors, or makes suboptimal changes, we remove the right from them. Any admin can do this, and then a required discussion ensues.
I am a well-intentioned but less-experienced user who recently made a change to main page section that was not good. Because I am a well-intentioned person, this taught me a valuable lesson. If it hadn't, and if I'd continued to make such changes, I would expect someone to give me a stern warning. If I ignored it, I'd expect to be asked not to edit the main page any more. If I ignored that, I'd expect to be desysopped. That's how long it takes to get an incompetent admin off the main page. This proposal doesn't require that long of a process. As an admin you could remove this right from someone any time you felt you wanted to re-discuss their competence to edit the main page. --valereee (talk) 14:35, 10 December 2019 (UTC)
@Valereee:, as we have come to know you at DYK, I believe you describe yourself perfectly here. You are the new star of the process, so to speak, the one who makes an additional effort to get the job done, while making a valiant effort to treat others with respect. But if one admin can remove rights from an editor and discuss it later, that's beyond even what happens at WP:ANI. I can't imagine an admin removing somebody else's oversight rights without citing Wikipedia policy and discussing it at length. In other words, removing rights and backing up the action is not a simple process, thus far. — Maile (talk) 15:37, 10 December 2019 (UTC)
Maile66, I can't decide whether to laugh or cry at the idea I'm 'the new star of the process' but thank you for the kind intention. :D I agree that stating in the proposal that the process is this easy and actually removing the right are two different things. An admin would have to feel like others would see it as reasonable to re-discuss. Personally, if I saw more than a couple of such overstepping/misjudging-of-self errors, I'd find such a discussion absolutely reasonable. What I mean is: Main Page Editor X 'fixes' an error in a section they aren't familiar with and creates a bigger error which then is even more urgently in need of fixing. Admin Y asks them not to do this again. The next week MPEX does the same thing. Admin Y or some other admin removes the right. In the resulting required discussion, I would absolutely think the call for a discussion was reasonable. I might in the end not agree that the removal should stand, but two instances of operating-outside-your-area-of-expertise-incompetently would definitely be a reasonable reason to start that discussion (by removing the right.) --valereee (talk) 16:04, 10 December 2019 (UTC)
FTR, removal of permissions without discussion occurs all the time. Not advanced permissions such as CU or OS of course, but this would not be such. ——SN54129 16:08, 10 December 2019 (UTC)
Vanamonde93...hm, could we actually put that into inappropriate uses: "Repeatedly operating outside areas of expertise unhelpfully." ? --valereee (talk) 16:08, 10 December 2019 (UTC)
@Valereee: to this point specifically; my concern is that the policy ought not to get into who has expertise in an area and who doesn't. The policy should dictate responses based on outcomes; ie if a person repeatedly introduces errors, even in good faith, they should be removed from the user group. I think the removal process covers this at the moment. What do you think? Vanamonde (Talk) 13:36, 13 December 2019 (UTC)
Vanamonde93, for me, yes. It's more addressing concerns of others. As SN points out, removal of permissions happens all the time. And there are multiple options for the removal of this permission. I sincerely do not believe we're going to be giving this permission to anyone who has ever behaved badly anywhere near any of the main page projects. --valereee (talk) 14:36, 13 December 2019 (UTC)

Why not just RFA

Starting a subsection because admittedly I'm not going to read all the words written about this so far. If the problem is "not enough admins", and various "regulars" (of which I'm one at ITN) which to volunteer, why not just go through RFA? Maybe the issue is reforming RFA? Anyway, do whatever y'all feel. Cheers. --LaserLegs (talk) 01:22, 10 December 2019 (UTC)

@LaserLegs: See User talk:Vanamonde93/Main page editor/Archive 1#Why not adminship?. Wug·a·po·des​ 03:02, 10 December 2019 (UTC)
What Wugapodes said, which is also relevant to Kusma's comment above. Kusma, I agree that giving all of these folks the mop would be the ideal solution; the community seems to disagree, however. There are, to my knowledge, at least three editors who would have edited the main page who have failed RFA or been de-adminned recently, and approaching a dozen who either wouldn't pass an RFA, or would likely pass but have chosen not to put themselves through it; all but one of these people I'm thinking of would be a shoo-in for this right. And those are just the ones I'm familiar with. Vanamonde (Talk) 03:43, 10 December 2019 (UTC)
I'd suggest to just try again, find a couple of would-be Main Page editors and present them to the community, telling everybody "hey, we need some of these people to help with the Main Page". Then laugh at everybody who says that their AfD vote-like-the-outcome percentage is relevant to editing the Main Page. —Kusma (t·c) 09:10, 10 December 2019 (UTC)
I have been on Wikipedia since about 2007. Unfortunately, my maturity and editing competence was not the best back then. Anyone vaguely determined to do their homework on RFA would look past the fact my only real reason for obtaining the mop would be to assist the processes at ITN, and instead point to my lackluster mainspace contributions and gross errors in judgment I've made in the past. I really would rather not have that albatross around my neck considering I don't want or need the mop for anything else. WaltCip (talk) 12:14, 10 December 2019 (UTC)
Having reviewed the above, it seems clear to me that RfA needs fixing -- take the tools from abusers instead of creating impediments to granting the tools. Do what y'all feel. --LaserLegs (talk) 17:26, 10 December 2019 (UTC)
I think the admin-or-nothing idea is poor policy. I am pragmatically for unbundling, see also, specialization --Alanscottwalker (talk) 19:02, 10 December 2019 (UTC)

I think I'd oppose the more concerns that arise

I concur with everything @Gatoclass: has just mentioned above. Gatoclass has been one of the DYK longest-serving admins, and one often likely to be around for holiday runs when others are not available. They bring genuine concerns to the table. I also agree with @Kusma: that anyone trusted with editing the Main Page should already be an admin. If we don't have enough available admins, why would a special class Main Page Editor be anymore reliable, or be less inclined to not be available when needed? If we open to a special class for the Main Page, that's the most important part of Wikipedia to be protect - why WOULDN'T they already be admins, at least having gone through the RFA process?

Besides the obvious of rapid burn-out for anyone with special rights of any kind, there is also the very human phenomenon whereby an editor can successfully gain/retain special rights if they have enough good vibes with those who vote. Does that mean any former admin will be eligible for this, regardless of whether they loss the adminship to inactivity or otherwise? By the same thinking, it then becomes more difficult to remove those rights. I'm pretty sure I'd oppose this idea. If we don't already have enough admins, I'm not sure this special right would make anyone as reliable or independent to do the job.

At DYK, and by extension WP:ERRORS, we already see a donnybrook that happens with opposing posts about what needs to be changed on the Main Page. Would they be less likely to make Main Page changes based on the word of one individual, without feedback from others? I think we either do - or do not - already have enough admins. If they aren't always around when needed, a special group isn't going to be a 24/7 answering service, either. — Maile (talk) 12:27, 10 December 2019 (UTC)

@Maile66 and Gatoclass: Just ask yourselves how many of the DYK regulars alone could do good work with this userright, but have either tried and failed RFA, or have expressed clear-cut opposition to running. Those users are the target for this proposal. If you don't think those folks ought to be editing the main page, then we've to agree to disagree. Vanamonde (Talk) 12:38, 10 December 2019 (UTC)
Then we agree to disagree. Those same ones you mention who could do a good job Main Page editing for DYK, might not have the same knowledge of what is right for the other sections. Every part of the Main Page is developed through their own process, some more extensive than others. BTW, while I have been most active at DYK in this regard, I have participated in numerous FL and FA review processes, and have had several TFL/TFA. Other than obvious typos on the Main Page, as an admin I would never presume to know enough to edit their end-product blurb on the Main Page. — Maile (talk) 12:44, 10 December 2019 (UTC)
Maile, if we trust someone to edit the things they're familiar with, why wouldn't we also trust them to not edit the things they weren't familiar with? (Or at least not to make that mistake a second time, which is my own personal goal.) --valereee (talk) 15:10, 10 December 2019 (UTC)
And why not just let the existing admins take care of that, if they feel comfortable with it? I'm just saying that I've been active in enough other projects to know there are enough variations in how they present the topic on the Main Page, that corrections should not require a new species of Main Page Editor rights. I don't think we should create the new right at all. It just puts another level in the bureaucracy, and one not necessary. — Maile (talk) 15:17, 10 December 2019 (UTC)
Please see this discussion. This is not a solution in search of a problem; this is a recurring issue. Through no fault of their own, there are simply a shortage of admins at ITN able to post non-controversial items that are ready and fit for the main page. The relative competence needed to fulfill such a task is low, but we are setting the bar for carrying out this task to be an Sisyphean unenviable feat. Very few people willingly subject themselves to RFA due to the confrontational nature of the process, despite the recurring call for more admins.--WaltCip (talk) 15:34, 10 December 2019 (UTC)
WaltCip I already saw that. But thanks for re-posting here. — Maile (talk) 15:56, 10 December 2019 (UTC)
Maile66, because there aren't enough existing admins. Recently it was suggested we go to 12-hour sets, and the primary objection was whether admins could keep up. For whatever reason, there just aren't enough admins who want to work on the main page.
Meanwhile we have multiple trusted editors, some of them with more experience at DYK that most admins, who are willing to work on the main page but can't help with the tasks where we get bottlenecks, like promoting preps > queues or fixing errors in a timely fashion. That's the entire rationale for this user right: not enough admins, but plenty of trusted users who could help with this one thing that doesn't really require adminship. Neither of these things even get counted as admin work. Someone could work their entire career as an admin on the main page and have no logged admin actions. --valereee (talk) 15:42, 10 December 2019 (UTC)
@Valereee: According to Wikipedia:List of administrators, there are already 498 active admins among the 1,147 administrators who can edit anything on the main page. Burn out happens everywhere. I've voted for new admins who ran specifically to help out at DYK. They quickly found other places less toxic to apply their new tools. One of them only lasted a few days an an active admin at DYK. I should know ... my first session as an Admin at DYK was a period when others were not active. And I became a painful target. There have since been other, less dramatic but otherwise critical incidents. I stuck it out, and I'm still here. I don't see adding another level to the bureaucracy as the solution, as much as I do our finding a way to filter out the random mistreatment of DYK editors in general. We have lulls where everybody treats everybody with respect. But not always. I oppose more bureaucracy as a way forward. — Maile (talk) 15:56, 10 December 2019 (UTC)
Maile66, yes, burn out occurs everywhere. It's just that the Main Page gets updated daily. Other places, the burnout just means slowdowns, but we can't slow down. So are you saying you don't agree there's a problem with lack of people to move preps > queues and attend to DYK errors? --valereee (talk) 16:16, 10 December 2019 (UTC)
@Valereee: I'm not saying there's not a problem there. Look at the edit history in the Queues. There are plenty of admins experienced at it. The underlying issue is the toxicity to which admins face there is somewhat discouraging. Main Page Editor is just going to be another level where human beings face that same toxic reality. Find a resolution for that aspect of the process, rather than covering it with a band aid of new permission levels. — Maile (talk)
So make people stop behaving like...er, in ways that are counterproductive to collaborative work? :D --valereee (talk) 19:16, 10 December 2019 (UTC)
WP:CIV - and good luck with that idea. I understand we can't control nominators/editors who believe their work is being short-changed. And there is no available instructional class to teach that at DYK. But maybe those of us who are semi-regular residents over there could develop some skills/methods to not antagonize already heated discussions, or perhaps push back by reminding people about maintaining civility. Allegedly, we're all after the same goal. Oh, my goodness, I'm feeling the urge to join hands and form a circle, and sing Kumbaya. :-) — Maile (talk) 19:38, 10 December 2019 (UTC)

More feedback

I find the proposal convincing and would support it, although I doubt that I am the type of editor whom the discussion was aimed at, and am inexperienced enough for my opinion to weigh lightly in the scales. I am entirely convinced by Valereee's and/or Vanamonde's responses to the various concerns or objections (bar any about bots - I skipped that section) above.

As an aside, as someone who has hung around DYK and TFA a little at various times, if someone were to point me at any non-admin task which needs doing in these areas, it may well be that I would be happy to give it a thumb-fingered try. Gog the Mild (talk) 16:06, 11 December 2019 (UTC)

  • @Vanamonde93: perhaps To prevent active disruption of the main page or any other fully-protected page... ==> To prevent activeIn response to actual disruption or inapproriate useof the main page or any other fully-protected pagecaused by an editor using this access.... It speaks more to someone actually having done something "bad" - not requiring a reason to think that the are about to do something bad. Also includes emergency stop for other wrongful uses (such as modifying protection levels of random pages). If that doesn't change your intent - may be easier to be broad on that one. — xaosflux Talk 19:59, 14 December 2019 (UTC)
    Yes, I think that's a lot clearer and more direct; I've implemented it. Vanamonde (Talk) 08:15, 15 December 2019 (UTC)

Post-feedback modifications

@Tryptofish, Alanscottwalker, Hut 8.5, and Mandarax: (In no particular order) In response to your comments, I have made a series of modifications to the proposed policy; do these adequately address your concerns? Also, for the record; I've read all of the comments above several times, and thank all of you for posting them; but these were the comments I felt to be actionable here. @Valereee and Xaosflux: thoughts on the modifications? Vanamonde (Talk) 13:44, 13 December 2019 (UTC)

Vanamonde93, the only issue I'm still wondering about is ERRORS, which kind of gets at both Kusma and Maile's concerns. ERRORS is where the ugliness usually is worst. It's where we get people who aren't actually regular collaborative participants at any project but are more interested in potstirring as late in the process as possible. :) 1. I'm not sure ERRORS, if it's the ONLY area where someone is actually regularly participating, is enough. 2. Is ERRORS so full of toxicity that this new permission would be simply transferring that toxicity from admins to non-admins and exposing them to pressure to work on sections they aren't familiar with? I'm not as concerned about #2 -- one mistake like that is likely to cure anyone who has a clue -- but I think one of the things Maile is primarily concerned about. For me, #1 does make me think. Maybe it shouldn't be all by itself something that can prove need for this tool. --valereee (talk) 14:26, 13 December 2019 (UTC)
Valereee, I think that's a very good point; griping at ERRORS shouldn't be sufficient; but I feel like griping at ERRORS isn't going to be accepted by folks during the request phase anyway. On the other hand, if someone were to regularly make accurate reports at ERRORS without contributing to the toxicity, and without work at any of the projects, I don't see why they shouldn't have the right. I'm open to persuasion, though. Vanamonde (Talk) 14:07, 14 December 2019 (UTC)
Vanamonde93, my thinking was that if your entire expertise at the main page is limited to errors reports, you probably don't have enough understanding of how any of those projects got that blurb onto the main page to know how to check its history. It's one thing to notice a possible problem, but it's another to be able to assess whether it's an actual issue that needs to be addressed and decide how best to address it. For DYK, the history of discussion of a hook is at the nom and maybe also at WT:DYK. An "error" reported at errors might represent something that's already been discussed and gained consensus somewhere, but if you don't know DYK well enough to know where to find past discussions, you probably shouldn't be fixing DYK except obvious blatant errors that literally everyone would agree were errors. I suspect that even someone who is regularly making accurate reports at errors isn't likely to be accepted during the request phase for just that reason. Personally I'd need to see not only nearly perfect reporting but suggested solutions always included and also nearly perfect. --valereee (talk) 14:38, 14 December 2019 (UTC)
@Valereee: I agree that that's what I'd need to see; but I'm concerned about a possible asymmetry between places MPEs are allowed to work, and places they need to have worked before gaining the right. Surely bullet point 2 of the "requirements" should address your concern? Vanamonde (Talk) 17:15, 14 December 2019 (UTC)
Vanamonde93, it does address mine. I was more thinking whether there might be objections from others. I'm fine leaving it as is.--valereee (talk) 18:06, 14 December 2019 (UTC)
@Valereee: fair enough. I'm wondering if we need to solicit feedback at the village pump before we actually run the RfC; if there's still a few sticking points, that could help sort them out? Xaosflux any thoughts on whether to do another round of feedback before running an RfC? Vanamonde (Talk) 18:16, 14 December 2019 (UTC)
@Vanamonde93: you've gotten a lot of feedback - and will likely get much more in a larger RFC, so might as well pull the trigger. — xaosflux Talk 18:22, 14 December 2019 (UTC)
That does address my concern, thanks. I suspect it's possible that the toxicity issues associated with main page processes may end up putting off non-admins as well as admins but if non-admins are willing to give it a go then I don't see why not. Hut 8.5 17:44, 13 December 2019 (UTC)
It's good for what I said, and thanks for all the work you've been putting into it. --Tryptofish (talk) 21:29, 13 December 2019 (UTC)
• The addition which addresses my issue about cascade protection of templates is fine. However, I think "Protecting, unprotecting, or changing protection level of pages by transcluding them onto cascade-protected pages" should be changed to something like "Protecting, unprotecting, or changing protection level of pages, including by transclusion onto cascade-protected pages".
• The addition about edit warring seems oddly specific to me. If any such mention is required, then it should be a general statement that any edits/behavior which would be considered inappropriate elsewhere would also be inappropriate when editing Main Page components.
• My interpretation of appropriate uses listed is that pretty much the only allowed edits to existing Main Page content that one could make on their own initiative would be fixing grammatical and formatting issues. Any other improvements a user wants to make, including correcting errors, would require listing it at ERRORS and waiting for consensus. Is my interpretation correct? MANdARAX • XAЯAbИAM 00:48, 14 December 2019 (UTC)
@Mandarax: agreed, regarding the first two points. I've adjusted the wording. About the third; almost, but not quite; there's also updates, ie posting new items to ITN, and updating DYK queues from preps. Also, at ITN things often require non-controversial updates (casualty counts, for instance) that are frequently performed by admins when they notice the need, without prior discussion. I don't see a reason to exclude these activities from the scope of this group; DYK queues and posting new articles to ITN are both major areas where I'd expect MPEs to be active. Vanamonde (Talk) 14:04, 14 December 2019 (UTC)
Thanks for the adjustments. As for the footnote, I had said it was fine for addressing my concern, but upon looking at it again in broader context, I see that a tweak is needed. It could be read as saying that protecting/unprotecting such templates would be acceptable. It needs to specify that transcluding them, which results in cascade protection, is acceptable.
I was aware that updates were allowed, which is why I was inquiring about existing content. I'm wondering about "consensus". Many ERRORS reports get acted upon with no further comment. Would it be acceptable to take care of such reports? Would one have to wait a certain amount of time to see if any discussion evolves? Could one act on one's own ERRORS report if no objections arise within a specified time? MANdARAX • XAЯAbИAM 19:48, 14 December 2019 (UTC)
@Mandarax: Those are fair questions, but I feel they are outside the scope of this exercise, because at the moment protocols for that sort of thing aren't established for admins either. Admins working at ERRORS have wide discretion; which also tends to mean that when editors are dissatisfied with the outcome, admins deal with a lot of abuse. My intention has been to frame this in such a way that MPEs can do the same things at ERRORS that admins can; ie fix obvious changes of their own accord or when they are raised; wait for substantive consensus on truly contentious issues; and deal with the grey areas using their own judgement; because that's what admins have to do now. I would certainly be open to creating more structure at ERRORS, but that's a different project, I think. Vanamonde (Talk) 08:27, 15 December 2019 (UTC)
You actually did answer what I was getting at. That description of how MPEs can handle various issues is exactly how I thought it should work. However, my reading of the proposal is that any changes, even obvious ones, other than grammatical or formatting fixes, would require explicit consensus. Maybe that's just me. MANdARAX • XAЯAbИAM 09:19, 15 December 2019 (UTC)
  • Changes seem ok, on the issues I raised. (assuming attack and/or misleading edit summaries, etc. are included in things not to do). Alanscottwalker (talk) 19:52, 14 December 2019 (UTC)
    @Alanscottwalker: I think your comment ought to be addressed by the addition made in response to Mandarax above; that behavior that would be a problem elsewhere is also a problem when using these permissions. PAs, misleading edit summaries, edit warring, all of it, would be covered. Vanamonde (Talk) 08:27, 15 December 2019 (UTC)
  • Apologies for being a killjoy, but I have to agree with what Gatoclass, Maile and LaserLegs have said elsewhere on this page. The solution to this issue should be for relevant parties to go through RfA, not to lower the restrictions for editing on our most visible pages. Put simply, if an individual would not successfully pass an RfA, that means the community does not have full trust in that individual. The most common reasons for failing RfAs are in my experience temperament and lack of experience, both of which are concerns for main page editing too. Sure, there are some individuals who insist on AIV and AfD experience but I think an editor with no other red flags who stood for RfA on a stated platform of helping the main page would for the most part pass with flying colours. There's also the issue that admin numbers are going down steadily over time, and as much as unbundling helps with local issues, it could mean ultimately that even fewer people actually go and seek the mop. And speaking from personal experience, as someone who applied for adminship with a very specific goal in mind (closing page-move discussions) but later branched out into other areas of adminship, I think that would be a great loss. In short, all the worthy candidates mentioned for this permission should be going through an RfA. Cheers  — Amakuru (talk) 11:54, 16 December 2019 (UTC)
    Amakuru, it could conceivably have the effect of getting people who otherwise have absolutely no interest in becoming admins to consider it. Just as you found that you wanted to branch out after becoming an admin, MPEs may find after they've had a taste of adminy capability that they want to go for full adminship. And, having been an MPE may give them more confidence to do so, as well as providing a résumé item for their RfA. MANdARAX • XAЯAbИAM 09:07, 17 December 2019 (UTC)
    @Amakuru: I would quite like all of the folks who would be able to work with this permission to run at RFA. Having attempted to persuade a fair number of them, however, I know that isn't happening anytime soon. RFA is still somewhat toxic; and furthermore, often requires a broader range of experience. This permission would require a very narrow experience; and so more users would be eligible for it. Vanamonde (Talk) 12:09, 16 December 2019 (UTC)
    I disagree that this requires a very narrow experience, and my personal criteria for anyone applying for this role would be identical to those of any other RfA candidate. Which doesn't have to include vast experience in AfD, AIV or other specific areas, but simply to be be an experienced and non-toxic Wikipedian. No doubt you have a few specific individuals in mind who would be able to do a lot of good with this right, and I'd probably share your confidence in those same individuals. And those individuals would sail through an RfA were they to run. With the advantage that with their stated goal being main page improvement, all eyes would be on their track record in that department. The misunderstandings and false flags that we regularly see at ERRORS are evidence that throwing more cooks at this brew is not necessarily helpful, unless they're the right cooks. So the focus should be on getting the qualified editors to run. I hear you on the toxic atmosphere at RfA, but the solution to that isn't to simply unbundle everything that goes with the role and therefore lower standards everywhere.  — Amakuru (talk) 14:44, 16 December 2019 (UTC)
    Amakuru, like Vanamonde and you, I'd like to see more of the DYK regulars run an RfA. I've approached two regular hook promoters, and neither is interested in running an RfA. I think both would easily pass, they just aren't interested. Not everyone wants to be an admin. Moving preps to queue requires experience at DYK and literally doesn't require experience anywhere else. It's not even counted as an admin action. --valereee (talk) 21:42, 16 December 2019 (UTC)
    @Valereee: right, and I did think that was the case myself a few months ago, but then we had the whole kerfuffle regarding queue checking. And as you rightly pointed out at the time, uploading content to the main page, including promoting DYK queues, is governed by WP:ADMINACCT and that failure to thoroughly check for errors risks a desysop. I have now been taking greater care when I upload queues as a result of that, following your excellent example! Non-admins, though, are not subject to ADMINACCT, so the rules would have to be relaxed, with the incumbent risks that come with that. Cheers  — Amakuru (talk) 09:28, 17 December 2019 (UTC)
    Amakuru, why would the rules need to be relaxed? An admin can be desysopped for failing to thoroughly check. A Main Page Editor could lose their MPE rights for the same failure. Re: that discussion -- I think someone else pointed that out in response to me saying I'd moved several preps to queue (IIRC in response to a request from the prep setters, because we had six full preps and zero full queues again), and asking what I should do if I knew I wasn't going to have time to check them. --valereee (talk) 12:16, 17 December 2019 (UTC)
    Amakuru and @Valereee: a couple of points. Re the queue checking, and some accusations that flew, as well as misunderstandings. Since we don't have the ability to perform thought-wave brain scans, there is no way an admin is going to be desyspoed for failure to "check" anything. If an admin says they checked, no one can prove they didn't, anymore than it can be proved whether it was human error, or a detailed check of every sentence in the article and hook. Let's get real. How many admins ever get desysoped for failing to live up to expectations? Admins either get desysoped for lengthy inactivity, or because their actions were so serious - usually committed against one or more editors - someone had to put a stop to it. You're thinking very simplistically here about how this would work out. Wikipedia is a place where lines are often drawn in the sand, and people side with one or the other. Has DYK ever escaped moments of donnybrooks? — Maile (talk) 14:32, 17 December 2019 (UTC)
    @Maile66: I have to confess I laughed a little at your comment here... imagining the scenario where an admin is hauled before ArbCom because they promoted Prep 2 to Queue 2, and it was subsequently determined that there were three errors in the set. Quelle horreur. But yes, I do take your point. It is worth considering as part of this proposal though, whether MPEs have identical authority to admins when it comes to making amendments. It was suggested above that an MPE could only make non-trivial changes to the main page with "explicit consensus", which would appear to differ from current practice for admins, because in reality many changes suggested at ERRORS (or the now-dormant ERRORS2) are the result of one person suggesting something and an admin concurring, without further discussion.  — Amakuru (talk) 14:51, 17 December 2019 (UTC)
    Oh, yes, I was speaking hyperbolically. :) And yes, I generally will make a suggested change if I agree it's an actual issue, without waiting for further consensus. Not so much if I think it's purely a stylistic preference, even if I happen to also prefer it. --valereee (talk) 15:09, 17 December 2019 (UTC)
    Amakuru and @Valereee: Also worth considering, is the inevitable human scenario where the new classification MP editors develop an inactivity rate at DYK no different than Admins. If we add, say, 6 new MP editors, and 3 of them become inactiive - perhaps only editing every month or two - for any reason. So, we add more to fill the gap. And more. And more. What are we creating? Do we need a requirement of X-number edits per time frame, so we aren't spinning our wheels on this? — Maile (talk) 15:15, 17 December 2019 (UTC)

Perhaps another criteria for granting

Something along the lines of "An existing administrator in good standing may be granted access by relinquishing their administrator access". That way MPEditing only admins that want this don't have to jump through hoops to keep doing something they already can do. — xaosflux Talk 12:48, 7 January 2020 (UTC)

@Xaosflux: This makes sense to me, but I was under the impression that when admins relinquish their tools, they are able to ask to retain any of the "lesser" userrights. I recall when I temporarily handed in my mop I kept autopatrolled and rollback. Is there a reason to make this explicit? Vanamonde (Talk) 17:53, 7 January 2020 (UTC)
@Vanamonde93: it is at least similar - the main difference is that things like rollback/autopatrol are by policy able to be issued solely by admin discretion, (i.e. you don't require a formal request and review at somewhere like WP:PERM) it isn't actually because they were "included". — xaosflux Talk 18:23, 7 January 2020 (UTC)
@Xaosflux: I see; so those requests were, in a sense, requests for those userrights to be added at admin discretion, rather than pro forma requests for retention? In that case, the addition you propose is necessary. Valereee is unlikely to have objections, I think, but pinging her as a courtesy. Vanamonde (Talk) 18:32, 7 January 2020 (UTC)
Yup, they are almost always given, but noone has a right to rights :) A good example would be if you resigned at WP:BN right now and I removed you, you'd be a non-sysop. If next week you said, hey can I have rollback now - I wouldn't hesitate. If you asked for Edit Filter Manager, I'd likely send you to the request process. (Might IAR if there was something special going on and you were previously a heave filter maintainer for example). — xaosflux Talk 18:38, 7 January 2020 (UTC)
Makes sense, thanks. Vanamonde (Talk) 19:48, 7 January 2020 (UTC)
No objection! --valereee (talk) 14:00, 8 January 2020 (UTC)

Is it time?

@Valereee and Xaosflux: I apologise for dropping the ball on this; as you may or may not have noticed, I haven't been very active for a while, largely because RL got very very busy. I'm likely going to be back to "normal" activity for a while, and would now be comfortable posting this as an RfC. I think we've gotten enough feedback. Obviously, not everyone is in support; but I still think it's necessary, I don't think we're going to persua those who oppose to change their minds, and even if this fails, I would feel that I'd given the problem my best shot. How do y'all feel? Vanamonde (Talk) 03:24, 20 April 2020 (UTC)

@Vanamonde93: Question: adding images to Wikipedia:Main Page/Commons media protection is permitted, but what about for local images, either because a local copy already exists, or because one doesn't want to wait for the commons bot. Can they protect the local version? DannyS712 (talk) 04:48, 20 April 2020 (UTC)
Fair question. I'm inclined to think not, because I think we expand the number of users who can make use of this set of rights if they do not need to be experts in image copyright. I'd be interested in hearing the opinions of the others. Vanamonde (Talk) 05:16, 20 April 2020 (UTC)
The rule is already that they have to be non-fair use (Wikipedia:In the news/Administrator instructions#Images, Wikipedia:FAQ/Main Page#Why is a Main Page section missing an illustrative image?, etc). The intention was not to involve image copyright, but just to allow, eg, files in Category:Wikipedia files on Wikimedia Commons for which a local copy has been requested to be kept to be used, or to allow uploading local copies of commons files if the bot isn't working, etc DannyS712 (talk) 06:59, 20 April 2020 (UTC)
Vanamonde93, no worries, RL should always trump. I think this is worth getting input on. Well, of course I do, lol, I'm the one throwing a hissy over two-a-days, and this is likely to help with the understaffing. :) I don't have an opinion on protecting local images, but I'm inclined to err on the side of limiting the scope of the right rather than expanding it, in hopes of addressing the greatest number of concerns. If it turns out this right is mega-helpful to multiple main-page projects, causes no problems, and gains widespread support, we can always suggest an expansion. —valereee (talk) 11:06, 20 April 2020 (UTC)

Village pump discussion

Adding the link here, as it's a pain to find in the archives: Wikipedia:Village_pump_(policy)/Archive_157#RfC:_proposed_creation_of_new_usergroup. Vanamonde (Talk) 06:16, 31 August 2021 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Main_page_editor/Archive_2&oldid=1047318812"