This proposal is proposed to be adopted in the RfC at Wikipedia:Edit filter noticeboard#RFC - creation of the edit filter helper user right. While that is in progress most comments should be left there. Thryduulf (talk) 14:26, 14 August 2017 (UTC)[reply]

• The proposal has been adopted and the technical aspects etc. are under active development.Winged Blades ^Godric 15:36, 13 September 2017 (UTC)[reply]

3. By any administrator following a self-request from an editor in good standing to reduce the editor's access from edit-filter manager.

Per the discussion in a recent EFH request (specifically ProcrastinatingReader's comment in Special:Diff/995365712), I'm proposing we require that EFH requests (maybe EFM too?) include a nomination by an EFM/admin. We could exempt holders of certain user rights from this requirement, but I can't think of any obvious candidates. Enterprisey (talk!) 05:19, 23 December 2020 (UTC)[reply]

• Support As the person in the linked request, certainly. Requests currently are subjected to a stigma akin to RFA with regards to self-nominations. I think I likely would have garnered more support if the request was headed by someone already able to manage filters. I would oppose EFM requests be prohibited from self-nominating, given that a very small few have succeeded anyways, with the great majority of the EFMs being administrators who can simply grant the right to themselves. EggRoll97 ^(talk) 08:05, 23 December 2020 (UTC)[reply]

Don't think this is called for - you can always ask for a nomination from an existing EFM/admin, but it shouldn't be required - we don't even require nominations for RFA! DannyS712 (talk) 09:15, 23 December 2020 (UTC)[reply]

RfA has a higher pass rate than EFH. The de facto requirement is that EFM must support an app early on for a successful outcome, usually the EFM referred the nominee in the first place. Requiring it to be so: (a) stops good faith people dealing with walls of opposes for no real reason; (b) makes clear whose job it is to pass a successful nomination. As such I support. ProcrastinatingReader (talk) 11:39, 23 December 2020 (UTC)[reply]

Striked in favour of proposal below ProcrastinatingReader (talk) 14:00, 1 January 2021 (UTC)[reply]

• However, I also like the ideas of more emphasis on sponsoring from GeneralNotability’s comment (which I shamelessly stole this idea from). Alternatively, EFMs being able to grant just like CUs do (indeed, the track record shows no EFM supports in the past have failed nomination). ProcrastinatingReader (talk) 12:05, 23 December 2020 (UTC)[reply]

  Not sure I like the latter idea. The trust required for EFH is approximately in line with that required for sysop. A single person, no matter how experienced, is not capable of judging community trust like that. That'd be like saying, I've never nominated an unsuccessful RfA candidate, so give me the ability to grant sysop to anyone I deem worthy. Best, KevinL (aka L235 · t · c) 18:31, 2 January 2021 (UTC)[reply]

• Oppose I agree with @DannyS712:. This is a solution in search of a problem. We don't require it for the sake of requiring it because it looks better. -- Amanda (aka DQ) 14:35, 23 December 2020 (UTC)[reply]

  @AmandaNP: Take a skim through the archives; even this failed. It must be discouraging for candidates who meet all the listed criteria to get struck with a wall of opposes for trying to help, not knowing their request is DOA. The only semi-recent exception to the rule I mention above (that I can recall) was EEng. The reality is that requests do not succeed without it, and it's both skewing results, wasting time and discouraging editors to pretend otherwise. ProcrastinatingReader (talk) 14:55, 23 December 2020 (UTC)[reply]

  For the statistics, to see the problem: for the 15 EFH requests since archive 6, 3 have passed (incl 1 EFH, withdrawn, resubmitted as EFM), leading to a success rate of 20%. The archive before this was slightly better, 3/8, or 37.5% success rate (excluding 1 CU grant). So that's the difference with RfA: the rate there was 70% in 2020. ProcrastinatingReader (talk) 15:12, 23 December 2020 (UTC)[reply]

  That sounds like a problem with the community, not the nomination process/standards. Creffett is now General Notability and has EFM and does a good job at it, so... -- Amanda (aka DQ) 16:18, 23 December 2020 (UTC)[reply]

  I think that's the point, AmandaNP - that I did not pass my EFH request and then passed RfA about half a year later suggests that maybe the process is a little too strict. I think I mostly agree with your comment, though - I've had plenty to say about this in the past, but I think the problem is that the standard for "demonstrated need" is too high. I'm neutral on this particular request - I think prospective EFHs being nominated would help their chances (though I only have intuition about this, not actual evidence) but I don't know if it's appropriate to require nominations. GeneralNotability (talk) 17:02, 23 December 2020 (UTC)[reply]

  Right. I'd be equally happy with nailing down the real requirements for EFH and/or just strongly suggesting that candidates ask an EFM for advice first. But what would the EFM look for? Apparently just doing false-positives work is insufficient? I would like a better-explained "demonstrated need" standard. I'm reading Crow's comment in Wikipedia:Edit filter noticeboard/Archive 6#EFH for User:CAPTAIN MEDUSA but can't really get anything out of that. CC Suffusion of Yellow, another frequent commenter on these. Enterprisey (talk!) 09:54, 24 December 2020 (UTC)[reply]

  The issue is not really demonstrated need imo, that's mostly a pretext, as was obvious in the moony request. Not to use EEng as an example again, but since he can take it he's the best person to use: compare creffett's request to EEng's request. One passed, the other didn't; and in the opposite direction one showed more 'demonstrated need' than the other. (obviously, in my eyes, both were very qualified requests, but I'm speaking purely in terms of the typical 'demonstrated need' definition). This standard is flawed in any case, as you find more ways of demonstrating need for a right after you have it than before.

  I think the real de facto standard is: do we think you're a sock or a hat collector, do we know you, and do we trust you? And there is no way to codify this into WP:EFH better than it already is, as they are all subjective measures. Strong measures make sense, but when it's literally easier to go get a global right (which gives you local access) than it is to apply locally, obviously the standard is bust. ProcrastinatingReader (talk) 15:56, 24 December 2020 (UTC)[reply]

