User talk:Gryllida/Tasks

Review subtasks

If we're accumulating a general list of things a review assistant might do (not necessarily ones that require any primitive capabilities not already implemented), here are some:

• Keep running notes that can later be used to compose review comments. This may sound minor, but I often think of things during review that I want to mention in review comments, then lose track of them by the time I'm actually finished.
• When completing a review (regardless of whether publish or not-ready), aid in leaving a note on the user talk page of the reporter (or user talk pages of the reporters, if there's more than one).
• 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.

--Pi zero (talk) 23:25, 26 October 2017 (UTC)

Tasks via dialog tools

Guesses on how smoothly the 13 tasks integrate with the dialog tools. The levels from easiest to hardest are:

• I. Can probably be done with substantially the tools already in place.

The tools can already extract page history (somewhat), manipulate page content, and perform an edit; that's enough for some purposes.

• II. Can probably be done with a few simple straightforward operations added to the tools.

Some pretty basic operations aren't available yet, and some careful thought should go into how they're supported to make sure the design naturally encourages the sorts of safeguards these more potent operations should have. All of these are sensitive, some have hefty potential for wrecking havoc: sighting pages; renaming pages; deleting/undeleting pages; setting/modifying/clearing blocks.

• III. Should be doable by adding a specialized action.

An action is essentially a javascript program attached to a page, that uses the receive module to interface with the dialog system. Pretty much arbitrary operations can be performed that way.

	I nothing new	II general ops	III specialized ops
1: plagiary				supposing article content can be extracted
2: wikilinks
3: spelling
4: highlight
5: old/aband
6: notify authors
7: running notes
8: make lead				make lead sights the edit, so that's a operation not yet supported
9: freshness				some kinds of checks are easy, others not so much
10: source cite				supposing article content can be acquired, extracting info may sometimes approach hard-AI
11: pillars/wizard
12: mirror
13: archive discussions

One could somewhat imagine spellchecking at level I rather than level III, but my first guess (and only a guess) is it'd be awkward and slow. --Pi zero (talk) 04:51, 17 January 2018 (UTC)

Regarding "todo" task

Two thoughts.

• We should beware of building into such a facility a bias on the dicey question of single-writer versus multi-writer articles. In my experience, collaboration on articles sometimes works, but often creates problems more than it solves them. Perhaps there are ways to make it work; but it seems advisable that any ToDo facility should be designed so as to not interact with that complicated issue.

That suggests to me, likely, a facility for making a suggestion without actually starting a stub article, as such. A stub is, after all, an article that has already been created and therefore tends toward multi-author unless taken up by the same person who started it (which is possible, but it seems the notion was more in the suggestions-for-someone-else vein?).

• There is a page on the site that was meant for people to make suggestions of this sort. It hasn't worked at all well. The two biggest shortcomings seem to me to be:

• It's far too labor-intensive, in all its aspects; it seems to want a stiff does of semi-automation. One would like assistance with adding an item, with picking up a suggestion, and with disposing of a suggestion once it passes by and is no longer viable.
• It's not nearly visible enough; the solution of which might well also involve semi-automation.

--Pi zero (talk) 12:56, 13 February 2018 (UTC)

@Pi zero: Thanks. I've put a note that collaborative editing is to be avoided into the relevant section. My thinking is that perhaps people who read news on a particular topic regularly could start making tiny ({{stub}}) articles and tag them with {{free for anyone to take}} at the time of submission. Perhaps eventually such readers (a) encourage good coverage of the topics they have interest in; (b) continue coming to Wikinews to read on their topics of interest; (c) eventually start writing larger articles. Perhaps this eases the learning curve somewhat, as they have an opportunity to watch the development of the stories on topics that interest them. Gryllida 02:27, 14 February 2018 (UTC)

Notifier

Do you mean everyone who has edited the article should be notified about the review outcome? Even if someone had just fixed a typo/vandalised a page/moved it/other reviewer who not ready'ed it? Personally I think a personalised message by the actual reviewer does a better job. And not always should the author desires to receive information about it, unless it failed. Noobs want to know when their article passes (and sometimes fails too) as someone who has enough experience; they are worried if the article fails. The notifier would soon become a thing like daily digest which some people would not care to read and/or find bugging.
•–• 01:46, 14 February 2018 (UTC)

{{ping|Acagastya}}

1. A contributor who fixes a typo can mark their edit as minor and then they may not be notified.
2. A contributor who vandalised a page may have their edit reverted. The notifier could look for 'revert' edit summary messages and use those as a guidance for excluding those contributors.
3. Moving a page is tricky. It's not possible to mark this edit as minor. Perhaps those who move a page can be either ignored by the notifier, or be notified anyway, whatever is considered desirable (this is easy to exclude them).
4. The reviewer who just not readied it is the best person to know of new changes. Perhaps they need to be notified when the page is submitted for review.
5. Re "Personally I think a personalised message by the actual reviewer does a better job." -- agreed; this notifier tool MUST have a text area where the reviewer leaves a personalised message.
6. Re "And not always should the author desires to receive information about it, unless it failed." -- this can to be opt out or opt in, whatever the user wants it to be, they could be able to set this.

I've incorporated some of these ideas into the relevant section. If you have other suggestions how to only notify people who are likely to act on the review comments quickly, please share. --Gryllida 02:15, 14 February 2018 (UTC)

I don’t always mark typo/ce edits as minor edits. Anonymous editors can not make minor edits. Sometimes I explain the revert and the undo revision summary is removed if 256 character limit is reached. The opt-in opt-out is tricky. I would like to know the status of articles that failed on a normal day, but when I have to travel, I wish to know about it regardless of the outcome (I would specify on or off wiki). And then how if this different from EzPr? Just copy the review comments and status and dump it on the talk page of authors from the authors list. I believe I am missing something and you should explain more about this notifier.
•–• 02:23, 14 February 2018 (UTC)

@Acagastya:Manually copy/pasting review comments to the talk pages of relevant contributors is laborious and time consuming. The notifier could 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). Again added this to the task section. --Gryllida 02:30, 14 February 2018 (UTC)

