User talk:Rich Farmbrough/Archive/2017 January

Previous · Index · Next

"Listas" edits

Hi. I filed phabricator:T154346 just now after noticing your recent "listas" edits such as these. I think duplicating default category sort keys between subject-space pages and talk pages is kind of crazy and we should stop doing it once there's a better/more automated functionality available. --MZMcBride (talk) 01:43, 31 December 2016 (UTC)

It's an interesting question. There may be circumstances where the two should be different, but I'm not sure that anyone cares enough. I was also considering whether template magic could pick up the DEFAULTSORT in the same way it can pick up redirectness - this may be one of the methods you mention. User:JimCubb did a great job on maintaining these for several years, alas he is no longer with us.

In terms of the number of edits, catching up a five year backlog has been tedious work, but I am hoping that we can be smarter going forward and add living and listas when the banner is added. All the best: Rich Farmbrough, 07:30, 31 December 2016 (UTC).

The exceptions are probably too few. This phab ticket was a brilliant idea. -- Magioladitis (talk) 12:06, 31 December 2016 (UTC)

I think we would keep the listas template parameter available for overrides and exceptions, but the (implicit) default value of the parameter would be the subject-space's default category sort key. --MZMcBride (talk) 14:16, 31 December 2016 (UTC)

Indeed! (This is the approach I like - the vast majority just works, only the exceptions have elaborations.) All the best: Rich Farmbrough, 14:35, 31 December 2016 (UTC).

Happy 2017!

Wishing good health and happiness as we start the new year! --Rosiestep (talk) 19:22, 1 January 2017 (UTC)

Thank you! All the best: Rich Farmbrough, 20:45, 1 January 2017 (UTC).

Happy New Year Rich Farmbrough!

Happy New Year!

Rich Farmbrough,
Have a prosperous, productive and wonderful New Year, and thanks for your contributions to Wikipedia.

--Rubbish computer (HALP!: I dropped the bass?) 19:31, 1 January 2017 (UTC)

Looking forward to it! You too! All the best: Rich Farmbrough, 20:45, 1 January 2017 (UTC).

Happy New Year, 2017 Rich

	To an awesome Wikipedian
	Another year; another edit. Keep up the good work. Best wishes 7&6=thirteen (☎) 20:51, 1 January 2017 (UTC)

Many thanks! This year is going to be busy! All the best: Rich Farmbrough, 20:55, 1 January 2017 (UTC).

Happy New Year, Rich Farmbrough!

Happy New Year!

Rich Farmbrough,
Have a prosperous, productive and enjoyable New Year, and thanks for your contributions to Wikipedia.
Donner60 (talk) 10:03, 2 January 2017 (UTC)

   Send New Year cheer by adding {{subst:Happy New Year fireworks}} to user talk pages.

Happy New Year Rich Farmbrough!

Happy New Year!

Rich Farmbrough,
Have a prosperous, productive and wonderful New Year, and thanks for your contributions to Wikipedia.

Rubbish computer (HALP!: I dropped the bass?) 10:35, 2 January 2017 (UTC)

Wikidata weekly summary #242

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • Open requests for adminship: יונה בנדלאק, Pyb

• Events/Press/Blogs
  • Next IRC office hour on January 5th
  • Past: we were at 33c3
  • Scaling OpenStreetMap with Wikidata knowledge
  • 2016 – A busy year for Gene Wiki and WikiData

• Other Noteworthy Stuff
  • Wikidata and the celebrity deaths of 2016 on Buzzfeed
  • Welsh Wikipedia has some 16,000 lists regularly maintained from Wikidata

• Did you know?
  • Newest properties: INSEE arrondissement code, INSEE countries and foreign territories code
  • Query examples:
    • Filtered timeline of Spotify artists
    • Paintings of the Eiffel Tower by Robert Delaunay (source)
    • Ratio of “famous” (≥25 sitelinks) people’s deaths since 2000 (source)
    • Things with coordinates on globes other than Earth (source)
  • Newest WikiProjects: US Virgin Islands
  • Newest external tools: "Descriptioner" - Tool to add descriptions batchwise
  • Newest database reports: Popular items without claims, Portuguese-language films without articles in Portuguese

