Wikinews:Water cooler/policy/archives/2015/January


Can we deprecate this, and remove the corresponding WN:FU section? I never much liked it, and the way we review things now doesn't really square very well with throwing up a picture and saying "We probably can't use this, we'll get around fixing it later though. Promise." BRS (Talk) (Contribs) 22:08, 5 January 2015 (UTC)[reply]

Wikidata

I strongly recommend all routine users turn on Wikidata in RC by default (Preferences->Recent changes->"Show Wikidata edits in recent changes"). Keep an eye out in particular for Wikidata items for categories linked to topic cats. We should be linking directly to the main topics. For example Category:Paris links here not here. This is not obvious to the majority of Wikidata users so naturally we should be on the lookout. Wikidata's pithy local policy on the issue is here, be prepared to link to it.

Having poked around a fair bit with Wikidata I find myself rather warming to it. It does create new problems, but they seem to be worth it to avoid having to make dozens of edits per page just to ensure languages were linked up correctly. It also makes problematic interwiki bots, which were often inaccurate, an obsolete thing of the past. BRS (Talk) (Contribs) 03:37, 15 January 2015 (UTC)[reply]

The functionality could have been provided in a way that doesn't screw over local control by the projects. But their centralizing choice follows from Conway's law. Some of the folks I met at Wikidata were friendly and helpful, but that doesn't make me any less pessimistic about the consequences of the gratuitously centralized strategy. --Pi zero (talk) 04:18, 15 January 2015 (UTC)[reply]
This experience sounds the same as mine. Offline, a lot of helpful and friendly people. Online, software crashes and bug reports. Hawkeye7 (talk) 04:57, 15 January 2015 (UTC)[reply]
I find it daunting to say anything polite about showing Wikidata edits. Watching them ignore their own policies while demonstrating that they don't give a crap about ours just raises my blood pressure; errors that afaics Wikidata's non-wiki-markup design makes maximally difficult to fix. --Pi zero (talk) 04:35, 15 January 2015 (UTC)[reply]
@Pi zero: It's hard to understand what you mean. Can you explain? —Justin (koavf)TCM 04:37, 15 January 2015 (UTC)[reply]
@Koavf: I'm pretty sure I was wrong about the specifics. I find the interface to Wikidata, in all its aspects including the way Wikidata edits show up on Wikinews recent changes, hard to use; the project should have been designed not only to be more distributed amongst the projects in its control, but also to actually be a wiki (i.e., to use wiki markup). In this case, I was probably confused by the fact that Wikidata edits show up on Wikinews RC under the name of the Wikinews page rather than the Wikidata page, so if you want to know what Wikidata item is attached to the Wikinews item you have to follow a link to Wikidata for each edit. --Pi zero (talk) 12:02, 15 January 2015 (UTC)[reply]
@Blood Red Sandman:, apologies that <deleted, irrelevant to the current point> tended to eclipse your specific practical remarks on day-to-day operations.
Do you have any suggestions on how one might diminish either of the drawbacks of showing Wikidata edits — that it tends to flood RC, and that —seemingly— one cannot tell from what appears on RC here what sort of Wikidata structure has been attached to the Wikinews page? --Pi zero (talk) 15:21, 15 January 2015 (UTC)[reply]
I've been a lil cranky lately. I'm not sure if I should apologise given we're moving forward because of it, but... Well, <hugs>. The flooding is generally minimal. Wd is a sufficiently small project that one editor or bot can make a big difference and create flooding, likewise enwn (e.g. if you look now, one user has been doing alot of tidying up of wn items). My suggestion to that is, turn it off when flooding happens and try again in a few hours.
The latter is quite predictable based on the numbers attached to the item. You get the item id in recent changes. Most of our cat-fixing will involve countries and major cities, which seems to have been the earliest items created by wd. So you will look for something in the form Q## or Q###. If you see Q####### it's most likely been erroneously linked to a page collecting categories. The diff link goes to wd and obviously so does the Q#### link, I personally open these in new tabs to check quickly and then close. I do similar when populating new cats. BRS (Talk) (Contribs) 21:21, 15 January 2015 (UTC)[reply]
Example: Cat:Caribbean is currently linked to Q6140308. That's a lengthy item number and, on inspection, links it to other cats. Cat:United States is currently linked to Q30. That's a short number and sure enough is correctly linked to the item for the USofA. Both can be seen near the top of RC with Wikidata enabled. BRS (Talk) (Contribs) 21:26, 15 January 2015 (UTC)[reply]
Ah! The old number-of-digits heuristic. Very neat.
I'm guessing, once one spots a problem like that, it requires tediously manually copying over all the links one-at-a-time from the wrong wd item to the right one (one "edit", but a whole lot of copying-and-pasting — hence my grumble about wikidata not using wiki markup). --Pi zero (talk) 22:15, 15 January 2015 (UTC)[reply]
Oh, wait, it's worse than that. Wouldn't many Wikinewses want the portal associated with the low-numbered item, rather than the category? Since Wikidata doesn't, as I understand it, permit more than one page per wiki to be associated with, say, Paris. Bloody hell. That would seem to make it structurally impossible for Wikidata ever to support both interwikis and sister links at the same time. --Pi zero (talk) 22:25, 15 January 2015 (UTC)[reply]
Sigh. I'm wrong again, or at least sort-of. The Wikidata policy you linked specifies categories, not portals. So maybe some Wikinewses would like to link a portal to Paris instead of a category, but they don't get to do so. --Pi zero (talk) 22:33, 15 January 2015 (UTC)[reply]
Well, to get a feel for what's involved, I decided to fix one. I tried to fix the Caribbean item. It seemed not to want to let me add more than one link to the given item at a time. And it seemed not to be giving me any way of adding an edit summary, so I could invoke the rule that says what I was doing was what was supposed to be done. But then I also was unable to find a way to save the edit. So much for my friendly overture toward Wikidata. --Pi zero (talk) 22:50, 15 January 2015 (UTC)[reply]
Fixed Caribbean. I'm sorry to report it didn't improve my opinion of Wikidata's design concept. I reasoned Wikidata might be balking at adding a page to the correct item (Q664609, a surprisingly long number) because it didn't want that page linked to more than one item at a time. The solution would therefore be to delete the item from the wrong item first; I hesitated, lest I remove it and then be unable to add it back, but then tried. It "worked", in the minimal sense that the objective became achievable. I never did find a way to even ask to have multiple items added. I never did find a way to add an edit summary. And I never did get the software to un-grayout the "save" button, but was sometimes, seemingly at random, able to save an add-link by hitting return while editing a field. I've no real idea why it was being so cantankerous about it now, since I've added to wikidata items before, when somebody proposed to remove all our interwiki markup from a page but I found (on careful manual check) that some interwiki was missing from wikidata's list. --Pi zero (talk) 23:36, 15 January 2015 (UTC)[reply]
Wikidata->preferences->gadgets->move is infinitely useful. Edit summaries are available upon undoing the edits of others. Wikidata went through another redesign/upgrade in the last day or two that could explain the other bugs. My guess is edit summaries in some form will appear within a year or two as the green project continues to grow. Play with it over a few items, it's remarkably simple after a while. (I worked it out for myself, and I still don't self-sight {{topic cat}}s.) BRS (Talk) (Contribs) 00:23, 16 January 2015 (UTC)[reply]
The solution for things like {{topic cat}} is, of course, assistants. I'm not keen on complicated template interfaces either; you'll note how reticent I was about adding another bell-and-whistle to {{topic cat}}, before finally adding the no comma=non-blank option. --Pi zero (talk) 01:09, 16 January 2015 (UTC)[reply]

