Wikinews

Wikinews:Water cooler/policy/archives/2011/February

< Wikinews:Water cooler | policy
This is an archive of past discussions from Wikinews:Water cooler/policy/archives/2011. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current page.


Regarding images of Aselman

I know they have the wrong license, but this user has not been here in years. We have tried to contact him with no success. It is unlikely he will ever return unfortunately. Great contributor, but nonetheless, we know his images will always be "problem images." Can we make some kind of category that will just take them off that list? Something like a local only category... Just an idea. It bugs me to always see them there. DragonFire1024 (Talk to the Dragon) 11:24, 19 January 2011 (UTC)[reply]

They by definition do not fall under fair use (Because they were taken explicitly for us). There was discussion on the local Fair use policy talk page that the WMF at the time might have been open to letting us keep old images, provided that we don't use them on new articles. I think we should try to pursue that (A couple years late ;). Bawolff ☺☻ 23:16, 19 January 2011 (UTC)[reply]
Wait... if the images were taken specifically for us, why is there a problem? And they're all CC-by-ND, which should allow for local project use in any case, I'd think. Gopher65talk 00:20, 20 January 2011 (UTC)[reply]
  • Aselman's images are here under the Image use policy, Grant of License. Iirc, Adambro or someone else from commons was the person who created the whole 'problem images' category to support xyr war on en.WN's image policies (which had specific Board approval before we were allowed upload privileges.) - Amgine | t 20:18, 26 January 2011 (UTC)[reply]
  • Amgine is being charitable; in passing, I will mention the term "freetard", and swiftly move on.
First point: Is there anyone on-project in favour of keeping this idiotic category? It was created by Commoners and people from The Other Place who suffer from 'cultural insensitivity'. The ideals of Wikinews were never considered in the somewhat devisive poll on licencing, and a "dream-world" policy from WP perspective was imposed from the top down.
Wikinews has a local upload policy for precisely these sort of images; The Other Place has a local upload policy so that, once an iconic/breaking news/unreplaceable image is 'stale' they can rip it off. We need a policy that encourages would-be photojournalists - which ASelman qualified as.
So, cut to the chase: We ditch this idiotic category, and we encourage GoL" where usage is exclusive. If we nurture a would-be photojournalist, help protect what might be their livelihood, and showcase their work, they will - in the long term - look favourably on Wikinews. The alternative, as prescribed by the licensing "resolution" is like asking someone in the street to give you their shirt as it is prettier. We need to cultivate photographers who go into journalism; as a platform to start showing their work we build a relationship where photos MSM reject come to us. This was never ever considered in the licensing agreement; I'd rather be pragmatic, open the door to interesting relationship-building, and accomodate people who might need to live off their photography.
Give these folks a chance, I think it will pay off long-term. If Wikinews gets their "just starting in the biz 'Grassy Knoll'" photo, but leaves them in control of it commercially, we'll have hundreds of eager photographers. Else, we look like leeches. --Brian McNeil / talk 21:32, 26 January 2011 (UTC)[reply]
Note, what is being suggested is in violation of a wmf board resolution [1]. Well it is true that the original upload policy was also approved by the board, the newer resolution takes precedence (To quote: "may not be circumvented, eroded, or ignored on local Wikimedia projects." ). I personally do not support new images under the nc or nd cc licenses (or GOL images) as i feel it defeats the whole point of Wikinews. However I feel old images that were once accepted, should always be accepted (at least on old articles). At the time of the foundation's resolution, it was claimed that the foundation would be supportive of allowing old images allowed under the previous policy to stay. We never followed that up. I think we should try to follow that up, instead of just ignoring the official policy and hoping no one notices. Bawolff ☺☻ 02:30, 7 February 2011 (UTC)[reply]
  • Well, we've fought of wave upon wave of Commoners zealously trying to retrospectively apply the policy; I don't see why that should change. Their resolution was "defective by design" – not our problem, quite frankly.