• Development
  • When a {{#statements:…}} property couldn't be resolved, a tracking category will be added (phab:T50799)
  • Rewrote Special:NewItem and all other Special:New… pages to use OOUI error handling (phab:T150205)
  • Getting ready the basic Lexeme prototype (phab:T146662)
  • Continued work on federation basics (phab:T149580)
  • Release version 1.0.0 of the DataTypes component
  • Enjoying the holidays and getting ready for this year's challenges. Hope you do to :)

You can see all open tickets related to Wikidata here.

• Monthly Tasks
  • Hack on one of these.
  • Help develop the next summary here!
  • Contribute to a Showcase item
  • Help translate or proofread pages in your own language!
  • Help merge identical items across Wikimedia projects.
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals - proposals needing attention

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 14:55, 2 January 2017 (UTC)

Photo request for Lebanon PA

Why did you remove the places category from the photo request at Talk:Lebanon, Pennsylvania? JustinTime55 (talk) 15:05, 3 January 2017 (UTC)

Because Category:Wikipedia requested images of places is "intended to organise other categories and not for specific article talk pages. Using ... one of the sub-categories or using the in= parameter implies it is a photograph request of a place." All the best: Rich Farmbrough, 22:52, 3 January 2017 (UTC).

Arbitration Case opened

You recently offered a statement in a request for arbitration. The Arbitration Committee has accepted that request for arbitration and an arbitration case has been opened at Wikipedia:Arbitration/Requests/Case/Magioladitis.

Evidence that you wish the arbitrators to consider should be added to the evidence subpage, at Wikipedia:Arbitration/Requests/Case/Magioladitis/Evidence. Please add your evidence by January 17, 2017, which is when the evidence phase closes.

You can also contribute to the case workshop subpage, Wikipedia:Arbitration/Requests/Case/Magioladitis/Workshop.

For a guide to the arbitration process, see Wikipedia:Arbitration/Guide to arbitration.

If you no longer wish to receive case notifications for this case you can remove yourself from the notifications list here.

For the Arbitration Committee, Amortias (T)(C) 22:52, 3 January 2017 (UTC)

Reference errors on 5 January

Hello, I'm ReferenceBot. I have automatically detected that an edit performed by you may have introduced errors in referencing. It is as follows:

• On the Schizognathina page, your edit caused an unsupported parameter error (help). (Fix | Ask for help)

Please check this page and fix the errors highlighted. If you think this is a false positive, you can report it to my operator. Thanks, ReferenceBot (talk) 00:16, 6 January 2017 (UTC)

Wikidata weekly summary #242

Here's your quick overview of what has been happening around Wikidata over the last week.

• Events/Press/Blogs
  • Current: Wikimedia Dev summit in San Francisco (January 9-11th) If you are there, come and meet our developers and volunteers!
  • Upcoming: WikiIndaba, January 20-22th, Accra, Ghana
  • Wikidata used to connect people giving interviews for the oral history project at the computer history museum

• Other Noteworthy Stuff
  • Video: how institutions can donate data to Wikidata, explained in a cartoon
  • Category:Articles with infoboxes completely from Wikidata on English Wikipedia
  • Mix'n'match encountered some problems with labels and descriptions, some of them are now fixed, cf post from Magnus
  • Wikidata-powered citation lists with citation.js
  • How to use objects from OpenStreetMap in Wikidata
  • Video: Navigating a cemetery using Spotify and Wikidata (by Magnus Sälgö)

• Did you know?
  • Newest properties: eBird taxon ID, Victorian Heritage Database ID, Debian package, FIFA country code, time signature, angular resolution, vehicle normally used, people or cargo transported, AELG ID, VGMDb artist ID, ERIH PLUS ID, biological variant of, parent cell line, Publons Publication ID, Social Networks Archival Context ID, Electronic Enlightenment ID, INCAA film rating, as.com athlete ID, ArbetSam ID, Natura 2000 site ID, Polish cultural heritage register number
  • Query examples:
    • Birth place of Academy Award winners
    • Neujahrskonzert with conductor by country and age (source)
    • 9 species named after the President of the USA (source)
  • Newest external tools: R wrapper for WDQS API (by Mikhail Popov), Wikidata authority file mapping tool (by Jakob Voß)
  • Newest database reports: list of episodes of Desperate Housewives (in English and German)

• Development
  • Log of our last IRC office hour
  • This week, most of the developers are at the Dev Summit hacking stuff and doing great things!
  • Continued working on "federation" – support for multiple Wikibase repositories (phab:T76007)
  • New dimensions for unit conversion in the query service (phab:T150881)
  • Fixed a timing issue that can happen when using the property suggester (phab:T115267)
  • Still investigating an issue in which the "save" button stays disabled, as reported in December
  • We may remove the sliding animation when using the date, geo, monolingual, and quantity experts (gerrit:330145). The preview popup may now cover parts of the page. Please try it at wikidata.beta.wmflabs.org and tell us what you think on our contact page.

You can see all open tickets related to Wikidata here.

• Monthly Tasks
  • Hack on one of these.
  • Help develop the next summary here!
  • Contribute to a Showcase item
  • Help translate or proofread pages in your own language!
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Add statements to items without
  • Help with one of the bot requests
  • Help merge identical items across Wikimedia projects.

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 14:00, 9 January 2017 (UTC)

Request for a custom list of pages

Hi Rich,

I'm looking to try and sort some of the many "next" redirects and think a list of a subset of them would be a good place to start. I don't know how to generate this, but I think it is the sort of thing you can do. If so, please could you to generate a list of all redirects that:

• contain the word "next"; and
• contain at and least one of the words "assembly", "by-election", "by-elections", "byelection", "byelections", "debate", "debates", "election", "elections", "parliament", "parliamentary", "president", "presidential", "season", "senate", "session" or "spill"; and
• target a page that does not have the word "next" in the title.

(all case insensitive) And post the result to a new page in my userspace, ideally as a sortable table with a column for the redirect, a column for the target, and a column for the date of the last revision (this is the least important).

Thanks, Thryduulf (talk) 19:13, 10 January 2017 (UTC)

Y Answered on user's talk page. All the best: Rich Farmbrough, 22:55, 11 January 2017 (UTC).

FRS

What's this about Rich? Hawkeye7 (talk) 10:07, 12 January 2017 (UTC)

Fellows of the Royal Society who do not have articles. Note they are all men, as all the women have been covered. All the best: Rich Farmbrough, 12:28, 12 January 2017 (UTC).

Oh. Well, you can strike William Richard Joseph Cook off your list. Hawkeye7 (talk) 19:00, 12 January 2017 (UTC)

Thanks! And indeed quite a few others! All the best: Rich Farmbrough, 23:53, 14 January 2017 (UTC).

The Signpost: 17 January 2017

• From the editor: Next steps for the Signpost

• News and notes: Surge in RFA promotions—a sign of lasting change?

• Interview: What is it like to edit Wikipedia when you're blind?

• In the media: Year-end roundups, Wikipedia's 16th birthday, and more

• Featured content: One year ends, and another begins

• Arbitration report: Concluding 2016 and covering 2017's first two cases

• Traffic report: Out with the old, in with the new

• Technology report: Tech present, past, and future

• Recent research: Female Wikipedians aren't more likely to edit women biographies; Black Lives Matter in Wikipedia

* Read this Signpost in full * Single-page * Unsubscribe * MediaWiki message delivery (talk) 10:39, 17 January 2017 (UTC)

Wikidata weekly summary #243

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • New request for comments: Badge for templates that work with Wikidata?

• Events/Press/Blogs
  • Wikimedia Foundation receives $3 million grant from Alfred P. Sloan Foundation to work on structured data for Commons
  • EPA CompTox Dashboard IDs in Wikidata
  • Data donation: 128K of Social Networks Archival Context IDs, matched to Wikipedia articles, and imported using P3430. Thanks, University of Virginia!
  • Past: Wikipedia Day 2017, NYC

• Other Noteworthy Stuff
• Discussion about the use of values from Wikidata in the English Wikipedia

• Did you know?
  • Newest properties: legal status (medicine), basic reproduction number, muscle insertion, muscle origin, pregnancy category, minimal incubation period in humans, maximal incubation period in humans, normal respiratory rate, bite force quotient, name shares origin with, VGMDb album ID, Europeana Fashion creator ID, Parks & Gardens UK Record ID, base Mémoire reference, Aftonbladet topic ID, Songkick Artist ID, Nihon Tarento Meikan ID, PSA Worldtour ID, SANU member ID, Ubuntu 16.10 package, VICNAMES Place ID, wikiskripta id, Woodland Trust wood ID, WTA tennis tournament ID, National Inventors Hall of Fame ID, Inventario Sculture - Polo Museale Fiorentino, Israeli CBS municipal ID, maximum frequency of audible sound, medicine marketing authorisation, Fedora package, FAMA work ID, designated as terrorist by, colonel-in-chief, Euring number, CNC authorization number, case fatality rate, ATP tennis tournament ID, CircleID, Arch package, IPI base code, inferred from, nighttime view, season of, NSW Heritage database ID, stepparent, mirrors data from, FIDAL ID, Cinema of Israel ID
  • Query examples:
    • People without gender, but with photo (~2500 items)
    • Gallery of cheese varieties and origin
    • Taxa with more female than male individuals (source)
    • Scatter chart of river watershed area (in km²) over length (in km), now using normalized unit support (source)
  • Newest database reports: lighthouses at night

• Development
  • Attended the Wikimedia Developer Summit to talk about a lot of things (including editing Wikidata from Wikipedia directly, back-end work for structured data support for Commons - specifically Multi Content Revisions, ideas for improvements to the query service)
  • Final touches to get ArticlePlaceholder pages ready for search engine indexing
  • Continued working on "federation" – support for multiple Wikibase repositories (phab:T76007)
  • Clickable prototype for client editing is finally in the works!

You can see all open tickets related to Wikidata here.

• Monthly Tasks
  • Hack on one of these.
  • Help develop the next summary here!
  • Contribute to a Showcase item
  • Help translate or proofread pages in your own language!
  • Help fixing the most important constraint violations
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals - proposals needing attention

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 15:46, 17 January 2017 (UTC)

Magioladitis workshop page

Hi Rich - could you move your edit here to the "Comment by others" section please? Thanks. Doug Weller talk 17:04, 18 January 2017 (UTC)

Netanyahu (disambiguation) listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Netanyahu (disambiguation). Since you had some involvement with the Netanyahu (disambiguation) redirect, you might want to participate in the redirect discussion if you have not already done so. --Nevé–selbert 23:45, 19 January 2017 (UTC)

Trump image moratorium

Hey Rich, re [1], did you intentionally not !vote on the proposal itself? ―Mandruss ☎ 13:21, 22 January 2017 (UTC)

Also your comments seem closer to 3 than to 2, since BRD involves discussion. ―Mandruss ☎ 15:35, 22 January 2017 (UTC)

Suggesting that the new image should automatically be installed, on the basis that there is not likely to be an objection. All the best: Rich Farmbrough, 19:29, 23 January 2017 (UTC).

I still don't perceive your position on the moratorium proposal (parent section), so I'll assume you're abstaining. ―Mandruss ☎ 15:29, 24 January 2017 (UTC)

Wikidata weekly summary #244

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • New administrator: Pyb is now admin on Wikidata!

• Events/Press/Blogs
  • Wikidata: the new hub for cultural heritage
  • Past: WikiIndaba, Ghana
  • Upcoming: FOSDEM, Brussels, February 4-5th

• Other Noteworthy Stuff
  • Coordinates on Russian Wikipedia now link to maps generated with the Kartographer extension. The map includes the location outline, if that object exists in OpenStreetMap (OSM) with a corresponding Wikidata ID (ways and relations only, not nodes). Example: w:ru:Зальцбург (click coordinates in the upper right corner, or in the infobox on the side). If you create a Wikidata item about a specific administrative area, building, or other physical individual object which appears on maps, then please add the Wikidata ID to the relevant object in OSM, using key:wikidata= (here's how to contribute to OSM).
  • QuickStatements V2 can now run your commands in the background, no need to keep the browser tab open anymore
  • List of churches generated from Wikidata on Cymraeg Wikipedia

• Did you know?
  • Newest properties: ZNIEFF Code, teams classification by time, cycling teams classification by points, FilmPolski.pl ID, points classification, legal status (medicine), basic reproduction number, muscle insertion, muscle origin
  • Query examples:
    • Tide mills in France (source)
    • Wind mills in Paris (source)
    • Mathematical formulae containing HTML escapes (source)
    • Fire stations in Paris (source)

• Development
  • Created a new Special:EntityPage, needed for federation (phabricator:T153499)
  • Sitelink "name" and "badges" in diffs are now translated (phabricator:T111016)
  • Worked on finalizing mockups for editing Wikidata from Wikipedia and co. Now working on the click-dummy for it so we can try it with you.
  • Last touches for automated sitelinks for Wiktionary.
  • A ton of refactoring needed for Wiktionary support.
  • More research on improving our input widgets (for example URL and date).

You can see all open tickets related to Wikidata here.

• Monthly Tasks
  • Hack on one of these.
  • Help develop the next summary here!
  • Contribute to a Showcase item
  • Help translate or proofread pages in your own language!
  • Help merge identical items across Wikimedia projects.
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals - proposals needing attention

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 15:55, 23 January 2017 (UTC)

Nomination for deletion of Template:Fact-now

Template:Fact-now has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Pppery 20:16, 26 January 2017 (UTC)

'Cosmetic' changes ARE a significant wiki-sociological issue... clear definition needed

-2 Introducing a typo or style error

-1 Making a non-rendering error

+0 Neutral point is here

+1 Fixing a non-rendering error

+2 Fixing a typo or style error

Rich, I am observing the arbcom case over whether unblocking one's own bot is tool abuse, and on whether "cosmetic" has a meaning or not. Although I would agree that your rough scale is a good start, it fails to cover the nuances. I suggest expanding your chart, with some of the nuances spelled out.

For instance, one of the apparently-really-irksome areas is bot-edits which make changes to template-names that avoid redirects (aka 'template bypass' which sounds like some kind of medicine-related surgical procedure to me), thereby saving a few CPU cycles of server-load for the WMF, and a few milliseconds of pageload-time for the readership, plus apparently helping bots that don't properly understand redirects 'work' as well as keeping the namespace 'clean' for devs who prefer the 'official' nomenclature be a bot-enforced naming-convention. These types of edits are clearly 'non-rendering' in the sense that nothing visually is modified as far as the readership is concerned, but there *is* a reader-detectable improvement in site-responsiveness, at least theoretically. In practice, most of the response-time improvement is *aggregate* from performing thousands and thousands of such optimizations... just performing a handful of template-de-redirection-edits, will not noticeably improve pageload-times without extremely precise measurement-regimes... and indeed, just the average noisy-internet-traffic-environment would probably make a handful of template-de-redirection-edits be unmeasurably useful.

In such cases, dozens of pedantic-optimization-edits with no measurable impact, I would argue that we are no longer talking about *helpful* edits, we are talking about *faux* optimization which makes programmers feel better, and boosts their editcountitis as wikipedians, but in reality does not have any measurable impact on the readership. (One could still argue the coding-convention angle or the helping-bots-that-do-not-grok-redirects-angle but those are weaker arguments.) And indeed, 'template bypass' type of editing *does* have a measurable impact on other wikipedians: the handful of pedantic edits that make changes to the template-name, such that it is a direct link rather than a redirect, may well be perceived as a nuisance (watchlist-spam).

Now, the situation is qualitatively different, when instead of talking about a *handful* of changes here and there, we are talking about a bot which makes thousands or millions of such changes, across the 'pedia. From the perspective of the readership, such massive edits have no *visible* impact aka they are non-rendering, but they definitely have a *visceral* impact because wikipedia pageloads are faster (in a statistically-measurable way that exceeds the noise-floor-threshold at least -- though quite possibly certain cases also in a human-measurable "this complex page used to take a few seconds to render and now it loads nigh-instantaneously"), and more important to my mind, such widespread automated changes will tend to make wikipedia.org generally more responsive, server-expenses generally lower, free up developer-time and donation-bucks for other thing (i.e. there is an opportunity cost of *not* performing such bot-style performance-optimizations and wiki-markup-sanitizations).

But from the perspective of watchlist-spam (which is no longer 'perceived' but quite real now that we're talking thousands of edits implemented via bots), these bot-style performance-optimizations are well into WP:BADIDEA territory, or at least, some folks in the anti-vandalism areas (and other heavily-watchlist-reliant sectors) perceive it thataway. In the situation where there were a *handful* of edits being made, there was some nuisance-level watchlist-spam, and no measurable gain in pageload times. In the situation where there are thousands if not millions of bot-automated performance-optimizations, which "theoretically" improve sitewide response-times and "hypothetically" free up donationbucks and devtime for unspecified other beneficial goals... we are talking about a LOT of watchlist-spam. Constant watchlist-spam, year after year after year. Hence the desire to impose WP:BURO and the desire to strip bits and the desire to sanction with "thou shalt not use automated tools" methinks.

So this specific issue, whether it is a 'cosmetic' edit to convert from {{citation}} to instead say {{cite}} and similar, and whether an *individual* edit of that sort has a non-negligible value, is fairly complex. Any individual edit like that has an infinitesimally tiny value, in terms of pageload times and server CPU cycles and WMF donation bucks and template-dev-mental-effort-plus-coding-workarounds. Thousands or millions of such edits, in aggregate, *do* add up to have non-negligible positive impact on the readers (complex pageloads && sitewide responsiveness) and on the project (more devtime && fewer serverUpgrades)... but there is a tradeoff being made, due to the increase in watchlist-spam! Which is only really noticed by people that are pushing the envelope with their watchlists, such as anti-vandalism folks who have thousands and thousands of watched-pages.

Probably in the long run, the 'correct' solution will involve 1) putting some actual responsiveness/pageloadtime metrics in place, wherein bots are programmed so at to perform A/B type editing, and the "control group" versus the "experimental group" of pages are actually TESTED to see what kind of performance-gains are actually being achieved, and 2) fixing the way watchlists work under the hood, so that bot-edits made by admins can be 'hidden' (i.e. the watchlist does not display bot-edits by default but can unhide them iff needed), as well as the more difficult-to-implement fix where bot-edits can also be 'ignored' if the wikipedian in question prefers (i.e. their watchlist will function as if the bot-edits did not exist in terms of whether a page has been 'edited' or not and which username was the 'most recent editor').

In the short run, though, I think the key task is to carefully and precisely define what is meant by 'cosmetic edit'. There are some edits which are 'cosmetic' in my opinion, but have an ever-so-slight visual alteration to the rendered page, though perhaps only detectable with a microscope: converting from http -> https for instance, which alters tooltips displayed to the readership, and iff they click, alters the address-bar, too. There are also hypothetical edits (not sure if any bot is tasked with this) such as the mostly-hypothetical-font-rendering-difference between saying E=MC² versus saying E=MC², which I would also consider in the "cosmetic edit" basket although pedantically it could have a rendering-impact at the pixel-per-pixel-exactness level.

Compare that situation with a (hypothetical) bot that converts from entity-refs to unicode or vice versa, aka E=MC² versus saying E=MC² vs E=MC² where by definition there is no rendering-change, but there very much *is* a potential pageload-time and render-time change (two utf8-bytes transmitted versus five), and very much *is* an actual difference in ease-of-editing (average wikipedian can type '²' or the mnenonic-equivalent '²' but does not know offhand how to type '²' without pulling up charmap or a similar app).

Some of the specific complaints in the arbcom case, revolve around whether it is "cosmetic" for a bot to perform template-bypass-work ('broadly construed'), whether adding 1= during such a template-bypass-edit does or does not make the edit 'non-cosmetic' in some sense, and whether removing unused template params (another type of server-performance and reader-pageload operation) counts as 'cosmetic' or not. And there is longstanding consensus that "only adding or removing some white space, moving a stub tag, converting HTML to Unicode [see my 'hypotheticals' above], or removing underscores from links" are something best batched up with more substantial changes, because doing them alone is a watchlist-nuisance (and causes view-history clutter, and increases server-load for little gain, and so on). Redirect-bypass-optimization, has also been added to that list, albeit only since 2010 rather than "since forever".

So here is what I am suggesting, as a bit more complete of a picture:

–2.0 Introducing a typo or style error

–1.8 millions of reverted-changes that ARE undone

–1.6 thousands of reverted-changes that ARE undone

–1.4 hundreds of reverted-changes that ARE undone

–1.2 dozens of reverted-changes that ARE undone

–1.0 Making a non-rendering error

–0.8 millions of nuisance-changes that CAUSE grumbling but are NOT undone

–0.6 thousands of nuisance-changes that CAUSE grumbling but are NOT undone

–0.4 hundreds of nuisance-changes that CAUSE grumbling but are NOT undone

–0.2 dozens of nuisance-changes that CAUSE grumbling but are NOT undone

–0.0 Neutral point is here (nuisance)

+0.0 Neutral point is here (pedantry)

+0.2 millions of pedantic-optimizations which have no MEASURABLE performance impact

+0.4 thousands of pedantic-optimizations which have no MEASURABLE performance impact

+0.6 hundreds of pedantic-optimizations which have no MEASURABLE performance impact

+0.8 dozens of pedantic-optimizations which have no MEASURABLE performance impact

+1.0 Fixing a non-rendering error

+1.2 millions of justified-optimizations which improve sitewide performance

+1.4 thousands of justified-optimizations which improve sitewide performance

+1.6 hundreds of justified-optimizations which improve sitewide performance

+1.8 dozens of justified-optimizations which improve sitewide performance

+2.0 Fixing a typo or style error

Note specifically that +1.8 is *dozens* of changes that cause measurable sitewide performance, as distinctly Moah Betterer than +1.2 which requires millions of changes (higher nuisance-factor). Similarly, -1.8 millions of annoyed-enough-to-revert changes very likely lead to drama, and thus are considerably more problematic than mere -1.2 dozens of changes-followed-by-dozens-of-reverts. We could also include some numeric rankings for *serious* WP:DRAMA such as -9.9 for 'automated edits which result in an arbcom case' perhaps.... Tweaks and improvements and rewrites and cuts are most welcome, of course, to my 'deathless prose' shown here  :-)

p.s. I am sympathetic with your plea for a WP:LONGTAIL exception, and suggest that perhaps there ought to be 'WP:BOTFRIDAY' for a one-minute-wall-clock-timespan once a month, at the lowest editing-by-humans point in the day (and week) which are chosen... and that during that brief timespan only, specially-approved bots are permitted to act like Bots Gone Wild and update as many articles as they wish, strictly within the imposed deadline, including 'merely cosmetic' changes and other such things. If this scheme is accepted, the initial one-minute-timespan could be subject to ongoing discussion, sometimes getting increased to handle backlog, sometimes getting decreased so that the bot-owners will triage and prioritize only the highest-value edits. But that is probably not a scheme that we want *arbcom* imposing on the community methinks :-)

