Wikinews talk:Archive conventions

• /Archive 1

suggesting something that is probably really unpopular (no protection)

Perhaps stopping the protection of archived materials may be of ultimate benefit to the project. There are definitely changes on protected pages that could happen (mostly "trivial" items) and most users are not going to be admins. --Remi (talk) 06:01, 25 May 2008 (UTC)

Disagree with this idea, that is what {{editprotected}} is for. Cirt (talk) 06:54, 25 May 2008 (UTC)

Definitely a bad idea. Too many people don't get the difference between here and Wikipedia. --Brian McNeil / ^talk 07:02, 25 May 2008 (UTC)

Solar Eclips

This file image of the Pleiades star cluster does not show the recent Westerlund 1 discovery, but is used to illustrate what a star cluster looks like.
Image: NASA.

Names of publications and articles

Please italicise names of publications and articles mentioned, including web site names. Don't put web addresses into articles.

When the publication is something like The Boston Globe, note that 'The' is capitalised.

When using a common, shortened form, such as calling The Boston Globe simply the Globe.

Always use the full name of the publication on the first mention, not a contracted name. Unlike with acronyms, there is no need to explicitly define the contracted form in brackets after the first mention of the full name.

Wiki links within an article Do not over-wikify articles. Link only particularly relevant background material. If your article is about a high-speed chase and accident, the make and colour of the vehicle is probably not particularly relevant, but the city or region might be.

If I wave chicken entrails over this, will it make sense? --Brian McNeil / ^talk 06:45, 23 July 2009 (UTC)

This seems to have been copied from Wikinews:Style guide#Names of publications and articles. Not sure what the user was trying to do. Tempodivalse [talk] 20:37, 4 September 2009 (UTC)

Seven days

It seems some articles are being protected several days early. I'm not necessarily against this, and I actually think it would be a good idea to protect articles after five days, but we need to be careful not to jump the gun in terms of archiving things. –Juliancolton | ^Talk 16:51, 30 September 2009 (UTC)

Bump, as I see this issue is still happening. –Juliancolton | ^Talk 01:27, 12 January 2010 (UTC)

