The following discussion is an archived debate. Please do not modify it. Subsequent comments should be made in a new section. The result of the discussion was Approved.

Operator: — Carl (CBM · talk)

Automatic or Manually Assisted: Automatic

Programming Language(s): Perl

Function Summary: Make an announcement when a page is changed to policy or guideline.

Edit period(s) (e.g. Continuous, daily, one time run): daily

Edit rate requested: 2 edits per min

Already has a bot flag (Y/N): Y

Function Details: This script will keep a cache of which pages are tagged ((policy)) or ((guideline)). It will run once per day. When it notices a page has been upgraded to guideline, or from guideline to policy, it will leave an announcement on Wikipedia:VPP. When it notices a page has been downgraded, it will leave a note. So the control flow is to read the contents of the corresponding categories, compare and update a cache, and if needed make announcements on the village pump. I will use the "new section" method to post to the pump, which should avoid edit conflicts.

As an internal safeguard, if the bot believes it needs to make more than 5 announcements, it will not make any announcements. This is intended to prevent errors in the cache from generating spurious messages.

In order to reduce unneeded messages, a changed page has to be stable for an entire day before the bot will announce it again. The idea behind this is that the original announcement should be enough to let people know to put the page on their watchlist or otherwise pay attention to it. Thus, if page that is marked as a policy, announced, and then downgraded the next day, there will be no additional announcement.

Discussion[edit]

The output of the bot can be seen at User talk:VeblenBot/PolicyNotes. The code is written and tested. — Carl (CBM · talk) 23:19, 16 January 2008 (UTC)[reply]

Bot trial run approved for 50 edits. βcommand 16:07, 19 January 2008 (UTC)[reply]

Notification of Wikipedia:User page and Wikipedia:Version 1.0 Editorial Team.[edit]

When the change is in "response" to the announcement by the bot. Ie. the change have occurred since the last time the bot made an announcement about the page it's probably better if the bot updates the section it wrote to the previous time. If that section have been deleted then I think the bot should let the change pass quietly. Concretely; rather than Wikipedia:Village pump (policy)#Wikipedia:Version 1.0 Editorial Team/Assessment is no longer marked as a policy the bot should update Wikipedia:Village pump (policy)#Wikipedia:Version 1.0 Editorial Team/Assessment is marked as a policy to read(title nowiki'd to prevent section break.);

== Wikipedia:Version 1.0 Editorial Team/Assessment is marked as a policy ==

Wikipedia:Version 1.0 Editorial Team/Assessment (edit | talk | history | links | watch | logs) has recently been marked as a policy. This is an automated notice of the change. -- VeblenBot (talk) 19:02, 20 January 2008 (UTC)[reply]

The above change have been reverted by Kesh with the edit summary (Undid revision 185539614 by Simpsons fan 66 (talk) - I think you need to open a discussion for consensus, first) This is an automated notice of the change. -- VeblenBot (talk) 19:02, 20 January 2008 (UTC)[reply]

The change at Wikipedia:User page should go probably go unannounced since the removal of the relevant section from VPP was unchallenged. Taemyr (talk) 19:46, 21 January 2008 (UTC)[reply]

It's extremely difficult to do that sort of page parsing. I would rather use a system in which the bot simply assumes that if a page changes status on two days in a row, the second change is a response to the note. I don't want to try to parse page diffs, or parse the village pump text (not that it's a bad idea, just that I think it's more trouble to write reliable code for that than its worth).
So here's a proposal: the bot will keep a second cache, which lists all pages that were "announced" on the previous run. If a page should be announced, but was announced last time, it will not be announced again. But it will be put back in that cache, so if it is changed yet again on the third day, it still won't be announced again, and so on. Thus only pages that sit completely unchanged through at least one invocation of the bot (24 hours) will be announced when they change the next time. Is there anything I am missing there? — Carl (CBM · talk) 19:52, 21 January 2008 (UTC)[reply]
(Edit conflict) That would take care of the problem. But how difficult is it? Doing HTML scraping we would look for the content list which starts with <table id="toc" class="toc" summary="Contents"> from there we start counting <li class="toclevel-n">'s, where n is a digit, until we reach the relevant section or </table>. Since we have counted we now know the section number that we are interested in and we can use action=edit&section=that_number to get the wikitext of the section. This text should begin with the edit made with by the bot. If it does not then fail, if it does then any text after our bots edits are comments by other users that needs to be included. Since the bot is ignoring any of these comments we should introduce the new text between the old edits by the bot and any new edits. Of course this ought to get easier and better once the API is finalized. I have never programed Perl but the regexp's should be trivial.Taemyr (talk) 21:22, 21 January 2008 (UTC)[reply]
Yes, it's not severely difficult theoretically, but writing a reliable parser for wiki text is difficult in practice. As a minor point, section editing is not robust, because if a section above mine is removed then the section index changes. So one has to take the entire source, break it into sections, find the appropriate section, etc. I'm not claiming that is impossible to do, only that I don't see the benefit as worth the effort. I would rather just avoid multiple announcements about the same page, if they are disliked, by remembering which announcements have been made recently and not repeating them. The goal of the bot is to publicize these changes to draw attention to them, but not to give a full history of the changes of each page. — Carl (CBM · talk) 21:39, 21 January 2008 (UTC)[reply]
The following is from user talk:CBM:

