User:Gryllida/Tasks

These tools assist with authoring and review at Wikinews.

Recent changes:


 * February-April, 2019: Welcome a bit: completed Version 3, seems mostly working OK --Gryllida (talk)

Plan:


 * May 2019:
 * Spam easy delete and block software
 * Dupdet auto-restart (and debug) software


 * June 2019:
 * Video tutorial software


 * Very brief summary

Wikinews is a neutral, entertaining citizen journalism site where anyone can add a story. To ensure the quality and accuracy of the published output, peer review is implemented. The wiki software needs to be improved to make the peer review as well as article authoring easier. To be clear, article authors are guided by style and content guides. While comprehensive and designed very carefully, these are barely reflected on the authoring or reviewing software. Some commonly performed tasks are listed below. Implementing them in the Wikinews web site would allow to increase productivity of authors as well as reviewers.


 * EVERYTHING ELSE IS OK TO TAKE AND WORK ON

= Background =

To ensure accuracy of the published output, an article goes through "developing" to "review" to "not ready" or "publish". This whole process is documented here, for instance, in more detail. This process is inefficient: archival and notification of authors need to be performed manually, and a lot of time is spent processing the article to check for common errors such as plagiarism, broken or missing wikilinks, sources sorted in wrong order, articles are more than 3 days old, and so on. Thus reviewer tools could be improved so that these tasks take less time, and article authoring tools could be improved so that these mistakes happen less.

At present reviewers use the existing wiki facilities as well as the easy peer review script. Development of this gadget has been slow.


 * Not many contributors are available on the web site.
 * Not many contributors know JavaScript.
 * To test modified versions of the gadget, 'publishing' articles may be necessary, which may not be done on production site. However, mirroring Wikinews on localhost to test the gadget is virtually impossible (I myself took two months to import a dump of Wikinews pages data and ran out of space ona 50GB drive in August 2017).
 * Tasks are not adequately documented.

It is recommended to implement these tasks using JavaScript using one of the following methods.
 * dialog tools. This software is comprised of several files on-wiki, and its functionality is tested and demonstrated on this page. Further documentation is available here. The premise behind this approach is that users benefit from the ability to create custom wizards using wiki markup rather than programming in JavaScript. This tool is developed by Pi zero.
 * a custom gadget, this is the same technology as behind the dialog tools, but it does not provide users access to creating their own custom dialogs that may be modified without JavaScript knowledge.
 * a MediaWiki extension in PHP, but this is difficult to deploy.
 * a standalone JavaScript tool using the wiki API and oauth, but this again does not provide users access to creating their own custom dialogs that may be modified without JavaScript knowledge. Meanwhile this allows to work outside of the restrictions of a wiki; a custom web site may be created.

See also:
 * mw:User:Brian_McNeil/current_Wikinews_workflow
 * User:Pi zero/essays/vision/dialog
 * User talk:Pi zero/essays/vision/dialog
 * User talk:Gryllida/Tasks

= Tasks (in no particular order) =

In no particular order (add at the end)

Task 1: Check plagiarism
Rationale: article authors occasionally copy content from external sites, despite it being incompatible with the Creative Commons Attribution 2.5 License used at Wikinews. Other authors copy and then reword content, which is non-trivial to find. Relevant content guide section.

Who would use it: authors (to learn about and avoid plagiarism) and reviewers (to check for plagiarism).

Current developments and tools: list, particularly dupdet, User:Gryllida/js/plagiarismcheck.js (talk)

How it would work:
 * provide links to dupdet output for external links present in the current article
 * allow to browse current article contents and external source contents side by side with copyvio offending parts highlighted? (depends on the 'read sources' task)

Criteria of success: plagiarism check takes less time

Task 2: Insert Wiki Links
Rationale: Articles need to have links to France or. Those are easy to add in wrong ways, for example, France. Relevant style guide section.

Who would use it: authors (to add wikilinks) and reviewers (to correct or add wikilinks).

Current developments and tools: Wiki markup in plain text, plus documentation and examples in other articles. This is not semi-automated in any way.

How it would work:
 * provide a toolbar button
 * scan the text to suggest user which phrases to wikilink (like a word processor spell checker goes through offending words one by one and provides suggestions)
 * use W when the page does not exist on the local wiki
 * check for word forms
 * only wikilink the first occurrence
 * allow user to select a phrase and wikilink to a local or wikipedia page of their liking

Criteria of success:
 * relevance of the suggestions produced when scanning the text
 * only wikilinks the first occurrence
 * wikilinking a custom phrase takes little time and effort

Task 3: Check spelling
Rationale: Avoid spelling errors.

Who would use it: authors and reviewers

Current developments and tools:
 * spell checkers in browsers, not always installed by default
 * meta:Gadgets/Rechtschreibpruefung Rp_js_beispiel.png Spell checking for common errors while reading articles. Spelling mistakes are highlighted in red, and pointing the mouse over them shows possible corrections. Users a dictionary of common mistakes. - no
 * mw:Extension:Spellcheck
 * w:Wikipedia:Gadget/proposals/Archive_2
 * w:Wikipedia:Tools/Editing tools
 * w:User:Symplectic Map/AutoSpell corrects common misspellings - no