(i know this is a post from a long time ago, but figured I'd post anyway) Meh, I don't see that it makes much difference if we occasionally are a day or two ahead in archiving - it's just less work to do later, plus we don't have a lot of admins who consistently archive pages (just me at the moment, occasionally Cirt). As long as we don't get more than 1-2 days ahead, i think it should be okay. Tempodivalse [talk] 14:32, 31 March 2010 (UTC)

Challenge this policy

It's completely anti-wiki to prevent edits to an article prior to the archive date. While I'm not necessarily opposed to archiving after 24 hours, it's illogical to say an article should not be edited after 24 hours, but not archived until 168 hours. - Amgine | ^t 02:37, 23 July 2010 (UTC)

I agree. While major new developments and the like should have there own article, being a Wiki gives us the ability to continue to work on an article even after it has been published. We should be taking advantage of this. If we are not going to, the page should be protected at the cut off point. Technically allowing edits and then reverting them wastes new contributors time and will chase them off. --Cspurrier (talk) 02:43, 23 July 2010 (UTC)

I am pretty sure it chases newcomers off. However, when a story is breaking, or when new facts about an incident are disclosed (new photos or statements), or when another Wikinewsie does better research: then we need to draw it to the attention of our readers appropriately, and the current solution to this is to post as a new story if it is more than 24 hours later. Appropriate presentation is important whether a story takes more or less than 24 hours to develop after first publication. I don't think we have it right yet: there must be some combination of re-posting stories, forward links, and protection that presents things in a way that clearly delivers Wikinews's latest/best assessment of the facts, while still being clear and honest about how a story developed, and welcoming to new contributors.

Every good story develops after publication, so I think it is time to take a relaxed but serious look at whether there is a better way to deal with that.

--InfantGorilla (talk) 06:56, 23 July 2010 (UTC)

I think the archive policy 24 hour cut off is a bit strict, but the general idea of having a cut-off date where a sentence could get re-worded, but the article shouldn't significantly change is a good idea. Note we also spam people trying to edit old articles with {{Editintro notcurrent}}. Bawolff ☺☻ 07:06, 23 July 2010 (UTC)

Perhaps we should provide a start-a-new-article box on that template. Is it possible to set it up to prefetch a pattern with a related-article section linking back to the article currently being edited? --Pi zero (talk) 11:59, 23 July 2010 (UTC)

Having the start-a-new-article box is a great idea. Pre-adding the links would make it really cool, but I'm not sure it's possible. Even if you could add the old title automatically, those links also need the publication date, which would be trickier. Maybe some fancy Javascript could do it? Bawolff? the wub "?!" 13:51, 23 July 2010 (UTC)

• Given how things are at the moment, I'd argue in favour of the timescales; that is why we have reviewers, and why BRS pushed through killing autosight. Sorry to be terse, but I laboured over this policy when nobody took any care to archive. --Brian McNeil / ^talk 09:55, 24 July 2010 (UTC)

Propose changes?

Remember also, Brian, that I initiated this policy for pretty much the reasons why you feel strongly about it. That doesn't blind me to the fact its current implementation is not optimal.

Based on the discussion here I would suggest a two-fold set of changes:

1. Automate archiving

   Articles should be "closed" at 24-48 hours. Few c/e, style edits happen 48 hours after publishing, and most of those which do are by administrators.

2. Implement start-a-new-article fields in both the archived template and the notcurrent template.

   Date changes are already automated with this tool, and a specialized pre-populating template can be used to fill in related news, other fields.

Are there any other tweaks we should add to this? - Amgine | ^t 14:56, 24 July 2010 (UTC)

I support these changes. If we are not able to switch to a fully automated archiving system (or if we keep the 7 day archive mark), we could have a bot semi-protect the article at the first cut off point and thus make it so new users do not mistakenly edit the articles, but still allow some non-admins to c/e --Cspurrier (talk) 17:35, 24 July 2010 (UTC)

While (2) just makes sense to me, and I suspect to everyone else, I don't think I agree with (1). There's a world of difference between asking people to create a new article for substantive changes after 24 hours ("alter[ing] the balance of the article"), and not allowing them to submit any edits at all after 24 hours. If there's any reasonable chance that someone will look at the article and perceive it as recent news, it should be possible for them to make copyedits to it; copyedits are a likely way for newcomers to get their feet wet, and we want to encourage newcomers (some of whom, properly encouraged at the start, will become the future of the project). Seven days seems to me like a perfectly reasonable cut-off. The central question here, as I understand it, is whether there should be any real difference between the cut-off for substantive changes and the cut-off for non-admin edits to the article. I see a real advantage to having a difference between them, in encouraging newcomers, and I hope that the new-article field will mitigate the current disadvantage. --Pi zero (talk) 21:01, 24 July 2010 (UTC)

Unfortunately, there will be no visible new-article field until someone has been reverted, or if we take Craig's suggestion to semi-protect the article first (and add a template to that effect.) Perhaps that would be the best solution? Without the new-article field it seems particularly unhelpful/likely to scare of new contributors if we have an editable article which they get into trouble for editing.

The other option might be to lengthen the time an article might be edited - including new material/expansion - to 48 hours, and then have it automated archived. This longer content-editing period may chafe senior community members, but there is no actual *harm* so long as earlier portions of the article are not removed. - Amgine | ^t 21:37, 24 July 2010 (UTC)

Sorry, I'm not sure what you mean by "there will be no visible new-article field until someone has been reverted"? The idea as I read it was to put the new-article field into {{editintro notcurrent}}, which is shown on the editing page for any article published more than X hours ago (by voodoo magic). X is currently 48 hours, but that can be changed easily enough.

I agree completely with what Pi zero said. Being able to copyedit and the like is great for attracting new users, and oh boy, do we need more of them! Do we really have a serious problem with substantive edits to old articles? The current system seems to discourage them pretty well. Even if there were lots of them, thanks to flagged revisions they would be nothing more than a very minor time drain, as they never go live. the wub "?!" 23:19, 24 July 2010 (UTC)

You're right, I was wrong about whether it was visible at the edit window (for those using the web-based editor); I was more interested in avoiding them getting to any editor by having the new-article box on the article page (via the "article protected prior to archiving" template.) An argument against having it on the editing page is - how much of the editing page do you read before editing? I just looked conscientiously at the edit screen and was completely unaware of this bit: "Also, please refrain from offensive or inflammatory comments." (Incidentally, I love having the templates drop-down, but have long wished for Brian's opinion question template to be included.)

