Wikipedia:Village pump (idea lab)/Archive 20

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

Put Any Wikipedia Article on a Timeline

Well we have finally accomplished our task of giving anybody the ability of putting most of Wikipedia history on a timeline, at:

http://wikitimelines.net

Look at this website on the largest computer screen that you can get your hands on. We eventually would like to create a timeline of all history. This was a massive undertaking. For right now, you can add and delete any Wikipedia article you want from this timeline (just click the green "Add" button). Any and all 4 million of them, any 6 at one time. Instructions are included under the heading "New user message". Do you think this would be a good history education tool? From elementary to the collegiate level? I know I would have loved to have a tool like this when I was taking European history in college.

And you can (eventually) put anything on this timeline. Medical histories, legal documents and project plans. Even whole books! The potential is endless.

There are still some bugs and other foibles we are working on, but it is pretty stable now.

Thanks Jeff Jroehl (talk) 09:52, 22 January 2016 (UTC)

Wow, that's neat! Maurreen (talk) 05:17, 19 February 2016 (UTC)

@Jroehl: This is a great tool and an amazing bit of coding from what I understand of the NLP paradigm. Kudos!

I do have a simple feature request I hope you will consider... Allow the tool to accept a Category: namespace URL like en.wiki.x.io/wiki/Category:20th-century_physicists. Parse the page HTML to extract only those items that match the CSS parameter .mw-category a:link and build a list of pages to add to a timeline. You have not mentioned if the tool has an upper limit for number of articles per timeline but if there is an issue there just cap the HTML parser to the first NNN a:links with NNN being the max allowed.

Alternatively, extract a single-level of all links from any given article page such as en.wiki.x.io/wiki/Chemical_element, limiting the extract to only those links inside the mw-content div. This would allow users to see the relevant timeline for a given article. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 12:41, 19 February 2016 (UTC)

@Koala Tea Of Mercy: Thanks! I will look into the category issue. It sounds like it might have some potential. The timeline, as it is right now, is extremely complex over a whole host of reasons. One issue of (potentially) timelining whole categories, is the fact that the human eye can only distinguish a limited number of colors. For simplicity sake, we are only utilizing 6 colors. Therefore you are only allowed to have 6 articles on any one timeline, at any one time. It is theorized that this could go to 20 colors. Search for "The Tableau 20 colors" for a discussion on that. There are dozens of "feature requests" we would love to add to our curious timeline contraption. I have a long list. We just don't know if investing more time in this tool is worth the effort. Is it really that interesting? If we could get more adoption and interest, we would attempt to add a whole host of new features. Basically, it all comes down to marketing. And since we are relatively unknown people, this is very difficult for us.

So, unfortunately, we are stuck, after 5 years of development. It is called "The real world" we have to deal with. But we are optimistic!

Thanks Jeff

Jroehl (talk) 04:48, 22 February 2016 (UTC)

I hear you man, living in the real world would be so much easier if it didn't intrude into our online life!

