User:Brian McNeil/improved Wikinews workflow


 * « Prev (Weaknesses in Wikinews' workflow)

Thoughts on components/required 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.
 * 1) "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.
 * 1) "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.
 * "Customer-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.
 * 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.
 * "Customer-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.
 * 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)