As for whether copyediting is a great draw for new contributors, I agree. How often do you see them copy editing an article greater than 48 hours old? Is it a huge percentage of the new contributors? I personally have my doubts but if it is, then why restrict them from editing the content? surely that would be an even greater draw to new contributors, seeing their contributions to a published article being reviewed and visible? - Amgine | ^t 01:40, 25 July 2010 (UTC)

This all hinges around the following - article lifecycle. --Brian McNeil / ^talk

Article lifecycle

1. Unpublished, and always unreviewed.
2. Review requested
3. Reviewed, and published
   1. Reviewed and published, open/breaking
   2. Reviewed and published. stable
4. Archived

I'm completely happy with the above, it's how things should work. Timescales is the issue (fill in as you prefer). This policy, as it stands, is based on the whole lot having been done at the last step. --Brian McNeil / ^talk 13:17, 25 July 2010 (UTC)

Quick first observation on that is, that I'd go to a "review failed->re-review requested" state; if an article is resubbed for review, the reviewer should be directed to the failed review - they may not need to check everything. --Brian McNeil / ^talk 13:19, 25 July 2010 (UTC)

Re timescale: The discussion has been mostly about when to fully protect, which is the second half of the transition to Archived state. The first half of the transition is adding the {{archive}} tag. Full protection should not happen until the article is not, and never again will be, listed on the main page. The {{archive}} tag forces the DPL to exclude the article. Archiving after 24 or even 48 hours would routinely foreshorten the DPL; what we want is a figure that's unlikely to do that even in a reasonable output slump. On that basis, seven days seems reasonable to me. --Pi zero (talk) 03:50, 28 July 2010 (UTC)

Pre-protection process - why then?