By contrast, very likely arbcom *will* be imposing a specific 'legal' interpretation of the exact meaning of WP:COSMETICBOT when the outcome of this arbcom case is finalized, and I would like it to be a correct and pragmatically-useful interpretation/definition of the term, with all nuance required. Best, 47.222.203.135 (talk) 14:48, 27 January 2017 (UTC)

That is a very wide ranging and thoughtful response. Of course my initial scale was designed to be a rough ordering of individual edits (and, perhaps, to provoke thought).

Certainly there is a cost to each edit, and this has the effect of sliding the zero point - one can imagine a similar thing in paper publishing, which is why gummed errata slips exist.

As far as "causing grumbling" is concerned, there are two types of grumbling, justified and unjustified. While we may not wish to provoke even the latter, I give it considerably less weight.

Template redirects should generally be replaced, where possible. There are issues:

1. When there is a useful semantic difference - {{Footnotes}} perhaps.
2. Where the current name is the "wrong" one. We have had very vociferous editors arguing against template renaming because the redirect exists.

But the reasons for replacing them are more and more varied than you outline.

1. Confusing editors. When I last looked there were several hundred maintenance tags, and a few thousand redirects.
   1. Recognising the most popular tags is fairly simple, recognising the thousands of redirects is very hard.
   2. [Un-bypassed] Redirects spawn redirects. So we have {{Citation Needed}} => {{Citation needed}}, and {{Cite needed}} also redirects there. But because we don't clear up the {{Cite needed}}, people use that and we need the variants on that, currently only {{Cite-needed}}. Then people run around nominating this stuff for deletion, and otherwise wasting everyone's time, when all we really need to do is have the redirects dealt with by the hi-volume bots, or by the pre-save transform.
