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(a)wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l
--
View this message in context:
http://www.nabble.com/Re%3A-Corporate-vanity-policy-enforcement-tf2358125.h…
Sent from the WikiMedia Foundation mailing list archive at
Nabble.com.