On Jan 31, 2008 6:46 AM, Angela beesley@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.