A thought on the color issue. Take a lesson from sailors and use color combinations. If your timeline bar is just 4 pixels tall that is enough to do two contrasting colors as a pair of horizontal lines (=======, example red on top and yellow on bottom). This alone will dramatically increase your color options. You also could do other color combos like 4-pixel tall, 3-pixel wide diagonal stripes (//////////).

Just an idea. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 10:02, 22 February 2016 (UTC)

@Koala Tea Of Mercy: Actually, you are correct, the 2 color lines would greatly expand the potential color combinations. Why didn't I think of this? I thank you for this tip!

Jeff Roehl Jroehl (talk) 10:12, 22 February 2016 (UTC)

I spent some time this morning looking for a good outline tool to use and then this afternoon I stumble upon your post. I love this feature! I'm working on articles about publishing history and this will come in very handy. Jaldous1 (talk) 23:19, 10 April 2016 (UTC)

Statistics Website

Hi, since 2011 the website wikiscan.org calculates statistics for French Wikipedia. The project is to transform it into a multi-wiki site with a dedicated site for every Wikimedia wiki with more than 100,000 edits, actually it would make more than 300 sites. I plan to apply for a m:Grants:IEG to achieve this big transformation and also add a multilingual interface with an English version and other improvements.

In summary, the site provides two main types of statistics:

• Statistics by dates, for every day and every month for the wiki history, and for the last 24 hours:
  • Most active pages according to several criteria (number of users, edits, revocations, size changes and pageviews when it's available), examples with fr.wp: 1 February 2016, January 2015, January 2015 on archive.org (when pageviews were active, visible in the first column).
  • Most active users according to the number of edits, logged actions, revocations and size changes. Examples: 1 February 2016, January 2015.
  • General statistics over this period: total number of edits, edits for each namespace, article creations, deletes, blocks, etc. [1] [2]
• Pre-computed statistics for each user, this allows to quickly view the page even with many edits, for example a bot totaling about 2.5 millions edits [3]. A classic edits counter can take more than 2 minutes to load as many contributions or fail [4]. The downside with pre-computed statistics is that last changes may take longer to be considered, on French WP it's actually between one and two hours, for English WP it will probably be more.
  • Approximately 30 statistics are calculated: total edits, creations, talk namespace percent, number of days and months with at least one action, the overall diff, the number of small or large changes, estimated time spent doing edits, etc.
  • These statistics are available for the total and in tables for each year and month.
  • There is also a chart by month and a pie chart by namespace groups.
  • A table summarizes these statistics for all users [5], sortable for most statistics. The same table is envisaged for each year and each month.

Would you interested in an English Wikipedia Wikiscan ? the site address would be http://en.wikiscan.org. It is also planned to support other projects like Commons, Wikidata, Wikisource, Wiktionary, etc. --Akeron (talk) 18:09, 18 February 2016 (UTC)

User:Akeron, looks useful! Fences&Windows 09:25, 27 February 2016 (UTC)

• Yes. I was thinking of this very concept myself today but more from the point of view of "how many visitors has this page had?" but the other statistics would also be interesting to see how much a particular topic was corrected over time. kk (talk) 23:52, 20 March 2016 (UTC)

  @Fences and windows and Do better: thanks, the IEG is open on m:Grants:IEG/Wikiscan multi-wiki. --Akeron (talk) 16:39, 12 April 2016 (UTC)

Few ideas

Here are few ideas just to think about. It is not meant to be ever implemented. Just ideas.

• User recieves notice ring if someone proceed the conversation in which he participates, no matter he is not literally mentioned in future posts ({{Ping}}).
• (±123) Page size change in bytes when you preview the page. Easier to decide whether or not to mark a minor edit.
• Slideshow button if <gallery> by default as in Commons
• Edit section0 link by default
• Special:SpecialPages would need interwikis
• Activity light bulb at signature, for example --Example (talk) 15:06, 5 March 2016 (UTC)

Categories

Categories [ edit ]   Show in columns   Sort by alphabet 1879 births | 1955 deaths | 20th-century American engineers

• Introducing "sectioncat". For most users that would be the easier way to edit categories.
• Options to show categories in columns and/or sorted by alphabet order. The article of Albert Einstein currently (as of March 2016) has 71 categories. The average reader is hard to find the desired category. Maybe even better idea is to show categories in columns by default, as in "What links here" pages and many other lists.

Advanced search options (layers) for admins

Often I miss one of the following options.

Search

Layers   Live pages   Deleted pages   Past versions   Content   Titles   Redirected titles   Code   Summary

Namespaces   (Article)   User   Wikipedia   ...

--Janezdrilc (talk) 15:56, 5 March 2016 (UTC)

Some of those options are already available as search parameters (for everyone), e.g. intitle:, insource:. Searching deleted pages and/or past versions would probably be tough, and should probably be a different special page entirely (though WikiBlame covers searching an individual, known page's past revisions somewhat). Searching for redirects would presumably require a special search parameter, because currently search surfaces the target page if a redirect matches a search. Some of the rest … would require the suggestions to be more concrete; does "summary" mean "searching the edit summary field"? {{Nihiltres |talk |edits}} 17:48, 5 March 2016 (UTC)

Searching within deleted pages is borderline technically feasible and probably won't happen. Searching in past revisions is probably not feasible performance-wise for the same reason. Searching for deleted titles on a different special page is hopefully coming soon. MER-C 05:29, 7 March 2016 (UTC)

That's great. intitle: and others actually are layers that I had in mind. Maybe they just have to be put in the form of » « (as above in the table). It would be much more user friendly. --Janezdrilc (talk) 11:18, 7 March 2016 (UTC)

• Find a way to prevent Wikipedia Link Rot from occurring in the References section of all possible articles. — Preceding unsigned comment added by Tom mai78101 (talk • contribs) 05:02, 17 April 2016

IDEA: Watchlist indication/activation from other users' pages

This is a problematic editor that I have to watch a little more closely in my capacity as a gnome admin, because I suspect him of sockpuppetry. While scrutinizing his edits I added a bunch of articles he's edited to my watchlist. It occurs to me that it would be helpful if I could add pages to my watchlist directly from his contribution history, instead of having to open each article and click the star. It would also be helpful if I could see in his contribution history which articles we have in common.

I can see this being used in a pernicious way to stalk other editors on Wikipedia, so maybe it makes more sense for admins, although I know a lot of power editors who might also benefit from this. Thoughts? Cyphoidbomb (talk) 02:01, 6 April 2016 (UTC)

As to your wish to compare lists of articles edited by different users, we do have this tool. עוד מישהו Od Mishehu 16:07, 7 April 2016 (UTC)

The watchlist is already so crowded as to be confusing and difficult for many users, but this seems like the kind of thing you could run a userscript to do. (Bonus: you could turn it off when you didn't need it.) Maybe ask at WP:VPT to see whether any of the script-savvy folks agree with my guess that you could do this in userscript? WhatamIdoing (talk) 03:05, 8 April 2016 (UTC)

Od Mishehu, thank you for the tip, although I think you misread my request. :)

WhatamIdoing, your point is noted about the crowded watchlist, but I'm proposing functionality that would enable me to add articles to my watchlist directly from another user's contribution history. With sock operators, for example, it's necessary to follow them to other pages. Often they have niche interests, so if you start watching pages they are interested in, you will often be led to their socks sooner. I'll ask at VPT, though, to see if anyone can think of a quick solution. Regards, Cyphoidbomb (talk) 03:40, 8 April 2016 (UTC)

Thanks for the correction; that was sloppy of me. Perhaps some might disagree, but I think that Special:Contributions isn't quite as crowded as Special:Watchlist. It looks like a good script writer over at VPT is interested in this, so you may be able to try it out before long. WhatamIdoing (talk) 05:59, 8 April 2016 (UTC)

Note that the Navigation Popups Gadget has a watch/unwatch command that’s only a click away when you hover over any wikilink, be it on a Contributions page or anywhere else. It doesn’t add pages en masse, but you’d probably want to be selective anyway.—Odysseus1479 23:39, 15 April 2016 (UTC)

Research announcement: Learning from article revision histories

I'd like to announce an IEG proposal I'm working on titled "Learning from article revision histories". The basic idea is to develop some web tools for studying article revision histories which would allow, for instance, people to compare historical versions of articles or particular sections. I know there are a number of diff tools available, but as far as I know, there is currently no way to easily put a particular diff up for a vote from a survey of editors. I say "as far as I know" because I'm relatively new to Wikipedia, and it's likely I'm not the first to ask some of these questions. My hope is that tools like this could be used to make editorial oversight easier, and facilitate community involvement when disagreements arise. But the tools I'm proposing are only useful if they are addressing a real need, and I admittedly don't know much about the frequency of disagreement among editors. If you have some comments about whether disagreement is a actual problem that should be addressed, please consider leaving your thoughts on the talk page for the proposal.

Evoapps (talk) 20:52, 6 April 2016 (UTC)

You might want to look into Wikipedia:Labels, which can be used to score/tag individual diffs. Whatamidoing (WMF) (talk) 03:08, 8 April 2016 (UTC)

I want to let readers know that my "Learning from article revision histories" proposal is much improved based on feedback, and I believe it is now a project that will be much more valuable to editors and researchers alike. Thanks to Whatamidoing (WMF) for telling me about Wikipedia:Labels; my proposal now integrates more closely with the Wiki Labels project as well as the ORES. Others have provided valuable feedback as well about related work that has been done in this domain. Please consider checking the project out! -- Evoapps (talk) 15:29, 16 April 2016 (UTC)

"Arbitrator" user group

So, the Wikipedia:Non-administrator Arbitrators RfC over a month ago did in its closure feature a rough consensus in creating an "Arbitrator" usergroup for arbitrators, but the closer indicated that it would need some development and further discussion. So, now it may be time to discuss how to implement that - assuming that the close still stands. Noting also this revision regarding one possible setup and whether it would be acceptable to the WMF given that it involves sensitive permissions.Jo-Jo Eumerus (talk, contributions) 18:50, 30 December 2015 (UTC)

If I recall correctly, this would not be a foundation problem - provided that any access granted follows the same requirements (community approvals, identification, etc) that is already in place. Creating a new usergroup is fairly easy. We would need to decide what permissions are actually required for the group, see example list of all available permissions here. Users can belong to multiple groups, and their permissions merge. So for example, the new group could be granted the ability to view deleted and oversighted (deletedtext and viewsuppressed permissions) without the ability to also delete or oversight the pages. — xaosflux ^Talk 19:30, 30 December 2015 (UTC)

This would require the user to ALSO be an oversighter, administrator, etc to gain the additional permissions. This may open the discussion to limit or expand the permissions someone gets just for being on the committee. — xaosflux ^Talk 19:32, 30 December 2015 (UTC)

Also, by default new groups would only be able to have membership changed by stewards - and if bundling portions of oversight or checkuser the foundation would likely still require this. If they will have equal to or LESS permissions than administrators, then we could also request that our 'crats be able to update the group. — xaosflux ^Talk 19:35, 30 December 2015 (UTC)

Among the concepts proposed in the RfC was to give this group solely the "view" privileges (that is by my assessment, abusefilter-hidden-log, abusefilter-log, abusefilter-log-detail, abusefilter-view, abusefilter-view-private, browsearchive, checkuser-log, deletedhistory, deletedtext, spamblacklistlog, suppressionlog and titleblacklistlog), although editprotected may also be useful if arbitrators have to work within protected pages. And yes, such a group if it includes the "sensitive" permissions (here suppressionlog and checkuser-log and some abusefilter permissions) it would need to be added/removed by stewards only; if not requested by the WMF, the folks in Phabricator will likely ask for it since non-steward granting of such permissions has created issues in the past.Jo-Jo Eumerus (talk, contributions) 21:34, 30 December 2015 (UTC)

I pruned duplicated items that are already in "users", etc - so this could be a request such as:

• Create a new group: Arbitrators

Include permissions:

abusefilter-hidden-log

abusefilter-view-private

browsearchive

checkuser-log

deletedhistory

deletedtext

spamblacklistlog

suppressionlog

titleblacklistlog

viewdeletedfile

viewsuppressed

— xaosflux ^Talk 22:08, 30 December 2015 (UTC)

Now, a prime question is - is this moot? Since ArbCom is the deciders of who gets CheckUser and Oversight - if they are going to just assign themselves the permissions then there is no need to include that stuff in here. — xaosflux ^Talk 22:10, 30 December 2015 (UTC)

If memory serves, some arbitrators have stated that they won't use this full "requestable" permission set, so a more narrow set may be useful. Plus, I am not sure if the OS and CU rights entail all the permissions mentioned before, which may matter in case of a non-admin being elected to ARBCOM.Jo-Jo Eumerus (talk, contributions) 22:27, 30 December 2015 (UTC)

Purely from the perspective of programming and security, it makes sense to have a group for arbitrators. Membership in this group begins when their term starts, and ends when they leave. If an arbitrator gets CU or OS, they may keep it beyond the end of their term, or remove it early. In theory an arbitrator might not have sysop access, or might resign sysop after being elected. We should disentangle the roles so that each hat works independently of the others. Jehochman ^Talk 22:44, 30 December 2015 (UTC)

Please identify the problem before offering a solution. Why would an arb need all these permissions? Arbitration always takes plenty of time so why can't other arbs provide information that an individual may not be able to access? In an emergency any sensible arb should quickly act on the advice of respected users with the permissions, with a review to follow. Do arbs frequently need to study deleted pages and such like? Johnuniq (talk) 00:56, 31 December 2015 (UTC)

Do they really need another 'feather' ? I think the voting was done without any user there having any knowledge on how this would be done. Sometimes certain rights are removed when not used such as OS/CU so how would you go about doing that? for example a sitting arbie, AGK lost his CU/OS rights for inactivity but he is still an arbitrator, so would the stewards remove his "bundled" arbitrator right when he isn't active? It would be silly to bundle multiple rights into one cannister especially for a group which will never have more than 15 members at any given point....I think only large groups, or groups that can allow for more users should have their own special usergroup (the only exception is the founder rights ofcourse)..This might need another discussion..--Stemoc 01:48, 31 December 2015 (UTC)

AGK did not lose his CU/OS access by inactivity, as you can see here. Also, as said here sitting arbitrators are not subject to the (local) inactivity policy. As for deleted pages, yes, I do remember a number of cases where deleted evidence did play a role.Jo-Jo Eumerus (talk, contributions) 09:50, 31 December 2015 (UTC)

@Johnuniq If we ever elect an arb who is not currently an admin then yes they would need access to deleted and indeed oversighted edits. If they had to rely on other arbs to check deleted revisions and decide which were appropriate to show them as evidence then we would have two classes of Arbs. I would prefer that only those who had been elected as admins were deleting, restoring, blocking and unblocking. But all arbs need to be able to see the same evidence. ϢereSpielChequers 10:29, 31 December 2015 (UTC)

In reply to User:Jo-Jo Eumerus's comment of 18:50, 30 December 2015 (UTC) at the top of this section: Unless the Arbitration Committee or at least a significant minority of that committee ask for such a feature, I think we are putting the cart before the horse. In any case, if and when a majority of the committee ask for it, as long as it only affects members of the committee and it doesn't give them rights they don't already have, it should be done as "routine maintenance" without further community input. The only reasons I can think of for the community to discuss this is if a significant minority of the committee would like this or if it would be an actual "upgrade" in permissions beyond what the community has already given them. I don't see evidence of either one of these conditions being met right now. davidwr/(talk)/(contribs) 18:34, 1 January 2016 (UTC)

Pretty sure we need a community consensus before any user right will be created. I remember that the developers in Bugzilla/Phabricator require a community consensus for such things, an ArbCom request is not enough.Jo-Jo Eumerus (talk, contributions) 13:59, 2 January 2016 (UTC)

From a logical point of view, I agree with the concept of creating a usergroup specifically for ArbCom members, namely:

• Permissions necessary for an arbitrator to do the job can be issued directly to the group as opposed to needing to add a given Arb to perhaps two or three groups (sysop, oversight, checkuser - as required). By the same token, at the expiration of their term, it's only one group to take that arb out of instead of having stewards/crats lookup what group(s) the former Arb had and removing the others
• Through use of $wpAddGroups, $wgRemoveGroups and $wgGroupsRemoveFromSelf Arbs can add/remove specific groups to other editors (class examples: CU/OS)

Just my two cents (keep the change)

Dax Bane 01:33, 2 January 2016 (UTC)

Arbitrators cannot add or remove people from usergroups. When arbcom appoints someone as e.g. a checkuser, they make a request for a steward to add the user concerned to the checkuser usergroup. Likewise when permissions are removed for inactivity, a request is made to the stewards for the permissions to be removed. This will not change if the arb usergroup is created. Thryduulf (talk) 13:17, 3 January 2016 (UTC)

Indeed, Arbs currently do not add/remove other editors from groups, but if a group were created specifically for arbs then why not give them limited ability to do so? Dax Bane 20:32, 3 January 2016 (UTC)

As far as CU/OS go - these require additional foundation requirements (identity verification) in ADDITION to the request of the local arbcom. — xaosflux ^Talk 20:37, 3 January 2016 (UTC)

Point taken Dax Bane 00:39, 4 January 2016 (UTC)

Didn't we already determine that Oversight Access allows for access to view deleted content, and that an ArbCom election was considered RfA-identical enough to meet the Foundation requirement for Oversight access? Therefore the Admin bit is not necessary to view deleted content, if the Arb were given Oversight access? (Note this was never tested practically, but as per before, I would be willing to drop my admin bit for a few hours to try it out, if we wanted to know what one could and could not do for sure.) The CheckUser log access is of little value as it provides little information, also keeping in mind that not all Arbitrators are CheckUsers (by choice). If we had a non-admin Arbitrator, they could be provided Oversight Access, and have all of the tools necessary without creating a new usergroup (plus the ability to revision (un)delete and revision (un)suppress, but not to delete an actual page). I think this is a solution looking for a problem. The idea of creating a new usergroup, for a hypothetical non-admin arbitrator that may or may not get elected in the future, when really all we have to do as give them a single permission, that they are already entitled to. --kelapstick^(bainuu) 02:35, 7 January 2016 (UTC)

Oversighters have all the required permissions to view deleted revisions without the admin flag (though oddly enough not the ability to delete pages, which would be required for some suppressions), and according to the global policy could be appointed by arbcom without being local admins. In terms of a need for the group, maybe? Some projects use one for arbitrators, others don't. If the group had CU or suppression log viewing abilities then it would need to be granted from meta by stewards, but if it just had the ability to view deleted revisions and the like then it could be granted locally by bureaucrats.

I'm not convinced of the need for such a group myself. You can just give arbitrators an admin flag for their tenure, if need be. Ajraddatz (Talk) 02:45, 19 February 2016 (UTC)

Arbcom elections and RFA look at very different things. I would be surprised if the community elected an arb who couldn't be trusted with the block button, but it is entirely possible that we could elect an Arb who we wouldn't trust with the delete button. ϢereSpielChequers 19:35, 8 March 2016 (UTC)

 Comment: We at Russian Wikipedia have had the arbitrator flag since June 2013, and AFAIK we've never had any problems with that. It includes 4 rights, namely browsearchive, deletedhistory, abusefilter-log-detail & deletedtext. P.S. I know the situation here is quite different, I'm just telling you about our experience. -Синкретик (talk) 19:00, 22 April 2016 (UTC)

WikiPolls

As a sister site, WikiPolls feels as though it could be a good idea, but, first, I would like to explain what it is and see whether there are issues to be repaired:

WikiPolls in my idea is a sister site which anyone can edit and wherein users can post their own topics such as "What World War subject is your most favorite? [Button]—World War I...[Button]—World War II...[Button]—the hypothetical World War III" for users to answer by selecting choices and then clicking on the "Vote" button. Of course, it would be hard to find topics by just searching for their topic names and entry names, so tagging them with words such as "World War" would help making searching much faster, and, to avoid giving in false polls or altering users' initial votes, users would have to vote in order to see results. Also, we would obviously not want to have polls such as "Which Wikipedia user is worse?" and even "Which of the following is the worst terrorist?", for that might otherwise make likers feel upset from seeing negative results after voting, and we especially do not want controversial entries such as "For whom do you want to win after the 2016 elections?", for that can skew general people's votes into getting apparently bad leaders.

This is only an idea, and I am only looking for suggestions. Gamingforfun³⁶⁵ (talk) 02:29, 13 March 2016 (UTC)

why would I want to go there?

btw, this is the wrong place. If I remember correctly you should put this on meta--Dixtosa (talk) 04:49, 13 March 2016 (UTC)

I was suspicious that it might have been that place where it belongs, but it was hard for me to tell (EDIT: Additionally, it was made harder because I have accidentally visited MediaWiki on the bottom-right corner of the page layout instead.), and the rules did not say that I must not do that, but, regardless of what I have said, I shall relocate this topic. Gamingforfun³⁶⁵ (talk) 09:19, 13 March 2016 (UTC)

Even though the official rules for submitting sister project ideas do not exist here, which is very misleading, what do you think of polls? Now, just forget the WikiPolls project for now. Gamingforfun³⁶⁵ (talk) 09:44, 13 March 2016 (UTC)

Sister sites are required to have an educational or informational purpose. This doesn't seem like a good fit on those grounds. It might be popular at some other site, though. WhatamIdoing (talk) 19:05, 14 March 2016 (UTC)

Such as Wikia, and where is the requirement? Other than that, I am sorry that I had given a lousy idea like that and therefore shown my medium amount of ignorance. Gamingforfun³⁶⁵ (talk) 05:05, 27 March 2016 (UTC)

The proposal would belong at meta:Proposals for new projects. See mw:Category:Poll extensions for existing MediaWiki extensions but it doesn't sound like a project for the Wikimedia Foundation. PrimeHunter (talk) 20:53, 14 March 2016 (UTC)

Are all wiki sites required to be educational in the conventional way that the encyclopaedia is? Presumably not or there wouldn't be ideas for alternatives and have just seen a mention of a wiki poll idea. This may simply be a relatively conventional market research of some sort that people could choose to be involved with instead of the invasive ones that often appear on computer screens as advertisement in some excuse that the owner didn't pay for the software. I am hoping for something I can use as I choose to help evolve and never pay for software as it was invented very many years ago and we are all part of the process. — Preceding unsigned comment added by Markostri (talk • contribs) 20:49, 19 March 2016 (UTC)

All WMF-sponsored wikis are required to be "educational" due to the foundation:Mission statement. The m:sister project committee only accepts projects that are compatible with the movement's general principles (freely licenced, spreading free knowledge, BLP rules), vision and mission statement. They don't have to be "educational in the conventional way", but they do have to be "educational". m:Proposals for new projects lists several wikifarms that are happy to host non-educational projects. WhatamIdoing (talk) 02:46, 8 April 2016 (UTC)

(EDIT: On the other hand, the only "education" which I would receive from the site would be people's opinions upon subjects about...anything. I also was thinking about providing a little information about subjects to make recognition of the subjects better and a little "educational", but, other than that,) I apologize for bringing up this topic. I wish that I had known about the statement. I feel somewhat embarrassed. Gamingforfun³⁶⁵ (talk) 17:02, 20 April 2016 (UTC)

Response, please. Gamingforfun³⁶⁵ (talk) 21:15, 20 April 2016 (UTC)

Definition of a stub and automatic removal of stub templates

At the moment there isn't really a set definition of a stub. WP:STUB has a very vague description of one, and also states that different editors follow different standards. I think we should create a a definitive number of characters that make an article no longer a stub. Probably somewhere between 500-1500 characters. Once this is decided, a bot could be used to remove stub templates when they no longer fit the requirements to be a stub, so that stub tags could be consistent and accurate among articles. Thoughts? — Omni Flames (talk contribs) 02:54, 27 March 2016 (UTC)

500-1,500 characters (a.k.a. bytes) make about four or five paragraphs and also about five or six references. A better number might be 3,000 or over. Gamingforfun³⁶⁵ (talk) 05:21, 27 March 2016 (UTC)

@Gff365: Ah, you're right. Perhaps 2000-2500 bytes would be a more appropriate measure? — Omni Flames (talk contribs) 07:36, 27 March 2016 (UTC)

I am looking at articles such as PlayStation World, and it is currently 3,531 bytes long, yet it in my opinion still constitutes a stub article. I would like to change my mind into saying that around 5,000 bytes might work better. Gamingforfun³⁶⁵ (talk) 19:11, 27 March 2016 (UTC)

That is not a stub, it has multiple paragraphs, an image, references. Graeme Bartlett (talk) 22:15, 27 March 2016 (UTC)

The reason that page has that many characters is proabably because of all the templates. But I agree with Graeme Bartlett: that's not a stub. — Omni Flames (talk contribs) 22:55, 27 March 2016 (UTC)

Exactly! That would make the robot want to change the quality level from "Stub" to "Start", and that is my point! Gamingforfun³⁶⁵ (talk) 21:29, 20 April 2016 (UTC)

I think a very short article with multiple sources can be a start-class article (or even C), while a somewhat longer article filled solely with unsourced plot info can be a stub, especially if it doesn't make use of sections. I don't think it's a good idea to base the idea of "stub" entirely around character-count, as I'd much rather see people trying to write good prose than useless trivia in order to get to start-class. I don't think a hard limit is a good idea. ~Mable (chat) 17:17, 28 March 2016 (UTC)

• Comment I've posted a note about this discussion at Wikipedia_talk:WikiProject_Stub_sorting#Discussion_at_Idea_Lab, where the stub experts can be found. PamD 20:48, 28 March 2016 (UTC)
• WP:STUB#How big is too big? says "there is no set size at which an article stops being a stub" and includes a link to the Croughton-London rule, which is a useful way of putting a perspective on it. --Redrose64 (talk) 13:26, 29 March 2016 (UTC)
• Agree with the above. Stubness is not about characters. It is about meaningfull content in proportion to what there is to know about a topic. Short articles about obscure yet important historical persons may give all available information, while adding the contents of the phone book to a further empty article on a major city would not elevate such an article above stub level. (NB I realise this is not the best example as phone books are listed among what Wikipedia is not, but I hope the idea gets across) Arnoutf (talk) 14:13, 29 March 2016 (UTC)
• The term 'stub' has become a justification to junk up the bottom of many articles with those ugly stub templates. Any criteria that expands the range of articles to receive those templates is not an improvement to Wikipedia. Likewise, an article shouldn't need more than one stub template; the categorization can go within the template itself. Praemonitus (talk) 20:16, 30 March 2016 (UTC)
  • Yes, it would be nice to be able to combine all of those stub templates into a single template, just as all of those Wikiproject templates can be combined into one. Probably doable, too: just copy the code from the WikiProjectBannerShell template into a StubBannerShell template, maybe tweak the parent stub template a little, & that part's done. Only step left to do would be to find all of those stub articles with more than one stub template & add it to them. Not more than a few million to check & edit, simple to do. -- llywrch (talk) 18:59, 13 April 2016 (UTC)
• WP:AWB has a byte-length definition of not-a-stub, and I believe that's the only (semi-)automatic method for removing stub tags at the moment. The number chosen is rather generous, to err on the side of caution. WhatamIdoing (talk) 02:58, 8 April 2016 (UTC)
• Wikipedia:WikiProject Stubsensor exists, although very inactive. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[1] 16:33, 19 April 2016 (UTC)

Workshopping: Proposed "Page mover" permission

Hey, I'd like some help workshopping a proposed new permission called "Page mover". Please see Wikipedia:Page mover and leave your comments at Wikipedia talk:Page mover (or just go ahead and edit your suggestions in). –xeno^talk 23:35, 15 April 2016 (UTC)

• Thanks for the help, I've moved to the RFC stage: Wikipedia talk:Page mover#RFC - Proposed: "Page mover" permission to be created. –xeno^talk 00:26, 19 April 2016 (UTC)

Wikipedia:WikiGhost

This is an idea to seek out and find a new WikiFauna Creature to identify users. I presently have no idea how a WikiGhost would behave, but it might be a good addition. Wyatt Hughes (talk) 23:12, 22 April 2016 (UTC)

You should probably start by finding a list of behaviors, and then give it a name. I think this strategy makes more sense than starting with a name. עוד מישהו Od Mishehu 07:51, 24 April 2016 (UTC)

There are probably too many such faunas (see e.g. Wikipedia_talk:WikiFauna#Inclusion_criteria_for_WikiFauna) and if you "have no idea" about this proposed one I suggest exorcising this idea. Fences&Windows 21:41, 25 April 2016 (UTC)

IEG proposal: A graphical and interactive etymology dictionary based on Wiktionary

I have written a grant proposal to develop an interactive visualization tool for etymological relationships (click here to see the proposal). If you are interested in etymology and you think you would be interested in an interactive graphical etymology dictionary please endorse my grant proposal (last section of the grant page). I need your feedback/comments there or on the talk page. To see a working demo of the visual etymology dictionary click here (the demo works best on a desktop).

The etymological tree of the English word 'butter' as visualized by etytree

The aim of the application is to visualize - in one graph - the etymology of all words deriving from the same ancestor. Users can expand/collapse the tree to visualize what they are interested in. The textual part attached to the graph can be easily translated in any language and the app would become a multilingual resource. My idea is to use Dbnary's extraction-framework and develop a (possibly) smart pre-processing strategy to translate Wiktionary textual etymologies into a graph database of etymological relationships.

I would very much appreciate any kind of feedback from you on the grant page. — Preceding unsigned comment added by Epantaleo (talk • contribs) 00:45, 27 April 2016 (UTC)

Wrap infoboxes in complementary divs for accessibility

I'd like to propose the following general change to all infoboxes, i.e., directly to Module:Infobox. With the infobox wrapped in a div with an accessibility role and label, screen readers can navigate to and from the infobox as a region or landmark. Screen readers will announce the infobox with a meaningful label, such as "infobox complementary information", rather than a cryptic announcement like "table with N rows and 3 columns".

For example, something along the lines of:

From

<table class="infobox"> ... </table>

To

<div role="complementary" aria-label="infobox"> <table class="infobox"> ... </table> </div> — most conservative change, visual output preserved, or

<div class="infobox" role="complementary" aria-label="infobox"> <table> ... </table> </div> — better semantics, encourages moving non-tabular data out of the table, but needs margins, padding, etc. fixed in CSS

The first version would be fairly easy and safe to implement. The second version wouldn't be too hard, but would require a whole lot of testing to make sure infoboxes don't get broken. Do either of these ideas look good? Matt Fitzpatrick (talk) 00:51, 27 April 2016 (UTC)

My biggest concern (that needs testing) would be if this will in any way at all interfere with mobile views. — xaosflux ^Talk 02:11, 27 April 2016 (UTC)

The first option, just wrapping with a div, appears to work in CologneBlue, Modern, Monobook, Vector, and Minerva. I doubt there's any surprises. The second option, wrapping with a div and refactoring CSS so the div is .infobox instead of the table, would need additional work in the mobile CSS. The mobile CSS uses a heavily qualified table.infobox selector, which would have to change to .infobox, in addition to the margin and padding changes for the desktop CSS. Matt Fitzpatrick (talk) 03:03, 27 April 2016 (UTC)

Automated list of authors

Tracked in Phabricator
Task T120738

The article history is a pretty clunky way to do attribution, because there is a lot more noise (edits that don't add text or text additions that were removed later) than signal. It would be better if there was an automated list of authors in a collapsed box at the bottom of the article. The list would be ordered by the number of bytes of text added to the current version of article. It would be easy for mirrors of Wikipedia to take care of attribution as all they have to do is mirror the list, which would say something about GFDL and Wikipedia. Of course you would still need the history to determine which author added which piece of text. — Preceding unsigned comment added by 109.79.99.105 (talk) 09:55, 19 April 2016 (UTC)

There are quite a few external tools that provide such information; registered users have access to a Gadget that displays some of them in a handy menu (Page > Analysis): see User:MusikAnimal/MoreMenu. I don’t see much advantage in including a list on the article page: even if collapsed by default it would often add a great deal to the page‘s size & loading time, and I imagine the associated database queries would be something of a burden on the servers if they had to keep the list continuously current rather than generating it only on demand. I’m also dubious about the significance of bytes-added as a metric of authorship: if I restore a large section blanked by a vandal, or spam the article with an autobiography that gets promptly reverted, does my ‘addition’ of so many kilobytes make me a major contributor?—Odysseus1479 23:43, 19 April 2016 (UTC)

Staleness or predictable outcomes of "Wikipedia:Move review"

I don't know where to discuss Wikipedia:Move review. The process, created four years ago, have become more predictable. Id est most reviews have been closed as "endorsed". Its talk page is nearly abandoned. If proposing a discontinuation of the process is out of option, what else can I do to improve the process? --George Ho (talk) 22:28, 7 May 2016 (UTC)

WP:NOTUSA

I'm a bit uncomfortable reading WP:NOTUSA and feel that English-speakers who are not from the USA have a legitimate case to make that the use of US has several problems, not least that there are several other countries which use the words "United States" in their title, that US could be misread to mean "us" and that there seems to be an inbuilt assumption that those of us outside of the USA always know how this abbreviation is being used. I'm not suggesting that all pages should be changed (given that from the context it is fairly obvious in many what is being discussed) but given there are bots which go around changing USA to US, it seems to me that WP:NOTUSA is too prescriptive. For example if one was making a list of countries where something applied, wouldn't it be correct to say "During his career, Henry had academic positions in France, Germany and several universities in the USA"? I'm not quite sure what change I'm suggesting, hence the post here.. JMWt (talk) 15:58, 25 April 2016 (UTC)

Using upper case letters for abbreviations is a common convention in English. Praemonitus (talk) 16:36, 25 April 2016 (UTC)

You've misunderstood. This is not about upper or lower cases. JMWt (talk) 20:51, 25 April 2016 (UTC)

I agree with JMWt. I'd also find it odd to be foreced to use "US", and to be told "Do not use U.S.A. or USA". Is it possible that this style guide was written by someone residing in the U.S. but that for people elsewhere in the world, it makes less sense? EvMsmile (talk) 01:03, 26 April 2016 (UTC)

Agree with JMWt. Somewhere (I can't find it now) there is or was a recent discussion that suggested putting footnotes in Wikipedia policies and guidelines to refer back to the consensus or reasoning that produced each policy or guideline. WP:NOTUSA is a typical candidate. It says simply "Do not use U.S.A. or USA" (with some exceptions). Why not? Can someone (a) explain here, and (b) add an explanatory footnote to WP:NOTUSA? For a Brit like me, the usage "USA" is normal – why is it apparently anathema to Americans? — Stanning (talk) 16:02, 26 April 2016 (UTC)

You can search the manual's talk page here. Brianga (talk) 16:44, 26 April 2016 (UTC)

@Brianga: No you can't, it's a redlink. @Stanning: Maybe because in a historical context, it might mean Union of South Africa? --Redrose64 (talk) 20:36, 26 April 2016 (UTC)

@Redrose64:Did you try clicking? It's indeed red, but the link seems to work. Brianga (talk) 20:45, 26 April 2016 (UTC)

@Redrose64: I've never heard or seen USA used to mean Union of South Africa. It seems nobody else on Wikipedia has that confusion, since USA isn't a disambiguation page but a redirect to United States. — Stanning (talk) 11:57, 27 April 2016 (UTC)

@Redrose64: In current and historical contexts, United States can also refer to numerous states, so I don't see that as a valid reason for avoiding USA. I've also found the insistence on using US contrary to WP:ENGVAR. Valenciano (talk) 11:01, 5 May 2016 (UTC)

At the very least Not:USA needs amending per ENGVAR to use USA in articles not written in American English. If USA really is deprecated in American English then I guess we have to live with the anomaly, but the articles where it is most likely to be an issue are I suspect the ones not in American English. ϢereSpielChequers 08:36, 27 April 2016 (UTC)

Agree. I propose this text: "Do not use U.S.A. or USA in articles tagged with {{Use American English}}, except ..." — Stanning (talk) 12:02, 27 April 2016 (UTC)

I'm not sure that's good enough. Some WikiProjects have agreed to use American English as standard on their pages, but I still don't see that this is a reason to change USA to US. OK, yes, I accept that there are some pages where it might be appropriate, such as Supreme Court of the United States and other specific pages relevant to readers in a particular geography. But if we're talking about non-geographic pages, pages about concepts or people or ideas which are not uniquely from that country, I can't see that there is any justification for changing USA to US. JMWt (talk) 12:53, 27 April 2016 (UTC)

@JMWt: I agree with you, but let's go for what's practical. It seems that there are Americans for whom it's desperately important that their country must be referred to as "the US" rather than "the USA", so much that they've inserted WP:NOTUSA into the MOS and have bots patrolling Wikipedia to enforce it. We're not going to change their minds, so let's leave pages in their dialect with the nomenclature that they insist on. If WikiProjects have agreed to use American English as standard, we'll have to live with that. — Stanning (talk) 17:56, 27 April 2016 (UTC)

WikiProjects have no business deciding what form of English to use on "their" pages, because WikiProjects don't WP:OWN any articles. Any group of editors, or any individual editor, can recommend something, but a WP:WikiProject advice page is as non-binding as a userpage essay. WhatamIdoing (talk) 18:50, 3 May 2016 (UTC)

"During his career, Henry had academic positions in France, Germany and several universities in the United States". Don't use any abbreviation. Problem solved! It even says so here: "When the United States is mentioned with one or more other countries in the same sentence, U.S. or US may be too informal, especially at the first mention or as a noun instead of an adjective (France and the United States, not France and the U.S.). "- Aalox (Say Hello • My Work) 17:40, 2 May 2016 (UTC)

Historically, MOS:NOTUSA said that "USA" is ambiguous because it could refer to other groups in the United States, such as the US Army. After discussion, that got taken out. There's also this older discussion. Apparently, "USA" is supposed to sound jingoistic and old-fashioned according to some editors. NinjaRobotPirate (talk) 00:11, 9 May 2016 (UTC)

Point of order: This discussion is fine if the goal is to develop a proposal to take to WT:MOS. But MOS:NOTUSA should not be modified without a consensus on that page, regardless of what happens here. If everyone present already understands that, please accept my apologies. ―Mandruss ☎ 06:39, 9 May 2016 (UTC)

Proposal for Linking of Wikipedia to wiktionary for easy understanding

NimXaif6290 17:37, 15 April 2016 (UTC) M/S wikipedia! It is suggested that you may link wictionary with wikipedia in such a way that pointing towards a general word shows its meaning from wiktionary. This can be applied to the words that are not links. This will make it easy for the readers to learn and to understand wikipedia. I often feel it very difficult to study on wikipedia because I have to search for the meanings as well... Thanks NimXaif6290 17:37, 15 April 2016 (UTC) — Preceding unsigned comment added by Nimrainayat6290 (talk • contribs)

Hi User:Nimrainayat6290. Some articles do have links to Wiktionary, e.g. Oi (interjection) has {{wiktionary|oi}} at the top, which links to wikt:oi. In the search box at Wikipedia, you can type in wikt:keyword to search for any word (in that case, it takes you to https://en.wiktionary.org/wiki/keyword). For general use, you can search Wiktionary in several ways, see wikt:Help:Searching. Handy tools are search plugins, which are available for Firefox and Chrome. Fences&Windows 21:51, 25 April 2016 (UTC)

The Simple (English) Wikipedia exists to meet the needs of those who might struggle with the English Wikipedia's level of English. There may also be some extensions for your browser that do what you want regarding linking words to dictionaries. It is not the English Wikipedia's goal to help readers learn English so this proposal would get shot down hard. On the other hand, articles should be accessible so if you feel the current reading level of an article is more demanding than it ought to be, try to improve it. Cheers, Jason Quinn (talk) 12:53, 9 May 2016 (UTC)

Conversion to past tense

Articles in Wikipedia are supposed to be timeless: WP:RECENT. However, this suggestion is not about the content of an article, or the long-term notabilty on the article, or the historical perspective. Rather, it is about the verb tenses and other temporal wording used in an article.

We have many articles about events that occurred after the start of Wikipedia in 2001. Often, the initial article was written as the event was unfolding or shortly thereafter, with sections written in the present tense. We also get sentences or sections added about projections into the future, written in future tense. We also get additions about new research added to older articles that are written in present tense and sometimes with projections from the date of the edit into its future. As time goes by, these sentences become incorrect as the future becomes the present and then the past. Sentences also use relative time terms, notably the word "recent". The resulting articles end up seeming unencyclopedic.

When I find such sentences, I try to fix them, but I think we need something a bit more focused than a single editor operating sporadically and independently. As time goes by, the percentage of such articles will increase, because the amount of prior research and potential articles about the past is fixed, while the number of articles about new events is not.

Questions:

• Is this being addressed in any existing project?
• Should we add this as a goal to an existing project or create a new project?

Proposal: We should establish a project to review each article for verb tense, on a schedule: one month, one year, and five years after it is created. We should also automatically scan for "relative time" words (i.e., recent, now) and verb constructs. These two scans can be automated and might find the bulk of the offending edits for manual correction by interested editors.

An additional automated scan might identify new edits to older articles, but would require manual review. When a new edit adds a recent reference to an "old" article, it often uses the present tense. It may be possible to simply create a list of such edits for manual review. It may be possible to automatically check these edits for present and future tense.

-Arch dude (talk) 03:46, 29 April 2016 (UTC)

{{As of}}, {{update after}}, etc. are relevant here. A way to automatically apply one or more of those templates would presumably be valuable. {{Nihiltres |talk |edits}} 04:34, 29 April 2016 (UTC)

A question I've wondered is: How soon should we start writing in past tense? When, if ever, is it acceptable to write in past tense if the subject is still ongoing? As in, if something is current, but we know that for readers in a couple of months it will be in the past, should we write in the past tense or present? I'm sometimes inclined to write everything in the past tense, simply because eventually it will have happened in the past, but that might be a bit too (the opposite of?) WP:CRYSTALBALL (in this case, the past hasn't happened yet, if that makes sense.)  DiscantX 10:58, 29 April 2016 (UTC)

If you know something is going to change from "present" to "past" at some particular date, you could use {{show by date}} to have it automatically change. Anomie⚔ 19:51, 29 April 2016 (UTC)

Hello, the Manual of Style has this policy, which is pretty thorough. --NaBUru38 (talk) 23:32, 1 May 2016 (UTC)

I know the policy. My problem is that is is ignored in many, many articles. I am asking if we have (or should have) a systematic project to repair these articles. I agree that Purely automated repair is not likely to work well, so I was hoping we could use an automated detector and subsequent manual correction. The existing templates work only when a editor used them. Most problematic articles do not use the templates. -Arch dude (talk) 15:39, 2 May 2016 (UTC)

In my submission, automated tense change should be used only when the event concerned is certain to occur, which is pretty much confined to astronomical events. Does it make sense to use {{show by date}} to change "Mr Smith will take office on 1 January 2017" automatically to "Mr Smith took office on 1 January 2017"? No, that's not certain to happen – between now and 1 January Mr Smith may die, or be taken ill, or be otherwise prevented from taking office. But you can validly use {{show by date}} to change "there will be a transit of Mercury on 9 May 2016" to "there was a transit of Mercury on 9 May 2016". — Stanning (talk) 08:15, 2 May 2016 (UTC)

On the other hand, Mr Smith dying, taking ill enough to prevent taking office, etc is probably noteworthy enough that the article will have to be edited anyway. Or looking at it the other way, it's not impossible that aliens could swoop out of hyperspace and blow up the planet Mercury, preventing the transit. ;) Anomie⚔ 21:03, 3 May 2016 (UTC)

While it's not impossible that there are aliens out there who will destroy Murcury, it's so unlikely to happen that you can say, with near certainty, that it won't. On the other hand, that a person doesn't take office on the date he's expected to does, is not so unlikely - to take a recent example, Roni Alsheikh took office 2 weeks late due to breaking his leg. עוד מישהו Od Mishehu 05:17, 10 May 2016 (UTC)

Proposal for the creation of a comparison tool

I have proposal I'd like to float for the idea lab: the creation of a compassion tool for the expressed purpose of allowing editors (more than likely admins) to look at the content of a deleted article and an article on the subject currently under development in a sandbox, draft space, or other area on Wikipedia. I know that we have the basic tech to do that since the copyright bot uses such a tool to look at what we have on site and what is written elsewhere, and I for one and tired of trying to read through deleted versions of an article and someone else's new version to decided if they are different enough to recommend moving forward or close enough to each other to warrant a return to the drawing board. Would that be a good idea? TomStar81 (Talk) 08:44, 5 May 2016 (UTC)

• Wikipedia:Viewing deleted content to me implies such a tool could be problematic if it can be used by everybody - some content that was deleted is not meant to be publicly visible. That will need fine tuning I think.Jo-Jo Eumerus (talk, contributions) 08:47, 5 May 2016 (UTC)
  • Well that's why its called an idea: right now this is very much in its infancy, so all I am interested in at the moment is if there is enough of an interest in this to warrant moving forward with it. Deleted content necessitates an ADMIN clearance to work with as is, so I think such a tool would be self selective, but the ability to compare pages on site would be a great benefit regardless of whether the material still exists or has already been deleted, don't you think? TomStar81 (Talk) 08:59, 5 May 2016 (UTC)
    • I think it would be useful. I know that one Commons upload tool does make a comparison and I've in the past tagged several pages for G4 deletion because copyvio tools indicated similarities with archived versions of previously deleted pages.Jo-Jo Eumerus (talk, contributions) 09:13, 5 May 2016 (UTC)
      • When I make such checks for G4 deletion, I always copy the deleted source, open the edit page for the existing page, paste the deleted source there, and use the "Show changes" button. This even comes with a slight advantage - I keep the existing headers, and can make small adjustments to the deleted version and check again. עוד מישהו Od Mishehu 04:12, 6 May 2016 (UTC)
        • But the fact that you have to copy the material and paste it to check it proves that the absence of such a tool is effecting our ability to work. A dedicated tool to check the material would therefore be appreciated, right? TomStar81 (Talk) 04:55, 6 May 2016 (UTC)
          • It would be less flexable. If the author adds an infobox, and then makes subtle changes to each paragraph, then any diff tool would make the articles look totaly different. I would simply not erase the infobox in my test, making them look a lot more similar. (Yes, I did actually see this once). עוד מישהו Od Mishehu 14:31, 6 May 2016 (UTC)
            • "Any" is a strong word. I frequently paste different revisions into ediff when Wikipedia's internal diff tool gets hopelessly muddled, and just about always get good results. —Cryptic 01:41, 8 May 2016 (UTC)
              • The way CorhenSearchBot checks shows the highlighted parts that are though to have been copy/pasted, but it shows the entirety from the versions. Wouldn't that obviate the issue of adding simple things like a template or other language coding? TomStar81 (Talk) 04:47, 9 May 2016 (UTC)
• I'd be ecstatic if Special:Undelete would even let us compare arbitrary revisions within a single deleted page, like viewing the history of a normal page does. The current interface only supports diffs between adjacent versions, and so far as I'm aware there's no way to force it into doing otherwise by writing the URL manually. From there, it'd just be a SMOP to allow a diff from a particular deleted revision to a non-deleted version of some other page. (I can't imagine the interface ever being anything but horrid, though.) —Cryptic 01:41, 8 May 2016 (UTC)
  • Exactly. And think how easy that would make things for us. TomStar81 (Talk) 04:47, 9 May 2016 (UTC)

Too many cooks

Quite unconsciously I'm sure, experienced editors tend to oppose change, and here's my take on why they do. First, they were around when things were worse; by comparison, the status quo looks pretty good, and why mess with a (relatively) good thing. Things could get worse again. Second, they have invested a lot in learning how to work within the current very complex system, they are adapted to the way things are, and (scientifically proven fact) change of any kind is stressful on or off Wikipedia. They've paid their dues, and they quite reasonably feel they've earned some stability.

There is a full grab-bag of reasonable-sounding arguments to oppose pretty much anything one wants to oppose; the greater one's mastery of that arguments toolkit, the more effective they are in Wikipedia debates. This, combined with the requirement for clear consensus for any disputed change, is why very little progress ever occurs at Wikipedia, and status quo reigns. It just doesn't take that much to kill a clear consensus, folks. There is simply too much that is not clearly defined in p&g, per WP:CREEP, so most of the time all that's required is 40% of the participants making Oppose arguments that sound somewhat reasonable.

I often wonder how Wikipedia got as far as it has; we have a ton of pretty good infrastructure and policy. It couldn't have been by exhaustive (and exhausting) discussion of every minute detail, by anyone who cared to participate, as we do now. There must have been a lot more bold action going on, with a lot less resistance to it, by people who had enough competence to do things reasonably well (this last part is key). There are too many cooks in the kitchen—anyone on the planet with Internet access and some English language skills can be a cook—and the broth is suffering. There remains ample room for improvement on en-wiki, but institutional inertia is stifling progress.

The solution? I don't know, but I do know that some change is sorely needed. Perhaps multiple sub-kitchens, each with an area of responsibility, with project-wide authority within that area. The community would agree to abide by their decisions; the community could lobby them for change, but their decisions would be binding. Committees, if you will, with membership of no more than perhaps 15 active editors. A candidate member would have to demonstrate competence in that area—a simpler and, I would hope, less contentious version of RfA. A bad member could be voted off the island by a simple majority of the others (if 51% feel they need to go, they are at least problematic, and the project would be better served by someone else).

Example: A documentation committee that would have free rein to develop, implement, and maintain site-wide formatting conventions for p&g, help, and template doc pages, with no authority to change the meaning therein. Example 2: An MOS committee that would have authority over all MOS guidance. I for one would readily abide by any style-related decisions of a panel of 10 or 15 editors qualified (with at least some credentials) in the area of style. Epic battles like comma-before-Jr? Gone forever. Thank you Lord.

Bureaucracy? Yes. Necessary bureaucracy? I think so. Power in the hands of too few? Given the alternative, not in my opinion.

Obviously there would be details to be worked out. I don't presume to have all the answers, but there should be workable solutions to any concerns. No doubt some areas would need to remain outside of committees. I'm basically just testing the water and seeking some constructive discussion, which are two of the purposes of this page. ―Mandruss ☎ 11:22, 8 May 2016 (UTC)

A committee approach tends to enforce the status quo, not break with it. The current approach seems adequate for now. Praemonitus (talk) 19:24, 9 May 2016 (UTC)

The idea is that the committee approach (1) vastly reduces the number of editors (potentially) involved in decisions within its purview, and (2) substantially increases the competence of the editors involved in those decisions. Where status quo bears improvement, a committee has a far better chance of improving it. Where it is good, whether already or by their action, maintaining it is a good thing.
I honestly don't know how you can say things are remotely adequate now, given the degree of inertia and the extreme inefficiency of the current system. Just take comma-before-Jr as an example. How many editor-hours have been spent on that battle over the past few years, and it still isn't over? That is time that was stolen from far more important things than a little comma before Jr., such as, say, learning Wikipedia policies or maintaining neutrality in BLPs about political candidates. How much negativity and ill will has been introduced to the environment by all that acrimonious debate? Can anyone reasonably claim that the same end, or an equally good end, could not have been achieved by 10 or 15 editors qualified in style matters? I don't see how.
Our doc will never be standardized without such a committee approach; any WP:BOLD attempt to do that would be seen as disruptive, and then we would be forced to debate each and every little detail to the nth degree, by any schmuck who shows up, regardless of their qualifications to participate in such decisions. Sorry but we are not all experts at everything, and expertise is what the project needs. We might finish that work some time around 2050, with any luck. And anyone who claims that this isn't that important demonstrates a complete lack of knowledge about that area. We have known since, say, the 1960s that this consistency is essential to effective documentation. It's intuitive that the lack of it has contributed to turning off many potentially good editors. These same principles are not unique to our documentation; they apply all over the project. ―Mandruss ☎ 09:33, 10 May 2016 (UTC)

I would love to comment on your proposals, but I just don't have time. I'm a committee man: and have missed my children growing up because I was always out at a committee meeting. I am creating fewer articles because I am spending too much time commenting here and elsewhere. Committees are self selecting, and efficient and time consuming and divorce the 'hero' from the reality of creating the 'encyclopedia', and ultimately lead to isolation. It is far harder to publish a raw idea- as there is a pressure to dot the i s and cross the t s (is that MOS compliant? what the hell, but life threatening to the committee hero.). The committee hero becomes the target- and faces only one future- deselection and oblivion. And is the work ultimately better- the committee man in me says yes, but I am now talking to an empty room. --ClemRutter (talk) 09:40, 10 May 2016 (UTC)

Eliminating discussion over style issues is not going to increase productivity one iota. Those who participate in said debates are individuals who enjoy that type of discourse, and if that is taken away then they will find something else to discuss. If your goal is to employ a set of experts to build a style guide, then hire experts. Don't try to claim that a self-selected committee of volunteers is necessarily going to do a better job. All that will do is create more rancor. Praemonitus (talk) 18:50, 10 May 2016 (UTC)

If your goal is to employ a set of experts to build a style guide, then hire experts. - That would work too, if the community would accept it and WMF would pay for it. Same goes for the doc. ―Mandruss ☎ 04:01, 11 May 2016 (UTC)

If you did this (and I'm talking about your main proposal too), Wikipedia would just become a normal encyclopedia, except that it would be written by unpaid volunteers. The essence of Wikipedia, which must be the reason it has succeeded over all other more professional encyclopedias, is that it results from free collaboration between interested editors where everyone is equal before content. If you impose governing committees that must be obeyed, Wikipedia would become identical in structure an unpaid job rather than a free collaboration. Volunteers would chafe at this and most would leave. A2soup (talk) 05:26, 11 May 2016 (UTC)

To add to this, if there were a committee overseeing the edits or opinions I wanted to make (or that disallowed my edits from the gate completely), I would never have been attracted to the project in the first place. The only thing that has made this project so expansive is that anyone can expand it. With over 5 million articles, I doubt that a group of small committees could have achieved this, and if it was a small group of committees overseeing and making decisions around the edits of the millions of people that contributed to those articles, I doubt those people would have contributed in the first place. The reason people come here is that be they someone who has a couple of lines to add to an article, or be they someone with an entire article to add, or be they in between, everyone who comes here with a justifiable edit can make that edit. Limiting parts of Wikipedia to an exclusive group of editors is against everything Wikipedia was created around, and honestly it's surprising an experienced editor such as yourself would think such an idea would pass, even at idea lab.  DiscantX 09:20, 11 May 2016 (UTC)

For starters, I'm not THAT experienced. And I'm an incurable idealist. "Some men see things as they are and say why. I dream things that never were and say why not." As I tried to express, perhaps not very well, I don't know that this is the answer, only that some answer is sorely needed. As hard as I've tried, I can't bring myself to accept that this is the best we can do, or even close to it. Not when I've actually seen so much better. But I get that there's nothing more I can contribute to this particular thread; please ping if you wish to address me. Thanks to those who have waded through my TL;DR. ―Mandruss ☎ 08:50, 12 May 2016 (UTC)

User:Mandruss, eh, 22,000 edits and two years under your belt is experience enough in my opinion. But that's neither here or there. I do get where you're coming from, but there's no easy solution. I could go on further about how this specific proposal goes against basic principles of Wikipedia, but there's no point other than to say this: The principles that have somehow (against many people's expectations) made this project somehow work, are also the cause of some of its biggest problems. But the problem is intractable. There might at times be too many cooks adding ingredients to the pot, but it's a very big pot to fill, and without all of those cooks, there won't be enough people filling it to keep up. As far as solutions to the problem go, I'd say we already do have committees in the form of WikiProjects and that people already do prove their competency in the quality of their edits, and that if their edits aren't up to par then the needed course of action is to simply change it, and if there is sufficient backlash in you changing it, then maybe it shouldn't have been changed in the first place. This isn't necessarily directed at you in particular, but all of this talk that has been ongoing for years about how Wikipedia is somehow broken and can be improved ignores the fact that it is working, it is a work in progress, and yes, it can be better, but it is getting better with every edit. Can we do better? Yes, and we already are.  DiscantX 09:58, 12 May 2016 (UTC)

I sympathize with the motivation behind this, but it's a recipe for disastrously enshrining the WP:Specialized-style fallacy behavior as official, valid policy. The problem is that people who feel they are experts at something (e.g. grammar and style, since this is first being proposed for an MoS committee) are not experts in the use of those things at Wikipedia for its audience; they're (alleged) experts on their use in totally different contexts with different needs and readers. This is essentially a variant of the Dunning–Kruger effect. People who don't know a damned thing about WP and how it really works would leap at the opportunity to dictate how it operates, to serve their off-WP interests. This is already the #1 problem with wikiprojects, especially small-but-active ones that end up operating like wholly-WP:OWNing sovereign fiefdoms in constant conflict with editors who are not part of their precious little exclusive club. If you want to see all the productive, genuinely encyclopedic editors quite the project en masse, the fastest way to ensure that would be to erect a topical experts committee system.

In reality, the dozen people most competent to edit MOS (to continue with that example, or pick another like WP:MEDRS) are the dozen editors who have most shaped it over the last 15 years. There are literally no other people one earth more competent at it, because there are no people who have that much experience observing what does and does not work in that topic (the MOS sphere, or the MEDRS sphere, or whatever) at WP, both from a reader perspective and an editorial community perspective. The last thing we could ever need is some pontificating asshat from the editorial board of The Chicago Manual of Style or New Hart's Rules (or the American Medical Association or FDA) being invited to come here and dictate how WP has to be written. To focus again on MOS in particular: Anyone familiar with style guides will notice that all of them sharply conflict with each other, and they are in competition for publishing-marketplace dominance. There is no one way to write English, even in a formal or semi-formal register.

A related issue is that credentials really don't mean much, and come with baggage. I guarantee you I know more about most style matters and their application to WP writing than average literature, English, or linguistics professors, because they spend most of their time writing lesson plans and grading papers, and trying to get new research on obscure topics published in journals, while a large amount of my own time is spend painstakingly comparing details in style guides from around the world, and keeping current with their new editions at all times, then working with other experienced editors here to figure out how to apply this information to both our articles on English and our own style guide. MoS, and our other guidelines and policies, are functional because they're written by Wikipedians who do the homework to make them functional, not because someone waving a curriculum vitae shows up and makes an argument to authority about their own opinion on the basis of their job title.

This problem will also arise if we were to erect some kind of medical advisory committee, or astronomy advisory committee, etc. They'll all be mired in baggage of professionals trying to promote their views with official WP imprimatur, instead of the current system of people who give a damn following WP content policies to create articles based on a neutral review of largely secondary literature. Specialists hate this approach, and always want to turn to bleeding-edge primary research (especially if it happens to cite them themselves). This has basically already been tried, by the split-off project Citizendium, and it basically collapsed under the weight of its own bureaucracy.

I do agree that there are too many cooks spoiling the broth in various areas, but that's just the nature of the beast. It will always be a problem with style matters, because all native speakers (and many fluent non-native ones) are utterly convinced that their preferences are norms that must be enforced and that every other way to write is "wrong". That's never going to change, to MoS (and related, e.g. AT and naming conventions, and RM) pages are always going to be fraught with unusual levels of dispute. It's not because they're broken, it's just because of human nature about language, especially in a language with no central "authority" like French has, exerting something of a normalizing force (and much less of one that they wish they had). A simpler potential solution to the cooks-and-broth problem at MoS and other policypages would be disallow their being edited by anons or even by registered users who are not autoconfirmed. Make an incremental protection-level change. (Full protection and no changes made except by {{Editprotected}} after a consensus discussion probably would not work, for the very problem you lead with: change is resisted just to resist change. And it would still permit admins to make changes without consensus, and plenty of them want to. Another actually effective mechanisms is this: If you care about the stability that MoS provided, and this continuing, watchlist all the MOS and related pages, and resist PoV-pushing attempts to alter them, especially if they're motivated by editor, wikiproject, or off-WP concerns, not by reader needs.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:37, 11 May 2016 (UTC)

References

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)

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 [6] 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)

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)

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)

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)

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)

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)

Customized templates to deal with specific and persistent problems.

• Proposal withdrawn, and thanks so much to Finnusertop for making me aware of editnotices. Mmyers1976 (talk) 16:13, 31 May 2016 (UTC)

I would like to propose a new policy/guideline of allowing the customization of templates to deal with persistent and specific editing problems on articles that are not covered by general templates. The main type of problem this would address is when multiple editors pass through an article and make the same good faith but incorrect edit to an article. An example is Berenstain Bears, where there is an ongoing problem of people thinking they are correcting the spelling of the name by changing it to 'Berenstein. As I assume good faith, I assume most of the people who are doing this are simply failing to check the talk page before making this edit, and therefore are unaware that the regular editors of this page have confirmed the correct spelling multiple times. A template at the top of the article might prevent these good faith edits, something like this is what I had in mind:

I have discussed this with one other editor on the talk page, her main objection seems to be that there is no precedence for this, but I believe that WP:BOLD and WP:IGNORE may apply, as at one time certainly all of Wikipedia's now-standard practices were innovations. But perhaps new policy or guideline allowing such customized templates but giving criteria for their use and format would prevent prevent forseeable problems. Can anyone think of possible problems with this and possible guidelines to prevent those problems? Mmyers1976 (talk) 15:49, 31 May 2016 (UTC)

What's wrong with editnotices? E.g. editing the article Muhammad displays this editnotice. In contrast to maintenance templates, they are not displayed to all readers but just to people who click to edit. They also reach editors who fail to check the Talk page. – Finnusertop (talk ⋅ contribs) 16:00, 31 May 2016 (UTC)

I don't see the issue with putting that on the talk page. Many article talk pages have a message to the reader customized for that specific page. Sir Joseph ^(talk) 15:55, 31 May 2016 (UTC)

Talk page notices, and editnotices are the way for this, and maybe html comments in the text for some extreme situations. Article content should be primarily for the benefits of the readers, and this doesn't really provide them a benefit. — xaosflux ^Talk 16:09, 31 May 2016 (UTC)

Wow, I had no idea that editnotices are even a thing. These seem to address the problem perfectly, thanks so much! Mmyers1976 (talk) 16:10, 31 May 2016 (UTC)

@Mmyers1976: Please note, that to get one made you should have to place a request. One of the template editors will be able to action it for you. — xaosflux ^Talk 16:20, 31 May 2016 (UTC)

Interactive Globe

It is generally accepted that different map projections create wildlify different impressions from the same data Gall-Peters Projection, Mercator Projection, Dymaxion Map.

The suggestion is to create a simple interface to which a user can upload a map created in a one of a range of projections, dragging their map to fit over a 'template' of that projection. This would then automatically re-project the map onto a simple globe that could be manipulated in an online viewer using the mouse.

Clearly this would involve some effort, but the storage space for processed maps need not be significantly larger than the original files, and the viewer could be quite light.

The final implementation would users to process maps already uploaded to Wikipedia and place a clickable 'view as globe' icon next to any, map on a wikipedia page that had been processed.

Stub Mandrel (talk) 06:55, 1 June 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)

• We have parallel threads going here, at Wikipedia:Village pump (proposals)#Unblock Requests Transparency and at Wikipedia:Village pump (technical)#Trying again on tech question. This goes against WP:MULTI. --Redrose64 (talk) 18:28, 2 June 2016 (UTC)

Create a "history merger" user group

Around 2 weeks ago, there was a proposal at Wikipedia talk:Page mover to include the mergehistory right in the user group. However, this proposal was generally shot down by the community, mainly because the two rights are very different to each other. That's why I'm putting forward the idea of creating a new user group, specifically for history merges. There are very large backlogs at both Wikipedia:WikiProject History Merge and Category:Possible cut-and-paste moves, some of which go years back. Few admins are active in those areas, so I feel that the creation of this permission would help to clear the backlog. This user right would be especially helpful for those who constantly find themselves tagging articles with {{histmerge}}, but unable to perform the merge themselves. Omni Flames ^{let's talk about it} 07:07, 31 May 2016 (UTC)

• Can this be done without giving non-admins deletion and page restoration rights? I don't think this is technically feasible. I think a better proposal would be to sort those by date. Wikipedia:Requests for history merge works pretty fast and doesn't seem to have a backlog so we may just need to start listing the oldest ones there or something. -- Ricky81682 (talk) 08:25, 31 May 2016 (UTC)
  • Actually it seems more like they just need to be checked. That doesn't require an admin. The bot may been over-enthusiastic about tagging. -- Ricky81682 (talk) 08:31, 31 May 2016 (UTC)
• I generally support unbundling, but I think this one will be hard. To make this into a proper right you must also have delete/restore permissions. For legal reasons the WMF requires that the community does an RfA-like review process before handing out those permissions. History merges are also one of the very few actions that cannot be reverted (without great effort), so the the bar for handing out this permission is going to be higher than template editor/page mover. I think few people would pass these hurdles, but wouldn't pass an RfA? —Ruud 09:41, 31 May 2016 (UTC)
• Would tend to agree that history merges can be pretty darned tricky! The admins who handle them on a regular basis are some of the ones I admire most.  OUR Wikipedia (not "mine")! Paine  11:21, 31 May 2016 (UTC)
• These certainly can get messy - it may be possible to use Special:MergeHistory - but complicated or messy mergers require delete/undelete access - and the "undo" process can be a nightmare. — xaosflux ^Talk 13:18, 31 May 2016 (UTC)
• I generally agree with most unbundling proposals, but I also think this is one that is technically infeasible. As others have mentioned, mergehistory requires (or implies?) being granted deletion and restoration rights, and due to actual legal implications the bar to be granted those permissions is quite high; WMF has stated they want users to pass "an RfA-like process" before being granted those permissions. Along with sorting as Ricky81682 suggested, it might be a good idea to train some users to clerk the requests, if we think that there are some that aren't actually history merge candidates, or are otherwise problematic. Ivanvector 🍁 (talk) 14:29, 31 May 2016 (UTC)
  • Clerking for this is an interesting idea, if it'll help with the backlog – I might even been interested looking into that, if training went along with it... --IJBall (contribs • talk) 20:05, 31 May 2016 (UTC)
• I'm a strong supporter of unbundling, but this (along with page deletion and blocking) is one of the few things I don't think should be unbundled. If we're looking for a "next" thing to unbundle, I'd recommend page protection given the frequent small backlog at WP:RFPP and the time-sensitive nature of such requests (with the bright line that protecting any page you've edited is grounds for immediate removal of the user right). ~ Rob^Talk 16:18, 31 May 2016 (UTC)
  • NeilN, who was one of the more active Admins at RfPP before he went on work-related hiatus, wasn't much in favor of spinning out a "Page protector" unbundle. I suspect there would be far more (Admin) "pushback" against a Page protector unbundle proposal than there was against Page mover (which actually went pretty smoothly...). --IJBall (contribs • talk) 20:10, 31 May 2016 (UTC)
    • @IJBall: Oh, I have no illusions that it would be easy (or even doable) right now. But things are slowly changing for the better. I've been here a year now and the environment at RfA and regarding user rights is markedly different than it was when I arrived. The biggest progress has been made in non-admins quietly taking on tasks once done almost exclusively by admins. Take TfD as a case study. Here's the backlog at the start of an RfC on allowing non-admins to close TfDs as delete. It's a tad hard to see exactly how many discussions were open since the transcluded pages have since been closed, but you can see just how far back it went. And lots of them were open, it wasn't just one per date in most cases. Now check out the backlog at WP:TFD today. It doesn't exist almost exclusively because non-admins have taken over a role that was under-served by the administrator population. ~ Rob^Talk 05:44, 1 June 2016 (UTC)
• Hmm, this one is hard. On one hand, this new right would help clear backlogs, but on the other hand, it has the potential for even worse abuse than page mover has. I don't know whether this right would be used frequently, anyway, or if it's going to be one of these relatively little-used, mostly temporary rights like account creator. Kylo, Rey, & Finn Consortium (formerly epicgenius) (talk) 02:04, 1 June 2016 (UTC)
• Let's take a clearer look at the reason given to demonstrate a need for this right: Wikipedia:WikiProject History Merge has large bot-generated lists of what a bot believes are cut-and-paste moves. Category:Possible cut-and-paste moves contains a large bot-generated list of possible cut-and-paste moves that a now inactive bot thought were cut-and-paste moves. Any user can look through those pages and apply {{histmerge}} to the positive results, which adds them to Category:Candidates for history merging (which currently has no backlog), where requests are generally handled promptly. There is no real need for this user right, or at the least, one has not been expressed here yet.—Godsy^(TALK_CONT) 03:38, 1 June 2016 (UTC)
• Agree non-admin history merging would be tricky. Folks make a good point that this is bundled with delete/restore permissions... and there's no precedence for that I think. While the backlog is huge, I'm thinking that it should be left (for now) to the admins more experienced in the field. If the WMF is involved here, perhaps it also makes sense to hold off on taking any action until it's clearer for them what the approach will be. FYI, the aforementioned RFC is still open. Someone can probably close it around now — Andy W. (talk · ctb) 18:36, 1 June 2016 (UTC)
• I've done history merges. Such a merge is a messy activity and potentially uses a lot of the admin tools. It is something that would be hard to unbundle. Since revisions can disappear due to a history merge, such a merge is about as sensitive as WP:Revdel in its overall effect. As User:Godsy points out, pages that someone tags with {{histmerge}} tend to be handled promptly and there is seldom a backlog. Unless the guy who does most of the history merges is on vacation. EdJohnston (talk) 21:19, 1 June 2016 (UTC)
• Including, if history-merging X to Y, what to do with Talk:X and Talk:Y and all their possible multifarious sub-pages. And what to do if X and Y are WP:Parallel histories with each other or with already-existing deleted edits sitting under the undeleted edits. Anthony Appleyard (talk) 21:33, 1 June 2016 (UTC)
• Oppose If a user is given the right to perform some action, then the user should also be given the right to reverse the action. In order to reverse a history merge, the user needs the delete and undelete tools and lots of patience. --Stefan2 (talk) 21:53, 1 June 2016 (UTC)

• Stefan2, you do realize that this is VPI right? This page isn't for oppose/support, but rather it's for developing and discussing ideas. Did you even read the heading? "Stalwart "Oppose" and "Support" comments generally have no place here". Omni Flames ^{let's talk about it} 22:02, 1 June 2016 (UTC)
  • Omni Flames, see WP:NOTAVOTE. The use of 'oppose' and 'support' at the beginning of a line never carries a meaning. It's always the rest of the text on the line which matters. --Stefan2 (talk) 22:20, 1 June 2016 (UTC)
    • @Stefan2:Actually, each merge log entry has an "Unmerge" link at the end; All a merger would need to do is use that link, click the merge button at the bottom, and the old history will be back where it came from. The only issue is that these merges must be undone in reverse order to when they were done if the same pages are involved. There may also be a redirect revision trhat needs to be reverted afterwards (if all the revisions have been merged away), but I doubt that mergers would run into this issuer a lot. עוד מישהו Od Mishehu 11:59, 2 June 2016 (UTC)

• It's a great idea to allow experienced non-admins to use the tools available with the mergehistory user-right. It's limited enough that incompetence can be easily un-done by an administrator (and the bit summarily revoked). I would be even more enthusiastic about giving wider access to an even-more-limited tool that only allowed merges where the edit history was completely non-overlapping (which is the typical case for cut-and-paste moves) and where the actions were written to a log that could be easily watchlisted to spot incompetence (or simple one-off goofs). This would be very low-risk and would free up administrators to do the more complex merges. As someone who has slapped {{histmerge}} on many a page that was copy-and-pasted from an WP:Articles for creation submission or a draft article, and as the person who added the |details= parameter to the histmerge template back in 2013, I would find having this userright very helpful to me and very helpful in freeing up the time of administrators who do the simple history merges today because nobody else can. davidwr/(talk)/(contribs) 03:26, 2 June 2016 (UTC)
• Here's an example of how an E-Z limited history merge user right might work: Write code or an external tool which would:

• Verify that the two pages have completely non-overlapping histories
• Verify there are no protection issues (such as the editor not being able to write to both pages, or the pages having non-identical permissions) that would warrant administrator intervention
• Merge the histories
• Create a redirect page with a new {{redirect to newer history-merged page}} template, which would include parameters linking to the oldest and newest edits of the "old page" (the page where the redirect now lives) and the oldest edit of the destination page prior to the move.
• Log all of the above details in a public log that can be patrolled
• Optionally, if the editor opted in, log all of the above to the editor's own user-sub-page log (editors considering a future RfA may want to do this)
• In addition, the tool would have a built-in undo feature: Within a short time period (say, 1 hour), the editor could "undo" his actions in an automated fashion. This would take some coding but it would not run afoul of the WMF's rule about non-admins seeing deleted edits. It would need to delete the redirect, but as the redirect was created by the editor in question and one it was deleted, only an admin could bring it back, I don't see the Foundation having any issues. The "undo" feature wouldn't be available if certain things had happened in the meantime, such as if either the original source page (now a redirect) or target had been moved or deleted or had their permissions changed or if the original sourced had been edited at all.
• For convenience, any administrator could use the "undo" feature without regard to the 1-hour (or whatever time period it turns out to be) time limit.

davidwr/(talk)/(contribs) 03:45, 2 June 2016 (UTC)

• The apparent acronym "E-Z" hereinabove should be replaced by plain explicit "easy", if that is the meaning. Here in Britain I (and likely many others in Europe) read it first as "ee to zed" and was wondering what the letters stood for; plus association with the expression "A-Z" meaning "all the alphabet, complete". Anthony Appleyard (talk) 04:49, 2 June 2016 (UTC)
• And cases where the pretext and/or the posttext have heads and/or tails of redirects (sometimes mixed with bot edits and cut-and-paste-and-revert sequences) which are WP:Parallel histories when the useful edits with text are not parallel. And check first for existing deleted edits. Anthony Appleyard (talk) 04:56, 2 June 2016 (UTC)
  • When fixing WP:NFCC#9 violations, I've come across lots of files which are used in both the article namespace and in the draft namespace, and where it may be beneficial to merge the draft to the article. Very often, the draft may have one late edit where a bot comments out some categories, but in that situation it may still be beneficial for the project to merge the pages (as long as the late bot edit isn't included in the merged content). This seems to be an example of the kind of complex mergers with parallel histories which you mention. I'm not sure that these mergers can be fixed with the special page which this user right grants access to. I suspect that the delete and undelete tools are needed here. --Stefan2 (talk) 12:23, 2 June 2016 (UTC)

• It's a nice idea, but in practice this won't be very helpful. My experience with mergehistory is doing incomplete merges that time out my browser and need to be fixed by delete --> move --> undelete in the end anyway. There are very few cases in which it actually works, and I would - as usual - prefer that RfA be fixed rather than more partial unbundling which would still require the calling in of admins to do much of the work. Ajraddatz (talk) 04:57, 2 June 2016 (UTC)

• Would need delete/undelete to be effective (the occasions when histmerges can be done completely 'clean' via mergehistory are rarities) and I can't see the community approving that. Jenks24 (talk) 15:28, 3 June 2016 (UTC)

Close resemblance of WP bureacracy to that of Kafka's The Trial?

How many Wikipedians have read this work? I am sure they will recognize something of themselves in it. — Preceding unsigned comment added by 70.199.65.2 (talk) 17:48, 2 June 2016 (UTC)

Perhaps our bureaucracy is more like that of The Castle where you never achieve what you wanted, rather than the Trial where you never figure out what is going on and are terminated. I am surprised that The Castle makes no mention of how it inspired Gödel's incompleteness theorems (not getting everywhere with maths). Wikipedia certainly has statements which can neither be proved nor disproved. But I do believe that progress is being made, and that the end of Wikipedia will not be so dark. For many individuals however, I see that they are kicked out by our procedures, and that the procedures only aggravate the person instead of rehabilitating them. Several long term potentially productive users have departed involuntarily in the last few months. Graeme Bartlett (talk) 23:44, 3 June 2016 (UTC)

Project Support 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)

Towards another April Fools' RfC

Moved to Wikipedia talk:Requests for comment/April Fools' 2

 – The RfC has begun. See Wikipedia:Requests for comment/April Fools' 2 and feel free to add your proposals there. I've moved this idea lab discussion to the RfC's talk page. Mz7 (talk) 19:46, 6 June 2016 (UTC)

Helper

I want to give the idea of new user group known as Helper, and their work is to help all other editors (mostly newusers). But wait, Why we need helpers?? Because new users dont know much about wikipedia, they do vandalism,etc. Example: Me (Mujtaba!). Just Think about it-- 🍁 Mujtaba 🌴 14:37, 2 June 2016 (UTC)

Other users also help newbies, but for helpers "Only helping Clearly"-- 🍁 Mujtaba 🌴 14:39, 2 June 2016 (UTC) — Preceding unsigned comment added by Mujtaba! (talk • contribs)

We only need user groups if the users require certain privileges that other editors do not have. What privileges would Helpers have? Anyone can provide advice. What else would Helpers do? Robert McClenon (talk) 12:40, 7 June 2016 (UTC)

Trial criteria for ITN?

I was thinking about taking this to WT:ITN, but maybe I'll discuss it here instead. What makes any story "newsworthy" and deserve a blurb? Due to the "success" of RD trial, which the trial runners call it, perhaps we'll try something on ITN as well. I fear it might bring disaster on ITN, so how do we (not just I) construct a looser trial ITN to bring in more stories? --George Ho (talk) 03:44, 9 June 2016 (UTC)

Documentary Reference Template

I was wondering if there are any guidelines on whether documentaries can be used as references. In case we can determine that a certain documentary is an acceptable source, then the next step would be creating a specific cite documentary template for them. Which would mention the exact second a certain fact is mentioned, the imdb number e.t.c.--Catlemur (talk) 20:38, 9 June 2016 (UTC)

We do, see {{cite AV media}}. Same standards for WP:RS apply. I used a documentary at William Robinson Brown for several footnotes there and it's a FA. Montanabw^(talk) 05:35, 10 June 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. — Preceding unsigned comment added by DJBay123 (talk • contribs) 20:56, 28 May 2016‎ (UTC)

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)

I second the two previous replies (while adding the unsigned template). Jason Quinn (talk) 16:24, 3 June 2016 (UTC)

I think that inserting a {{Current}} template should be enough warning for most people. The page can always be cleaned up later after the news has died down. Praemonitus (talk) 19:17, 13 June 2016 (UTC)

Overlinking - solve technically instead of with guidelines for fallible humans

r.e. Wikipedia:Manual of Style/Linking

How about using colour coding to deal with any 'overlinking' hazard; use the similarity between page topics (vector distance? something like word2vec on the graph structure of pages?) to pick out the most important links on a page, and de-emphasise anything deemed an 'overlink' (fainter shade of blue). Also deal with multiple links automatically. (only highlight one).

On another note, colour coding any links to the user's watchlist might be nice too (emphasise the pages away from a users deliberately chosen domain?). (default = de-emphasize probably, but you could make a preference to emphasise instead)

r.e. Red Links, why not just de-emphasize them by default (and keep a user preference to view them , for editors who want to fix them)

Links ,surely, make the wikipedia data resource more valuable - it's labelled text.. the more the better? They could help disambiguate for translation software? .. and accelerate reaching the future where we can make natural language queries and so on.. Fmadd (talk) 23:34, 10 June 2016 (UTC)

Choosing the right color would be difficult, especially considering Wikipedia:Manual of Style/Accessibility#Color and the fact that many navboxes have links with different background colors. עוד מישהו Od Mishehu 02:58, 13 June 2016 (UTC)

How about only showing these extra link shades in the main article text. for the main part , the 'less important link' could be a blend of regular black text & the blue link shade. I can see 'yet another color' for watchlist could be more problematic. — Preceding unsigned comment added by Fmadd (talk • contribs) 05:09, 13 June 2016

I'd be slightly concerned that the color inconsistencies could be confusing for people not used to the site. It's easier from a user interface perspective to use a simple, consistent theme. But otherwise, not the worst idea in the world. Praemonitus (talk) 19:14, 13 June 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)

Wikipedia pages aren't even allowed to have links to other wikis; it's in Wikipedia policy. — Preceding unsigned comment added by 2601:2C1:C004:4900:BD04:8B7D:BB53:4F01 (talk) 22:09, 1 June 2016 (UTC)

No, it isn't in Wikipedia policy. There is no ban on having links to other wikis. There is a guideline against having links to open wikis, unless they're large and long-lived, but there's no rule against linking to a closed wiki or to a large, stable open wiki such as Wookiepedia. WhatamIdoing (talk) 04:58, 15 June 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 mai78101 00:25, 30 May 2016 (UTC)

@Tom mai78101: addressing this problem came up #1 in the wishlist survey a few months ago, and it’s being tackled; see the Meta page for progress reports. There is also a related thread on m:Wikimedia Forum at the moment.—Odysseus1479 05:09, 30 May 2016 (UTC)

@Odysseus1479: Thanks for letting me know about this. Tom Mai (talk) 16:43, 2 June 2016 (UTC)

You may be interested in reading the advice at WP:DEADREF, if you haven't found that yet. WhatamIdoing (talk) 05:03, 15 June 2016 (UTC)

Better Documentation of Disasters

Wikipedia articles on disaster events are the number one search query when searching for any disaster. Many of the contributors to these pages are experts in the disaster research community. As a senior research scientist at the Karlsruhe Institute of Technology, Center for Disaster Risk Management and Risk Reduction Technology (CEDIM), I have reveiewed pages documenting disasters since 2010. The quality of documentation and type of information documented is variable from event to event. I have also found that for events after 2010, 70% of the edits are made within the first two weeks of an event. Some pages such as Hurricane Katrina and the Indian Ocean Tsunami are getting upwards of 100,000 views - 10 years later. Wikipedia has served as a popular source of information on disasters for the lay person and in many cases, professional and practitioners in the disaster field. The amount of traffic wikipedia gets on disaster information probably makes it one of the most - if not the most - consulted resource for documentation of disasters worldwide.

Globally there are many efforts and international bodies to study properly document disasters. One of this is our own initiative at CEDIM established in 2011 called the Near Real-time Forensic Disaster Analysis research program. We investigate disasters as they are happening and systematically document these events through our reports which are releasted within days of the events and followed up periodically.

The idea

Connect the community of experts who are already engaged through a pluarality of initiatives in studying and documenting disasters to contribute information on disaster events as they are unfolding on Wikipedia. Wikipedia is already the first search result on disaster events; it can also become a reliable source of real-time information to support various actors with their time-critical information needs!

How to make it happen

1. If the idea has any merit, it will need endorsement by the Wikipedia community of editors and suggestions for how to best implement it.
2. Endorsement by the community of editors can be the first step to link Wikipedia to the different international bodies working in this area and getting their support behind it.
3. A research project showing the value and reach of wikipedia for information on disasters similar to many studies conducted by the medical community would pave some of the way.
4. Organized and focused outreach activities at venues and conferences to engage and mobilize the expert community.

We can hit the road running in the next large disaster event and the idea will show is own value. What do you think? ―Bkhazai ☎ 7:15, 3 June 2016 (UTC)

I don't understand exactly what your idea is. What do you mean by "Connect [...] experts [...] to contribute information"? Are you suggesting that we let experts write about disasters without citing external sources? That would involve a major change to WP:V, one of the five pillars of Wikipedia and could be open to abuse. Are you suggesting that experts provide reliable sources externally for Wikipedia to use immediately about disasters? That wouldn't involve any change in policy; that's just improving news reporting, and it isn't related to Wikipedia. If you're proposing something else, you'll need to clarify. KSFT^C 05:24, 4 June 2016 (UTC)

I'd also like to see a little more clarity about the idea. While Wikipedia has been doing an impressive job of getting information out quickly, if there are experts who can improve the process, I'm happy to listen. I'd like to see experts more involved but there is nothing preventing experts from becoming involved. When you suggest it will need endorsement by the Wikipedia community of editors, I need to know more. No formal endorsement is needed if knowledgeable people are interested in helping write articles. Endorsement might be needed, if for example, as KSFT suggested, that the proposal would be to suspend some policies. That would be quite a big deal.

I think there are some things that could be done. For example, if there were some experts who did not regularly edit Wikipedia who plan to jump in and edit at the time of a disaster, they might find themselves accidentally in violation of rules or ignorant of norms policies and guidelines. It might be helpful to do a workshop for such experts to get them acquainted with the editing environment. Obviously, if a disaster is unfolding, that's not the time to have an in-depth discussion about what 3RR means. Some of these experts may choose to edit in general which would be a good thing some others might choose to edit only during a disaster, but like good disaster preparedness, the training should be done prior to the disaster.--S Philbrick(Talk) 14:31, 4 June 2016 (UTC)

To carry it further, we could even do a mock disaster drill. I'm vaguely aware that such drills exist for professionals trained to deal with disasters, but we could extend it to the reporting aspect. We have a test wiki, so we could do a real-time unfolding of a fake disaster — even on the test wiki we might choose to add some to emphasize that it is a test. That experiment might help identify ways that editors could improve the process.--S Philbrick(Talk) 14:34, 4 June 2016 (UTC)

Firefighters generally spend more time preparing for fires than extinguishing them and I assume the fewer people who handle bigger disasters are similar. Wikipedia:WikiProject Disaster management seems aimed in the correct direction. So, maybe some of the professionals who work in the public information part of disaster work, ought to revive that apparently inactive Wikiproject. If a number of such experts were to gather in one city, they would be an excellent prospect for a WP:Editathon.

User:Anthonyhcole has been working on a project to get information from medical experts. He may have some advice for this goal. WhatamIdoing (talk) 05:29, 15 June 2016 (UTC)

Integrating New Research Findings.

New reliable research findings are published regularly. See, for example the PLoS – Public Library of Science at: http://www.plos.org/ and many otters mentioned at: https://www.lib.utexas.edu/engin/guides/alumni.html

When Wikipedia becomes a complete repository of the world’s knowledge, then each of these newly published research findings will: 1) confirm an existing knowledge claim, 2) introduce a new knowledge claim, or 3) cast doubt on an existing knowledge claim.

I recommend we begin thinking about this influx of new knowledge systematically. For example, if Wikipedia provided a place where each newly published journal was analyzed, then each new article could be (tentatively linked) to the corresponding existing Wikipedia page. For example there is a recently published research paper titled: “The Great Migration and African-American Genomic Diversity” See: http://journals.plos.org/plosgenetics/article?id=info:doi/10.1371/journal.pgen.1006059 If this article presents new and reliable findings, then these findings have some bearing on the existing Wikipedia article on these subjects such as Great Migration (African American)

Under this proposal, the existing Great Migration article might have a (dedicated) Talk page section that links to the newly published research article. This link would have been created (semi-automatically) by the person who browsed the new research article. Over time, editors of the existing article can evaluate the newly published research to determine if it warrants a citation within the existing article, or requires the text of the existing article to be altered to reflect these new findings. In any case, interested readers can browse these newly published research articles to stay up-to-date on the topic. --Lbeaumont (talk) 13:18, 1 June 2016 (UTC)

We need a lot lot more volunteers to look at all those new papers. The idea is good in principal, and for example I use a Google scholar alert on several topics (eg langbeinites) and can then update articles I have written. Before we can just apply deltas from new publications, we first have to have 100% coverage of the knowledge in old publications. Perhaps a librarian can assess this for the whole of Wikipedia. I suspect Wikipedia is still less than 1%. For some narrow topic we may be able to have 100% coverage though. We also have the deletionists and minimalists that think a lot of what is published is not worth reporting in Wikipedia, or is too deep or technical for existing articles. However I believe that we need to have Wikipedia broader and deeper in knowledge. Graeme Bartlett (talk) 00:36, 2 June 2016 (UTC)

If memory serves, someone had a bot that did something similar to your idea. It tagged Cochrane review articles that had been updated. User:Doc James will probably know the details. WhatamIdoing (talk) 05:26, 15 June 2016 (UTC)

Yes in medicine we have Cochrane reviews which basically summarize the literature on a specific question.

We have a bot that lists which Cochrane reviews have newer reviews we should update to here [7]

But the editing community is small and we just run it on when there is no more items on the list. Doc James (talk · contribs · email) 18:00, 15 June 2016 (UTC)

Automatic notification if a thread is started about an editor on AN/I

AN/I seems to have a persistent problem with editors starting threads on other editors and not notifying them. Could some sort of automatic notification be set up to do so? Chickadee46 (talk) 20:31, 9 June 2016 (UTC)

There is a big red notice at the top of the page. Editors generally need to learn to read the instructions at the tops of pages, and particularly the big red notices.
The username is not always included in the section heading. Should this automation check every word in the thread to see if it matches an existing username? What about usernames that are multiple words? What about words, or series of words, that happen to match an existing username but are not used as such by the poster?
Failure to notify shows that the poster has failed to read the instructions, or they don't care about them much. Right out of the gate, it provides a useful clue as to their competence to file an ANI complaint.
It might be possible to create a new template for use in naming the user(s) within the text of the thread. {{ANI-notify|username}} could generate the same link as {{u|username}}. I don't know, but it might be technically possible for such a template to generate the notification at User talk:username. That would save some effort, but it would not address the problem you describe, that of missed notifications. For the most part, it would only be used by editors who have the competence and the energy to do it the existing way. It might result in a few notifications by posters who know they should notify but are simply too lazy to expend the additional effort, but imo not enough of them to justify the developer effort and the feature creep. ―Mandruss ☎ 00:49, 11 June 2016 (UTC)

@Mandruss:Those are good points, but I was thinking more along the lines of a field (like the one which shows up for asking a question at the Teahouse), which would have a blank to fill in with the name of the user(s) which are being complained about. If someone attempted to post but didn't fill in that blank, the thread would not be posted and a notice could pop up saying something like this:

Please fill in the "username of editor(s) being discussed" field. This will automatically notify the editor(s) you are discussing.

Chickadee46 (talk) 02:21, 11 June 2016 (UTC)

I see. If that's technically possible within our framework, it might be worth pursuing. I don't know whether it is. ―Mandruss ☎ 02:33, 11 June 2016 (UTC)

• You can make a report to AN/I for issues that don't necessarily involve a specific editor, or where you don't yet know who it involves. While some of these are gamey attempts to avoid giving the accused a chance to defend themselves, others there really isn't another editor to notify at the start. As a secondary issue, we are pretty good at enforcing the rule with regard to the initial reporter & accused, but technically a notice is required every time a new editor not already participating comes up in discussion, which this also wont address. Monty₈₄₅ 22:06, 18 June 2016 (UTC)

Delay on coverage of major events

Early news rushed to slap the terrorism label on the Orlando attack, Wikipedia editors rushed to reflect that in the article, and now it looks like that may have been significantly overstated. From NPR, dated Thursday the 16th: "As investigators continue to delve into the life of Orlando nightclub shooter Omar Mateen, the evidence is beginning to suggest the killings may have more in common with a traditional mass shooting than an ISIS-inspired terrorist attack."[8]

This is hardly an isolated case. And it's not just about disseminating misleading information. Article talk is often utter chaos as frenzied editors struggle to resolve conflicting early news reports, one minute detail after another. Quite often the conflict cannot be resolved that early, so we are forced to hedge our language in the article—"Some sources say..."—and then a few days later that has to be updated (after another round of discussion about whether it's appropriate to do so). What if we just backed off and waited awhile for things to settle down? My idea is a one-month delay on Wikipedia coverage of major events including airliner crashes and mass killings. Full list of categories to be determined.

