Wikipedia talk:Wikipedia Signpost/Single/2014-10-08

Comments

The following is an automatically-generated compilation of all talk pages for the Signpost issue dated 2014-10-08. For general Signpost discussion, see Wikipedia talk:Signpost.

In the media: Opposition research firm blocked; Australian brushfire (2,961 bytes · 💬)

• The COI editor should be unblocked. This seems like a unilateral action by a single admin, and blocking someone purely because they're making edits that are POV without discussing how to make the edits better shouldn't be allowed. We need to educate on how to cover every side of the dispute. Grognard Chess (talk) Help:Getting rid of Media Viewer 02:19, 11 October 2014 (UTC)
  • I think you've unintentionally hit upon the primary problem. The notion of "every side" needing to be represented so as to create a false balance is the problem. Viriditas (talk) 02:36, 11 October 2014 (UTC)
    • The problem is that we are now banning editors for potential to make bad edits, rather than banning them based on the content of edits. This fundamentally opposes our "Anyone can edit" ideology.AioftheStorm (talk) 04:01, 11 October 2014 (UTC)
      • That's why I made a point of including the content of the edits, which wasn't discussed in too much depth in BuzzFeed. A case could be made that the content is problematic, not just the orientation of editor making them. Another different case could be made that the content of the individual edits isn't particularly problematic, but when you have an editor dedicated to negative content towards one particular group, overall that is problematic. Gamaliel (talk) 04:09, 11 October 2014 (UTC)
        • It's good the you included the content of their edits, but no mention of the content of his edits was made when he was blocked. We don't want to institutionalize preemptive bans.AioftheStorm (talk) 05:12, 11 October 2014 (UTC)
• Wikipedia, the statue that anyone can edit? Altamel (talk) 03:11, 11 October 2014 (UTC)
  • Sorry, but even with Wikipedia, some things are set in stone (especially in this case)! Peaceray (talk) 06:08, 11 October 2014 (UTC)
    • Actually not. I suspect a number of "editors" act during "silly season" and the one which got blocked was the only one which tried to be responsible. Look at the edits of PatToomey for example and tell us whether those edits are as factual as the ones for which these blocks were made. Cheers. Collect (talk) 12:46, 11 October 2014 (UTC)
      • The COI editor has been unblocked: Jehochman reversed himself. Nyttend (talk) 14:35, 15 October 2014 (UTC)

Technology report: HHVM is the greatest thing since sliced bread (4,189 bytes · 💬)

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)

Traffic report: Panic and denial (765 bytes · 💬)

We now can include mobile viewership User:West.andrew.g/Popular_pages Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:42, 11 October 2014 (UTC)

'WTF Fun Facts'? Is that http://wtffunfact.com/ Does that site drive so many hits? If so, where is our article about it? John Vandenberg ^(chat) 04:25, 11 October 2014 (UTC)