While we're naming things that would tend to improve Wikidata's database, here are two others: When a Wikidata edit in RC is linking our cat to the correct Wikidata item,

  • Add a wikidata sister link to the category's topic cat (if it doesn't use topic cat, convert it so it does :-). Parameter wikidata goes alphabetically between commons and wikipedia (d goes between c and p).
  • Check the Wikidata item for the corresponding Wikipedia category, in case there are other-language Wikinews categories that got misplaced there.

I just did both of these for our Category:Athens, Greece; we were linked to the correct item, but there were only en.wn and ru.wn there so I checked the wrong item and found five other Wikinewses linked there. --Pi zero (talk) 21:00, 16 January 2015 (UTC)[reply]

Another example: our Category:Beijing was linked to the right item, and so were eight other Wikinewses, but one was all by itself linked to the wrong item (so if any of the other nine were relying on Wikidata for their sister links, that one would have been deprived of its interwiki from those). --Pi zero (talk) 21:16, 16 January 2015 (UTC)[reply]
Not surprising. Incorrect but understandable reverts are also to be looked out for, be ready to link to the explanation when turning them back. I still find WD, for all its multiple flaws, to be an improvement on what went before. BRS (Talk) (Contribs) 00:09, 17 January 2015 (UTC)[reply]
Whenever I do one of these moves, I add the from and to to my watchlist on Wikidata, so when checking my watchlist there I've a better chance of noticing reverts.
"I still find WD, for all its multiple flaws, to be an improvement on what went before."
I don't think WD versus what preceded it is the comparison to make. Wikidata, as I see it, institutionalizes serious structural mistakes that didn't have to be made. The damage that is being, and will be, done by the misdesign is down to the Foundation's misconceptions, and fixing the new set of problems is likely to be a lot harder that it would have been to fix the old problems without introducing the new problems. The fact that WD does alleviate some old problems gives the Foundation an excuse to imagine they didn't make a major blunder with WD. --Pi zero (talk) 00:33, 17 January 2015 (UTC)[reply]
Btw, in one case where some Wikinews cats had just been added to the wrong cat, I left a note on the user's Wikidata talk page, pointing out that the Wikinews cats —including the ones that had already been there— belonged on the other item. (I'm crossing my fingers my tone was sufficiently positive.) --Pi zero (talk) 00:38, 17 January 2015 (UTC)[reply]

