On Jan 31, 2008 6:46 AM, Angela <beesley(a)gmail.com> wrote:
The regex part is for usernames, not IPs. It's
especially used for
blocking people who troll by using inappropriate names like "Werdna
Sucks". Even without a shared user database, that can be useful.
That's implemented per-wiki using the Username Blacklist extension. I
think per-wiki is probably better in this case than global --
different projects are likely to have fairly different naming
policies, and also most of the wikis are non-English. Of course you
could have global plus local, but I don't know how much more useful
that would be than currently, i.e., if it would be worth the developer
effort and user-end complexity. (One more thing for stewards to
maintain a request list for, one more thing for sysops on wikis to
have to know about, one more possible cause of conflict between Meta
and local communities.)
A global IP block would certainly be useful. Currently stewards would
have to sysop themselves on every project in turn, block, and
de-sysop, if they want to do a global ban. This makes me wonder,
though -- would it be better to have a separate global database of
blocks, or just add an ordinary block to each project's block list? I
don't know if there's any gain in distinguishing between global and
local blocks on the backend. If you do it this way, local sysops will
be able to view, unblock, and adjust the block just like any other
block, and not have to use any kind of separate interface or who knows
what. Some issues:
* The global block list still has to be tracked separately somewhere,
so that new wikis can be initialized with it.
* You would have to have an extension able to access and modify all
other wikis' databases. That shouldn't be a problem, I guess, since
some already do (like changing rights for foreign wikis' users).
* Global unblocks need to be able to distinguish between ordinary and
global blocks, since they should undo the latter but not the former.
This one is a bit tricky, since it's not clear how an extension could
store metadata in a preexisting log.
* The current logging mechanism sucks, and probably won't be able to
cope cleanly with actions taken by off-wiki users. But come on, it
should be improved anyway. It's ridiculous to have no log entries
allowed by anyone other than locally-registered users (no foreign
users, no fictitious users, no anons). This is also moot when SUL
finally arrives, real soon now.
* Arguably, global blocks *are* different from local blocks, and
should be treated as such. But this is only plausible to a point.
Users don't care whether they've been blocked locally or globally, and
sysops don't have to care either, since the procedure for unblocking
would be the same. Users who have been globally blocked likely want
to approach local sysops first, not stewards, because local sysops
more likely speak their language and are more familiar with local
blocking policy (which may differ from global policy).
Advantages:
* Increased local interface simplicity: no need for local sysops to
learn about Yet Another New Feature. Everything's straightforward:
you just have a block like any other, except it was made by someone
who is (visibly) not from the current wiki. This includes only having
to check one block log to establish the reason for a block, only
having to maintain one interface message for blocks -- which isn't
inappropriate, because in any case you're probably going to want to
discuss with local sysops first, not the stewards -- only having one
interface to unblock, and so on.
* No special unblock, logging, or other local interfaces need to be
written, since they don't exist. The only code that needs to be
written is to make a new local database for one project (Meta), and
some code to add or remove a special sort of block to/from many
databases at once. This would basically be a single special page
extension, instead of multiple ones probably needed for the
alternative implementation: one to institute or remove a global block,
one to view global blocks locally, one to institute a local exception.
I think the implementation issues here might be greater, but the
interface and concept would be considerably cleaner. But that's just
my opinion, which isn't particularly important, since I'm not about to
write the thing.