I'm certain hundreds of thousands (millions?) of readers are used to coming to Wikipedia for concise summaries of breaking news, and it would be painful to change their habits. I do not discount or dismiss that pain at all. But "real-time encyclopedia" is an oxymoron, and in my opinion we need to cease trying to be that. News outlets often (if not usually) get important things wrong in the beginning, Wikipedia readers read it during the early days and then move on, and they have other things in their lives that prevent them from coming back after two weeks to see what's changed. In our fast-paced and busy world, a huge number of people have short attention spans for current events, and that is not going to get anything but worse. The Wikipedia editors addicted to the newsroom adrenaline rush of working with breaking news would have to move to Wikinews for that fix, and readers would have to gradually make the transition. If Wikinews does not have a single place to go for the concise summary of a breaking news story, it could and should. That certainly belongs there more than here.

I'm aware of the general disclaimer. How many readers do we suppose are aware of that and keep it in mind when they read these articles? I prefer to confine my thinking to the real world, not legalistic arguments. The GD is little more than lawsuit protection.

I would welcome any discussion of this issue here, or a pointer to meta if this is seen as wrong venue (I've never visited meta, and that's probably something I need to learn anyway). ―Mandruss ☎ 08:44, 18 June 2016 (UTC)

a traditional mass shooting - this makes it sound like it's normal to have a mass shooting in the USA every year or so, like Groundhog Day is a tradition. Anyway, we cannot ask people to hold off for a month, because there will always be people who want to get in first, won't read the guidelines, probably are newbies. --Redrose64 (talk) 10:54, 18 June 2016 (UTC)

