Contents 1 A proposal to permanently semi-protect the Template space 1.1 Discussion (permanently semi-protect the Template space) 1.2 Hashing out a number 2 A Bot for Creating Arthropod Stubs 2.1 Qbugbot discussion 2.2 Qbugbot sample articles 3 Audio samples on articles related to languages 4 Providing some way to easily spot when controversies or criticisms are removed or reduced 5 Disable messages left by InternetArchiveBot 5.1 Yes 5.2 No 5.3 Discussion 6 Please mention classification system in taxobox 7 ZipcodeZoo.com 8 An update of the default introduction & tutorial to Help:Introduction 9 Discussion: Use of AR-15 Style Rifles in Mass Shootings


A proposal to permanently semi-protect the Template space[edit] Closing this RFC. Half of those participating were in favour of semiprotecting every template, and a lot of the remaining half were, while opposing the blanket approach, were in favour of semiprotecting those templates with more than a certain number of transclusions (the figure varied). There appears to be a rough consensus to for now, permanently semiprotect anything with at least around 200-250 transclusions, with the remainder being addressed on a case-by-case basis. Fish+Karate 12:20, 12 February 2018 (UTC) The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion. Following a series of vandal edits to the template space (here and here, and the ANI about it), MusikAnimal template-protected (without opposition) templates with 5k+ transclusions and semi-protect all those with 1000+ transclusions. Earlier today a template with 956 transclusions was vandalised. Due to the fact that the template space isn't widely patrolled, and the potential for great harm to be done in a very short amount of time, I am proposing that all templates be semi-protected. This would likely involve a software change, but I think it's the only way to ensure that major vandalism on a relatively-unused template doesn't sit around for ages, to be seen by the unsuspecting public who might not know how to let us know to fix it. I briefly discussed this off-wiki with Cyberpower678, who said they would support if there was a minimum transclusion count (10+ was discussed) so I am amenable to that option, but from an administrative standpoint I think it's easier to just batch-protect everything (unless we can get a protect-bot that can autoprotect templates with 10+ transclusions). Primefac (talk) 18:18, 21 December 2017 (UTC) NOTE: This would not require a "software" change (to apply to an entire namespace), but would require a configuration change in InitialiseSettings.php. See example of auto confirmed being used for the Module: namespace on eswiki (scroll to the bottom of the page). — xaosflux Talk 19:30, 21 December 2017 (UTC) Supportentire space a small transclusion number but not the entire space, per zzuuzz's argument below. — Insertcleverphrasehere (or here) 18:25, 21 December 2017 (UTC) Yeah. OK make it so. net positive -- Dlohcierekim (talk) 18:26, 21 December 2017 (UTC) Support Having a protect-bot is a little ehh, because it means that anyone can semi-protect any template with less than 10 transclusions by transcluding it..not too much potential for harm there, but still. Galobtter (pingó mió) 18:39, 21 December 2017 (UTC) Other than "winning" an edit war, I don't see the how it would be gaming the system to add a few more transclusions to result in semi-prot. Primefac (talk) 18:50, 21 December 2017 (UTC) I mean, that is a vague problem. But rare. Galobtter (pingó mió) 03:58, 22 December 2017 (UTC) Support I did indeed say I will support this and I can easily create a bot to enforce this. When I did say 10+ transclusions, I did mean in articlespace. So not too much potential for gaming as mentioned above.—CYBERPOWER (Merry Christmas) 18:42, 21 December 2017 (UTC) Support Net positive. I love IPs and new editors, but they can either log in and wait 4 days or just wait 4 days to edit the Templates. L3X1 (distænt write) 18:53, 21 December 2017 (UTC) I don't find zzuzz's argument convincing. "Autoconfirmed socks are easy to come by" If you bother getting your mouse over to the create an account button. Driveby vandals aren't usually socks. And I didn't think this was being proposed as a cure for socking, just vandalism which can be pretty hard to detect. I'm fine for the base limit to be raised to a thousand transclusions or something like that, but SEMI is a very effective anti-vandal lockdown. Also "encyclopedia anyone can edit" doesn't apply here. The template space is maintenance and framework of the encyclopedia, not the content. L3X1 (distænt write) 20:19, 21 December 2017 (UTC) Oh the number of autoconfirmed socks I've blocked - these are dedicated regular vandals who do this, not drive-bys. But that's a minor point - I disagree with you strongly about the use of templates. Some are indeed maintenance and framework templates (particularly those targeted), but the vast majority of templates (particularly those edited by unregistered users) contain lists, and names, and numbers, and very much form part of the content. -- zzuuzz (talk) 20:36, 21 December 2017 (UTC) Comment Primefac, wouldn't it be easier just to roll out an ACTRIAL like technical restriction rather than semi-protect every new template? TonyBallioni (talk) 19:08, 21 December 2017 (UTC) TonyBallioni, I'm not overly concerned about the creation of templates, I'm concerned about vandalism to templates. The vandalism to Template:Redirect-multi was done almost two years after the page was created. Primefac (talk) 19:24, 21 December 2017 (UTC) Right, but what I'm saying is that there may be a way simply to prohibit any editing to templates to non-AC users on en.wiki without having to manually protect them, which would be ideal. TonyBallioni (talk) 19:26, 21 December 2017 (UTC) Oppose basically because of this. This proposal is fine in theory for long standing prominent, widely-used and heavily transcluded templates - typically maintenance templates. However there's a notable maintenance of less common templates by new and unregistered users, including those with dozens of transclusions. I find it's especially notable in sports templates, but several other topics - politics, media, software, all sorts actually. Many of these templates are almost exclusively maintained by unregistered users. Several hundred transclusions would be my floor. I would prefer instead that the current system of caching and purging is improved to reduce any vandalism's longevity. Also, autoconfirmed socks are incredibly easy to come by. -- zzuuzz (talk) 19:12, 21 December 2017 (UTC) I do see that problem. Don't see why it has to be several hundred transclusions though. Most of those have less than 10 transclusions. Galobtter (pingó mió) 03:58, 22 December 2017 (UTC) But plenty have more than ten transclusions. It's a figure based on experience. Take some random obscure examples recently edited by unregistered users: Template:Philip K. Dick - 184 transclusions; Template:Syracuse TV - 37 transclusions; Template:Miss International - 64 transclusions; Template:Cryptocurrencies - 109 transclusions; Template:Pixar - 110 transclusions; Template:Flash 99 transclusions. There's a lot like this. -- zzuuzz (talk) 07:22, 22 December 2017 (UTC) Oppose Wikipedia is the encyclopedia that anyone can edit but there are only 159 editors with template editor right. I don't have this right myself and would resent being considered a suspicious vandal by default. We have far too much creeping lockdown of Wikipedia which is tending to kill the project. If such paranoia had been allowed to prevail in the early days, Wikipedia would never have been successful. Andrew D. (talk) 19:51, 21 December 2017 (UTC) @Andrew Davidson: This proposal is to semi-protect the templates, not template protect them. Just thought I would clarify that.—CYBERPOWER (Merry Christmas) 20:09, 21 December 2017 (UTC) Oppose zzuuzz's argument is convincing. Jo-Jo Eumerus (talk, contributions) 20:01, 21 December 2017 (UTC) Sort of oppose, sort of support. 10 transclusions is way too low a limit and the devil is in the details. Maybe 100+, or 1000+ and I'd be OK with this. But I feel a better approach might be to simply be identifying templates that do not need to be edited regularly, and semi-protect those (e.g. semi-protect maintenance templates, infoboxes, etc...). But I do not see a need to semi-protect templates like navboxes, for instance. Headbomb {t · c · p · b} 21:13, 21 December 2017 (UTC) comment would it be better, perhaps, to use PC1? seems to me, aht it's a useful way to allow ipusers and new registered to make productive edits, without them going live immediately. (this may, however, require technical changes. -- Aunva6talk - contribs 22:32, 21 December 2017 (UTC) Support semi-protting, but ONLY for templates with 250+ transclusions. The vandals are going to be drawn to those templates that are widely used in order to cause chaos, so the simplest thing to do is to semi-protect only those templates that are used in many articles at once. As per usual I oppose CRASHlock on ideological grounds, not to mention that only an idiot would want that many pages CRASHlocked all at once. —Jeremy v^_^v Bori! 22:57, 21 December 2017 (UTC) There must be some vague way to figure out if something is a maintenance or content template. Maybe make templates that take parameters semi-protected? Some sort of solution of 10+ transclusions and that. But it'd also have to be designed to prevent abuse. Galobtter (pingó mió) 03:58, 22 December 2017 (UTC) Oppose. Aside from zzuuzz's points, it would vastly increase the workload on WP:Template editors (and admins who respond to requests that TE's can also do). Yes, non-TEs could respond to template-editing requests on templates that are only semi-protected, but most of them don't know that, and it would likely not be obvious what the protection level was when it came to any particular request. I think a more reasonable proposal would be to semi-protect templates with X number of transclusions. 100? 250? 1000? I'm rather agnostic on the matter. A good thing to do would be to find the sports-specific template that is used on the largest number of pages that is not an infobox (we do not want anons adding or deleting parameters from an infobox, because those templates are a massive WP:DRAMA factory as it is) and not a navobox (because we have rules about them, and anons mostly will not have read them). There are likely football (soccer) templates relating to team roster, uniforms ("kit"), league standings, etc., used on hundreds of articles at least, possible 1000+, to which anons with some experience could meaningfully contribute. Might give us an idea what number we should be thinking about. Anyway, I would actually like to see automatic semi-protection on somewhat-high-use templates as an anti-vandalism method, and also as a means for reducing the number of templates that have template-editor protection for which semi-protection would actually be sufficient. That will not only waste less TE time, it will get us more template development by anons and non-anons.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  05:07, 22 December 2017 (UTC) Oppose. Excellent arguments made by zzuuzz. I read through the recent changes link, and surprisingly few of the diffs listed were vandalism. We might want to protect highly-used maintenance templates. Perhaps 5000 transclusions would be a good floor for this (from what I've seen at the most-transcluded templates report). Enterprisey (talk!) 05:16, 22 December 2017 (UTC) Support Vandalism on template is affecting several pages at the same time. Any IP user can propose any meaningful change via edit request which normally doesn't last 24 hours without getting response. –Ammarpad (talk) 09:15, 22 December 2017 (UTC) Based on recent data this would affect around 1,500 edits every week. I think most wouldn't even bother making requests, but if even a proportion did I would expect that to increase. -- zzuuzz (talk) 10:53, 22 December 2017 (UTC) I would support a proposal for using a bot to give all templates with more than 10 transclusions semi-protection, or pending changes protection if possible; and to remove semi-protection if templates, having been protected by the bot, have their number of transclusions reduced below 10. Automatic semi-protection of all templates is definitely overkill (having a bot find the number of transclusions is definitely possible), and 5000 as a minimum for semi is definitely too high (I'd say even 500 would work for template protection). Note that none of these would increase the workload of template editors, since they are only needed for editing template-protected templates and modules. The bot could also avoid protecting templates consisting solely of navboxes or sidebars, since they are supposed to be transcluded on many pages by design and are relatively easy to edit. Jc86035 (talk) 11:38, 22 December 2017 (UTC) OP Comment Okay, a few things I've seen that keep popping up: First, all templates with 1000+ transclusions are already semi'd (and 5k+ TE'd). This proposal is talking about those with 0-999 transclusions being potentially vandalised. Second, the proposal is for semi protection, which would not increase Template Editor's jobs in any way, shape or form. They would of course be welcome to patrol the edit requests for Template-space issues, but not required. Third (going off the previous note) the TEs aren't exactly hammered under the weight of responsibility. We get maybe three TPER requests a week. Just felt I should clarify those things going forward. I will admit that IPs aren't all bad with their changes, especially to Sports templates, but those type of frequently-updated templates are (for the most part) single-season templates that are rarely used on more than 10 pages (which would mean the 10+ option of semiprot wouldn't affect them). If Cyberpower says he can make a bot to do it, then it wouldn't involve any software changes. Primefac (talk) 13:22, 22 December 2017 (UTC) And for what it's worth, I don't particularly care if we decide on 10+ or 250+ or 500+, but I think there should be some threshold for semi-protecting templates. Primefac (talk) 13:24, 22 December 2017 (UTC) So... if we (assuming we can) run the numbers, looking at frequency of edits and number of transclusions, what does that graph look like? Is there some evidence based threshold beneath which most IP editors can happily plod along, while the rest of us can avoid having a cock and balls transcluded on a few hundred pages every few weeks? GMGtalk 13:44, 22 December 2017 (UTC) Oppose, current protection level works generally well, and vandalism level on templates isn't very high. Openness ("anyone can edit") is more important than restricting vandalism to sleeper accounts. —Kusma (t·c) 18:17, 22 December 2017 (UTC) Oppose blanket protection. zzuuzz's argument is compelling and this is the free encyclopedia that anybody can edit. At a certain number of transclusions, the tradeoff points in the direction of protecting. So I would support an x+ transclusions rule. Malinaccier (talk) 18:28, 22 December 2017 (UTC) Oppose, there are template such as sports competitions, sport team lineups, list of stations etc, where IP contributions are mainly constructive and helpful. I could support the x+ protection, though 10 inclusions looks like a low bar for me (a football team lineup is at least 23 + the team + the coach), I would more think about fifty or so.--Ymblanter (talk) 00:00, 25 December 2017 (UTC) Oppose This is the encyclopedia anyone could edit. Functionally, semi-protecting everything would be great, but its not what we do and it's fundamentally against our ideas. Don't do this kneejerk action. Be smart, and judge it on a case-by-case basis. !dave 08:17, 28 December 2017 (UTC) moved to support Oppose. There are many templates that would be perfectly legitimate for newer editors to edit, especially navboxes and the like. I would support semi-protecting everything with 100+ transclusions. We probably should create an edit filter logging newer editor's edits to template namespace, as an aside. ~ Rob13Talk 08:24, 28 December 2017 (UTC) @BU Rob13: If you use the new filters form on RC/WL/RCL (see beta preferences), this is all non-EC edits to template space. --Izno (talk) 13:39, 28 December 2017 (UTC) Support on templates used more than 100/200 times but Oppose generally. Doc James (talk · contribs · email) 05:59, 30 December 2017 (UTC) Oppose entirely per my response to BU Rob13. The majority of changes made in the template space by non-EC users are good changes; routine updates to navboxes seemingly the majority of such changes. --Izno (talk) 06:32, 1 January 2018 (UTC) Oppose Counting transclusions isn't that useful in template vandalism, you really care about page views. If a template is transcluded 30 times, but one of those pages is Obama, it's a highly viewed template and should be protected. But if a stub template is used on a thousand pages that barely get read, protecting it is of little use. Beside that, protecting an entire namespace is an extremely dangerous road to go down IMO. We should always default to open. Legoktm (talk) 07:11, 2 January 2018 (UTC) Support Semiprotection is not an insurmountable hurdle. The benefit of this proposal outweighs concerns, imo. James (talk/contribs) 14:43, 2 January 2018 (UTC) Support with a reasonable threshold of transclusions (say 200?). Peter coxhead (talk) 16:01, 2 January 2018 (UTC) Support Templates that are used in more than 200 pages should be permanently semi-protected. However, it doesn't seem to be reasonable to semi-protect all templates. I have seen constructive edits made by IP editors to templates. Extended confirmed protection for all the templates that are used to warn users about their edits. Pkbwcgs (talk) 16:49, 2 January 2018 (UTC) Support as long as a) there is a transclusion threshold, b) the bot removes protection when a page drops below the transclusion threshold, and c) there is a mechanism to request that a template be unprotected (and a flag that the bot will obey). --Ahecht (TALK PAGE) 22:28, 2 January 2018 (UTC) Oppose per zzuuzz, Kusma et al. Better to apply whatever protection is required manually on an individual basis. At the end of the day, newby vandals are unlikely to be aware of template space anyway, and those out to deliberately disrupt the project would have no problems about waiting till they're auto-confirmed. Optimist on the run (talk) 11:22, 4 January 2018 (UTC) Oppose per zzuuzz et al, Not all IPs are vandals and the other point is "We're an Encyclopedia that anyone can edit" .... we'd be defeating the purpose of the object if we locked all templates, Whilst in theory I agree with this proposal unless we ban all IP editing (which sounds great!) then I think it's best to just stick with semi protecting here and there and blocking here and there. –Davey2010Talk 16:47, 5 January 2018 (UTC) Support, no particular opinion on best number for cutoff. --SarekOfVulcan (talk) 19:02, 8 January 2018 (UTC) Oppose on ideological grounds. This is the free encyclopedia that anyone can edit. Protection of so many templates runs contrary with Wikipedia's principles. AdA&D 19:28, 8 January 2018 (UTC) I have some bad news for you; we'll start with how IPs cannot create pages, and get progressively darker from there... - The Bushranger One ping only 07:10, 13 January 2018 (UTC) Support. Templates are a gaping hole in our antivandal protection; one edit can splash an offensive image, a WP:BLP-violating message, or even a link to malware across dozens or even hundreds of pages. I feel for our IP editors, but that horse left the barn years ago (and wouldn't even be an issue at all if the WMF listened to its editors with regard to SITE, but that's an entirely different kettle of surstromming). This is something that must be done, because the alternative is to wait until we're forced to - under terms we probably won't get to dictate. - The Bushranger One ping only 07:10, 13 January 2018 (UTC) Support. WP:IP addresses are not people. IPs are free to do basic editing, but this is a situation where the risk for damage outweighs the benefit of the edit to a template. My second choice would by limited the protection to templates that are used in a dozen or more articles. Dennis Brown - 2¢ 18:56, 13 January 2018 (UTC) Support semi-protecting templates with ~250+ transclusions (or some other reasonable number determined by consensus). Tony Tan · talk 03:59, 17 January 2018 (UTC) Support This is becoming an increasingly easy way to make a small edit and do a lot of damage. There are parts of Wikipedia we just don't trust with editors who haven't shown an ability to edit. These are important to the inner workings of Wikipedia. Templates, I feel, fall under that distinction. This won't stop until they are protected from vandalism. --Tarage (talk) 22:22, 22 January 2018 (UTC) Support Template vandalism is an increasing problem, and as the more commonly transcluded templates get protected, it is the more obscure templates - often on pages with less traffic and/or watchers looking after them - which will be targeted more frequently. Template vandalism is harder to fix for most editors than regular article vandalism, and does more damage to Wikipedia as a result. IMHO, the damage done by not protecting the Template namespace like this greatly outweighs the inconvenience caused by preventing IP users from editing what is, in all fairness, a fairly niche and specialist area of the project. Yunshui 雲水 23:18, 22 January 2018 (UTC) Support Template vandalism is a real problem, and it's easy for a vandal to stumble across a template - they don't need an understanding of the software. We already restrict access to many templates to template editors. Hawkeye7 (discuss) 00:11, 23 January 2018 (UTC) Weak oppose We really need something to help with this, the amount of damage that can be done is bewildering, and usually we're told about it from a random person on IRC, after the spammer has garnered 1000s of views. I don't think we should limit template editing because of our own technical shortcomings. I know there's a plan in the works to do away with the need to purge, but a "recursive purge" is a necessity at this point. Drewmutt (^ᴥ^) talk 00:53, 23 January 2018 (UTC) Support : Same suggestions as Ahecht. Template talk pages should be excluded of course.   —  Hei Liebrecht 16:02, 25 January 2018 (UTC) Weak support I don't like this proposal, because it restricts one of our principles, but recent template vandalism has made me change my mind. !dave 17:44, 27 January 2018 (UTC) Oppose: WP:IPs are human too. Besides the ideological grounds upon which WikiMedia was founded, this proposal essentially adds significant impediments to the development of templates by anonymous IP users who are already censured en masse far too much. Though a significant amount of vandalism is done by this class of users, so too is a significant amount of useful content generated by such users. The natural progression is to extend this to apply similar mass protections of Module space. Please consider that this proposal penalizes a large class of editors for the actions of a few (albeit persistent) in this class. I understand there is a balance between the work needed to police vandalism vs. the value generated by the class of users penalized but I believe this proposal goes too far. We hear from registered users about the increasing issues of vandalism but remember so too is there the increasing issues of censure to a group of users that already have a difficult time making their issues heard. Remember this sort of proposal not only blocks the vandals but also blocks anonymous IP users (which are a large number of eyeballs) from reverting vandalism so this could in fact increase the damage done by more determined vandals. 50.53.21.2 (talk) 05:17, 28 January 2018 (UTC) Oppose - templates should be semiprotected individually. --NaBUru38 (talk) 19:39, 31 January 2018 (UTC) Support At whatever transclusion number comes by consensus. Ronhjones  (Talk) 17:59, 3 February 2018 (UTC) Discussion (permanently semi-protect the Template space)[edit] If the proposal is adopted, then the transclusion count cut-off point should be somewhere above 200. The vast majority of templates are navboxes: they don't get vandalised often and they do requite quite a bit of maintenance that anons are generally able and willing to help out with. – Uanfala (talk) 15:46, 24 December 2017 (UTC) I havent observed the editing history of templates much. But Uanfala's comment above makes sense. Also, by doing this we will take away one more thing from "anybody can edit" thingy. Yes, anybody can edit, but you need an account. Also, you need to wait for 4-5 days, and make 11 edits before you can edit. Also, if a vandal who is going to vandalise through templates, i think he is already familiar with concepts of socks, and sleepers. So I dont see much point in implementing these proposals. courtesy ping to Uanfala to let them know that their comment was moved. —usernamekiran(talk) 23:44, 24 December 2017 (UTC) In general, vandals will go for the low-hanging fruit of unprotected templates first. (Note that I don't support semi-protecting all templates, just those with 250+ transclusions.) It takes time and edits to create an autocon-buster, and generally speaking most vandals who would create autocon-busters have very specific targets in mind, as opposed to just causing general chaos. Burning an autocon-buster on templates is a VERY good way to get the rest of your sock drawer ferreted out or your anonymising service's IPs blocked, since, as I mentioned in the PC2 RfC, using an autocon-buster virtually guarantees CheckUser attention. There is no such thing as a drive-by autocon-buster. —Jeremy v^_^v Bori! 23:27, 26 December 2017 (UTC) The template subspace not only contains templates but also their talk pages. New users should be able to ask for help on the talk pages of templates so the talk pages shouldn't be semiprotected. ChristianKl ❪✉❫ 22:57, 31 December 2017 (UTC) So far two ideas seem to be floating: one, that a bot protects any template with more than 10 transclusions (uses) or a sitewide configuration change for the template namespace. In neither case would talk pages be affected. :) Killiondude (talk) 03:31, 1 January 2018 (UTC) Atleast can we have semi-protection for 100+ transclusions? Another incident occured today that shows why it really is needed. {{Sidebar person}} is transcluded on 564 pages, including Donald Trump. Yet it was completely unprotected, and was vandalized by someone so that a huge "fuck donald trump" showed for at least 40 minutes (probably more) at-least 2 hours (based on a reddit post), 2 hours after the vandalism was reverted (only for logged-out users, because apparently they get a cached version of the page - so regular editors did not see it) I'm thinking that after that automatic semi-protection, at admin discretion, maintenance templates that shouldn't be changed much can be preemptively template/semi protected. Galobtter (pingó mió) 11:25, 1 January 2018 (UTC) I'm wondering if there's a smarter way to do it. Templates that are transcluded onto other templates (like that one was) should be protected at a lower count. I'm sure there are reasonable ways so that sports stat templates etc are not protected while ones like these are. Galobtter (pingó mió) 11:52, 1 January 2018 (UTC) I did not catch this particular vandalism, however, I want to underscore the fact that now that this template is protected, we have effectively restricted the number of editors that can respond to (i.e., revert) vandalism of this template (by more determined vandals). This can in fact cause more damage due to vandalism as the vandalism can potentially exist longer despite anonymous IP users seeing the issue but being unable to directly do anything about it. 50.53.21.2 (talk) 05:51, 28 January 2018 (UTC) This sub-transclusion problem is of course a major one not addressed above. What today's vandalism shows, yet again, is that it's templates with not merely tens or a hundred of transclusions, but several hundred transclusions. The templates which generated this thread were around 1,000 transclusions. But also the real problem is not the vandalism but the caching and no effective means to bust the caches. -- zzuuzz (talk) 12:03, 1 January 2018 (UTC) Another tool might be an admin ability to mass purge cache, perhaps cache's generated in a certain period of time (when the template was vandalized) linked to a certain template. Galobtter (pingó mió) 12:15, 1 January 2018 (UTC) Has anyone confirmed or heard if that was seen on any other page or did it just happen to Donald Trump? Emir of Wikipedia (talk) 16:49, 1 January 2018 (UTC) Yes others[1][2]. -- zzuuzz (talk) 16:54, 1 January 2018 (UTC) Wikipedia:Purge#forcerecursivelinkupdate is interesting Galobtter (pingó mió) 16:56, 1 January 2018 (UTC) Apparently can force cache update of all transcluded pages.. Galobtter (pingó mió) 16:58, 1 January 2018 (UTC) Another 900-page template got hit this morning. Primefac (talk) 16:38, 10 January 2018 (UTC) 200-page template that got hit, as well as 110-page and 31-page templates. As a minor note, this was after I semi-protected all templates with 350+ transclusions, so while they're still being vandalised, the templates are having a smaller impact as they pick the (to quote Bushranger) "lower-hanging fruit". Primefac (talk) 14:34, 14 January 2018 (UTC) If we want to lower the impact of vandalism, we would be far better off enabling as many users as possible to respond to vandalism rather than restricting both vandalism and any response to vandalism to ever smaller groups of users. Vandals by definition are a small set of users and as such can always be thwarted by a larger populace. Adding restrictions just means vandals will have to become more determined to bypass the restrictions. As such, restrictions are not a sustainable practice. Currently anti-vandalism tools are difficult if not impossible to access and use by anonymous IP users which are in fact the largest set of users and editors within WikiMedia projects. 50.53.21.2 (talk) 06:08, 28 January 2018 (UTC) Comment: for some mystical reason, nobody has mentioned the Wikipedia:High-risk templates guideline. --NaBUru38 (talk) 20:02, 31 January 2018 (UTC) I'm still of the opinion that everything in this namespace should be Pending Changes protection/Deferred changes/whatever we want to call it, for edits not made by sysops. Having 2 people look over each others code changes is no more than normal in ANY space where code is deployed to so many people at the same time and seems perfectly reasonable to me. I'm not sure why we are bothering with semi protection, it just feels like a a moving goalpost for the vandals, that will just go on to the next level of least resistance. —TheDJ (talk • contribs) 14:58, 7 February 2018 (UTC) @TheDJ: I think we'd want to exclude bots and templateeditors as well. The former as they are already tightly controlled by task approvals, and the later as they are specifically selected for this function and many are more skilled in this maintenance then some sysops. — xaosflux Talk 15:32, 7 February 2018 (UTC) @TheDJ and Xaosflux: This would need software changes, as transclusion currently picks up the latest version even if it has not been reviewed. Currently List of soap opera villains has unreviewed changes and is transcluded at User:John of Reading/X3. Viewing both while logged out, I see the old version of the real article but the latest version in my sandbox. -- John of Reading (talk) 16:06, 7 February 2018 (UTC) Hashing out a number[edit] It looks like about half of the "oppose" votes are opposing the "blanket" semiprot, which I sorta get. That half also mentioned that an alternate option was an "X+ transclusions" option. Seeing as how the % of !votes who would be amenable to that is more than the "hard oppose", I think it's time to flesh out a number. The numbers that were thrown around the most were 10+, 100+, and 250+. So, despite my personal concern that we'll never agree on anything, I'd like to see if we can try. Primefac (talk) 02:21, 4 January 2018 (UTC) 100+ - it's a high enough bar that the sports-type templates that frequently get updated by the helpful IPs won't be affected, but keep "bigger" templates from causing more harm than necessary (and <100 pages is a piece of cake for someone with AWB to null edit in a hurry). Primefac (talk) 02:21, 4 January 2018 (UTC) 250+ per the comments below. Still a low bar for AWB/null edits. Primefac (talk) 13:56, 8 January 2018 (UTC) 250+; I've made my reasons why clear above. —Jeremy v^_^v Bori! 02:27, 4 January 2018 (UTC) 250+ or 10+ semi-protected pages. (I'm not sure this suggestion is feasible) Templates like Template:Duke Blue Devils men's basketball navbox should be able to stay unprotected. Templates transcluded on high-profile pages should have a lower threshold. power~enwiki (π, ν) 11:56, 4 January 2018 (UTC) Wait, are we talking semi-protection, or pending-changes protection? I could support pending-changes for the entire namespace. power~enwiki (π, ν) 12:17, 4 January 2018 (UTC) @Power~enwiki: I don't think the software supports pending changes in templates, as the software will always transclude the latest version. I can't find where I read that, though. -- John of Reading (talk) 07:23, 5 January 2018 (UTC) Not to mention that that would be too much of a strain on the hive of idiots that is CRASH. Like I said above, only utter fools would want so many pages CRASHlocked. —Jeremy v^_^v Bori! 20:36, 5 January 2018 (UTC) No numbers please. If we came up with a rule that references a particular number I'm afraid this will have the effect of discouraging the exercise of common sense. If there's any take-home message from the above discussion, it is that the circumstances vary between templates and that some basic judgement should be exercised. If a template is unlikely to ever be edited – say, if it's simply a wrapper for a module, or it produces some very simple code that is unlikely to be changed – then it may be protected even if it has a low number of transclusions (say, 30). On the other hand, if it's a large template that is likely to need some sort of regular maintenance (like a navbox) then it usually doesn't make sense to protect it, even if it's got thousands of transclusions. – Uanfala (talk) 15:23, 11 January 2018 (UTC) The entire reason for this discussion is because of the increasing frequency of vandalism regarding templates with hundreds of transclusions, since it grossly disrupts articles the template is then transcluded on; hence the numbers. Blanket semi-protection of the Template: space isn't workable or viable, so the goal should be to eliminate the most tempting low-hanging fruit to prevent this sort of vandalism. —Jeremy v^_^v Bori! 21:43, 11 January 2018 (UTC) My druthers would be to protect all of them, as only protecting "the most tempting low-hanging fruit" will simply make the fruit on the next branch up increase in temptation value. But if a number must be set, 10+. - The Bushranger One ping only 07:10, 13 January 2018 (UTC) Unfortunately, the same is true with semi-protection, it isn't difficult to reach autoconfirmed level with trivial edits, even in a sandbox... —PaleoNeonate – 10:39, 13 January 2018 (UTC) Template vandalism is virtually always drive-by, however. Setting up an autocon-buster takes time, and since the goal of these accounts is to cause disruption for a quick laugh then move on, that takes more time and dedication than they are willing to spend. —Jeremy v^_^v Bori! 17:48, 13 January 2018 (UTC) Unfortunately it also takes the same determination for someone who sees vandalism to respond to it. Blanket protections at ever lower transclusion counts mean fewer people can respond to more determined vandalism. 50.53.21.2 (talk) 06:19, 28 January 2018 (UTC) Most of the unregistered users/readers who see template vandalism generally don't recognise it as such and look in the article only to come up empty-handed - which is why template vandalism is disruptive to the point where blanket protection of all templates that are transcluded on X number of pages is a far better option than seeing dozens or hundreds of articles all vandalised at once. —Jeremy v^_^v Bori! 06:55, 28 January 2018 (UTC) I am curious how you arrive at such a determination. Do you have some convincing metric? I also believe we need more than just a generic translusion count as a measure of impact. As an example Template:Sandbox other is currently semi-protected with over 3000 transclusions, but not a single one of them is in article space. 50.53.21.2 (talk) 08:07, 28 January 2018 (UTC) 250+ is a reasonable number. Tony Tan · talk 04:02, 17 January 2018 (UTC) I'd be fine with 250+, yes. Headbomb {t · c · p · b} 22:48, 17 January 2018 (UTC) Update. Templates with more than 200 transclusions appear to have now been semi-protected. – Uanfala (talk) 00:43, 31 January 2018 (UTC) The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


