Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

• Discussions of technical issues belong at Wikipedia:Village pump (technical).
• Discussions of policy belong at Wikipedia:Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Wikipedia:Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

« Archives, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57

A username blacklist?

Has anyone ever proposed a blacklist on usernames? This month, I've spent a bit of time countering vandalism, eventually frequently ending up on the Special:Log/newusers page. We can observe that most users registering don't actually make edits. However, we sometimes (maybe often) get offensive usernames or those that are misleading (i.e. have "admin" or "bot" in their names). Those that counter new user vandalism will be the ones that can best vouch for this.

If we had some sort of English-language username blacklist, we could potentially alleviate Wikipedia:Usernames for administrator attention from very offensive stuff, such as those that appear at MediaWiki:Titleblacklist.

Any thoughts, suggestions, or archived discussions we should note? — Andy W. (talk · contrib) 05:09, 27 April 2016 (UTC)

This would be an obvious problem with probably any username blacklist. I'm not sure if there is a good way to avoid that while still making the filter somewhat useful -- Even then prospective username trolls would just circumvent them with a near-infinite combination of look-alike characters. JWNoctis^talk 05:18, 27 April 2016 (UTC)

Andy W., doesn't it already check MediaWiki:Titleblacklist? I'm just reading Wikipedia:Account creator#Account creators' abilities and from what I take from that it already does. Or do you mean we should have a separate blacklist?  DiscantX 05:31, 27 April 2016 (UTC)

@DiscantX: wow, thanks for pointing that out... goes to show still how little I know about policy/stuff that's set up already. I suppose it is checking the title blacklist... I'm now thinking it makes sense to have a separate stricter blacklist of usernames that will obviously be blocked for being a current username violation. There must be a way to get stuff like this to be disallowed. If implemented, this would entail changing the account creator userright to override that.

I suppose the difficulty of making such a blacklist is that we want to avoid false positives, such as (potentially) my own username, if you know what I mean (haha). Pinging some folks that seem active at village pump (good faith)... @Redrose64, Iridescent, Xaosflux, and Xeno: any thoughts? — Andy W. (talk · contrib) 05:47, 27 April 2016 (UTC)

MediaWiki:Titleblacklist does not apply to user name because of SUL. However, meta:Title blacklist does control user names and has a list of English usernames that are disallowed.Jo-Jo Eumerus (talk, contributions) 05:52, 27 April 2016 (UTC)

Hence, a proposed change would have implications cross-wiki, then. I see. Since this is the idea lab, something else off the top of my head: could we auto-block these users on the English WP on a separate list?

I collected some examples (looking at some of the latest entries in the block log, and going back to the latest in March 31): 1 2 3 4 5 6 7 8 9 — Andy W. (talk · contrib) 06:01, 27 April 2016 (UTC)