I can do in 1 + 2(N) clicks if the aim is telling N users what is written in the review comments -- so I am not convinced we need this. As far as informing various authors -- each author need not be told the same thing, what about that situation?
•–• 15:39, 14 February 2018 (UTC)

We don't want something that produces a boiler plate, but the unaided task of leaving personalized notes is onerous and as a result often isn't done. There are some sorts of remarks that work better on user talk than article talk. So, to my mind, we want a tool that makes it easier for the reviewer, at the end of a review, to leave short, somewhat-personalized notes on the talk pages of relevant users. There are certainly lots of ways for it to go wrong, and we need to leave the human decisions to the human reviewer while absorbing mindless tedium into a semi-automated assistant (which sums up the challenge of semi-automation in general). --Pi zero (talk) 15:46, 14 February 2018 (UTC)

About the reviewing process

Lately, I have noticed here in particular that the reviewing and approval process for an article which has been newly written often is so slow that most news items already get stale (according to the strict criteria used here) before they can be published at all. Another point is that I sometimes get the impression that certain topics are selected earlier than other ones for the reviewing process (this might have something to do with the interest fields of the reviewer, though I can't be sure of that, of course). The result is that the topics which appear here on the front page represent a very selective choice, which does not really (perhaps rather: not at all) reflect the news which is worldwide most important (which, in my opinion, should be by far the most important criterion). likely is due to the very low number of active reviewers. So I think there should in any case come more reviewers. De Wikischim (talk) 09:19, 14 February 2018 (UTC)

my two cents: reviewers do not magically come up and start reviewing articles — experienced editors become reviewers. Did you read the 18.02 WN:Print Edition? There were thirteen articles published last week. Do you seriously think there is a recurring theme of the articles? How do you claim some articles are more newsworthy than others (a clear PoV/CoI; beedless to say, breaks neutrality concept) To be honest, your “worldwide most important” bullshit does not consider events that did not happen in the first world countries. This is not the first time I am telling you this; but without strict policies; the quality of articles is not up to the mark, and that is something we can not compromise with. The only reason you "might" be able to find articles of similar focus is because out of the last ten articles published, I wrote eight — and my interest would be reflected in those articles. A reviewer is not going to say no to my articles just because many of my stories were published. And even if I was the author, I can find diversity: an obituary of a war “hero” and first female to do X (being a crucial article for that country); a retired footballer's obituary (important in UK countries where he played); two articles about politicians sentenced for corruption (one being one of the most important news articles in that country), a crime and law article about mob violence in Pakistan for false blasphemy (sensitive topic in that country, and one of the most important articles for that country), KNVB assigning new manager to men's team (most important article for Dutch football), Google fined by Indian watchdog (latest development to their biased search results; already faced issues in the EU, Russia), arrest of a Chinese bookseller highlighting no complete freedom of expression. I fail to see a recurring pattern. FWIW, either you learn to write articles per the threshold standards or don’t (else you would be wasting your time) because the standards would not be lowered.
•–• 12:24, 14 February 2018 (UTC)

@De Wikischim: another couple of cents from me:

• You're quite right that we want to increase review capacity, which includes both increasing efficiency per reviewer and increasing number of reviewers. We're discussing here tools to aid reviewing and tools to aid writing, and in the long run both of those lead to increased review capacity: Good tools to aid review make reviewers more able to review, including making people who are capable of review more able to afford to actually do a review since it's a smaller lump-sum investment for them. Good tools to aid writing should, hopefully, increase the success rate of new contributors, if nothing else eliminating superficial distractions so they can concentrate on whichever fundamental principles they may be struggling with; and increasing quality of articles submitted should, hopefully, somewhat decrease difficulty of review. The more reviews, and the more publications, we can achieve, the larger the contributor base we can support — and our future reviewers are a fraction of our contributor base, so we have to greatly increase our contributor base in order to later increase our reviewer base.
• Regarding topic bias (though that's less directly relevant here): I might struggle to express this in the most positive way, but, reviewers are more able to afford, and more eager, to invest their labor in a review that is likely to be a smooth process and produce a high-quality publication. So the way for a contributor to have a larger voice in what gets published is to improve their skills at producing articles that will provide that sort of review.

--Pi zero (talk) 13:14, 14 February 2018 (UTC)

Hello De Wikischim. Thank you for raising this question here. I agree with the concern and concur with what Pi zero said, essentially their first paragraph above is the motivation for my work on this list of tasks and finding or writing scripts which provide the necessary feature set. --Gryllida 22:38, 15 February 2018 (UTC)

Task 16: delete spam

And recently, with the fake tech support phone number spam, we have to hide revisions also since they put the phone number in the title and/or edit summary. Also, we add the user to Wikinews:List of phone number spambots. Another step we always do, is to issue a block notice (either on the user page or user talk page). I don't know how far you want to take the automation, but my dream is to 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. I have no idea how much (if any) of this is possible, but I just happened to see you writing about it in your task list. Cheers, --SVTCobra 22:50, 19 February 2018 (UTC)

OK. Thanks. Added this to the task section. --Gryllida 03:49, 20 February 2018 (UTC)

What consideration have Wikinews and other Wikimedia projects given to using w:CAPTCHAs to limit spam? Wouldn't this largely eliminate bots posting press releases and similar spam? DavidMCEddy (talk) 05:23, 4 September 2018 (UTC)

Hello DavidMCEddy  :-)

We currently use the 'fancy captcha' for signups and for URL insertions in articles.

The spammers are bypassing this captcha.

Also some of their edits do not have any URL whatsoever.

This makes them difficult to distinguish from legitimate edits.

Cheers, --Gryllida (chat) 02:48, 5 September 2018 (UTC)

Task 15: browse topics (categories) on-wiki

Fwiw, there is a not-yet-completed effort toward some such device at User:Pi zero/Archives. (As I recall, it was proving to be a difficult problem.) --Pi zero (talk) 01:51, 13 February 2020 (UTC)