User:Brian McNeil/current Wikinews workflow

Next » (Weaknesses in Wikinews' workflow)

Introduction

Wikinews is the news-based sister to Wikipedia. In dealing with news, articles must be completed and published in a very short timeframe. The easiest articles for most contributors are synthesis articles, where Wikinews articles aim to provide more complete, rounded and NPOV-compliant coverage based on multiple (usually mainstream) sources.

Following the development of Extension:FlaggedRevs, and its deployment on the German Wikipedia, Wikinews requested the extension be installed and configured to allow enforcement of a peer-review process prior to publication of articles. This is covered in the reviewing policy. The gadget mentioned therein, Easy Peer Review (EzPR), aids a reviewer in completing a passing or failing review (in the latter case, an article is marked as "not ready" with a to-do list from the five criteria applied (Copyright, Newsworthiness, Verifiability, NPOV and Style).

What Wikinews has in the way of tools for reviewing is overwhelmingly javascript based, somewhat error-prone and overly-sensitive to any malformed templates. It does not include any easy way to mark an article as being reviewed (or, to potentially 'lock' whilst under review); and, it fails to alert a reviewer should someone make a change to the article whilst they are reviewing. One upshot of this is that two reviewers could be working through the same article, unaware they are duplicating (and wasting) effort. There have been instances on Wikinews where a less-thorough review has completed and been given a pass, followed shortly thereafter by a more critical review which marks a now-published article as failing.

Current workflow

Illustrated narrative

The initial creation of an article sees it tagged with the template {{develop}}, which, through use of a Javascript-handled button, may be moved to {{review}}. At this point, those who have the FlaggedRevisions reviewer permissions may access the EzPR gadget from the page options drop-down menu (just before the search box). A screenshot of EzPR in use is below:

The three choices per review checklist item are shown here: Not reviewed (i.e. the article not checked for this), Fail (with option to explain why), or pass.

In addition to the drop-down options against each of the review criteria, there is a free-form text area into which a reviewer may place additional remarks. These need not be restricted to critique in failing an article, reviewers are encouraged to give positive feedback when a quality article passes review and is published.

The checkbox, "I have read all the important information on the talk page" is only displayed where the article's associated talk page is non-blank. Generally, this is due to the article failing a prior review; although, there may be comments from collaboration, or original reporting notes. [Aside: Where there is original reporting (OR) within the article, it is particularly important that the reviewer satisfies themselves that the notes cover what is OR within the article; hence the option to pull up the talk page in a separate window/tab.]

Review submission/completion

When the review is submitted, a copy of the template {{peer reviewed}} is filled out on the article's talk page (see template page for extensive additional information). This template is not conducive to manual completion, and the other work carried out by EzPR is highly error-prone if performed manually.

Below these screen captures of passing/failing reviews, are the additional workflow steps carried out (most of the time) by EzPR:

A failing review	A passing review
Review of revision 1423588 [Not ready] Click image for larger version, or here to see on-wiki.	Review of revision 1425800 [Passed] Click image for larger version, or here to see on-wiki.
The above template is placed on the talk page, with the revision ID placed in the newly-created section name The {{develop}} template on the article is replaced with {{tasks}} For each failing point in the review, an additional parameter is included in the tasks template. The parameters of the tasks template are converted, within that template, to links to the appropriate policy points upon which the reviewer has failed the article. For example, an article failing on style, as shown above, includes a link "Edit for style" when the markup {{tasks|mos|re-review}} is inserted; the re-review parameter causes a javascript-driven button to be included to enable easy resubmission (see here). Had the above article also failed in terms of being inadequately sourced (verifiability) then the markup {{tasks|src|mos|re-review}} would be inserted, and an additional link "Add sources" included.	The above template is placed on the talk page, with the revision ID placed in the newly-created section name The {{develop}} template is removed from the article page The {{publish}} template is placed at the foot of the article page, just before the categories The revision which has the publish template added is "sighted"; i.e. marked as reviewed within FlaggedRevisions Further processing is handled in two ways: Extension:DynamicPageList (Wikimedia) will, based on categories, automatically list the now-published article on the main page, and in a variety of other places (eg, on the United States portal if that is a matching category A reviewer (not necessarily the one who has completed the article's review) may use the WN:ML (Make lead) gadget to place the article in one of the main page's lead positions.

Issues, 'missing' functionality

Quick notes for basis of following section

• Requirement to manually add an "under review" template, which can easily be missed
• No marker in-database to alert to an in-progress review
• Fragility of EzPR
• Does not notify main contributors of fail (or pass)
• No locking, or alerting to a review underway
• Unable to in any way mark text being reviewed, or carry out limited copyedit work whilst in EzPR
• Limitation of Make Lead to the main page where associated portals may have lead templates; this tends to result in stale portals
• Cannot, as part of review, reject completely and move to userspace (Example: a number of university journalism classes have used Wikinews; their submissions should not end up deleted if they fail to pass review in a timely manner, but be moved to the relevant student's userspace).

Next » (Weaknesses in Wikinews' workflow)