Guillaume Paumier, 24/08/2011 17:39:
Both concerns you raise are valid, and I agree with
you, but globally
enabling the extension by default is no different in that sense from
enabling it one wiki at a time.
Mischievous admins could be abusing AbuseFilter already on any small
wiki where the extension was enabled following a request in bugzilla,
and we wouldn't know about it if no one brought it up to the larger
community.
The difference is that to request it on bugzilla you need community
consensus, which means that the local community agrees, is aware of the
existence and functioning of the extension at least at a basic level and
can monitor it.
Similarly, a group of POV-pushing could be blocking
users, deleting
pages or protecting POV versions on a small wiki, and we wouldn't know
about it either unless someone reported it. Yet, this is not a reason
for not giving all admins block, delete and protect rights by default.
Block, delete and protext are very simple actions; the AbuseFilter is
harder to understand and often even the sysops using it don't know the
effects of their filters. It's not a tragedy, but there must be some
local control: compare the requirement for wikis to have at least two
CheckUsers and not only one.
Globally enabling the extension is merely more
convenient for users
(who don't have to wait until their shell request is processed) and
shell users (who can spend time fulfilling other requests).
I'm not saying we should (I don't know), but we could by default
restrict the abusefilter-modify right to an abusefilter group (as in
en.wiki) which could be assigned only by stewards, who would then be in
charge of actually enabling the AbuseFilter locally without shell
requests. This wouldn't create an instruction creep, it could just
require a local consensus to give all sysops that right, or stewards
could just decide to assign the flag to all sysops who request it
notifying the community.
Nemo