Whilst attention is on this page, I'll bring up something that's been bugging me about it for a while. Most of the things listed under Pre-protection process seem like they should have been done long before archiving, as part of the reviewing process. The only exceptions are undoing late edits (which ideally shouldn't get through so much now that everything needs to be sighted), and adding the {{archive}} template (obviously). I guess the rest must be left over from before we had such formalised reviewing prior to publish? Nevertheless it's quite a useful little checklist, so it should maybe be merged into Wikinews:Reviewing articles instead. Thoughts? the wub "?!" 22:51, 24 July 2010 (UTC)

I agree. It annoys me when I review an article and the person who wrote it hasn't formatted the sources properly, or they have the cats in the wrong place. But what annoys me a lot more is when an article gets published with that incorrect formatting still in place. I haven't brought this up before because I've been more concerned with people properly copychecking and factchecking articles. It seemed silly to nitpick about formatting if people weren't properly reviewing the article content. Gopher65_talk 23:28, 24 July 2010 (UTC)

• Those issues should be dealt with at review-time. --Brian McNeil / ^talk 13:13, 25 July 2010 (UTC)

I suggest replacing the entire Pre-protection process section with

== Archiving process ==

An administrator should archive an article by adding tag {{archive}} to the end of the article (preferably just after tag {{publish}} on a separate line), sighting it, fully protecting the article, and sighting it again.

I also suggest removing from subsection Age for protection the antiquated provision "in case of a conflict on this basis administrators may apply protection early"; that's surely a relic from before flaggedrevs, and on any other basis it's instruction creep. --Pi zero (talk) 02:49, 28 July 2010 (UTC)

Okay, I admit it, that was a naive suggestion. Some things really do have to be spelled out. --Pi zero (talk) 00:41, 31 July 2010 (UTC)

It doesn't seem antiquated to me. We don't often get edit wars, and even less between registered reviewers, but we should have a standard procedure to deal with them. Temporarily and speedily removing the review bits from two protagonists in an edit war would also be useful, but speedy protection is kind of a standard MediaWiki fallback. --InfantGorilla (talk) 10:29, 31 July 2010 (UTC)

I was thinking 'antiquated' because it seemed to me to be a holdover from when a published article could be edited freely by anyone. I'd think full-blown edit wars between non-reviewers relatively unlikely in the subdued setting of published articles, where the edits wait for a higher authority to judge them before being published; and reviewers should be more mature than to engage in a sighted edit war, given their awareness of the gravitas of publishing edits. We also have a clear tradition of preferring to pull dubious material until we're sure, which tends to damp out a class of potential edit wars between those with extra privileges.

I said "instruction creep" because, as you note, temporarily fully protecting a page is a basic tool in the toolkit of an admin. It seems likely (depending on actual circumstances, of course) that better choices from the toolkit would probably be temporary removal of the reviewer bit for a sighted edit war on an article, and temporary blocking for an unsighted one. For Wikinews, subduing the warriors seems better than retarding improvements to the article, and soft restraints on warriors (de-reviewer) should also be better for the article since it leaves interested contributors still able to provide constructive input. If we were going to have any instructions here at all, I'm inclined to think they should say something about preferring alternatives to early protection. --Pi zero (talk) 12:39, 31 July 2010 (UTC)

Well argued! I say delete the phrase then. One day it should re-emerge in an administrators' manual or an edit war guideline, if those don't already exist. --InfantGorilla (talk) 13:04, 31 July 2010 (UTC)

• Pi's detective work is pretty accurate. When I did the initial attempts to clear a multi-year backlog of unarchived articles I ended up with something like the following process:

1. Check history, compare with publication date.
2. Review each edit since publication, remove the "sneaky" vandalism done on old articles.
3. Standardise the section names, source templates
4. Add the archived template
5. Full prot.

Personally, I think the whole workflow / article lifecycle could do with being looked at. I would really like some tools to help manage that. Ideally, those would be server-side in the form of some sort of extension. I've paid next to no attention to Wikipedia's plans to introduce FlaggedRevs, but I'd argue we should be trying to design something flexible enough that it would be of-use to them too. --Brian McNeil / ^talk 09:45, 1 August 2010 (UTC)

A note about {{DEFAULTSORTKEY:}}

A note about {{DEFAULTSORTKEY:}} Says that articles are sorted by modification date. Semantic MediaWiki allows sorting by creation date. Here's an example:

http://www.coincompendium.com/w/index.php/Category:Types

This is a technical issue that can easily be fixed using SMW. I recommend WikiNews start using it. If WikiNews needs help with that, let me know. I'm competent in SMW administration (there are many people who are better at it than me), and expert in SMW template programming (there only a few people who are better at it than me).

Badon (talk) 21:25, 6 April 2012 (UTC)

They aren't sorted by modification date, they're sorted by when they were added to the category (if one selects that option on the DPL, which we most often do). That's usually a much closer approximation to what we want, than creation date would be. --Pi zero (talk) 22:17, 6 April 2012 (UTC)

Ah, I see. I misunderstood. Thanks for the clarification. Badon (talk) 08:09, 7 April 2012 (UTC)

Change the "Post-archival edits" section

Images are considered content and should not be changed or removed, even if deleted on Commons. Wait, even if deleted on Commons? I don't understand why these harmless edits should be prevented. Red links should be removed on articles. This is actually the reason why CommonsDelinker is blocked. Can it be changed to something that will not prevent post-archival edits that removes images that are deleted on Commons? Or if that is not possible due to consensus, can someone make an abuse filter that will just prevent CommonsDelinker removing images that are deleted on Commons, while permitting file moves? Blocking CommonsDelinker doesn't solve this problem, and will just make the situation worse. I am a filemover on Commons, and I am worried that this wiki will not have the latest filenames immediately when files on Commons are moved. Thanks, Pokéfan95 (talk) 12:44, 2 January 2016 (UTC)

Well, there was once a request for renaming a media file, few months ago. But the media was already in use on this project. Once renaming was successful, the one who did it came here and rectified the location. I guess the renamers makes the correction wherever the file is used.
14.139.242.195 (talk) 12:59, 2 January 2016 (UTC)

• Why would a news source want the "latest" files? The images displayed should be those current at the time the article is published. The history behind this goes back to, for example, the H5N1 spread and maps used on Wikinews articles. Imagine an article with the headline Foobar is third country where some disease is confirmed. If the map then shows a dozen countries, the article looks weird.

Secondly, the project has a local Fair-Use/Fair-Dealing policy, so can host images locally. This could often rescue images which might fall foul of Commons' particularly strict policies. --Brian McNeil / ^talk 13:38, 2 January 2016 (UTC)

• Some thoughts.

• If a file move really doesn't change anything significant, notify us and we can fix it.
• We can also neatify ugly redlinks using template {{missing image}}.
• On close consideration, the policy-change idea does really amount to compromising one's core values — here, "don't rewrite history" — simply because a bot was designed to aggressively enforce incompatible policies from a different project.
• Avoid gratuitously complicated solutions. It's asking for trouble to put in place a bot misdesigned to aggressively ignore local policy and then try to "fix" it by putting a second elaborate software mechanism in place to filter out the undesirable vast majority of the bot's edits.
• In the larger picture, I prefer to avoid bots as much as possible because they move control of activities further away from the wiki community and thereby undermine the essence of wiki-ness. As a practical matter, to avoid them as much as possible one needs technical alternatives, and I'm working on just that (see, for example, here).

--Pi zero (talk) 13:50, 2 January 2016 (UTC)

I am increasingly of the opinion Commons should be avoided entirely for images. Although we have some archival resilience to file deletions/filemoves, we have no method of being aware when an image is updated on Commons. I believe it would be a fair assessment that a large percentage (>5%) of our articles with images have been damaged in this fashion. This is primarily due to a misunderstanding by Commons of Wikinews's mission as a record of what happened when. - Amgine | t 19:22, 2 January 2016 (UTC)

Fair-use images could be uploaded locally and thus CommonsDelinker's "job" could be avoided. Do correct me if I'm wrong. --Winter^eu 19:45, 2 January 2016 (UTC)

IIRC free-use images do not require a justification to be hosted on Wikinews. Fair use can also be hosted locally due to a board-approve FU policy. - Amgine | t 19:51, 2 January 2016 (UTC)

does the policy allow for updating logos to better versions?

I noticed many articles are using old JPEG or PNG logos that have since been superseded by SVG versions on Commons. Would it be counter to the archival policy to update the articles to use higher-quality logos? --Ixfd64 (talk) 19:20, 15 March 2020 (UTC)

@Ixfd64: Do you have an example in mind? I feel I'd have to see an example to judge applicability to a particular case, but given it's just a logo, and just increasing resolution, it sounds likely okay to me. --Pi zero (talk) 20:24, 15 March 2020 (UTC)

@Pi zero: Here's one: the article "Exclusive look at Bebo" uses the local image File:Bebo logo.gif. However, there is a far better version at File:Logo Bebo.svg on Commons. --Ixfd64 (talk) 21:04, 15 March 2020 (UTC)

In that particular case, the gif is local and therefore stable, whereas I wouldn't necessarily trust Commons not to eventually replace it with a different "updated" logo, appropriate for use of such a logo on an encyclopedia, but not for its use in an archived news article. Since the gif is already here, I'd be inclined to leave its use in that article alone. --Pi zero (talk) 21:20, 15 March 2020 (UTC)

Fair enough. --Ixfd64 (talk) 00:47, 16 March 2020 (UTC)

Just checking, bit unsure

So, is the rule that anything older than seven days and not on the main page is archived? No issue with this, just wanting clarity so I know when to archive! --LivelyRatification (talk) 10:35, 15 November 2021 (UTC)

@LivelyRatification: Correct but with the caveat: only archive the articles listed below the horizontal line in the "To archive" section at the foot of the policy page overleaf. So if there’s ever a time when there are only ten unarchived recent articles, we hold off archiving until things change. [₂₄Cr][talk] 15:35, 15 November 2021 (UTC)