RationalWiki talk:Community Standards

From RationalWiki
Jump to navigation Jump to search

Archives for this talk page: , (new)


For the discussion and voting on the accountability rules for techs, see this archive.
For the discussion and voting on changes proposed in May 2020, see this archive.
For the rewrites and their discussions during January 2009, see the revamp and its talk page and archive, an early draft here, and further discussions here, plus the voting discussion.


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 CommanderIn ServiceTo HerGoatness 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 CommanderIn ServiceTo HerGoatness 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

Banning impersonating signatures

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. Pizza SLICE.gifChef Moosolini’s Ristorante ItalianoMake 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)

Ineligible

A more objective approach on sources

Writing on my smartphone (which is not even that smart to begin with). Sorry if there are even more typos than your average GeeJayK post. I've been thinking about this for a while. I think RW needs a more objective way to deal with sources. Since RationalWiki:Webshites became an unsourced eyesore with things we don't like I don't think it's a good idea to use it as a blacklist. On the other hand, Media Bias/Fact Check has a more solid list of reliable sources. For those who are unfamiliar with MB/FC, they have six categories to measure how factual a source is, from very low to very high. As their name suggest, they also measure the bias of the source, something that we might want to discuss too. In my opinion, anything that has a "high" factual reporting is A-ok as a source, though I think "mostly factual" sources can also be used. Some think MB/FC is biased against the right. I don't think that's the case. There are many center-right/right wing sources with a high or a very high factual reporting, including some sites that RW seems to dislike, like Cato Institute and the Tax Foundation. Meanwhile, many center-left sources (The Guardian, CNN, MSNBC just to name a few) have a "mixed" factual reporting which in my opinion is a no-no.

Of course, we don't have to use MB/FC as a white list too, there's fair criticism towards them too. That's just my first idea. My main point here is that IMO we should at least consider a more official, objective criterion when it comes to sources. I think this might even be good in future ATIM/Coop cases since we can tell new users what they can and what they can't use before adding content to mainspace. GeeJayK (talk) 02:48, 20 August 2021 (UTC)

Edit: User LongStylus mentioned Wikipedia:RSPWikipedia. It} is probably a better source than Media Bias/Fact Check. GeeJayK (talk) 12:56, 20 August 2021 (UTC)

For the record, Wikipedia itself doesn't trust MBFC primarily because the methodology is in the dark. I need to dig up that big list of sources Wikipedia vets. --It's-a me, Lgm sigpic.png LeftyGreenMario! 02:54, 20 August 2021 (UTC)
(C) Also, a practical problem I can think of. Many articles still use "bad" sources. I support Ex nuncWikipedia effects in case we do this, with the "bad" sources only being gradually replaced. GeeJayK (talk) 02:56, 20 August 2021 (UTC)
@LeftyGreenMario You can check them on Wikipedia:Deprecated sourcesWikipedia. I think we can ban the entire list too. As for MB/FC, as I said they are just my first suggestion. My most important point is to make things less arbitrary. GeeJayK (talk) 02:59, 20 August 2021 (UTC)
We should bear in mind that there are generally two types of sources: evidentiary and explanatory. For the former, it's evidence that someone said something; these can often be webshites. For the latter, these generally need to be high-quality sources, though exceptions exist. I think I've come across two Daily Mail citations that we've used (not on the Daily Mail page) that are actually OK. Bongolian (talk) 03:11, 20 August 2021 (UTC)
I agree with you. But the Internet is a big place. If a real information is on the Daily Mail then it's probably on a good source too, so even in this cases I'm not sure we need to resort to them. Although I agree with you that we don't need to revert them on sight like they do on Wikipedia as well. GeeJayK (talk) 03:15, 20 August 2021 (UTC)
Why the heck are The Guardian, CNN and MSNBC "mixed"? WP:PERENNIALWikipedia says they are all reliable. Methinks MBFC is just BS.
Anyways, I think we should use WP:PERENNIALWikipedia to determine whether a source is reliable and can be used for "explanatory" stuff. On the other hand, unreliable sources are useful as well for "evidentiary" stuff and snark. So we shouldn't remove all bad sources on sight; they should only be removed if they are used for "explanatory" stuff. LongStylus (talk) 12:39, 20 August 2021 (UTC)
You meant Wikipedia:RSPWikipedia, right? I'm ok with using it too. As I said MB/FC was just an idea. The most important thing is to have an objective policy on this matter. GeeJayK (talk) 12:43, 20 August 2021 (UTC)
Yes, my bad. LongStylus (talk) 12:46, 20 August 2021 (UTC)
You're right though, RSP is a better source than MB/FC. GeeJayK (talk) 12:56, 20 August 2021 (UTC)
MB/FC lists failed fact checks for e.g. The Guardian on its page. On the one hand, a lower rating when there's known errors in reporting simply makes sense. On the other hand, it's not clear whether MB/FC fact checks are fairly distributed; any given source could have fewer failed checks and a higher rating because it simply ended up lucky, or the opposite, for all we know. --ApooftGnegiol (talk) 13:08, 20 August 2021 (UTC)
For the record, I'm not supporting MB/FC anymore. I'd rather use Wikipedia:Reliable sources/Perennial sourcesWikipedia. GeeJayK (talk) 13:10, 20 August 2021 (UTC)
I agree this is generally a better list, for a quick check on a source. Bongolian (talk) 20:18, 26 August 2021 (UTC)