2. Names changed for good reasons.
   1. Easier to read {{Wfy}}, {{Cn}}, {{WPAAA}}.
   2. {{Fact?}} was considered rude as perhaps {{Prove it}} should be.
3. Systemic naming, such as starting infocboxes with "Infobox" and WikiProject banners with "WikiProject" (and in fact being the name of the project), is easier for both people and bots. (As is using spaces instead of camel-case, spinal case, train case, etc.) Also almost all Navboxes have name=title.
4. Freeing up valuable names that were hastily allocated in the early days. For example {{Physics}}
5. Avoiding names for different templates that differ only in capitalization, spacing or number.

I don't think the redirect-bypass has any significant effect on performance, though I may be wrong. Rather I think that we have a mindset that is predicated on an old and outdated situation, when we had "a server" so that the "WMF cost" of an edit was considered relevant (and relatively large).

I'm not sure I agree with all your examples of cosmetic edits. I think there is long-standing consensus that moving the stub template after the other categories justifies an edit, for example.

I do agree that more bad edits are worse than fewer. But I disagree that we can value them on whether they get reverted in the short term. For example I made some redirect-bypasses many years ago which were (unbeknownst to me, until this case came up) bulk reverted by another editor. All those I have checked, have had the change I made re-done since then. In the terms of various research papers this is a measure of "goodness". Even then it has to be considered that things can change. For example the edits made by Erik9Bot had consensus, but needed to be undone. Also there are systematic reasons to be "reverted" - maintenance tags are added in the hope that they will be removed.