How it would work:
 * underline words which seem spelt wrong (not in a dictionary)
 * provide suggestions
 * allow to add words to a dictionary (one for everyone on this wiki)
 * don't think it needs a custom dictionary per user?

Criteria of success:
 * does not miss misspelt words
 * provided suggestions are relevant

Task 4: Highlight text in article
Rationale:
 * text highlighter to select the text that was already verified
 * maybe also highlight text in an external source (before or after the '17: read sources' task is solved)
 * means to highlight problematic passages and comment on them on the talk page

Who would use it: reviewers and collaborating authors to provide feedback

Current developments and tools:
 * in-browser addons allowing to highlight page parts or remember what was already highlighted
 * MediaWiki:Gadget-onScreenEdit.js
 * User:Gryllida/js/onScreenEditWithLocalStorage.js (derivative attempting to use local storage)
 * mw:User:Ontone/js/veTextHighlight.js

How it would work:
 * allow to highlight text with a few colors
 * does not lose data when navigating away from the page
 * maybe even updates the data if the article was changed after highlighting it the last time
 * maybe allow to add comments to each highlight
 * maybe allow to share the highlights and the comments

Criteria of success:
 * provides the required functionality above
 * fact-checking takes less time

Task 5: Archive old or abandoned stories
Rationale:
 * semi-automated assistance to reject stale articles and delete or userify abandoned articles
 * archival of published articles

Who would use it: administrators and volunteers

Current developments and tools: none

How it would work:
 * list abandoned articles and their last edit date
 * for each article provides link to article, talk page, history
 * for each article provides details of last edit (or several?)
 * allow to select whether to do nothing, userify or delete the article
 * userify means add 'tl' to all templates and add ':' to all categories
 * userify may also mean notifying the user on their talk page
 * this means we need to figure out how to show radio select boxes or an equivalent
 * fresh items at the top or bottom (whatever, as long as it is consistent)

Criteria of success:
 * identifies abandoned articles correctly
 * follows the choices indicated by the sysop

Task 6: Notify authors of peer review outcomes
Rationale :
 * notifier to tell the article author(s) of the review outcome see /Notifier merged this subpage into this page 02:04, 14 February 2018 (UTC)
 * notifier to tell previous reviewer(s) when the article is re-submitted for review
 * 1) The reviewer clicks 'notify contributors' button
 * 2) The page leaves messages on the contributors talk pages
 * This SHOULD NOT become a bugger
 * could be opt-out or opt-in (whatever preferred)
 * MUST ignore irrelevant contributors such as those who only fixed a typo or vandalised the page or did a page rename without any other contributions
 * SHOULD have a text area where the reviewer may leave a personalised message to deliver to everyone who is notified of the review outcome
 * SHOULD present the reviewer with a list of contributors and what they did to the article, so that they deliver the message to them all in one click (and only those that they consider unnecessary).

Who would use it : reviewers, authors

Current developments and tools :


 * one of the tests at WN:Dialog/do/test does page history
 * Dialog/do/test/history
 * specific tests i.e. Special:PrefixIndex/Wikinews/Dialog/do/test
 * js source in either the receive module or the do action.
 * docs Help:Dialog
 * partly at MediaWiki talk:Dialog/receive
 * MediaWiki:Dialog/receive follow the link to documentation, at the bottom under "see also" there should be a link to the javascript, MediaWiki:Common.js/Wikinews:Dialog/do


 * easy peer review script shows "article review completed" message at the top
 * 1) add link to pass article title as an argument to another page
 * 2) the 'another page' has a few things:
 * article title at the top (received as an argument, not editable)
 * list of article contributors who would be notified, with a tick box next to each (retrieved by JS based on the article title; excludes the last reviewer)
 * a multiline text area where the message may be modified (something like 'Re: article title here' headline and 'Hi NICK, your article was reviewed as 'not ready /.ready'. Please see reviewer comments here (this is a link to article talk page) and check the article history to see the changes made during the review as they may help you with writing your future articles')

phases
 * I can provide article title and retrieve the list of potential contributors to notify. api query a facility that allows dialog to acquire revision history of a page; might be up to 50 revisions at a time - at WN:Dialog/do/test - local dialog parameters request the data, the data is read from other dialog parameters
 * I can provide article title and retrieve the list of potential contributors to notify, then leave them all a message.
 * I can provide article title and retrieve the list of potential contributors to notify, then leave them all a customized message (edited before clicking submit)
 * can receive article title as an argument, and do everything described above.