A Bot for Creating Arthropod Stubs[edit] I am interested in adding about 17,000 new stub articles for arthropod species. These can be added over a period of a several weeks or a few months with a bot. The article content is significantly better than the minimal stub frequently seen on these and similar Wikipedia topics. In my mind, these stubs will serve three primary purposes: They will give users some idea of the organism, including references and, if available, a photo or two. They will make online and print references available to users. They will contain enough material to make it convenient for editors to expand the article. A casual editor can spend significantly less time expanding an existing article than creating a new one, because it takes time to learn and work with the various templates and other "standards". An article with online references makes it even more likely for the article to be expanded into a start-class or better article. I have requested and received positive input from the Arthropods and Tree of Life projects. I have been manually posting new stub articles generated for a variety of arthopods, primarily insects and spiders, over the past few weeks at the recommendation and encouragement of project members and interested editors. I have received positive feedback, and the stub quality has evolved and improved significantly. Several of the stubs have already been expanded by various editors. User_talk:Edibobb#Welcome! User_talk:Edibobb#Comments_on_your_stubs User_talk:Edibobb#Speciesbox Wikipedia_talk:WikiProject_Arthropods#Adding_Species_Stub_Articles Wikipedia_talk:WikiProject_Tree_of_Life#Adding_Species_Stub_Articles Today I applied for approval for bot operation, and was directed to the Village Pump for more discussion. Operation Details VB source code is available at User:Qbugbot/source. Species selection The ITIS has most long-established arthropod species in its database, although it does not have many of the newer species and may not reflect recent reorganization of genera and higher taxa. The species in Bugguide generally reflect the latest research, and are limited primarily to species photographed or collected in North America by its users. By selecting the species that appear both in ITIS and Bugguide, we end up with a set of non-controversial species (from a taxonomic standpoint) that are not overly rare or obscure. 35,000 arthropod species are in bugguide. 23,000 of these are in ITIS (out of 250,000 total arthropod species in ITIS). 17,000 of these have no Wikipedia article. Article creation Articles are created in the following steps: A taxobox template is created using the (taxonomic) ancestry of the "bug", selecting appropriate ranks for the taxobox. For example, subfamily should be included except in Lepidoptera with no subfamily common name. An image is included if available. Synonyms are added if they appear in the ITIS database. (Other catalogs may have ridiculous numbers of synomyms.) A text introduction is generated, such as "Andrena perarmata, the well-armed andrena, is a species of mining bee in the family Andrenidae," giving the scientific name, common names (if any), taxonomic rank, an ancestor's common name, and the scientific name of the family or order. This is followed, as available, by the distribution range, the IUCN conservation status, Hodges number, ITIS taxonomic notes, additional images, and a list of taxonomic children (if any). If there are too many children, a link to a separate list page (created afterward) is included. The distribution data comes from ITIS, World Spider Catalog, or Odonata Central. References may include inline citations, general references, further reading, and external links. A Wikimedia Commons template is added if there are photos, a Taxonbar is added if Wikidata has this bug listed, the appropriate Wikipedia category is selected, and the proper stub template is selected for the talk page. Article upload Articles are created on demand for upload. An article will be uploaded only if no article exists for that title. If one does exist, the article will be skipped. No existing articles will be altered. If the taxonomic parent of an uploaded article does not exist, it will be generated and uploaded. If a list of more than 100 "children" is included in the article, it will be split off as a separate list article. A talk page with the proper stub template is created for each article. Manual verification During the test period, every article created will be viewed on Wikipedia to verify that it exists, it is the correct article, and the information is proper. Later on, the text of all the day's articles will be downloaded and verified manually or automatically. At least one article daily will be manually viewed on Wikipedia. Sample articles Here is a list of some random test articles generated and manually posted on February 1. Acmaeodera decipiens Acmaeodera hepburnii Agrilaxia flavimana Amara pseudobrunnea Antrodiaetus pugnax Apsectus hispidus Arhyssus Arhyssus scutatus Bassareus detritus Bembidion salebratum Blissus insularis Boopedon Boopedon auriventris Cannaphila insularis Chalepini Chrysobothrini Chrysobothris breviloba Chrysopilus velutinus Coenosia atrata Conophthorus Conophthorus edulis Crabro cingulatus Culex territans Dichagyris neoclivis Digrammia atrofasciata Exoprosopa painterorum Furcula scolopendrina Glena quinquelinearia Homochlodes disconventa Homorthodes dubia Icterica circinata Leptinus Leptinus orientamericanus Leucorrhinia patricia Melanocanthon Melanocanthon nigricornis Myrmex floridanus Nemadus brachyderus Neoterpes ephelidaria Opomydas Opomydas townsendi Paracapnia Paracapnia opis Patrobinae Patrobus cinctus Pissonotus Pissonotus brunneus Plataea californiaria Platysoma Platysoma gracile Plectoptera Plectoptera picta Promachus painteri Psammodiini Psammodius Psammodius basalis Rhamphomyia nasoni Sumitrosis Sumitrosis pallescens Tesagrotis corrodera Bob Webster (talk) 05:27, 3 February 2018 (UTC) Qbugbot discussion[edit] In general, we strongly discourage the creation of one-line stubs, whether by human or by bot; experience has shown that they're rarely if ever subsequently expanded, and just end up being unwatched (and consequently vandal-magnet) clutter that clogs categories, makes Special:Random unusable, and gives Wikipedia a bad reputation. Is there a specific advantage in this case (a) to having an individual microstub article for each of these species rather than a few long lists from which individual articles can be created and linked if there's enough to say about a particular species to justify a stand-alone article, and (b) to doing it on Wikipedia (which really isn't designed to handle this kind of thing) instead of on Wikispecies (which is)? If you haven't already, I'd recommend reading Wikipedia:Village pump (policy)/Archive 66#Automated creation of stubs, which is the thread that created the current policy when it comes to mass article creation, and ensure that you have an answer for every objection that was raised back then. ‑ Iridescent 09:02, 3 February 2018 (UTC) Many of these concerns/questions are addressed at m:Wikispecies FAQ (which I found at this BRFA by Ganeshk that occurred relatively shortly (7 months) after the archived VPP discussion linked above). I'm sure we can find many examples of good and bad bots. The key is rigorous community vetting, which I think has been, and is, going on.   ~ Tom.Reding (talk ⋅dgaf)  14:44, 4 February 2018 (UTC) I strongly support use of this bot, after a proper careful test phase (as planned above). So far, what I've seen seems reasonable. The linked discussion is from 2009 and we're 9 years past that; the objections there seem vague. Articles are articles, it doesn't matter if a bot or a human or a dog or a devil makes them: they have to be judged by their merits. The stubs generated by this bot seems still better than having nothing. cyclopiaspeak! 11:44, 3 February 2018 (UTC) Make sure that the bot is posting accurate information; we have had bad luck in the past with mass created species articles being full of errors. I am also minded to oppose any mass creation of one line stubs; please try to add some more information. Jo-Jo Eumerus (talk, contributions) 12:02, 3 February 2018 (UTC) Support as long as you use Template:Speciesbox (edit | talk | history | links | watch | logs) . These seem better than stubs, almost start. Nessie (talk) 13:25, 3 February 2018 (UTC) Today I changed over from Taxobox to Speciesbox (and Automatic taxobox for higher ranks). It involves adding to the Taxonomy templates, which should help reduce "unrecognized" messages editors might encounter using the Speciesbox. Bob Webster (talk) 05:22, 4 February 2018 (UTC) Super! thanks @Edibobb:! Nessie (talk) 23:11, 4 February 2018 (UTC) As noted in the previous discussions, I also support this bot concept. Those are high quality species stubs, rich in refs; you can't tell me something like Leptinus orientamericanus isn't useful for the reader, even if there's only one line of text proper. The genus and higher level articles with their taxa lists should be particularly welcome. - But we really should make sure these do not have to pass through the NPP queue; otherwise I think this would singlehandedly murder the backlog situation. --Elmidae (talk · contribs) 18:00, 3 February 2018 (UTC) Tentative support: those seem like pretty high quality species stubs, but I am concerned what impact this would have on New Page Patrol. We have just fought down from a massive backlog (22,000) to something more reasonable. We still don't have a handle on it yet, with the backlog having stalled around 3.5k. These stubs will need to be reviewed by a human New Page Patroller for errors. At the very least the articles should be spread out over a period of several months so as not to overload NPP (for 90 days that is still 188 added per day, for comparison we currently have to review around 350 each day to keep up). Not banging the concept, but don't bury us in new articles (even if they turn out to be almost entirely good ones). I generally Oppose granting the bot autopatrolled. These articles should be reviewed by a human at least once IMO. Dragging it out over a few months will be fine (although I think it would be ideal if all the bot-added articles for the day were added at the same time on that day, so that they are stacked up and can be reviewed as a single block easily). Insertcleverphrasehere (or here) 19:43, 3 February 2018 (UTC) Indeed. Unless you all trust the bot enough to grant it the Autopatrolled user right, please don't do it. You'll kill WP:NPP. Mduvekot (talk) 20:03, 3 February 2018 (UTC) If the bot is granted bot it will have autopatrol, so the articles would not show up in the NPP queue. — JJMC89 (T·C) 20:12, 3 February 2018 (UTC) Support, and support granting the bot autopatrolled status, on the basis of the example articles shown above. One minor point: in Arhyssus scutatus, the markup included {{taxonbar|from=Q10417852}}; {{taxonbar}} will suffice, as shown here. It's a pity that {{Taxobox}} doesn't yet pull its data from Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:28, 3 February 2018 (UTC) Concerning adding the Q codes to {{taxonbar}} @Pigsonthewing:, and perhaps @Tom.Reding: can answer this better than i, but I believe the movement in this direction is to better track and maintain taxa with upcoming maintenance categories. Nessie (talk) 23:25, 3 February 2018 (UTC) The change I suggest should make no difference to that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 01:30, 4 February 2018 (UTC) Thanks for the information on the Q codes (and the support). The problem I had was that unless the Q Code was specified, the taxonbar did not appear on about half the pages. I don't understand why, so I've just been adding the Q code to everything I can. Bob Webster (talk) 05:22, 4 February 2018 (UTC) Could you specify a page this happened on (or will happen on the next time you notice it) so that we may try to recreate this behavior? Perhaps it's just lag between Wikidata, Wikibase, and Wikipedia for newly created pages? It looks like it could just be a lag. I removed the Q code from some pages created a few days ago, and taxonbar showed up fine (except for a couple without Wikidata records, which had no Q code to begin with). I did the same on some pages created yesterday (Acinia picturata, Schizura badia, and Eucapnopsis), and the taxonbar was not visible without the Q code. Bob Webster (talk) 15:40, 4 February 2018 (UTC) While the |from=/|from1= parameter is not required for {{Taxonbar}}, it is desired from a tracking perspective. |from=/|from1= should only be removed if the Wikidata entity (Q code) has no relation to the page (i.e. it was erroneously added to {{Taxonbar}}).   ~ Tom.Reding (talk ⋅dgaf)  06:14, 4 February 2018 (UTC) The parameter - which affects the data displayed - should not be replied upon for tracking; to do so may have unintended consequences. Consider, for example, the case where a duplicate is detected and so Wikidata items merged, or the Wikipedia link is moved to a more apprpriate item in Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 4 February 2018 (UTC) Yes, that is an intended consequence, and precisely what we want to track & check. The behavior of {{Taxonbar}} has changed in the last month or 2, largely due to the efforts of Mellis, Ahecht, Peter coxhead, and community discussions. One of the improvements is that the primary Wikidata entity is always displayed as the top row, regardless of |from1=. Also, no duplicate entities are ever displayed. Discrepancies are shunted to one or more tracking categories (though not yet live). There is no tracking category for duplicate |from#= values, and it should probably be added in the future (though it's not a priority now since this is a very fringe case). For more info I encourage you to read through the discussions at Template talk:Taxonbar.   ~ Tom.Reding (talk ⋅dgaf)  15:56, 4 February 2018 (UTC) Did you try purging the affected pages? And items? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 4 February 2018 (UTC) Conditional Support, after discussion/consensus on the usage of (or disusage, or apathy towards) standard WP:CS1 templates like {{Cite journal}}, {{Cite book}}, {{Cite web}}, etc., by WP:ARTH and/or WP:TREE. This was alluded to at WT:ARTH#Adding Species Stub Articles by Jonesey95 (only recently, however, and VPP is a more active venue than WP:ARTH anyway). Personally, I'd prefer full CS1 usage for maintenance and standardization. However, I also realize that most of the other arthropod stubs probably (I haven't checked) also use a mix of free-form & CS1, but that doesn't mean that pattern has to continue. I defer to the collective judgement of WP:ARTH/WP:TREE in the end, and am in full support (including WP:Autopatrolled status) as long as the resulting consensus is followed by the bot!   ~ Tom.Reding (talk ⋅dgaf)  14:24, 4 February 2018 (UTC) Thanks! I've converted the bot to use {{Cite journal}}, {{Cite web}}, and {{Cite book}} for all references. Bob Webster (talk) 04:10, 7 February 2018 (UTC) Bob Webster, well done! I was just going to post to WT:TREE for more attention, but now there's no need. Could you link to 10+ pages your bot would have created—perhaps you can overwrite existing pages you created, that have no other intervening edits, with the new code incorporating CS1 templates? Preferably ones that are representative of the possible spectrum of the different sources drawn upon (i.e. all 10 using identical sources wouldn't be helpful). The templates can get very exacting sometimes. Creating a separate subsection below or within #Sample articles for these would be helpful too for others just coming to the discussion.   ~ Tom.Reding (talk ⋅dgaf)  18:28, 7 February 2018 (UTC) I've added some sample articles below, and would welcome any comments or suggestions. Bob Webster (talk) 02:07, 8 February 2018 (UTC) Also, in case you'd like to scan a lot of the references, I left a few hundred of them (about half I'm using) here. I was using Wikipedia to point out some invalid fields. I'll try to leave them for a couple of days. Bob Webster (talk) 06:55, 8 February 2018 (UTC) Support, but please use the automatic taxobox system ({{speciesbox}} for species, {{Automatic taxobox}} for higher level taxons); this requires making sure that appropriate taxonomy templates exist (also a task a bot can do) down to the genus level - see Template:Taxonomy/Polycestinae for a sample. עוד מישהו Od Mishehu 07:47, 5 February 2018 (UTC) Thanks! The bot now uses {{speciesbox}} for species and {{Automatic taxobox}} for higher level taxons. The higher level templates are added as necessary. Bob Webster (talk) 04:10, 7 February 2018 (UTC) weak support The samples above do look to be adequate stubs and are better than some of the work people come up with. I would prefer not to put in pages that are too small. However someone should look at the page at some point to see if it is OK. Graeme Bartlett (talk) 06:33, 7 February 2018 (UTC) I've added a new list of sample articles below. The latest source code is available at User:Qbugbot/source. Thanks for the suggestions! Please let me know if you run across anything else. Bob Webster (talk) 19:32, 12 February 2018 (UTC) Qbugbot sample articles[edit] Here is a list of some random test articles generated with qbugbot and manually posted on February 12. They now include changes recommended below by Trappist the monk, Tom.Reding, and Elmidae. These are the latest of about 2,000 arthropod stub articles that have been generated by qbugbot and posted manually since the first of the year. Bob Webster (talk) 19:29, 12 February 2018 (UTC) Agonum nigriceps Amblytylus Amblytylus nasutus Andrena erythrogaster Anthonomus lecontei Araneus trifolium Axion Axion tripustulatum Bicyrtes viduatus Calycomyza solidaginis Carphoides incopriarius Celithemis verna Ceuthophilus chiricahuae Chrysotimus delicatus Coelioxys banksi Colydium Colydium robustum Corythucha juglandis Cucullia eulepis Dialysis dispar Dicranoclista Dicranoclista fasciata Dictyna foliacea Efferia latruncula Excirolana Excirolana chiltoni Glaucina lowensis Haematopota rara Hogna baltimoriana Hyperaspidius Hyperaspidius vittigerus Hyperaspis dissoluta Isoperla bilineata Keroplatus Keroplatus militaris Lebia perita Leia bivittata Lethe anthedon Melanoplus huroni Microphotus Microphotus decarthrus Neomegamelanus Neomegamelanus lautus Notiophilus intermedius Omophron solidum Orchelimum fidicinium Orthosia transparens Pachyceramyia Pachyceramyia robusta Perdita rivalis Poecilus chalcites Psen erythropoda Pterostichini Rhynencina longirostris Rivellia munda Salina Salina mulcahyae Sphecodes mandibularis Symphoromyia hirta Tachytes intermedius Tricholochmaea rufosanguinea Ululodes Ululodes floridanus Grabbing one at random - Tricholita chipeta - I do wonder if whatever algorithm selects the "Further reading" is really on the level. There's a number of "Further reading" entries here that seem irrelevant, e.g. this, which deals with two species in the same family but has no further connections. How are these determined? This kind of thing should be avoided. - Otherwise looks good, I think. --Elmidae (talk · contribs) 07:48, 8 February 2018 (UTC) You're right. This reference and a lot of others have been assigned too broadly. The way it has been done is that the parent of the important taxon (the genus, in this case) is selected and the reference is assigned to all its descendants (in this case, the subfamily Noctuinae). But it's a huge subfamily, and there are over a thousand descendants! Needless to say, these two new species are not applicable to most of them. I'm reassigning a few hundred references to take care of situations like this. Bob Webster (talk) 15:27, 9 February 2018 (UTC) I couldn't find anything automatically amiss with these; only 5 not-worth-the-edit minor WP:GenFixes were found on as many pages. Manually, Anthaxia viridifrons, Melanophilini, Phaenops californica: had CS1 main tags due to |date=2008-2009, which should simply use an en dash instead of a dash. Use of volume & number params too (tho I'm not sure whether or not an en dash was needed for |number= since "No." was used previously). Smicronyx spretus, Lacinipolia triplehorni, and others: if the url is a doi, it'd be useful to include it as a doi too (I think there are bots that do this) Hermetia hunteri, Lobophora nivigerata, and possibly others: are |pages=475/|pages=1016 the # of pages in the books? (they shouldn't be! should be the location of the supporting material only; otherwise it doesn't belong; I left it alone for now) Lacinipolia triplehorni, Metalectra bigallis, and others: periods are used after initials in some templates, but not others. Can you standardize this usage on a page-by-page basis? (no explicit error here, just a suggestion) Sphaeroderus bicarinatus: |pages=323 + 22 plates looks odd, but I have no suggestions for anything more appropriate. Can anyone else comment on this? (|id= exists, but doesn't look appropriate) Also, trailing periods (i.e. |publisher=Houghton Mifflin Company.) aren't needed in CS1 templates (other than for abbreviations), as the template takes care of all otherwise-superfluous punctuation. No errors found regarding this, just fyi to help avoid potential future errors. I should also say - well done! And so quickly too.   ~ Tom.Reding (talk ⋅dgaf)  17:59, 9 February 2018 (UTC) Bellamy is not a journal so {{cite journal}} for that is inappropriate. Because it comes in five volumes, mixing book's volume designation with the publisher's series issue number seems non-nonsensical: 1–5 (76-80) implies that we mean issues 75–80 from each of the five volumes. cs1|2 does not support the notion of series numbers. Pensoft is the publisher; series, if it is necessary, is Faunistica. Similarly, Nelson, et al. is also a book, not a journal; The Coleopterists' Society is the publisher. urls to dois should generally not be placed in |url= when there is |doi= because that constitutes overlinking and because most most dois are behind paywalls (|url= is generally considered free-to-read). When the doi is free to read, the citation should be marked with |doi-access=free |pages=323 + 22 plates looks like the total-number-of-pages-issue that was mentioned so should not be done publisher names do not include corporate designations: 'Company', 'LLC', 'Ltd', 'Inc', etc —Trappist the monk (talk) 13:21, 10 February 2018 (UTC)


