RationalWiki talk:Community Standards/Archive26

Banning impersonating signatures

This discussion was moved here from RW:ATIM.

In case you're unaware, Monet aka Kevlarstar used Template:USERNAME in their signature for a period of time, making it look as if other people were posting their comments, which recently resulted in a lot of confusion. I think there should be a formal rule banning this and other similarly impersonating signatures, what do you think? Plutocow (talk) 14:16, 9 July 2021 (UTC)

Agree. Fun fact, before he turned into Kevlarstar and Monet, he was known as Iwillprobablygetbanned. Still looking forward to him becoming more than a drive by nuisance to really earn that original nick. Knight Commander^{In Service}_{To Her}^Goatness 14:21, 9 July 2021 (UTC)

I agree that was an abuse of the user name template. Whereas at the time the comments were first posted, most RatWikians would have quickly realized what was going on and that they weren't being impersonated, we've seen today that it can cause a lot of confusion later. People have imperfect memories and, looking back on comments from weeks, months or years ago, that misuse of the template could easily lead them to believe they said and did things they never did. It shouldn't be allowed to happen again. Spud (talk) 14:45, 9 July 2021 (UTC)

Zero objections. Also didnt know that Monet was Kevlar/Iwillprobablygetbanned. Should probably propose this on the CS talkpage with some formal text about not having a disruptive signature. @Plutocow let me know if you want to do that, I can set up the site header for that to be put to a vote. Techpriest (talk) 16:08, 9 July 2021 (UTC)

Yes, I would support having a vote. Plutocow (talk) 16:15, 9 July 2021 (UTC)

Yeah, RationalWiki_talk:Community_Standards is where this belongs. As per Techpirest. Knight Commander^{In Service}_{To Her}^Goatness 16:18, 9 July 2021 (UTC)

I don’t think we need to formalise this, far too much hassle. Mods can just use common sense. Christopher (talk) 16:30, 9 July 2021 (UTC)

This could get annoying fast...CorruptUser 16:36, 9 July 2021 (UTC)

I agree. Bongolian (talk) 18:35, 9 July 2021 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@Monet, you are hereby forewarned. Bongolian (talk) 18:35, 9 July 2021 (UTC)

As an aside, i lose track of who used to be who with everyone changing their username every five minutes. its a real pain in the arse and you all should stop it AMassiveGay (talk) 17:21, 9 July 2021 (UTC)

Don’t worry, I already learnt my lesson. Monet ^Ye 19:19, 9 July 2021 (UTC)

Thank you. Bongolian (talk) 19:23, 9 July 2021 (UTC)

Vote

Aye

1. Monet ^Ye 16:01, 10 July 2021 (UTC)
2. No real reason for people to have these, it just creates confusion with archiving. Most other wikis ban these, I don't see why we shouldn't. Plutocow (talk) 21:36, 10 July 2021 (UTC)
3. Because we have seen this lead to a good user regretting and apologizing for something he never did. It shouldn't be allowed to happen again. Spud (talk) 08:14, 11 July 2021 (UTC)

Nay

• Only an issue with some potential signatures, should be dealt with on a case-by-case basis by mods. I’m opposed to formalising something as niche as this in the CS. Christopher (talk) 20:10, 10 July 2021 (UTC)

Goat

• We have a long tradition of using this to make jokes. It's annoying the first time you get caught out but after that it's usually not a problem. But I would be happy with a ban or not.Bob^{"Life is short and (insert adjective)"} 16:22, 10 July 2021 (UTC)
  • We're not talking about banning the username template altogether, I'd be strongly opposed to that, just banning is use in signatures. Spud (talk) 08:09, 11 July 2021 (UTC)
• I thought the consensus was that we didn't need a vote. It can be dealt with on a case-by-case basis if necessary. Bongolian (talk) 18:29, 10 July 2021 (UTC)
• Go to "Preferences"; "Gadgets","User interface gadgets"; select: "Display a warning on usernames inserted by Javascript. " Simples! Scream!! (talk) 18:48, 10 July 2021 (UTC)

  Thanks for that.Bob^{"Life is short and (insert adjective)"} 07:52, 11 July 2021 (UTC)