I like your "bot frenzy minute" idea, but I fear his might become "vandal frenzy minute" too.

All the best: Rich Farmbrough, 17:23, 27 January 2017 (UTC).

Longer reply below, but please note that I pulled the 'moving a stub tag' thing as longstanding consensus, straight from the evidence-page. It was apparently the AWB rules-proposal back in 2010, as found at this talkpage entry -- WT:AutoWikiBrowser/Archive_9#Rules_of_use. Also presuambly, it used to be on the 'policy-page' as well? ...but nowadays WP:AWBRULES just says something more generic, without giving stub-tag-moves as a specific example. So I don't disagree that stub-tag-moves MIGHT not be considered 'cosmetic' anymore... but to me, they are cosmetic (see: definition-of-cosmetic-is-very-fuzzy-and-thus-a-problem), no matter what the written rules may say  ;-) 47.222.203.135 (talk) 21:23, 27 January 2017 (UTC)

Probably lack of precision. There were two widespread cases for moving stub tags, one, moving it after the categories, so the stub category appeared last, the other putting two(?) blank lines after the cats and before the stub tags, so that they didn't merge in with any navboxes or other end-cruft. The first was generally supported after it was explained, the second maybe not so much.

These days pretty much all articles comply with both, I believe, so the question is pretty much moot.