A couple of suggestions (just passing by):

  1. The bot runs daily right? So if a change is made, I suggest the bot logs it but does not report it. Then, the next day, if the change has stood, that either means it has not been noticed or it has been accepted. Then the bot makes a post, so the community can decide which! (Advantage: if the change got reverted in the last day, no spam.)
  2. At the moment, the phrasing of the bot output suggests it is announcing a change in policy rather than reporting an edit (perhaps without consensus). Even with the above provision, it could be either. I suggest rewording the output so that it makes no assertion either way.

If these two suggestions are combined, it would probably not be necessary to keep a cache of changes reported by the bot, nor would it be necessary to vary the bot output depending on the situation. Geometry guy 20:08, 21 January 2008 (UTC) PS. Please feel free to cross-post to the bot request page if this suggestion is helpful.

This would still have the "churn" problem, just on a 2 day scale rather than a I day scale. That is, if the bot reports a change, and the change is undone, the bot would still report the reversion as an independent change, after a longer delay.
The idea to change the message to point out that this is a report of an edit, rather than an established change, is sound, and I'll (try to) implement that right away. — Carl (CBM · talk) 21:09, 21 January 2008 (UTC)[reply]
True, I guess you would need to keep track of reported changes. However, if a change is undone after a bot report, and this stands for a day, then there might even be no need to report the reversion at all. So the first idea cuts out spam in more than one way. Geometry guy 21:19, 21 January 2008 (UTC)[reply]

Second cache implemented[edit]

I implemented the second cache. So now a page must remain unchanged for one bot run before it can be announced on the next bot run. A page which changes each time the bot is run will only be announced the first time. I think the bot is ready for approval, unless there are other concerns. — Carl (CBM · talk) 17:32, 24 January 2008 (UTC)[reply]

Maybe I'm misunderstanding the requests above, but I think that this should have been reported. — madman bum and angel 17:51, 27 January 2008 (UTC)[reply]
The original change was announced [1]. Right now the bot has that page in its "announced last time" cache, which means that any changes to the page will not be announced on the next bot run today. Also, the bot only runs once per day (around 18:50 UTC), so even without the cache it could not have reported that change yet.
A changed page has to be stable for an entire day before the bot will announce it again. The idea behind this is that the original announcement should be enough to let people know to put the page on their watchlist or otherwise pay attention to it. — Carl (CBM · talk) 17:58, 27 January 2008 (UTC)[reply]
I see; I had not realized that the bot had not run since then -- I thought it had missed it. It will announce it on its next run, then? At some point there really should be some kind of followup, as even if administrators should be watching developments, often they won't be or they'll be overwhelmed by the other changes in their watchlists. — madman bum and angel 18:08, 27 January 2008 (UTC)[reply]
I think it's a balancing act between no announcements at all and so many announcements that people feel as if they are being spammed. I'm willing to consider whatever functionality there is a broad interest for, as long as I don't have a mob of people complain that I am spamming.
So here are two situations. What sort of followup should be bot give in each case?
  1. A page is marked as a guideline, bounces back and forth for a week, and ends up marked as a guideline.
  2. A page is marked as a guideline, bounces back and forth for a week, and ends up back where it started, not a guideline.
In the first case, it definitely makes sense not to have a second announcement. The original announcement said the page is a guideline, and it is. In the second case, I'm not sure that the bot can give a good summary of the (probably complex) discussion that happened. I could change the original announcement to say something like "Tnterested editors should participate in the discussion on the corresponding talk page." to let people know the recommended course of action. — Carl (CBM · talk) 18:21, 27 January 2008 (UTC)[reply]
The seemingly duplicate announcement the bot made today was because of a change in the library that the bot uses. It used to be that apostrophes were represented as an html entity &#039;, but now they are just apostrophes. The policy script had no way to know that was what happened. — Carl (CBM · talk) 19:07, 27 January 2008 (UTC)[reply]
To be honest, I don't know, and I think we should have more input here. Personally, if I think it bounced back and forth for a week, some contributors would need to be blocked for edit warring, but that's just me. I think if WPU/Article guidelines remains a not-guideline for a day or two (which is extremely likely; it never should have been marked as such in the first place), there should be some sort of followup to the bot's original announcement. — madman bum and angel 03:14, 28 January 2008 (UTC)[reply]
I think the point is that this followup should be provided by human editors. Having a bot report each change in an ongoing edit-war to the village pump will annoy people. Taemyr (talk) 10:29, 28 January 2008 (UTC)[reply]

Simple tasks, bot works, rubber stamp says approved goes here. Do you want flags with that? -- Tawker (talk) 04:39, 4 February 2008 (UTC)[reply]

Thanks. The bot already has a flag. — Carl (CBM · talk) 04:44, 4 February 2008 (UTC)[reply]
Mere formality, it looks like Tawker has approved.  Approved. Soxred93 | talk bot 21:40, 29 February 2008 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section.