• This whole thing is dumb, and I'm not even going to vote. Chef Moosolini’s Ristorante Italiano^{Make a Reservation} 20:56, 10 July 2021 (UTC)
• The two week voting period is over, and it seems that this passes 3-1. Plutocow (talk) 20:30, 25 July 2021 (UTC)
• It's rather absurd that this passes on 3-to-1. My complaint about an impersonating signature had induced Plutocow to initiate this vote, but I didn't even care enough to vote. Lack of voting means few people care. Bongolian (talk) 03:58, 14 September 2021 (UTC)
  • If you didn't want it to pass, you should've voted against it while you had the chance. Plutocow (talk) 04:03, 14 September 2021 (UTC)
    • That's not what I was saying. Bongolian (talk) 04:07, 14 September 2021 (UTC)

Range blocks for /64 on IPv6: Implemented

So if you've not been living under a complete technical rock, you may have noticed that the internet is moving over to IPv6 for it's IP address allocation more and more. While this is an exciting time that mostly tech nerds get really happy about, it proposes a conundrum for us. I'll try to illustrate this to the best of my ability so hold onto your horses. Most of the next paragraph will make sense if you've been here for a bit, but it helps as a bit of a refresher.

Every website and user on the internet uses an IP address to connect to other websites and other users. Normally, as most of us know them, an IP address is something like 127.10.2.5, a small collection of numbers. Most people usually only get one IP from their ISP, this is called a static IP, whereas others have the option to change their IP (willingly or unwillingly), and this is called a dynamic IP. In addition, you should know that all IP addresses are allocated in ranges. For example, in the case of 127.10.2.5, it's very likely that every IP between 127.10.1.1 and 127.10.255.255 all got allocated to the same ISP (or hosting company, both can buy IP adresses). This is called an IP range and is usually either notated as 127.10.0.0 or 127.10.0.0/16. That last one is known as the CIDR notation, and while that is too difficult to get into in this explanation, all you should know is that a /48 is usually allocated to an ISP, rotating IPs usually go over a /24 and a /128 is just a normal IP address.

With all this in mind, there is a bit of a problem; we have run out of IP adresses to assign to people. There are only so many ranges you can give to devices on the internet, and we've exhausted all numbers (kind of, the US department of defense actually has a bunch of fairly large ranges dedicated for it's use alone, but they've been releasing them back to the public gradually). To solve this, a bunch of very smart tech nerds thought up the solution: IPv6. While not every ISP supports it, most these days do, and it's become customary to make websites accessible on both IPv4 (what old IP addresses are called) and IPv6.

That said, technologywise, IPv6 aimed to solve pretty much every problem IPv4 could possibly have. This includes something that affects us. Rather than the traditional method, where every user usually has one IPv4 adress and a dynamic IPv4 was generally used to allow ISPs to get away with buying less addresses than they actually had customers for, IPv6 offers way larger ranges than IPv4 ever did. The advantage is obvious; people get more static IPs, right?

