Meta:Babel/Archives/2013-08

Allow email notifications on minor edit

I propose to set $wgEnotifMinorEdits to true on Meta. The change is very minor, because it only adds a checkbox (false by default) on Special:Preferences for those who want to receive talkpage and watchlist notifications also for minor edits.
Rationale: many or most users won't bother, but we have a bunch of busy users of Meta who only watch some pages of their interest and come back exclusively if notified of changes; when you watch only a handful of pages, minor edits can be important too, and marking an edit as minor could also be too easy a way to hide it from review by such users. --Nemo 09:20, 25 June 2013 (UTC)

Support. --MF-W 12:25, 25 June 2013 (UTC)

 Support --Glaisher (talk) 12:27, 25 June 2013 (UTC)

Useful, especially since I'm marking my edits as minor most of the time while not even having the intention to hide them from email notifications. Vogone talk 19:34, 25 June 2013 (UTC)

•  Support Whether an edit is minor or not is very subjective, and some users may be interested in the minor ones. Also, if someone makes a minor edit, you won't get any notifications for any subsequent major edits either, potentially suggesting to you that no one has edited the page since you last looked at it. --Stefan2 (talk) 14:50, 28 June 2013 (UTC)

Filed as bugzilla:51108. --Nemo 13:20, 10 July 2013 (UTC)

This was just done and it works. --Nemo 17:03, 17 July 2013 (UTC)

This doesn't seem to work if a bot makes a minor edit. --Stefan2 (talk) 13:53, 2 August 2013 (UTC)

Allow Meta-Wiki AbuseFilter to block as option

I propose that we give our local AbuseFilter the ability to block as option. Most of our AbuseLog is flooded by spambots which trigger our spam filters. Those specific filters (for example: [1]) are very accurate and have a good performance. The level of false positives would be tad low, and it'll reduce the work of the admins. And since blocking also inmediatelly autoblocks the underlying IP, it'll be (in principle) more difficult for those bots to create more accounts or continue spamming. If approved, we should be careful on which filters we do enable that option of course. Other projects such as mediawiki.org and es.wikibooks have that option enabled and, speaking as of es.wb, it helped reduce the vandalism a lot. Thanks. -- MarcoAurelio (talk) 13:51, 4 July 2013 (UTC)

• Support; blocking the spambots caught by the nearly never-failing filters is an annoying task that can be done automatically. --MF-W 22:48, 5 July 2013 (UTC)
• Support. --Rschen7754 22:51, 5 July 2013 (UTC)
• Support. Filters work well. Ajraddatz (Talk) 23:30, 5 July 2013 (UTC)
• Weak oppose. Humans should be making blocks, not machines. PiRSquared17 (talk) 00:01, 6 July 2013 (UTC)
  • Sure, but simply put, we don't have the manpower for that. --Rschen7754 00:18, 6 July 2013 (UTC)
    • I know this is going to pass, but I feel that blocking n spambots and one innocent user is worse than not blocking those spambots is. PiRSquared17 (talk) 00:42, 6 July 2013 (UTC)
      • I have never seen any false positives on any of the spambot filters, and in the unlikely event that one does occur, the user can simply request unblock and the block can be removed. I feel that the pros far outweigh any cons. -Mh7kJ (talk) 00:49, 6 July 2013 (UTC)
        • Hmm, maybe this would be good then. I would support adding it for any filters with low/no FPs, but I would still not like to be that one new user who is blocked for looking like a spambot. PiRSquared17 (talk) 01:50, 6 July 2013 (UTC)
•  Support. I've seen these filters work very effectively on the Spanish Wikibooks while patrolling RC. I believe humans should perform polemic or difficult blocks; bots and filters can handle uncontroversial cases. --LlamaAl (talk) 00:17, 6 July 2013 (UTC)
• Support, per above. -Mh7kJ (talk) 00:35, 6 July 2013 (UTC)
• Support  ℳono  04:55, 13 July 2013 (UTC)
• No, I don't like blocks by AbuseFilter. Actually, I'd think such a permission should be forbidden on Wikimedia projects, and I'm worried that some wikis may imitate Meta if we go that way (I'm worried enough about the current ones). If the filter works so well, it will be able to disallow all problematic behaviour it identifies (otherwise, I'd be embarassed adding to a workload I don't help with). It's however not true that autoblocks will help. In fact, I've experimented a bit with the principle mentioned by the proposer: on translatewiki.net we've raised autoblock expiry to 14 days and even when blocking some hundred spambots a day they rarely run out of IPs; this filter has way less matches than that in total and expiry is 24 h, so the underlying bot won't even notice, probably, and the same for most bots. --Nemo 07:08, 13 July 2013 (UTC)
• As the one who proposed it on MediaWiki.org, I think it's a good idea for wikis like this one with a low danger of false positives. The filters on MediaWiki.org make something like a fourth to a third of the spambot blocks now, which is a significant workload saving. To counter Nemo, the purpose of the abuse log is to act as a net for catching abuse. Once abuse is identified, there's no need to clutter the log with more of it. Autoblock does indeed prove useless with today's spambots, but that's besides the point of this proposal, which is to save sysop work.--Jasper Deng (talk) 19:10, 13 July 2013 (UTC)

  Just to keep it in mind: the proportion of blocks is not necessarily meaningful, it's possible that some blocks are not really required (many of those spambots don't ever reuse a username); but I understand this argument. "Acting as a net" is the opposite of block first then check, let's ignore this one.

  What I find more convincing is that backstage wikis like Meta and MediaWiki.org might have by themselves a lower danger of false positives because of the different proportions and kinds of edits they receive. This could be a rational reason to make an exception, but too thin a line to eliminate the concerns above (which one can also decide to ignore, "I don't like" means that it's just my personal skin reaction). mw:Special:AbuseFilter/24, for instance, reuses a filter from another wiki (according to the comments) but adds the block; this however makes some of the checks dangerous, i.e. "my homepage": not terrible, but an example of what could happen. We already see many projects copying filters meant for tagging from another wiki and then adding all actions possible, I just hope it doesn't happen for blocks too. --Nemo 06:50, 16 July 2013 (UTC)

• Support with conditions Availability of the option should not make use of the filter automatic, or immediate. I would only want to see such an option used after it has been through the gamut of other options (tag, warn, disallow all before block) and that the filter has been in place for an extended period, AND it is reviewed regularly, minimum of every few days, preferably daily. I would also hope that any abuse filter to block has at least had a level of discussion, and review at least by a second party. — billinghurst sDrewth 13:49, 18 July 2013 (UTC)
•  Support, also for the conditions mentioned by Billinghurst. Certainly a good suggestion to reduce the spam. Trijnstel_talk 21:46, 18 July 2013 (UTC)

---

Looking through the comments here, it seems that there is a clear support to enable the blocking feature of the abusefilter here on meta. I guess I don't need to mention that this should be used very carefully and controlled regularly by humans to minimize possible errors. (I will create a bug right now.) -Barras talk 20:02, 9 August 2013 (UTC)

The bug (52681) has been fixed now, and the option is live. --MF-W 00:10, 22 August 2013 (UTC)

When to review the "Global bans" policy

See Talk:Global_bans#When_to_review_the_policy. --Michaeldsuarez (talk) 13:26, 29 August 2013 (UTC)