All the best: Rich Farmbrough, 22:08, 27 January 2017 (UTC).

ctrl brk

If one clicked edit during the weekly bot-frenzy, one would get a polite message: "bot frenzy in progress... please try again in 60 seconds" because ONLY the bots would be working. This locks out good-faith editors as well as vandals, but one minute per week is a reasonable tradeoff, for eliminating that long tail. Read-only access would still work, using the varnish caches, but only the Special Approved Bots would be permitted to *save* edits during that timespan. There would be a problem with people who had edit-windows open... I for instance will sometimes click edit and then forget to save, come back to the browser-tab days later... and this would generate the normal edit-conflict-please-resolve-manually. And if you had an open edit-window, and clicked save during the bot-frenzy, you would get the please-wait-60-seconds, and after you waited would (probably) get the edit-conflict. So it is not ideal. But it is probably needed.

And yes, I understand that we (meaning all-us-wikipedians-that-care-about-wikimarkup-coding-conventions) are trying to get people that see the 'correct' template names to start using and remembering THOSE names. And if they don't then the bot comes along and MAKES the change for them. Which is not much different than any big software project, where you have rulz for whether the braces are allowed/required on a line by themselves, and what kind of varnames are permitted, and all that stuff. Most people learn wikimarkup through osmosis: they click edit, they see some template-garbage for the infobox, the hunt around to find the BLP's name, they change it to be a four-letter-word, eventually they grow up and stop doing such silly things, and with luck use their de facto knowledge of infobox structures to make *helpful* edits instead of garbage edits.

