Wikinews

Wikinews:Water cooler/proposals/archives/2010/September

< Wikinews:Water cooler | proposals
This is an archive of past discussions from Wikinews:Water cooler/proposals/archives/2010. 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.


wikt:MediaWiki:Gadget-WiktSidebarTranslation.js

It would be elegant to import this gadget, especially for those who have never installed any additional fonts. It just translates the interwiki links into English, you can test it by ticking it here. JackPotte (talk) 09:16, 19 August 2010 (UTC)[reply]

I'm not really sure if its relevant here. I'd like people to show interest before importing it. Bawolff ☺☻ 17:36, 19 August 2010 (UTC)[reply]
Why not? Diego Grez return fire 20:53, 19 August 2010 (UTC)[reply]
It could be useful for checking interwikis before sighting them. Blood Red Sandman (Talk) (Contribs) 20:54, 19 August 2010 (UTC)[reply]
Does it resolve a known problem or issue? the point is, en.wikinews is already loading a large collection of scripts and (worse!) script libraries which do not do anything 99% of the time. For edge-case users (specialty browsers for disability, old hardware, poor or per-kb-billing internet connectivity, old browsers, etc.) this is already a burden, and should not be added to unless there is a demonstrated need. - Amgine | t 14:27, 21 August 2010 (UTC)[reply]
A better solution to that problem might be to kill off some of the crap... Blood Red Sandman (Talk) (Contribs) 19:59, 23 August 2010 (UTC)[reply]
  • In terms of demonstrated need (Brian's beloved "What is the problem you're trying to solve?"), it is important to translate the titles of interwikis before sighting them. I have previously refused to allow additions of interwikis because, although the other article was about essentially the same thing, it was on another aspect, usually from the day before or after our article, and therefore was not an appropriate addition. Blood Red Sandman (Talk) (Contribs) 18:53, 4 September 2010 (UTC)[reply]

New Main Page Proposal

Hi all, I have created a new main page proposal that I think eliminates a lot of whitespace currently present and organizes it more. The proposal is here. Please leave feedback on the talkpage, I would love to get this implemented! red-thunder. 01:35, 2 September 2010 (UTC)[reply]

It does eliminate whitespace, yes. But at the cost of being extremely busy on non-widescreens. On my widescreen, it's fine, but the non... the entire page just feels like one large blob of text. Also, I'm not enthused with pushing the Latest News section down so far, making is "less important". --ShakataGaNai ^_^ 09:04, 5 September 2010 (UTC)[reply]
I agree with SGN. Also, in my browser the Welcome to Wikinews banner at the top extends to the left. Kayau (talk · contribs) 10:55, 5 September 2010 (UTC)[reply]
That's too crowded, and I don't like the font. Can we please stick to Arial, or at least a sans-serif font? Serif fonts are hard to read on screens, and the main page really ought to use the same font as the rest of the site. Δενδοδγε τ\c 10:34, 6 September 2010 (UTC)[reply]
Related to Dendodge's comments: in general online body texts are sans-serif, headers are often serif. I don't like Arial, but think we should leave the choice of font up to the user's browser; just use font-family:sans-serif;. I personally am not fond of colored backgrounds except where necessary to highlight or provide emphasis. Keep in mind most users will see the main page in the Vector skin, but not everyone. What does it look like in monobook? Simple? etc. - Amgine | t 20:02, 6 September 2010 (UTC)[reply]
Chick, Classic, Cologne Blue, MonoBook, My Skin, Nostalgia, Simple, and Vector. —Mikemoral♪♫ 20:12, 6 September 2010 (UTC)[reply]
Thanks Mikemoral (and Dendodge)... Oddly enough, it almost looks great in CologneBlue (on Ubuntu FF). If the two blue backgrounds were tones of the top banner... - Amgine | t 23:22, 6 September 2010 (UTC)[reply]
Agree. Perhaps use some more brilliant colors? --Diego Grez return fire 23:39, 6 September 2010 (UTC)[reply]
Thanks for the feedback guys. I changed the font to Arial per request. If anyone wants to make any improvements whatsoever, please go ahead and do so. If we work together on this, I'm sure it will come out great. Cheers, red-thunder. 00:52, 7 September 2010 (UTC)[reply]

Wikipedia finally has something good to give. We have Featured Articles, why can't we have Featured Pictures? I've been thinking about this for some time and finally I attempted to comment about it. The only criteria to become a featured picture would be that the picture must illustrate a (past or current) news article. Open to thoughts :) Diego Grez return fire 01:20, 6 September 2010 (UTC)[reply]

