I'd be interested in helping with any sort of client & server side development. Not only can it be more covert and difficult to analyize and circumvent, but since sending script may sometime be easier than actually running a server-side version, there is the chance that it might be easier on the servers to implement something of this sort.
Tim Starling-2 wrote:
Wouldn't it be better to apply the filter retroactively, i.e. to delete orphan articles with human confirmation some time after they are created? If we put in profanity filters to prevent bad page saves, Wikipedia would suddenly be overwhelmed with 5H1t, if you understand my meaning. But the current system of IRC notification and semi-automated reversion is strangely effective.
Let's say for argument's sake that maybe there is a way to automatically recognise PR fluff, even if the best method is not by orphan status as geni has suggested. Then you can automate the process of deleting it. Display a big list of articles with a column of checkboxes, click "select all", select "CSD a7" from a drop-down list, click "delete". Wham, all gone. Keep the filters covert as much as possible, e.g. on the client side.
These kinds of features are the things we're trying to encourage with what I've been calling "hybrid" development, i.e. simultaneous development on the client and server. Get the client-side developers interested, ask them what they need on the server side in support, and we server-side developers will see if we can incorporate it into an API or extension.
-- Tim Starling
foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l