• Comments As an "EFH Conservative", and ironically perhaps the one whose offhand comment may be responsible for this permission in the first place, I think this proposal is good in spirit, if not to be actually codified. Just like RFA advice pages say getting a well-known user or admin to nominate you will increase your chances, the same rather applies here. Regarding the pass rate between EFH and RFA, that's a bit of a fruit inversion: How many RFAs would succeed if the self-nom was of the form "I do anti-vandal and NPP, so I think I could help with blocking and deleting"? Perhaps it does come down to "do we know you and trust you", though I still maintain that having a real need, one that inhibits you by not having it, is also required. I also maintain that this is a dangerous permission to have, in one way perhaps moreso than admin: If an admin goes off the rails, the permanent damage they can do is limited, and reversible. A malicious EFH/EFM can basically render all filters useless, requiring them to be started from scratch, and only need 30 minutes to do so (and I don't mean just by deleting or disabling them). As such I don't like seeing requests just to help out at EF/FP or to use the test interface. The Test Interface can "easily" be set up on one's home computer in a matter of an hour or so, assuming a certain basic competence with software, which is how I used it originally. Crow^Caw 19:53, 29 December 2020 (UTC)[reply]

  @Crow: re one that inhibits you by not having it: I've never quite understood this, can you explain? My view of this was just: if the editor had the perm, would the wiki be better off for it? But this is a low bar and obviously not the standard meaning of the phrase.

  I feel like everyone on the wiki who has worked in any administrative area would have benefitted from having the technical ability to do something (vs wasting overall time by tag with CSD / list at WP:RM/TR / go to AIV / pester people on IRC / etc). In that sense, everyone is inhibited by not having technical ability to do something when it's required. At the same time, it's always possible to do anything by just asking an admin, and the only thing that changes is the name on the log. And even if someone disappears, the wiki keeps going, even if there are things which could be better. So in this sense, nobody needs any perm. So I don't personally understand what being inhibited by not having a permission means? ProcrastinatingReader (talk) 20:28, 29 December 2020 (UTC)[reply]

  Re the substance of your msg: I do anti-vandal and NPP, so I think I could help with blocking and deleting, yeah why not? I mean, the experience when applying for the delete button is to have a CSD log showing you know when to CSD. The experience when asking for the block button [for vandals] is to show your AIV reports are solid. What's the experience for EFM? "I can write regexes"? What's the experience for EFH? Extensive experience in tangential areas + being well known? And what about this more recent example (technically 100% support, but not done?)

  More to the point, see the global right discussion I mentioned. That likely would've failed on enwiki (indeed all but 1 enwiki regular opposed/neutral'd), yet the user now has access to EFH on enwiki via the global right. The recurring theme of the global users' comments? valid request reason, low impact permission. This is nothing against the editors opposing FWIW, I have positive interactions with all of you/them, but imo our attitude towards permissions is unhealthy, and when it's out of line with the global equivalent it's also visibly broken. Regarding sensitivity, whilst the argument makes sense in theory, consider half of our 1000+ admins are mostly inactive, and most probably given the perms when the standard was half as strict as EFH currently is. Yet, our filters haven't been dumped. Personally, makes me think the concerns are overblown. I don't think anyone who isn't a sock/vandal (and even then...) wants to help socks/vandals mass-disrupt. ProcrastinatingReader (talk) 02:28, 30 December 2020 (UTC)[reply]

