Wikipedia talk:Wikipedia Signpost/2014-10-08/Technology report

← Back to Technology report

Discuss this story

UX approach feedback

Thanks for the write-up. Sounds promising. You asked:

... is it appropriate to pretend that we have saved the page when such [spam and vandalism detection] processing is still going on, and to send a message later if the edit is rejected? And if we do that, do we show the updated site to the user while processing is in progress?

I would say yes to both questions, on the principle that the needs of the many outweigh the needs of the few.

Many good editors make rapid-fire, serial micro-edits, with discrete edit summaries; many more editors often take several edits to fix a citation to their satisfaction: both large sets of users would certainly benefit from quick feedback, just as Wikipedia benefits from their test-driven edits.

Screw the UX of the fewer (I hope) suspected spammers or vandals. They can wait. -- Paulscrawl (talk) 01:43, 11 October 2014 (UTC)

I'd be very annoyed to learn that a failed vandalism check caused me to lose an hour's worth of editing work—especially if I logged out and/or killed the session after "confirming" the change. At the very least, automatically-rejected article edits should be saved, even if they're not committed. (Although that may open up the possibility of DoS attacks in which a malicious party repeatedly creates single-use accounts and makes one large spam edit from each account, causing the saved edit files to eat up space. I don't see any simple solution to that.) —Twice Nothing (talk) 20:20, 11 October 2014 (UTC)

Specialist-targeted details

Nice effort to engage with non-specialists at the top, but could you explain for us, for example: "The net effect is to allow an existing PHP codebase to be progressively migrated to strong typing, with many type checks being done pre-commit instead of at runtime.”? Perhaps a wider editorship should know about these things. Tony (talk) 08:09, 11 October 2014 (UTC)

Why? It's strictly a back-end detail. No editors (qua editors) need ever be concerned with it. —Twice Nothing (talk) 20:20, 11 October 2014 (UTC)

Just because editors need not be concerned in order to edit, doesn't mean there's anything wrong with being curious. Personally I think the more the editors know about the technical details (So long as they have the option of not knowing if they get bored), the better. As for the the original question, I'll try my hand at clarifying: Computer programs are generally made up of data, and code or functions that manipulate that data. The data has various "types". For example, it could be a number, a string (computer speak for a series of letters), a boolean (true or false), an array (computer speak for list), or a number of custom made types (classes). PHP generally doesn't care about the types that much. If you have a function named add2, which adds two to a number, PHP will let you output data of any type from that function. This allows for a certain amount of flexibility at the expense of not automatically being able to catch certain types of silly errors (like adding 2 to the string "dog"). If you need to insist that the function only works on numbers, you can add a check, but it is checked when the user is actually running the program (At run-time). With the static typing mentioned above, you can mark certain functions as only outputting data of certain types. If enough things are marked like that, the computer can automatically check that people are not making certain mistakes. Thus such errors can be caught before the code is put on wikipedia servers (pre-commit) instead of when you're editing a page (at runtime). Hopefully that made sense. Bawolff (talk) 22:28, 11 October 2014 (UTC)