We already have a speedy deletion mechanism that could handle those cases. ―Mandruss ☎ 10:57, 18 June 2016 (UTC)

I'm opposed to delaying coverage of major events, but maybe there should be something like the {{recent death}} tag which explains that early details of such events may be inaccurate. Strawberry4Ever (talk) 11:18, 18 June 2016 (UTC)

The Orlando article initially used the {{Current}} template. The template was removed almost four days ago, about 47 hours after the perpetrator was killed, because the article was well below the threshold specified in bullet 2 of the template's usage guidelines. News stories are not still "breaking" after 47 hours, and there were certainly not "a hundred or more" editors per day. Sure, it's only a guideline, but what WP:IAR rationale was there for disregarding it? If people are willing to make major changes to that bullet 2, that would be a slight improvement, to whatever extent that readers even read that template message and absorb what it means. It would do nothing to address the chaos in article talk however. And there's still the principle that we are supposedly WP:NOTNEWS, and yet we are. ―Mandruss ☎ 11:27, 18 June 2016 (UTC)

After this happened, I mentioned Howard Unruh on the talk page almost immediately. I didn't say what I was actually thinking about this, which was "Now let's see if this guy had repressed homosexual feelings", which according to current news coverage, he may well have done. A week on, and the CIA also says that it is unlikely that Omar Mateen had any contact with anyone in ISIL. The "Current" template allows for some of this, but it may need to be beefed up given the wildly inaccurate reporting of the Orlando shooting during the first 24 hours.--♦IanMacM♦ ^{(talk to me)} 12:02, 18 June 2016 (UTC)