• I think all of the above kind of cements the requirement as being more of a trust thing, I suppose. By "inhibits you", I see it as a line between (for example) being a prolific NPP patroller/CSD tagger, and having someone just say "take the dang bit already". It is admittedly a fine line, as is "will the wiki be better off if this person had the bit". Technically doing one positive thing and nothing else is a net gain for the wiki, but that doesn't mean the floodgates should open for this or any other permission. Take the case of Danny's EFH requests: I opposed in Jan 2019 based on "demonstrated need", and then supported in Aug 2019 because I felt that it was detrimental for him not to have it at that point. Crow^Caw 17:43, 30 December 2020 (UTC)[reply]

  re floodgates: maybe. But it's also possible that they begin to like the work, so broaden their interests; interests they wouldn't really know existed unless they had the perm. Danny is a funny case. I've never seen them complain about it, but I think they got hard done by around the same time period. Example. Yes, a person can always go from not being ready -> being ready (and that's fine to reject the first request if so!). But they can also be ready -> even more ready (and a rejection loses some output but it's later corrected, so fine). However, they can also go from ready -> discouraged / losing interest / not reapplying, which is a net negative for the project. I suppose these are all a fine line, to be fair, but I'm not sure we're on the right side of the line currently. ProcrastinatingReader (talk) 18:50, 30 December 2020 (UTC)[reply]

  Overall, you can maybe see my main point: that all of the above might dissuade someone from wanting to contribute in an area? And surely anti-vandalism efforts would be more effective with more competent editors on board, not less. Whilst the guiding principle for current attitudes is fair, don't you think the wiki is actually worse off in the long term with what we're collectively doing wrt permissions? ProcrastinatingReader (talk) 23:47, 30 December 2020 (UTC)[reply]

• I do see your point, yes, but as is the case with all permissions the risk must be weighed against the benefit. Before I had access, I did not know the extent of what the EF does on an hourly basis, and the potential damage that could be done to all the effort put into EF up to now. As I typically state when I oppose EFH noms, helping out at EF/FP is always welcomed, but there is rarely a backlog of private filter FP reports, and those are very often invalid reports (vandalism, etc). Yes, in an ideal world every editor would have the tools to do whatever they need to improve the encyclopedia. That this filter even has to exist shows we're far from that state though. Crow^Caw 17:00, 31 December 2020 (UTC)[reply]

• Crow, regarding the permission being "more dangerous than admin" - afraid I have to disagree with you there, it cannot be any more dangerous than admin. Since EFH perms are bundled into +sysop and admins may self-grant EFM at will, the moment someone gets +sysop they can leak all the filters they want.

  As for the whole "demonstrated need" thing, it's a bit of a catch-22 - it's hard to demonstrate that it would be helpful for me to see specific filters if I don't know what's in those filters and can't easily track them. When I requested EFH last year, the main reason I wanted it was because I wanted to add a few private filters to my daily filter log monitoring (that was a lot of my patrolling pre-RfA - watching a list of interesting filters via Special:AbuseLog). It wasn't exactly possible show how much being able to see those filters would help, since I had no way of knowing how many filter hits those interesting-looking filters got or how much value I could add by getting access to those filters, since I couldn't see any details about them (except for occasionally seeing hits on them in per-page filter logs.

  And regarding the test interface...first, "why not just set up your own local MW instance?" is not something I think we should need to tell people. And this gets at something I'm unclear on - why exactly is the test interface locked behind EFH/EFM? That seems like something that an average user could make use of, I'm curious why it requires special perms. My assumption is that it leaks private information, like letting a user load any filter rather than just ones they have access to, but that's just guessing on my part. GeneralNotability (talk) 21:14, 29 December 2020 (UTC)[reply]

  @GeneralNotability: It does leak private information, if you put the number of a private filter in the URL, e.g. Special:AbuseFilter/test/2. But that would be trivial to patch. The real reason is to prevent a (theoretical) DoS attack, from evil regex, etc. Personally, I think the risk is overblown on WMF wikis, though it might be a concern if you're trying to run your own wiki on a budget webhost. The API module behind Special:AbuseFilter/tools was open to all users (including IP users) for about a decade and no one exploited it, as far as I know. Maybe instead of outright prohibiting unprivileged users from using /test, we could just add a rate limit for all non-EFH/EFM. Even the evillest regex will just timeout eventually. So as long as they can't have hundreds of parallel requests going at once, I doubt there will be a problem. If there's a "mild" DoS concern, it could be limited to, say, rollbackers or even extendconfirmed users. Making 500 edits for the thrill of moderately slowing down the site doesn't seem worth the trouble, when you could just vandalize instead. But obviously, that's a decision for the developers. Suffusion of Yellow (talk) 02:30, 30 December 2020 (UTC)[reply]

  Thanks Suffusion of Yellow, that's useful history. I might look into writing a couple Phab tickets for those - doesn't seem too complicated and it would be very nice to make /test generally available. GeneralNotability (talk) 02:41, 30 December 2020 (UTC)[reply]

  @GeneralNotability: Ok so a bit of hyperbole there, although I did set up MW on the side to play with the test interface, and if an Admin was going to go bonkers they would have to have endured 10x the vetting that EFH gets now. I guess the point I'm trying to make is that this is a dangerous permission to have, more dangerous that I thought before I saw the sheer volume of vandalism that it currently prevents, so perhaps I'm a tad overzealous in trying to keep it that way. And you are correct that Demonstrated Need is hard to quantify, which is why I support the original proposal in spirit. At some point an EFM or 2 will eventually tell a prolific contributor "just take the dang bit already". I don't think that should be codified, but a modification to the guidelines to suggest this would probably be good. Crow^Caw 17:43, 30 December 2020 (UTC)[reply]

@Crow: fair. I think we're not that far apart, but it's a thin line.

I have another suggestion here, based off your response at User_talk:Crow#Regarding_the_discussion_at_WT:EFH. Let's advertise EFH/EFM requests more broadly, like WP:BAG requests are. Not quite a community consultation or a vote, like RfA/RfB/BAG/etc, but I think this will just invite more participation from the wider admin corps and the community -- trusted people who may know a person we don't, and are willing to lend their name in support.

So similar to Wikipedia:Bot_policy#Bot_Approvals_Group, policy should be that all EFH/EFM requests are advertised to WP:AN and WP:VPT. Thoughts on this? ProcrastinatingReader (talk) 17:53, 31 December 2020 (UTC)[reply]

• I mentioned there that the wider advertisement has its own issues, some beansy, while others include that many don't know or understand exactly what that permission entails, good or bad. So as happens at RFA a lot, there would be a fair amount of "why not" !votes. Before going that far I would prefer the original proposal here, that an EFM "nominate" (or just introduce may be a better word) potential EFH/EFMs. Just as CUs are the ones who choose their clerks because they're the one who truly know what is involved, the same tends to apply here. Crow^Caw 18:06, 31 December 2020 (UTC)[reply]

  I don't think this is as much of a problem as it seems in theory. See BAG requests, for example. They're widely advertised, but people outside technical/bot circles don't bother comment. I feel like the community is generally entitled to decide who it trusts, and EFH requests aren't a vote anyway. ProcrastinatingReader (talk) 18:13, 31 December 2020 (UTC)[reply]

  How about we do a trial of the new way and see how it goes? Next time someone's up for EFH, we try advertising it and see if it significantly affects the quality of !votes. GeneralNotability (talk) 21:44, 31 December 2020 (UTC)[reply]

• I don't think we should at this point. As I hinted at on my talk page, there are some beansy reasons for this. I'd prefer to see how this proposal works out first, as it may indeed yield the benefits you mentioned way up there in your support. Crow^Caw 23:12, 31 December 2020 (UTC)[reply]

• I'm only one voice of course. I'd like to hear from other EF/N regulars. I suspect the holiday has them elsewhere, as indeed I'm off to now. Have a happy new year! Crow^Caw 23:16, 31 December 2020 (UTC)[reply]

I supported above mainly to reduce the number of failed requests, but mostly by reducing the number of total requests. I now see this doesn't really fix the underlying problem, and I didn't think there was much of a solution to that until you raised the idea (in that sense, I guess you spilled the beans lol). So I've struck the above in favour of this proposal. I guess the real problem is what Amanda says above (That sounds like a problem with the community), which this fixes, by encouraging more participation from people who may know the requestee. I didn't think we'd actually have opposition to letting more admins have more input here. I'm also happy with GN's idea of some trials but if that fails I'll probably try sending this to RfC for broader input. Unless the wider community itself wants no advertisement of requests, and wants them limited to effectively a self-selecting circle, then I don't think this should not be done -- we have no remit to protect the community from itself. ProcrastinatingReader (talk) 14:00, 1 January 2021 (UTC)[reply]

• Ultimately it is the community's decision, of course. I don't believe there is any situation to which more discussion is inappropriate; I hope I did not come across as suggesting that. One thing that may result from a wider advertisement is a greater volume of requests from people we would both consider "not yet", which would likely lead to an increase in discouraging feedback to eager users. If we do proceed with that, I would first like to see a guide similar to WP:MRFA which explains in layman's terms what the perm is all about, and what is expected of an applicant beforehand. After all the only requirement for RFA is having an account, which may be the requirement, but certainly not the expectation. Crow^Caw 16:25, 1 January 2021 (UTC)[reply]

  Isn't the lead of WP:EFH sufficient for this (the 3 bullets)? ProcrastinatingReader (talk) 16:39, 1 January 2021 (UTC)[reply]

• That's the "what", yes. I would like to see more on the "how" as has been discussed above. E.g. how to show the "need", about trust concerns, the advantage of being "nominated", what to do before volunteering one's service, and so on. Assuming the original proposal doesn't pass of course which would set a requirement. A friendly advice page, if you will, to head off requests that are far too premature. Just a random crow thought (but it seems twice now that one of my random thoughts has set a process in motion!). Crow^Caw 19:35, 1 January 2021 (UTC)[reply]

  We could add a sentence about how editors should be trustworthy, and a nomination may help, into Wikipedia:Edit_filter_helper#Requirements_for_granting, but otherwise I don't see what else is missing there. A separate page would probably just be repeating this one, to be honest, at least as I envision it. Do you have a proposal in your mind of what you want this to look like? ProcrastinatingReader (talk) 20:42, 1 January 2021 (UTC)[reply]

• I don't have anything specific in mind, perhaps a draft could be started on a sub-page. Or maybe as you say it would be pointlessly redundant. Just throwing things out there. Crow^Caw 15:41, 2 January 2021 (UTC)[reply]

I'm not 100% sold that wider advertisement is the right solution; I would still prefer clarifying the requirements or changing the rules (suggested/required nominations) so that vague requirements aren't an issue, as I feel like the current problem of vague requirements will still be there if wider advertisement is implemented. Enterprisey (talk!) 03:23, 2 January 2021 (UTC)[reply]

• I'm rather in agreement the more I think on this. The discussion is held on the EF Noticeboard where anyone who concerns themselves with EFs will see it. Just as CU's hold their own clerk discussions on their noticeboard, Copyright team holds their own clerk discussions, etc. Your original proposal up top was intended to address the success rate, with some in support also intending to address "walls of opposes" that would discourage people after applying. I think we should move more incrementally and see what happens if an EFM/EFH nominates someone they think should have the perm (either one). That would be a good test of the original proposal. If things suffer from low participation, then we could maybe post to AN on the next one and see how that affects it, and so on. There's no urgency to rush out and change everything about the process right now. Crow^Caw 15:41, 2 January 2021 (UTC)[reply]

Unless you have a draft of what it will say I don’t know how to move forward with your idea. I can’t imagine anything that isn’t redundant to the existing page. Enterprisey, imo we already have clear guidelines, we just don’t have enough participation to the point where they’re actually followed. The policy page explicitly lists authoring filters and coming from other wikis as valid reasons. In practice, the former often gets denied for “this isn’t a path to EFM” and the latter for “this won’t help on your wiki”. In both cases, we have exemptions, usually based on the username making the request. I don’t really see changing the guidelines to be helpful, nor do I think there’s anything to change them to. I really think wider advertisement is the solution here, with no other changes, so it won’t be changing too much. ProcrastinatingReader (talk) 16:15, 2 January 2021 (UTC)[reply]

I think we can clarify the requirements without changing the rules. Just add a sentence or two about nominations and recommended support from an EFM to the header of WP:EFN or something. KevinL (aka L235 · t · c) 18:34, 2 January 2021 (UTC)[reply]

There have been multiple good-faith requests for Edit Filter Helper (EFH) recently. These include editors that have been active for 1-2 months requesting EFH and being declined due to lack of experience. Many voters have stated that they would want a EFH to have been a Wikipedian for at least 6 months. The current policy only requires 1 month. I propose changing the criteria from:

In addition to the above requirements, the candidate must also meet at least one of the following criteria:

Currently-active extended confirmed editor on the English Wikipedia (i.e. has made edits or logged actions within the last 12 months)

Current administrator on another WMF project

Current edit filter manager on another WMF project

Current WMF developer or staff member who needs access for WMF-related purposes

to

In addition to the above requirements, the candidate must also meet at least one of the following criteria:

Has been an active^[1] member of the English Wikipedia for at least six months and has made over 1,000 edits

Current administrator on another WMF project

Current edit filter manager on another WMF project

Current WMF developer or staff member who needs access for WMF-related purposes - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:46, 21 April 2023 (UTC)[reply]

• Support Likely to make the process easier, while not limiting many deserving editors. Captain Jack Sparrow (talk) 11:41, 21 April 2023 (UTC)[reply]
• Support per my original proposal and comments on Illusion Flame's talk. Schminnte (talk • contribs) 13:35, 21 April 2023 (UTC)[reply]
• Oppose. We should not systemically deny candidates that would do well as edit filter helpers. The proposed change doesn't make the process easier since it doesn't change any specific editor's standard for what makes a trusted user that they would agree to hand the permission to. It's backwards to propose that the requirements for a permission request to be raised, same goes to RFA, because it doesn't make people who think that they are incompetent for the role think otherwise, in fact it is quite the opposite. If we do six months and 1,000 edits as a minimum, then I feel that people with less than 12 months of tenure and 2,000 edits would be slightly turned away by that requirement. 0xDeadbeef→∞ (talk to me) 08:55, 24 April 2023 (UTC)[reply]
• I'm not sure this is the right approach. Probably 99.99% of users with 1000 edits and six months of experience also would not be given this right. Instead we need greater emphasis that these requirements are necessary, but not sufficient. How about something like "There are currently 24 edit filter helpers, compared with 6,878 rollbackers. This is a highly specialized right that is routinely denied even to experienced editors." Hopefully that statistic will be jarring enough to make people pause and look through the EFN archives before requesting EFH. Suffusion of Yellow (talk) 19:44, 24 April 2023 (UTC)[reply]

  I agree with your reasoning. What you propose is a better approach. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:27, 24 April 2023 (UTC)[reply]

  @Suffusion of Yellow, I agree with your reasoning as well. If implemented, six months and 1,000 edits should be an absolute minimum, and it should be stressed that experience is necessary. It seems to me that the main problem is that the information page doesn't quite impart just how much experience is needed. Schminnte (talk • contribs) 20:43, 24 April 2023 (UTC)[reply]

  Yeah that's probably a good idea. I suggested 6 months minimum just because EFH is sensitive. WP:TPE also has a similar 1 year requirement (though I personally think it should be shorter in that case). I think the text you suggest can be added WP:BOLDly as reflecting current consensus.

  Currently the requirements are to be extendedconfirmed however, and I don't think raising the account age requirement to 6 months from 1 month would be harmful, and might give a better idea of the expectations. Galobtter (talk) 21:18, 24 April 2023 (UTC)[reply]

  +1 to your second paragraph. 0xDeadbeef→∞ (talk to me) 00:47, 25 April 2023 (UTC)[reply]

  +1, SoY has covered my concerns well. GeneralNotability (talk) 21:49, 24 April 2023 (UTC)[reply]

• Question. Out of pure curiosity, how many people who would be denied EFH would have a ghost of a chance of passing RFA? If it's any substantial number, that indicates a problem with how we handle the EFH permission, since adminship includes view-only edit filter access. It shouldn't be easier to get full adminship than it is to get any unbundled permission. Taking Out The Trash (talk) 01:57, 25 April 2023 (UTC)[reply]

  I could see myself supporting a hypothetical candidate for adminship but not EFH. It's about risk vs. reward. In either case, there's a risk that their password is "12345", or they're planning to dump all the filters on the website-which-shall-not-be-named. But assume otherwise. With the admin we get pages protected, vandals blocked, backlogs cleared, etc. With the EFH candidate, we get what? A slightly faster response time at EFFPR? This is why I'm only likely to support EFHs who I think are plausible future EFM candidates. We do need more EFMs, but if an EFH request contains some variant of "I don't know regex, but", I tend to sit that one out. Suffusion of Yellow (talk) 21:26, 25 April 2023 (UTC)[reply]

  In addition to the 6 month/1,000 edit tenure, I believe that EFH should be given to trustworthy editors (500 or more responses to EFFPR, participating at the EFN) as this will allow you to see email addresses and phone numbers disallowed by various filters; in addition, we may need to further expand the criteria for revocation. — 64andtim (chat • see here) 14:44, 17 November 2023 (UTC)[reply]

See phab:T367683. –Novem Linguae (talk) 04:27, 24 June 2024 (UTC)[reply]

Editors may be interested in a discussion I have started concerning users who have global abuse filter user rights. Best, Barkeep49 (talk) 16:10, 17 September 2024 (UTC)[reply]