Audio samples on articles related to languages[edit] I noticed that the article about the German language has a spoken audio sample, but many other language-related articles (like Spanish) don't. Would it be good to add audio samples to other articles describing languages (including English dialects)? I find them useful since they help to form a picture of how the target language sounds. --Sir Beluga 16:26, 9 February 2018 (UTC) You could tag the talk pages with {{Audio requested}}. Nessie (talk) 21:26, 10 February 2018 (UTC) Hello, Sir Beluga! You can find audio samples here, and more specifically here. Good luck! --NaBUru38 (talk) 00:44, 15 February 2018 (UTC)


Providing some way to easily spot when controversies or criticisms are removed or reduced[edit] Hi I have found several articles over the years where the Controveries or Criticisms sections of articles (mainly companies and politicians) has been deleted by IP editors (most probably who have very direct COI) with innocuous editing summaries like 'copyediting' or 'grammar fixes' and it hasn't been caught by people watching the pages (or no one is watching the pages). I wonder if there is some way to flag this? Perhaps there can be a bot that checks for where section headings or large chunks of text related to controversies and criticisms have been wiped and flags them somewhere for review? Thanks John Cummings (talk) 13:10, 11 February 2018 (UTC) Oppose per Wikipedia:Criticism: in many cases separate Controversies or Criticisms sections are symptomatic of bad article writing (with "troll magnet" as a further symptom) – it is not up to a bot to impose such bad writing. At least, the bot would not be able to distinguish between cases where the controversies and/or criticisms should better be integrated in the main narrative of the article, and where they deserve a separate section. The separate section option should be a very rare exception (while indeed, "troll magnet"): the fact that it is not a too rare exception speaks to the lack of quality of many of these articles: the overall quality of the article is what needs addressing in most cases, and in a way that can hardly ever be operated by a bot or otherwise bot-assisted. I'd support a bot removing "Controversies" and "Criticisms" section titles for those articles where there never was a talk page discussion on whether such separate section should be present in the first place. That would be a bit unrealistic as a bot task, but still I'd rather support that than what is proposed in the OP. --Francis Schonken (talk) 13:43, 11 February 2018 (UTC) This seems to misunderstand the proposal, which talks about flagging such edits for human review, not about automatically reverting them. As for the essay Wikipedia:Criticism, it makes valid points about formatting and style, but the reality is that the section layout that it criticizes is still widespread for the time being, and I understand the proposal is about detecting content removals, not layout changes. Regards, HaeB (talk) 14:56, 11 February 2018 (UTC) Still, oppose the whole idea: an edit *starting* a separate Controversies or Criticisms section should be flagged, not the edit that deals with the more often than not undesirable separate section. Imho "... still widespread ..." is part of the problem (as I explained above), not something for which we should seek a status quo: the flagging would not occur when a troll expands a Controversies or Criticisms section with WP:UNDUE details, but when such trolling would be removed it would get flagged. A no-no for being too supportive of more often than not deplorable article content & layout. --Francis Schonken (talk) 15:37, 11 February 2018 (UTC) @Francis Schonken:, I'm sorry I'm not being clear, I'm looking for ways to flag for a human to look at instances where controversies and criticisms have been removed, which is often done by IP editors with probable COI (see the UK parliament IP edits as a good example of continued PR removal of information over many years). I'm suggesting these common sections are a good place to start looking for this kind of activity, rather than being the only place to look for it (however you feel about their existence). — Preceding unsigned comment added by John Cummings (talk • contribs) No, you were perfectly clear and I oppose it, for rather protecting WP:UNDUE criticism than countering it; and not protecting criticism that is in the article conforming to the Wikipedia:Criticism guidance, and protecting (often trollish) content in a separate section. The approach is unbalanced towards bad habits ("troll magnet" is a far more widespread problem, and established as a problem for a much longer time than IPs removing criticism that would pass WP:DUE). --Francis Schonken (talk) 17:03, 11 February 2018 (UTC) I agree that such edits (with deceptive edit summaries) are a problem. FWIW, there are already the "section blanking" and "references removed" edit tags. Regards, HaeB (talk) 14:56, 11 February 2018 (UTC) Still: rather protective of the often undesirable separate Controversies or Criticisms section instead of addressing the layout issue. --Francis Schonken (talk) 15:37, 11 February 2018 (UTC) @Francis Schonken:, I appreciate your point that criticism and controversy sections may be being overused and sometimes should be moved to different sections, but this isn't a discussion about that. Its a discussion about finding a way to better find and flag for review COI edits which remove information that is accurate and within the scope of Wikipedia. I am suggesting that one way of surfacing these edits is by paying attention to what happens in these sections. Thanks, John Cummings (talk) 16:47, 11 February 2018 (UTC) Re "this isn't a discussion about that" – that's why the point needs to be mentioned, while your proposal would mess (i.e. in a less than desirable way) with something that is already a long-time problem. --Francis Schonken (talk) 17:03, 11 February 2018 (UTC) Sounds like a good idea for an edit filter. I don't think this would be too difficult to implement, although it might just duplicate to role of Special:AbuseFilter/172 anyway. Kb.au (talk) 15:06, 11 February 2018 (UTC) Thanks @Kb.au:, does the existing section blanking filter account for if the whole section is removed including the heading? John Cummings (talk) 16:33, 11 February 2018 (UTC) Specifically it detects the removal of a section heading. Personally I don't see any advantage to highlighting the removal of Criticism sections over any other. I also agree with those who think these sections are usually problematic anyway. -- zzuuzz (talk) 17:48, 11 February 2018 (UTC) Thanks @Zzuuzz:, so the abuse filter already displays this kind of activity, its just that people aren't catching it. Is it that there are just too many edits happening for someone to see them all? I can see that some of the ones I've seen could be seen as OK edits, but not many, thinking about UK PMs for instance, many edits happen where people try and delete the expenses scandal section and sometimes it doesn't get reverted. John Cummings (talk) 18:24, 11 February 2018 (UTC) I can't say if people are catching it - knowing people they probably are - but it's correct they're already flagged along with other section blanking. Who's to say that removal of a criticism section is worse than removal of a section by any other name - criticism, praise, achievements or otherwise? (I note "Expenses scandal" is a common section header for UK politicians). Such a filter may be useful to detect problematic sections, but I would not like to think of it as a 'revert list', as it would become, which whether intentional or not is precisely how you just described it. -- zzuuzz (talk) 19:09, 11 February 2018 (UTC) Not a good idea Such sections are generally a bad idea anyway. North8000 (talk) 18:54, 11 February 2018 (UTC) Interested could we get a trial edit filter to see what the scope of the issue is? If editors are restructuring controversies, i.e. incorporating elsewhere in the article as suggested, that's one thing. But I've seen advocacy editing more than once that simply deletes such material. Examples here and here. It's fairly common for this kind of wikiwashing job to be advertised on one of the job boards. ☆ Bri (talk) 19:40, 11 February 2018 (UTC) Problematic at best "Criticism" sections tend to be pretty much entirely negative and of UNDUE weight, pretty much in every case. In many cases, they use sentences giving what appears to be a Wikipedia imprimatur to the "criticism" which is contrary to a bunch of policies. Typically we see "George Gnarph claims A, but everyone knows that A is false." type edits. Collect (talk)  Comment: Perhaps an alternative proposal to try and address the same problem would be to look at edits with a large number of characters removed where certain words appear, e.g criticism, scandal, illegal, conviction etc. John Cummings (talk) 09:42, 12 February 2018 (UTC) Re. "... removed ...": "... removed or added ..." I'd say. I'd oppose any approach that is more sympathetic to futile criticism being added than such criticism being removed. Again, adding exaggerated & WP:UNDUE criticism is more often than not the elephant in the room, and across many articles the bigger problem. The "section blanking" tag, which is over-all a good idea, already has a bit of an undesirable side-effect of rather protecting against deletion of unwanted criticism sections, than against creation of such sections based on dodgy verifiability (often introducing WP:BLP problems, etc, into an article). I can live with that side-effect because of the over-all advantages of that tagging. But oppose further imbalances in maintenance systems favouring *the more problematic* additions over often *less problematic* deletions: currently, if someone merges criticism from a separate section to the main narrative of the article, and deletes the undesirable section header, that gets tagged as "section blanking": don't push it, I'd say. --Francis Schonken (talk) 10:09, 12 February 2018 (UTC)