How it would work:
 * provide interface at the time or after submitting a review
 * the interface is side by side with the review comment and the article contents so that either of them may be reused when writing the custom comments
 * interface has three inputs:
 * a list of relevant contributors (with links to user pages and contributions, and with summary of their contribution to this article (eg 'did 3 edits'))) which are all ticked but may be unticked
 * a custom message subject (prefixed by link to the review comments)
 * a custom message body
 * clicking submit delivers the message to the selected contributors talk pages
 * the dialog must have a link to the program discussion page or the technical water cooler

Criteria of success:
 * identifies relevant contributors correctly
 * delivers the custom messages
 * signs the delivered messages correctly

Task 7: Provide notes space
Rationale:
 * a scratch space for reviewer to store "running notes" (whilst editing the article at the same time) to use these notes in the final reviewer comment (from this page's talk page)

Who would use it: reviewers

Current developments and tools: none; easy peer review gadget notes must be placed into another program ie Notepad if article must be edited prior to submitting the review

How it would work: use localStorage to save the ezPR gadget contents. For different pages - use some identifier that does not change after a page rename.

Task 8: Edit the front page leads to add newly published articles
Rationale:
 * "Improved make-lead. Particular improvements of interest include better deduction of the lede (current program sometimes gets confused); better handling of templates in the lede; more sophisticated help with selecting an image; and swapping leads around rather than just replacing one." (from this page's talk page)

Who would use it: reviewers and administrators

Current developments and tools: Make lead

Task 9: Check freshness
Rationale:
 * date checker for freshness when inserting a source into a story or before starting to write a story

Who would use it: authors

Current developments and tools: none

Task 10: Populate the source metadata
Rationale:
 * automate writing of source templates
 * from URL get the date, author, publisher names and news title
 * warn the user if the date is too old (more than 3 days old)

Who would use it: authors and reviewers

Current developments and tools:
 * User:Gryllida/js/addSourcesUi.js (talk),
 * User:Gryllida/js/addSourcesUi.json (talk)
 * 
 * mw:Citoid
 * - Zotero translators contains a list of domains that helps to retrieve the relevant information from the page. This may need to be expanded to fit the existing massive listing of source templates already used at Wikinews..
 * https://stackoverflow.com/questions/3837717/get-html-of-external-url-in-jquery "The short answer is you can't, because AJAX requests are limited to the same (sub)domain and port by the Same Origin Policy. The usual way is to use a server-side script (written e.g. in PHP) that serves as a proxy: It fetches the external site's content and serves it back to JavaScript. It will have to run on the same domain as the page."

Task 10: Idea 1
An API (through extension or an external tool hosted on Wikimedia Toolforge or elsewhere) which takes


 * /getinfo/
 * Input
 * a page name, or
 * a page source text (wiki markup)
 * Output
 * infoboxes - a list of this page infoboxes, for example, Australia;
 * sources - a list of this page sources,
 * source url,
 * source title,
 * source publisher,
 * source author,
 * source date,
 * source language (if defined)
 * categories - a list of this page categories, for example, Category:Australia
 * number of external links in the article body
 * date of the latest source
 * warnings
 * if there is more than one external link in article body
 * if the freshest source is more than 3 days old
 * if there are less than two independent sources (from different publishers)
 * if some sources metadata is not indicated on the page
 * suggest values provided by zotero, citoid or similar
 * /modifyinfo/
 * Input
 * a page name, or a page source text (wiki markup)
 * list of properties to modify, and their new desired values
 * Output
 * new modified wiki markup

Task 11.: Walk the users through WN:PILLARS
Rationale:
 * Writers may often not be aware of the the 'no bias', 'no copyrighted content', 'pyramid' concepts.
 * Walk the user through WN:PILLARS (a wizard kind of thing)?
 * Present a 'I will have no bias', 'I will have 5Ws answered in lead', etc checklist above or to the side of the edit box or something, show it again when users click submit.
 * This can be interactive. First 'I will have no bias and observe copyright', then only show the 'pyramid structure' prompt after the user started writing a second paragraph.
 * This can be simply a video that users are encouraged to watch before they begin.

Who would use it: authors

Current developments and tools: Article_wizard (under construction)

Task 12: A ready to install image of Wikinews mirror
Rationale:
 * make it easier to work on Dialog tools
 * this needs to be a Docker image or a .iso file or something similar
 * should take 2 minutes to have a running wiki copy on localhost

Who would use it: developers

Current developments and tools:
 * https://github.com/wikimedia/mediawiki-docker

Task 13: Archive talk pages
Rationale:
 * When a talk page grows large, and particular discussions are no longer active, they need to be moved to a separate page. This is not so important at article talk pages but at water cooler this is a necessity.

Who would use it: everyone who wants to volunteer to look after talk pages

Current developments and tools: This is done manually using archive top template and similar.

Task 14: add todo notes to propose a story creation (often by oneself, sometimes by someone else)
Rationale:
 * There is no comfortable facility on-wiki to write 'this topic would be nice to write about'. A wn:newsroom/ideas page would suffer being a mess. And creating the articles in main namespace tagged with 'category:stub' would incur a maintainance burden on an admin.
 * Requirements:
 * store one or two sentences with links to sources which could later be written into a story, often by the same person who wrote these lines, but they may be unable to write half of their ideas
 * easy for someone else to take a proposed story
 * easy to dispose of the proposed stories which nobody takes
 * could be complemented with discoverability, for instance a person reading an article on a particular topic could be presented with a list of articles which are under development on a similar topic
 * avoid collaborative editing (it does not work well)

Who would use it: readers and article authors

Current developments and tools:
 * page categories,
 * develop tag,
 * article templates like Australia
 * A possible solution could be modifying infobox so that templates like Australia include not only published stories but also stories under development, which the reader could develop further. An option to suggest a news topic could be provided. (?)

Task 15: browse topics (categories) on-wiki
Rationale:
 * Provide readers with access to articles relating to a particular region or topic.
 * The topics should be easy to navigate.
 * The way the news on a particular topic is presented should be visually appealing and consistant.

Who would use it: readers

Current developments and tools:
 * Links from the front page take readers to pages like Category:Australia, however those are not as nicely formatted and the stories do not have images. It is also difficult to navigate back, readers maybe still want to continue seeing the list of topics handy without having to click 'back'.
 * 

How it would work:
 * expose interface to 'incategory' searches (ie "firefox incategory:Microsoft") or maybe "deepcat" not sure mw:Help:CirrusSearch
 * this would show at Special:Search

To make it more clear, I'd see it as

1) a bar with categories visible at all times when reading a story or viewing a category:

Africa • Asia • South / Central / North America • Europe • Middle East • Oceania • Antarctica Crime and law • Culture and entertainment • Disasters and accidents • Economy and business • Education • Environment Health • Obituaries • Politics and conflicts • Science and technology • Sports • Wackynews • Weather

And when the user moves mouse over them, or clicks any of them, a bar with subcategories is shown, for example

Africa • Asia • South / Central / North America • Europe • Middle East • Oceania (currently selected) • Antarctica
 * Australia • New Zealand

User then can navigate

Africa • Asia • South / Central / North America • Europe • Middle East • Oceania (currently selected) • Antarctica
 * Australia (currently selected) • New Zealand
 * NSW • South Australia  • Western Australia • Northern Territory • ACT • ... (Etc)

Simultaneously the topic categories could also be selected in a similar way.

2) At places like Category:Australia images and/or short snippets for each news could be shown.


 * I think that if a list like this is shown somewhere, it should have a search box which takes the reader to a news-friendly search page. Unlike the current one, this page should allow the reader to select topics (regions or sections) and view the results sorted by publication date. The current search API sorts them by creation date. I am not sure how this date processing should occur. When a certain topic is selected, all its parent topics should also be shown, and also the list of child ones (subcats of a given category). --Gryllida (talk) 00:40, 13 February 2020 (UTC)

