User:Gryllida/wc001

Some technical ideas how to help Wikinews grow. Anybody is welcome to edit this page.

Writing and reviewing tools

Problem: writing and reviewing articles has common errors and common routine work. Reviewing takes longer, articles get stale. Helper dialogs could be scripted to inform authors and aid reviewers. Challenges: lack of a non-production server; time and effort for both coding and design.

• help writing WN:Dialog
• start a Wikinews mirror to help scripts and extension development

Statistics analysis

Problem: we don't know why articles most commonly get rejected. If we know this, we may be able to design a better help page. Challenges: find time to code this, find time and good strategy to analyse this.

• review comments including rejections
  • rejections get deleted
  • store somewhere separately where it is not deleted?
• delays
  • between author submission and reviewal
  • between reviewer comment and author reply
  • not stored at all at present
• language
• history of the volunteer contributor (number of submissions, edits, and acceptances)

Word of mouth

Problem: people don't always easily refer friends to Wikinews. We could find barriers and ways to make this easier. Challenges: identify the barriers.

• Wikinews has Twitter, Facebook, Instagram, and other social networks presence.
• at some point we published original reporting from all wikis in a weekly newsletter
• Wikinews Audio edition
• Wikinews Print edition
• ???

Universities students

Problem: people do not know of Wikinews and read crap mass media. Solution: educate everyone. Advantage: improves relationship with academia.

Challenges: students often leave Wikinews after finishing their course.

• Category:UoW student
• There was another university collaboration with Wikinews in the Russian Wikinews, I would have to find out what it was.

Video format

Problem: some people prefer daily reporting with a talking head and videos or at least talk + visuals of the recent events. Solution: create such reporting.

Challenges:

• volunteer time?
• not enough visuals for many articles?

From Wikinews:Water_cooler/policy,

Quote

---

• I would personally expect that many news articles fail the review process entirely due to two main reasons: they get stale (if there is too many articles or the topic is too specific for the reviewer to handle), or the article writer does not put effort into working on the reviewer comments. Adequate reviewing and review feedback tools would resolve both of these issues.
• Finding the exact statistics is hard because the articles eventually get deleted. If you have ideas on how to resolve that, please tell. (I would perhaps be willing to volunteer to write a code to log the review actions on one page in plain text, just how they are on the article talk page, except that one page would not get deleted).

@Gryllida: Can you get a group of editors to brainstorm categories and codes for delays? Then data can be harvested on codes for delays vs. time to the last edit on articles when published or deleted. Combine that with data on the reviewer, language, history of the volunteer contributor (number of submissions, edits, and acceptances), and whatever else we can conveniently harvest. That could be analyzed in many different ways. DavidMCEddy (talk) 21:41, 9 June 2017 (UTC)

DavidMCEddy, I did not quite fully get the idea. What delays? In what format would you like the data to be stored? --Gryllida (talk) 04:22, 15 June 2017 (UTC)

Quote

---

• You need to tell the public that writing tools is complicated by the need for any 'Extensions' to pass a code review by WMF Engineering. This is a slow process. JavaScript and Lua programming is available to site sysops without WMF review requirements, at present; they have less flexibility, but the deployment is easier and this is a great thing. However, having a guide how to create a copy of Wikinews for development would make engaging new contributors into the development process a lot easier. I am struggling with finding that out, myself, for over a year.

Regards, --Gryllida (talk) 02:01, 22 May 2017 (UTC)

@Gryllida:, @DavidMCEddy: I've wondered about saving review comments. When trying to assess a contributor from the reviews of their articles, it's often very useful to be an admin so one can read the reviews of their failed articles as well as their successes. We really need to provide much more robust support for accumulated reputation of users we don't personally know well; this sort of thing must be better supported in order for us to successfully scale up; if there were a thousand active users on Wikinews every day, how could a reviewer know what sort of writer they were dealing with, and how could anyone recognize if a small group of reviewers ever started rubber-stamping each others' articles? At the same time, though, deleting the talk pages of unsuccessful articles can also dispose of a great deal of unpleasantness. One could, of course, save only the reviewer comments, not the comments by others, but then what if a reviewer made a comment that was legitimately objected to? The reviewer would automatically get the last word. This is a sort of thing I would be giving a lot of thought, if the things I've been doing with the dialog tools weren't so obviously even more urgently needed. --Pi zero (talk) 02:33, 22 May 2017 (UTC)

Would it be suitable to log the review comments on User:Foo/reviews, where Foo is the nick of the person who submitted the article for review? I could perhaps try to edit the easy peer review script to do that on another wiki, and after it works, copy the edit here. --Gryllida (talk) 04:30, 22 May 2017 (UTC)