Wikipedia:Bots/Requests for approval/Joe's Null Bot 2
- The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was
Approved.
Operator: Joe Decker (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)
Time filed: 08:12, Tuesday February 26, 2013 (UTC)
Automatic, Supervised, or Manual: Automatic
Programming language(s): PERL
Source code available: Will be available
Function overview: Purge WP:Main Page once per 15 minutes
Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Purging_Main_Page_at_regular_intervals, also (as background) Wikipedia:Village_pump_(proposals)/Archive_97#How_to_add_TAFI_to_the_main_page.3F
Edit period(s): 1 purge per 15 minutes
Estimated number of pages affected: One
Exclusion compliant (Yes/No): No (The proposed "bot" only addresses a single page...)
Already has a bot flag (Yes/No): Yes
Function details (and background): Background: WP:TAFI, "Today's Article for Improvement", has consensus from the community for some Main Page real estate, an approval which may greatly increase the visibility of the project and the project's targeted articles. As a result, they've opted for a small list of randomly ordered articles in order to distribute the attention of editors across those artilces, reducing edit conflicts. (See:Wikipedia:Village_pump_(proposals)/Archive_97#How_to_add_TAFI_to_the_main_page.3F.)
"Randomly ordered", of course, conflicts with caching. Cached HTML doesn't vary, unless you do something clever. But what?
In the discussion at Wikipedia:Bot_requests#Purging_Main_Page_at_regular_intervals, editors discussed implementation alternatives (client-side JS vs. a regular purge), and seemed to prefer the latter out of concerns for client-side dependencies.
Not much to the actual implementation, again, a basic purge 4x/hour.
Discussion
[edit]Just to clarify, this is purging as in
&action=purge, is that correct? It would seem to be a non-controversial bot task that could be speedily approved. Thanks. 64.40.54.87 (talk) 01:48, 3 March 2013 (UTC)
- Just read the BotReq and one purge every 15 minutes seems to be reasonable, but I am no expert in high-traffic cached pages. Cheers. 64.40.54.87 (talk) 02:00, 3 March 2013 (UTC)
- As discussed at Wikipedia:Bot requests#Purging Main Page at regular intervals, a cache purge causes a page to be rebuilt, after which the same version is sent until the cache is purged again. Whether the page is requested zero times or 100,000 times in the following 15 minutes, it's been rebuilt only once. In other words, the amount of traffic should have no bearing on the server-side impact. —David Levy 17:47, 4 March 2013 (UTC)
- Thanks for the clarification. 64.40.54.87 (talk) 11:21, 5 March 2013 (UTC)
- As discussed at Wikipedia:Bot requests#Purging Main Page at regular intervals, a cache purge causes a page to be rebuilt, after which the same version is sent until the cache is purged again. Whether the page is requested zero times or 100,000 times in the following 15 minutes, it's been rebuilt only once. In other words, the amount of traffic should have no bearing on the server-side impact. —David Levy 17:47, 4 March 2013 (UTC)
- Has someone ran this by a WM engineer to ensure that it is "fine" with them? --Izno (talk) 16:44, 6 March 2013 (UTC)
- Approved for trial (2 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete., poke me on my talk page once this is complete :) (please make sure your bot checks maxlag) ·c· Talk To Me! 16:47, 6 March 2013 (UTC)
- Starting trial now (from my laptop in a hotel room, but I'll make the logistics involved work somehow). I essentially machete'd the task 1 code down, so it's got maxlag support. --Joe Decker (alt) (talk) 04:38, 7 March 2013 (UTC)
- Comment. It doesn't seem like this really solves the goal of avoiding edit conflicts. It just means the edit conflicts move to a different article every 15 minutes. Why not make it actually random with Javascript like we did for the 2008 election Featured Article. This would also save our servers from a lot of unnecessary work. Kaldari (talk) 21:42, 7 March 2013 (UTC)
- I've seen no indication that the added server-side work would be non-negligible, but as I commented in the now-archived bot request discussion, the JavaScript method seems worth considering (and I'd like to see a functional mockup). —David Levy 22:06, 7 March 2013 (UTC)
- Addshore: I'll leave you a note on your talk page, but the 48 hours are more or less up. No side-effects or problems identified. Hard to tell if it was working, of course, but it worked fine when pointed at a test file, so... (I really don't have a personal stake in how this gets dealt with, for what it's worth, just trying to lend a hand.) --j⚛e deckertalk 01:59, 9 March 2013 (UTC)
- I've seen no indication that the added server-side work would be non-negligible, but as I commented in the now-archived bot request discussion, the JavaScript method seems worth considering (and I'd like to see a functional mockup). —David Levy 22:06, 7 March 2013 (UTC)
- Comment. It doesn't seem like this really solves the goal of avoiding edit conflicts. It just means the edit conflicts move to a different article every 15 minutes. Why not make it actually random with Javascript like we did for the 2008 election Featured Article. This would also save our servers from a lot of unnecessary work. Kaldari (talk) 21:42, 7 March 2013 (UTC)
- Starting trial now (from my laptop in a hotel room, but I'll make the logistics involved work somehow). I essentially machete'd the task 1 code down, so it's got maxlag support. --Joe Decker (alt) (talk) 04:38, 7 March 2013 (UTC)
Approved. ·Add§hore· Talk To Me! 11:41, 11 March 2013 (UTC)- The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.