Task 16: delete spam [urgency: medium; importance: high]
Rationale:
 * Spam often comes in the form of new pages. Its deletion requires (as I think) numerous clicks such as:
 * open the page to view its content and confirm that it is spam
 * click 'delete page'
 * click 'advertising/spam' delete reason
 * click 'delete'
 * click to switch back to the recent changes tab
 * click 'history' next to the page author's nick, check whether they made any other spammy pages
 * click to switch back to the recent changes tab
 * click 'block' next to the page author's nick
 * click to select 'indefinite'
 * click to select 'spam' block reason
 * click block
 * This is laborious and time consuming. The number of clicks needs to be reduced. This may be achieved by adding delete and block links where appropriate, pre-selecting the correct block and delete reasons, showing page contents or contributor contributions where needed so that viewing them on a separate page is not required.
 * expected flow:
 * see a new spam page
 * click a button to view user contributions
 * click a button to wipe all their new pages and block them indefinitely
 * as proposed by SVTCobra:
 * "click on the user name and select the type of spam (in this case phone number spam) and set for indefinite, and then the following would happen automatically: 1) block notice issued 2) mass deletion of pages added 3) revisions hidden 4) user added to the list" List of phone number spambots.
 * as proposed by Gryllida:
 * In fact when blocking it would be nice to view a list of the users contributions below the block box, and a mass delete tick box.
 * blocking section with the fields such as block duration and reason
 * tick box for mass delete (takes place when I click 'block')
 * 'add this block' button
 * list of the user's contributions
 * list of the user's deleted contributions

Who would use it: administrators

Current developments and tools:
 * User:Gryllida/js/showPagePreviewWhenDeleting.js
 * User:Gryllida/js/deleteLinkInRc.js
 * User:Gryllida/js/showUserContributionsWhenBlocking.js

Task 17: read sources
Rationale:
 * often sources are javascript intensive and clogged with unneeded sidebars and clunky website contents
 * this slows down a reviewer's web browser and clutters their mind
 * firefox provides a clutter-free reading view
 * retrieving the html-only version of the source could be useful
 * this may occasionally need a javascript-enabled html engine