Can you imagine trying to get another resolution through to support us? That'd be a waste of our efforts. If we have any Wikinewsies at Wikimania, get them to bring this issue up with the board. --Brian McNeil / talk 16:30, 8 February 2011 (UTC)[reply]
Well technically the policy is binding on us, and is retroactive (As it stands). Well ignoring it works for now, I don't really think that's a good position to generally hold. Bawolff ☺☻ 00:06, 9 February 2011 (UTC)[reply]
I believe there is general agreement that free content is preferable, but there are irreplaceable images which are acceptable under the current Board policy. In practice this means any freely-licensed content is preferable to unfreely licensed content which is preferable to fair use/fair dealing content which is preferable to no content. Given this priority, nc/nd is far more desirable than fair use, and clearly should be more welcome than fair use. - Amgine | t 19:00, 14 February 2011 (UTC)[reply]
Well that may be logical, I don't think that is reflected in the reality of current policies. If I recall the argument that was used at the time was that a commercial fork would still be able to use any fair use photos, but they wouldn't be able to use any NC photos. My argument here is not so much that the foundations policy is a good one (or bad one for that matter), just that pretending it doesn't exist and hoping no one notices we are ignoring it is a bad idea. Bawolff ☺☻ 20:55, 14 February 2011 (UTC)[reply]
No, that's not the case. An NC/ND image would likely still be available to a commercial fork as a fair use image, for exactly the same reason any other fair use is defend-able (not, I point out, legal under US law.) - Amgine | t 01:48, 16 February 2011 (UTC)[reply]
This has been a problem for a while. It seems to me that the best response is to assert that standard journalistic practices (in particular the practice of keeping perfect copies of articles exactly as they appeared) renders these images effectively irreplaceable and thus arguably ok under the board's resolutions. The argument seems weak but plausible enough that unless we get the board specifically telling us they didn't intend to include this sort of thing we should be ok (and one advantage here is that the board just doesn't care very much about little projects like us so they aren't going to ever say that for the same reasons that they aren't ever going to adopt a fair use resolution that takes our needs into account). JoshuaZ (talk) 04:59, 16 February 2011 (UTC)[reply]

Fewer stories than leads

Last week we went for about three days without publishing a single story. We're on our way to duplicating that, and the days this week when we've published anything, we've usually published only one story. Doing the math, my question is this: when there are fewer than five articles left on main headlines, what do we do about the leads? --Pi zero (talk) 02:31, 8 February 2011 (UTC)[reply]

Ugh, this is getting ugly. The obvious solution is to write some articles :-) - but aside from that, the only thing I can think of is to make sure that the most recent five published articles are never archived (so the "recent" headlines list will always correspond with the lead stories). In the long run though, it might be worth considering pulling one or two of the leads so that it's easier keeping everything fresh - embarrassingly, all leads are well over two days old and some are nearing five days old at the moment. Tempodivalse [talk] 04:32, 8 February 2011 (UTC)[reply]
I did write an article. A so-so one, anyway, and although I was a little slow picking it up, it wasn't too late... when I submitted it, over a day ago. Meanwhile, I kind of fried my brain on it, exercising all those little-used intellectual muscles, leaving me unfit to review the article since submitted by a newcomer, which is about ten hours behind mine on the queue. So I might have done more good for the project by not writing one.
Actually, with javascript on it seems the number of articles listed is one less than the number unarchived, so we'd want six unarchived. My question was probably born of frustration, so not entirely fair: I stopped archiving when we got down to ten articles. Three of the ten are two days overdue, though, and two more will be due at the end of today UTC; so if somebody decided to enforce the archive policy at this point, the answer to my question would matter. It just wouldn't be me doing the archiving. --Pi zero (talk) 06:44, 8 February 2011 (UTC)[reply]
  • Well, more than a full day later and we're still in the same situation we were before. I've had to fail one of the two articles in the queue for {{stale}}ness, and the Indonesia story will follow suit as it passes the 3-4 day mark in a few hours. (I don't have the time or interest to review it right now, it's too long.) The January articles really do need to be archived though. I suggest removing one or two of the leads from the main page - they're all over three days old at this point and at our current output rate there's no realistic chance of keeping them fresh. Tempodivalse [talk] 17:08, 9 February 2011 (UTC)[reply]