Well, no. Instead, they also tried solving the so called "private space" problem. You see, IPv4 has an entire range dedicated to private use for internal IPs (It's usually the range that your router assigns internal network IPs for, if you are a bit more technical), which with the massively increased ranges of IPv6 would be overkill to repeat and would be seen as a waste of address space. Instead, IPv6 addresses are much longer, with individual customers being given a range of addresses rather than a singular address. This way, IPv6 addresses could be used internally for different devices, but also exposed over the same IPv6 to the internet, without needing to go through the major hassle of port forwarding the router, which limits options.

So, for our problem: Right now, RationalWiki has an unwritten rule where we don't do rangeblocks of IP addresses unless they pass by community vote, mostly because of how a certain other wiki has handled IP blocks in the past. While this works for your average driveby vandal, we are also seeing the occasional IPv6 vandal appear. This leads to a conundrum; it's a lot easier to IP hop with IPv6 than it was with IPv4, since unlike before, where a single IP usually represented a single customer, any individual customer now has access to uh.. 18,446,744,073,709,551,616 IP addresses (that's 2⁶⁴ and is a lot), and that's without the potential of rotating addresses.

If we want to solve this in an equivalent way (where a single enduser address on IPv4 is identical to a single enduser range on IPv6), you would need to allow for the blocking of /64 ranges on IPv6. You can see this page for more or less what this looks like (reference the table, sorry I know this is bad for colorblind people, but the blue ranges are individual enduser privately and the first green range is what a customer has access to).

As a result, and in order to solve this issue, I would like to propose the following clarification about range blocks and IPv6 blocks in the Blocking Policy in a new paragraph to be added to that page (under Blocking Tools). -- Techpriest (talk)

Range blocks

tl;dr Don't enact rangeblocks without a vote unless it's IPv6, in which case you can enact a /64 rangeblock.

When blocking IP addresses, it might be tempting to issue a rangeblock against the address to avoid the user from hopping IPs. Because of the nature of IP addresses, we have two different policies in place:

• When dealing with an IPv4 address (ie. 192.37.67.132), do not issue rangeblocks. IPv4 addresses can sometimes be statically assigned, meaning that a range block could potentially hit other users. If you have evidence that someone is hopping IPv4 addresses to disruptively edit the site, you can ask for a rangeblock on the moderator noticeboard.
• When dealing with an IPv6 address (ie. 2407:7000:9700:CA00:84A3:2F0E:4517:174F), you are allowed to issue a /64 rangeblock. Unlike IPv4 addresses, individual users behind an IPv6 get assigned ranges. The smallest possible range that an individual user can get assigned is a /64 (which still encompasses 2⁶⁴ addresses). To this end, any sysop is allowed to issue /64 rangeblocks freely. To do this, enter /64 after the IP address when blocking the user. The site will automatically take care of modifying the IP for the assigned range. If you have evidence that a user is hopping ranges larger than /64, you can ask for a relevant rangeblock on the moderator noticeboard.

When reporting IP hopping to the moderator noticeboard, make sure to mention the range you want blocked and provide evidence of users in this range making disruptive edits over a short period of time.

Do note that issuing rangeblocks on IPv4 addresses or rangeblocks larger than /64 on IPv6 addresses outside of community votes is considered sysop rights abuse and may lead to consequences.

In the event that this is somehow not desired (Nay), I will be putting this on the blocking policy page instead, since this is current effective policy:

Range blocks

We don't issue rangeblocks against IP addresses without a community vote. If you have evidence that someone is hopping IP addresses to disruptively edit the site, you can ask for a rangeblock on the moderator noticeboard.

When reporting IP hopping to the moderator noticeboard, make sure to mention the range you want blocked and provide evidence of users in this range making disruptive edits over a short period of time.

Vote

This vote has been closed. Please do not add, remove or change votes. The result of this vote was: Passes 13-0. (100% Yay.) -- Techpriest (talk) 08:53, 14 September 2021 (UTC)

Yay Either we tackle this problem now, or we don't tackle it and we'll drown into IPv6 BoN spambots once this really kicks into gear. -- Techpriest (talk) 18:54, 6 September 2021 (UTC) Even as a non tech nerd it makes sense to me - well written - thanks. Aloysius the Gaul (talk) 22:00, 6 September 2021 (UTC) I support it because of wp:WP:/64, which describes it as well. Be careful not to mistype and type a /63 though when requesting! Andrew5 (talk) 23:02, 6 September 2021 (UTC) We should be willing to do more when an annoying IP spammer shows up. Plutocow (talk) 23:34, 6 September 2021 (UTC) If such blocks pose no risk of collateral damage, I see no non-dogmatic reason to oppose this. 𝒮𝑒𝓇𝑒𝓃𝑒 talk 23:37, 6 September 2021 (UTC) Seems a decent proposal. I don´t want to be hampered dealing with a new Morris.𝔖𝔲𝔪𝔪𝔞 𝔄𝔱𝔥𝔢𝔬𝔩𝔬𝔤𝔦𝔠𝔞 (𝔮𝔲𝔢𝔯𝔢𝔩𝔦𝔰) (𝔰𝔠𝔯𝔦𝔭𝔱𝔲𝔯𝔞) 00:24, 7 September 2021 (UTC) Chef Moosolini’s Ristorante ItalianoMake a Reservation 01:26, 7 September 2021 (UTC) Let's take action now. Spud (talk) 01:34, 7 September 2021 (UTC) Yes, as per the time limit caveats discussed below. Bongolian (talk) 06:08, 7 September 2021 (UTC) . Ok. I'm convinced.Bob"Life is short and (insert adjective)" 12:40, 7 September 2021 (UTC) Fair enough. GeeJayK (talk) 15:51, 7 September 2021 (UTC) Yes, explanation presented makes sense, and let's be honest, it will become an issue at some point. Give the vandals enough time and they'll adapt.--NavigatorBR (Talk) - 01:11, 9 September 2021 (UTC) ShabiDOO 16:25, 9 September 2021 (UTC) Nay Goat This also counts as our clarification on our stance of rangeblocking, which isn't codified anywhere as of right now but does have standing undescribed policy. -- Techpriest (talk) 18:54, 6 September 2021 (UTC) Also yes, I kinda implied it in my original proposal, but RW is accessible on IPv6. -- Techpriest (talk) 19:15, 6 September 2021 (UTC) If sysops are allowed to issue IPv6 range blocks, shouldn't there be a time limit for such blocks unless there is community consensus for longer blocks? Bongolian (talk) 19:18, 6 September 2021 (UTC) We already regularly ban IPv4 adresses for infinite. A /64 block is identical to a single normal (non-range) IPv4 block, so that would also require changing our rules for IPv4 blocks in my eyes. Keep in mind that this IPv6 range is to pretty much create equivalency between a single IPv4 block and a "single" IPv6 block. -- Techpriest (talk) 19:21, 6 September 2021 (UTC) No one has ever blocked an IP address indefinitely. Christopher (talk) 20:43, 6 September 2021 (UTC) I stand corrected, although with the caveat that this is obviously only those still left standing. But yeah time limits should be the same as regular BoN, so basically anything that's not infinite is safe, but try to stick to the "bore them to make them go away" degree. -- Techpriest (talk) 21:47, 6 September 2021 (UTC) Just wanted to add, I've been explicitly admonished years ago for putting an IP on indefinite (bin rather than block tho), so I'm doubtful it's anything new. ℕoir LeSable (talk) 02:16, 7 September 2021 (UTC) I second establishing a time limit in guidance. Or at least provide guidance that v6 blocking should have lower cap than v4 ones. ℕoir LeSable (talk) 02:13, 7 September 2021 (UTC) For now, I’m happy to defer to the judgment of our resident tech-experts. LeucippusSalva veritate 22:21, 7 September 2021 (UTC) Ineligible There is no evidence that IPv6 spammers will drown wikis. Also, I don't want any poor user who gets blocked for no reason but have a similar I.P to a spammer. BeardOfZeus (talk) 23:02, 6 September 2021 (UTC) @BeardOfZeus Due to IP alignment, it will only be on one computer. Saying that is like saying "we shouldn't block IP x.x.x.x as it is a school IP". It should still be blocked if it causes disruption. If someone has the IP 2a01:4c8:495:3993:d1cf:9bdb:17ab:c8aa, chances are the IP 2a01:4c8:495:3993:9abd:4575:2ccd:5689. Andrew5 (talk) 21:48, 7 September 2021 (UTC) The site's traffic will likely increase to some extent in the future, and we want to encourage users to visit and make contribs, right? I'm in. Jake Holmesyell at me 13:58, 7 September 2021 (UTC) /64 on IPv6 is equivalent to a single address on IPv4 (a home router tends to get exactly one from the ISP). I switch IPv6 addresses every day, but my /64 remains constant pretty much forever. Elli (talk) 23:09, 13 September 2021 (UTC) Ineligible, see Eligible users. Monet Ye 10:40, 7 September 2021 (UTC)

Change recommended spambot block length to pi times infinity: Fails

This vote has been closed. Please do not add, remove or change votes. The result of this vote was: Fails, 8-9. (47% Yay.) -- Techpriest (talk) 08:55, 14 September 2021 (UTC)

This is something that many of us are doing already, but it would probably be a good thing to codify it. The thing with spambot accounts is that many of them nowadays will come back weeks or even months later to continue their spamming after they were already blocked, so three day blocks aren't really cutting it anymore. Spambots will never ever be constructive users anyway, so there really is no reason to not permaban them. Of course, this doesn't mean that I think the edit filter should be doling out infinite blocks in case of a false positive, but for the ones that slip through the cracks, they should be nuked into eternity. Also, we could probably include a reminder to remove TPA for spambots. Plutocow (talk) 01:30, 7 September 2021 (UTC) Hai (Yea) There is no reason why we shouldn't be permabanning spambots. Plutocow (talk) 01:30, 7 September 2021 (UTC) Already what we do in practice. The one time permablocking with revoked talkpage access has an actual benefit. Christopher (talk) 11:37, 7 September 2021 (UTC) Yes, any spambot that escapes the filter should immediately be banned forever. Spud (talk) 14:00, 7 September 2021 (UTC) Damn the spam! Chef Moosolini’s Ristorante ItalianoMake a Reservation 14:00, 7 September 2021 (UTC) Plutocow made a joke here.It's serious business then. GeeJayK (talk) 15:55, 7 September 2021 (UTC) -Flandres (talk) 17:05, 7 September 2021 (UTC) This applies to non-BoN accounts, so no loss. Bongolian (talk) 17:56, 7 September 2021 (UTC) Yes, all and all the reasoning is sound.--NavigatorBR (Talk) - 01:09, 9 September 2021 (UTC) ShabiDOO 16:24, 9 September 2021 (UTC) Iie (Nay) Sometimes humans make mistakes as well, and a permablocked spambot by a human might still be a false positive. Human make errors. I would support permabanning on a 2nd offense when it becomes clear, but not 1st. It leaves room for error. Unless there TPA is enabled,and only disabled if it spams the talk page. --Andrew5 (talk) 13:08, 7 September 2021 (UTC) (unstruck 20:37, 9 September 2021 (UTC))Andrew5 (talk) -Hastur! (talk) 15:51, 7 September 2021 (UTC) It's best to err on the side of caution with automated systems, thus allowing for manual oversight. ☭Comrade GC☭Ministry of Praise 17:35, 7 September 2021 (UTC) @GrammarCommie It actually says "Of course, this doesn't mean that I think the edit filter should be doling out infinite blocks in case of a false positive, but for the ones that slip through the cracks, they should be nuked into eternity." Automated systems would stay 3.6 days. Andrew5 (talk) 18:37, 7 September 2021 (UTC) I object, mostly because I've had to deal with users who accidentally got permabanned because of zealous sysops who confused them with ban evaders, spambots and the like. Codifying that would in part mean codifying our ability to never be wrong on this matter. Also there is no draft text proposed here, I want to see the language this would take on the blocking policy page. This one might be changed if the proposed draft text is acceptable, but until then it's a Nay. -- Techpriest (talk) 21:21, 8 September 2021 (UTC) I’ve changed my mind, per Techpriest. No one is objecting to indefinitely blocking actual spambots in practice, this’ll just be used as a defense for overzealous blocking. Christopher (talk) 06:45, 9 September 2021 (UTC) Per Techpriest. 𝒮𝑒𝓇𝑒𝓃𝑒 talk 12:22, 9 September 2021 (UTC) This proposal is a facile gambit: it leaves no room for the cognitive flexibility that Techpriest had to employ when dealing with users who were accidentally banned. I think a moral from Oliver Heaviside applies here (from his “Electromagnetic” ii, 33): “Nothing could be more fatal to progress than to make fixed rules and conventions at the beginning, and then go on by mere deduction. You would be fettered by your own conventions […] stopped by your own rules.” LeucippusSalva veritate 20:29, 9 September 2021 (UTC) Per Techpriest/GC as well. ℕoir LeSable (talk) 15:02, 10 September 2021 (UTC) Bob"Life is short and (insert adjective)" 08:38, 14 September 2021 (UTC) Yagi (Goat) Pi is wrong. Should be tau times infinity. Hmmph (talk) 03:26, 7 September 2021 (UTC) I'd just like to say that in two and a half years in Japan, I only heard someone say "iie" once. The person who said it was a woman at the next table to me in Makudonarudo who was being asked by a sleazy photographer if she'd like to do a nude photoshoot. The Japanese really do not like sating "no". Spud (talk) 14:00, 7 September 2021 (UTC) @Plutocow Let’s say the spammer is using some arbitrary IP, why should we indefinitely ban this IP? If we do, we may prevent good-faith users from contributing. LeucippusSalva veritate 22:15, 7 September 2021 (UTC) We're indefinitely banning accounts, not IPs. Plutocow (talk) 22:16, 7 September 2021 (UTC) I see, that’s certainly less problematic. LeucippusSalva veritate 22:27, 7 September 2021 (UTC) Please provide a draft of the exact text you want included in the CS. Then I'll vote. -- Techpriest (talk) 01:03, 8 September 2021 (UTC) Probably the main change would be to move "Clear spam/bot account" and "Clear spam/bot account (see edit filter)" to "Serious infinite-block reasons (to be used when deserved)" on MediaWiki:Ipbreason-dropdown. Apparently, the CS and the blocking policy both say that obvious spambots should be permaed, so the discrepancy between them and the block reasons is odd. Plutocow (talk) 03:35, 11 September 2021 (UTC) If this fails, are rules bitches gonna crawl up my ass about permablocking spambots when the filter misses them? Chef Moosolini’s Ristorante ItalianoMake a Reservation 03:28, 11 September 2021 (UTC) Ineligible BeardOfZeus (talk) 01:47, 7 September 2021 (UTC) (Profile) - (Spoke!) 15:58, 7 September 2021 (UTC) Same reason. Monet Ye 10:56, 7 September 2021 (UTC) I think they are eligible, they've been here since April and have more than 75 edits. GeeJayK (talk) 17:11, 7 September 2021 (UTC) They're close, but not quite at 75. They're not in the eligible users usergroup. Plutocow (talk) 17:29, 7 September 2021 (UTC) @Plutocow My count shows BeardOfZues at 80, does he have to re-vote or does his vote automatically become eligible? (FTR, his vote was yea.) Andrew5 (talk) 18:41, 7 September 2021 (UTC) His account is only 12 days old. Monet Ye 18:54, 7 September 2021 (UTC) Oh. TransChicken is at 69 edits, so if they make six more, then they will be eligible. Will they have to re-vote or could it just be moved? Andrew5 (talk) 21:34, 7 September 2021 (UTC) No, the Eligible users policy is clear on this. You need to have 75 edits by the time of the vote, as well as 3 months of registration. Edits afterwards don't actually count (otherwise a malicious user could just rapidly spam the site over the course of a few days to bump a couple of accounts up to vote a certain way). -- Techpriest (talk) 21:21, 8 September 2021 (UTC) I heard here that if you surpass 3 months you're eligible, it also says "you must have at least 75 total edits and a registration date at least three months prior to the conclusion of the vote". (Emphasis mine). Maybe there can be another vote on this? I will also ping @Christopher, since he wrote that comment (albeit 5/30/2021).--Andrew5 (talk) 23:40, 8 September 2021 (UTC) I will certainly raise this issue. It should definitely be reworded to "before the start of the vote" as anyone can build up 75 edits through foolery once a vote starts. The idea is to be inclusive of relative beginners (a good thing) but not virtual entrants to the site. ShabiDOO 12:07, 9 September 2021 (UTC) Thanks. When I have more time I'll probably start a vote.--Andrew5 (talk) 18:39, 9 September 2021 (UTC) Vote started below.--Andrew5 (talk) 20:47, 9 September 2021 (UTC)

Changing who is eligible to vote

In this discussion on this page, there was a dispute on if a user's eligibility should be on the start of a vote or the end. All diffs needed are linked above.

Personally, I am neutral to the idea, but I am starting up a vote nonetheless. On the onehand, it makes sense for the 75 edits, but the 3 months is too iffy, as how could that be gamed? Seventy-five edits is easier to game, though, and nonetheless, I will start a vote. This needs to be settled.

I see both positives and negatives. It would allow more people to vote, but also more trolls to vote, if we leave it as is. A troll could mess up a vote in the chicken coop, if close, and possibly cause a 16-8 vote to fail 16-9, or a 15-8 vote to pass 16-8, and possibly someone who is even block evading. As we saw with Prpht mhmd, sometimes Ken socks can get quite far.

The current text reads,

In order to vote in policy votes, which seek to change the Community Standards or similar official policy documents, or penalty votes, which seek to penalize (or change existing penalties for) a user, you must have at least 75 total edits and a registration date at least three months prior to the conclusion of the vote.

What I am proposing but not voting on, is to change it to,

In order to vote in policy votes, which seek to change the Community Standards or similar official policy documents, or penalty votes, which seek to penalize (or change existing penalties for) a user, you must have at least 75 total edits and a registration date at least three months prior to the start of the vote.

A comprimise, that I will vote in favor of, is to require 75 edits by the start and 3 months by the end as there is no way to tell when a vote on May 14 will start on February 15 for example. It would look like this.

In order to vote in policy votes, which seek to change the Community Standards or similar official policy documents, or penalty votes, which seek to penalize (or change existing penalties for) a user, you must have at least 75 total edits prior to the start of the vote, and a registration date at least three months prior to the conclusion of the vote.

Andrew5 (talk) 20:47 9 September 2021

This vote has been closed. Please do not add, remove or change votes. The result of this vote was: 10-0 support (100% to make it 75 edits 3 months, start. -- Andrew5 (talk) 13:06, 17 September 2021 (UTC)

75 edits 3 months, conclusion 75 edits 3 months, start Fairest and easiest for us to measure. Per Bongolian under goat; we'll get folks gaming the vote either way, but this is the most fair we can make it to avoid people from booting up sleeper accounts. -- Techpriest (talk) 09:25, 10 September 2021 (UTC) Christopher (talk) 09:29, 10 September 2021 (UTC) Scream!! (talk) 11:56, 10 September 2021 (UTC) I just thought this is always how it was...-Flandres (talk) 12:00, 10 September 2021 (UTC) Bongolian (talk) 16:22, 10 September 2021 (UTC) I assume that this means 75 edits before the start, right? CorruptUser 01:41, 11 September 2021 (UTC) Yes. Bongolian (talk) 01:46, 11 September 2021 (UTC) Again, I always assumed this to be the case, and I can’t fathom any serious rationale for the alternative. Chef Moosolini’s Ristorante ItalianoMake a Reservation 03:26, 11 September 2021 (UTC) Good idea to make this clear ShabiDOO 10:52, 11 September 2021 (UTC) I've finally been persuaded. Andrew5 (talk) 12:07, 11 September 2021 (UTC) Bob"Life is short and (insert adjective)" 08:39, 14 September 2021 (UTC) 75 edits start, 3 months end Goat In general, there's no way to prevent gaming the system, only to minimize it. I think that requirements based on the start of a vote rather than its conclusion are less likely to be gamed since the termination of a vote is variable and knowledge of who has voted (and how) is mostly known by that point. Bongolian (talk) 21:11, 9 September 2021 (UTC) I don't think there's a need to vote, just leave it as it is. Monet Ye 10:47, 10 September 2021 (UTC) Whatever the number of edits required or the time since joining, someone will find a way to game the voting. The best way to solve this (IMO) is to encourage as many people as possible to vote, to minimise the impact of troll votes. Avida Dollarsher again 22:14, 10 September 2021 (UTC) I somewhat agree, but the mob will vote against it. This is enough for now.--Andrew5 (talk) 22:31, 10 September 2021 (UTC)