Don't forget that sources for facts have different standards than sources for claims. Unreliable source:

"The moon is made of cheese[Joe's blog]"

Reliable source:

"Joe thinks the moon is made of cheese.[Joe's blog]"

Rules lawyers on Wikipedia love abusing this distinction to remove factual things they don't like because they're "unreliably sourced". MBFC and WP:RSP are both good vetters. Hmmph (talk) 03:33, 7 September 2021 (UTC)

Coop Blocking, Result; "Longest Block Only"

We need to have an agreement on how to apply blocks when multiple block lengths are proposed. Specifically, are blocks consecutive or concurrent? That is, if we vote to block DooshBag420 for Pi Weeks and Pi Months, do we block them for Pi Weeks + Pi Months, or only Pi Months? And if so, we should clarify the rule in our community standards. CorruptUser 18:10, 26 August 2021 (UTC)

Vöt

Concurrent

"The block length shall be of the longest duration that the community successfully votes to impose" I.e., if the community votes in favor pi months and in favor of pi weeks, the length is for pi months only.

  1. I'll support this. CorruptUser 18:21, 26 August 2021 (UTC)
  2. 𝒮𝑒𝓇𝑒𝓃𝑒 talk 18:22, 26 August 2021 (UTC)
  3. Monet Ye 18:24, 26 August 2021 (UTC)
  4. How we’ve always done it. You get what you vote for, no more no less. People only support the alternative when it’ll get someone they don’t like banned for a bit longer, no one actually thinks it’s a good system. Christopher (talk) 18:26, 26 August 2021 (UTC)
  5. Per Christopher. Honestly, if you really want to do it consecutively, add another vote in the system, like for USHA, where pi quarters of a year (9.42 months) was added (although that failed miserably). Andrew5 (talk) 18:31, 26 August 2021 (UTC)
  6. Easy clarification, fixes ambigiuity that led to the current situation. -- Techpriest (talk) 18:32, 26 August 2021 (UTC)
  7. Bob"Life is short and (insert adjective)" 19:34, 26 August 2021 (UTC)
  8. Bongolian (talk) 19:59, 26 August 2021 (UTC)
  9. Helena Bonham Carter (talk) 02:14, 27 August 2021 (UTC)
  10. I always assumed this to be the case. Pizza SLICE.gifChef Moosolini’s Ristorante ItalianoMake a Reservation 02:59, 27 August 2021 (UTC)
  11. I also assumed this was what we already did. And it seems I was right in my assumption. Spud (talk) 04:12, 27 August 2021 (UTC)

Consecutive