Further, the decisions on article titling would be far easier after the one-month delay. Many of these articles go through three or more moves in the first week, which is just crazy. All because very few editors can restrain themselves and just hold off for a week or two before any title change discussions. We must get this title right, NOW. Even most very experienced editors do that. ―Mandruss ☎ 12:08, 18 June 2016 (UTC)

• In my opinion, this would be step backwards. Feedback suggests that at least some readers benefit from our agility in presenting up-to-date facts in an organized fashion. I agree that news outlets sometimes incorrectly report facts, but so do history books.- MrX 12:16, 18 June 2016 (UTC)

  up-to-date facts and up-to-date fiction. ―Mandruss ☎ 12:30, 18 June 2016 (UTC)

  That's why it's important to use the best sources and be conservative about the type of information we include in a breaking news article. I think we do an excellent job removing fiction once we actually know that it's fiction.- MrX 12:41, 18 June 2016 (UTC)

  Regardless, those same readers could just as easily benefit from Wikinews's agility in presenting up-to-date facts in an organized fashion, after they make the transition. I don't think saving them from that transition is a benefit that outweighs all the points I've made, many of which you haven't addressed. ―Mandruss ☎ 12:54, 18 June 2016 (UTC)

  Ah, that would be great except that the Wikinews article is viewed by a fraction of a percent the number of readers as the Wikipedia article.- MrX 13:06, 18 June 2016 (UTC)

  Maybe that would change if there were no Wikipedia article (yet)? I'm thinkin' the Wikipedia percent would fall to about zero. ―Mandruss ☎ 13:10, 18 June 2016 (UTC)

  It would be an interesting experiment to try.- MrX 13:16, 18 June 2016 (UTC)

  I, for one, have never heard of Wikinews until now. How would members of the general public hear about it? Strawberry4Ever (talk) 16:44, 18 June 2016 (UTC)

  Well I don't know. How did they hear about Wikipedia? It may be largely unknown now, but that would change if we moved our coverage of major developing events there. The change would be reported by all mainstream news, no doubt. Readers who somehow miss that will come here looking for the article on the latest event, not find it, and either go to someplace like WP:HD and ask, or walk away scratching their head and discuss the problem with their friends and family, one of whom might know the answer. It does take a little while for changes to make it into the culture. ―Mandruss ☎ 16:51, 18 June 2016 (UTC)