But I do think there is a case to be made, that having firm bot-enforced naming conventions, could significantly speed up sitewide responsiveness. For instance, most javascript is still run through the minimizer, prior to getting deployed, because it goes over the wire as (sometimes gzip'd on-the-fly) plaintext even nowadays. Bot-converting from {{cn}} to {{Citation Needed|January 2017}} is almost certainly a mistake, from a performance perspective, because first of all the bot-related server load has a price, and second of all the more-bloated wikimarkup has a cost in read-time from the storage prior to sending the end-result HTML out over the wire. I understand this specific thing is small potatoes, but you catch my drift: if the bot-devs were *trying* to optimize average pageload times and perceived-by-the-readership responsiveness, there is a lot they could do. But given my druthers, I would rather see editor-oriented optimizations, it is a huge pain to have to wait for wikipedia to 'think' in between steps when manually editing. If we had some bots that were optimizing the perceived lag of the time between when I click the show-preview button, and then time when I can *see* the rendered preview, that would make me happy. Of course, why depend on bots when we could have dynamic updated-in-realtime preview... well, maybe someday. So yeah, I understand that the template-redirect-thing is not JUST about performance. In fact, it is mostly about bot-enforced coding conventions.

And that is the problem. Vandal-fighters don't need to recognize what a bazillion templates do, at a glance. They need their watchlists to be free of bot-spam, so they can concentrate on vandal-catching. I have only been annoyed by a bot once, that I remember: I was editing a leaf-article off in the wiki-boonies, and taking the luxury of doing a complex rewrite without worry of being interrupted... but when I clicked save, got an edit-conflict... because a bot had helpfully changed http into https. Not a big deal, I overwrote the bot's work with mine, and then manually did a find-n-replace to make the http-to-https changes that the bot was doing. I could also have just overridden the bot en masse, and eventually the bot would have returned to redo the change, too. But for somebody that is seriously depending on a watchlist, especially a very large one, bots are bleeping annoying. Anons don't have watchlists, but good grief do I hate the WP:ABUSEFILTER regex bugs, they are neverending. It's not the filter-author's fault, regex is just incapable of dealing with arbitrary english well. But I still rend my garments and gnash my teeth when I see yet another TalkPageAbuseDetectedYouSlimyAnon message from the buggy abusefilters. So I have some idea, of what the grumbling is about, and why it can explode into arbcom cases after enough years of grumbles.

Point being, *any* grumbling is justified, to the person grumbling. Annoyances make editing less fun. That hurts the mission here, of improving the encyclopedia, so we have to take all grumbling as justified. The more grumbling (either because more people are impacted or because the impact is perceived as more severe and thus causes correspondingly louder grumbling), the more it is a problem. Let the problem fester, and you get arbcom cases, sooner or later. So all grumbling is justified. The correct question, is how HARD is it to eliminate the grumbling. I will grumble until I die about the lagtime between clicking show-preview and the rendering of my changes, but fixing that by implementing some kind of WYSIWYG magical javascript is hard enough that VisualEditor failed. Even just doing realtime on-the-fly previewing, into an iframe, would be pretty damn difficult from a development-n-maintenance viewpoint, not counting the vastly increased server-load. So probably I'll just have to keep grumbling to myself. And I understand that it is difficult, since I am a programmer too, not just a wikipedian. But most people don't program seriously, and don't have a good sense of "easy bugfix" versus "astronomically difficult redesign" because to them it all seems hard and arcane. Programmers have the reverse problem: we look at complaints, and we say, well sure I could rewrite my bot so that it understand redirects, but there is already a bot which runs around *rewriting* template names to eliminate redirects, so why should I fix *my* bug when 99.9% of the time my bot will only see the canonical names? And complaints from endusers, that are not writing code and are not running bots and don't want to edit thataway, can seem unjustified or unfeeling. But this is a severe problem in and of itself, since on top of the programmer-culture versus enduser-cultures of various sorts, we also have linguistic barriers of a global project, different understanding of what 'counts' as actually being 'merely cosmetic' and just general wikipedia-related friction like admins-versus-non-admins and inclusionists-versus-deletionists and perfectionism-versus-expansionism-versus-protectionist and so on and so on.

Further point being, I would like to see this be one of those arbcom cases which has a good outcome. Actually, strike that, I would like this to be the *first* arbcom case evah, which results in a good outcome. No sanctions for anybody. No desysop's for anybody. Ideally, no admonishments, no wristslaps, everybody goes home happy. There are two ways that can occur: first, arbcom will have to rule that unblocking a bot, which even an anon like me can stop with a simple talkpage message on the bot's talkpage, is NOT wheel-warring... and neither is *reblocking* the bot, as many times and as often as is necessary, to correct the bugs or the problems that the bot is causing. Obviously, it *is* possible to wheel-war over whether a bot needs to remain blocked... but in general, for a bot that can be stopped with a talkpage-message, it is more of an WP:EDITWAR when the bot-owner reverts somebody who left a message, and that somebody puts the message back, which the bot-owner again reverts. It is a bit of a sticky wicket, and there are clearly ways that blanket permission to unblock one's own bots could be abused... but bots are not users, and users are not their bots, and it is WP:BURO-scale ridiculousness to pretend otherwise. But the core of the problem is not the bickering over whether a bot is 'really fixed' or not... the core of the problem is sociological, and related to people disagreeing (perhaps even unconsciously i.e. unaware that the definitional differential exists) about the meaning of 'cosmetic'. And even more sociological, people disagreeing about what is important and who ought to do the work.

So, if we wanna see a good outcome, my suggestion is that we need to identify *what* is really important, *who* thinks so, *why* they think so, and *who* is gonna implement the software changes necessary to keep them (i.e. that specific subgroup of wikipedians) content-not-grumbling. Other groups will have other priorities ('really important' ones of course), and will be grumbling about things also (*different* things usually). For the template-devs and the bot-devs, naming conventions are considered pretty damn important, and thus bots which perform template-bypass-surgery and properly canonicalize all the template-names, are an essential kind of wikimarkup-specific coding conventions thing. Necessary, if you spend all day debugging hairy temlates, and writing bots to parse wikimarkup! For the people who are not doing that, bot-spam in the edit-history and especially bot-spam in the watchlists is somewhere between mildly annoying and I'll-take-you-to-arbcom-damn-you intolerable. It builds up over the years. So my idea about the bot-frenzy-minute, is actually intended to help mitigate that exact problem: if certain kinds of changes are *only* permitted once a week, during the bot-frenzy-minute, this could dramatically reduce the watchlist-spam for the other 10,079 minutes of the week. Which in case you are computationally inclined, is roughly one-hundredth-of-a-percent. And even for the non-computationally-inclined, it is only one time per week that they'll see botspam (of certain sorts at least) in their watchlists. But in addition to figuring out if we can make a compromise-deal, where certain kinds of bot-edits are *only* performed during that weekly bot-frenzy-minute (with the selected subset of bot-edits optimized to reduce the maximum amount of grumbling we can), but also ANY kind of 'cosmetic' bot edit is legal so long as the bot is specially approved for the frenzy (with long tail elimination the other main goal)... that would be nice, but I still think we need to go a bit further.

Specifically, what will it take to get that one longstanding seemingly-intractable watchlist bug finally fixed? I can look at it myself, from an amateur's perspective, but I suspect you and Magioladitis and the other folks that are template-wizards and bot-meisters, will have a much better idea than me. And time is limited, given the arbcom decision means WP:TIAD. Now obviously, we don't want wikipedians to get into the habit, of anytime somebody wants a phabricator bug fixed, they open an arbcom case against the devs they hope will fix the stupid bug  :-)

But I wonder, if that heinous bug were fixed, that has kept the watchlist-spam grumbling going, and going, and going, festering all these years... would the ardent desire for an arbcom case, start to become significantly less ardent? Or is this just one of those times, when good-faith contributors that wanna do automated edits, and good-faith contributors that wanna have clean yet very large watchlists, are just inherently at loggerheads and somebody needs to be sanctioned so everybody can go away mad at the arbs? I am hoping the answer is, that there just might be a way out of this pickle, which doesn't require anybody getting 'the hammer' of the arbs, whether as 'plaintiff' or as 'defendant' in the 'case' which is ongoing 47.222.203.135 (talk) 21:23, 27 January 2017 (UTC)

• You might look at User:UncleDouggie/smart_watchlist.js and see if that would help with the heinous bug.

All the best: Rich Farmbrough, 23:55, 27 January 2017 (UTC).

January 2017 at Women in Red

January 2017
	Women Philosophers & Women in Education online editathons Faciliated by Women in Red