Who would use it: reviewers and authors

Current developments and tools: none

Task 18: time the review process
Rationale:
 * find out what takes the most time during a review process
 * difficult to implement
 * this could be a video of a screen
 * SimpleScreenRecorder for Ubuntu, for other GNU/Linux distributions
 * VLC media player (tutorial) or ShareX (at Windows Store), both released under a variant of GNU GPL, ava available for Windows.
 * or a browser add-on which checks which tab the reviewer spends time in
 * find what web browser reviewers use
 * drawback: some reviewers just don't even start reviewing (for example I don't review larger articles with more than four sources) because of how terribly difficult it is, they are not included into this study

Who would use it: reviewers

Current developments and tools:
 * meta:Research:Wikinews Review Analysis
 * meta:User:LauraHale/Wikinews Content Import Analysis
 * Category:Wikinews training materials review screencasts (videos of review from LauraHale)
 * analyse these videos, time different steps of the review process -- work in progress

Task 19: identify the role of hash tags and social network choice
Rationale:
 * Wikinews publishes its news at social networks such as facebook or twitter, this is done by a robot or human, often without adding . Would addition of these hash tags increase audience? This may need to be tested.
 * A desired solution would be sharing some links with and without hash tags and creating a correlation.
 * The same solution could be used for different social networks.
 * This needs to keep in mind that more page views is not necessarily better.

Who would use it: everyone

Current developments and tools: none

Task 20: configure the editor - disable welcome dialog
Rationale:
 * If you open a new private browser window and visit Wikinews home page, there you can make a new page in the 'write a new article' section. That opens the new page contents in mw:Extension:WikiEditor.
 * 1) It immediately prompts "Switch to visual editor" or "continue editing". Visual Editor is not ready yet. How can this welcome dialog be disabled?

Who would use it: article authors

Current developments and tools: unclear

Task 21: configure the editor - enable syntax highlighting
Rationale:
 * If you open a new private browser window and visit Wikinews home page, there you can make a new page in the 'write a new article' section. That opens the new page contents in mw:Extension:WikiEditor. It has no syntax highlighting.

Who would use it: article authors

Current developments and tools:
 * mediawiki.org has a syntax highlight toolbar button for the WikiEditor (see, for example,, type foo and it turns blue underline). Where is this syntax highlighting toolbar button and its subroutine source code found? (I like the syntax highlighting; not sure whether the font size changes for headings are a good idea or not.)
 * mw:User:Remember the dot/Syntax highlighter (but that's separate, not the same thing as the wikieditor syntax highlight toolbar button)
 * mw:Extension:WikEd maybe too confusing
 * mw:Extension:CodeMirror already available as beta feature, may be the preferred option. enable it by default for everyone including anonymous contributors?

Task 22: configure the editor - add error checking
Rationale:
 * If you open a new private browser window and visit Wikinews home page, there you can make a new page in the 'write a new article' section. That opens the new page contents in mw:Extension:WikiEditor.
 * 1) I would like to add line numbering to it like in mw:Extension:CodeEditor and some syntax check (" " for example). This would allow me to write a custom subroutine to nag myself about sources templates that were not filled in correctly. How can this line numbering and error check be added -- you can see this error checking at a javascript page if you type "{" without a closing brace. How can this be added to the wiki editor?

Who would use it: article authors

Current developments and tools:
 * linter
 * w:User:Cameltrader/Advisor

Task 23: add categories
Rationale:
 * when writing an article it is necessary to categorize it

Who would use it: authors and reviewers

Current developments and tools:
 * HotCat gadget

Task 24: add images
Rationale:
 * articles need illustrations, now people must upload them at commons which is many clicks and often takes them away from the article page
 * licensing needs to be very very clear, plagiarism is common with image uploads

Who would use it: authors and co-authors

Current developments and tools:
 * commons plain upload
 * commons upload wizard
 * visual editor has a dialog to upload images
 * non-visual editor could just link to the commons upload wizard

How it would work:
 * provide a toolbar button to upload an image
 * this toolbar button opens a dialog which
 * explains that images are to be uploaded to Commons
 * allows direct file upload provided that user ticks 'this is my own CC-* work to release to commons' box
 * links to commons upload wizard for more complex cases
 * links to local upload wizard for the cases when image can not be uploaded to commons
 * indicates image attribution in caption

Criteria of success:
 * ability to add an image from non-visual editor
 * ability to add an image from visual editor
 * correct syntax of the inserted image in the produced article
 * correct Image source provided in caption