I'll go ahead and ask the question that I know is coming, if this doesn't just die from lack of interest.
Q: Well doesn't this just move all those problems to Wikinews? Same misleading early information, same chaos in article talk, etc.
A: Partly. But in that venue, readers are far more likely to take things with a large grain of salt. Hell, Wikinews could slap a big red disclaimer permanently at the top of every article page. As for the chaos, good point. I guess there's no avoiding that with developing stories, but it would at least be in a news venue rather than an encyclopedia. I doubt they agonize a lot over article titles there, worrying about COMMONNAME and disambiguation and such, so that part of the problem would go away. ―Mandruss ☎ 16:31, 18 June 2016 (UTC)

• The creative ferment of readers racing to put together the facts about a breaking news story is one of the best aspects of Wikipedia. The value of this process is recognized by external sites like Google News that link here because these articles are among the best coverage of the topic. Whether something is a minute old or a century old, Wikipedia aspires to put together the best article based on available sources.

• "WP:NOTNEWS" is the most outrageously misnamed and misused policy on Wikipedia. Those who read it beyond the awful shortcut see that it says to treat breaking news like other events. We use the same policies on notability and the same guidelines for writing.

• I feel bad for any in the news industry who realize that, no matter how good they are at what they do, their careers are doomed because there simply is no way to make news pay, unless you are one of a few top eyeball owners, in which case anything will pay. The fact that something happened is not copyrightable, at least outside of certain litigious European countries; even if it were, people will ignore that. We have a broken economic system that relies on the nonsense idea that people can own your thoughts and words. But that is no excuse for the relentless effort to slow down, confuse, dumb down and destroy Wikipedia's attempts to get together the whole story. Wnt (talk) 16:58, 18 June 2016 (UTC)

"WP:NOTNEWS" is the most outrageously misnamed and misused policy on Wikipedia. Point taken. I hereby retract that sentence. Nevertheless, "real-time encyclopedia" is an oxymoron. And all the great things you say about developing stories at Wikipedia could be said about developing stories at Wikinews, the more appropriate venue for that. ―Mandruss ☎ 17:47, 18 June 2016 (UTC)

I don't think that a delay on creating new articles about stories in the news is ever likely to happen, but the coverage of the Orlando shooting has not been the finest hour of the mainstream media. Wikipedians are expected to go along with the things that "reliable" sources have said, regardless of whether they are reliable or not.--♦IanMacM♦ ^{(talk to me)} 18:36, 18 June 2016 (UTC)

@Ianmacm: Do you think it should happen? How much merit do you see in the argument? ―Mandruss ☎ 18:44, 18 June 2016 (UTC)

It is tempting, because many articles about mass shootings are an utter shambles for the first 24 hours. Orlando has set a new benchmark for this sort of thing. However, people do like to create new articles as soon as possible, and I can't see it ever happening.--♦IanMacM♦ ^{(talk to me)} 18:50, 18 June 2016 (UTC)

Hmmm. Well people would like to do a lot of things that we don't let them do. And none comes to mind at the moment, but there are probably things that people liked to do for a long time and are no longer allowed to do. So that seems pretty thin. If this doesn't happen, I think it will probably be simple resistance to change, protection of the status quo. And that old bugaboo, "no consensus to change", from lack of sufficient participation. ―Mandruss ☎ 19:00, 18 June 2016 (UTC)

It's like the quote by Oliver Cromwell, "Not what they want but what is good for them." This could be proposed formally, but we're already up and running at Death of Jo Cox despite objections. The British media has covered little else for the last 48 hours and some people would complain if there was no Wikipedia article.--♦IanMacM♦ ^{(talk to me)} 19:34, 18 June 2016 (UTC)

Got it. Mustn't do anything that some would complain about, even if it's good for two wiki projects. Never mind that complaining about things is everyday routine at Wikipedia. I'm ready to be the one walking away scratching my head, discussing the problem with my friends and family. Thanks for the conversation all, I'll now give this up per Wikipedia:How to lose unless I see some support. ―Mandruss ☎ 19:51, 18 June 2016 (UTC)

Suggestion - unify "glossaries", "categories","List of.." by automatically assembling 'microarticles', streamline glossary&list creation/maintainance

goal

streamline the generation of glossary & 'list of..' pages using "Micro-articles"; simpler for users and reducing manual redirects/anchors etc.

ideal situation

• A 'category page' automatically assembles the first 1-2 sentences from each article, and displays it alongside the title, in glossary format.
• Allow "micro-articles" - articles which are just 1-2lines of definition of a term, hyperlinked of course.
• Clicking a link to such "micro-articles" automatically loads a corresponding category/glossary page & locates it's internal anchor.
• Obsoletes all "glossary of.." and "list of.." pages.
• EDIT: consider how this would play with the new 'hover cards feature - imagine if you consistently get a nice definition/summary under any term you hover over..

transition

Some tool splits existing glossary/'list-of' pages into individual "micro-articles". automatically guess categories for new 'small pages' from wording, 'in foobar, baz is ....'

benefits

