User:Brian McNeil/improved Wikinews workflow
- « Prev (Weaknesses in Wikinews' workflow)
Thoughts on components/required tools
edit[...]
[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.
[...]
- "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.
- "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.
- "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.
- "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)