If we do this, we shouldn't accept fair use pictures either. This would be a great way to resurrect Picture of the Year: at the end of each year, all the pics featured from articles that year go up for selection to Pic of the Year. Blood Red Sandman (Talk) (Contribs) 11:40, 6 September 2010 (UTC)[reply]
I support that even though I am not very active in this community. --Mattwj2002 (talk) 23:40, 6 September 2010 (UTC)[reply]

Changing how we handle shorts

At present our handling of shorts is less then ideal. It is impossible to find a short in a category other then by guessing. Search has gotten better, but is still handles them poorly. RSS and Twitter display them oddly as well. You also have no idea what the shorts are going to be before you click on it.

I would like to propose making the following changes:

  • All shorts sections would be their own articles
  • We tag them with a category that we exclude from the normal list on the main page
  • We add a section to the main page (below the normal articles?) that we dpl in the days shorts

These changes fix all of the problems I listed above and also make reviewing much easier (only have to review one section at a time). Secondary benefits include making our coverage appear to be more comprehensive and encouraging more people to write shorts via better exposure (and with luck eventually graduate into writing full articles). Thoughts?--Cspurrier (talk) 01:02, 23 August 2010 (UTC)[reply]

Oh yes! This should stop good shorts getting stuck in review treacle.
Let's have a distinctive headline style, to set expectations in headline feeds, search results and portals. I propose starting each one with "Brief: " such as,
Brief: General Motors recalls 243,000 crossover vehicles
--InfantGorilla (talk) 10:03, 23 August 2010 (UTC)[reply]
Suggest "In brief:" or "In short:". Note that any en.WN article may also have a short; if a standard practice were to write a single paragraph short, it could also serve as the lede for news articles (although that would entail more work in maintaining the short for articles which are still developing.) - Amgine | t 05:43, 25 August 2010 (UTC)[reply]
  • I like your (Amgine's) suggestion for the headline.
  • Why not copy and paste the short into the lede of an expanded article? Then the short would be frozen in time, while the expanded article would be developed and published a few minutes or many hours later, by which time the opening paragraph would look a little different.
  • (It would be nice to have a forward link from the short to the in-depth version, but that is for a different discussion)
  • Shorts can also be used for brief updates on an existing full article. For example last month we published a story about a writer who was arrested by Singapore police. 48 hours later he was bailed, which was an important update, but not enough for a full article. It would have made a good short if we could get it out quickly (rather than wait a day or two for a 'shorts' combo with 2 unrelated stories) and would be helpful to show in the news feed. In the end, the release on bail was never reported by Wikinews (though I did mention it in 'Opinions') but nearly all other outlets that covered the original story reported the release.
--InfantGorilla (talk) 12:54, 25 August 2010 (UTC)[reply]
Did some work on this today, but having transclusion problems. Apparently the main namespace does not allow transclusions from the main namespace. Not sure about this, but trying to figure it out. - Amgine | t 20:48, 2 September 2010 (UTC)[reply]

Without supporting infrastructure already in place (alas, we haven't worked that out yet), it doen't work properly. Due, as far as I can see, entirely to the unfortunate lagging of infrastructure behind the concept, we had an article get put on the main page with a nonstandard title (advertising an erroneous publication date, which was also advertised by an erroneous date category), and no dateline (that might otherwise somewhat illuminate the situation).

In an (I believe) logically separate issue, the article didn't have any sources on the page, but instead a link to the talk page where the sources were listed. BRS had objected to this concept earlier today (and elsewhere), on the grounds IIRC that it would put the sources on an unsightable page. I'd been thinking of adding to that, that identifying the sources of the article is basic information that I would think should always be visible as part of the article itself, in order for the reader to make a basic assessment of what they're reading. --Pi zero (talk) 03:45, 5 September 2010 (UTC)[reply]

What is nonstandard about the title? it's more structured than our usual, but hardly non-standard. (The date involved is the Wikinews Shorts: date, not the publication date.) It's clearly a sub-page of the Wikinews Short, or at least it was before you moved the article and made it a "full" article (even though it's a stub, which should not be published in that format as a full article.) Generally when stepping into (and breaking) a process it is considered good manners to - at the least - clean up afterwards: see User talk:Gryllida#Abducted British girl and mother may be in Toronto as an example.)
As for the logically separate issue of sources... Blood Red Sandman and I agree we'd prefer to have the sources on a shorts subpage, using a collapsible template (and a sources header of Full title: Sources, to avoid the infamous MW header anchors bug.) This resolves the concern regarding flagging. I have messages out to a couple of people about importing the mostly-standardised collapsible templates; there's nothing preventing us from continuing the experiment without this functionality at this point, with the expectation it will be implemented within a few days. - Amgine | t 04:39, 5 September 2010 (UTC)[reply]
(I'd been composing a comment for your talk page, but then realized it belonged here, and would have to be retargeted.) Some of my latest thoughts:
  • The concept here, as I understand it, is to have these, er, mini-articles (I'm now afraid to use the word "short" or "brief" lest we have different preconceptions of them) that each consist of a short block of unadorned prose, without any extras. Suitable for certain kinds of modern media that call for, well, a short block of unadorned prose without any extras. I actually love that idea, and have no problem with its corollary that the list of sources would be somehow separate.
  • These mini-articles would not appear, in their unadorned form, as Main headlines. Instead, we could have aggregate frames that contain all the mini-articles for a given day. I feel quite strongly (it turns out) that Main headlines should have the professional look of our standard article format — in other words, adorned by the very extras that we don't want in the mini-articles themselves. Aggregate frames could, ideally, fix that, although making them do so without extensive finicky manual intervention is a nontrivial challenge.
  • I don't understand your distinction between the Shorts date and the publication date. It seems to me that the only dates involved are the date that the (mini-)article was started, which I wouldn't think would be of interest, and the date that it was published. Ideally (to my mind), the act of publishing a mini-article would add it to the aggregate for the current date at the time of publication. In fact, the excuse for leaving off the dateline —and the dateline is one of the extras we want to do without in the mini-article— is that that information is in the page name. If the page name isn't the publication date, then we've lost our justification for omitting the dateline.
  • Supposing the date were publication date, I think this would be the only mini-article for the 4th. It would certainly be possible, on a one-off basis, to construct an aggregate framework that would transclude the text, but not the sources link, of the one mini-article, and the sources list of the mini-article as part of the trappings of a Main headline. The one mini-article would be sighted but not published (a nocat parameter could be added to {{publish}} for this), and the aggregate frame would be published. I'm reasonably sure I could figure out how to do that, anyway, although I'm unclear on whether I could do it at this point without violating the three-revert rule.
  • We are in agreement, I think, that the stub should not be published as a full article; my immediate concern was to deal, as best one could, with the lamentable fact that it already had been published as a full article, by which I mean, a Main headline. As I've said, though, making it a technically unpublished mini-article within a published aggregate frame would be another way of resolving that.
--Pi zero (talk) 06:31, 5 September 2010 (UTC)[reply]
Postscript: Although it does not in any way alter my belief that the mini-article in question should be a short for the 4th, not the 2nd, a rather messy combination of factors has led me to revert my renaming of the page; I've documented my reasons here. --Pi zero (talk) 10:31, 5 September 2010 (UTC)[reply]

Arbitrary section break: Outline of theory

My test system to create Shorts articles is based, primarily, on three things (isn't every good argument a triptych in words?):

  • It must be simple to use (in its final format) for contributors who are not en.Wikinews regulars.
  • It must have an accelerated review process - either by streamlining the requirements or by simplifying the review requirements - to get them published quickly (less than 1 hour averages.)
  • It must appear on the main page upon review via DPL, as per CSpurrier's original proposal.

The perfect system consists of three steps, to maintain the rhythm here:

  • An easy-to-use new short template. Just type in a proposed title, and the short should open up for editing with most of the details already done and let the contributor just write the news short. This is a step toward that ideal, but there are several important elements lacking:
    • Category addition, with a pop-up clickable news categories map
    • A pop-up js dialogue box for creating the news Short would probably be even better than the normal Mediawiki editor page.
    • A similar tool to add sources to a collapsible sources section (with an arbitrary header name, to allow for multiple source sections within an article without confusing either the TOC or the #target in links.)
  • Integration with the Easy Peer Review, allowing a similar (but streamlined/simplified) review process.
  • Publication where contributors can see their work.
    • A DPL section on the main page; preferably one which can collapse itself if empty, and which is able to select shorts from the past X hours rather than the past X days.
    • A permanent link within a Wikinews Shorts: article, one which is much more graceful and attractive than the current model.

- Amgine | t 00:52, 6 September 2010 (UTC)[reply]

We need to really work at not letting our standards drop; they easily could, if we put too much emphasis on rapid turnover. The five criteria for WN:Reviewing articles#Checklist are all still applicable, but turnover will of course be faster because
  • a vastly shorter style guide can (and should) be written for lightweight articles, omitting all the geegaws that don't occur in lightweight articles, and
  • what's left won't take as long because there's less article content to review.
Looking over WN:Tips on reviewing articles#Checklist, I'd say a lightweight variant checklist would probably be about half as long. --Pi zero (talk) 02:49, 6 September 2010 (UTC)[reply]
While we need to keep an eye on standards, if the choice is between content creation/community growth and well-regulated content quality I would suggest content creation/community growth is more important at the moment. This is a moving target and balancing act - trying to get the best ratio of regulatory oversight to happy and productive community - and I believe it is currently too focused on the former. This too will change, and being too correct is never "bad".
(As a side explanatory note: there was review process when I first became involved in Wikinews, and I was instrumental as a part of the community in eliminating it. Doesn't mean I don't think there should be review processes, only that they are very prone to Instruction creep and tend to strangle productivity unless they are kept in the subsidiary role to which they rightly belong. Our purpose isn't to edit news, it is to write it.) - Amgine | t 19:45, 6 September 2010 (UTC)[reply]
"If the choice is between ..." There is no such choice. There is no choice between quality control and anything else. Quality control is a sine qua non; without it we'd be an inferior sort of community blog, with no good reason for existing. We want to improve by getting things out the door faster. We want to improve by growing. Quality control is an inherent feature of the landscape where we want to do those things. Put it this way: without quality control, the project would not grow, it would wither and die. When you first joined the project, we weren't carried by Google news. Eventually we mean to be accepted by Wikipedia as a reliable source. Quality control is the future of Wikinews, if it is to have a future. Since lightweight articles are meant to propagate fast and widely, it's crucial to control for quality (as with full articles, of course).
Right now, by the way, we're at a point of crisis where we need to improve our quality control; as I've observed elsewhere recently, the existing peer review infrastructure is pushing the upper limits of its optimal volume range, and faltering under its load, causing increasing frequency of publication mistakes and increasing stress in the community. --Pi zero (talk) 23:23, 6 September 2010 (UTC)[reply]
I think we have a fundamental disagreement which may not be resolvable. It's my opinion the sine qua non of Wikinews is the community, without which there will be neither content nor reviews. Your contention is that it is our quality control. My response to the current "crisis" is to increase the size of the community, while yours is to defend the standard of quality. Neither is necessarily better than the other, but I think mine can lead to yours, while I do not see how yours can lead to mine.
I'm sure you have the best interests of en.Wikinews at heart. I hope you can see my own is also to improve the project, and that we should collaborate or at least not sabotage each other. - Amgine | t 02:29, 7 September 2010 (UTC)[reply]
It seems, from your characterization (caricature?) of my position, that we have not yet achieved mutual understanding.
  • I have not said, and do not believe, that quality control is "the sine qua non" of Wikinews. I would find that proposition absurd. My drastically different statement was that quality control is a sine qua non of Wikinews.
  • It seems to me that you are defining into existence an entirely fictional opposition between community and quality control. To me, that's just as absurd as (and very closely related to) the idea that it is even possible to put quality control "ahead" of community. We are a community in common cause, and an intrinsic part of that cause is quality control. It is certainly possible to create a community of people who aren't interested in the quality of their output, but that's got nothing to do with Wikinews.
Do you seriously think it possible that I would consider community unimportant to a wiki? Sigh. Okay, for the record: it is meaningless to talk about Wikinews independent of its community (because it's a wiki), just as it is meaningless to talk about Wikinews independent of its quality control (because it's a news site). I choose to believe in the possibility of something that is both a wiki and a news site, and my conduct here flows from that belief; in particular, that belief rejects the idea that community and quality control must be traded off against each other. --Pi zero (talk) 06:41, 7 September 2010 (UTC)[reply]

Arbitrary section break: Abbas article event

There have been issues surrounding the publication of the Abbas short. Wikinews has not been harmed by this. Template:Main headlines should not be displaying any article which has Category:No publish added to it. It was still displaying the article a few moments ago, then I re-added the cat and it disappeared. (We could add 

notcategory=brief

or 

notcategory=Wikinews Shorts

to the Main headlines dpl to insure this doesn't happen in the future.) - Amgine | t 01:00, 6 September 2010 (UTC)[reply]

The description of Category:Wikinews Shorts says that those articles are compilations; so they should appear in Main headlines.
Category:Brief doesn't have a description, but it looks like it might be intended particularly for the Audio Wikinews Briefs. So maybe we shouldn't use that category for this purpose, either.
Perhaps something like Category:Lightweight articles?
A special variant publish tag —{{publish lightweight}}, or whatever— could add the category (whatever it is) automatically. Keeping the whole publication machinery separate, such as using a separate publication template, seems like a good idea. --Pi zero (talk) 02:27, 6 September 2010 (UTC)[reply]
I don't have strong opinions one way or another. The concept of the news briefs was, actually, to be a multi-use short news article, suitable for audio recording but certainly not limited to it, and possibly to serve as a variety of teaser text. Some were written as subpages of the full-length articles: Title/Newsbrief title. Then as now it was experimental. The lovely thing about a wiki is, if something works and develops a tradition, it is policy; if it doesn't work or causes problems, it can be fixed easily. Wikinews is not paper. It is quite malleable, and able to take twisting and change. - Amgine | t 19:52, 6 September 2010 (UTC)[reply]

Two cents, adjusted for hyperinflation

Proposal: Forget briefs and shorts. Add a new namespace, say, Summary, or Alert.

  • An abridged style guide.
  • A lightweight article wizard.
  • A new section on the main page (steal a lead slot?).
  • A less arduous review gadget/tool.

Beyond the above, this has to be fast. The auto-collapsed templates for sources have some of that code on-wiki already; don't recall where.

As a matter of urgency, I'd like to see reviewing move into MediaWiki. My gut says the above meets our needs and covers enWP's basic needs for, say, a BLP with FR enabled - as long as the criteria can be flexibly set.

News style still remains critical; active voice, 5W+H, own wording, independent sources.

Wizard? Well, Where's a source from? Is it recent? Corroborating with a press release?

When published, footer template links to create full article, to further develop one, to review one (if you've the bit and it's been subbed), or to read one. Then, ditch 'request'/'suggest' an article.

"Contribute to Wikinews right now. Know a breaking or very recent story we've not covered? Check our Style synopsis, fill in a short, but descriptive, title and a couple of independent, freely accessible, sources where requested, and write a three-five sentence summary of the news item."

Does this break the above, somewhat verbose impasse? --Brian McNeil / talk 21:04, 7 September 2010 (UTC)[reply]

I don't know about breaking the impasse, but the simplicity of your suggestion is very appealing. I love it. --InfantGorilla (talk) 14:20, 8 September 2010 (UTC)[reply]

Couple of points:

  1. Keep Shaka's main page design, snarf lead 2 (I think row under L1, left side).
  2. DPL of alerts to fit the lead (maybe slightly smaller font, suppress namespace display in list).

Technically, can then push out alerts via Gnews which immediately push people to a bite-sized news item asking them to contribute a full article. The Alert becomes the lede,... I think IG sees where I'm going.

Caveats:

  1. I'd put my foot down and say FlaggedRevs must have more sophisticated reviewing than just a checkbox. ( More in followup.)
  2. The form must be just as you'd expect:
    1. Line for headline input - with sane, short, character limit
    2. Textbox for Alert - accepting, but not requiring, wikimarkup.
    3. Two, possibly three, lines for sources.
    4. Javascript validation of submission. (Headline compliance, at least three sentences, at least two different source URLs, repeat preview until OK to sub & add Alert review template).

Someone prod our JS hackers; and, keep this lightweight guys. I'll quickly outline a general idea on moving review server-side below. If a few of the proponents of FR on enWP or deWP can be persuaded to look and discuss, brilliant. --Brian McNeil / talk 20:18, 8 September 2010 (UTC)[reply]

FlaggedRevs enhancement for review

  1. Currently, EzPeer is a monstrous nightmare and irregularly fails.
  2. We have a need to 'partial pass'/'partial fail'.
  3. To support different review type, and different project/wiki requirements, the criteria checklist must be quite flexible.

Reviewing should become 'magic-worded' utility for in templates. The parameters, and review result, should be set via pages in the Mediawiki space.

So, in a mediawiki page you've something like:

Alert Review
Criteria=4
Pass=all, required,carry,reconfirm
1=Current item?
2=Project compliant?
3=Neutral Point of View?
4=Sourcing adequate?
tooltip_1="Is this in the last 24hrs?"
tooltips 2-4
Pass=Sighted
Newtemplate=Published_Alert

So you then have some sort of FLAGGEDREVS magic word available in templates. Set out prompted criteria, tooltips to display for them, how many for a pass, options to carry forward results, and specify the template to replace that containing the magicword and pulling these criteria out.

Standart HTML for either/or checkboxes are displayed under header columns, or in drop-downs.

In doing a review, a signed code of results can be embedded in the template (so a review becomes an edit, and a code is embedded as a parameter to the template containing the magic word. If the signature is using a key hidden in the MW install, you can prove the review is valid if using the public key, or decode the result to display it without the hassle of the edit to talk, plus edit to use tasks.

Does anyone follow? Shaka? Required points of clarification? (Briefly, not writing full specs from a mobile device). --Brian McNeil / talk 21:01, 8 September 2010 (UTC)[reply]

New concise mobile page

Hello. I have created a main page that's similar to the regular one but is shorter and easier to use for people trying to get to Wikinews on their mobile devices. Currently, it's subordinated to my account. If you would like to take a look at it, please do. It also has a long, comfortable search bar and is simpler, quicker and easier for phones. Thanks, --Shankarnikhil88 (talk) 22:11, 10 September 2010 (UTC)[reply]

  • Firstly, the main skin of the wiki is Vector. I attempted to access the wiki from Opera Mini, and it loooks awful. My other cellphone browser also hates the navboxes, especially the show/hide part. We don't need a main page for mobiles, we need software for them. --Diego Grez return fire 22:39, 10 September 2010 (UTC)[reply]
In regards to diego's point, does https://secure.wikimedia.org/wikinews/en/wiki/User:Shankarnikhil88/Wikinews_mobile?useskin=chick look any better? (I've just always wondered, don't have a cell phone so can't test myself). Bawolff ☺☻ 23:18, 10 September 2010 (UTC)[reply]
  •  
  •  
  •  
    Too much white space with both Vector and Chick.
  •  
    Search bar is terribly large.
OK. I agree with you. It does look awful on my phone. However, could someone please find a good alternative to the main page, which is also hard to navigate on a mobile device. Could someone make something that acts like www.m.wikipedia.org - something like m.wikinews.org? That would probably boost our popularity on mobile devices. An app would also be nice, just like Wikopedia has Wapedia and the like. --Shankarnikhil88 (talk) 03:13, 11 September 2010 (UTC)[reply]
Some of us were working on Wikinews:Tech btw. Diego Grez return fire 03:19, 11 September 2010 (UTC)[reply]

De-sensationalizing and real journalism

I've been considering proposing this as an alternate en.wikinews.org (en-c.wikinews.org for en-corollary? Dunno) but I figure why not try for main?

It's commonly held (by a large and loud minority) that the media is overly sensational and insanely biased. I happen to share this opinion, to some degree; I haven't measured myself up against the noisy minority. It's also notable that Wikinews both produces originally researched news (occasionally) and largely aggregates other news sources; at least in the second case, Wikinews maintains the bias and sensationalism of the source material.

I don't think "reporting" should involve "blindly repeating the same trite as everyone else."

Journalism shouldn't revolve around repeating garbage. Some thought and research, expansion, explanation would appropriately add value to the facts presented by Wikinews: I think centering and de-sensationalizing would accomplish this goal better than, for example, trying to reverse-spin (turn "liberal bias" into "conservative bias" or just try to cover up any non-centered language about a minor group that may very well actually be a handful of sociopaths).

For a starting example, I'll call all the way back to what first raised my attention to this issue: The December 25 "Underwear Bomber." This individual had PETN sewn into his underwear, and ignited it on a plane in the passenger cabin. The media went on for a month or so about how he got "high explosives" through airport security; an anchor on CNN complained that he talked to "men in suits" and should have been questioned; and I've heard issue raised multiple times about his one-way ticket to Chicago without a coat.

The facts: PETN needs a special detonator that compresses the plastic explosive significantly. Without such a detonator, PETN plastic explosive only burns. The detonator would not have passed through airport security.

The facts: Detonating a high explosive with a proper detonator would be more successful without interference. A highly visible attack is not necessary: detonation in the bathroom at the right point would bring the plane down, and everyone would notice that.

The facts: Travelers may talk to all kinds of people dressed in all kinds of ways. There is no reason a person might not talk to someone well-dressed.

The facts: A one-way ticket to Chicago with no coat would show up if you rummaged through all on-board luggage. It wouldn't show up otherwise. If the person is moving, he might ship his luggage by alternate courier-- it may even have shipped already. Maybe he's buying a coat when he's actually in Chicago, instead of taking one on the plane. Alarming on every little thing that looked good in hindsight at one point would generate a LOT of false positives.

Interpretation: This plan was never going to do more than gain lots and lots of attention. The ignition of PETN high explosives was never going to cause an actual explosion without high compression of the PETN plastic explosive. The terrorist involved was likely aware of this, and chose to ignite the explosives in the passenger cabin to attract attention and incite media-driven terror.

In the reporting of this story, including the first fact and indicating that this attack was never going to bring the plane down would be appropriate and would de-sensationalize the article. The second, third, and fourth are progressively more logical thought-experiments and less scientific, and thus progressively pushing the definition of "NPOV."

The last sentence of the interpretation is pure speculation; however, the first two sentences are logical and factual conclusions from the technical facts about PETN explosives.

These are the kinds of things reporters should do: research a story, aggregate facts, interpret them, then peel out the useful facts from this aggregation and interpretation and enter them into the story being published.

Thoughts?

--Bluefoxicy (talk) 13:20, 15 September 2010 (UTC)[reply]

What Wikinews article(s) are you addressing, specifically? --Pi zero (talk) 15:15, 15 September 2010 (UTC)[reply]

Articles created by accredited reporters should...

...have their username, or some kind of credential somewhere in the article. It's what most news agencies do. A good place for this would be right at the top of an infobox or the main picture. What do you think, 'newsies? --Diego Grez return fire 23:25, 19 September 2010 (UTC)[reply]

Most news agencies publish articles that have exclusive authorship, which is asserted by means of a byline. We do not have bylines because our articles do not have exclusive authorship: we're a wiki, and anyone reading an article is welcome to edit it.
In interviews, the name of the interviewer is routinely given in the article. When a more general question came up a while back it was my opinion that, based on that precedent, it's also okay for the text of an article to name a Wikinewsie who's the source of particular information; however, as I recall, there were only three of us in on that decision.
It's my general instinct that we should avoid anything that could come across even slightly like ownership. Even in the sources section, the {{Original reporting}} tag only says "Wikinews members"; it doesn't have an optional parameter to identify the original reporter(s), and that's probably right that it doesn't. --Pi zero (talk) 01:45, 20 September 2010 (UTC)[reply]

New gadget: the subtitles in the videos

Bugzilla are inviting us to put this gadget allowing to see the subtitles with the videos (already installed at least on en.w, fr.w, fr.b, fr.v & Commons) directly in Mediawiki:Common.js. Actually, they need some feedback. JackPotte (talk) 13:04, 25 August 2010 (UTC)[reply]

We don't actually use video's really anywhere (and definitly don't have any with timedtext), so I think we should just wait until it gets merged into mediawiki/oggHandler/whatever the final plans for mw-embed are. (but i don't have strong opinions). Bawolff ☺☻ 12:49, 8 September 2010 (UTC)[reply]
The player also supports audio streams which wikinews appears to make use of --Mdale (talk) 07:05, 25 September 2010 (UTC)[reply]

How To Create a Live Kindle Feed

Hey guys, I thought you guys might enjoy this! Using the instructions from this forum you can create a free RSS feed of Wikinews:http://www.mobileread.com/forums/showthread.php?t=24949 Basically you create a kindle (.mobi file) using the http://www.feedbooks.com/feed web and the http://feeds.feedburner.com/WikinewsLatestNews RSS feed. You can then upload the file to the kindle. There are only a few articles at a time (I would like to see this changed in the feed). You only get part of the artcile, but you can select more and be redirected to Wikisource for the full article. What do you guys think of this? Can we expand the RSS feed to include a lot more articles like 50 maybe? --Mattwj2002 (talk) 01:27, 25 September 2010 (UTC)[reply]

HTML5 video sequencer Gadget

Also I would be interested in supporting some exploring how a video sequencer would work in the wikinews context, and what sort of features we could add to make it work in the wikinews work flow. The sequencer makes it easy to pair images with synchronized audio, with inter spliced video clips, so maybe the Audio Wikinews efforts could be appropriated.

On the technical front I would need to know if wikinews community would want to host their own sequences or have all their sequences hosted on commons. The commons project is of course not compatible with fair use images and video clips, and I imagine a wikinews video reports could ( in addition to free original contributed content ) include fair use audio/video --Mdale (talk) 07:05, 25 September 2010 (UTC)[reply]

Hmm, this might be interesting. We probably would want fair use images (logo's in paticular). Do we have anyone still working on audio wn, or is that project dead again? Bawolff ☺☻ 16:39, 25 September 2010 (UTC)[reply]
I will work on making the sequencer work better with per-project assets and send an update once that is ready Mdale (talk) 19:12, 28 September 2010 (UTC)[reply]
Retrieved from "https://en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2010/September&oldid=4583083"