One other subtask: check to see if we have any interwikis that wikidata doesn't. I found a whole lot of interwikis on our Category:Archaeology that were missing from wikidata (which I had to add to Wikidata one-at-a-time due to its crappy interface). On consideration, I left our interwikis in place, although, having just spent a great deal of time on that cat, I didn't add local interwikis for the other ones at Wikidata. Nonetheless, as a principle, I favor having local interwikis redundant to Wikidata's interwikis, because that prevents centralized mistakes from depriving readers of interwikis. Naturally, it's then necessary to watch for introduction of discrepancies between Wikidata and local interwikis; a bot could be used to alert human users to any such discrepancies, so that humans can then consider what to do about them — either change the local interwikis, or change Wikidata, or keep the discrepancy (if Wikidata is simply unwilling or unable to follow local best practice). --Pi zero (talk) 14:10, 17 January 2015 (UTC)[reply]

  • Yet another refinement. When some or all of the Wikinews cats are linked on the wrong item (which happens more often than not, seemingly), the move can't be done as a block if there's already some other page from one of the Wikinewses on the right item. This happens often with sv.wn, which differs from most of the others in that instead of a category and a portal for given topic, it has a category and a mainspace page. It's taken me a fair amount of blundering to figure out that the sv.wn mainspace page is effectively a portal, so it seems the appropriate measure is to move it to the portal item. --Pi zero (talk) 21:52, 17 January 2015 (UTC)[reply]
It looks like almost all the topic cats are wrong on Wikidata. In fairness, the one I just straightened out was way worse than usual. New York. Most Wikinews pages were linked under the "Category:New York City" item; some of them were actually the state. Fixing it all involved six items (category, portal, and article; city and state), and studying each linked Wikinews to see if it was city or state and whether it also had a cat for the other. --Pi zero (talk) 14:50, 18 January 2015 (UTC)[reply]
@Pi zero: Have you brought up any of this at d:Wikidata:Project Chat? —Justin (koavf)TCM 19:46, 18 January 2015 (UTC)[reply]
Various Wikinewsies discussed various stuff over there, some time back. I was involved with some of those discussions for a while, till they got way too big and sprawling to follow. I do have one open question there now (you can find it by searching string "pi zero"), no responses to it thus far. --Pi zero (talk) 20:11, 18 January 2015 (UTC)[reply]

Wikidata threat of blocking

A Wikidata admin has threatened to block me there if I continue to correct Wikidata items. I'm exchanging messages with them on my user talk page there atm. --Pi zero (talk) 13:21, 20 January 2015 (UTC)[reply]

For better or, more likely, for worse, I've made this inquiry at Wikidata's chat:
wikidata:Wikidata:Project chat#Threats of blocking and status of Wikinews links practice.
--Pi zero (talk) 19:02, 20 January 2015 (UTC)[reply]