"The block length shall be the sum of all the durations the community successfully votes to impose, rounded for simplicity" I.e., if the community votes in favor pi months and in favor of pi weeks, the length is for a total of about 4 months.

  1. ShabiDOO 21:38, 26 August 2021 (UTC)

Göt

  1. It appears the vote has gone on for over a week, and there is an 11-1 vote to make it "longest sentence wins/concurrently". Is it ready to be marked as successful? — Unsigned, by: Andrew5 / talk / contribs
    Unless 11 people suddenly appear and all join my dissenting vote...then yes, we can fairly safely close this :) ShabiDOO 16:23, 6 September 2021 (UTC)
    Well you'd need less than 11 people, but yeah, closing this. -- Techpriest (talk) 17:52, 6 September 2021 (UTC)
    Implemented. -- Techpriest (talk) 17:55, 6 September 2021 (UTC)

Range blocks for /64 on IPv6

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 264 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 264 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

Yay

  1. 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)
  2. Even as a non tech nerd it makes sense to me - well written - thanks. Aloysius the Gaul (talk) 22:00, 6 September 2021 (UTC)
  3. 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)
  4. We should be willing to do more when an annoying IP spammer shows up. Plutocow (talk) 23:34, 6 September 2021 (UTC)
  5. 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)
  6. Seems a decent proposal. I don´t want to be hampered dealing with a new Morris.𝔖𝔲𝔪𝔪𝔞 𝔄𝔱𝔥𝔢𝔬𝔩𝔬𝔤𝔦𝔠𝔞 (𝔮𝔲𝔢𝔯𝔢𝔩𝔦𝔰) (𝔰𝔠𝔯𝔦𝔭𝔱𝔲𝔯𝔞) 00:24, 7 September 2021 (UTC)
  7. Pizza SLICE.gifChef Moosolini’s Ristorante ItalianoMake a Reservation 01:26, 7 September 2021 (UTC)
  8. Let's take action now. Spud (talk) 01:34, 7 September 2021 (UTC)
  9. Yes, as per the time limit caveats discussed below. Bongolian (talk) 06:08, 7 September 2021 (UTC)
  10. . Ok. I'm convinced.Bob"Life is short and (insert adjective)" 12:40, 7 September 2021 (UTC)
  11. Fair enough. GeeJayK (talk) 15:51, 7 September 2021 (UTC)
  12. 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)
  13. 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

  1. 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)
  2. 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)
Ineligible, see Eligible users. Monet Ye 10:40, 7 September 2021 (UTC)

Change recommended spambot block length to pi times infinity

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)

  1. 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)
  2. Yes, any spambot that escapes the filter should immediately be banned forever. Spud (talk) 14:00, 7 September 2021 (UTC)
  3. Damn the spam! Pizza SLICE.gifChef Moosolini’s Ristorante ItalianoMake a Reservation 14:00, 7 September 2021 (UTC)
  4. Plutocow made a joke here.It's serious business then. GeeJayK (talk) 15:55, 7 September 2021 (UTC)
  5. -Flandres (talk) 17:05, 7 September 2021 (UTC)
  6. This applies to non-BoN accounts, so no loss. Bongolian (talk) 17:56, 7 September 2021 (UTC)
  7. Yes, all and all the reasoning is sound.--NavigatorBR (Talk) - 01:09, 9 September 2021 (UTC)
  8. ShabiDOO 16:24, 9 September 2021 (UTC)

Iie (Nay)

  1. 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)
  2. -Hastur! (talk) 15:51, 7 September 2021 (UTC)
  3. 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)
  4. 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)
  5. 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)
  6. Per Techpriest. 𝒮𝑒𝓇𝑒𝓃𝑒 talk 12:22, 9 September 2021 (UTC)
  7. 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)

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

Ineligible

  1. BeardOfZeus (talk) 01:47, 7 September 2021 (UTC)
  2. Non.gif (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)
Retrieved from "https://rationalwiki.org/w/index.php?title=RationalWiki_talk:Community_Standards&oldid=2360440"