Disable messages left by InternetArchiveBot[edit] The community has spoken and the Support votes have it! The proposal passes, and the messaging functionality for InternetArchiveBot has now been turned off. ~Oshwah~(talk) (contribs) 16:58, 18 February 2018 (UTC) The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion. This topic has seen a lot of debate, but I think we might want to consider turning off the function that leaves messages on talk pages. See user:InternetArchiveBot for context. This talk page shows a typical instance of the bot's messaging process, which it does after redirecting a dead link to an archived copy of a dead web page hosted at the Internet Archive. The bot has posted hundreds of thousands of these messages on various Wikipedia article talk pages since 2016. Why? IABot's error rate has dropped to near negligible numbers. Users really interested in checking the edit, will do so without being asked to. If the bot did make an error, with IABot's newest upgrade in v1.6, simply reverting the bot is enough to report a bad edit as a false positive. Question for you guys, should I turn off the bot's messaging feature? — Preceding unsigned comment added by Cyberpower678 (talk • contribs) 19:51, 11 February 2018 (UTC) Yes[edit] Support The costs of the bot posting messages to the talk page are significant and outweigh the benefits. Every time a user engages with a message, either by reading it, scrolling past to ignore it, or following its instructions, that user is donating time and labor to Wikimedia projects. If a message on average consumes 1 second then if there are 500,000 messages, that is 140 hours of labor in this. Since the messages remain in place for years I think that they actually consume perhaps 30 seconds each on average over the course of their lives, meaning that the crowdsourced checks from this messaging system are consuming thousands of user volunteer hours. If anyone advocates for keeping this messaging system in place then I call on those people to make their best estimates of the labor costs to keep the messaging system. I previously raised this issue in March 2017. In October 2017 other people discussed this. Now the situation is even more clear, as we have evidence that the bot almost never makes mistakes. Also, now this bot can get alerts from history log revisions, which means that communication need not happen on the talk page and can instead happen by undoing or reverting its edits. Whenever any bot is going to do anything on wiki 100s of 1000s of times, we have to be very careful to estimate and measure how much wiki crowdsourced labor those bot actions will consume. In general, bot actions cannot be a time sink for human attention, and whatever a bot does needs to relieve human time, not accumulate it. The costs of keeping talk page messages outweigh any benefits which I have seen anyone describe. I feel that in the past, people who have advocated to keep messages have in their mind that the value of wiki volunteer time is 0, or that they refuse to acknowledge that it is possible for wiki editor human attention to have a value worth quantifying. In fact, our human labor is extremely valuable and we have to protect it. IABot is awesome, thanks everyone for developing this project both technically and socially. Blue Rasberry (talk) 20:01, 11 February 2018 (UTC) Support per nom and Blue Rasberry, and let's not forget the costs to the operator and the WMF of making, storing, and displaying those article talk page edits.   — Jeff G. ツ 20:32, 11 February 2018 (UTC) Support the standard revision history is sufficient. power~enwiki (π, ν) 20:35, 11 February 2018 (UTC) Support. I never quite saw the reason to do these as hardly anyone reviews them. The argument was that they would be... but I don't think there's any evidence for it. There's millions of dead links and thousands every month. I doubt these messages are being reviewed. —  HELLKNOWZ   ▎TALK 21:21, 11 February 2018 (UTC) Support It's essentially a duplication of effort for the bot and the readers of the talk page messages. Nihlus 21:23, 11 February 2018 (UTC) Support Yes please. They're a victim of the bot's own success, and have been rendered unnecessary. ~ Amory (u • t • c) 21:57, 11 February 2018 (UTC) Support Every edit made by IABot, every archive link it adds, is checked and verified by WP:WAYBACKMEDIC. I happen to know exactly what the error rate is :) It's small enough that it would drive a human a little bonkers trying to look through the good ones for a bad one. Also, IABot has an online tool, API and database where much of this information is available. If someone wanted to know "Show me all archive links in an article modified by IABot", that information is available, a simple tool could be made to display it without needing clutter the talk pages. -- GreenC 22:30, 11 February 2018 (UTC) Support Assuming a very low error rate. @GreenC, Cyberpower678: what is it?   ~ Tom.Reding (talk ⋅dgaf)  23:15, 11 February 2018 (UTC) My error rate is based on the number of incoming false positive reports in relation to the overall edit rate. Ever since IABot v1.6 was deployed, it would automatically detect reverts made by a user, identify the reverting user, and report every link change reverted as a possible false positive for me to review. Of the reports that came in, only 3 or 4 were actually false positives. Since GreenC says he has the exact number, I'll let him answer that question.—CYBERPOWER (Be my Valentine) 00:07, 12 February 2018 (UTC) Well.. now someone had to ask :) It's complicated. One problem is I can't say this bad link was added by IABot and not someone else. It doesn't go through revision history. Roughly speaking though, WaybackMedic is able to "do something" with about 2% of the archive links, to fix problems. "Do something" might mean remove the archive because it doesn't work, adding an archive to a dead link, changing to a different archive service, changing the timestamp, modifying the URL encoding, removing garbage characters in the URL (eg. trailing ":" at the end of a URL), etc.. However many of these the root cause has nothing to do with IABot. Anyway, I can verify about 98% of the archive links in the system are working and WaybackMedic can then fix to bring it over 99% (except for soft404 or verifying content matches the cite, which require human checks). -- GreenC 03:36, 12 February 2018 (UTC) Support but last one I checked Talk:List of Mountain Bothies Association bothies#External links modified (January 2018) seemed entirely wrong to me. I expect the referenced website was down at the time of checking. There seemed to be no feasible way to report the problem so the message on talk didn't help. Thincat (talk) 23:37, 11 February 2018 (UTC) There is a feasible way. Revert the edit. IABot will catch it and auto-report on your behalf.—CYBERPOWER (Be my Valentine) 00:07, 12 February 2018 (UTC) That's good then because that is what I did. I didn't realise that would happen. Thank you. Thincat (talk) 08:14, 12 February 2018 (UTC) Weak support, or perhaps keep the notification process but put the text in an envelope so those that wish can open and review. GenQuest "Talk to Me" 04:23, 12 February 2018 (UTC) Support, thanks for the ping Bluerasberry. Chances are, it'll get checked sooner or later by someone invested in the topic. There may be times when it would be useful, but by and large this seems a superfluous feature. I reiterate my comment from the last time I weighed in on this by saying there's usually, if not always, plenty of space for the bot to write in a link for users to ping for false positives, à la ClueBot NG. With OP's comments that a simple reversion works exactly the same way, however, I find my comments have even more force to them. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 05:28, 12 February 2018 (UTC) Support I see these messages all over the place, with scarcely any feedback. I have checked a couple, but I am unlikely to check any more. All the best: Rich Farmbrough, 13:14, 12 February 2018 (UTC). Support turning it off except for actually useful messages. We do not need pointless botspam about having done trivial things like provided an archive URL for a cite that didn't have one, and other non-controversial actions. If it is not highly likely to need human review, then don't pester the talk page about it. It triggers an endless stream of watchlists for no reason, and is very annoying.  — SMcCandlish ☏ ¢ 😼  17:47, 12 February 2018 (UTC) Support, this is mostly clutter on zillions of talk page. Use an edit summary link instead, pointing to an info page if needed. Headbomb {t · c · p · b} 18:36, 12 February 2018 (UTC) Support (slightly reluctantly). They're noisy, both on talk and in everyone's watchlist, eat precious editor attention, hang around forever, and serve very little purpose given a presumably very low error rate. I would very much like an alternate "gnoming facilitator", but on the balance I think the downsides far outweigh that one positive. Especially since, in my experience, the wast majority of the messages are simply ignored: a potential, but unrealised benefit does not outweigh actual downsides. --Xover (talk) 19:13, 12 February 2018 (UTC) Support for the same reasons others have voiced. It clutters talk pages and is not particularly controversial. Killiondude (talk) 05:38, 13 February 2018 (UTC) Summoned by ping Turn it off. While i understand Xaosflux's argument that the monetary/computing costs are low, i believe the human/time costs are too high. These messages quickly become mere noise, so are skipped over, i believe, leading to no great benefit in leaving the message; if a person is going to check what the bot has done, he is probably going to do so in the presence or absence of a message, likely having been drawn to the page by watchlist or by checking the history of the article. Happy days, LindsayHello 09:05, 13 February 2018 (UTC) Support It is very annoying and unnecessary with little benefit, (if there's any). I almost asked for this, but on searching archives and seeing many people had asked without success, I gave up. Please stop it ASAP. –Ammarpad (talk) 10:26, 13 February 2018 (UTC) Support per SMC. Ealdgyth - Talk 14:33, 13 February 2018 (UTC) Support as this is too trivial to bring up on an article's talk page. The overwhelming majority of these talk page posts I've seen are ignored, and to most editors they appear to serve no other purpose than to create clutter. The situation is similar to other cases where it's desirable for minor edits to be reviewed for errors, like Cluebot's reverting of vandalism, or human editor's fixing of links to disambiguation pages (for the dabfixes that end up on my watchlist, the average error rate is an order of magnitude higher than the stated upper limit to this bot's error rate, and yet no-one would want to see a talk page post for every dablink fixed). The only useful feature of these talk page posts is that they allow an editor to mark up the archive link as checked, so that other editors don't have to waste time checking again. But realistically, such surplus of eager editors is likely to available only on the most popular articles; and at any rate, any way of marking an archive link as "reviewed by human" had better happen in the link template itself (rather than on the talk page). – Uanfala (talk) 19:30, 17 February 2018 (UTC) No[edit] leave it on I often check the archiving, and in contrast to what WAYBCK medic may think, a significant proportion, perhaps 10% of archiving has failed to produce a useful result. Sure there is often a page archived, but it may be a database query page with no database behind it, an error message saying the page does not exist, a domain squatter message, or a shell of a page with all the dynamic content missing. In these sort of cases it is much harder for a bot to figure out something went wrong, and a human can easily see. Then they need to track down where the page or database went. The bot message gives a suitable summary that enables observing the results easily. Just looking at the page edited is much harder, as you have to find the needle in the haystack of the modified link. Perhaps the message could be less verbose taking up less real estate on the talk page though! Graeme Bartlett (talk) 22:52, 11 February 2018 (UTC) This is a trivial problem. The solution to it is to have a page where the bot logs these things, and the gnomes who want to clean up after them can watch that page. On an article by article basis, it makes no difference. An article with a valid source is 100% as validly sourced if the bot adds an unhelpful archiveurl; this is not something that particular article's watchlisters need to be notified about, and they'll already see it in the edits to the article anyway; being verbally notfied about it is just spammy and pointless.  — SMcCandlish ☏ ¢ 😼  17:50, 12 February 2018 (UTC) leave it on, The bot’s activities are unique among bots, in that they often require checking. The bot is dumb. It can check for a dead link but it cannot check if there is a better link: maybe the site has reorganised its archives, or is at a new domain address, or even a search turns up a better one. For references this is not as important – a reference can be verified from an archive link. But external links are generally meant to be the best, so the current and most up to date, links for that subject. So having the bot report what it’s done is essential, to ensure editors have the chance to check it. If the messages are not posted the danger is the bots edits will not be noticed, and opportunities to fix old links will be overlooked. I updated a couple of articles’ links only two days ago - My Love Is a Bulldozer and My So-Called Life (Venetian Snares album) – and would almost certainly not done so if there was no talk page report, just an entry in the page history.--JohnBlackburnewordsdeeds 23:04, 11 February 2018 (UTC) I'm not sure how I feel about you calling my bot dumb. If you knew how much code and intelligence goes into this, just to do what it does now, you'd change your mind. Unfortunately, the bot can never determine what would be a better link as it would need google class infrastructure to pull that off.—CYBERPOWER (Be my Valentine) 23:15, 11 February 2018 (UTC) Dumb in the way I described it. It can check a link is dead but does not have the smarts to work out why and find where it’s moved to, or if there is a better replacement. Yes, that level of AI is beyond any bot. But that’s why it’s valuable to check its changes, something that would happen far less often if the bot did not leave a note. It would look like any other bot, which editors are used to ignoring.--JohnBlackburnewordsdeeds 23:59, 11 February 2018 (UTC) True. If the URL doesn't automatically redirect to the new location, then the bot will never know that it isn't dead.—CYBERPOWER (Be my Valentine) 00:09, 12 February 2018 (UTC) leave it on: Like other editors asking the same, I use it as an opportunity to expand citations (particularly when they are in a language other than English). Not only does the bot often link to an archived redirect to a top level page, it picks up 404 error pages, etc. It can't confirm that the citation is RS (there are plenty of instances where they're not), nor can it tell whether it's picked up the correct save on a dynamic page. I have a backlog of notifications I'm working through slowly (it's grunt work, but I've found plenty of replacements for dead links and other problem archives for articles). When I add another article to my watchlist, I go through these notifications where they have not been marked as checked. You'd probably be surprised at how many times I've found that content has been tampered with subsequently, or the citations are intentionally falsified, or - as happens uncomfortably often in articles dependent on languages other than English - AGF errors are made due to a poor knowledge of English leading to mistranslation. I'm sure I'm not the only editor who uses the talk page prompts as a method of catching up on the integrity of an article. --Iryna Harpy (talk) 00:41, 12 February 2018 (UTC) Leave it on: The talk page messages provide a handy way to get to the affected links and check them efficiently. I'm not a fan of the extra watchlist entries, however, and would be open to another system for noting the affected links. Graham87 02:30, 12 February 2018 (UTC) Leave it on The "costs" are entirely notional and vastly overstated based on zero research. The benefit is that the bot's actions are transparent. Posing a zero cost-real benefit CBA answers itself. Eggishorn (talk) (contrib) 15:50, 12 February 2018 (UTC) Leave it Bytes are cheap, and users are not required to read the messages if they don't want to, and I don't see the harm in leaving notice on talk pages. --Jayron32 16:00, 12 February 2018 (UTC) Leave it the transparency of the bot action with the notice and what response may be needed by humans is worth even the claimed downside, above. Response is also more likely lead to improvement of the bot. Alanscottwalker (talk) 16:07, 12 February 2018 (UTC) Leave it on The bot's talk page messages have provided a useful synopsis for checking links. If such a synopsis exists elsewhere, then link to it in the edit summary and let's see if that's a good replacement, before turning off the current messaging. I still find questionable edits by IABot, even though I'm not checking regularly. I hardly ever correct its edits by reverting, so a system of registering reversions isn't enough. In any sort of cost-benefit analysis, you would have to include the time it would take live editors to maintain the sort of link viability that IABot does automatically. Even at its most imperfect, it was more efficient that manual checking and updating of links. Dhtwiki (talk) 23:08, 12 February 2018 (UTC) Discussion[edit] I am pinging people who have engaged in previous conversation about the bot messages. From Wikipedia:Bots/Noticeboard/Archive_11#InternetArchiveBot_notices_about_nothing_but_archive-url_additions @Francis Schonken, Graham87, Rich Farmbrough, Hawkeye7, and Hasteur: @SMcCandlish and Zeke, the Mad Horrorist: From Wikipedia:Village_pump_(proposals)/Archive_138#Proposal_-_non-requested_automated_messages_on_talk_pages_must_be_short @Xaosflux, GenQuest, Eggishorn, Od Mishehu, and Godsy: @Graeme Bartlett, LindsayH, Doc James, and Jeff G.: Blue Rasberry (talk) 20:07, 11 February 2018 (UTC) Meh I don't care really one way or the other - if they are useful, keep them - if not, don't. However I don't agree much with arguments about the "costs". — xaosflux Talk 21:06, 11 February 2018 (UTC) @Xaosflux: I wish to avoid encouraging you to enter a conversation which you do not find interesting, but if you are open to conversation, then I would like to hear more about how you think of the costs. You are a wiki bureaucrat whose role includes reviewing bots, and I am interested in your opinions on the extent to which bot consumption of human labor factors into your decision to approve bots. I am imagining an equation where (amount of human time which bot consumes) * (value of human time) = cost of bot Your personal view and default opinion might be (bots always consume 0 human time) * (human time has a value of 0)= bots always have 0 cost My view in this is (10 seconds on average per IABot post) * 500,000 posts * US$15/hr = 5,000,000 seconds * 15/hr = bot consumes human labor with value of ~$20,000 All of this is a guess, but it is challenging for me to imagine how lower estimates could be reasonable. Any time estimate or labor value estimate multipled by 500,000 or 1,000,000 leads to a large cost. I am seeing an unsustainable call for human labor engagement in highly tedious bot activity and I would not want typical wiki contributors feeling a draw to engage in social interactions with bots in preference to more human activity which the wiki environment should promote instead. No human will make a loud request for help a million times, but it is possible for bots to do this, and as a general rule I advocate that we should not allow such loud automated requests to compete with human to human interaction. If you have another view of the value of bot/human interactions or other numbers to plug into the equation then I would like to hear what you think, because it is challenging for me to understand what it means to socialize with bots that seem vocal about making demands 10,000 at a time. What insight do you have to detect any misconception in my narrative here? Blue Rasberry (talk) 23:17, 11 February 2018 (UTC) @Bluerasberry: I do review bots as part of BAG and I would not have introduced a requirement for this bot to do this. As for the "costs" of storage space on the WMF servers, edit rates/bandwidth etc - in general if this is causing a problem the server ops team will let us know (it rarely is). As far as talk page notices go - we fill those up will all sorts of things like project banners, continually re-evaluated class information, etc. I've never been bothered by any of these as an editor but I can see where others might not find it useful. Like I said above, if its not useful stopping it is the way to go. And this discussion is a good way to help determine that it is or isn't useful. I'm generally opposed to forcing a bot operator to make an edit they don't want to (or quit operations) unless there is a compelling community reason why it is necessary. In this instance the operator doesn't want to make these edits, so I'm generally supportive of their request. Hope that helps. — xaosflux Talk 23:25, 11 February 2018 (UTC) @Xaosflux: I feel like I have failed to communicate clearly. I am talking about contributor labor and time, whereas you seem to have understood that I am talking about the cost of electricity. Please cease considering servers, processing, or anything unrelated to the time of individual humans. The talk page posting which IABot currently does is in the family of Chatbot or Spambot behavior and the bots review process should identify and restrict spambot-style social interaction between bots and humans. Right now we are having a human to human conversation and you are giving your labor to this. The wiki environment should encourage these kinds of interactions. The wiki environment should not encourage human interactions with spam bots. Bots have the potential to draw humans into giving their attention to tasks which no human should do. From the start this IAbot had a near 0% failure rate, and now it has a failure rate much closer to 0, yet very loudly to many thousands of users, the bot requested their time, attention, and labor to check the bot work. I understand that the wiki community was cautious about the editing this bot does and that it originally made sense that the bot would be cautious and give disclosure when entering the wiki environment. I do not fault anyone for assuming that talk page posts would be useful, but how that we know how bots can work I never want to see any bot have in its design an objective to solicit a massive amount of human attention directed to social interactions with bots ever again. The wiki community should be cautious about letting anyone automate thousands of requests that human attention go to bots. If any bot has inherent in its design the intent to request 100s of Wikipedia contributor hours then I think that should be made clear in the review process and that there should be an evaluation about whether 1000s of Wikipedia contributors should all give their attention to the social experience which the bot is putting in front of everyone. This bot has made not fewer than 500,000 talk page posts when a typical mass posting is 100 posts. This is crazy off the scale of what we normally address. If you feel that this bot is consuming an insignificant amount of time, or if you feel that human interaction with this bot's posts were typically beneficial for the wiki environment, then I would like to hear that from you. To what extent am I making my concern easy to understand? Blue Rasberry (talk) 00:20, 12 February 2018 (UTC) I already said I'm in support of letting this operator change this task barring any community consensus that it is needed, should the community decide these messages are a net positive then its not my place to override them. Personally, I don't mind if they stay or go. Community input to proposed bot tasks at WP:BRFA is always welcome, and BAG strives to ensure that community support is in place for large tasks, which are always available to be re-reviewed. It does appear a bit verbose, and I think the best improvement would be for the operators to change to using a link in their edit summary that goes to a more expanded FAQ subpage of the bot's userpage. This should be able to summarize the general usage and give instructions for people to better give feedback to the operators. — xaosflux Talk 02:41, 12 February 2018 (UTC) Thinking out loud: I'm undecided on this question as yet. I'm generally inclined to accept the bot operator's position on the assumption that they have superior insight into the issue (and Cyberpower doesn't think it serves any purpose). And similarly, I subscribe to Xaosflux's principle above: if a bot owner doesn't want to make a type of edit, there should be a very compelling community interest present to justify forcing them. I also find Bluerasberry's and related cost arguments salient: both the raw technical cost of extra edits etc. (which is small but non-zero, and which may grow to be non-neglible over time), and the human cost of the wasted effort to deal with the notices (but not the effort when humans actually intervene for whatever reason). All that said, however, I am still ambivalent. As a foundational premise, I do not see every edit on every article in my watchlist. Or even most edits on most articles on my watchlist. There are simply too many edits and too many articles. Further, there are very few editors working in my area, so the odds are very low that any given edit gets sufficient, or even just any, review. This a major problem in general (and it applies to many areas, not just my little sub-specialty), but it also applies to IABot's edits (and absent meaningful review, you cannot tell what IABot's actual approximate error rate is). On that background, I think I want some way to keep track of IABot's activities, in my area, at some granularity coarser than individual edits, but not so coarse as to be binary. The current talk page notices are that: they persist past the individual edits scrolling off my watchlist. But they still deal with just one edit to one article. So maybe the current setup is just too fine-grained? Perhaps a sweet spot, for me, would be a periodical (weekly, say) report of IABot's activity on articles in my WikiProject? This would be analogous to Article Alert bot and Cleanup lists. That gives me some place to go check periodically, and the edits to the report page will show up in my watchlist if I'm actively working on Wikipedia; or if it gets updated at a predictable interval (as the Cleanup list is) I'll know to check it when time allows. And not every article on my watchlist is within the scope of my WikiProject, but it is the articles in the WikiProject that I care enough about to want to track this closely. For others there may be similar aggregations such as a category; but a tracking/interest aggregation greater than the individual article in any case. And a change aggregation greater than the individual edit (i.e. typically time based, even if the optimal interval is something other than my preference for one week). There are also issues of "discoverability" (how do you find the IABot tools interface? A link in the edit summary vs. a descriptive text permanently on the talk page are very different propositions!), and quality (IABot is very good, but not perfect; it does still need humans in the loop, for "false negatives" and "other" issues, in addition to what above gets called "false positives" for some reason). But these are of lesser import, I think. So where does this leave me? Well, it leaves me undecided, obviously. Perhaps cyberpower678 could chime in on the technical feasibility and their interest (or lack of, obviously) in implement some kind of report system? And it would be useful to know if others have any interest in something like this, or whether the vast majority are simply on one side or the other of the binary Yes/No to per-edit talk page messages? — Preceding unsigned comment added by Xover (talk • contribs) 06:18, 12 February 2018 (UTC) Hmmm...I'm not inclined to create one right now. A lot of other plans for IABot right now. Though honestly, as GreenC said IABot's API allows tools to actually access similar information by going to https://tools.wmflabs.org/iabot/api.php —CYBERPOWER (Be my Valentine) 13:39, 12 February 2018 (UTC) API documentation: https://meta.wikimedia.org/wiki/InternetArchiveBot/API -- GreenC 16:06, 12 February 2018 (UTC) @Cyberpower678: Yeah, I kinda figured as much. Keep it in mind as possible long term wishlist kinda thing? In any case, I can't see anything in the API docs that would cover the kind of stuff I describe above. I'd be looking for something like "Which of 'my' articles had a link go dead, or had an archive added (that might be a bad archive), in the last 30 days?" The API, afaict, is entirely oriented around the URLs and their current state, not the articles and their history, if that distinction makes sense? --Xover (talk) 19:04, 12 February 2018 (UTC) I solicited further comments at Wikipedia_talk:Bot_policy#Bots_that_consume_user_time,_and_request_for_comment and Wikipedia_talk:Bots/Requests_for_approval#Request_for_comment_about_Internet_Archive_Bot_messaging. Blue Rasberry (talk) 22:13, 16 February 2018 (UTC) The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Please mention classification system in taxobox[edit] I have a request on improving taxobox. On a taxobox for a taxa; it should be explicitely mentioned; which system of classification has been used. If a mixture of system has been done (although that is highly unrecommended). It is important because classification systems change; where not only the taxa fusion and splits; but ranks of the taxa sometimes changes; and although quite rarely; rank names too changed. So whenever publish a taxobox; please mention which system of classification is followed. Best if a taxobox contain 2 or 3 columns for the hierarchies according to separate classification systems. This not only improve correctness of the articles; but also will work as better reference and would help literature search. RIT RAJARSHI (talk) 16:55, 13 February 2018 (UTC) Please clarify what you mean by classification systems. It's just ranked vs. unranked, somewhat like a common system vs. scientific system scenario. --QEDK (後 🌸 桜) 19:29, 13 February 2018 (UTC) If one uses Template:Speciesbox (edit | talk | history | links | watch | logs) and Template:Automatic taxobox (edit | talk | history | links | watch | logs) then the citations should be in the associated taxonomy template. Nessie (talk) 20:01, 13 February 2018 (UTC)


ZipcodeZoo.com[edit] ZipcodeZoo.com is a free online natural history encyclopedia, with a page for every living species. Text is supplemented with video, sound, and images where available. The site's 6.1 million pages include over 1.2 million photographs, 52,000 videos, 223,000 sound clips, and a 3.9 million maps describing 4.7 million species and infraspecies. ZipcodeZoo draws on the Catalogue of Life for its basic species list, the Global Biodiversity Information Facility for its maps, Flickr and the Wikimedia Commons for many of its photos, YouTube for videos, the Taxonomicon for taxonomic information, and Xeno-canto for some of its sound recordings. All pages are published under one of the Creative Commons licenses. I began creating ZipcodeZoo.com in 2004, and have thousands of hours invested in its development. Much of this time was spent in developing tools that could competently harvest other trustworthy public sources of species information, integrate that information, and display all pages with a standard look and feel. MediaWiki is now the engine behind page delivery for the website. I've posted over 40,700 of my wildlife photos to Commons.wikimedia.org (see here), and now want to act to preserve the intellectual content of ZipcodeZoo's pages by providing it to Wikipedia. The addition of the ZipcodeZoo.com content to Wikipedia would add or change many pages. Consider the difference between the descriptions of Zenaida macroura on ZipcodeZoo.com and on Wikipedia. My proposal is that I would write the code that would create Wikipedia pages that do not exist, as well as to edit existing Wikipedia pages to incorporate the additional ZipcodeZoo.com information. All uploaded material will be available under the Creative Commons Attribution-Share Alike License. Prior to uploading, my code would remove all references to photographs other than those available at Wikimedia Commons. No existing content in Wikipedia would be replaced. My goal is to only supplement the current information of Wikipedia. Before I begin, I need to get some feedback on this proposal from those who've worked so hard on Wikipedia. I don't want to flood the site with SPAM, and don't want to invest a month in coding a bot that won't be used. - David Stang (talk) 13:55, 16 February 2018 (UTC) (240) 477-8817. ZipcodeZoo.com@gmail.com Comment - do you have an example of what this change would look like for an article? Nessie (talk) 14:45, 16 February 2018 (UTC) Here are some examples: Pileated Woodpecker on Wikipedia and ZipcodeZoo: expand the scientific classification section of the taxobox to include the additional details from ZZ; add the section on Distribution, with the map. Northern Fur Seal on Wikipedia and ZipcodeZoo: add vernacular names; expand taxobox; add the map; add images; add bibliography. Andaman shrew on Wikipedia and ZipcodeZoo: add vernacular names, habitat and ecology, taxonomy, distribution, and bibliography sections. Also expand taxobox. In general, those pages that have little information at Wikipedia would grow more than those that already have a lot. David Stang (talk) 17:53, 16 February 2018 (UTC) Is Wikipedia:WikiProject Tree of Life still active? If so, members of that project may have some useful input to this discussion. --Jayron32 14:48, 16 February 2018 (UTC) ZipcodeZoo was offered to Wikispecies in July 2017 (species:Wikispecies:Village_Pump/Archive_43#ZipcodeZoo) One major concern expressed at Wikispecies was that some of the photos at ZipcodeZoo were licensed CC-BY-NC-SA and thus not compatible with WMF's CC-BY-SA license. Restricting photos to those on Commons might avoid that particular problem. However, I note that the text in ZipcodeZoo's Andaman shrew page is almost entirely taken from the IUCN Redlist. The IUCN does not permit commercial use of their data. I appreciate the offer being made. I have some serious concerns about how ZipcodeZoo could be integrated into Wikipedia. I'll just pick two nits for now; I'm not seeing a link from ZipcodeZoos Andaman shrew article to the IUCN record, just links to the IUCN search page. The Wikipedia article has two direct links to the IUCN record. Secondly, long standing consensus is not to include minor taxonomic ranks in most cases; we don't want to expand the taxoboxes of Northern fur seal and Andaman shrew. As one of the more active Wikipedia taxonomy editors I recognize that we have too many species already and not enough people working on them to get most of organism articles into any sort of useful state. Incorporating ZipcodeZoo might be helpful, but I'd want to proceed extremely cautiously. And we absolutely need to get copyright compatibility sorted out before any other steps are taken. Plantdrew (talk) 21:49, 16 February 2018 (UTC) Response: I would agree that no material would be posted to Wikipedia that was not CC-BY-SA. So the only thing I would draw from IUCN is their claim of Redlist status, and the page would display the current information as it is now displayed for the Northern fur seal, including a status sentence ("The IUCN (2008) lists the species as globally threatened under the category "vulnerable".) and an entry in the References section.David Stang (talk) 15:25, 17 February 2018 (UTC) Response concerning minor taxonomic ranks: At ZipcodeZoo, I got many comments from biologists and teachers who appreciated this information. But if consensus is to not display minor taxonomic ranks, I can certainly abide by that. Response concerning links to IUCN: My bot can determine the specific link to IUCN, and include this information David Stang (talk) 15:25, 17 February 2018 (UTC) Response: agreed. My database contains copyright details for most of my content. I would proceed ensuring that everything was CC-BY-SA.David Stang (talk) 15:25, 17 February 2018 (UTC)


An update of the default introduction & tutorial to Help:Introduction[edit] Wikipedia's default introduction (WP:I) and tutorial (WP:T) for newcomers has changed little in the last decade. Yet the introduction of visual editor has made much of its advice confusing for newcomers (e.g. the advise to manually insert references using <ref>Your Source</ref>). Nevertheless, it is in a prime location, with multiple welcome messages and help pages funnelling new users to it. Over the last two years, a group of users from the Help Wikiproject, have put together an updated version. The main menu, Help:Introduction: Clearly separates the VisualEditor and WikiMarkup versions of each help page Is more up to date Has an easier-to-read layout pioneered by the original Help:Introduction to referencing Proposal Replace WP:introduction and WP:tutorial with Help:Introduction. Overall, I think it is a marked improvement over the current default. Edits can be made if there are any elements of the old tutorial that are felt to be missing from Help:Introduction. T.Shafee(Evo&Evo)talk 11:42, 17 February 2018 (UTC) Oppose replace - have both...much more info in the tutorial that the help project keeps up to date dispite the assertion above (only 3 of us there really making updates and were not involved in these so called new pages about the wikitext portion). Like I indicated above no problem with having two different how to styles for this info. But the help project does recognize that these "Next Pages" things don't work out all too well as view count drops dramatically on the next page. The Wiki text links are old how-to pages the peoject has not update in a long time. I am concerned with the assertion made above that the project endorses the changes....some of the linked stuff is very old. Most automated post send our new editors to WP:Contributing to Wikipedia in hopes they find what they need on the first page with links etc. I hope this request is not because you can't edit the other templates. If you need help with them just ask...no need to replace. --Moxy (talk) 03:14, 18 February 2018 (UTC) @Moxy: The proposal is because I think that help:intro series provides better learning materials for new editors than WP:I and WP:T. A large proportion of new editors get sent to WP:I and of WP:T. WP:I gets approx 100x more traffic, and the basic editing section WP:T gets approx 10x more traffic than their Help:intro equivalents. I think that the main options are: Redirecting WP:T and WP:I to Help:intro equivalents, in my opinion the simplest solution. Reduce the direction of new users to WP:T and instead direct to Help:intro in the various welcome messages, templates, help pages. Overhauling and modernising the existing WP:T, but I think it would end up looking extremely similar to the Help:intro equivalents, at which point it'd be much of a duplication. Apologies if I seemed to be speaking for the whole of WP:WPHELP - I was attempting to not take credit for the work of multiple people on the help:intro series. My application for templateeditor status was largely to be able to edit the {{Intro_to}} template. T.Shafee(Evo&Evo)talk 05:05, 18 February 2018 (UTC) I do not belive Help:Introduction sub wiki introductions that have not been updated in a long time look better. They provide less readable text because of the sandwiched text beside the side tabs.... by omitting top tabs text is less readable especially in mobile view. Your asking to redirect two tutorials and the sub pages (Including Wikipedia:Tutorial/Editing/sandbox that is used daily) that are linked in many templates and automated messages to a list of links in a fancy format. This is a huge change that even omits a link to the projects main help pages. I am more them willing to help update what you think is missing in our long standing intros.--Moxy (talk) 06:21, 18 February 2018 (UTC) Oppose: I'm not at all sure it is a good idea to show Visual Editing as the first option on "Help:Introduction". To become an effective editor, newcomers need to adopt the traditional approach using Wikicode. I note, btw, that "Help:Introduction" is linked with explanations from the Wrap-up page of WP:T. If WP:I and WP:T are not as "up-to-date" as Help:Introduction, they should be improved asap. Any important new features from Help:Introduction could also be incorporated.--Ipigott (talk) 11:14, 18 February 2018 (UTC) Can someone explain what needs updating? So far those of us that work for the help project cant figure out what is not up to date.--Moxy (talk) 16:23, 18 February 2018 (UTC) Support in principle, though I haven't had a full read through the new pages yet. Attitudes like "newcomers need to adopt the traditional approach using Wikicode" are going to be the death of Wikipedia. It's painfully obvious that the visual editor is a vastly better way of introducing new editors to Wikipedia and a set of updated introduction pages which reflect this is a sensible idea. Sam Walton (talk) 13:11, 18 February 2018 (UTC) The reason it's not used more is because there is so many problems Wikipedia:VisualEditor#Limitations. Need to learn some wiki code it they want to use talk pages. Files etc. We have a request to redirect 2 tutorials of 10 pages that covers both editing versions to a tutorial that separates the two and directs editors to a tutorial that has over 30 pages. The project stopped this formate years ago because....first page 5500+ views.....But...50% loss by 4th page. We have trouble keeping new editors reading 7 tabs.....not sure how 30+ tabs will help that. It's why we direct editors to WP:Contributing to Wikipedia an article style with all the info on one page.....no link runaround. Moxy (talk) 16:16, 18 February 2018 (UTC) However, we'd need eye-tracking studies to know how much of the content on the one page is getting read. It's possible that many people aren't scrolling down to the later content, which could mean the multi-page approach still reaches more people. isaacl (talk) 17:08, 18 February 2018 (UTC) 100 percent correct....we use 2 styles of intros one has 7 tabs the other is in the article style (and the adventure that also has a completion problem) We direct most to the article style because some research seems to indicate that people get serviceable information out of the contents eye tracking and Which_parts_of_an_article_do_readers_read. Things are done in certain manners for a reason at the project. This request is a big change that the data we have tells us is not the way to go. Having more and being more stylish is not always the best way to go.KISS -Moxy (talk) 17:21, 18 February 2018 (UTC) Oppose from what I can see this is a proposal to delete both Wikipedia:Tutorial and Wikipedia:Introduction, and basically replace them with Help:Introduction and a yet unfinished Help:Introduction to Wikipedia. Well I oppose these changes. The format of the pages, as well as missing a lot of detail, is a lot less user friendly in my opinion. While Wikipedia:Introduction doesn't contain a lot of information, Wikipedia:Tutorial does but in a far more user friendly format. Help:Introduction to Wikipedia hasn't even been completed yet, which makes me really question why this has even brought forward yet. Replacing a lot of advice in Wikipedia:Tutorial and replacing them mostly with a series of links is in my opinion a big mistake. Update them to include more VE info if necessary, but their basic format is a lot more favorable. Even the naming of the pages is poor and confusing. --Jules (Mrjulesd) 20:57, 18 February 2018 (UTC) Oppose but with some sympathy I rarely look at either of the three pages, but I couldn´t support replacing the old with the unfinished. The old pages are clumsy written in a overcomplex form of English and jam too much on to each page and need severe pruning. The new page is focussed on how wonderful visually editor is and how there are equivalent functions in two disparate editing systems that the neophyte hasn't yet encountered. Instead we need to function on the 'user of the page' and present what we need to tell him- in a language that is appropriate to his position on the learning curve. So at level one we want to say. A wikipedia edit has three parts- you type in an interesting fact- you say where you found the information- you write in the edit summary what you have done so you can find it later. When I am teaching wikipedia editing, my students start by writing me a message on my talk page, before they make a correction in an article. Failing that they write a short message on the article talk page, asking for forgiveness for any errors they are about to make. This blows out of the water, Visually Editor, which doesn't do talk pages- and kills stone cold the new suggested Help:Introduction. The next level one learning point is that wikipedia is not a free-for-all but has rules. This is targetted not only at the neophyte but the journalist passing by with the intention to to show anyone one can introduce a false fact so had to be prominent. Now we get to level two skills and basic markup- student have little difficulty in understanding our markup, but we relish in failing to explain the obvious. Everyone seems to try and do a worse job than his predecessor. The difference between exposition and tutorial becomes more obvious. However remember the user will probably be very experienced in his own field, but may not have English as his first language. Put less text on each page. Avoid compound sentences, remove the nuances and put them in footnotes with {{efn}} or float individual level three pages where these can be discussed with all their options. There are some tutorial booklet on my training page, that folk are welcome to customise for classroom use. User:ClemRutter/training * ClemRutter (talk) 01:15, 19 February 2018 (UTC) @ClemRutter can you fix the dead links at User:ClemRutter/training would love to see what your using .--Moxy (talk) 14:52, 19 February 2018 (UTC) @Moxy: So what happened there! Could it have something to do with MS buying Dropbox, and resetting permissions to make it more Linux unfriendly! So I have removed the links and am starting to rebuild them. Thanks for caring. ClemRutter (talk) 19:31, 19 February 2018 (UTC)


Discussion: Use of AR-15 Style Rifles in Mass Shootings[edit] A discussion is taking place at: Wikipedia_talk:WikiProject_Firearms#Use of AR-15 Style Rifles in Mass Shootings Interested editors are invited to participate. --K.e.coffman (talk) 20:29, 18 February 2018 (UTC) Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=826548652" Categories: Wikipedia village pumpWikipedia proposalsHidden categories: Wikipedia move-protected project pagesNon-talk pages with subpages that are automatically signedPages automatically checked for incorrect links


Navigation menu Personal tools Not logged inTalkContributionsCreate accountLog in Namespaces Project pageTalk Variants Views ReadEditNew sectionView history More Search Navigation Main pageContentsFeatured contentCurrent eventsRandom articleDonate to WikipediaWikipedia store Interaction HelpAbout WikipediaCommunity portalRecent changesContact page Tools What links hereRelated changesUpload fileSpecial pagesPermanent linkPage informationWikidata item Print/export Create a bookDownload as PDFPrintable version In other projects Wikimedia CommonsWikibooksWikinews Languages العربيةAragonésঅসমীয়াCatalàČeštinaDeutschEspañolEuskaraGalegoIlokanoBahasa IndonesiaქართულიҚазақшаKurdîMagyarBahasa Melayuမြန်မာဘာသာनेपालीНохчийнOʻzbekcha/ўзбекчаپښتوPortuguêsРусскийसंस्कृतम्සිංහලSlovenčinaŚlůnskiکوردیСрпски / srpskiBasa SundaతెలుగుТоҷикӣTürkçeУкраїнськаاردو粵語डोटेली Edit links This page was last edited on 19 February 2018, at 19:31. Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization. Privacy policy About Wikipedia Disclaimers Contact Wikipedia Developers Cookie statement Mobile view (window.RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgPageParseReport":{"limitreport":{"cputime":"0.492","walltime":"0.812","ppvisitednodes":{"value":4483,"limit":1000000},"ppgeneratednodes":{"value":0,"limit":1500000},"postexpandincludesize":{"value":67213,"limit":2097152},"templateargumentsize":{"value":26120,"limit":2097152},"expansiondepth":{"value":15,"limit":40},"expensivefunctioncount":{"value":27,"limit":500},"entityaccesscount":{"value":0,"limit":400},"timingprofile":["100.00% 272.095 1 -total"," 39.83% 108.387 1 Template:Village_pump_page_header"," 14.06% 38.268 1 Template:Shortcuts"," 11.76% 32.004 1 Template:Start_tabs"," 11.34% 30.868 1 Template:Village_pump_archives"," 10.55% 28.718 1 Template:Archive_list"," 8.28% 22.525 1 Template:Cent"," 7.12% 19.364 1 Template:Centralized_discussion/core"," 6.94% 18.885 16 Template:Ping"," 6.57% 17.867 1 Template:Max"]},"scribunto":{"limitreport-timeusage":{"value":"0.062","limit":"10.000"},"limitreport-memusage":{"value":2367786,"limit":52428800}},"cachereport":{"origin":"mw1312","timestamp":"20180219193127","ttl":1900800,"transientcontent":false}}});});(window.RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgBackendResponseTime":116,"wgHostname":"mw1267"});});