Task 25: de-clutter editor toolbar
Rationale:
 * wiki editor presented to new users has a toolbar
 * [[File:VectorEditorBasic-en.png]]
 * many items in it are not relevant
 * bold - used outside of main namespace (very very very rarely)
 * italic - used (not every time)
 * add external link - not used
 * add image - ok, but dialog is confusing, majority of users may wish to upload a new media (?)
 * add reference - not used in this form (ref tags), need add source instead?
 * advanced, add picture gallery - used (not every time)
 * advanced, add table - used (not every time)
 * advanced, headings - used (not every time)
 * advanced, suberscript, subscript, big font, small font, nowiki - used outside of main namespace (not every time)
 * special characters - could be useful for currencies I guess
 * help
 * links - needs instructions to use W for links
 * references - irrelevant (ref tags), maybe replace this with brief instructions how to use source template
 * everything else seems ok
 * missing items: add source, add quote (quote), add infobox, add category

Who would use it: authors

Current developments and tools:
 * mw:Extension:WikiEditor
 * mw:Extension:WikiEditor/Toolbar customization

How it would work:
 * remove ref tag references button
 * add buttons to add categories and infoboxes and sources and wikilinks and article status tags

Task 26: redesign visual editor toolbar
Rationale:
 * UI provided by visual-editor is irrelevant
 * preload must be supported
 * missing Wikinews-specific items:
 * info-boxes
 * allow to add image galleries
 * add Image credit to every image caption when adding an image
 * add sources using source
 * add wiki-links using W template
 * template:date requires no user input, but is based on subst and pulling in the date.
 * tag articles with template:draft, template:review etc
 * add a category

Who would use it: authors or reviewers

Current developments and tools:
 * Visual Editor

How it would work:
 * remove ref tag references button
 * add buttons to add categories and infoboxes and sources and wikilinks and article status tags
 * adding gallery or italics or headings should be available but not the most important feature

Criteria of success:
 * quality of entries submitted using visualeditor
 * makes sense to people who did not use visualeditor before
 * renders templates correctly

Task 27: find alternative sources to paywalled
Rationale:
 * need to find alternative syndicate sources when some are paywalled
 * "The Washington Post, ABC News, The New York Times — they are paywalled sources and of ten they republish articles from AP, AFP, Reuters or such wire agencies" (acagastya)

Who would use it: authors and reviewers

Current developments and tools: none

How it would work:
 * "search headline with syndicate name prefixed" (acagastya)

Task 28: real-time communication
Rationale:
 * people with intermittent or non-24/7 internet need to be able to read new messages from wikinews
 * requirements:
 * offline message storage (user comes back online, reads messages sent in their absence)
 * mobile friendly
 * real-time

Who would use it: ...

Current developments and tools:
 * wiki talk pages - not real time
 * WN:IRC - real time, but no offline message storage
 * Wikinews-l mailing list
 * Skype groups, Telegram groups, Facebook groups, Twitter groups - ??

Task 29: editing tips
Rationale: Markup and style documentation is long. Its parts could be presented to users at the time they are editing a page.
 * Each tip is short.
 * Each tip has a next and previous button.
 * Tips are chosen at random.

Who would use it: authors

Current developments and tools:
 * mw:Manual:Interface/Edit notice
 * WN:SG
 * WN:CG

Task 30: timezone tracker
Rationale:
 * we donot know timezones of other contributors. If we do we may forget what is their current time

Who would use it: anyone talkative :P

Current developments and tools:
 * proposed idea: use this library to show time
 * where to show:
 * page top ( a few relevant times of user's choice )
 * https://usercontent.irccloud-cdn.com/file/nHFQNRNL/IMG_2450.JPG
 * userpage & user talk page top (time of current user )
 * signature ( current time of the user )
 * what to show:
 * current time of the contributor
 * timezone of the contributor
 * User:Acagastya/Time.js
 * Time-Convertor - maybe add option of named bookmarks for individual people?
 * Time-Convertor - maybe add option of named bookmarks for individual people?

Task 31: debug dupdet
Rationale:
 * dupdet frequently stops working entirely after certain URLs are supplied

Who would use it: reviewers & authors

Current developments and tools: dupdet
 * proposed solution:
 * log which URLs are being processed prior to each dupdet restart
 * https://github.com/jamesryanalexander/Duplication-Detector
 * People: Jamesofur, Gryllida

Task 32: ui, analysis of post-publication edits
Rationale:
 * policies prohibit edits 24h after pubilcation
 * ui does not show this it does,as &editintro=Template:Editintro_notcurrent

Who would use it: authors, proofreaders

Current developments and tools:
 * a message at the top of edit box which warns of flaggedrevs approval required
 * analyse post-publication edits?
 * modify the message to conditionally include a reference to Correction after 24h have passed?

Task 33: track decline and deletion reasons
Rationale:
 * need to track decline and deletion reasons
 * need to track article review phase history - which phrases take longer - to see when and why authors abandon writing a story
 * this would help to make writing easier by developing templates and tools which facilitate the difficult tasks and provide clear documentation of the work required to complete
 * this could also allow to track mistakes and topic preferences of authors and reviewers (to easier allocate articles from review queue to each reviewer)

Who would use it: reviewers, authors, editors, everyone

Current developments and tools:
 * currently review history is only stored at the article talk page, and after the article is stale and is deleted, this precious information is no longer available for the newcomer or for other reviewers
 * Gryllida (talk) leaves notes to involved authors in the view of numbered list on some contributors' talk pages, this is done by hand by reading the story (prior to deletion, or after a review) and formulating a list of strengths (=to praise) and weaknesses (=points for improvement)
 * this is time consuming and not everyone does this and we do not know how to do it in the most efficient way possible
 * we need to assist a reviewer or a deleting administrator with leaving notes from an article talk page on authors' talk pages (or reviewers' talk pages where a reviewer preferred topic areas may be noted)