(To subscribe, Women in Red/Invite list. Unsubscribe, Women in Red/Opt-out list) --Rosiestep (talk) 02:14, 29 December 2016 (UTC) via MassMessaging

Some philosophers

• Samantha Brennan
• Federica Giardini
• Karen Green
• Annemie Halsema
• Heisook Kim
• Susanne Lettow
• Tuija Pulkkinen
• Christina Schües
• Stella Villarmea
• Prof. Dr. Elfriede Walesca Tielsch
• Dr. Brigitte Weisshaupt
• Susan Gelman
• Tania Lombrozo
• Carole Lee
• Christine Legare
• Lisa Miracchi
• Jennifer Nagel
• Deena Weisberg
• Hilde Lindemann
• Victoria, Lady Welby
• Karen Neander
• Ruth W. Grant
• En Hedu'ann of Iraq
• Aganice
• Lopamudar of India
• Gargi of India
• Maitreyi of India
• Ambapali of India
• Cleobulina of Rhodes
• Themistoclea of Greece
• Theano of Crotona
• Damo
• Arignote
• Myia
• Melissa
• Damo
• Aspasia of Miletus
• Diotima of Mantinea
• c. Arete of Cyrene
• Axiothea of Philesia
• Hipparchia
• Lasthenia of Matninea
• Pertictione I
• Phintys of Sparta
• Aresare of Lucania
• Theano II
• Perictione II
• Pan Chou ( Ban Zhao )
• Bruriah
• Julia Domna
• Marcella
• Sosipatra of Ephesus
• Catherine of Alexandria
• Hypatia of Alexandria
• Macrina the Younger
• Macrina the Elder
• Hild of Streonshalh= Hilda of Whitby
• Yeshe-Tsogyal
• Dhouda of Gascony
• Hroswitha of Gandersheim
• Murasaki Shikibu
• Hildegard of Bingen
• Herrad of Hoehenbourg
• Akka Mahadevi
• Beguines
• Beatrice of Nazareth
• Mechtild of Magdeburgh
• Hadewijch of Brabat
• Helfta Monastery
• Gertrude the Great
• Christine Pisan
• Isoatta Nogarola
• Cassandra Fedele
• Veronica Gambara
• Lorenza Strozzi
• Oliva Sabuco
• Marie le jars de Gournay
• Asnat Barzani (Asenath Barzani)
• Bathsua Makin
• Elana Cassandra Tarabotti
• Anna Maria Van Schurman
• Elizabeth of Bohemina
• Margaret Cavendish
• Kristina Wasa
• Anne Finch/Conway
• Gabrielle Suchon
• Helena Lucretia Cornaro Piscopis
• Damaris Cudworth Masham
• Mary Astell
• Catharine Trotter Cockburn
• Sophia
• Emilie du Chatelet
• Laura Bassi
• Maria Gaetana Agnesi
• Catharine Macaulay
• Olympe de Gouges
• Mary Wollstonecraft
• Anna Doyle Wheeler
• Judith Sargent Murray
• Mary Fairfax Somerville
• Hortense de Meritens
• Harriet Martineau
• Jenny Poinsard d'Hericourt
• Elizabeth Cabot Cary Agassiz
• Julie Velten Favre
• Anna Brackett
• Ellen Mitchell
• Susan Blow
• Grace C Bibb
• Marietta Kies
• Helene von Druskowitz Helena Maria Druschkovich
• Emma Goldman
• Zitkala-Sa
• Susan Stebbing
• Susanne Langer
• Christa Davis Acampora
• Linda Martín Alcoff
• Amy Allen
• Babette Babich
• Alison Bailey
• Rebecca Bamford
• Bat-Ami Bar On
• Berit (Brit) Brogaard
• Lara Buchak
• Joan Callahan
• Sharyn Clough
• Angela Coventry
• Sharon Crasnow
• Anne D'Arcy
• Nancy Daukas
• Judith Wagner DeCew
• Penelope Deutscher
• Paula Droege
• Patricia Easton
• Ann Ferguson
• Carrie Figdor
• Pieranna Garavaso
• Nicole Garner
• Ann Garry
• Tamar Szabo Gendleris
• Lori Gruen
• Ruth Hagengruber
• Nancy Slonneger Hancock
• Sally Haslanger
• Claire Horisk
• Kristen Irwin
• Anne Jaap Jacobso
• Robin James
• Marianne Janack
• Leigh M. Johnson
• Marjorie Jolles
• Barrie Karp
• Amy Kind
• Eva Feder Kittay
• Christine M. Korsgaard
• Rebecca Kukla
• Rae Langton
• Hilde Lindemann
• Mary Briody Mahowald
• Chaone Mallory
• Jennifer Matey
• Noëlle McAfee
• Linda López McAlister
• Mary Kate McGowan
• Jen McWeeny
• Diana Tietjens Meyers
• Marjorie C. Miller
• Roberta L. Millstein
• Elizabeth Minnich
• Mary Christine Morkovsky
• Mechthild Nagel
• Kathryn J. Norlock
• Martha Nussbaum
• Peg O’Connor
• Kelly Oliver
• L.A. Paul
• Tanya Rodriguez
• Naomi Scheman
• Sally J. Scholz
• Robin May Schott
• Falguni A. Sheth
• Susanna Siegel
• Miriam Solomon
• Cara Spencer
• Nancy Stanlick
• Shannon Sullivan
• Julie Tannenbaum
• Marcella Tarozzi-Goldsmith
• Lisa Tessman
• Rosemarie Tong
• Adriel M. Trott
• Nancy Tuana
• Ericka Tucker
• Mary Ellen Waithe
• Florence Bradford Wallack
• Karen J. Warren
• Laura Werner
• Kathleen J. Wininger
• Kristin Waters
• Georgia Warnke

RfA

Have you ever considered re-running? I think you might pass this time.—CYBERPOWER (Chat) 18:56, 28 January 2017 (UTC)

Yes, I would be willing to run again. I'd need a quiet time to keep up with the RFS. All the best: Rich Farmbrough, 13:24, 21 May 2017 (UTC).