User:Brian McNeil/improved Wikinews workflow

« Prev (Weaknesses in Wikinews' workflow)

Thoughts on components/required tools

[...]

[03:28] <pizero> I've been figuring, in the past few weeks, there are four bits of software we want (not counting redo of ezpr). Userspace-ifier. Review-notifier. Red sharpie. Custom-wizard-ing tools.

[...]

1. "Userspace-ifier": A function to take an article which is never going to be published, and move it into the appropriate user's space (eg: User:Foo/The article title)

    

   This must (amongst other things) ensure the article is not included in most categories (templates which include categories generally have a |nocat=1 parameter available).

   The main driving factor behind this is increasing use of Wikinews as a publishing target for university journalism classes.

    

2. "Review-notifier": The ability to notify appropriate contributors of an articles failing (or indeed passing) review

    

   At simplest, this could scan the history, list all contributors not reverted, not a reviewer of the article, and responsible for minimum of +x characters added/changed.

   The reviewer may then mark checkboxes and personalise a message for their talk. If the talk contains a section for the article, the comment is added to it.

    

3. "Red sharpie": A visual tool whereby a reviewer can colour-mark sections of an article as reviewed/unreviewed for each of the review criterion handled in EzPR. (Your lecturer/professor/reviewer/copyeditor making life hell by handing back a paper covered in red sharpie marks!)

    

   This could show all text as inverse-video for unreviewed; colour changes of text/background then can be used to indicate the review points cleared on sections until the article is all black-on white, and review is complete.

   Ideally, where an article fails on any point, the reviewer could save annotations in that section for a contributing editor to resolve the concerns.

    

4. "Custom-wizard-ing tools": A considerably more-sophisticated form handler than Extension:InputBox which can chain forms through a workflow.

    

   An example use of this would be re-making the Make Lead (ML) widget in a more-generic form, review leads at top-level (main page), possibly update those, then carry the just-reviewed article through to relevant topic and/or geographic portals where the leads could also be updated.

   Additionally,this would offer a basis for managing what is now, largely, handled by EzPR.

---

Additional notes:

• The javascript-driven buttons in the develop and tasks templates need to be "more intelligent". Examples:

It should not be possible to submit an article for review if it fails to meet the required minimum of three paragraphs

It should be impossible to resubmit for review from the tasks template if no changes have been made since the failing review

If the user's browsing history is available, it should be difficult to re-submit for review if they have not read failing review comments (the talk page)