Extension:AbuseFilter/Priorities and Design

Identified Priority Projects (highest impact with minimal dev cost)

Variable / List Maintenance - Bugs 38279, 32928 (maybe), and the general idea to merge SpamBlacklist into AF
Blocking Options (custom time, custom reason) - Bugs 22523, 29739, 30024
Global Blocking - Bug 18660

https://meta.wikimedia.org/wiki/Talk:Global_AbuseFilter specifies a set of functionality that the community would like to see implemented:

Requirement	Design
Large wikis with active abuse filter managers will not be affected by these filters. These are projects such as enwiki, dewiki, itwiki, ptwiki, eswiki, nlwiki ,etc who have active people maintaining the local abuse filters, and would not really benefit from global filters.	Each wiki can opt in to using the rules by setting the global variables, pointing to the shared global tables.
Global sysops would be granted access to the modifying the filters. Since these filters will not affect every Wikimedia wiki, this can be seen within the global sysop scope, as well as the practical application of it in regards to the current role of global sysops in global anti-spam and counter-vandalism.	Rules are modified on meta, so only admins with permissions on meta can edit or view private rules, which are applied globally.
The global filters would not include the options to locally block and remove local rights. These options are not practical with local filters, and even less so with global ones which could cause more false positives.	A new global will be used to control this behavior. If the global is set, the Revoke / Block / Remove actions will be disabled for global rules.
Emphasis will be placed on removing filters after one day, or short time of no positive actions. This policy will exclude filters which just tag edits.	It's assumed this will be done by policy. We will not automatically disable filters.

Most of the development is already done, but untested in production. Some bugs may be opened as issues are identified.
Rules will be kept on metawiki. Database access to meta is required, multi-site db setup a requirement for use.
- Every action triggering AF processing will need to read the global rules from meta's database
Log of hits/actions currently live in the central database (i.e., meta), and accessible based on admin permissions in meta

Throttling is currently done with memcache keys, stored by each wiki
Global Throttling must use memcache, probably using a shared memcache key
Initially, the existing throttle variables should be sufficient if they're globally applied

Do we need to keep global rules in memcache for local wiki access?
- Andrew recommended yes. To store them with a key tied to the central server, flushed when a global rules is updated.
Do we need to list global rules locally in rules view?
- Andrew recommended yes
Do we need to filter log view by originating wiki on meta?
- Andrew recommended yes
Do we need links to the central log from local instances? Or show global hits in the local log?
Does Automatic Disabling need to happen when local wikis trigger global rules over the threshold?