Wikidata talk:Bots/Archive/2020

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Request approval of Reinheitsgebot be revoked

User:Reinheitsgebot has been warned on several occasions of introducing the wrong calendar, usually Gregorian, when the correct calendar is something else, usually Julian. Here is one such warning. But the behavior continues. In view of the long-term unwillingness to do anything about this problem, I request the bot permission be revoked indefinitely. Jc3s5h (talk) 16:19, 19 December 2019 (UTC)

@Jc3s5h: the bot didn't introduce any calendar in your example, I look at another example you reverted and here the bot is also only sourcing it. So what's the problem? Multichill (talk) 16:49, 19 December 2019 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ One of the edits in question is this one, for Caroline Matilda of Great Britain. She was born in London, which in 1751, observed the Julian calendar. The edit asserts the birth date was 11 July 1751 Gregorian and give the source as The Peerage. More exactly, the Wikidata item already falsely claimed 11 July 1751 Gregorian, and said it was imported from the Spanish Wikipedia, which like all Wikipedias, is an unreliable source.

The Peerage is run by an amateur, but it does appear a lot of effort went into it; discussing the reliability of that site can wait for another time.

The Peerage's item does indeed state "b. 11 July 1751" but does not, in immediate proximity to the date, say what calendar was used. The site's FAQs do not say anything about calendars.

Digging deeper, we can look at a really famous person, Isaac Newton, on The Peerage; the death date given is 20 March 1727. As is documented by many sources, such as Encyclopedia Britannica, this is a Julian calendar date, but uses January 1 as the beginning of the new year, rather than 25 March as was the practice in England at that time. This shows that the date from the peerage for Caroline Matilda is most likely a Julian calendar date, not a Gregorian calendar date.

The persistant fault in the bot is turning it loose on sources which provide Julian Calendar dates but falsely interpreting them as Gregorian calendar dates. Jc3s5h (talk) 17:29, 19 December 2019 (UTC)

So you know a date can be improved and instead of doing that, you revert the bot and come complaining here? I understand you want to improve quality, but this is not the way to do it. Multichill (talk) 18:50, 19 December 2019 (UTC)

My most recent reversion of this bot did improve the item. The bot added the death date 9 April 1626 Gregorian, supported by two sources, neither of which state which calendar the date is in. The bot made the incorrect inference the dates from the sources were Gregorian. There was no need to add either of the sources added by the bot because the date, correctly lablled as Julian, was already supported by sufficient good sources. Jc3s5h (talk) 19:15, 19 December 2019 (UTC)

We have sourcing circumstances (P1480)=unspecified calendar (Q18195782) for a vague source.--GZWDer (talk) 20:22, 19 December 2019 (UTC)

sourcing circumstances (P1480)=unspecified calendar (Q18195782) is fine if no high quality source with an unequivocal date can be found. Part of this process involves a human editor searching through the source for any statement of what calendar is used, in places like a preface, FAQ, instructions to authors of a journal or encyclopedia, etc. Having found nothing there, the human would, if applicable, check the dates for several well-known people who's dates are not in question, such as Isaac Newton or George II of Great Britain. Only after such efforts do not resolve doubts should sourcing circumstances (P1480)=unspecified calendar (Q18195782) be resorted to. It is inexcusable for a bot to add ambiguous dates to an item that already has unambiguous dates with citations to reliable sources. Jc3s5h (talk) 18:38, 20 December 2019 (UTC)

The main problem with Reinheitsgebot is that bug reports are never answered. Sometimes the problems are fixed, sometimes not. That’s not how bots should be operated. --Emu (talk) 10:14, 20 December 2019 (UTC)