Wikipedia:Village_pump_(proposals) - Photos and All Basic Informations

Wikipedia:Village_pump_(proposals) More Links

Wikipedia:Village Pump (policy)Wikipedia:Village Pump (technical)Wikipedia:Village Pump (idea Lab)Wikipedia:Village Pump (miscellaneous)Wikipedia:ShortcutWikipedia:Perennial ProposalsWikipedia:FAQ IndexWikipedia:Village Pump (idea Lab)Wikipedia:Village Pump (policy)Wikipedia:WikiProject Council/ProposalsWikipedia:Requested ArticlesWikipedia:Village Pump ArchiveWikipedia:Village Pump (proposals)/Archive 125Wikipedia:Village Pump (proposals)/Archive 126Wikipedia:Village Pump (proposals)/Archive 127Wikipedia:Village Pump (proposals)/Archive 128Wikipedia:Village Pump (proposals)/Archive 129Wikipedia:Village Pump (proposals)/Archive 130Wikipedia:Village Pump (proposals)/Archive 131Wikipedia:Village Pump (proposals)/Archive 132Wikipedia:Village Pump (proposals)/Archive 133Wikipedia:Village Pump (proposals)/Archive 134Wikipedia:Village Pump (proposals)/Archive 135Wikipedia:Village Pump (proposals)/Archive 136Wikipedia:Village Pump (proposals)/Archive 137Wikipedia:Village Pump (proposals)/Archive 138Wikipedia:Village Pump (proposals)/Archive 139Wikipedia:Village Pump (proposals)/Archive 140Wikipedia:Village Pump (proposals)/Archive 141Wikipedia:Village Pump (proposals)/Archive 142Wikipedia:Village Pump (proposals)/Archive 143Wikipedia:Village Pump (proposals)/Archive 144Wikipedia:Village Pump (proposals)/Archive 145Wikipedia:Centralized DiscussionWikipedia:Village Pump (policy)Wikipedia:Village Pump (idea Lab)Wikipedia:Requests For AdminshipWikipedia:Requests For AdminshipWikipedia Talk:Notability (organizations And Companies)Wikipedia Talk:AdministratorsWikipedia Talk:Banning PolicyTalk:Sarah Jane BrownWikipedia:Village Pump (policy)Wikipedia:DashboardTemplate:Centralized DiscussionWikipedia:Centralized Discussion/ArchiveWikipedia Talk:Centralized DiscussionUser:Fish And KarateUser Talk:Fish And KarateSpecial:Diff/804461129Special:Diff/804461747Wikipedia:Administrators' Noticeboard/IncidentArchive966User:MusikAnimalWikipedia:TPROTWikipedia:Administrators' Noticeboard/Archive293Wikipedia:SEMISpecial:Diff/816093519User:Cyberpower678User:PrimefacUser Talk:PrimefacUser:XaosfluxUser Talk:XaosfluxUser:InsertcleverphrasehereUser Talk:InsertcleverphrasehereUser:DlohcierekimUser Talk:DlohcierekimUser:GalobtterUser Talk:GalobtterUser:PrimefacUser Talk:PrimefacUser:GalobtterUser Talk:GalobtterUser:Cyberpower678User Talk:Cyberpower678User:L3X1User Talk:L3X1User:L3X1User Talk:L3X1User:ZzuuzzUser Talk:ZzuuzzUser:PrimefacUser:TonyBallioniUser Talk:TonyBallioniUser:TonyBallioniTemplate:Redirect-multiUser:PrimefacUser Talk:PrimefacUser:TonyBallioniUser Talk:TonyBallioniUser:ZzuuzzUser Talk:ZzuuzzUser:GalobtterUser Talk:GalobtterTemplate:Philip K. DickTemplate:Syracuse TVTemplate:Miss InternationalTemplate:CryptocurrenciesTemplate:PixarTemplate:FlashUser:ZzuuzzUser Talk:ZzuuzzWikipedia:CREEPUser:Andrew DavidsonUser Talk:Andrew DavidsonUser:Andrew DavidsonUser:Cyberpower678User Talk:Cyberpower678User:Jo-Jo EumerusUser Talk:Jo-Jo EumerusSpecial:CentralAuth/Jo-Jo EumerusUser:HeadbombUser Talk:HeadbombSpecial:Contributions/HeadbombWikipedia:PHYSWikipedia:WBOOKSUser:Aunva6User Talk:Aunva6Special:Contributions/Aunva6Wikipedia:Pending ChangesUser:Jéské CourianoUser Talk:Jéské CourianoSpecial:Contributions/Jéské CourianoUser:GalobtterUser Talk:GalobtterWikipedia:Template EditorWikipedia:DRAMAUser:SMcCandlishUser Talk:SMcCandlishSpecial:Contributions/SMcCandlishWikipedia:Database Reports/Templates Transcluded On The Most PagesUser:EnterpriseyUser Talk:EnterpriseyUser:AmmarpadUser Talk:AmmarpadUser:ZzuuzzUser Talk:ZzuuzzWikipedia:TPROTUser:Jc86035User Talk:Jc86035User:PrimefacUser Talk:PrimefacUser:PrimefacUser Talk:PrimefacUser:GreenMeansGoUser Talk:GreenMeansGoUser:KusmaUser Talk:KusmaSpecial:Contributions/KusmaUser:MalinaccierUser Talk:MalinaccierUser:YmblanterUser Talk:YmblanterUser Talk:My Name Is Not DaveUser:BU Rob13User Talk:BU Rob13User:BU Rob13User:IznoUser Talk:IznoUser:Doc JamesUser Talk:Doc JamesSpecial:Contributions/Doc JamesSpecial:EmailUser/Doc JamesUser:IznoUser Talk:IznoUser:LegoktmUser Talk:LegoktmUser:James AllisonUser Talk:James AllisonSpecial:Contributions/James AllisonUser:Peter CoxheadUser Talk:Peter CoxheadUser:PkbwcgsUser Talk:PkbwcgsUser:AhechtUser Talk:AhechtUser:Optimist On The RunUser Talk:Optimist On The RunUser:Davey2010User Talk:Davey2010User Talk:SarekOfVulcanWikipedia:SOPUser Talk:Anne Drew Andrew And Drew2001 (Stargate SG-1)User:The BushrangerUser Talk:The BushrangerWikipedia:BLPUser:The BushrangerUser Talk:The BushrangerWikipedia:IP Addresses Are Not PeopleUser:Dennis BrownUser Talk:Dennis BrownUser:Tony TanUser Talk:Tony TanUser Talk:TarageUser:YunshuiUser Talk:YunshuiSpecial:Contributions/YunshuiUser:Hawkeye7User Talk:Hawkeye7User:DrewmuttUser Talk:DrewmuttUser:AhechtUser Talk:DarkmorpherUser Talk:My Name Is Not DaveWikipedia:IPs Are Human TooSpecial:Contributions/50.53.21.2User:NaBUru38User Talk:NaBUru38User:RonhjonesUser Talk:RonhjonesUser Talk:UanfalaUser:UanfalaUser Talk:UsernamekiranWikipedia:BEANSUser:Jéské CourianoUser Talk:Jéské CourianoSpecial:Contributions/Jéské CourianoUser:ChristianKlUser Talk:ChristianKlWikipedia:NAMESPACEUser:KilliondudeUser Talk:KilliondudeTemplate:Sidebar PersonUser:GalobtterUser Talk:GalobtterUser:GalobtterUser Talk:GalobtterSpecial:Contributions/50.53.21.2User:ZzuuzzUser Talk:ZzuuzzUser:GalobtterUser Talk:GalobtterUser:Emir Of WikipediaUser Talk:Emir Of WikipediaUser:ZzuuzzUser Talk:ZzuuzzWikipedia:PurgeUser:GalobtterUser Talk:GalobtterUser:GalobtterUser Talk:GalobtterSpecial:Diff/819590838User:PrimefacUser Talk:PrimefacSpecial:Diff/820115281Special:Diff/820114929Special:Diff/820109549User:PrimefacUser Talk:PrimefacSpecial:Contributions/50.53.21.2Wikipedia:High-risk TemplatesUser:NaBUru38User Talk:NaBUru38User:TheDJUser Talk:TheDJSpecial:Contributions/TheDJUser:TheDJUser:XaosfluxUser Talk:XaosfluxUser:TheDJUser:XaosfluxList Of Soap Opera VillainsUser:John Of Reading/X3User:John Of ReadingUser Talk:John Of ReadingUser:PrimefacUser Talk:PrimefacUser:PrimefacUser Talk:PrimefacUser:PrimefacUser Talk:PrimefacUser:Jéské CourianoUser Talk:Jéské CourianoSpecial:Contributions/Jéské CourianoTemplate:Duke Blue Devils Men's Basketball NavboxUser:Power~enwikiUser Talk:Power~enwikiSpecial:Contributions/Power~enwikiUser:Power~enwikiUser Talk:Power~enwikiSpecial:Contributions/Power~enwikiUser:Power~enwikiUser:John Of ReadingUser Talk:John Of ReadingUser:Jéské CourianoUser Talk:Jéské CourianoSpecial:Contributions/Jéské CourianoUser Talk:UanfalaUser:Jéské CourianoUser Talk:Jéské CourianoSpecial:Contributions/Jéské CourianoUser:The BushrangerUser Talk:The BushrangerUser:PaleoNeonateUser Talk:PaleoNeonateUser:Jéské CourianoUser Talk:Jéské CourianoSpecial:Contributions/Jéské CourianoSpecial:Contributions/50.53.21.2User:Jéské CourianoUser Talk:Jéské CourianoSpecial:Contributions/Jéské CourianoTemplate:Sandbox OtherSpecial:Contributions/50.53.21.2User:Tony TanUser Talk:Tony TanUser:HeadbombUser Talk:HeadbombSpecial:Contributions/HeadbombWikipedia:PHYSWikipedia:WBOOKSUser Talk:UanfalaWikipedia Talk:WikiProject ArthropodsWikipedia Talk:WikiProject Tree Of LifeUser Talk:EdibobbUser Talk:EdibobbUser Talk:EdibobbWikipedia Talk:WikiProject ArthropodsWikipedia Talk:WikiProject Tree Of LifeUser:Qbugbot/sourceAndrenidaeAcmaeodera DecipiensAcmaeodera HepburniiAgrilaxia FlavimanaAmara PseudobrunneaAntrodiaetus PugnaxApsectus HispidusArhyssusArhyssus ScutatusBassareus DetritusBembidion SalebratumBlissus InsularisBoopedonBoopedon AuriventrisCannaphila InsularisChalepiniChrysobothriniChrysobothris BrevilobaChrysopilus VelutinusCoenosia AtrataConophthorusConophthorus EdulisCrabro CingulatusCulex TerritansDichagyris NeoclivisDigrammia AtrofasciataExoprosopa PainterorumFurcula ScolopendrinaGlena QuinquelineariaHomochlodes DisconventaHomorthodes DubiaIcterica CircinataLeptinusLeptinus OrientamericanusLeucorrhinia PatriciaMelanocanthonMelanocanthon NigricornisMyrmex FloridanusNemadus BrachyderusNeoterpes EphelidariaOpomydasOpomydas TownsendiParacapniaParacapnia OpisPatrobinaePatrobus CinctusPissonotusPissonotus BrunneusPlataea CaliforniariaPlatysomaPlatysoma GracilePlectopteraPlectoptera PictaPromachus PainteriPsammodiiniPsammodiusPsammodius BasalisRhamphomyia NasoniSumitrosisSumitrosis PallescensTesagrotis CorroderaUser:EdibobbUser Talk:EdibobbSpecial:RandomWikispeciesWikipedia:Village Pump (policy)/Archive 66User:IridescentWikipedia:Bots/Requests For Approval/Ganeshbot 4User:GaneshkUser:Tom.RedingUser Talk:Tom.RedingWikipedia:DGAFUser:CyclopiaUser Talk:CyclopiaWikipedia:Articles For Deletion/Anybot's Algae ArticlesUser:Jo-Jo EumerusUser Talk:Jo-Jo EumerusSpecial:CentralAuth/Jo-Jo EumerusTemplate:SpeciesboxTemplate Talk:SpeciesboxUser:NessieVLUser Talk:NessieVLUser:EdibobbUser Talk:EdibobbUser:EdibobbUser:NessieVLUser Talk:NessieVLLeptinus OrientamericanusUser:ElmidaeUser Talk:ElmidaeSpecial:Contributions/ElmidaeWikipedia:NPPUser:InsertcleverphrasehereUser Talk:InsertcleverphrasehereWikipedia:NPPUser:MduvekotUser Talk:MduvekotUser:JJMC89User Talk:JJMC89Special:Contributions/JJMC89Arhyssus ScutatusTemplate:TaxoboxUser:PigsonthewingUser Talk:PigsonthewingSpecial:Contributions/PigsonthewingTemplate:TaxonbarUser:PigsonthewingUser:Tom.RedingUser:NessieVLUser Talk:NessieVLUser:PigsonthewingUser Talk:PigsonthewingSpecial:Contributions/PigsonthewingUser:EdibobbUser Talk:EdibobbUser:EdibobbUser Talk:EdibobbTemplate:TaxonbarTemplate Talk:TaxonbarCategory:Taxonbar Templates Desynced From WikidataCategory:Taxonbar Templates Missing From ParameterTemplate:TaxonbarUser:Tom.RedingUser Talk:Tom.RedingWikipedia:DGAFUser:PigsonthewingUser Talk:PigsonthewingSpecial:Contributions/PigsonthewingTemplate:TaxonbarUser:MellisUser:AhechtUser:Peter CoxheadCategory:Taxonbar CleanupTemplate Talk:TaxonbarUser:Tom.RedingUser Talk:Tom.RedingWikipedia:DGAFUser:PigsonthewingUser Talk:PigsonthewingSpecial:Contributions/PigsonthewingWikipedia:CS1Template:Cite JournalTemplate:Cite BookTemplate:Cite WebWikipedia:ARTHWikipedia:TREEWikipedia Talk:ARTHUser:Jonesey95Wikipedia:ARTHWikipedia:ARTHWikipedia:TREEWikipedia:AutopatrolledUser:Tom.RedingUser Talk:Tom.RedingWikipedia:DGAFTemplate:Cite JournalTemplate:Cite WebTemplate:Cite BookUser:EdibobbUser Talk:EdibobbUser:EdibobbWikipedia Talk:TREEUser:Tom.RedingUser Talk:Tom.RedingWikipedia:DGAFUser:EdibobbUser Talk:EdibobbUser:Edibobb/sandboxUser:EdibobbUser Talk:EdibobbTemplate:SpeciesboxTemplate:Automatic TaxoboxTemplate:Taxonomy/PolycestinaeUser:Od MishehuUser Talk:Od MishehuTemplate:SpeciesboxTemplate:Automatic TaxoboxUser:EdibobbUser Talk:EdibobbUser:Graeme BartlettUser Talk:Graeme BartlettUser:Qbugbot/sourceUser:EdibobbUser Talk:EdibobbUser:EdibobbUser Talk:EdibobbAgonum NigricepsAmblytylusAmblytylus NasutusAndrena ErythrogasterAnthonomus LeconteiAraneus TrifoliumAxion (genus)Axion TripustulatumBicyrtes ViduatusCalycomyza SolidaginisCarphoides IncopriariusCelithemis VernaCeuthophilus ChiricahuaeChrysotimus DelicatusCoelioxys BanksiColydiumColydium RobustumCorythucha JuglandisCucullia EulepisDialysis DisparDicranoclistaDicranoclista FasciataDictyna FoliaceaEfferia LatrunculaExcirolanaExcirolana ChiltoniGlaucina LowensisHaematopota RaraHogna BaltimorianaHyperaspidiusHyperaspidius VittigerusHyperaspis DissolutaIsoperla BilineataKeroplatusKeroplatus MilitarisLebia PeritaLeia BivittataLethe AnthedonMelanoplus HuroniMicrophotusMicrophotus DecarthrusNeomegamelanusNeomegamelanus LautusNotiophilus IntermediusOmophron SolidumOrchelimum FidiciniumOrthosia TransparensPachyceramyiaPachyceramyia RobustaPerdita RivalisPoecilus ChalcitesPsen ErythropodaPterostichiniRhynencina LongirostrisRivellia MundaSalina (genus)Salina MulcahyaeSphecodes MandibularisSymphoromyia HirtaTachytes IntermediusTricholochmaea RufosanguineaUlulodesUlulodes FloridanusTricholita ChipetaUser:ElmidaeUser Talk:ElmidaeSpecial:Contributions/ElmidaeUser:EdibobbUser Talk:EdibobbWikipedia:GenFixesAnthaxia ViridifronsMelanophiliniPhaenops CalifornicaSpecial:Diff/824804244Special:Diff/824816505Special:Diff/824817233Smicronyx SpretusLacinipolia TriplehorniHermetia HunteriLobophora NivigerataLacinipolia TriplehorniMetalectra BigallisSphaeroderus BicarinatusUser:Tom.RedingUser Talk:Tom.RedingWikipedia:DGAFTemplate:Cite JournalUser Talk:Trappist The MonkGerman LanguageSpanish LanguageUser:Sir BelugaTemplate:Audio RequestedUser:NessieVLUser Talk:NessieVLUser:Sir BelugaUser:NaBUru38User Talk:NaBUru38User:John CummingsUser Talk:John CummingsWikipedia:CriticismUser:Francis SchonkenUser Talk:Francis SchonkenWikipedia:CriticismUser:HaeBUser Talk:HaeBWikipedia:UNDUEUser:Francis SchonkenUser Talk:Francis SchonkenUser:Francis SchonkenWikipedia:SignaturesUser:John CummingsUser Talk:John CummingsSpecial:Contributions/John CummingsWikipedia:UNDUEWikipedia:CriticismWikipedia:DUEUser:Francis SchonkenUser Talk:Francis SchonkenUser:HaeBUser Talk:HaeBUser:Francis SchonkenUser Talk:Francis SchonkenUser:Francis SchonkenWikipedia:CriticismUser:John CummingsUser Talk:John CummingsUser:Francis SchonkenUser Talk:Francis SchonkenWikipedia:Edit FilterSpecial:AbuseFilter/172User:Kb.auUser Talk:Kb.auUser:Kb.auUser:John CummingsUser Talk:John CummingsUser:ZzuuzzUser Talk:ZzuuzzUser:ZzuuzzUser:John CummingsUser Talk:John CummingsUser:ZzuuzzUser Talk:ZzuuzzUser Talk:North8000User:Bri/WikiturfingUser:BriUser Talk:BriUser:CollectUser Talk:CollectUser:John CummingsUser Talk:John CummingsWikipedia:UNDUEWikipedia:BLPUser:Francis SchonkenUser Talk:Francis SchonkenUser:OshwahUser Talk:OshwahSpecial:Contributions/OshwahUser:InternetArchiveBotInternet ArchiveWikipedia:SignaturesUser:Cyberpower678User Talk:Cyberpower678Special:Contributions/Cyberpower678Wikipedia:Village Pump (proposals)/Archive 138Wikipedia:Bots/Noticeboard/Archive 11User:BluerasberryUser Talk:BluerasberryUser:Jeff G.User:Jeff G./talkUser:Power~enwikiUser Talk:Power~enwikiSpecial:Contributions/Power~enwikiUser:HellknowzUser Talk:HellknowzUser:NihlusUser:AmorymeltzerUser Talk:AmorymeltzerSpecial:Contributions/AmorymeltzerWikipedia:WAYBACKMEDICUser:GreenCUser Talk:GreenCUser:GreenCUser:Cyberpower678User:Tom.RedingUser Talk:Tom.RedingWikipedia:DGAFUser:Cyberpower678User Talk:Cyberpower678User:GreenCUser Talk:GreenCTalk:List Of Mountain Bothies Association BothiesUser:ThincatUser Talk:ThincatUser:Cyberpower678User Talk:Cyberpower678User:ThincatUser Talk:ThincatUser:GenQuestUser Talk:GenQuestUser Talk:Zeke, The Mad HorroristSpecial:Contributions/Zeke, The Mad HorroristUser:Rich FarmbroughUser Talk:Rich FarmbroughUser:SMcCandlishUser Talk:SMcCandlishSpecial:Contributions/SMcCandlishUser:HeadbombUser Talk:HeadbombSpecial:Contributions/HeadbombWikipedia:PHYSWikipedia:WBOOKSUser:XoverUser Talk:XoverUser:KilliondudeUser Talk:KilliondudeUser:LindsayHUser Talk:LindsayHUser:AmmarpadUser Talk:AmmarpadUser:EaldgythUser Talk:EaldgythUser Talk:UanfalaUser:Graeme BartlettUser Talk:Graeme BartlettUser:SMcCandlishUser Talk:SMcCandlishSpecial:Contributions/SMcCandlishMy Love Is A BulldozerMy So-Called Life (Venetian Snares Album)User:JohnBlackburneUser Talk:JohnBlackburneSpecial:Contributions/JohnBlackburneUser:Cyberpower678User Talk:Cyberpower678User:JohnBlackburneUser Talk:JohnBlackburneSpecial:Contributions/JohnBlackburneUser:Cyberpower678User Talk:Cyberpower678User:Iryna HarpyUser Talk:Iryna HarpyUser:Graham87User Talk:Graham87User:EggishornUser Talk:EggishornSpecial:Contributions/EggishornUser:Jayron32User Talk:Jayron32User:AlanscottwalkerUser Talk:AlanscottwalkerUser:DhtwikiUser Talk:DhtwikiWikipedia:Bots/Noticeboard/Archive 11User:Francis SchonkenUser:Graham87User:Rich FarmbroughUser:Hawkeye7User:HasteurUser:SMcCandlishUser:Zeke, The Mad HorroristWikipedia:Village Pump (proposals)/Archive 138User:XaosfluxUser:GenQuestUser:EggishornUser:Od MishehuUser:GodsyUser:Graeme BartlettUser:LindsayHUser:Doc JamesUser:Jeff G.User:BluerasberryUser Talk:BluerasberryUser:XaosfluxUser Talk:XaosfluxUser:XaosfluxWikipedia:CRATUser:BluerasberryUser Talk:BluerasberryUser:BluerasberryUser:XaosfluxUser Talk:XaosfluxUser:XaosfluxChatbotSpambotUser:BluerasberryUser Talk:BluerasberryWikipedia:BRFAUser:XaosfluxUser Talk:XaosfluxUser:Cyberpower678Wikipedia:SignaturesUser:XoverUser Talk:XoverSpecial:Contributions/XoverUser:Cyberpower678User Talk:Cyberpower678User:GreenCUser Talk:GreenCUser:Cyberpower678User:XoverUser Talk:XoverWikipedia Talk:Bot PolicyWikipedia Talk:Bots/Requests For ApprovalUser:BluerasberryUser Talk:BluerasberryUser:RIT RAJARSHIUser Talk:RIT RAJARSHIUser:QEDKUser Talk:QEDKSpecial:Contributions/QEDKTemplate:SpeciesboxTemplate Talk:SpeciesboxTemplate:Automatic TaxoboxTemplate Talk:Automatic TaxoboxUser:NessieVLUser Talk:NessieVLZenaida MacrouraUser Talk:David StangUser:NessieVLUser Talk:NessieVLPileated WoodpeckerNorthern Fur SealAndaman ShrewUser Talk:David StangWikipedia:WikiProject Tree Of LifeUser:Jayron32User Talk:Jayron32User:PlantdrewUser Talk:PlantdrewUser Talk:David StangUser Talk:David StangUser Talk:David StangWikipedia:IntroductionHelp:IntroductionWikipedia:IWikipedia:TWikipedia:Tutorial/Citing SourcesWikipedia:WPHELPHelp:IntroductionHelp:Introduction To ReferencingWikipedia:IntroductionWikipedia:TutorialHelp:IntroductionHelp:IntroductionUser:Evolution And EvolvabilityUser Talk:Evolution And EvolvabilityWikipedia:Contributing To WikipediaUser:MoxyUser Talk:MoxyUser:MoxyHelp:IntroWikipedia:IWikipedia:TWikipedia:IWikipedia:THelp:IntroWikipedia:TWikipedia:IHelp:IntroWikipedia:THelp:IntroWikipedia:THelp:Introduction To Editing With VisualEditor/1Wikipedia:WPHELPHelp:IntroTemplate:Intro ToUser:Evolution And EvolvabilityUser Talk:Evolution And EvolvabilityHelp:IntroductionWikipedia:Tutorial/Editing/sandboxUser:MoxyUser Talk:MoxyWikipedia:Tutorial/Wrap-up And More InfoUser:IpigottUser Talk:IpigottUser:MoxyUser Talk:MoxyUser:Samwalton9User Talk:Samwalton9Wikipedia:VisualEditorWikipedia:Contributing To WikipediaUser:MoxyUser Talk:MoxyUser Talk:IsaaclUser:MoxyUser Talk:MoxyWikipedia:TutorialWikipedia:IntroductionHelp:IntroductionHelp:Introduction To WikipediaUser:MrjulesdUser Talk:MrjulesdTemplate:EfnUser:ClemRutter/trainingUser:ClemRutterUser Talk:ClemRutterUser:ClemRutterUser:ClemRutter/trainingUser:MoxyUser Talk:MoxyUser:MoxyUser:ClemRutterUser Talk:ClemRutterWikipedia Talk:WikiProject FirearmsUser:K.e.coffmanUser Talk:K.e.coffmanHelp:CategoryCategory:Wikipedia Village PumpCategory:Wikipedia ProposalsCategory:Wikipedia Move-protected Project PagesCategory:Non-talk Pages With Subpages That Are Automatically SignedCategory:Pages Automatically Checked For Incorrect LinksDiscussion About Edits From This IP Address [n]A List Of Edits Made From This IP Address [y]View The Project Page [c]Discussion About The Content Page [t]Edit This Page [e]Visit The Main Page [z]Guides To Browsing WikipediaFeatured Content – The Best Of WikipediaFind Background Information On Current EventsLoad A Random Article [x]Guidance On How To Use And Edit WikipediaFind Out About WikipediaAbout The Project, What You Can Do, Where To Find ThingsA List Of Recent Changes In The Wiki [r]List Of All English Wikipedia Pages Containing Links To This Page [j]Recent Changes In Pages Linked From This Page [k]Upload Files [u]A List Of All Special Pages [q]Wikipedia:AboutWikipedia:General Disclaimer



view link view link view link view link view link