I archived two of the remaining January stories. The last one remaining doesn't have as blatant a shelf life, and I just left it, for now.
Participating on Wikinews is a strange combination of immersing oneself in moment-to-moment stuff —which is the nature of news— and not losing track of the long-term big picture. It's unfortunate that things aren't moving at the moment, and working to get them moving is a fine thing to do, but one also has to look at long-term solutions. We need to make it easier both to write and to review articles — not lowering our standards, but making it easier to live up to them. Automated tools should be the key; I'm actually starting to study javascript, for just that reason. (I'm a programmer, if out of practice lately, and in the past I never balked at learning a new language. How hard can it be... don't answer that. :-)
  • Making writing easier should also have the secondary benefits of making it easier to review newbies' articles (the less awful they are, the easier for reviewers), and —perhaps— somewhat lessening the sting to the author if it doesn't work out.
  • We need to make reviewing easier, by finding a way to let multiple reviewers share the burden for each article. I say this about every six months. There's a good reason why it hasn't happened, despite my repetition: neither I nor (afaik) anyone else knows how to do it. But mentioning it every once in a while may help to stir up thoughts, and eventually perhaps one of us will get an insight.
--Pi zero (talk) 20:06, 9 February 2011 (UTC)[reply]

Template:Review

The {{review}} template text is ghastly out of date. Rather than flounder around with edits and non-self-sights directly on the template, given that the template page has a noincluded official-policy notice, this seems a reasonable place to discuss an update. (A flagged discussion on template talk would be possible, but the water cooler generally gets more attention faster.)

The template now looks like this:

I tentatively suggest changing it to look like this:

--Pi zero (talk) 14:40, 5 February 2011 (UTC)[reply]

The danger with verbosity is that it alienates new users. I wouldn't mind seeing a hide/show box to hide some of the jargon -- new users don't need to know technical instructions to the reviewer, only that only reviewers can review. Thinking about it, I'm unconvinced we need any technical instructions on there anyway: (*swivels in his seat towards Bawolff's end of the conference table*) if we take EzPR out of gadgets and stick it into core, we could just stick a [javascript:Bawolff.review.start() click here to begin your review] link into the template, and only display the manual process if .js is disabled. We could also stick tabs into the template, á la {{howdy}}. (By the way, I do think the template needs overhauling, but adding text is the wrong way to go about it. YMMV.) — μ 15:06, 5 February 2011 (UTC)[reply]
Two quick thoughts.
  • Now that you mention it, I'd favor moving all the manual-review instructions, and perhaps all reviewer instructions whatsoever, to a separate page somewhere; by avoiding any mention of {{publish}} here, we might significantly reduce incidence of newbies attempting self-publish. (I do think we should have manual-review instructions somewhere, so once in a blue moon when someone has to, they've got help to do it right.)
  • My sense is EPR isn't ready to internalize, because we haven't got all the bugs ironed out yet.