• Less to teach contributors (e.g. template term/defn list markup, bullet point markup); casual editors just need to know [ [ link ] ] format to contribute.
• Adding many 'micro-articles' bridges the gap between wiki and a knowledge graph AI resource.
• Such pages would be subject to additional filtering e.g
  • category intersections/unions, ('computer hardware=comp arch+personalcomputers/ 'personal computers'/ 'computer software' / 'computer architecture...' etc etc)
  • an advanced 'what links here' result - 'everything related to this..'
  • glossary for an individual article?
• Encourage heavy linking with more machine-processable definitions of terms.
• Easier for inter-language translation.
• Easier to manage. (where should a minor definition go?)

motivation

currently I find myself wanting to create all sorts of redirects to terms & re-work articles to create additional anchors to increase the 'link fidelity' (knowing that links are a potential form of labelled data for AI), but these may be more complex to manage. e.g. what if you create a term in a summary and eventually it gets an article, but there's all sorts of conflicting redirects to either the glossary entry or the full article

more details

compiling micro-articles, perhaps deal with parsing some standard formats like "in <foo> , <title> is <content>.." which compress to <title> : <content> when rendered in the 'glossary/category' page for <foo> - or do the reverse. Perhaps auto-assign category from 'in <foo> ..'

— Preceding unsigned comment added by Fmadd (talk • contribs)

EDIT: if worried about 'overlinking', the software could filter out some of the links based on importance. — Preceding unsigned comment added by Fmadd (talk • contribs) 07:14, 20 June 2016

I changed your six subsections to bold text. I guess you don't want separate discussions below each heading. PrimeHunter (talk) 20:06, 8 June 2016 (UTC)

This would be a major change in the organization of pages on Wikipedia that you are suggesting, and is not only technical in nature. If you have not already, you should read Wikipedia:Categories, lists, and navigation templates. After that, please address what that guideline specifically says about the advantages of having lists (plus glossaries) and categories as two different ways of organizing information. – Finnusertop (talk ⋅ contribs) 20:09, 8 June 2016 (UTC)

(Sure it might be a big change. I realise anything like this would have to be implemented gradually as a rolling transition). So to address the advantages of a list- red links= (todo) => perhaps you could do the same job with a placeholder article, and you still have red-links in micro-article content. embellished with annotations => my suggestion is to encourage the first line to include salient information (which it mostly does). I suppose a transitionary measure would be a template in micro articles, but that recovers complexity that the suggestion aims to reduce. included in searches => i think this would benefit search more (and couldn't categories just be added to search anyway?) list formatting styles => software can choose an optimal format based on the content, which might even change depending on the view (e.g. category intersection & even user's browser,mobile vs desktop). more easily edited by newbies => overall this suggestion is trying to streamline what users have to learn. it is of course shifting work into the platform itself. images can be interspersed - I notice the beta-feature of 'page suggestions' uses images - I think a way to highlight a 'key image' associated with the article must already exist. introductory paragraphs for list => split these into a 'introduction to blahblah' page which is automatically assembled by the tool. Fmadd (talk) 20:31, 8 June 2016 (UTC)

I am afraid that for this to work, the first few lines of every single article need to perfect. If we cannot guarantee that, we will end up with endless confusing micro-articles and list entries automatically compiled by the system. How would we solve this? Arnoutf (talk) 17:59, 9 June 2016 (UTC)

I would hope that is less hazardous than the scope for mess already; another way to spin is to display 'foo is blah blah...<more>' to emphasise it's a preview of an article. But if people want their articles to be read, I think they'd pay attention to it. Also notice the new 'hover card' beta feature - I think it would play well with that. I would imagine the dynamic nature would be easier to deal with than manual maintenance issues with existing glossaries/lists. (just encountered a merge request today.. 2 pages with different glossary styles..) Fmadd (talk) 03:28, 10 June 2016 (UTC)

Creating redirects and disambiguation pages to influence search engine indexing

I'm concerned about a practice I've noticed for many years when articles that would fail to meet notability guidelines are created and then immediately redirected to another (but notable) article and a specific subsection. These redirects are often picked up by Google and other search sites. And perhaps these are useful, however I am concerned when BLP's are involved. Per WP:BLP (emphasis added)

Biographies of living persons ("BLPs") must be written conservatively and with regard for the subject's privacy. Wikipedia is an encyclopedia, not a tabloid: it is not Wikipedia's job to be sensationalist, or to be the primary vehicle for the spread of titillating claims about people's lives; the possibility of harm to living subjects must always be considered when exercising editorial judgment.

I've raised this at BLP/N, but I think this needs a bit of a wider audience, so please forgive me if this seems like canvassing. The immediate issue at hand is the List of Guantanamo Bay detainees, but this is just an example of one of many lists that may be of concern. The list is comprised of several hundred people. While several of the people on the "list" pass Wikipedia's notability guidelines, the majority do not. So we have a list comprised of no links, blue links and red links. Several of the links such as Mustafa Ahmed Hamlily have been redirected to other articles (in this instance Algerian detainees at Guantanamo Bay). One can presume that is because it was determined that these people did not meet GNG. Some of the BLP articles were created with just a redirect, bypassing a stub altogether. I apologize for not providing an example, but this "create/redirect" type of articles exists in many "list" type articles. Regardless, a BLP article exists only to redirect a user to another article.

If the subject is not notable, is this not a privacy concern? What if I'm an employer and I google someone who, while not notable returns a hit as a "detainee"? This could obviously be prejudicial. The "red links" also pose a concern for similar reasons. Just having one's name pop up in a Wikipedia article could raise a red flag. At what point does linking cross the line of verifying reliable sources to possibly causing the subject harm? That man from Nantucket (talk) 08:42, 19 June 2016 (UTC)

Mr Nantucket, you have voiced this concern, in one fora after another.

I've responded elsewhere. And you have said, multiple times, that you aren't interested in my opinion. One more time, this concern you repeated overlooks a key element of notability. There is a spectrum.

• At one end there are people who are unquestionably notable because a billion educated people know who they are -- like Napoleon Bonaparte, or Yuri Gagarin.
• At the other end there are almost seven billion people who are totally non-notable ... they haven't even been written about in their church newletter, let alone a newspaper, or any other reliable source.
• In between there are the less notable people we cover here in the wikipedia. They fall into two subgroups:
  1. Individual who measure up to the notability criteria of the GNG, or one of our special purpose notability guidelines, are notable enough for a standalone article. The last time I looked about half the wikipedia's articles were BLPs.
  2. What you keep overlooking is that the WP:GNG, and various special purpose notability guidelines, like WP:POLITICIAN, all say that individuals who aren't notable enough for a standalone article, can nevertheless be notable enough for some coverage in some other article.

     Consider Robert G. Smith (educator). I came across him when I worked on the article on Libby Garvey. He was in charge of the Arlington County Board of Education, for a decade or so, during the time Garvey was a trustee. A exchange they had, during his job interview, was notable enough to be quoted, paraphrased, or referred to, in several RS.

     That made him notable enough to merit a wikilink in the Garvey article.

     It turned out that Robert G. Smith was a bluelink, but because my guy had a namesake, and I found a redirect. I converted that redirect to a disambiguation page, and added my guy, as per the DAB rules. I added an entry for Robert G. Smith (candidate, 1968) who had been linked in United States House of Representatives elections, 1968 to Robert G. Smith (aviator).

     You excised the entry for the educator, with the edit summary "Red link". I've already pointed out to you, that this excision was not consistent with WP:Manual of Style/Disambiguation pages#Red links. Inexplicably, you left the other redlink, to Robert G. Smith (candidate, 1968), although it too was a redlink

     As I have tried to discuss with you, contributors are authorized to create wikilinks for individuals when they think they may merit coverage here.

• Mr Nantucket, you quoted from BLP above, adding emphasis, in your quote, to our obligations to "respect [the] privacy" of individuals, and bear in mind the "possibility of harm" from sensationalist reporting. However, from your calls upon the authority of BLP I honestly think you carry your idea of how much protecting individuals are entitled to far beyond what the rest of the wikipedia community agrees with.

Consider your comment about Libby Garvey, again. You went to several fora, asking contributors to go weigh in on the AFD you initiated. In the this comment, at BLPN, you challenged whether I was editing in good faith, writing: "I'm afraid that my first impression, which I've kept to myself until now is that the raison d'etre for this article may be to attack a living person for a political position they took..."

Garvey is not a private person, who was covered in RS due to some kind of accident. She is a politician, and has been a politician for twenty years or so. If she was a singer, we'd cover her songs. If she was a film-maker, we'd cover her movies. Because she is a politician, we should cover her political positions.

I am going to repeat this, since you seem to have so much trouble recognizing it is an important point -- Because Libby Garvey is a politician, we should cover her political positions.

You decided that compliance with BLP required us to protect Garvey from "harm" from accurately reporting on how she performed her job. Was George W. Bush embarrassed soon after he gave a major speech on Iraq in front of a massive banner that said "Mission Accomplished", when it became painfully obvious the US forces would be bogged down in Iraq for over a decade? Tough. We shouldn't protect George W. Bush from the consquence of his "Mission Accomplished" appearance. Similarly, we shouldn't protect Garvey.

Unless youare in violation of WP:COI, and know Garvey personally, or worked on her campaign, without disclosing this fact to us, how would you know Garvey even wants' this protection? Some politicians double-down, when criticized. Look at Donald Trump.

With regard to whether individuals like Algerian Mustafa Ahmed Hamlily should be wikilinked in articles like Algerian detainees at Guantanamo Bay. Removing those wikilinks, to "protect" them is not responsible. All the individuals held at Guantanamo are individuals who measure up to the lesser measure of notability to be covered in an article on another topic -- just like Robert G. Smith (educator).

FWIW, a selection of the individuals who were held at Guantanamo, who are red-linked today, neverthess sail past the inclusion criteria for meriting a standalone biography article Geo Swan (talk) 22:02, 20 June 2016 (UTC)

That's not even remotely accurate. There are dozens of Gitmo BLP articles that have been deleted precisely because of the lack of notability. And I'd appreciate it if you would turn off your verbose mode. Yes, I'm looking for other opinions. Walls of text, IMO, shutdown discussion, not encourage it. I don't want to create a proposal via RfC or other measure if I see a lack of support for the concept. But if one person stifles the discussion, I will do so.That man from Nantucket (talk) 03:37, 21 June 2016 (UTC)

Phone view

Most editors change pages on their laptop but most readers check Wikipedia on their phone. What we see is not what the reader gets. An article full of info boxes and images may look good on a laptop and terrible on a smaller screen. An editor can resize their edit window to check, but most would not. And if the server software adapts to the viewing device, that effect will not show. Better to have a button at the bottom of the edit window that prompts the editor to preview how the article would look on a typical phone:

Save page

Show preview

Phone view

Show changes

Cancel

The new button would encourage editors to check how the article looks to the normal reader. Comments? Aymatth2 (talk) 13:50, 14 June 2016 (UTC)

Mobile sidebar preview - Show page in mobile view while browsing the desktop site

Hi Aymatth2, There is a gadget in Special:Preferences#mw-prefsection-gadgets "Mobile sidebar preview: show page in mobile view while browsing the desktop site" which does this. - NQ (talk) 13:54, 14 June 2016 (UTC)

To clarify, I'm merely pointing out that the functionality already exists if it needs to be integrated to the edit window. The gadget is normally used for testing and development purposes and is well tucked away in preferences and not available to the average user at a glance. - NQ (talk) 14:08, 14 June 2016 (UTC)

• I had no idea it was there. It demonstrates that something like this is possible – but the "Phone view" button would be much more likely to be used. I don't know if the server software adapts to the viewing device. If so, more than a change to the preview skin would be needed to really see the effect. But that may be pushing it further than needed. Aymatth2 (talk) 14:18, 14 June 2016 (UTC)
• Yea, I do think that a phone display button would be more accessible for new users. a_creeper_won —Preceding undated comment added 17:18, 14 June 2016 (UTC)
• Agree. I think that the ability, on the push of a single button, to see a single page in phone view mode while editing it, and then return to normal view on the next page load, would be very useful. עוד מישהו Od Mishehu 03:09, 15 June 2016 (UTC)

For what it's worth, this is already available on Chrome by pressing Ctrl-Shift-I and then Ctrl-Shift-M. TimothyJosephWood 17:46, 17 June 2016 (UTC)

• I didn't know that! That is exactly what is needed, although it should be a button rather than six keys to get there, and it should default to 100%. I assume Chrome is telling WP "I am a mobile with a 360x640 screen", whatever, and WP is formatting accordingly. There must be a way of a pop-up window doing the same. Aymatth2 (talk) 18:47, 17 June 2016 (UTC)

Not sure where the default size comes from, but at the top over the simulated mobile screen, if you hit the drop-down that says "Responsive" by default, you can select different devices to emulate. By clicking "edit" at the bottom of the menu you can select from ~30 supported devices. TimothyJosephWood 18:52, 17 June 2016 (UTC)

I like the idea of a "mobile preview" button that appears by default. I'm all for seeing how an article looks on multiple platforms, but it's a PITA (pain in the a--) to be tweaking the features in preferences, time-consuming and at times complicated. Montanabw^(talk) 03:26, 20 June 2016 (UTC)

• For some reason the gadget does not work properly for me. It shows the phone view sidebar, but does not show a tab to toggle it on or off. Once I press the big "X" to close the sidebar, I have no way to get it back. It is probably fighting with some other preference. Aymatth2 (talk) 13:02, 20 June 2016 (UTC)

@Aymatth2: Are you missing the small phone icon next to the More tab? (as shown in the picture attached) - NQ (talk) 13:11, 20 June 2016 (UTC)

@NQ: Yes. See below for what I see in Chrome. The gadget is selected. Aymatth2 (talk) 13:36, 20 June 2016 (UTC)

@Aymatth2: The documentation says the gadget is for Vector skin only. - NQ (talk) 13:40, 20 June 2016 (UTC)

• @NQ: If I had any idea what that meant, I am sure that would explain why the gadget does not work for me. This seems like a good reason for having a simple "Phone view" button at the foot of the edit window. Aymatth2 (talk) 13:48, 20 June 2016 (UTC)

@Aymatth2: Please disable the gadget in preferences and copy importScript('User:קיפודנחש/mobile-sidebarcopy.js'); // Linkback: User:קיפודנחש/mobile-sidebarcopy.js to your common.js for a version that works with your skin. - NQ (talk) 13:53, 20 June 2016 (UTC)

• @NQ: That sort of works, except the tab is not there in edit mode so I can't preview how the article will look. And it just shows the one screen size, not a tablet size. We need something simpler that the average non-technical editor is likely to use. I get the feeling that there is no basic technical issue and general agreement here that a "phone view" button would be useful. Aymatth2 (talk) 14:15, 20 June 2016 (UTC)

i will add some background, regarding the "mobile view gadget": (1) this gadget is only available in "view" mode, not in "edit" mode, so it can't be used for edit preview. (2) the gadget was written by User:Brion VIBBER (incidentally, the person that created the mediawiki software as we know it). the gadget he created works for vector skin only. some time ago there were some questions in WP:VPT, and i challenged myself to create the absolute minimal change to the gadget which will teach it to work with other skins. what i came up with was this modification: User:קיפודנחש/mobile-sidebarcopy.js. i never meant it as a "solution". it was more like "proof of concept". i left Brion messages about this on several talk pages, hoping he will modify his script to be "skin agnostic". ttbomk, this did not happen yet. i don't think it would be good to use my script - the right thing would be for Brion to teach the master script to be skin agnostic. this will still not enable mobile-view for edit preview - if this functionality is desired, some other solution should be looked for. peace - קיפודנחש (aka kipod) (talk) 14:43, 20 June 2016 (UTC)

• @קיפודנחש: I did not mean to be critical. Brion's gadget, your script, and the Google Chrome Ctrl-Shift-I and then Ctrl-Shift-M are all much more than I thought were available, and show that technically a "phone view" preview button should be possible, if anyone will volunteer to write it. I suppose the next step is to take this to a more sceptical audience as a village pump proposal, and if it does not get shot down put it into a wishlist somewhere. Aymatth2 (talk) 15:08, 20 June 2016 (UTC)

Now a proposal. I have started a discussion at Wikipedia:Village pump (proposals)#Mobile view. Thanks to all who contributed with ideas and information here. Aymatth2 (talk) 14:00, 22 June 2016 (UTC)

ParliamentEdits

Should there be (or is there already) a list of Twitter accounts in Wikipedia namespace, that automatically tweet when someone from a government edits Wikipedia anonymously, like @ParliamentEdits. There are quite a few of these accounts (@AussieParlEdits, @congressedits, etc. - quite a few accounts listed in the references of CongressEdits) and this list could be useful if editors want to see/check anonymous editing from these organisations, which could help combat vandalism/COI editing. Thanks for your input.  Seagull123  Φ  16:58, 26 June 2016 (UTC)

A new WikiProject

This is a general notice that a new WikiProject has been created: WikiProject Reforming Wikipedia. Its purpose is to improve Wikipedia by promoting policy reforms that will facilitate better-sourced, higher quality content and fairer, more efficient governance systems. This is a new project in the very early stages of development, so please read the page linked above and consider joining if you are interested in helping to improve Wikipedia. Thank you! Biblio (talk) 17:33, 26 June 2016 (UTC)

Is this not identical to WP:WikiProject Wikipedia Reform? ‑ Iridescent 22:43, 26 June 2016 (UTC)

I was aware of that project, but it's a defunct one from many years ago (in the context of Wikipedia, at least). That project never really seemed to have any clear goals at all—it was more of a forum, not an actual working project, and WikiProjects were never meant to simply be forums. This new project has some actual ideas to start with, and the goal here is not to simply to discuss ideas, but to actively collaborate in crafting and promoting those ideas. The revival and improvement of older ideas is encouraged. Biblio (talk) Help improve Wikipedia. 22:59, 26 June 2016 (UTC)

Looking for feedback on a tool on Visual Editor to add open license text from other sources

Hi all

I'm designing a tool for Visual Editor to make it easy for people to add open license text from other sources, there are a huge number of open license sources compatible with Wikipedia including around 9000 journals. I can see a very large opportunity to easily create a high volume of good quality articles quickly. I have done a small project with open license text from UNESCO as a proof of concept, any thoughts, feedback or endorsements (on the Meta page) would be greatly appreciated.

Thanks

John Cummings (talk) 11:24, 28 June 2016 (UTC)

Extended confirmed protection policy

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.

---

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,[9] 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)

In comparison with Full Protection, two particular points of contention spring immediately to mind - Talk pages; Admin removal of the extended confirmed bit - with a third a few moments later - indefinite length. Suggest we should certainly want to put questions on the first two to the community as part of any RfC; and likely the third also. - Ryk72 ^'c.s.n.s.' 12:48, 2 June 2016 (UTC)

Draft RfC

• @KrakatoaKatie: I've started a very rough draft of a possible RfC at User:Mz7/Draft extended confirmed RfC based on my comment above. Feel free to add to it, edit it or comment on it. Should we add any options? Should we scrap a few options? Is this completely the wrong structure for the RfC? I should probably elaborate more on each option, though, if we are using this structure. Mz7 (talk) 18:55, 2 June 2016 (UTC)