The filter does seem ineffective... if, as Jo-Jo Eumerus says, meta:Title blacklist is what is checked, and *FU[C(K]+K+ <newaccountonly|antispoof> is one of the regex lines, how did 2 and 3 get through? (My regex foo is very weak, I'll admit).

Another option I can think of is having something a bit more dynamic. My understanding is that User:ClueBot NG uses machine learning to catch vandalism, and is pretty darn good at catching random gibberish such as 1, as well as obvious swears, so maybe a bot could be written for such a cause? Or User:ClueBot NG could add another task to its list and use its current knowledge to flag usernames?  DiscantX 08:50, 27 April 2016 (UTC)

As has already been pointed out above, since usernames became global it would be virtually impossible to create any kind of autoblock mechanism which wouldn't hit good-faith users; as an off-the-top-of-my-head example, there are at least three towns called "Shit", and a crude "naughty word" filter would autoblock the Shit equivalent of User:Newyorkbrad. The best one could hope for is a "this username is potentially problematic" bot which flags accounts as potentially problematic, which is what we already do. Since usernames are effectively invisible until they start editing—nobody not involved in Wikipedia is aware of the existence of Special:ListUsers—I can't see why we would want to take the spectacularly bad-faith action of pre-emptively blocking Joachim Cuntz on en-wiki should he decide to edit de-wiki with his surname as a username, and the SUL automatically create an en-wiki logon for him. ‑ Iridescent 09:31, 27 April 2016 (UTC)

Makes sense, thanks. — Andy W. (talk · contrib) 14:37, 27 April 2016 (UTC)

To get a rough idea of just how many false positives would be caught by an automated filter, just look at Wikipedia:Usernames for administrator attention/Bot, where I would say at between 50%-90% of "offensive usernames" at any given time are false positives (as I write this, Papacita1 "contains the offensive term Paki with a c substituted for a k", Adcockp "contains the string cock" and Vicfuxntxs "contains the string fux" are all listed there). Unless and until they start editing, potentially offensive usernames are the least of our problems, given that they're invisible to readers unless and until they actually make an edit. ‑ Iridescent 15:07, 27 April 2016 (UTC)

I certainly think we need to consider the Scunthorpe problem before we start to have the software disallow usernames like that. Even our bot reporting system has many false positives; it would be wrong to make a system with that many false positives actually disallow user names. And it comes with a whitelist feature (e.g we disallow the string "rape", but allow the strings "grape" and "drape"). עוד מישהו Od Mishehu 14:47, 6 May 2016 (UTC)

I doubt you could find a good program which would disallow me, but allow BunchOfGrapes.HavingRape (talk) 15:25, 16 May 2016 (UTC)

3rd party wikis links

Wouldn't it be better if Wikipedia had a 'See also on' section on the sidebar with links to the same subject on other wikis (including the sister-projects under Wikimedia)? I was thinking (for example) of wikia.com, ProofWiki and OSDev wiki - they all offer in-depth information or technical knowledge on specific topics. Also, I think that a link on the sidebar for authors to their Wikisource Author: pages would be more accessible than the same link at the bottom of the page. This would allow Wikipedia to remain a general-purpose encyclopedia, while still offering links for more in-depth technical knowledge. I think it will also help with WP:NOT#Wikipedia_is_not_a_manual.2C_guidebook.2C_textbook.2C_or_scientific_journal. — Preceding unsigned comment added by Mostanes (talk • contribs) 07:45, 7 May 2016 (UTC)

Please, no. It would be a spam magnet. --Redrose64 (talk) 10:25, 7 May 2016 (UTC)

If those links were appropriate, then they could be included as ==External links==. This is the recommended location for WP:SISTER links.

Also, you should keep in mind that very few people look at the (gray) side bar, and it's completely invisible for the huge percentage of readers who use the mobile website. WhatamIdoing (talk) 22:06, 21 May 2016 (UTC)

Content summary for notable non-fiction / academic work

I wonder if wikipedia would consider revising the guidelines it uses for summarizing notable non-fiction and academic work. Specifically, I mean work such as: Silent_Spring, Capital_in_the_Twenty-First_Century. These examples are random, but they contain somewhat different "content" and "contents" sections.

Ideally, any revised guidelines would recommend a more formal structure for providing accessible, digestible summaries of work. Perhaps: i. a short, whole book summary and then, ii. short, individual chapter summaries. Any additional information would not describe minutiae, nor provide opinion or commentary on the content, just make somewhat extended descriptive claims that provide a succinct summary of the work (in whole or part).

From what I can tell this is not against any current MOS guidelines. Indeed the text below seems to support such an idea: "...articles on works of non-fiction, including documentaries, research books and papers, religious texts, and the like, should contain more than a recap or summary of the works' contents. Such articles should be expanded to have broader coverage" (Wikipedia:What Wikipedia is not).

Guidelines like this already seem to exist for providing plot summaries for movies (Wikipedia:Manual_of_Style/Film#Plot). Perhaps equivalent guidelines could be developed for notable non-fiction / academic works. Incidentally, I note that a dormant proposal for a similar, but separate, wikimedia project already exists (Wikisummary). Importantly, the current suggestion would be to incorporate this additional information within existing wikipedia page entries.

I would appreciate any feedback. Apologies in advance if I've missed the page(s) that already deal with this issue, but I couldn't obviously find it (e.g. Wikipedia:Manual_of_Style/Contents#Topic- and culture-specific guidelines). Mvdct (talk) 16:37, 11 May 2016 (UTC)

• There's a minimal amount of guidance at Wikipedia:WikiProject Books/Non-fiction article (There is no universal set length for a synopsis, though it should not be excessively long. While longer descriptions may appear to provide more data to the reader, a more concise summary may in fact be more informative as it highlights the most important elements. is the totality of the "Synopsis" section), and links to some examples, and a list of Featured Articles on books which might help. PamD 21:55, 11 May 2016 (UTC)
• Unlike fictional works that usually have a story arc, non-fictional works take a wide array of different formats. Crafting precise recommendations on "a more formal structure" for the summary of non-fictional works would be difficult to do in a one size fits all way. We'd probably end up having a bulleted list of what to do for different types of works, contributing to documentation bloat. Instead I see virtue in Wikipedia:WikiProject Books/Non-fiction article's vagueness, allowing for editorial judgment to handle each item on a case-by-case basis. One more thing I just want to mention so it's on the table: short summaries aren't just to "in fact be more informative", they are short in large part because a longer summary may be a copyright violation. Jason Quinn (talk) 16:02, 17 May 2016 (UTC)
• There was a recent related discussion (I think at WT:NFC). @Masem: as I vaguely recall you being involved in that one--having a link handy would be good. --Izno (talk) 17:15, 17 May 2016 (UTC)
  • That I believe was [1] which turned out to be part of a class project, so might not be a good example to work from. --MASEM (t) 17:30, 17 May 2016 (UTC)
• Keeping in mind that some non-fiction books still present novel presentation of material (for example, Sagan's Cosmos: A Personal Voyage, TV or book version) means that full and lengthy descriptions of their content can be a derivative work and thus a copyright issue. I would recommend still keeping these short and concise but because we can usually hyperlink and provide good context with existing Wikipedia articles, we can have a bit more length than your standard plot summary. But these should focus on not so much the "non-fiction" (which by definition should be duplicating facts we already cover elsewhere), but the presentation of the non-fiction. Again, Cosmos is a good example as each episode/chapter is written to demonstrate how the facts are grouped under a specific theme, rather than just enumerating the facts. Similarly, The Civil War (TV series) (the Ken Burns series), as broken up chronologically, its appropriate to hit the major historical points each episode/chapter presented. --MASEM (t) 17:30, 17 May 2016 (UTC)

Ignoring past results of requested moves on commas before speedy omissions?

John D. Rockefeller Jr. Library loses its comma, but Talk:John D. Rockefeller, Jr. Memorial Parkway#Requested move 2 March 2015 was closed as "not moved" regarding the page. Somehow, TPTB decided in RFC to omit commas to go for the flow and ignore RMs. I tried case-by-case method, but I get criticized for it. Somehow, another person did that case-by-case method, but he doesn't get criticized. Anyway, the omission of commas without further discussions since a latest RM irks me, but that's how consensus decided at RFC. I'm almost running out of ideas, and I don't know where to create a central discussion about ignored RMs. --George Ho (talk) 09:49, 16 May 2016 (UTC)

New consensus can nullify earlier discussions and decisions, and that's what has happened here. The new consensus was established in an RfC and codified in the guideline WP:JR. The guideline now sets a high bar for inclusion of the comma, a high bar that did not exist at the time of the earlier RMs you refer to. Hundreds of articles have already been moved per that guideline, without discussion. For any of those, anyone is free to propose re-adding the comma if they can make the case for clearing the high bar. Anything else is a useless waste of time. We don't need to go to each article that has had an RM in the past and ask, hey, does the new guideline apply to this article? Of course it does. This has been explained to you multiple times by multiple editors, with no one supporting you that I have seen, and my suggestion is that this is a clear case of WP:STICK. ―Mandruss ☎ 11:23, 16 May 2016 (UTC)

What if an editor unaware of the whole situation sees the past RM and decides to create a newer RM? --George Ho (talk) 18:29, 16 May 2016 (UTC)

Do you mean "unaware of WP:JR"? If so, well editors do the wrong thing all the time because they aren't aware of the applicable p&g. They get corrected by someone else, eventually. If they are aware of WP:JR, and they actually paid attention when they read it, they should understand that they need to have a strong case for the comma if they want to start a new RM. That means no cherry-picking of sources, for starters. If they start the RM without such a strong case, the RM will fail and they simply waste some of the project's time. ―Mandruss ☎ 00:48, 17 May 2016 (UTC)

Would that include new editors? This is George Ho actually (Talk) 00:55, 17 May 2016 (UTC)

I don't understand your question. ―Mandruss ☎ 01:00, 17 May 2016 (UTC)

I'll rephrase: would new editors be aware of comma disputes at the start when they arrive to Wikipedia and look up past RMs? This is George Ho actually (Talk) 01:02, 17 May 2016 (UTC)

No. Actually that's part of the function of an RM, to prevent moves that are not consistent with p&g. Like I said, we all spend a lot of time dealing with the mistakes of newer editors, and it goes with the job. I don't see how that's unique to this situation by any means. ―Mandruss ☎ 01:06, 17 May 2016 (UTC)

George, thanks for notifying me that you're complaining about me (not). Anyway, this being an "ideas" page, I take your good idea to put something on the relevant talk page to forestall any future confusion about why the page was moved to where it is. Done. Dicklyon (talk) 03:30, 17 May 2016 (UTC)

I'm thinking about amending the guideline to notify readers about ignoring past RMs or WP:consensus policy. Good idea? George Ho (talk) 05:44, 17 May 2016 (UTC)

Seems like WP:CREEP in my opinion, per my comments above. ―Mandruss ☎ 08:36, 17 May 2016 (UTC)

Bad idea. --Izno (talk) 11:15, 17 May 2016 (UTC)

Come to think of it, African Americans was pluralized per RfC at WP:VPP despite previous lack of consensus at RM. No further discussion at talk page has been made; VPP consensus was made in November last year. I don't like where this is going, but I have no choice but to ignore the past RM. Same for the commas? George Ho (talk) 16:59, 17 May 2016 (UTC)

I can't say I fully understand your thought process here. For one thing, you seem to see some problem with that article being pluralized per RfC at WP:VPP despite previous lack of consensus at RM. But, per WP:LOCALCON, community consensus trumps local consensus (or lack of local consensus), so there is no problem. As for Same for the commas?, I'm not sure what you're asking, but I would oppose any new action regarding the commas. If you agree with that, thank you and I think we're done here. ―Mandruss ☎ 17:10, 17 May 2016 (UTC)

Information regarding generation of WP:Backlog categories.

I have recently joined Wikimedia Foundation as an intern as part of Google Summer of Code 2016.

My project aims to build an accuracy review bot for Wikipedia[T129536]. The idea is to build a bot that detects outdated or inaccurate content and flags them and sends them for review to the reviewers. In order to define important areas to start off with, I browsed through the Wikipedia:Backlog categories. I am keen on knowing which categories are the most urgent, the easiest to do, the hardest (and why). Also, how are these backlog lists generated? How much of it is automated and how many entries are manually entered? — Preceding unsigned comment added by 103.225.100.51 (talk) 20:45, 17 May 2016 (UTC) Prnkmp28 (talk) 20:47, 17 May 2016 (UTC)prnkmp28

Hello! Most, (if not all) of the categories listed are populated by editors adding cleanup tags to articles. Some of this is done by bot, but it is mostly human editors. Level of difficulty of cleanup depends on the article and the editor, but I have found Category:Wikipedia articles needing copy edit typically quite easy, especially when I was new. Category:Disambiguation pages in need of cleanup is also easy if you use the tool and stick to topics you know. I really can't say which are hardest, or most important. Often serious time-sensitive issues like attack pages, unreferenced BLPs and copyright violations have separate more timely processes like BLP-prod and speedy deletion. Hope that helps. Happy Squirrel (talk) 15:03, 18 May 2016 (UTC)

Thanks for pitching in with us, and welcome. Most, if not all, of the backlogs are generated by users or bots applying various tags to articles, as Happysquirrel indicated. As examples, the CSD logs are done manually by users adding one of the CSD templates, while CorenSearchBot applies tags automagically to articles it suspects of copyright violations, which adds them to WP:SCV. I urge you to stay away from the administrative backlogs at first, simply because we're already aware of them and of their size. (There are only so many of us and only so many hours in the day.) The maintenance areas might be a good place to start, maybe with articles containing {{unreferenced}} or {{cn}}. Thanks again, and good luck. :-) Katie^talk 15:32, 18 May 2016 (UTC)

Extended confirmed protection policy

Discussion

It's become necessary to begin discussing how the community will apply WP:BLUELOCK in articles outside ArbCom jurisdiction or discretionary sanctions. Rather than formulate an RFC in a hurry, let's all take a few days to hash out ideas on how to best implement ECP.

I'll begin by saying that I don't think ECP should be authorized for uses other than sockpuppetry or new, disruptive accounts that can't be controlled by semi-protection. I'm open to other uses but I'm having trouble seeing them right now. Katie^talk 15:43, 18 May 2016 (UTC)

For me, it should be the last resort. I mean, real last, not just a burst of vandalism or socking. We don't need to have the entire Wiki blue-locked. Sir Joseph ^(talk) 15:45, 18 May 2016 (UTC)

First I think we should understand, when we say "community" in the protection policy, whether we mean a priori by the community, with exceptional cases handled at a noticeboard of some sort, or whether all such discussions should be held at a noticeboard, or some other option. Ban discussions are basically required to occur at WP:AN/WP:ANI, yet the most recent case where an editor attempted to have a discussion there about a potential use of ECP is probably going to close as "no consensus" or possibly even "this doesn't seem to be the place to have this discussion", without having had a "wide" community discussion about the policy problem. (ref WP:AN#Reducing List of social networking websites from indefinite full protection to indefinite 30/500 protection). The originating RFC rejected WP:RFPP as a venue for these; what about a WP:RFPP/EPC? --Izno (talk) 15:50, 18 May 2016 (UTC)

I think an RFC is the way to go in the end. As someone who closes RFCs semi-regularly and is in the process of co-closing a big one that's muddied by a section that basically ended up as "it depends", the questions really have to be stated in a 'support/oppose' or 'yes/no' manner. It's the only way to effectively gauge consensus. How about something like:

• Do administrators have discretion to apply ECP in the same manner as they use discretion to apply other forms of protection?
• Is ECP authorized for persistent sockpuppetry?

There are obviously other questions to be asked, but these two are a start. I hesitate to propose a 'what if admins do not have discretion' as I think the first question should be answered, well, first. Katie^talk 16:02, 18 May 2016 (UTC)

It may be interesting to see the current usage of blue-lock protection. The following are the articles that have the {{pp-30-500}} template in the article text:

The only listed article that doesn't fall under Gamergate, ARBPIA, or the caste sanctions is Real Madrid C.F. I'll notify the admin who placed that protection that we are having a discussion here. Only five *article talk* pages are under blue-lock protection; they are at the end of the list and are all ARBPIA or Gamergate. EdJohnston (talk) 03:06, 19 May 2016 (UTC)

Going by the presence of {{pp-30-500}} doesn't give the full list, since that template is merely a visual reminder: it's not obligatory to add a prot icon template to protected pages. Nor does it provide any reasons for the use of WP:30/500. The full list is here. --Redrose64 (talk) 11:20, 19 May 2016 (UTC)

The number of extended confirmed users won't be confirmed unless everyone edits at least once since 9 April 2016 (UTC). 333-blue 11:53, 19 May 2016 (UTC)

I notice in comparing the lists, that there are four pages under 30/500 protection not listed by EdJohnston, those omitted are Haaretz, Im Tirtzu, Talk:Nair and Category:Temple Mount. Also, EdJohnston lists Jerusalem, but despite the blue padlock, that page is only semi-protected, and has been since 05:19, 28 February 2011 - it has never been 30/500 prot, so this edit by SSTflyer (talk · contribs) was in error. --Redrose64 (talk) 13:25, 19 May 2016 (UTC)

The admin who applied 30-500 protection at Real Madrid F.C. has now changed it back after someone pointed out the issue. EdJohnston (talk) 13:42, 19 May 2016 (UTC)

I don't think Haaretz should have 30/500 protection. It's an article about a newspaper. Has that page experienced vandalism excessive enough to warrant that? Sir Joseph ^(talk) 13:58, 19 May 2016 (UTC)

If you think Haaretz should be changed, why not ask the protecting admin, User:Rami R. If no agreement can be found, the matter could be raised at WP:AE for a decision. I only saw one recent POV-pushing edit on that article by someone who had less than 500 edits. That User:BoredSocks is now blocked by Rami R. You'd expect a sock to use a more imaginative name. EdJohnston (talk) 20:09, 19 May 2016 (UTC)

Since Haaretz has been tagged as falling under ARBPIA since 2014,[2] I felt that applying ECP would be uncontroversial. However if any admin feels otherwise, s/he may feel free to remove protection. Rami R 07:45, 20 May 2016 (UTC)

• We've needed something like this for a long time. Until now, there was no intermediate level of protection between "anyone with an account, ten edits, and four days' tenure"—which prevents the vast majority of casual vandalism and presents at least a moderate obstacle to all but the most determined sockmasters—and "only administrators". I've seen several cases where articles have ended up under long-term full protection or we've just had to accept that every few weeks somebody is going to have to block a load of socks and oversight some libellous edits. So, used sparingly, I support the use of ECP/bluelock at admin discretion where semi has been/would be ineffective and the alternative would be full protection. Perhaps the protecting admin should be required to record their rationale on the talk page (and preferably link to the diff in the protection log so that it can be easily reviewed)? This might help prevent over-use and might also prevent removal by a well-meaning admin who assumes it's being over-used. HJ Mitchell | Penny for your thoughts? 07:30, 20 May 2016 (UTC)

Well, we did have such an intermediate level of protection – pending changes level 2 – but that did not receive consensus by the community to implement anywhere. I would say that 30/500 is actually a large step up from PC2. Mz7 (talk) 17:09, 22 May 2016 (UTC)

• I generally oppose any bluelock that could be enacted by a single or small group of people. So no lone administrator (except where use in a topic area has been authorised) no local consensus (otherwise you will get walled gardens where a small group can easily lock out new editors). So some form of AN discussion with a *wide* notification. Only in death does duty end (talk) 07:57, 20 May 2016 (UTC)
• I supported the 30/500 protection on any article experiencing vandalism issues. Semi-protection is still inefficent because a vandal account may be autoconfirmed, and to vandalize semi-protected pages, for full protection it seems quite aggervating and stressful to me. KGirlTrucker87 ^{talk what I'm been doing} 22:03, 21 May 2016 (UTC)
• I think the thrust of the RfC should be answering 1) who should have the authority to implement this level of protection, and 2) when would implementation be appropriate. Here are a few options:

1. Option A: Allow use only by the Arbitration Committee (community cannot use it; most restrictive)
2. Option B: Allow use only by prior community consensus at AN, ANI, village pump or RfC for reasons to be decided on a case-by-case basis
3. Option C: Allow administrators to apply at their discretion only against persistent sock puppetry or continued use of new, disruptive accounts where other methods (such as semi protection) have not controlled the disruption (verbatim what ArbCom stipulated for WP:AE and WP:AC/DS 30/500 applications)

   Option C alt: Allow use only by prior community consensus at AN, ANI, village pump or RfC only against persistent sock puppetry or continued use of new, disruptive accounts where other methods (such as semi protection) have not controlled the disruption

4. Option D: Allow administrators to apply at their discretion to prevent persistent or egregious disruptive editing (in the same manner semi, PC, and full protection are currently applied; least restrictive)

We could have the community vote support/oppose for each option. What other options could we make available? Mz7 (talk) 04:03, 23 May 2016 (UTC)

• I don't really understand why this is particularly controversial. Maybe I'm missing something. The ArbCom resolution specifies that it is authorized for certain areas, but does not specify it is unauthorized in others (even though Wikipedia:Protection_policy interprets it both ways in different sections), and if it did, that would be policy making. Furthermore, the wording under expectations clearly opens use broadly beyond ArbCom sanctioned topics.

Bluelock is objectively a protection level intermediate to semi and full. The same rationale should be applied for escalation and reduction of protection.

Further, I would support the broad empowerment of admins to reduce fully protected pages to blue locked, with immediate restoration of full if disruption resumes. Overall, I expect it can be a useful tool for reducing the number of fully protected pages, and not, as some seem to fear, of widespread escalation of semi articles. TimothyJosephWood 13:09, 26 May 2016 (UTC)

Draft of an RFC introduction

I started this per the discussion at AN simultaneously with Katie's post here. --Izno (talk) 15:50, 18 May 2016 (UTC)

Extended confirmed protection is a new level of protection which prevents certain editors from editing protected pages of that type. Those editors must have made at least 500 edits and have been editing for at least 30 days. The edit protection was instituted due to an RFC earlier this year, mostly with the intent of providing for the then-existing arbitration enforcement scope. The Arbitration Committee recently clarified by motion the extent to which the protection level can be used as a form of arbitration enforcement. They declined to answer the question of how it should be used outside that scope. Current policy allows for the protection level to be added as the result of a community discussion. What a community discussion means in the context of the protection policy seems to be ambiguous: A recent request at WP:AN#Reducing List of social networking websites from indefinite full protection to indefinite 30/500 protection would seem to indicate that many editors at that noticeboard believe it to be of the "widely discussed" kind of community, whereas "community" discussion in the context of a ban is a discussion at a noticeboard such as WP:AN or WP:ANI. In addition, Per WP:AN#Extended confirmed protection, there appear to be administrators applying the protection without either the remit from ARBCOM or the community. Given that this is the case, what does the community think "the community" means in the context of this protection level? The previous RFC indicated that WP:RFPP is not an acceptable level. Is it a discussion at WP:AN/WP:ANI, a discussion at a new community page (such as WP:Requests for page protection/ECP), or should it be authorized broadly within a certain scope a priori by the community (a la the ARBCOM clarification)? If a prior, what is that scope? Straw poll Community discussion is at a noticeboard Community discussion is a broader discussion about use

Wikipedia:Trading card game

Should we revive this project? This might take some work, but I think it could be done. BlackVolt (talk) 20:13, 18 May 2016 (UTC)

You're a bit late to the party. Realistically, even if there weren't competition, it's likely very few people would buy it; the Wikipedia merchandise store is more of a morale-boost than a realistic commercial proposition, and I doubt it brings in as much as 0.1% of cash raised from donations. (Bear in mind that while the 3500–20,000 active editors love Wikipedia, to most of the remaining 7 billion people in the world "branded Wikipedia merchandise" sounds about as appealing as Donald Trump pornography.) ‑ Iridescent 20:21, 18 May 2016 (UTC)

That doesn’t appear to be a trading-card game, rather a fairly typical trivia/quiz game. AFAICT the only WP-specific aspect is a type of question that involves guessing the relative rank, by page-views, of a given set of articles. I would expect a trading-card game to have a prominent element of simulation—of either editing WP or using it for research—which expectation seems to accord with the ideas on the Talk page so far.—Odysseus1479 00:02, 19 May 2016 (UTC)

Odysseus has a point. That game is barely even related to Wikipedia. Plus, we can do this online (card program). BlackVolt (talk) 13:42, 19 May 2016 (UTC)

If there isn't any dissent within a few hours, I'll move this to proposals. BlackVolt (talk) 15:29, 19 May 2016 (UTC)

Alright then. BlackVolt (talk) 17:39, 19 May 2016 (UTC)

Reinstate visual editing for English

I think that this is a good idea because, without all of the loading glitches that there were before, it was a useful tool. I was recently on the Spanish wikipedia, and it has visual editing enabled, and it was a lot better and easier to understand. It was just too glitchy before. Now I might just have it disabled, please comment if you still have it, but this is something I want to see back, especially because the English Wikipedia is the one with the most information on it, it should have all of the features. [User:Williditor|Williditor] ([User talk:Williditor|WikiWilly]) 16:02, 19 May 2016 (UTC)

"Editing mode" at Special:Preferences#mw-prefsection-editing chooses your editor. PrimeHunter (talk) 16:05, 19 May 2016 (UTC)

I don't see that; I guess that you mean "⧼visualeditor-preference-betatempdisable⧽". --Redrose64 (talk) 16:18, 19 May 2016 (UTC)

It's a drop-down menu right below that. PrimeHunter (talk) 16:48, 19 May 2016 (UTC)

Thank you! Now should I delete this, or not? I don't know village pump rules very well ;) — Preceding unsigned comment added by Williditor (talk • contribs) 13:17, 20 May 2016

@Williditor: No, never delete a thread that somebody else has replied to, except within the provisions of WP:TPO. Just let it be, and once there has been no further comment for a period, the archiving bot - in this case ClueBot III (talk · contribs) - will move the thread to the most recent of the archive pages. --Redrose64 (talk) 20:21, 20 May 2016 (UTC)

Enabling "⧼visualeditor-preference-betatempdisable⧽" removes the menu. PrimeHunter (talk) 18:02, 19 May 2016 (UTC)

The new 'welcome' screen should help some editors find the visual editor if they accidentally disabled it or defaulted to the wikitext editor. You may also want to see mw:Help:VisualEditor/User guide#Switching between the visual and wikitext editors on how to switch between them. Whatamidoing (WMF) (talk) 22:15, 21 May 2016 (UTC)

Template for City, State?

The standard usage on Wikipedia for a city, state is to link to Rockville, Maryland as [[Rockville, Maryland|Rockville]], [[Maryland]] would a template (call it CSL) which would look like {{CSL|Rockville, Maryland}} which would turn into the above link be useful? This would end up being used considerably, I think, so I thought I would ask here rather than the requested template page. (Not sure if it is too US Centric)Naraht (talk) 20:08, 19 May 2016 (UTC)

I have no opinion on the template proposal, but I want to point out that such links can already be made a little shorter with the “pipe trick”: typing [[Rockville, Maryland|]], [[Maryland]] avoids repetition of the city name while producing the same result, Rockville, Maryland. This should work for any title containing a comma or parentheses.—Odysseus1479 20:21, 19 May 2016 (UTC)

Why did you mean by "the standard usage"? If there were a standard (as in "standardized") way to link US cities, there should exist a policy or guideline regarding it and there is (to my knowledge) no such thing. (It's always risky making statements about non-existence so if I'm wrong, please correct me.) Yes, there's a common way its done, but that's different. Lacking an official way of linking US cities, people do it according to editorial judgment. With that said, if such a template were created WP:OVERLINK must be kept in mind. You wouldn't want to keep linking Maryland over and over again in some article mentioning many cities in Maryland. Personally I think templates introduce complexity to the wikisource that turns away new editors so we should often prefer slightly more verbose code if it's easier to decipher for non-wikitext experts. Unless we'd be dealing with many many cities, perhaps it's best just to use the longhand. Jason Quinn (talk) 21:38, 19 May 2016 (UTC)

It should be [[Rockville, Maryland]] giving Rockville, Maryland, see WP:SPECIFICLINK. There should be no need to use two links when one works perfectly well. If people don't know where Maryland is, they're not likely to know where Rockville, Md is either. --Redrose64 (talk) 22:32, 19 May 2016 (UTC)

Agree with Redrose64. If you intend the link the city, there's probably no good reason to also link the state. A template to make it easier to overlink is a bad idea. Dicklyon (talk) 20:45, 20 May 2016 (UTC)

Editors' Main Page

Idea: Start a sort of "main page for Wikipedia editors", essentially a combination of the Dashboard, the Signpost, and a few other features, such as these:

• Today's article in need of sources
• This week's stub for expansion
• An "In the news" type feature from the Signpost
• The Tip of the Day
• WikiProjects where the Main Page has portals (in the page header) Chickadee46 (talk) 23:59, 20 May 2016 (UTC)

• I think the Wikipedia:Community portal could use some updates instead. I'd probably drop the giant hunk of "things to do" to just above the motto and that kind of gets you what you're looking for. -- Ricky81682 (talk)`

Thanks! Yes, that's just about what I was looking for. Chickadee46 (talk) 00:41, 21 May 2016 (UTC)

Great. I'd hit the talk page and see if there's a better way to organize it to what you're thinking. As I said, the things to do section is quite busy. -- Ricky81682 (talk) 10:21, 22 May 2016 (UTC)

Additional Preference options for watchlist pages that have changed?

Moved to Wikipedia:Village pump (technical) § Allow additional Preference options for watchlist pages that have changed?

 – Redrose64 (talk) 19:51, 22 May 2016 (UTC)

Category Idea

Hello all!

I'm not sure if this is the right place for this. If not, I'll be happy to post in the proper place if you could tell me where that is!

I have an idea for categories. As I don't yet know proper terminology for either categorization or coding, I have an example which I hope makes my idea clear. I'll be happy to make more examples or talk to anyone who gets what I mean! :)

Now to the actual example.

Category "Law Museums in the United States" exists

Law Museums in United States = Law Museums in "CountryName" = "MuseumType" in United States

Automatically create 2 categories.

Law Museums in "Country" (which "Law Museums in the United States" will be moved to, and create empty categories "Law Museums in China", "Law Museums in Greece", etc.)

"MuseumType" in United States (which "Law Museums in the United States" will be moved to, and create empty "History Museums in the United States", "Science Museums in the United States", etc.)

JonathanHopeThisIsUnique (talk) 03:24, 23 May 2016 (UTC)

@JonathanHopeThisIsUnique: You posted substantially the same suggestion at Wikipedia talk:WikiProject Categories#Idea - per WP:MULTI, this is not good practice, so please decide which one should remain, and replace the other with a link to the one which remains. --Redrose64 (talk) 08:46, 23 May 2016 (UTC)

@Redrose64:Hello Redrose, and thanks for replying!

Sorry for the multiple similar suggestions in different places; I didn't know how to do them properly.

I want to keep the discussion in whichever place is the better one, but I'm not sure which that would be. If both are equally good, I'd like to keep it here. Also, I don't know how to do the proper links, and what else, if anything, I should do. I'd be grateful for help/link to relevant help page!

I really appreciate your help. :) JonathanHopeThisIsUnique (talk) 17:33, 23 May 2016 (UTC)

I've removed the other one. You make links by using double square brackets, as I did in my post of 08:46, 23 May 2016, more at Help:Link. --Redrose64 (talk) 20:05, 23 May 2016 (UTC)

Future Ping

I think it would be a great idea to setup either a future ping, or a webpage listing username, article, date and reason for ping. Many articles need to be updated after a certain date, and it's up to the editor to remember to go to that article and edit. If I know that in three weeks I will need to update, I should be able to either setup a future ping, or it might be easier to have a page with a bot that pings based on the entry. Sir Joseph ^(talk) 13:40, 23 May 2016 (UTC)

You might be interested in phab:T88781. Whatamidoing (WMF) (talk) 17:16, 23 May 2016 (UTC)

Thanks. That looks interesting, hope someone picks it up.Sir Joseph ^(talk) 17:28, 23 May 2016 (UTC)

We have {{Update after}}. Works by categories and a visual "dated info" tag rather than notifications, though. – Finnusertop (talk ⋅ contribs) 22:42, 23 May 2016 (UTC)

Also note the various general-purpose, free-of-charge reminder services available on the web. They send you an email at the date and time you specify, with the note you specify. Not at all of them sell your email address to spammers. I hesitate to suggest the one I use, but you can email me if you're interested, and there are probably others that are as good or better. I generally oppose reinventing wheels, where perfectly good wheels already exist. ―Mandruss ☎ 13:19, 26 May 2016 (UTC)

Collaboration Inquiry

Hi, all.

First of all, if here is not the correct place to post this, please just let me know. I'll be happy to move it.

Last year I created a website called BetterWaysWiki https://betterwayswiki.com/. It was created as a place where people can share better-ways ideas to do things. Sharing high-quality better-ways ideas, I think, will help to accelerate human advancement to achieve higher quality-of-life.

The website itself has the following key points behind it:

1. Its most basic idea is a container for formal articles that focus exclusively on straight away highlighting what are the available better ways of doing things that can actually benefit me (from the readers' point of view) and also how it benefits me (from the readers' point of view). This forces the contributors to first able to explain why and how the new ideas are more beneficial than the existing ones
2. Content to be attractively (hopefully virally) spread via social media.
3. Free, wiki-based and community-sourced.
4. To inspire new ideas that are far better and bigger; fast and continuously.

The About Us and Help pages can be found at https://betterwayswiki.com/us/ and https://betterwayswiki.com/help/ respectively.

I've posted a few articles on the website, and on hand, I still have a few hundred other potential subjects.

Undoubtedly I'll need a lot of help to grow the website to make it as valuable as possible to as many people as possible. After some thoughts and some consultations with Wikipedia community engagement staffs, I decided to pitch the idea here to try to get some valuable feedbacks, pointers and, hopefully, supports. For Wikipedia itself, I believe that BetterWaysWiki can help contribute to bringing in more visitors especially for niche and not yet widely known subjects - BetterWaysWiki articles are just summary of better-ways ideas; it almost certain needs to include links to other sources like Wikipedia for details of each component inside.

So please don't hesitate at all to give me your thoughts, questions or requests here as I'll consider it for the future of BetterWaysWiki. — Preceding unsigned comment added by 203.126.130.140 (talk) 10:19, 26 May 2016 (UTC)

Dealing with attack pages

I would like to open a discussion, prompted by an actual incident which may not be fixable but perhaps we can discuss how to prevent it going forward.

Most of you are aware that it is not difficult for an editor to create a brand-new page which contains blatantly false or harassing information. These creations are often detected early, tagged as CSD G10 and deleted quickly. The admin dashboard highlights any such candidate in red, and is one of the highest priorities for deletion. Because of this rapid response, it is possible that many editors have not run across such pages. However, in the course of a year the number of such pages probably numbers in the hundreds, perhaps thousands.

I see two potential problems. One potential problem is based upon my belief that Google is very quick to spider new pages and may be faster at this than in the past. I don't have specific knowledge about the Google process so I might be mistaken on this, but my impression is that if an attack page was deleted quickly in the past it might never show up in a Google search and if Google is quicker about adding pages to their list this might change.

However, that's not my main concern. My main concern is that we permit other parties to copy and reuse material from Wikipedia. Some of these third parties are quite aggressive and quite timely and make copies of such pages before they are deleted. In the specific case which prompted this discussion (which I will not link for obvious reasons) an attack page was created, deleted within seven hours of creation, but scraped by an outside party in the interim. A Google search of the subject's name brings up content, probably false but embarrassing.

While the official response appears to be that we have no control over third parties I think it is our moral duty to think through whether we can do better.

My off the top of the head thought is that we might change your procedure so that any new article created by some class of editors (perhaps unconfirmed) is non-indexed and not subject to the creative Commons license until it has been reviewed by the NPP.

I fully realize this is a nontrivial concept, and might require changes to the media wiki software, but I'd like to find some way so that if some third-party does scrape such content we have a legal basis for requesting removal.--S Philbrick(Talk) 13:27, 26 May 2016 (UTC)

Google indexes new pages so quickly that I've always assumed they were scraping Special:Newpages or one of its equivalents. All of those are already noindexed, so if we flag unreviewed new articles as noindexed too, the cynic in me says that'll also get ignored. —Cryptic 03:05, 28 May 2016 (UTC)

I suspect that there's a difference between "spidering a noindexed page to find pages that aren't noindexed" and "adding a noindexed page to Google as a search result." (Not in the least that the former is slightly hard to prove, whereas the latter is glaringly obvious.) So I wouldn't be surprised if Google respects noindex on the pages even if it doesn't respect it on Special:Newpages. In any case, there's no real harm in noindexing new articles until they've been reviewed, since reviewing is incredibly fast and will be near-instantaneous for anything dealing with major breaking news (which is the only case where the difference of a few hours before a page is indexed is likely to matter.) --Aquillion (talk) 04:12, 28 May 2016 (UTC)

@Cryptic: Interesting point, but that may be testable, if I understand correctly. We could create a test article, make sure it is no-indexed at creation, and see if it is scraped by Google. I can be cynical, but I think our relationship with Google is solid enough that if they are indexing a no-indexed article, they will fix it.--S Philbrick(Talk) 18:14, 28 May 2016 (UTC)

I'm reasonably sure that they wouldn't index such a page now; my cynicism was for what I'd expect them to do after we started noindexing all new pages.

Back on subject, or at least closer to it—we might get some benefit from removing the {{noindex}} transclusion from {{db-g10}}, so that search engines, mirrors, etc. have at least some chance of picking up the current revision (which should just be the speedy template, with the original attack page blanked). I don't have even anecdotal data on how quickly they pick up changes to new pages they've already indexed, though. —Cryptic 23:17, 28 May 2016 (UTC)

Ah, I catch your point - I agree.--S Philbrick(Talk) 22:44, 29 May 2016 (UTC)

Ability to Move Questionable New Pages to Draft Space

There is currently a discussion at WT:New pages patrol about dealing with skeleton articles with very little content by new editors. At present these articles are commonly proposed for deletion. The only policy question is how long should a new page patrol reviewer wait before proposing these articles for deletion. The question has been raised of whether PRODding these articles is biting the newbie, and whether some other approach should be taken. One idea that has some support is that a reviewer should be able to move an article from article space to AFC draft space if it clearly isn't appropriate for article space. Since there is presently no rule saying that this can't be done, but no rule saying that it can be done, it will be a case of Ignore All Rules. However, if rules need ignoring on a regular basis (rather than a one-time basis), then maybe rules should be changed. Moving new articles by new editors that clearly don't belong in article space into draft space seems to me to be a reasonable compromise, neither going too far to encourage new editors and avoid the dreaded "bite" nor being too aggressive toward new editors. Comments? Robert McClenon (talk) 02:15, 28 May 2016 (UTC)

You might want to take a look at Wikipedia talk:Drafts#RFC: Clarification over main-space to draft-space moves, which closed without consensus fairly recently. —Cryptic 03:00, 28 May 2016 (UTC)

This is a foolish idea. AfC, as I have described previously, is undermanned and is not designed to work as an incubator or filter for substandard articles in the article namespace. The suggestion that PROD'ing new articles is BITEy behavior seems ludicrous to me. Almost every time I nominate an article for deletion the n00b editor makes a WP:OTHERSTUFFEXISTS argument, because too much of the content on Wikipedia is sub-standard therefore creating the impression that substandard content is fine here. AfC is not project to adress the community's collective lack of backbone. Chris Troutman (talk) 11:10, 28 May 2016 (UTC)

I agree with Chris above. If editors new or old want to bypass AfC in getting their article to mainspace, they are taking a conscious risk. They should know what mainspace is for and that failing to adhere to certain standards results in deletion. I find it improbable that new editors – those who have demonstrated not being keen on AfC by moving their article to mainspace directly – would be interested in making effort within that very process if their substandard article is moved there.

We should consider what is the profile of editors who won't through AfC when they clearly should have. Are they editors who are frustrated by AfC declining their drafts over and over again? Maybe, and these are exactly the kind of editors who either need to go through AfC or face the possibility of deletion. I'm not talking about giving them a lesson or punishing them – if they keep moving bad content to mainspace it's proof that they are immune to either. Ultimately, we are here to build an encyclopedia. To that end, keeping mainspace clean is paramount, and reserving AfC for people who actually listen to advice is also a priority. – Finnusertop (talk ⋅ contribs) 11:40, 28 May 2016 (UTC)

Thank you. So is it the opinion here that very inadequate articles by new editors that would otherwise be proposed for deletion should be proposed for deletion? There is argument about how quickly new articles should be in NPP before deletion tagging (e.g., immediately, 10 minutes, an hour), but is it being said that very inadequate articles by new editors should be treated like very inadequate articles? Does that mean (and I agree) that keeping crud out of the encyclopedia trumps the "bite" guideline? Robert McClenon (talk) 14:01, 28 May 2016 (UTC)

This proposal is a really really really bad idea. Draftspace is already full of clutter, of problematic BLP, promotional, possible copyvio etc material, that sits there for months and years and is very difficult to remove. We should not create new mechanisms for increasing the amount of that clutter. There is actually an open RfC at Wikipedia:Village pump (policy)#RfC: Proposed draftspace deletion about possible extra ways of deleting pages from draftspace. While that RfC is not likely to succeed in its current form, it does show a considerable sentiment for doing something to make deletion of problematic draftspace pages easier (Right now G13 only applies to AfC pages, so MfD is the only option for deletion, unless some other CSD criterion applies). PRODDing a new page in mainspace, even within a few seconds from its creation, is not really particularly bitey. There is no immediate risk of deletion, and the creator of the page has 7 days to improve the page - plus he/she can just unPROD the page. Leaving the new page in the mainspace, with or without the PROD tag, makes it much more likely that other users will notice it, and will either help to improve it to some minimally acceptable standard, or CSD/AFD the page. On the other hand, if the page is quickly moved to Drfatspace, it will most likely just fester there for weeks, months or years will little or no attention from other users. The end result will likely be the opposite of what the authors of this proposals intend. Nsk92 (talk) 15:44, 28 May 2016 (UTC)

• I second Chris troutman. AfC is meant, in short, to review articles for their mainspace aptitude. Flooding us with non-suitable drafts is not going to improve anything. If I come across a poor draft while reviewing, I will continue to decline them and offer the user feedback, but I don't see how moving a ton of drafts from one place to the other will in any way improve its chances if the editor isn't keen on improving them or if the subject is non-notable. Best, FoCuS contribs; talk to me! 18:24, 28 May 2016 (UTC)
• I disagree with the proposal but I would accept a greater encouragement and detailed explanation for when admins can userify/draftify a page that has been deleted. Currently that can be done after an AFD and otherwise admins can take deleted content and do that. It should also be a consideration if a prod has expired but deprodding it and moving is just as bitey to me as deleting it. From there, AFC can be a consideration but it should be the choice of the creator not other people. Someone who doesn't care to listen to an admin or anyone else who says that the page isn't sufficient is just going to make AFC miserable. -- Ricky81682 (talk) 19:07, 28 May 2016 (UTC)

I'll spit a couple points into the wind here. We're not going to create an unsustainable AfC clutter with this proposal. A new article in mainspace that would otherwise be proposed for deletion will be converted to an unsubmitted AfC draft. If the author chooses to improve and submit the article to AfC, they may. If they do not, it will be deleted in 6 months per G13.

I feel that those participating in this discussion are overestimating the capabilities and thickness of the skin of new editors. I don't think we can assume that they fully appreciate what's required to get past NPP (or AfC). The difference with NPP is that they aren't really given an opportunity to learn when their submission is summarily tagged to high heaven several minutes after submission. Also nothing about the assertion that promptly nominating new articles from new editors is not bitey is ringing true for me. I can't imagine how that experience wouldn't be disheartening. ~Kvng (talk) 03:26, 29 May 2016 (UTC)

The potential harm possibly caused by pricking the skin of some particularly thin-skinned newbies when their articles are PRODDED is a true infinitesimal compared with the great harm that implementing your proposal would actually create. But consider a different point. Most newbies have no idea what draftspace is and will not understand what happened if they see their article yanked out of mainspace and moved to draftspace. Most likely many of them will regard that act as a form of deletion, and will be not simply pricked but actually bitten by it. Nsk92 (talk) 05:25, 29 May 2016 (UTC)

• AfC is a voluntary process. Editors, new or not, don't have to submit their pages (even though it's strongly recommended for COI editors). That's the way it should stay, because AfC only works if the editors read the reviews, make appropriate changes and resubmit. We have two areas besides mainspace for drafting articles: User subpages, appropriate when a single editor is starting a new topic, and Draft space, where editors can work together to get a page up to minimum standards. There's really no point in moving a problem article into either of these spaces unless (1) there is at least one editor interested in improving it, and (2) the topic meets Wikipedia's standards for inclusion in the first place. The best way to determine these things is with the usual processes - PROD, Speedy deletion tagging or AfD, depending on how problematic the article is, with appropriate notifications. The page may still end up being userfied, moved to Draft space or put through AfC, but with less chance of it being abandoned. I can see two situations, though in which an editor from NPP might shortcut the process and move a very inappropriately written article on a good topic to Draft space: one would be if there had been a discussion with the article's creator, who agreed to keep working on the draft; the other would be if the originating editor was no longer active and the NPP editor was planning to fix up the page personally, but couldn't do it right away. This would take up a lot of time and I don't think it would happen very often.—Anne Delong (talk) 13:16, 29 May 2016 (UTC)

I am of two minds on this issue. I think it would be beneficial to have this as an option for NPP reviewers however I am mindful that this can be seen as a kind of 'back door delete'. I believe the primary purpose of NPP is to insure that new articles meet a certian minimum standard. In most cases, where there is an editor who is activly working on a new article PROD is useless and stubbing the article will be restisted as well. In those cases moving to draft is the best option and I believe forming some consensus to allow this will help avoid IAR drama down the road.

As to the matter of 'filling up AfC' I believe this is less of an issue because the only articles I thing this should apply to are ones where there is an active author. If there is no active author stubbing is, in my opinion, the proper solution for an article likely to pass notability and PRODing otherwise. (This assumes the article is not caught in one of the 'mass dePROD' events - then we end up clogging up AfD. I also note I get more complaints about AfDing articles which could have been PRODed than vice versa.) Jbh^Talk 13:31, 29 May 2016 (UTC)

How are technical changes implemented?

I'm thinking of proposing something that requires technical coding etc to implement..(creating a log of the history of all unblock requests going forward showing whether they had been granted/approved to increase transparency)..if people thought this was a good idea how would it go about being implemented (who would code it etc...I certainly don't know how)..68.48.241.158 (talk) 13:12, 28 May 2016 (UTC)

This could be done now with Wikipedia:Tags. --Izno (talk) 15:36, 28 May 2016 (UTC)

the idea would be to create a page that would list all unblock requests (perhaps all blocks too) and also whether they had been granted or denied...so people can scan down and take a look with links to the talk pages...this can be done with what you suggest above? who creates this if it's improved as an idea?68.48.241.158 (talk) 16:09, 28 May 2016 (UTC)

If you click on WP:RFU you will see a table of the open unblock requests. If the user's request is declined or if they are unblocked, the user disappears from this list. Possibly this is what you wanted. For the list of all current blocks, see Special:BlockList. The record of all blocks ever issued can be seen in Special:Log. EdJohnston (talk) 17:01, 28 May 2016 (UTC)

but there's no transparency because you can't see the total history of unblock requests..and have any sense whether they are being handled appropriately over time/be able to take a look at ones from the past....I'm concerned there are a small number of block happy admins dealing in this area and they are chasing off potential new editors to Wikipedia...68.48.241.158 (talk) 17:18, 28 May 2016 (UTC)

i'd like to see a log like the one you linked to but dealing with the history of unblock requests..68.48.241.158 (talk) 17:20, 28 May 2016 (UTC)

You can see the history of open unblock requests here. When they are removed, they have been declined or accepted, but you can't tell what happened without going to the user's talkpage. -- The Voidwalker ^Discuss 17:28, 28 May 2016 (UTC)

right, that's the problem...but I'll have to bring that up elsewhere first...I was just curious how something that needs a technical implementation is implemented...68.48.241.158 (talk) 17:29, 28 May 2016 (UTC)

There is plenty of transparency, it is just not indexed the way you like. Unblock requests are tracked through categories, and while the software does track what pages are in a category now it does not log when they are added and removed.

This means you can get the information but it will take some effort on your part. There is the block log, this logs every block and unblock. Choose your time period, look up all the blocks, then go through the talk page history on each one to see how it turned out.

This will take some work so I guess it depends on how much you want this information. We do have an API if you want to try and automate it. HighInBC 17:35, 28 May 2016 (UTC)

right, there's no transparency because one would have to jump through major hoops to get any big picture sense of what's going on...but that's a debate for later and elsewhere...I'm trying to learn how things like this are implemented technically...what is API? I'm not personally experienced in any way at coding..would I be responsible for putting it in place?68.48.241.158 (talk) 17:41, 28 May 2016 (UTC)

Since you appear to be the only person who wants this, then yes, you would have to do it yourself unless you can persuade someone else to do so; the WMF devs are not your slaves. As HighInBC correctly says above, this is a complaint that you don't like the way we currently index the information in question rather than a question of the information being somehow hidden, so "transparency" doesn't come into it. ‑ Iridescent 17:58, 28 May 2016 (UTC)

because I said anyone is my slave...and we're even discussing a proposal here..thanks for the helpful and thoughtful post!!68.48.241.158 (talk) 18:07, 28 May 2016 (UTC)

It's actually possible to watch addition and removal of pages in categories now. Create an account and log in. Go to Category:Requests for unblock‎. Click the star tab to watch the category. Click Watchlist. If the "Hide:" line has a check mark at "page categorization" then remove it, or change the setting permanently at Special:Preferences#mw-prefsection-watchlist. You can watch up to 30 days back. PrimeHunter (talk) 23:08, 28 May 2016 (UTC)

okay, that's interesting...still don't think it solves the transparency issue I'm after in terms of a straightforward log that memorializes it all going forward so people can get a sense of what's going on..68.48.241.158 (talk) 00:37, 29 May 2016 (UTC)

The mw:API is a means to access the logs and content of Wikipedia through an automated tool. I don't think anybody is going to do your research for you, but the information is there if you want to get it. HighInBC 18:14, 28 May 2016 (UTC)

(edit conflict) I'd also add that I don't think you have any idea of the scale of what you're suggesting, when you talk about logging every unblock—let alone every block—at a single page. As of June 2014 (which is when the logs stop for technical reasons owing to the Labs move), 90,165 unblocks and 2,693,123 blocks had been performed. ‑ Iridescent 18:17, 28 May 2016 (UTC)

trivial as far as data size..still interested in learning how technical tools are implemented if it's been determined by consensus that they are desired...are there tech people that volunteer to code things or what?68.48.241.158 (talk) 18:27, 28 May 2016 (UTC)

There are basically 2 mechanics - either someone writes a tool to perform their analysis and post results (possibly a bot that you can request someone else create and run if they want to at WP:BOTREQ) or you get programmers to create a module and load it, or change the core mediawiki software to do something like this for you by creating a Wikipedia:Bug reports and feature requests. — xaosflux ^Talk 02:21, 29 May 2016 (UTC)

okay, for example. above someone linked to "Special:blockedlist" which has all current blocks...this is a page/function that must not have existed at some point in time and was then created...how was it created and by who?68.48.241.158 (talk) 13:04, 29 May 2016 (UTC)

Hello User:68.48.241.158 I think you are referring to Special:BlockList. That display contains a list of blocked users, merged with information from the block log. I don't know the name of what developer wrote that code, and it has been part of the core for what seems to be at least 10 releases. You may want to follow up on mediawiki-l to see where to find the history of that section of code.

Changes to the functionality of the blocklist are normally going to be outside the scope of the English Wikipedia, as they affect the software base - not the encyclopedia project. You can propose changes or enhancements to the software here: Wikipedia:Bug reports and feature requests ("Requesting a change" and "Reporting a bug" are basically the same thing - the creation of a "task" that software developers can choose to pick up or not). If you are a programmer, you can pick it up your self and get to programming, then request your new software section be merged to the main code base, or added as an extension. While I do report "bugs", I'm not currently involved with programming so don't have a lot of details on the "how" of all of the steps.

As to your idea, "unblock requests" are not really something that exists as far as the software is concerned - they are just edits; and they don't necessarily always occur as edits, unblocking requests can also be made by email, via UTRS, on IRC, etc.

If you want people to come up with ides for changing how these requests are processed careful consideration of all options will need to be decided. Also, are you only trying to solve this for the English Wikipedia? Rolling in software changes is something that affects everyone who uses mediawiki - thus the care needed. Additionally, if you want this to be consistently usable, you would need the community to agree to a policy that a specific mechanism must be used to the exclusion of others, and I don't think you would get much support on that.

— xaosflux ^Talk 17:30, 29 May 2016 (UTC)

thank you for the excellent info and thoughtful reply.68.48.241.158 (talk) 17:44, 29 May 2016 (UTC)

(edit conflict) Under its old name of Special:IPBlockList (despite the name, it was always a list of all blocked users), it's been a part of MediaWiki since Nupedia days, back when Wikipedia was small enough that Jimbo approved the blocks personally. If you're interested, User:Throbbing monster cock appears to have been the first registered account to be blocked from Wikipedia. ‑ Iridescent 17:56, 29 May 2016 (UTC)

Locking Involved Sport Players During Big Final

As seen with Yannick Ferreira Carrasco (forgot how to add link as I'm watching final now), it's become quite noticeable in and out of Wikipedia that during big sports finals, especially football,with the Euro's coming up aswell you get people changing names short facts and intros. I think that maybe we should consider blocking sports personals involved. Though I'm not sure if it will be possible to implement or really stop the problem. I'm sure we'll see changes to the wikipage of the player who scores the winner.

Pages are only protected when persistent vandalism has occured, not per-emptively. See WP:NO-PREEMPT. Protection is done on a case-by-case basis and not blanket topics. – Finnusertop (talk ⋅ contribs) 22:03, 28 May 2016 (UTC)

Also, during major sporting events is exactly when we don't want to lock the biographies of the players involved, since by definition that's the period when there's most likely to be new information published about them. ‑ Iridescent 17:33, 29 May 2016 (UTC)

Prevention of Link Rots

Link rot is starting to become prevalent in many articles with references to old blog posts that no longer exist. My idea is to start using Internet Web Archives as a way to keep the cited resources available for others to access and refer to.

For example: See this article's 1st reference link. If you click on the first reference link, it will link you to "Page not found" error page. This is an issue if Wikipedia continues to cite resources without the ability to obtain a snapshot of what the resources look like.

Tom Mai (talk) 04:25, 30 May 2016 (UTC)Tom mai78101 00:25, 30 May 2016 (UTC)