--Pi zero (talk) 16:43, 5 February 2011 (UTC)[reply]
Gigantic +1 to everything said here. I don't think i've ever actually read what the review template says. EasyPeerReview is already loaded in core js (for people in editor) group for the last little while. Just never got around to killing the gadget. Bawolff ☺☻ 17:04, 5 February 2011 (UTC)[reply]
Okay, here's another version. So far, I've still kept one line of basic instruction for reviewers, plus the extra notice if there's a talk page. Do we want to go all the way to no reviewer instructions at all?
(Note: I think asking for a second opinion on potentially tricky or controversial non-mainspace edits is a healthy trend, and can help to steer well clear of potential edit wars. My point was that this situation required an actual discussion, because non-self-sighting just wouldn't provide enough mutli-way bandwidth.) --Pi zero (talk) 01:54, 6 February 2011 (UTC)[reply]

Arbitrary section break #1

We could probably cut it down some more by removing the instruction to put it at the top of the page. For me, at least, I rely mainly on CAT:REV (or, more specifically, the gadgets that use it) – it doesn't matter where {{review}} is, as long as it's on the page. Now that EPR has a talk-page sniffing thing, we can cut out that too.
We probably need a link to a page explaining what the hell this {{delete}} ← {{abandoned}} ← {{stale}} ← {{develop}} → {{review}} → {{publish}} → {{archive}} thing is anyway. I remember being thoroughly confused when I first encountered it. Maybe a "what does this mean?" section? — μ 02:56, 7 February 2011 (UTC)[reply]
The sheer compactness of that version is appealing. One could imagine re-adding an abbreviated form of the talk-page-reminder magic on the line about please use EPR, without forcing an extra line (on a standard-sized screen)... but, even though I'm a big fan of both reminders and non-JS magic, I'm not sure the reminder would still be worthwhile when that short.
On balance, I like it. --Pi zero (talk) 04:16, 7 February 2011 (UTC)[reply]
I much prefer the last, short version posted. The review template has been growing in size ever since it was first created, and it was getting ungainly:). Gopher65talk 12:22, 7 February 2011 (UTC)[reply]
  • Since the template is effectively considered policy in its own right, I hereby   Support the nice, compact version. Here's my £0.02 towards consensus. Newcomers, who the text is most important to, don't want a scary, complicated set of instructions - they want it clear, concise and small. (My gripe about non-self-sighting is withdrawn on this particular one; fair enough, though, I note it is a more general thing than just this. I'm actually not sure why I mentioned it here - saw an oppertunity? :) Blood Red Sandman (Talk) (Contribs) 17:49, 7 February 2011 (UTC)[reply]
  • Per vague consensus already seemingly gathered, I OBJECT to the new shrunken template, please make the fucking text bigger since without blowing your font up it's a git to read, and you could easily miss information. BarkingFish (talk) 22:54, 22 February 2011 (UTC)[reply]

Trimmed further

I did want to use {{Dynamic navigation small}}, but it doesn't show as auto-collapsed. --Brian McNeil / talk 23:56, 7 February 2011 (UTC)[reply]

I like this one more than the one above or the one below; shorter than the one above, and I find two separate lines neater than a paragraph that wraps around onto a second line. I'll support any of the three for a consensus, though. We've spent enough time on this; let's pick one and go with it. --Pi zero (talk) 07:07, 8 February 2011 (UTC)[reply]

Even more

— μ 00:00, 8 February 2011 (UTC)[reply]

Movie interview

From what I understand, RockerballAustralia, is the director, writer and one of the cast members of a 2011 film called Localise This. RockerballAustralia asked me to interview him, to which I agreed. However, Pi zero has pointed out that an article like this may have "some element of self-promotion (for some value of self) about doing a news report about a Wikinewsie's movie". What is the best way to approach an idea like this? What do you think? --Rayboy8 (my talk) (my contributions) 01:33, 20 February 2011 (UTC)[reply]

The mythic NPOV is a very worthy goal, but it should not be used to prevent useful content generation. News of interest to at least a neighbourhood is our lowest measurement; clearly my doing coverage of how my neighbourhood is annoyed by damage to the street by a current construction project will have some elements of bias, but no one else at en.WN could do this reporting. Likewise, a third-party Wikinewsie interviewing a fellow wikinewsie will have some POV bias, but hopefully not enough to prevent publication. We don't need POV-paranoia any more than we need overt POV; we work to minimize POV, but we cannot eradicate it. - Amgine | t 21:40, 23 February 2011 (UTC)[reply]
  • By and large agree with Amgine; NPOV is an overly idealistic goal for a news site. The vast majority of interviews we conduct adopt a 'soft touch' towards the interviewed. Take a look at the article on the 2,000th enWP FA. Here you'll find something not being hard on those interviewed in any way whatsoever. However, I got what I think is a really interesting article with broad appeal. What makes the difference is the questions asked, and a cooperative subject. When it comes to an utterly uncooperative interviewee, the shoe is on the other foot - if not on a ballistic trajectory towards their head. In this example, I'd suggest asking for a preview of the film for several 'newsies, some outline of why an interview would be newsworthy, then - away from RockerBall's view - preparation of questions for something like an IRC interview. We're not "Hello!" magazine, we have different ideas on newsworthiness, as well as a more realistic view on NPOV than Wikipedia. This is a challenging item, but not impossible. --Brian McNeil / talk 23:05, 23 February 2011 (UTC)[reply]

The peer review mechanism

I made this remark on BarkingFish's user talk just recently, and on consideration, should offer it here.

I see a serious design defect in the mechanism of peer review. We expect one person to do everything, with no safety net against mistakes and a reasonable chance that mistakes won't even be detected promptly. Not only is that error-prone in itself, but as site activity increases, the proportion of publication mistakes increases, that raises tensions, and the project turns into a powder keg. Recalling the way the site exploded last year, I'd say this design defect really needs fixing.

Note there are two parts to this: that peer review is by a single person, and that there is no redundancy. Those two are not independent.

  • The redundancy can't be added without also reducing the individual burden, since the burden is already so high that things go stale waiting for review.
  • It may be unsafe to split the burden without adding redundancy, because the split could open the door to new kinds of mistakes caused by mis-coordination.

--Pi zero (talk) 14:41, 26 February 2011 (UTC)[reply]

So, er, "How?" — μ 14:51, 26 February 2011 (UTC)[reply]
Um... Yes.
Months of wracking my brains over this on my own, with little to show for it, make me think it needs ideas from more minds. So I've brought it here.
A few thoughts. Maybe they'll stir someone else's thinking.
  • Peer review can be split in two directions: by task, and by place in the article.
  • We already divide by task, into five subtasks. The number could be increased, and/or we could have a hierarchy of subtasks; drawbacks are greater bureaucratic overhead and less flexibility. The biggest subtasks —copyright, fact-checking— don't seem amendable to division into subtasks (noting that fact-checking is already a proper subtask of "verifiability", another being suitability of sources).
  • Dividing by place in the article is already possible for a single reviewer; cf. onScreenEdit. Coordinating something by-place for multiple reviewers will likely require serious javascript: whole-page edits are the smallest granularity supported by the wiki software. Blue-skying, perhaps an auxiliary page could be used for coordination data; flaggedrevs might establish authorization, which implies the auxiliary would be in a non-main namespace that supports flaggedrevs. The auxiliary data would have to somehow not get lost when the article gets renamed. And coordination has to allow for edits by reviewers in mid-review. Implementation is left as an exercise for the student.
Not all subtasks would much benefit from being broken up this way; likely prime beneficiaries are fact-checking, copyright.
  • Redundancy is more important in some subtasks than in others — like verification and copyright. Redundant checks should probably have coarse granularity, looking at the big picture; noting, they must be a good deal easier than single-person review, or we aren't better off. The auxiliary data left over from earlier by-place coordination might somehow be exploited as an aid here.
--Pi zero (talk) 19:13, 26 February 2011 (UTC)[reply]
I tried reviewing per-revision on a couple of articles last month to see if it would translate well to multi-user per-revision reviewing. Although, most of the time, it worked well, there were times when either users created the article ready for review, with no earlier revisions, ex. this one. Other times, users added information first and only stuck sources in at the last moment before the review tag. I would still push for a multi-tier FlaggedRevs system in which edits are tagged "checked" (internally) before being tagged "published" (and off to Google News etc.) — re-flags are always quicker to be reviewed than new articles, it seems. I don't know if that's because they are normally minor edits, or because it's easier to review a single addition than an entire article. Nethertheless, I think that per-revision review, bundled with an alternative, back-up, system for the articles that don't conform to the system, might be what we are looking for. — μ 19:22, 26 February 2011 (UTC)[reply]
On consideration, I'm inclined to think this wouldn't work.
  • The definition of publication would have to be changed, to use a higher level of review. That seems likely to be, ah, messy to implement. We'd want to be getting a very high-quality result to justify that: something we expect to completely satisfy our needs for years to come (maybe forever). But I don't think the level of satisfaction would be nearly that high:
  • The efficacy of per-revision review seems to me to depend entirely on a peculiar development pattern. The revisions have to incrementally build the content, without any of the later edits modifying any of the earlier content. Otherwise, in order to review an earlier revision you would have to review content that wasn't even going to be in the revision that's actually a candidate for publication. And what if you can't review a certain revision because there's a defect in it? You can't correct the defect because you'd be wiping out the later revisions — and the defect might already get fixed in some later revision anyway.
It sounds as if you really want to review one paragraph at a time, which is (a slightly restricted version of) what I meant by splitting review by place in the article. If the revision history just happens to be lined up that way, then you can use the revision history to simulate splitting the revision by paragraph; but it's really easy for the revision history to have deviated from that pattern (even if it approximates it), and then you're out of luck.
Or, maybe I'm misunderstanding what you have in mind. :-) --Pi zero (talk) 19:54, 27 February 2011 (UTC)[reply]
Retrieved from "https://en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/policy/archives/2011/February&oldid=4256503"