• I'll take a closer look shortly, but my main problem is that there are too many options that could gain consensus from separate groups of !voters. (If both A and D get consensus, what to do then? It will have wasted everybody's time.) I also think you can combine B and C1 to just say 'community consensus' instead of 'community consensus only for X or Y'; let the community decide what it's going to decide. You want to make the RFC as clear as possible so consensus or the lack thereof is easy to judge. The fewer options the better, and ideally only one choice at a time. Katie^talk 19:14, 2 June 2016 (UTC)

I see what you mean. I'll see what I can do. Mz7 (talk) 19:26, 2 June 2016 (UTC)

• B and C have too much exclusivity in their verbiage - for example C's "Allow use only" precludes it from being used by other community consensus as in B. — xaosflux ^Talk 02:24, 7 June 2016 (UTC)
• We need another option between B and C in terms of restrictiveness. Here's what I wrote at a relevant AN thread a moment ago: "If this application is supported by the community, I have a small list of pages that could use 30/500 protection based on the activity documented at Wikipedia:Sockpuppet investigations/Никита-Родин-2002/Archive, where a couple other editors and I have been playing high frequency whack-a-mole with a particularly sneaky vandal for months. Given my experience there, I strongly support the use of 30/500 protection in cases where sockpuppetry has been highly persistent (longer than a month), highly disruptive (sneaky vandalism, BLP violations, or edits subject to WP:RevDel), and resistant to semi-protection." I think admins should be able to apply this protection level at their discretion, but those highly persistent and highly disruptive aspects are key. It makes little sense to apply 30/500 protection and freeze out legitimate editors to stop easily detectable and fixable vandalism that isn't highly disruptive. It also makes little sense when the sockpuppetry occurs in a brief but highly active period of vandalism, since a CheckUser would be able to find and block the relevant sleeper accounts if they're all popping out of the woodwork for a single mass-"attack". In that instance, SPI is a far more appropriate venue than WP:RFPP. But there needs to be something above semi-protection to prevent a huge waste of editor time in instances like the SPI I listed above. Long-term abuse cases are few and far between, but they're a serious time sink when they're active. ~ Rob^Talk 17:18, 17 June 2016 (UTC)
  • There's also technically the possibility of going with Option A but setting up a section at WP:RFPP to request 30/500, with ArbCom speedily considering the requests privately (well, more speedily than a full case, anyway). I'm not a fan of giving the community or admins no ability to apply this protection level, but this would at least be an improvement over requiring a full ArbCom case to get 30/500. I don't want to file a case just to get 30/500 on some pages related to that SPI I linked above. The thought alone makes me want to sign out for a long period of time. ~ Rob^Talk 17:37, 17 June 2016 (UTC)
    • There is a relevant discussion here on the community applying 30/500 to a set of articles. ~ Rob^Talk 04:38, 18 June 2016 (UTC)
• Option D; second choice option C. I've been helping to patrol RfPP for years, wishing we had something short of full protection to deal with persistent disruption, so I support option D, namely that admins should be allowed to use this as needed, as an alternative to full protection. Realistically, most of those cases are going to be of the option C variety: persistent sockpuppetry and sleeper accounts. SarahSV ^(talk) 21:25, 18 June 2016 (UTC)
  • @SlimVirgin: In case you're confused, this isn't the RFC, just getting ideas for what an RFC about EPC needs to look like. --Izno (talk) 23:40, 18 June 2016 (UTC)
    • Hi Izno, thanks. I realized after I'd posted it that I'd jumped the gun. I like the draft RfC, though it might have too many options. It would be better, in my view, to offer two options: current option B and a combination of C and D. SarahSV ^(talk) 01:30, 19 June 2016 (UTC)
• I have created my own draft of the RFC based on Mz7's draft, which can be found in my userspace at User:Tazerdadog/Draft Extended confirmed RFC. I encourage people to take a look at it, and incorporate any worthwhile content into whatever the final proposal ends up being. I know that there are too many options, however, I wanted to include everything I can think of. I fully expect the final RFC will cut 2-3 of them out. Cheers, Tazerdadog (talk) 06:24, 22 June 2016 (UTC)
• I think it needs to explicitly say whether "allow administrators to apply at their discretion" means 1. any one admin can unilaterally apply ECP on a page or 2. consensus among X number of admins. Option B shouldn't even need to be an option. Any action can be taken to a noticeboard for community approval but making it a specific requirement makes it too bureaucratic and an admin would likely to have to levy semi or full protection until community consensus was reached on ECP. That somewhat defeats the purpose. Admins already have the discretion to use semi and full prot, the RFC should focus on whether the community is comfortable with granting admins discretionary use of ECP.

I would recommend removing Option B altogether but subsume it into Options C-E as an addendum.

• • Option C: Allow use on pages that have an established history of particularly persistant and disruptive vandalism which would circumvent semiprotection. Notification is to be left on an appropriate noticeboard (AN, ANI, etc) for community review

  • Option D: Allow administrators to apply at their discretion against vandalism where semi protection is not or would not be effective to control the disruption. Notification is to be left on an appropriate noticeboard (AN, ANI, etc) for community review
  • Option E: Allow administrators to apply at their discretion when the page would otherwise merit full protection, but 30/500 protection is deemed sufficient. Notification is to be left on an appropriate noticeboard (AN, ANI, etc) for community review
• I suggest stripping the options down to this (using some of Mz7's phrasing).

1. Continue to restrict use of ECP to Arbcom only.
2. Allow administrators (how many?) to apply ECP 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. Notification is to be posted on an appropriate noticeboard for review.
3. Allow administrators (how many?) to apply at their discretion when other protection measures have failed and full protection would be inappropriate. Notification is to be posted on an appropriate noticeboard for review.

Blackmane (talk) 01:48, 24 June 2016 (UTC)

@Blackmane: Sensible, and I agree. Review at AN is a great idea. Persistent vandalism in these cases is almost always socking anyway, so that's redundant. I'll amend the RFC accordingly.

Unless there are objections, I'm going to take this live on Monday, July 4. Katie^talk 12:33, 28 June 2016 (UTC)

I second including the noticeboard disclosure requirement in the options. Altamel (talk) 03:57, 2 July 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

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.

Search Drop down list - redirects in italics?

There appear to be a number of places (like categories) where redirects are in italics and normal articles are in non-italics. Could that concept be added to the drop-down list on search box? (so that for example, if Phi Gamma Delta is typed into the searchbox, Phi Gamma Delta, Phi Gamma Delta House, and Phi Gamma Delta Fraternity House (University of Minnesota) show up as normal, but Phi Gamma Delta Chapters occurs in italics since it is a redirect.Naraht (talk) 14:50, 5 July 2016 (UTC)

Naraht Interesting idea. I created a task to have the search team take a look at it. I included a mockup of what it might look like given your description. Please let me know if I understood correctly. CKoerner (WMF) (talk) 19:23, 7 July 2016 (UTC)

@CKoerner (WMF): Yes, that's the idea. Note, I'd be fine if this was either a preferences option or even a tool that needs to be added. Mostly because I'm not sure where that sort of thing would be explained to a new user.Naraht (talk) 20:33, 7 July 2016 (UTC)

redlinks that exist in other capitalizations?

Not quite sure where to put this idea, but here seems more likely than most... Is there any way to keep track of redlinks where an article exists in another capitalization? For example alpha phi alpha is a redlink, but Alpha Phi Alpha exists. I'd be very hesitant to let a bot at these, but maybe just the top 100 or so out of mainspace?Naraht (talk) 20:42, 23 June 2016 (UTC)

If there are "lots" of red links to a wrong capitalization, redirects should be made. — xaosflux ^Talk 12:26, 26 June 2016 (UTC)

In the example of wrong capitalization, there should be a redirect, *but* in the wrong capitalization category allowing it to be fixed.Naraht (talk) 20:42, 30 June 2016 (UTC)

WP:RLR. --Edgars2007 (talk/contribs) 20:55, 30 June 2016 (UTC)

If only MediaWiki was case insensitive... --NaBUru38 (talk) 01:11, 8 July 2016 (UTC)

Talk page, edit-form hassle

It's obvious to me that the Edit Summary field is intended for edits being made to Articles. If I make an edit to an article as minor as fixing punctuation or grammar, I don't mind saying so in the Edit Summary for the article.

But Talk Pages aren't articles. And whenever I append an idea to a Talk Page, my submission is already a summary of my idea -- well, at least concise, or else I'm being too wordy.

After making an effort to use as few words as possible when contributing to a Talk page, it always seems annoyingly redundant to me to see the buttons ask for an "Edit Summary." The edit was already summarized, if you get my drift. At worst, the Edit Summary would be a repeat of the submission. At best, the "edit summary" for anything I've ever contributed to a Talk page would always be "I'm making a Talk page contribution," which I never write into that field because I feel it would be redundant to write it every time I contribute to a Talk page.

So when contributing to a Talk page -- I know you're wondering, I leave the Edit Summary field empty, and feel like a radical.

The conflict leaves me feeling unnerved every time I'm asked for an Edit Summary on a Talk page. I always say to my LCD screen, "Duhhh; My Edit Summary is that I'm submitting an idea." That would be my edit-summary, for any Talk page for any article.

Therefore, I'd like to propose removing the effectively-redundant request for the Edit Summary for contributions being appended to Talk pages. Thanks.

Nei1 (talk) 19:55, 6 July 2016 (UTC)

@Nei1: Sounds like you may have "Prompt me when entering a blank edit summary" option enabled at Preferences->Editing. Try unchecking that box. If that's not it, I'm clueless; I don't get anything like that when I leave editsum blank, on the article or its talk page. ―Mandruss ☎ 20:03, 6 July 2016 (UTC)

The principal purpose of an edit summary, whether for an article edit or a talk page edit, is to communicate with other editors. It's mostly going to be seen by other editors of the article when they look at their watchlists; keep them in mind as your target audience. Ideally, you're trying to help them figure out if the edit you've just made is something they might be interested in reading or responding to. Even if you don't reproduce the entire content of your post, you should be able to offer a hint about the topic, information, or opinion you're bringing forward.

A useful secondary purpose is in helping to locate particular comments when looking at an edit contributions list (your own or someone else's), for example when you want to follow up on a question you've asked, or to see how a debate was resolved, or just to refresh your memory about what you've been working on on Wikipedia. (And you're quite right that writing "I'm making a talk page contribution" is totally superfluous and entirely useless for accomplishing either purpose.)

So, looking at your last couple of talk page edits, you might be able to use edit summaries along the following lines:

• wording: "five times closer" versus "one-fifth the distance"
• Any plans to rebuild WTC transmitter?

...And so forth. In both instances, someone looking at the edit summary would know what you were talking about (approximately) and be able to judge with reasonable accuracy whether or not it would be useful for them to look at what you just wrote. TenOfAllTrades(talk) 19:29, 7 July 2016 (UTC)

That's possible, and Nei1 might like that suggestion, but the most common thing to do in such a situation is to instead use "reply" or "comment" (often abbreviated "r" or "c") for such edit summaries. WhatamIdoing (talk) 20:35, 7 July 2016 (UTC)

My style is to answer the question that was asked, which was about the technical issue. Otherwise I might have also gone into editsum philosophy. Applicable reading includes Help:Edit summary and Wikipedia:Editsummarisis. ―Mandruss ☎ 06:34, 8 July 2016 (UTC)

Self-destruction of 'Merge to' templates?

We have a considerable number of articles with 'merge to' templates that are now several years old (based upon the date listed in the template). These are cluttering up the lead without generating any activity. Could these be cleaned up after some period of time by a bot that migrates the suggestion to a section on the talk page? I.e. x months after the template is added, a bot looks for a matching "Discuss" section on the talk page. If it doesn't find one, then a boilerplate section is added listing the suggestion and the person who posted the template. The bot then removes the 'merge to' template from the article page. Praemonitus (talk) 19:04, 23 June 2016 (UTC)

• This suggestion has been made before, and generally the response is: "just because there's no discussion doesn't mean it's a bad suggested merge". If you think those pages shouldn't be merged, and there isn't discussion, just remove the tag. --Izno (talk) 19:12, 23 June 2016 (UTC)
  • And if you think that it's a good idea to merge them, then merge them! Most of the old proposed merges are languishing for lack of someone willing to do the work of merging them. WhatamIdoing (talk) 21:33, 25 June 2016 (UTC)
    • I don't believe that the opinion of one person regarding whether a merge should take place should take precedence over the style and usability of the article. If no merge has taken place, the talk page is a perfectly suitable location to put the suggestion. It should not be cluttering up the article lead indefinitely, detracting from the overall appearance and readability. There is, after all, no actual issue being expressed regarding the article content. Praemonitus (talk) 22:36, 28 June 2016 (UTC)
      • Do you mean that the opinion of two editors (the editor making merge nomination plus the editor implementing it) is insufficient to make changes to articles? I don't believe that you'll get general agreement on that. WhatamIdoing (talk) 20:55, 1 July 2016 (UTC)
        • A straw man argument? No that is not what I meant. If no other editor ever agrees with the opinion of the first, then the tag can still remain there indefinitely. There is no agreed upon mechanism for its removal. Praemonitus (talk) 22:03, 1 July 2016 (UTC)
          • That wasn't a straw man argument; this isn't an argument of any kind, and he was asking a question about what you meant. I also thought the wording was slightly confusing. KSFT^C 22:19, 1 July 2016 (UTC)
            • "If no other editor ever agrees with the opinion of the first" is exactly what I'm talking about. You can be that "other editor". If you "agree[] with the opinion of the first", then we're talking about two editors who agree that the pages should be merged. In that case, we are not talking about "the opinion of one person regarding whether a merge should take place" (your comment at 22:36); we are talking about the opinions of two editors at that point.
              If a merge has been proposed for "several years" (your first sentence), with nobody objecting enough to remove the tag or caring enough to comment on the talk page during all those years, then the agreement of the only two editors who cared enough to get involved (again: Editor #1, who proposed the merge, and Editor #2, who agreed with the proposal), then you shouldn't move the tag to the talk page and hope that a lively discussion about the merge will start. In that case, you should just boldly merge the pages. (Or boldly remove the tags entirely, if you disagree.) WhatamIdoing (talk) 00:32, 2 July 2016 (UTC)
              • If the merge has never occurred, then there is no editor #2 involved. All you've got are visitors who may or may not agree with the suggestion, but are distracted from their reading by the inert tag at the top of the page. Without a merge, it's only the opinion of the person posting the original tag that matters. On the other hand, if you don't care for the tag then boldly remove it without agreeing or disagreeing, you would seem to be in violation of WP:Civility. Praemonitus (talk) 21:08, 3 July 2016 (UTC)

I don't feel like we're managing to talk about the same thing. So here's a simple example:

• I (=one editor) propose a merge of Example and Related. It sits ignored for years.
• You (=one editor) eventually see the tag and believe that a merge is a good idea.
• Using normal counting numbers, do you and I constitute "one editor" or "two editors"?

WhatamIdoing (talk) 18:51, 7 July 2016 (UTC)

Yes, definitely some talking past each other going on. I understood Praemonitus comments to mean:

• Someone propose a merge of Example and Related. It sits ignored for years.
• Some other editor comes along years later and sees no discussion or anything pertaining to the merge has occurred and not only disagrees with the merge but is annoyed by the clutter of the ignored merge tag.

In that scenario, is the second editor justified in being WP:BOLD to remove the tag? Or for more cautious or gun-shy editors, is the alternative to simply tolerate the visual clutter? older ≠ wiser 19:10, 7 July 2016 (UTC)

That question is answered in the last bullet point at WP:MERGECLOSE in the "General advice". WhatamIdoing (talk) 19:17, 7 July 2016 (UTC)

That entire process is contingent on their being a discussion. What about the case of an editor performing step 2 only? Praemonitus (talk) 19:26, 7 July 2016 (UTC)

No, it isn't: "If the proposal is obvious...then a discussion need not even be held." MERGE is not AFD. It's not supposed to be a bureaucratic process with checks and balances and careful consideration. It's basically a plain old edit, which any plain old editor can undo with the plain old WP:UNDO button.

The last bullet point says "If there is a consensus against the merger, or, for older proposals, if there is no consensus or no discussion and you don't believe it is appropriate to merge the pages, then please remove the merge proposal tags, and, if necessary, close any discussion." For your convenience, I've highlighted the three words that you accidentally overlooked. WhatamIdoing (talk) 20:32, 7 July 2016 (UTC)

Yes, it's well concealed in the last part of the last entry in the final box near the last section, and still doesn't address my concern. Ah well. Thanks. Praemonitus (talk) 14:57, 8 July 2016 (UTC)

Yes thanks, that's close to what I meant. What I was proposing is why can't that template then be migrated to the talk page as a boilerplate discussion? The reasoning being that the idle template clutter is doing more harm than good, but the concept can still be preserved on the talk page. Even if somebody then comes along later and adds a merge template back in, they will then have a discussion to reference and some history to view. Praemonitus (talk) 19:21, 7 July 2016 (UTC)

If you think that the merge idea is a poor one, then it's much better to remove the tags entirely, rather than sticking them on any page. WhatamIdoing (talk) 20:29, 7 July 2016 (UTC)

That's not what I'm saying either. I'm not expressing any particular opinion on the merge; to me it's just useless defacing of the article. Discussions of that nature belong on the talk page. Praemonitus (talk) 14:57, 8 July 2016 (UTC)

• Writing as someone who has done a lot of merges, many merge tags generate no discussion, sometimes for years. In these cases, an editor needs to make an evaluative decision. Is the merge an inherantly good suggestion? If no, then remove the tag. If yes, then leave the tag, regardless of how long it's been on. Remember there is no deadline. You should also consider doing the merge yourself, if you find time. --NickPenguin_(contribs) 16:42, 10 July 2016 (UTC)