The false edits [ https://www.wikidata.org/w/index.php?title=Q37388&diff=next&oldid=1079779129 continue]. Jc3s5h (talk) 18:25, 20 December 2019 (UTC)

The edits are not "false". The bot adds that "source X states this is the birth/death date". So what the bot adds is the truth. If that is the correct date in the correct calendar, it does not try to solve, and it should not.

Note that, if no birth/death date exists, the bot might add a (referenced) date, without specifying the calendar. I am happy to amend some qualifier that specifies "unknown calendar" if that helps; please point me to the "official" way of doing so. --Magnus Manske (talk) 09:25, 6 January 2020 (UTC)

Ah that's already in the above discussion. I'll look into it. --Magnus Manske (talk) 09:25, 6 January 2020 (UTC)

The fact that a source does not specify the calendar in immediate proximity to the date in a machine-readable manner does not mean it is an unspecified calendar. If the sources calendar policy can be discovered through a human reading a source, the calendar is not unknown. Through proper investigation, we can say the policy of "The Peerage" is to always start years on 1 January, but otherwise use whichever calendar, Julian or Gregorian, was in force for a birth or death that occurred in Britain. For births or deaths in other countries, further investigation would be needed.

When you screen-scrape a source that is intended to be read by a human, you, Magnus Manske, are responsible for the blunders your bot makes. Jc3s5h (talk) 14:52, 6 January 2020 (UTC)

In addition, "The Peerage" is a source created by one individual as a hobby. It seems to be well-done, but one could argue it isn't a reliable source and nothing at all should be added from that source. In any case, if a source that has been written by a group of professionals an published by a reputable publisher is already cited, no mention of information from "The Peerage" should be added. Jc3s5h (talk) 15:03, 6 January 2020 (UTC)

Unattributed proxy edits

Sorry if this has been discussed before but, for bots that proxy edits on behalf of some user (presumably logged in via OAuth), is there any policy about identifying the user in the edit summary? I see some RFPs that explicitly undertake this (e.g. QuickStatementsBot), whereas others do not (e.g. Reinheitsgebot). If this is considered to be good practice, should we add it to the general requirements for "statements adding bots"? For further discussion of the benefits of identifying the user, see this thread. Cheers, Bovlb (talk) 21:43, 18 March 2020 (UTC)

Also, this thread. Bovlb (talk) 21:47, 18 March 2020 (UTC)

@Bovlb: I don't think Reinheitsgebot edits on behalf of anybody but the operator? ArthurPSmith (talk) 17:24, 19 March 2020 (UTC)

@ArthurPSmith: I had the impression that Reinheitsgebot proxies edits from the mix'n'match tool that the botop does not take responsibility for, but it was not my intention here to start another discussion specifically on Reinheitsgebot, but rather to establish a general principle about proxying bots (that would guide us in any specific discussions). My proposal here is that either a botop is generally responsible for the edits of a bot, or the bot attributes those edits to an editor linked in the edit summary, and there is no middle ground. Cheers, Bovlb (talk) 17:32, 19 March 2020 (UTC) (typo fixed)

Your proposal sounds good to me! We probably need to gather other opinions somewhere though? ArthurPSmith (talk) 17:36, 19 March 2020 (UTC)

I thought this would be the best place to gather opinions about bot policy, but perhaps I should advertise it somewhere more central. Bovlb (talk) 19:34, 19 March 2020 (UTC)

This isn't directly about proxying per se, but en:Wikipedia:Bot_policy#Bots_operated_by_multiple_users says, in relevant part, Accounts used for approved bots that can make edits of a specific designated type, at the direction of more than one person, are not likely to be a problem, provided ... the Wikipedia user directing any given edit must always be identified, typically by being linked in the edit summary, and ...all bot operators must have the required skill and knowledge to operate the bot within community consensus.. Bovlb (talk) 19:41, 19 March 2020 (UTC)

OK. Here is a specific proposal to add to "Bot requirements":

Bots that proxy edits

In order for a bot to make edits on behalf of another user, for which the botop is not responsible, then: The user must be logged in via OAuth The user must be identified and linked in the edit summary The bot cannot be used to bypass a block

If this seems reasonable, would it need to be posted on Wikidata:Requests for comment? Bovlb (talk) 18:26, 20 March 2020 (UTC)

@Bovlb: So if a user is logged in via OAuth, then an application can use the OAuth tokens to make the edits directly as that user - for example Quickstatements generally does this. The case where the edits look like they come from the bot rather than the user are when for whatever reason the bot has "lost" the OAuth tokens (for example due to a system reset of some sort) but still wants to finish the batch of edits that the user provided. That also means maybe we don't need to worry about blocks - if the edits could be made as the user to start with, then they were not blocked and presumably the bot can continue to edit. Anyway, I would modify your first requirement to "The user must have logged in via OAuth to initiate or authorize the batch of edits". And yes an RFC with an announcement on Project Chat would probably be best. ArthurPSmith (talk) 18:06, 23 March 2020 (UTC)

@ArthurPSmith: "if a user is logged in via OAuth, then an application can use the OAuth tokens to make the edits directly as that user" A good point. When you put it like that, it raises the question of why we need bots that make edits on behalf of a user that are not make directly as the user. Is this, perhaps, just a legacy thing, that we have existing bots that are still doing things "the old way"? If this is the case, then we don't want to encourage it, but it might still be helpful to have an explicit policy about it.

"an RFC with an announcement on Project Chat would probably be best" OK, but I'd like to debug the proposal first before rushing to a !vote. Bovlb (talk) 18:28, 23 March 2020 (UTC)

@Bovlb: As I understand it, in the case of Quickstatements what happens is that a user (authentiatced via OAuth) initiates a "batch" which may have tens of thousands of planned edits, which then goes into a queue. As long as the Quickstatements server is still running, it retains those OAuth credentials and can make those edits as that user. However, if the server has to restart for some reason, it no longer has those OAuth credentials, but it still knows those edits were authorized by that particular user. It may also be that a number of weeks pass before the queued batch can be done, so even without a restart, the credentials may no longer be valid. Either way, if the edits are to be continued, then (as a convenience so users don't have to restart stalled batches via logging in again) the "Quickstatementsbot" takes over and runs these edits on behalf of the user. Now, that's Quickstatements; other bot edits may be handled quite differently... ArthurPSmith (talk) 18:36, 23 March 2020 (UTC)

@ArthurPSmith: Thanks for the background. I note that QuickStatementsBot (talk • contribs • logs) is currently blocked for "making edits without attributing them to the users responsible for them". This sort of thing is why I would like to see some explicit policy in this area. Cheers, Bovlb (talk) 18:41, 23 March 2020 (UTC)

Ah! Well, maybe this RFC isn't really needed if we're already following that policy? ArthurPSmith (talk) 18:48, 23 March 2020 (UTC)

@ArthurPSmith: Well, yes, although that block was a little controversial at the time and I just unblocked a bot that may be making unattributed proxy edits. I feel like it would be better to have a general principle to point to, rather than having to shoot from the hip on a case-by-case basis. Bovlb (talk) 20:33, 23 March 2020 (UTC)

In whatever case, I support the proposal of Bovlb as written. — regards, Revi 09:16, 25 March 2020 (UTC)

Suggestion: cannot → must not. --Matěj Suchánek (talk) 10:24, 25 March 2020 (UTC)

@Matěj Suchánek: Sorry to be so slow to respond. Saying "must not" here seems to place the onus on the blocked user not to use the bot to bypass the block (which is also true, but not relevant here). I said "cannot" to suggest that the bot owner be responsible for preventing use by blocked users. Maybe clearer as "The bot must not be able to be used to bypass a block". Bovlb (talk) 16:07, 11 August 2020 (UTC)

@Bovlb: I'd suggest to add the condition "The bot must not set the botflag for these edits". If edits are made by human users they should appear in the recent changes and be checked for vandalism. User:QuickStatementsBot and User:Reinheitsgebot already don't set the botflag, but I want to write it down. Pyfisch (talk) 12:45, 31 August 2020 (UTC)

Important: maintenance operation on September 1st

Read this message in another language

The Wikimedia Foundation will be testing its secondary data centre. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.

They will switch all traffic to the secondary data centre on Tuesday, September 1st 2020.

Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.

You will be able to read, but not edit, all wikis for a short period of time.

• You will not be able to edit for up to an hour on Tuesday, September 1st. The test will start at 14:00 UTC (15:00 BST, 16:00 CEST, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST, and in New Zealand at 02:00 NZST on Wednesday September 2).
• If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

• Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
• There will be code freezes for the week of September 1st, 2020. Non-essential code deployments will not happen.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. Please share this information with your community.

User:Trizek (WMF) (talk) 10:30, 31 August 2020 (UTC)

Important: maintenance operation on October 27

Please help translate to your language Thank you.

This is a reminder of a message already sent to your wiki.

On Tuesday, October 27 2020, all wikis will be in read-only mode for a short period of time.

You will not be able to edit for up to an hour on Tuesday, October 27. The test will start at 14:00 UTC (14:00 WET, 15:00 CET, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST, and in New Zealand at 03:00 NZDT on Wednesday October 28).

Background jobs will be slower and some may be dropped. This may have an impact on some bots work.

Know more about this operation.

-- User:Trizek (WMF) (talk) 09:25, 26 October 2020 (UTC)