Needed implementation:
 * 1) by article name, output its review phase history
 * 2) *date created,
 * 3) *date added to developing,
 * 4) *date submitted for review,
 * 5) *date re-submited for review,
 * 6) *date marked as abandoned,
 * 7) *date deleted)
 * ...and author(s) involved (which reviewer or which author did the category change)
 * 1) output in a sortable table
 * 2) add 'time from creation to submit to review', 'time from submit to review to reviewed' etc columns to the table
 * 3) by a username, show this information for each article they created - including for deleted articles (needs sysop access)
 * 4) by a username, show this information for each article they reviewed - including for deleted articles (needs sysop access)


 * I just posted a note to Phabricator requesting help with this. Please feel free to comment there.  I don't know how to do that, but you probably do.  Thanks.  DavidMCEddy (talk) 15:46, 29 August 2018 (UTC)


 * No, Phabricator is a place where I cannot post; I do not trust the conditions on the agreement I would have to sign off on to get an account there, and even if I did, afaict it's subject to arbitrary bans by a Foundation star-chamber so I wouldn't wish to say anything there. --Pi zero (talk) 17:39, 29 August 2018 (UTC)
 * Phabricator is for help with software developed by WMF. This is a content task and in my opinion we need to do it ourselves. (I'm working on task 10, after which I may move to another task such as this one.) Gryllida (chat) 20:33, 29 August 2018 (UTC)

Task 35: facilitate identification of emerging news
Rationale:
 * it's hard to seek local news, manual long laborious process
 * if news is identified quickly, it may have higher chances of publication before it becomes stale
 * We may need a news reader, with each news source associated with an area and a comment, which everyone can access and apply tags & date to each headline, perhaps with assistance of an AI tool.

Who would use it: anyone

Who to contact:
 * Gryllida (talk) (Sveta at IRC)

Proposed implementation tips:
 * a tool could ask the user to specify country, based on their country or their list of sources propose events they could write about (with the 'requested article' form already filled in, the person needs to read the sources and add a bit of description and click confirm)
 * can use emerging Facebook trends or Twitter moments for example
 * if country is specified this tool could suggest to the user which sources they could use (based on what the developer wrote or based on what other users use in this area)
 * can use AI eventually (?)
 * https://spacy.io/
 * https://www.gdeltproject.org/
 * http://openeventmap.de/webdesign/index.html#power demo missing Source code not provided.

Current developments and tools:
 * Requested articles here people can propose a story

Task 35: live chat box
Rationale:
 * add real-time chat to make the site more interactive
 * people can then use this facility to reduce confusion

Who would use it: authors, reviewers

Current developments and tools:


 * Proposed idea:
 * a 'live chat now' box at the right top corner of a page
 * person opens the box. on irc we get a 'hi from ' and say 'nick: hi'
 * person sends their question. an irc bot delivers the question to IRC. an interactive session begins.
 * at IRC someone replies with "nick: answer here", something delivers the answer back to the box
 * privacy concerns with delivery of message to a channel where anyone is. instead deliver it to a channel where only helpers are present?
 * concern about transparency
 * concern about availability of helpers at the right time
 * maybe another implementation can resolve this problem

Add a new task
To add a new task, click 'edit source' here and copy/paste the template above the 'add a new task' heading. Then update the task number below.

= Phases =

"Task 12: A ready to install image of Wikinews mirror" may be a prerequisite for this work so that publishing features may be tested on another wiki.

Phase 1: provide documentation and track review status
These are currently supplied by Wikinews wiki:


 * users can read documentation on the requirements
 * users can submit a news article via a web form (a text box and a submit button)
 * users can track article submission status by visiting a particular URL
 * reviewers can publish or not-ready articles
 * published articles are listed at the front page
 * collaboration is available at article talk pages and users' talk pages
 * file upload
 * article categories
 * RSS
 * API to all functions available at the web interface

Phase 2: improved authoring tools
This is an expansion of phase 1. In addition to its features, provide the following:


 * Task 1: Check plagiarism
 * ✅ User:Gryllida/js/plagiarismcheck-0.1.js Version 0.1 (2018-02-24) - initial release - adds an "Open DupDet" tab which provides links to dupdet results against the external links present in the article
 * Task 10: Populate the source metadata
 * ✅ as a script User:Gryllida/js/addSourcesUi-0.1.js, adds toolbar button to wiki editor. please test!
 * as an extension
 * Task 9: Check freshness
 * how?
 * Task 2: Insert Wiki Links
 * User:Gryllida/js/addWikiLinks-0.1.js Version 0.1 (2018-03-11) adds wikilink buttons to wiki editor - link local, link wikipedia, link to an exact title match (auto-detect) - this needs a rewrite to somehow prefer adding W links over any other options
 * ✅ wizard to localify W links (for each link, choose whether to localify or not, and whether to add to respective category or not)
 * User:Gryllida/js/processWLinks-0.1.js 05:43, 29 March 2018 (UTC)
 * Task 3: Check spelling - rendered useless
 * Task 11.: Walk the users through WN:PILLARS (preliminary and simple)
 * how?
 * ✅ as a larger template, (Uses template and edit intro.)
 * via mw:Extension:GuidedTour?
 * ✅ via User:Gryllida/NewArticleStepByStepV2 (needs testing)

Phase 3: improved reviewing tools
This is an expansion of phase 2. In addition to its features, provide the following:


 * Task 4: Highlight text in article
 * Task 5: Archive old or abandoned stories
 * Task 6: Notify authors of peer review outcomes
 * Task 7: Provide notes space
 * Task 8: Edit the front page leads to add newly published articles
 * Task 11.: Walk the users through WN:PILLARS (advanced)

Phase 4: advanced collaboration and publishing features
This is an expansion of phase 3. In addition to its features, provide the following:


 * Simultaneous collaborative editing
 * Audio chat
 * Internationalization to publish in another language

= Other notes =

Education seems unused? --Gryllida 23:59, 18 February 2018 (UTC)

w:Wikipedia:User_scripts/List

mw:Gadget kitchen

Context: Wikinews aims to publish free entertaining news without bias. Newcomers are pointed to Style guide and Content guide. This is a lot of information and they do not usually read it in full the first time. There are many tasks that are done manually and waste time, and many common mistakes.

Writing (first time)
 * mistake: newcomers do not realise the story needs to be recent (WN:Fresh -- event needs to have happened within last 2-3 days)
 * mistake: newcomers often do not recognise how inverted pyramid article structure works (WN:Inverted pyramid)
 * WN:5W -- 'the first paragraph should say what, when, where, why, how, rather than spreading essential information across the entire article'
 * new and essential content goes first; non-fresh background goes at the very end
 * this is to make it very easy for the reader to get fresh and essential information from the first paragraph or two
 * mistake: some newcomers often plagiarise
 * automated tool to detect and show plagiarism score?
 * this is easy to work around by copy/pasting and then rewording text -- hard to catch and undesirable; wastes reviewer time
 * tool to react to 'paste' event in a text area?
 * interfere with the paste?
 * surround the pasted text with quotation marks?
 * manual work: newcomers often do not add wikilinks, or add them in a wrong way
 * manual work: newcomers often do not know how to fill in the sources template
 * automatically generate it from URL?
 * hard to auto-detect author, date

Writing
 * manual task: open a few sources (preferably with JavaScript off; only the plain text is needed, not the whole page)
 * manual task: remember parts of sources relevant to the story
 * could be highlightable - https://addons.mozilla.org/en-US/firefox/addon/textmarkerpro/?src=search
 * "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 resolv"e the concerns https://www.mediawiki.org/wiki/User:Brian_McNeil/improved_Wikinews_orkflow.
 * manual task: remember information from sources and write it in your own words
 * manual task: spell check
 * encourage users to install a spell checker, or provide it at the site
 * manual task: sort sources by date
 * manual task: add map
 * https://www.mediawiki.org/wiki/Help:Extension:Kartographer provides mapframe into a wiki markup
 * 'add map' button is provided by Visual Editor, but does not expose the user to all options (line color, pin color, etc)
 * manual task: upload image (have to go a long, long way for this, many clicks to upload an image to Wikimedia commons)

Reviewing
 * manual task: for fact check, search for a phrase in all open tabs
 * manual task: plagiarism check
 * https://tools.wmflabs.org/dupdet/ is used, but URLs are currently supplied to it by hand
 * manual task: for fact check, remember a lot of information from sources
 * highlight parts of sources relevant to the story? see highlight remarks above
 * manual task: add wikilinks (often time is wasted finding the right page name at English Wikipedia - open it in separate tab, type page name in the search box, etc)
 * manual task: edit the article without losing review comments
 * (current easy peer review tool doesn't allow this ...)
 * manual task: move article to user namespace
 * "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." https://www.mediawiki.org/wiki/User:Brian_McNeil/improved_Wikinews_workflow
 * manual task: review notification
 * "The ability to notify appropriate contributors of an articles failing (or indeed passing) reviewAt 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." https://www.mediawiki.org/wiki/User:Brian_McNeil/improved_Wikinews_workflow
 * manual task: provide instructions to users; should be a way to do wizards
 * "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. " https://www.mediawiki.org/wiki/User:Brian_McNeil/improved_Wikinews_workflow