Jump to content

Wikipedia:Village pump (idea lab)/Archive 16

Add links
From Wikipedia, the free encyclopedia
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

Rehashing an old idea - Maybe a "Comment committee" to deal with content?

One of our biggest problems is, of course, how to deal with content disputes. ArbCom cannot do that, and we don't have any sort of other body which can. I know there has been regular discussion about how to develop such a group, but I am not so sure anything specifically like the following has been discussed. Of course, maybe, if it hasn't been discussed, it might be because it is simply a dumb idea.

Anyway, I was wondering whether anyone thinks this might be workable:

We elect a committee of individuals whose specific job it is to try to respond and address concerns raised regarding content. This group will be in no way able to enforce its own opinions, but the individuals in the committee will be free to take part in RfC's regarding the topic just like anyone else.

The specific duties of the members of the committee would be:

  • 1) To try to determine, based on the existing independent reliable sources, the number and variety of articles and sections within articles relating to a specific topic.
  • 2) To consult, where appropriate, recent reference sources, including college level or higher textbooks, academic journals, etc., to help the community determine the existing academic consensus, or, if there is no consensus, significant range of opinion. Clearly, for at least some topics, like those of the breaking news type, this would have to be structured somewhat differently.
  • 3) To provide information based on those sources regarding relative weight given the various related topics in those sources.
  • 4) To present the findings of this research to the community as a whole before starting RfC's on the various up to that point intractable issues.

The committee as a whole would, presumably, be made up of people willing to spend time finding as many sources as they can relative to a topic who would also, hopefully, like ArbCom members, be willing to recuse themselves to a degree from the final preparation of sources and material if they believe themselves to be biased.

The group would, effectively, function as a "research committee", trying to find the better reliable sources where that's appropriate, or otherwise as many sources meeting RS as possible. Where encyclopedic articles exist, the structure of them would be found and indicated to the community.

But, I think, basically, in at least a lot of the problematic cases I know of dealing with religion related topics and history related topics, one of the big questions is not the one most generally asked, which is how much material on what topic is to be included in one article, but how many articles can and should we have to deal with all the encyclopedic content which we could reasonably have to include it all.

Maybe, if possible, making the members of such a committee individuals elected to serve there by the community and required only to spend half their time or less, in some sort of rotating shifts, might be optimal. Or, alternately, maybe indicating that individuals getting access to the databanks through the Wikipedia Library are expected, to so degree, to help out by checking what material relating to the topic is available through the databanks they have access to.

Anyway, thoughts? John Carter (talk) 17:14, 26 December 2014 (UTC)

I'm not sure I fully understand what problem this committee is designed to solve, could you clarify on that? Sam Walton (talk) 19:56, 26 December 2014 (UTC)
This was actually prompted by a proposal by one of the arbitrators at a current arb case, at Wikipedia:Arbitration/Requests/Case/Landmark Worldwide/Proposed decision#Additional eyes invited, to deal maybe a bit more effectively with instances where there may (or may not be) some reason to think that the editors actively involved in a given topic may be at a point of dispute over content, including perhaps problematic questions regarding content that something beyond a simple RfC might be called for. I have a feeling, actually I know, that this particular arbitration case is not the only one to ever exist where there is reason to believe that the individuals involved might need some outside help. It would also apply to instances where there seems to be some sort of serious, perhaps unbalanced, POV problems. Basically, getting together a group of people of some size to review the full range of sources available independently, and then present in as unbiased a way possible all the sources and content for an RfC, might be one of the few ways to really solve some of the content problems of this type. John Carter (talk) 20:13, 26 December 2014 (UTC)
I think I understand now, and this is an interesting idea. What do you think to the committee being created on a case-by-case basis rather than being one elected committee for all content disputes? I envision something similar to WP:3O where users post about their dispute but when, say, 5 editors have said they'll review the article/sources, they carry out what you envision the committee doing. Just a thought. Sam Walton (talk) 20:24, 26 December 2014 (UTC)
Just to add to the mix... it's one thing to have an outside body (as opposed to article regulars) fret about articles with 10 views per month, and another about articles with over 1,000 per day. If a list of articles with 1000+ daily views were generated and sorted into mega-categories, an outside panel could review them in some sort of reasonable system. One possibility would be that Jan = Literature month; the panel could select from articles nominated for review, with the top 5-most viewed articles being considered automatically nominated. Such a review might breath fresh air into established articles with a small set of regular watchers, and that in turn might help combat both bloat and staleness. NewsAndEventsGuy (talk) 21:10, 26 December 2014 (UTC)
Personally, I would like to see, maybe, some sort of semi-official request for such a group to be called into a given topic area. But, of course, there's nothing to rule out the possibility of non-controversial requests, maybe on a month-by-month basis with no pressing concerns elsewhere, being made and acted upon. And any sort of request proposal at AN or ANI might be sufficient to start such activity, including potentially for non-controversial topics or areas or broad areas which include a smallish area of controversy. Also, honestly, I think somehow getting the editors with Wikipedia Library databanks access to maybe have some sort of expectation to spend at least a little time once in a while on major topics that haven't gotten a lot of attention wouldn't be a bad idea. John Carter (talk) 21:21, 26 December 2014 (UTC)
Honestly? Most members of the ArbCom insist that they don't make rulings over content, and I suspect that some of them may even believe it. In practice, however, when they want to make a content ruling they are perfectly capable of doing so. The easiest way is to reframe the content dispute as a user conduct matter. The reformulation is pretty straightforward; it can go something like "User:X has engaged in persistent, tendentious editing on topic Foo, in violation of WP:NPOV." Slap a topic ban on the worst actors (especially those on the wrong side of the content dispute), maybe blanket the area with discretionary sanctions, and boom!, you're done. One content decision disguised as a conduct issue. Despite that sort of...fudging...about their scope, the ArbCom usually doesn't do too badly on this sort of thing.
Further, I'd say that our editor and admin corps have matured (perhaps I should say "have gained sufficient experience") with tools like WP:AC/DS, WP:FTN, and WP:RSN, and with policies like MEDRS and BLP, that content disputes that would have simmered for years half a decade ago now get resolved relatively quickly. We either have specific 'case law' already in many contentious areas, or we've been around the loop enough times that experienced editors can read the writing on the wall and see where a dispute is going to end up without having to reinvent the wheel.
As to the composition of the committee, I am very concerned that we would be able to find individuals with an adequate mix of social aptitude and specific subject matter expertise. We would have to consider very carefully what effect this type of committee is going to have on the willingness of, for example, genuine experts to contribute to the project.
Last, I do wonder if this is likely to prolong disputes rather than resolve them. It's another bite at the apple, another layer of appeal, another chance to ask the other parent. The monomaniacal fringe proponent wearing down the mainstream editor through persistent, time-consuming, civil POV-pushing is already a weak point for us. Bluntly, it's usually the single-track wingnut who has the most time to dedicate to a specific article and associated disputes, and this type of committee would be handing them a golden soapbox and inviting a rehash of every issue ever archived from an article talk page. TenOfAllTrades(talk) 21:41, 26 December 2014 (UTC)
Valid concerns. Once again, I note that the initial proposal was only to deal with cases where ArbCom, or, perhaps, ANI or others, to call in additional input and perhaps a clearer review of the relevant sources. And, again, at least in the initial proposal, it was not to necessarily decide anything, or create a body which would decide anything. Just a group of editors who might be able to provide a clear basis for others, probably through RfC, to review relevant material and come to conclusions, with at least a reasonable basis for assuming that information isn't being intentionally withheld or overlooked. I acknowledge that there are lots of topics which we probably have comparatively underrepresented relative to, say, Encyclopedia Britannica. Just look at the macropedia and see all the material it contains we don't yet. In probably rare cases such a body or group or whatever might find itself lacking for requests, but, honestly, given the number of contentious topics we have, I can't think that would happen very often. And, in the event I didn't make this clear earlier, I don't see the group as having any authority or powers beyond those of anyone or everyone else who might respond to one of the expected RfCs, although, perhaps, they might be in some cases better informed on some of the extant material out there. John Carter (talk) 21:49, 26 December 2014 (UTC)

Featured articles and candidates are subjected to a review somewhat akin to this proposal - seems to me this would build on that process for the benefit of high traffic articles that are not (yet) at FA status. NewsAndEventsGuy (talk) 23:07, 26 December 2014 (UTC)

I could certainly see, if the kinks were worked out, trying to somehow get people involved in this involved more regularly in FAC and similar discussions. In fact, ultimately, I would hope that happens. But I think it might be best to maybe start it on a smaller level, so that any problems which might arise can be identified and maybe dealt with early on in single cases, rather than find after a few months that one unanticipated problem has created difficulties in any number of already ongoing discussions. John Carter (talk) 18:26, 27 December 2014 (UTC)
Doing a Pilot experiment is a great idea.NewsAndEventsGuy (talk) 21:27, 27 December 2014 (UTC)

Followlist

The universe of Wikipedia contributors is vast, and they are clustered in galaxies according to their shared interests. To communicate with one another, users typically edit and watch each other's talk pages. SomeUser will create or edit a page that is not being watched by some significant others, and will then perhaps have to "ping" those others on one or more talk pages in order to let them know about it. That has worked well over the years, of course. But in Wikipedia's expanding universe, communication and collaboration ought to be a whole lot simpler and more efficient. So, when viewing a User page, I'd like to see a Follow/Unfollow option next to the normal Watch/Unwatch. And I'd like to have a Followlist in the exact same format as my current Watchlist, but listing page edits by the users that I am following. Jonathan Lane Studeman (talk) 07:41, 20 December 2014 (UTC)

Great idea. I've often thought the same thing, not about editors I trust, but about those I don't. It would be good to know if the spammer that appeared to give up has returned to spam again. Oiyarbepsy (talk) 07:45, 20 December 2014 (UTC)
It's quite true that it can be used positively against vandals and the like, but I'm afraid it will also inevitably feed Wikihounding. Just like in the real world, many people here hate being stalked. So, my opinion is oppose, sadly. Zhaofeng Li [talk... contribs...] 10:17, 20 December 2014 (UTC)
How about a simple option in Preferences to disable the ability of others to follow you? Jonathan Lane Studeman (talk) 12:24, 20 December 2014 (UTC)
Actually, now that I think about it, there's actually a much more elegant and vastly simpler two-part solution: Make mutuality a requirement. A) When SomeUser visits SomeOtherUser's page and clicks "Follow," he/she goes automatically onto the other's Followlist and the other is notified; and B) When SomeUser visits SomeOtherUser's page and clicks "Unfollow," he/she automatically comes off the other's Followlist and the other is not notified. Then, if SomeUser puts SomeOtherUser onto his/her Followlist after having been taken off, the other could simply report this as Wikihounding, and it could be dealt with in the normal way. I believe this or some other reasonable method of dealing with abuse could work very well; and I believe the benefits of allowing users to follow one another (whenever the desire is mutual, of course!) would far outweigh the potential for abuse. Jonathan Lane Studeman (talk) 13:02, 20 December 2014 (UTC)
Um... Good thinking. There's one flaw though: What if user A is interested in B's edit (and B agrees to be followed), but not the other way round (i.e. B does not want to be spammed by A's edits)? Mutuality isn't always possible. Moreover, what edits are displayed on the list (Many "interesting" editors here make hundreds or even thousands of edits a day)? Zhaofeng Li [talk... contribs...] 13:15, 20 December 2014 (UTC)
By the way, professional stalkers can already use the anonymous Atom feed to track one's edits with a feed reader (e.g. [1]). Zhaofeng Li [talk... contribs...] 13:23, 20 December 2014 (UTC)
Offhand, I'd suggest that mutuality is sufficiently important that we should just accept the limitation that User A won't be able to follow User B unless User B wants to follow User A. There are already other ways to follow someone; ways well known to Hounders, for example, as you noted, such as manually listing the other user's contributions. A Followlist would just be much easier to use since all of one's follow-ees would be listed on one page. As for one's list being spammed by the hundreds or thousands of edits from heavy users, Watchlists already deal with potentially massive numbers of edits when it comes to high-use pages, and if needed I suppose a filter could be applied so that only the recent-most several edits by any one user appear on the Followlist. Jonathan Lane Studeman (talk) 13:28, 20 December 2014 (UTC)
The watchlist (the web version, not the Atom feed) only displays the latest edit of a page, which is often "a tip of the iceberg" for high-volume pages. The usefulness of the Followlist is significantly reduced (if not useless) when filtered in this way. Zhaofeng Li [talk... contribs...] 13:41, 20 December 2014 (UTC)
I agree. But the Watchlist in earlier MediaWiki versions used to display every single edit of a watched page for a User-defined number of days, didn't it? That had to change, of course. But I wouldn't recommend filtering down to just the most recent edit. For myself, I might like to have, at most let's say, 20 Users on my Followlist, and have the list set to show only the 20 most-recent edits (of different pages) by each (and no more than the recent single edit of any one page by any one editor). The idea is to just to reveal who is editing where. If I need to dive in further I can visit the pages being edited and inspect the history. Jonathan Lane Studeman (talk) 13:52, 20 December 2014 (UTC)

It's still a tip of the iceberg. To elaborate, the watchlist is useful as it successfully solves the question of "Has the page been changed?". The followlist can solve the problem of "Has user A edited today?", but not "What has user A edited?" which is its main purpose. Zhaofeng Li [talk... contribs...] 13:57, 20 December 2014 (UTC)

Not so, actually. The Followlist would show what pages people are editing, and would link to what those edits consist of. In fact, what I'm suggesting is that the exact same citation format that is used on the Watchlist be used also on the Followlist. E.g.,
  • (diff | hist) . . m Some_page_name‎; 23:34 . . (-1)‎ . . SomeUserName (talk | contribs).
The only difference would be that the list shows edits made by those on your Followlist rather than edits to pages on your Watchlist. Jonathan Lane Studeman (talk) 18:08, 20 December 2014 (UTC)
Um, there are two limitations now: 1) The requirement of mutuality makes the list unusable against vandals, unless you can acquire willing participation of them (Does that make sense?) 2) Only recent pages edited will be displayed, making it unable to track the edits of active users (Many of them edit tens of pages a day, and vandal fighters often edit hundreds of them). So the only use-case for this is for mentoring/adopting new editors who don't edit that frequently, but examining one's contribution page manually provides more detailed information. Manual examination is also relatively convenient, considering the number of adoptees a mentor may have is small. Zhaofeng Li [talk... contribs...] 01:33, 21 December 2014 (UTC)
About "willing participation", see Evil bit which is an interesting read. Wondering if we can implement it here though: Vandals and the like can be asked to tag their edits with "vandalism" in the edit summaries, so that we can revert all vandalism at an 100% hit-rate! Just joking. Zhaofeng Li [talk... contribs...] 01:40, 21 December 2014 (UTC)
Excellent points! I'm sure that a Followlist would be a wonderful tool for mentoring new users. But that is not the only use-case, and is not even the primary use that I had in mind. I see this as simply a way to automate communication and collaboration within dynamic groups of users who share common interests. (Friend, Un-Friend, and Friends_list might be another way to name what I have in mind.) When SomeGoodUser comes across interesting pages needing improvement, surely the friends of SomeGoodUser will be interested, too. So why not automate the tip-off and the links to specific edits that otherwise depends on SomeGoodUser manually editing a whole bunch of Talk pages, composing emails, and pinging friends? I agree with you that a requirement for mutuality means this idea would be nearly useless for monitoring the behavior of vandals. However, A) I think we, and especially administrators, already have the tools needed for that; and B) any tool created to enable a random "good" user to do something that a "bad" user does not want done (in this case, follow him around) would by definition enable the bad user to do something that the good user does not want done. All swords are double-edged! So, again, that's not what I had in mind. With their consent, I would simply like to see the recent edits by chosen members of my circle of trusted collaborators listed on one page, my personal Followlist. That way, I'll have automated access to information that my current Watchlist simply cannot provide, such as new pages being created by my friends, or recently created or discovered pages being newly edited by my friends. Jonathan Lane Studeman (talk) 10:52, 21 December 2014 (UTC)
  • Comment by NAEG -

Any ed can already monitor my contribs manually. The ed who does that might have honest reasons or abusive ones. If I understand the proposal, it would just make contrib monitoring easier by combining contrib searches for multiple eds into a WP:Others' contribs watchlist (bearing the inevitable shortcut WP:StalkerList). Would that improve the project? I have mixed feelings on that point.... does it encourage honest people to get together more or would it turn turn honest people into POV cabals? Certainly it will encourage the quiescent wikihounds and stalkers to get become more active in their abuse. The already-active wikihounds are already active, so while that group might appreciate this move, the proposal's impact on the active wikihounds should be moot. If I understood it right, so far I think I oppose. PS, If I allow X to follow me, but deny Y, won't that info be used against us at ANI/AE? NewsAndEventsGuy (talk) 12:23, 21 December 2014 (UTC)

If I understand correctly, you are suggesting that enabling, say, climatologists to conveniently follow each other's postings shouldn't be done because this would enable wikihounders, proselytizers and other ne'er-do-wells to form their own groups and follow each other's postings. I suppose it's true some would do that, but is this really any different from suggesting that climatologists should lose the ability to conveniently watch the changes that are being made to climate-related to pages because hounders, proselytizers and other ne'er-do-wells are conveniently watching those changes also? Any feature can be abused. And if a vandal is following the posts of another vandal, is that really something a need to worry about? I would favor sanctions for vandalism itself rather than restricting capabilities that are designed to improve communication and collaboration overall. Jonathan Lane Studeman (talk) 13:12, 21 December 2014 (UTC)
Very few real climatologists have time to do wikipedia.... and the mere mortals who are regular editors of that or any other topic already have the major pages watchlisted. The advantage to this would be to let them know when a new page is launched... but don't we already find out anyway? The feature I would like to see is the ability to limit watchlist returns to specific categories. That would let regulars of Topic X see all the changes, including new pages, in the category, whether the individual pages are watchlisted or not. I suppose some will try to game the system by adding inappropriate (read "spam") categories to their pet articles, but whatever. Following the cat is very different than following the person. NewsAndEventsGuy (talk) 14:37, 21 December 2014 (UTC)
Perhaps climatologists was a bad example. How about, mortals who are "friends or share a common interest in ((you name the subject))." The advantage is not just regarding new pages, but regarding newly discovered pages and interesting topics on old but unwatched pages, including administration pages like this one. Don't we find about about these things anyway? Yes, we do. That's the point. We find out because those who share our interests communicate with us. They must "push" the info our way, typically using User Talk pages. But okay. A template that "pings" everyone listed on one's personal User_Talk:SomeUserName/Followers page would do the exact same thing, essentially. Perhaps I'll write it if it doesn't already exist! Jonathan Lane Studeman (talk) 08:00, 22 December 2014 (UTC)
A+ for the sentiment, I would not oppose if there is strong support elsewhere.NewsAndEventsGuy (talk) 12:59, 22 December 2014 (UTC)
For topic-specific activities, we can follow Wikipedia:Article alerts in each wikiproject (if/once it's setup) for major assistance/input requests.
For broader coverage, the only real option (afaik) is to use an index page (where they exist) and the "Related Changes" (Special:RecentChangesLinked) tool, e.g. for meteorology.
I think that improving the topic-specific-collaboration tools, would be more useful and more well-received, than improving/creating user-specific-watching tools. --Quiddity (talk) 21:48, 22 December 2014 (UTC)
"improving the topic-specific-collaboration tools, would be more useful and more well-received" ... Yes! How to go about that? NewsAndEventsGuy (talk) 18:02, 26 December 2014 (UTC)
Abstractly, m:Grants:IEG/WikiProject X should help us understand where the effort should be concentrated to help make a wikiproject as useful as possible to all editors (more so, if more editors help give them feedback over the next few months).
Technically, there are a number of possibilities in the longer-term: Flow originally interested me because one of its aims is to make many types of workflow into modular and easily reproducible components, so that any wiki or wikiproject can easily setup things (reports/tasklists/request-systems/etc) that help get stuff done, without having to know a large amount about templates or bot-wrangling.
Also, some added power/complexity for the watchlist is overdue - the mw:Watchlist wishlist compiles most of those dreams, but changing anything in the existing setup is fraught with complication hence nothing has significantly changed in ages. Maybe 2015 will be the year that some folks dedicate a few months to truly chewing to the heart of that puzzlebox, and documenting what exactly we collectively and individually need/want, so that volunteer or staff devs can prioritize feature development.
There've been a few plans over the years for an easier/automated wikiproject discovery mechanism - a way for newcomers to be prompted to say "I'm interested and/or experienced in topic foo" - things from Wikipedia:Teahouse/WikiProjects to mw:GlobalProfile/design#Structured Profiles (and mw:GlobalProfile/Affiliation scratchpad), but nothing is currently active AFAIK.
In the short-term, we have to build on what we already have: templates+categories+bots+lists. They're complicated as heck (for many of us) to setup, but do they work well once running smoothly.
(I'm missing things and not giving enough detail on others. insert bleary flu-recovery disclaimer here) --Quiddity (talk) 20:52, 29 December 2014 (UTC)

Possible new way to create redirects

Although making a redirect is rather easy (you just blank the page and add #REDIRECT [[Article]]), there may be some who find templates to be smoother and easier. I happen to be one of those, so if we don't have it already, I've been thinking that we should create a template for redirects. For example, to create a redirect with a template, you might type something like this: {{subst:go-to|Article}}. (I chose "go-to" because the "redirect" name is already taken.) I have the rather basic code in my sandbox, if you want to look at it. --Biblioworm 19:45, 30 December 2014 (UTC)

I think I understand what you are saying, but I consider such an idea to not be very necessary. In the "Advanced" edit bar, there is even a button which automatically inserts "#REDIRECT". Dustin (talk) 19:48, 30 December 2014 (UTC)
I don't find {{subst:go-to|Article}} easier syntax at all, and as Dustin points out, a click in the edit bar is easier than both typed options. Sam Walton (talk) 20:00, 30 December 2014 (UTC)
Perhaps it's a matter of personal preference. I also was unaware of the button on the advanced toolbar, so I guess it's not needed, after all. --Biblioworm 20:58, 30 December 2014 (UTC)
  • I wouldn't shoot down such an idea so quickly. This could be rather useful. Not everyone uses the advanced toolbar. Subst:ing a template would be easier than typing out the code in cases where you are also tagging it as "R to" or "R from" or any of those kinds of templates. — {{U|Technical 13}} (e • t • c) 21:27, 30 December 2014 (UTC)

Wiki Points

This probabbly sounds like the worst idea ever, but I think Wikipedia would be cool if editors could get Wiki Points so they can pay for stuff.

Like, you get 1 point for making an edit and an administrator could give or take points from you.

Maybe it could be like 200 points to nominate yourself for adminship or maybe it costs sone points for other things. 92.16.4.92 (talk) 22:54, 1 January 2015 (UTC)

You may be interested in Wikipedia:WikiCup. — xaosflux Talk 00:35, 2 January 2015 (UTC)
Oh. Thank you. 92.16.4.92 (talk) 02:08, 2 January 2015 (UTC)

I need WikiTube !!!

Hi,

The situation is like this - child does not know how to read and write, he asks to find something in YouTube, then video finishes and YouTube shows him the pictures of other videos related by keywords. So he then can continue to navigate from one video to another simply by mouse. He likes to watch interesting videos about real life that bring real information but if he at some moment clicks at animation cartoon link then YouTube gives him the links to animation cartoons or toys reviews and he rambles in this garbage. I really need right now something like YouTube but stuffed with really helpful videos that show how something works, some DIY videos, educational videos, etc., anything related to Wikipedia pages. For example, animation cartoon showing how watches work or video showing the DIY smelting furnace or process of making clay pots or multi-storey building, etc. The system should automatically find related videos and present them as pictures so user could navigate inside the content without using the keyboard at all. I would be glad to participate, help and donate for such system right now.

Alexey. — Preceding unsigned comment added by 121.211.246.141 (talk) 00:23, 3 January 2015 (UTC)

Commons has lots of videos. You can browse the categories, but navigation is rudimentary otherwise. -- [[User:Edokter]] {{talk}} 11:17, 3 January 2015 (UTC)

Wow! What a cool idea! It should be image based. Bit of work. Is there a sandbox where this is being developed right now? Can I volunteer my own sandbox to try things out? Chrislamic.State (talk) 22:27, 5 January 2015 (UTC)

Making wikipedia more accessible

Hi

I have an idea which may help improve the pages on Wikipedia, specifically the ones about scientific subjects.

My idea would be to have a simple and advanced page for each thing on here. For example, if you type in "black hole", it comes up with loads of equations about quantum mechanics and space time, which most people wouldn't be able to understand and they'd just stop reading.

You could have a basic introductory version of the page that explains black holes in a way that is more accessible to people. If then you wanted to read more, you could click on the "advanced" tab.

This would make Wikipedia a much better resource for kids and students.

Foot note:- After speaking with a Wikipedia editor, I have been informed there is a simple version of Wikipedia that already exists:- https://simple.wikipedia.org/wiki/Main_Page

With this in mind, perhaps a specific icon could be inserted at the start of each article which would send users to the simpler version of the page.

What do you think?

David Wardle — Preceding unsigned comment added by 213.205.232.226 (talk) 13:38, 9 December 2014 (UTC)

We do have this already with some articles. For example, see Introduction to special relativity. I'll propose this idea at Talk:Black hole. Oiyarbepsy (talk) 15:41, 9 December 2014 (UTC)
Simple English Wikipedia [2] is the place to make a simple version, its better to move Introduction to special relativity out. Mion (talk) 23:18, 18 December 2014 (UTC)
I believe that the people at the Simple English Wikipedia would say that their project is not for short or introductory material, but for material that is written using a limited set of vocabulary and a limited set of grammar structures. WhatamIdoing (talk) 19:20, 19 December 2014 (UTC)

Whereas I think that those difficult articles should have an "Introduction" section, written in plain terms. --NaBUru38 (talk) 15:27, 24 December 2014 (UTC)

If a reasonably complete and still non-technical description can be given in four paragraphs or less, then that would be fine. But when it can't, as in the example given, then another option needs to be considered. WhatamIdoing (talk) 18:55, 24 December 2014 (UTC)
This is an issue I've seen come up on several articles. Making articles more useful is a good idea. However, it's not clear what exactly "plain terms" "basic" and "introductory" mean. You could make things more simple by removing tensor equations, more simple by removing calculus equations, more simple by removing algebraic equations, and more simple by removing any numbers at all. I think you'd agree the last step is too far, but how do we reach consensus that the article is simple enough? What if someone wanted to make a basic, intermediary, and advanced version as well? Forbes72 (talk) 20:12, 8 January 2015 (UTC)

Geolocated template documentation

I was reading an entry at WP:TFM where an editor decried intricate templates with dozens of parameters that are used or are not used depending on where in the world the subject article lies. So, I was thinking that rather than having "one size fits all" template documentation, we could pull the editor's location from their browser and give the editor documentation tailored to their location. I realize that this would not be useful for those of us editing through a proxy, so there would have to be a location tree as well so you can find the right docs for the right location. –Fredddie™ 23:02, 1 January 2015 (UTC)

You seem to a assume that people only write articles about where they are. That would be a false assumtipn. Who do you think writes about lunar craters? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:49, 3 January 2015 (UTC)

Personal page to transfer into the main namespace

Hello, I am not a native English speaker, but I just want to bring to your attention the existence of User:JMiall/Louis Compton Miall since 2011. That would be worthy to transfer it into the main namespace (Louis Compton Miall). Regards, Totodu74 (talk) 23:55, 1 January 2015 (UTC)

@JMiall: : Ping to sandbox host. — xaosflux Talk 00:27, 2 January 2015 (UTC)
It isn't finished. It is partly in note/bullet point form and shouldn't be. There's also some text blocks I need to rewrite. Finishing it off would be a good new years resolution though... JMiall₰ 10:08, 2 January 2015 (UTC)

@JMiall: Give yourself some credit. Put it in article space now and you can finish it there. Oiyarbepsy (talk) 07:09, 10 January 2015 (UTC)

"Save to Draft" button?

To my mind, the failure to retain new editors is the biggest crisis the encyclopedia has right now.

At NPP, we see a lot of new editors creating pages they know aren't ready, either because they don't understand that "Save" makes the page public, or because they don't want to lose their work. Then these editors get discouraged when their pages are immediately speedied. Although we have plenty of drafting options (the Draft namespace, userspace, AfC), many new editors still aren't aware of them. For the sake of new editor retention, I'd love to see a "Save to Draft" button next to the "Save" button on the page creation window for (at least) non-autoconfirmed editors. The idea is not to make it any harder to save to mainspace (if that's what the editor wants to do) but to make the Draft option that much easier to recognize and take.

As the edit notice says, I'd like to get feedback that's more actionable than "Support" or "Oppose". Has this been proposed before? What do editors who've worked in Draft space think about it? Would it just make for a pile-up of bad pages in Draft? —Swpbtalk 20:46, 22 December 2014 (UTC)

I haven't given it too much thought yet but on the face of it this seems like a really good idea. A save button which puts the work in Draft space instead of article space could be useful for everyone, not just new editors (I'd probably use it). We've got Draft space now, but it's hard to use - needing to prefix Draft: to a title isn't intuitive to a new editor, and I agree that a save to draft button could really help. Sam Walton (talk) 20:49, 22 December 2014 (UTC)
Hmm, then maybe it would be best implemented as a user preference, on by default? —Swpbtalk 21:05, 22 December 2014 (UTC)
A preference which is on by default for new editors would make sense. That way experienced editors can turn it on if needed and new editors who don't necessarily understand namespaces would benefit. Sam Walton (talk) 21:37, 23 December 2014 (UTC)
Strongly endorse this idea. Brilliant, in fact. Honestly, I don't really see a lot of details that would need to be worked out to make this proposal, so you could have brought it up there. Oiyarbepsy (talk) 20:52, 22 December 2014 (UTC)
Thanks! Well, since I've already put it here, it might as well percolate for a bit; maybe tomorrow I'll move it over there. I'm a little gun-shy after seeing how apparently common-sense proposals can generate entrenched opposition, so I went with the lower-pressure forum first. —Swpbtalk 21:02, 22 December 2014 (UTC)
Sounds good. I suppose besides a "Save to Draft" button, you'd need an easy way to access and manage a list of "My Drafts", and when editing a page in Draft space, buttons for "Save to Draft" and "Publish" (meaning save to main space). Where would drafts be saved? Would they actually be in Draft space (i.e. public) or would they better be sub-pages of the user page (still technically public, but designated to the user)? Stanning (talk) 21:07, 22 December 2014 (UTC)
They would be in Draft space, which is not really "public" — draft space is not indexed by search engines, or accessed by "random article", for instance. —Swpbtalk 13:19, 23 December 2014 (UTC)
I might support such an idea, but only if the editor was registered. I assume that is what your aim was. Just to be sure that I understand your goal, where were you planning on having these "drafts" saved? Just under the person's account, perhaps? Dustin (talk) 21:09, 22 December 2014 (UTC)
As it is, only registered editors can create pages; I have no desire to change that. —Swpbtalk 13:19, 23 December 2014 (UTC)
"these editors get discouraged when their pages are immediately speedied" Then perhaps we should encourage the admins concerned, rather than deleting, to move them to user/ draft space and notify the editors concerned, using a template which includes links to tutorials and the teahouse? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:42, 23 December 2014 (UTC)
Doesn't the button seem way easier than that? I mean, we should be doing that already; the key word being "should". —Swpbtalk 13:14, 23 December 2014 (UTC)
These aren't mutually exclusive ideas - though the button would be easier for having avoided the situation in the first place, the point that admins should consider draft/userfying is a good point, one I'm sure many of us don't consider. Sam Walton (talk) 21:33, 23 December 2014 (UTC)

User draft or Articles for Creation

In my view, the save to draft button should create a userspace draft, without being tagged as articles for creation. I don't think new editors would be expecting Articles for Creation (they probably don't know what it is), so a user draft would be better. Oiyarbepsy (talk) 07:19, 10 January 2015 (UTC)

Oiyarbepsy, I agree that the users shouldn't be directed to WP:AFC, which is designed for brand new users. This change is intended for autoconfirmed editors who want to create an article. Draft space is not just for AfC, which affects only those draftswhich have been created through Wikipedia:Your first article or those who have asked for a review be adding a submit template to their draft. The other pages in Draft are similar to userspace drafts, except that they are more likely to be found by other editors who want to collaborate in making an article. My suggestion of having the page creation invitation say "You may create the article 'Flibberty' or you may start/improve the draft article 'Draft:Flibberty'" is intended to help editors notice if there is a draft already in progress, to prevent duplication of effort. —Anne Delong (talk) 00:53, 11 January 2015 (UTC)

Next step?

There seems to be broad agreement here. Do you feel like we need a more formal consensus, or can we move ahead with implementation at this point (as an on-by-default user preference)? —Swpbtalk 13:53, 24 December 2014 (UTC)

This would need consensus since it's a substantial change, but it's not ready for that yet. This would have either to be integrated into WP:AFC, which would need discussion, and keep in mind that AFC is severely backlogged already; or we would need another way to check non-AFC drafts, but we don't have new draft feed yet (cf Wikipedia:WikiProject Articles for creation/RfC to create a 'Special:NewDraftsFeed' system), and even then this would have to be integrated with mainspace NPP, otherwise those new drafts would be unattended. Cenarium (talk) 17:26, 24 December 2014 (UTC)
Also, as a note, I added a while ago a link to the article wizard (which gives an AFC / draft option in the end) to the mediawiki page presented to unregistered users when they try creating a non-existent article, see Template:No article text. I should point out that this edit generated on its own a significant increase in AFC submissions. We could mention AFC in the text presented to registered users too (but it would be all of them), if AFC is able to handle the increase in workload. Cenarium (talk) 17:38, 24 December 2014 (UTC)

See above - It also needs more clarity as to exactly what the proposal is. Is this an AfC submittal, a user draft, or something else? Oiyarbepsy (talk) 07:20, 10 January 2015 (UTC)

As I understand the proposal, it's not about AfC, it's for a change to MediaWiki or some layer on top of MediaWiki (I'm not familiar with how Wikipedia works under the hood). It'd be like what almost all of us have when we create or edit an e-mail or text message: beside 'Send message', in most software there's an option 'Save to draft' which stores the message in a Drafts folder where you can come back to it later. In e-mail/texting, this is well understood. Similarly, in Wikipedia when creating or editing a page, beside the buttons 'Save page', 'Show preview', 'Show changes' and 'Cancel', for registered users there could be a button 'Save to draft' which would save the article in Draft space, leaving the mainspace article (if any) unchanged.
I think this wouldn't be user-friendly by itself – we'd need some complementary changes:
  • A 'My Drafts' facility to list the user's articles in Draft space.
  • A change to the UI when editing an article in Draft space: the buttons would say 'Publish' (instead of 'Save page', meaning save to Main space and delete the draft), 'Save to draft' (meaning save back into Draft space) and the same 'Show preview', 'Show changes' and 'Cancel'.
  • A way to manage articles with the same name in Main and Draft spaces:
    • What happens when you 'Publish' a draft article with the same name as an existing Main space article? Perhaps a warning so that you have to click Publish again to confirm, like the existing warning when you save with no edit summary?
    • What happens when you click on a red link in Main space where an article with the same name exists in Draft space? Perhaps a warning like what you get when the article has previousy been deleted?
Maybe other aspects that I haven't thought of so far ... Stanning (talk) 13:08, 10 January 2015 (UTC)
Why do we need a "Show changes" button for a new article? --Ahecht (TALK
PAGE) 19:41, 13 January 2015 (UTC)
We don't – but there is one! Try creating an article, and you'll see. Why's it there? Beats me ... Stanning (talk) 16:22, 14 January 2015 (UTC)
  • Rather than have an extra button next to the "Save" button, it may be better to change the sentence at the top of the original search result page. Right now it says: "You may create the article 'Flibberty"". Instead, it could say on of two things. If there was no draft about the topic, it col;d say "You may create the article 'Flibberty' or you may start a draft article, 'Draft:Flibberty'". If, on the other hand, there was an existing draft already, the message could say, "You may create the article 'Flibberty', or you may improve the existing draft article 'Draft:Flibberty'" I think this would be an easier change to make software-wise, since it would require only (1) a check for the existence of a draft, and (2) changing a sentence based on the result. Even this complication could be done away with by just saying "You may create the article 'Flibberty' or you may start/improve the draft article, 'Draft:Flibberty'" (which would be a red or blue link according to the existence of a draft). However, this would likely mean a very large number of draft pages would be created, so either we'd need a way to attract experienced editors to deal with them (sounds like AfC, doesn't it?), or we'd need a really easy way for the draft creators to move their drafts into the encyclopedia, or both. —Anne Delong (talk) 13:41, 10 January 2015 (UTC)
  • This is a really good idea. Anne's idea is also very good, and much easier to implement as it doesn't take major software changes. As such, I would suggest starting there. --ThaddeusB (talk) 17:17, 10 January 2015 (UTC)
  • Anne's idea is rather good, But for the rest of the dicussion, some caveats ought to be entertained: Drafts , in the main concept of AfC, are often articles made by non registered users which constitute the only user group that is not allowed to create new articles directly in mainspace. Although Wikipedia is the encyclopedia anyone can edit does not read as Wikipedia is the encyclopedia where anyone can create an article (in mainspace), according to the reasons for which very senior members of the Foundation staff vehemently rejected WP:ACTRIAL, any further limitations to article creation would conflict with a Wikimedia core policy that individual language Wikis (e,g, en.Wiki) are not permitted to interfere with. Leading all registered editors by default to first create in the Draft mainspace or elsewhere would most likely conflict with that policy just as much as insisting that only autoconfirmed editors can craate new articles in mainspace. Bearing in mind also that again based on the outcome of WP:ACTRIAL any Foundation dev can apparently unilaterally decline/reject community consensus for changes to MediaWiki software. --Kudpung กุดผึ้ง (talk) 00:04, 11 January 2015 (UTC)
Kudpung กุดผึ้ง, (or whoever knows), I never tried to make an article before being autoconfirmed, so I have to ask, what does the brand new user or IP editor actually see that's different when they type a non-existant page name? Does it say "You may create the page...", or is that part missing? If it's missing, then unconfirmed users will not be affected by my idea of adding a second option to save to draft at this point. Also, giving registered users a choice, with the article choice first, is not really "leading" them to create drafts, just letting them know about an option that already exists.—Anne Delong (talk) 00:16, 11 January 2015 (UTC)
  • Anne, An IP editor is immediately redirected to AfC. ALL other editors see this:
  • Before creating an article, please read Wikipedia:Your first article.
  • You can also search for an existing article to which you can redirect this title.
  • To experiment, please use the sandbox. To use a wizard to create an article, see the Article wizard.
  • When creating an article, provide references to reliable published sources. An article without references, especially a biography of a living person, may be deleted.
  • You can also start your new article at Special:Mypage/Jingle slap. There, you can develop the article with less risk of deletion, ask other editors to help work on it, and move it into "article space" when it is ready.

And the last bit is completely wrong because is it should be reading 'Draft:Jingle slap' for a long time already. (Jingle slap was my invention for test purposes.) --Kudpung กุดผึ้ง (talk) 00:50, 11 January 2015 (UTC)

Kudpung, I am still not sure, but I am presuming from what you say that the unconfirmed users do see the "You may create the page whatever" text with the redlinked page name, and then are redirected in the way you mention above. I think that my idea to change the text to "You may create the article 'Flibberty' or you may start/improve the draft article, 'Draft:Flibberty'" would still work. If the new user selected the first option, they would be redirected as happens now. However, a little more software logic might be needed, because if the Draft article already existed the new user could be clicked through to work on it (no AfC needed) and if the draft was a redlink the redirection would happen. —Anne Delong (talk) 01:07, 11 January 2015 (UTC)
Anne, ALL registered users see the text above. If you wish to confirm it, create a legitimate new account for test purposes and you will see for yourself.
The last sentence of that text should be reading:
You can also start your new article at Draft:Jingle slap. There, you can develop the article without risk of deletion and it will be reviewed by other editors before being moved into "article space" if it is appropriate for the encyclopedia.
--Kudpung กุดผึ้ง (talk) 01:23, 11 January 2015 (UTC)
Now that you've confirmed that all registered users see the text, you have saved me from needing to create another account; thanks. If everyone sees the same text though, it needs to be written so that it's appropriate for everyone. The text you have written above (1) doesn't cover the case where the draft already exists, and (2) implies that all drafts will be reviewed before being moved, which is not true for autoconfirmed users - they can create drafts and move them when they want to, (3) isn't needed for brand new users, because if they click on the red link they are redirected to a page with plenty of explanation. I prefer the simpler version which I suggested, but will go along with whatever others feel is appropriate.
I also think that when a new non-AfC draft is created, it should have a template message at the top something like "This is draft is a work in progress and not an encyclopedia article. If you believe that it is ready to be moved to the main encyclopedia, you can ask for a review by experienced editors by adding "subst:submit" to your page. You can also move the page directly to the encyclopedia (link to the Move page); be aware that if the new article does not meet Wikipedia's policies and standards for inclusion, it may be deleted; you may wish to keep a copy of the text." That would cover the case of confirmed users, who then can choose to use or not use AfC, and experienced users can delete the template if they don't need it. —Anne Delong (talk) 01:59, 11 January 2015 (UTC)
You guys are talking about two different things. Anne is talking about the text above the search results whereas Kudpung is talking about what you see after clicking on the link in said text. (Either text is easily changed, I believe, as they are driven by pages in the MediaWiki: space, not the core software. Adding a "safe to draft button" would take fundamental software changes, I'd think.). --ThaddeusB (talk) 04:20, 11 January 2015 (UTC)
Actually, I don't think it matters either way until AfC in its current concept is finally scrapped and replaced with something more workable for the drafts and which generates more results and less permanent talk and tinkering with software. --Kudpung กุดผึ้ง (talk) 12:39, 11 January 2015 (UTC)
ThaddeusB, while it's true that these are two different pieces of text, both need to be taken into account so that any change is consistent. And while Kudpung is right to be concerned about AfC, which seems constantly plagued by a backlog, that shouldn't have a bearing on the relevance of this discussion, which is mainly about confirmed users who want to make drafts which are not part of AfC.—Anne Delong (talk) 15:37, 12 January 2015 (UTC)
While I support some form of this proposal, the issue I have is what happens after a user saves the article to draft space. Given the feedback I've seen from users at AfC (and the number of external websites that I've seen linking to drafts), it seems like many people who would create drafts would see that their article is up on a website, think it was published, and leave it at that. I think any proposal like this would also need some sort of banner automatically added to the top of all pages in draft space (except, maybe, for those with AfC banners) that say something like: "This is a Wikipedia draft page. This is not an encyclopedia article. If you feel this draft is ready for inclusion in Wikipedia, please move it or submit it for review." --Ahecht (TALK
PAGE) 15:56, 12 January 2015 (UTC)
This rather concurs with something I said very recently somewhere else (probably at WT:AFC or on a discussion concerning G13 abandoned drafts) that many who submit an article to AFC drop it in the lap of the rewiewers without any intention of returning in the belief that the article will then somehow go live.
It needs to be made clear to them that AfC is a review process, articles are not live, and that articles that do not meet criteria for inclusion will be declined, and then deleted after 6 months if not improved.
Thank you Ahecht also for pointing out that people are linking from outside to their Wikipedia drafts. This is something that hadn't crossed my mind but which is obviously inevitable. All the more reason why we should review submissions as quickly and briefly - but accurately - as possible, and should not be timid about applying normal CSD criteria to drafts when appropriate, and the AfC project not confusing itself with the WP:Article Rescue Squadron. --Kudpung กุดผึ้ง (talk) 19:34, 12 January 2015 (UTC)

Probation

To prevent user space abuse, we could implement "probation", which prevents you from editing userspace. This would be issued if you spend a lot of time in userspace. 50.83.140.10 (talk) 23:57, 6 January 2015 (UTC)

How is spending too much time in userspace damaging the site? For incompetent editors, maybe it's better to let them continue messing with their userpages than to find them constantly causing problems in mainspace. Zhaofeng Li [talk... contribs...] 04:27, 7 January 2015 (UTC)
  • Apparently this user has never heard of sandboxes for testing and learning how the site software works or userspace drafts for writing new content in one's own userspace without disrupting the wiki and reducing chances of it being deleted on them in the process of drafting. Hopefully, they will learn about such things. :) — {{U|Technical 13}} (e • t • c) 04:39, 7 January 2015 (UTC)
Well, this can get important. Like during high activity. 50.83.140.10 (talk) 01:55, 8 January 2015 (UTC)
And a lot a userspace editing clogs RC, especially when the wiki is busy. It also does not help the main space. 50.83.140.10 (talk) 01:57, 8 January 2015 (UTC)
In a busy wiki like English Wikipedia, userspace edits are rarely seen in RC, let alone clogging it up. But for a "popular ghost town", that's another story. Zhaofeng Li [talk... contribs...] 04:06, 8 January 2015 (UTC)
Userspace edits can be easily filtered out in Recent Changes if wanted. SiBr4 (talk) 08:27, 8 January 2015 (UTC)
You're missing the point. A lot of userspace editing doesn't help the main space, the part that matters. 50.83.140.10 (talk) 11:26, 8 January 2015 (UTC)
Encouraging users to make constructive contributions is a good idea, 50.83.140.10. However, if users spend less time in user space, it doesn't mean they will spend more time editing articles. What sort of abuse are you concerned about? Forbes72 (talk) 20:46, 8 January 2015 (UTC)
This is an idea that's on another wiki (and it works pretty well there, too). 50.83.140.10 (talk) — Preceding undated comment added 22:38, 8 January 2015 (UTC)

I don't see a lot of need for this. When we encounter Facebooking on user pages, we delete them, and that gets the point across pretty damn well. Oiyarbepsy (talk) 07:08, 10 January 2015 (UTC)

  • The thread is a solution looking for a problem. It is annoying, even sometimes exasperating, to see new users piling on hundreds of edits to their user page without making a single edit to an article or to any other part of Wikipedia. Unless they are blatant spammers, `attack writers, or creating a WP:FAKEARTICLE, (in which cases CSD/MfD is the obvious solution), they should be welcomingly encouraged to edit articles (but not welcomed for all their contributions}, and if that doesn't work we move on until we really have to warn them about Facebooking if their page is getting self-promotional. -Server storage space is not an issue.
Who is user:50.83.140.10 anyway? And how come with only 9 edits they know so much about Wikipedia, and why don't they want to register an account? (rhetorical questions). -Kudpung กุดผึ้ง (talk) 01:09, 11 January 2015 (UTC)
It gets frustrating to have a bunch of editors mainly edit user space when there is something that really needs to get done. 50.83.140.10 (talk) 12:09, 12 January 2015 (UTC)
Wikipedia is never finished and there is no deadline because we're all volunteers. Preventing people from editing userspace won't guarantee that they start working on whatever you might think is the most important task right now. So while it can be an issue, it is only rarely important (generally only when other policies like WP:SPAM and WP:BLP are involved). Mr.Z-man 14:48, 12 January 2015 (UTC)

Ban Enforcement Template

I noticed that there seem to be many users with editing restrictions that are not full site bans. To make it easier to identify when a ban has been violated, could users with bans other than site bans be required to have a template on their userpage?  B E C K Y S A Y L E S  06:07, 10 January 2015 (UTC)

I see some issues with that. With a full site ban, they have no right to edit and no right to a user page, so we replace the user page with the ban notice. But for topic bans and the like, they still have the right to a user page and the right to control it. Oiyarbepsy (talk) 07:05, 10 January 2015 (UTC)
No. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:40, 10 January 2015 (UTC)
No, Scarlet Letters are unnecessary; if an editor is being disruptive, sooner or later someone will figure out or recall they're violating an editing restriction. NE Ent 13:16, 11 January 2015 (UTC)
No. I think that having a /restrictions subpage would be reasonable, but it's unreasonable to expect the user to have such a banner in as visible a place as his/her user page. עוד מישהו Od Mishehu 21:48, 12 January 2015 (UTC)

More than 1 edit in watchlist

2nd: There must e a feature in your watchlist that allows you to see if there has been more than 1 edit in an article since the last time you visited. I know there is an option to show every single edit but it makes your watchlist too long Tetra quark (don't be shy) 22:44, 11 January 2015 (UTC)

Tetra quark, have you enabled WP:NAVPOPS in Special:Preferences (under the gadgets tab)? WhatamIdoing (talk) 23:32, 14 January 2015 (UTC)
Navigation Popups is very handy for all kinds of things; I highly recommend it. But there’s also the watchlist preference checkkbox “Expand watchlist to show all changes, not just the most recent“. I also see a link to the ‘net diff‘ beside each edited page that says how many changes were made since my last visit, which is especially useful in combination with the popups gadget.—Odysseus1479 01:50, 15 January 2015 (UTC)
I use that "expand watchlist" thing you mentioned, but I don't like it. The list gets too long. I wish there was just a different bullet next to a page in the watchlist that indicated there are previous edits Tetra quark (don't be shy) 01:54, 15 January 2015 (UTC)
(edit conflict) Sorry, missed it the first time: to fix the resulting watchlist-too-long problem, go to the recent changes section and check “Group changes by page …”. It will hide the details for each page, providing a ‘disclosure triangle‘ to reveal the individual edits.—Odysseus1479 02:00, 15 January 2015 (UTC)

Great idea for a partnership opportunity with Wikipedia

Hi everyone

Let me start off by saying that Wikipedia is awesome! I have a great idea for a partnership with Wikipedia. Any input would be fantastic!

I would love to join forces with Wikipedia to provide readers of such articles as books, TV shows, music, or bands with the opportunity to purchase whatever they are looking at at a given time, I would like to provide my links in tables for things like TV seasons of a specific show, episodes of specific TV shows or other related things. my idea is to edit an table in an article such as the ones that already exist in order to provide the reader the link in a way that they are not bombarded with a million links everywhere they look.

I do understand your need to ensure that the reader is not spammed with links and as a reader I very much appreciate that. I would however find it helpful to be provided a link that would further enhance my reading without taking me out of the experience.

It is my understanding that Wikipedia is a non profit organizeation, but I would be more then happy to donate a portion of whatever is earned during the time my links are on a page. Would anyone be open to this enhancment on Wikipedia?

Any feedback would be very much appreciated.

Thank You — Preceding unsigned comment added by Sledge106 (talk • contribs) 19:17, 23 January 2015 (UTC)

Inappropriate comment removed Oiyarbepsy (talk) 23:34, 23 January 2015 (UTC)
Andy (whose username is apt) is right to be blunt with you, though maybe not so blunt. You're proposing slathering Wikipedia with for-profit advertisements, which you alone apparently stand to profit from since you generously offered to donate some of your profits back to the Foundation. Consider that Wikipedia is neutral as a core founding principle. If Wikipedia allows an organization (any organization) to pay money to display their advertisement on this website, then Wikipedia can be coerced to rewrite content to suit the advertiser's whim, thus making Wikipedia non-neutral. Alternatively, if Wikipedia accepts some of the profit from your advertising venture, what's to stop some advertiser approaching you and offering you much more money if you demand to have certain Wikipedia content altered, or else lose out on the advertising revenue? In a nutshell, advertising allows for money and power to directly influence content, even with the best intentions, and this is why allowing advertising here is always going to be a terrible idea. I hope you understand.
If you are interested in reading further on this subject, the essay Funding Wikipedia through advertisements may be enlightening to you. But trust, my friend, that your idea is incompatible with our goals and will never be implemented here. Best wishes. Ivanvector (talk) 22:44, 23 January 2015 (UTC)
For what it's worth, most books link to ISBN numbers and most films to Imdb pages, which offer the additional info readers are looking for, as well as purchase options. But we won't do it here. Oiyarbepsy (talk) 23:33, 23 January 2015 (UTC)

Linking the Talk Pages across languages by Wikidata.

Wikidata is used to link en:George Washington to fr:George Washington, should the same list of languages generated by Wikidata for en:George Washington also be there for en:Talk:George Washington to enable a single click to get to fr:Discussion:George Washington? I'm sure someone else has come up with this idea before, so this is half a suggestion, half a "I wonder why it isn't" :)Naraht (talk) 16:23, 21 January 2015 (UTC)

Linking different language articles makes sense, since this is a benefit for our readers and we can be sure that both articles will have the same basic content, in different languages. However, since each language operates mostly independently, each language will be discussing completely different issues on the talk pages, so a direct language link is probably of relatively low value. Also, it is of no value at all for readers, who generally don't look at talk pages. There's always the slightly longer version of article -> article -> talk. Perhaps this could make sense as a user preference, though? Oiyarbepsy (talk) 01:01, 26 January 2015 (UTC)

Are Departing Editors Ever Surveyed??

I understand that one of the goals of wikipedia is to encourage people to contribute as editors. So it seems that it would be a good practice to obsessionally survey a sample of ex-editors regarding reasons they have not continued editing.

I'd suggest that every 6 months or so, a survey (which may change as we begin to learn more) be sent out to people who created an account with an email address who have not made an edit in the last 60 days but made more than 5 edits after creating their account, or within the last year, including people in each subgroups such as (1) users who were active for less than on month, (2) users who were active over one month but less than three months, and (3) users who were active over three months but less than a year.

It would not be necessary to email everyone fitting these categories, just a large enough sample to get 100-200 respondents in each subgroup.

Types of questions of interest to be explored using a likert scale: did they leave because it was too confusing, or because they had accomplished their goals, they were exhausted, they were frustrated by having their edits reverted, they found editing policies were inconsistent or not followed. And there should be an open ended text field for them to give their own reasons, which may shape future questions.

The results could be made available (minus the email addresses) for analysis by anyone interested and might help inform future policy and technical goals. –GodBlessYou2 (talk) 21:53, 25 January 2015 (UTC)

It's been done. Most of the "departed" editors said that they considered themselves to still be active editors, only they've been busy with real-world stuff or had forgotten to login recently.
Those that said they had stopped editing generally said that they quit because people yelled at them for honest mistakes (we were all new once, and the learning cure here is steep) or because everything they added was reverted or deleted. WhatamIdoing (talk) 23:10, 25 January 2015 (UTC)
Are the results available? And is there any discussion or plan for periodic efforts to repeat such surveys and to consider ways to address the concerns? How might I get involved? --GodBlessYou2 (talk) 15:34, 26 January 2015 (UTC)
It looks like the final report on that survey hasn't been published; a brief and early (read: probably wrong in some respects) summary can be read at strategy:Former Contributors Survey Results. I asked around, and here's what I learned: the survey was run in late 2009 or early 2010, for users who had edited the English Wikipedia at least once during 2009 but had not edited for a while, and who had never made more than 99 logged-in edits. About a third of the people surveyed directly said that they had never left, many said that they left for reasons unrelated to Wikipedia (e.g., people who stopped editing because a new job or family situation left them with no time for Wikipedia). Significantly more than half said that they were likely to edit again someday.
It appears that it was possible on this survey to simultaneously give the reasons why you left, and also say that you hadn't left at all.
Significantly more than half of the surveyed editors reported unpleasant experiences with other editors, like being reverted by other editors or receiving warnings from other editors. Significantly less than half of them would recommend editing Wikipedia to any of their friends. Of the people who left for some reason other than personal issues, and who had made more than 10 edits, most of them said that negative interactions with community members were a (or sometimes the only) reason for their departure. The (many more) people who had only made two or three edits were more likely to say that it was too confusing or complicated, although they, too, said that they had significant problems with actions by other community members.
AFAICT, there are no current plans to repeat this survey. Whether and how to change would be up to the community here. WhatamIdoing (talk) 23:58, 26 January 2015 (UTC)

Quicktalk

1st: A QuickTalk option. If enabled in the preferences, when you click "talk" next to the name of a user, a popup window will appear to make it easier to send a message. This would be good because it would motivate more dialogs and more feedbacks.also more help Tetra quark (don't be shy) 22:44, 11 January 2015 (UTC)

I support this idea, as an opt-in. --NaBUru38 (talk) 15:40, 30 January 2015 (UTC)

Counter

In my opinion, the Wikipedia software should attach a counter to both registered and non-registered editors that denotes whether all of the editor's edits should be checked. The counter starts at 0. All the editor's edits will be checked until the counter reaches 100. It reaches 100 after a hundred constructive edits were made with no clearly problematic edits in-between. If the editor ever makes a clearly problematic edit, the counter is reset to 0. There are external links to "Common Language in Marketing Project" here, here, here, here, here, here, here, here, and several more inline that have not been reverted for almost 3 months. They were added on 7 November 2014 by User:Karenmharvey who on her User page writes "Karen M Scheller on behalf of the Common Language Project at MASB." Clearly WP:PROMO/WP:SELFPROMOTE/WP:COI (and possibly WP:PE). I did not revert her edits, and I will not report them - mention them here only as an example of something that could've been prevented with a simple counter. Most vandalism could also be prevented with such a counter. Who's going to check all those edits? Well, first of all, if almost all vandalism (~8% of all edits?) is being prevented, that saves us a lot of time. It takes effort to create an encyclopedia. Just like editors check WP:PC edits, editors can check the edits of editors whose counters have not yet reached 100. The difference would be that WP:PC edits do not immediately go live. (related) --82.136.210.153 (talk) 09:33, 30 January 2015 (UTC)

(possible Hindi spam removed) — Preceding unsigned comment added by 203.192.214.195 (talk) 10:34, 5 February 2015 (UTC)

So would this be based on reverts? How do you define non-problematic edits in a way that software can do it? Is this something like "This editor has had 23 edits without being reverted", kinda lack those "23 days without an accident" signs in workplaces? Oiyarbepsy (talk) 16:56, 5 February 2015 (UTC)
I'd say not measured by reversions. We want people to be bold when necessary and we all make mistakes. If someone's counter is at 100 (it should never pass 100), and you believe the editor's counter should be reset to 0, nominate the editor. In practice, the nice thing about this is that anyone trying to get away with misusing or vandalizing Wikipedia will need to make (at least) 100 constructive edits in a row. It shouldn't be about shaming. If a good faith editor makes a clearly problematic edit, (s)he too could be nominated. --82.136.210.153 (talk) 16:49, 6 February 2015 (UTC)
Actually, it's probably better if reviewers can tag edits as being non-constructive/problematic, which will reset the editor's counter to 0, and that tagging can be contested. Way less discussions necessary than with nominations. --82.136.210.153 (talk) 17:09, 6 February 2015 (UTC)
I don't think we have enough editors to review all these contested tags, especially once vandals and spammers figure out they can tag the guys who revert them. Oiyarbepsy (talk) 20:32, 6 February 2015 (UTC)
How about without the option to object. Wouldn't be necessary anyway, since it only means edits are being checked by other editors, and editors are free to check each others' edits anyway. --82.136.210.153 (talk) 22:51, 6 February 2015 (UTC)
Here is another example. BG19bot put back a References section as a next edit. It's the fourteenth edit of that editor. If we would've kept an eye on such editors, it would not have required a coincidence for me to notice. It appears to be a good faith edit, but it's (also) worsening Wikipedia, and if there was a counter we'd set it to 0. We're carrying coals to Newcastle because it's too easy for editors to add unreliable, unreferenced, original research, and worse yet to remove (referenced) material. Certain articles are well-protected, but, by far, most are not. I frequently notice clearly problematic edits after months, even years; there's a lot we never even notice. The more articles I work on, the more I'll have to keep an eye on forever, because it's currently far too easy for editors to get away with destroying Wikipedia. What I also see a lot is vandalists who make many vandalist edits in a row, and when they eventually get stopped, nobody takes the time to check all their edits to see what nonsense of theirs is still present on Wikipedia. In the end we have an all right encyclopedia, but it's such a struggle because of what new editors get away with. --82.136.210.153 (talk) 11:03, 8 February 2015 (UTC)
  • Have you done any rough calculations on the number of new accounts registered every day and worked out the potential size of the task? A quick look at recent new accounts suggests around six per minute (and that's while most of the USA is asleep), or 8,640 new accounts per day. Or have you considered that many IP addresses are dynamic and may not last for 100 edits, and the effect of this proposal might be that almost all IP edits would need to be checked always? And how do you enforce "All the editor's edits will be checked until the counter reaches 100", given that voluntary work cannot be enforced? On the whole, this is a well-meaning idea, but I think the scale of the task would make it impractical. Squinge (talk) 11:44, 8 February 2015 (UTC)
I think that less than 1/4 of all edits would need to be checked. This really isn't that bad. It takes effort to create a good encyclopedia. I do not think that almost all edits by IP editors would need to be checked. If the checking needs to be enforced, Wikipedia software could ask editors whose scores are at 100 to approve a diff as part of making their own edits, every now and then. The status quo needs to change. This is an example of an article with 0 references that has been on Wikipedia for more than 10 years. We're pretending that we try to make material verifiable, but in reality everyone can do whatever they want with most articles, unless one or more people are protecting an article they personally put a lot of effort into, or when we feel the article is important for showing off what Wikipedia can accomplish. Like, for example, when I put a lot of effort into improving a Reception section, and someone decides to destroy all my work because some unrelated stuff is apparently plagiarized. The more articles I create or contribute to, the more articles I need to keep track of to prevent them from being destroyed. At some point you just walk away. I understand that a lot of people apparently feel that the way Wikipedia functions is currently 'good enough' and if it ain't broke, don't fix it, but in my opinion it is broken. Why do we allow editors to destroy what we work on. Just prevent vandalism, prevent non-constructive edits. Or at least force editors to make 100 constructive edits before they can give destroying our work a try. Add a big notice when an editor isn't at 100 edits that says it'll be checked. And, you know what, I think that most vandalism is not from IP editors as such but from IP editors (and registered users) who have made less than 100 edits. Most just happen to be unregistered, but it's the number of edits and not whether they're registered. You know, similar to how correlation does not imply causation. When you write "many IP addresses are dynamic and may not last for 100 edits", those "many" are exactly the ones that we should be checking because that's where the vandalism is coming from. The same goes for good faith edits, if someone is just starting with editing Wikipedia, that's when they need our help. Those are the people we need to keep an eye on. There's no need for semi-protection or pending changes. It's not about whether a user is an IP editor or not, it's the number of (constructive) edits that matters. --82.136.210.153 (talk) 14:24, 8 February 2015 (UTC)
How did you decide that only 1/4 of all edits would need to be checked, and have you worked out actually how many edits that would be per day? I do understand the problems you are describing, but without quantification of the required effort suggestions like this will get nowhere, and practically unfeasible solutions won't solve the problems. I suggest you start by working out how many edits per day would need to be checked under your proposals, and show us how you calculated it. Squinge (talk) 14:45, 8 February 2015 (UTC)
I'm not going to do that. For the same reason I described in my last post in this section. I don't want to start a discussion about exact numbers and details. You expect me to put an incredible amount of effort into giving you calculations that you can then easily shoot down if you'd wanted to because there's always something not 100% right. I should not even have mentioned the 1/4, because it's exactly the kind of thing you could easily jump on. As I wrote, I think it's doable and I think we should do it. If nobody else truly cares and agrees with me, it's pointless for me to start writing about exact numbers and details. Even the 100 score is obviously a random number I pulled out of my hat. What I'm doing is trying to paint a picture and offering a possible solution to what I believe to be a serious problem. In my opinion even checking every single edit would be doable. It's really not that difficult, just ask editors to check an unrelated diff each time they make an edit. A changed mentality. Most edits are fine, and the number of constructive edits would only increase if we have a proper system in place to really prevent vandalism from taking place. --82.136.210.153 (talk) 15:04, 8 February 2015 (UTC)
Oh no, I absolutely am not looking to shoot down your efforts, and I'm sorry if it came across that way. My point is simply that suggestions like this absolutely need to be quantified in terms of required effort before they can realistically be considered. I don't have any statistics myself, but I do have a feel for the enormous number of edits made by new editors every day, and I think it's very likely that your suggestion would require a very significant increase in new-edit reviewing - and where is that extra work going to come from? Squinge (talk) 15:35, 8 February 2015 (UTC)
PS: RE "just ask editors to check an unrelated diff each time they make an edit" - that's at least doubling the amount of work done by contributors, and simply assuming everyone has twice as much time to spare seems unrealistic. Squinge (talk) 15:39, 8 February 2015 (UTC)
I very much disagree with your assessment that it's "at least doubling the amount of work". Checking a diff is quite different from finding and properly referencing reliable sources, and thinking about how to formulate or rephrase material, and so on. Even if it would double the amount of work - not true, but hypothetically - it's still better to do what we do right instead of doing more half-cocked. If I click "Random article" a bunch of times, I run into so much unreferenced or poorly referenced articles, frequently with original research and just plain untrue nonsense that was dumped on Wikipedia by random fanboys. What's even worse is how solid and properly referenced material is being removed, because, let's face it, how could we possibly notice. Yes, sometimes stuff is tagged and bots intervene. Yes, some of us check the Recent changes or care enough about articles to keep an eye on their revision histories, but it's so easy to remove material without anyone noticing. What also happens a lot is trolls who change, for example, years. Would not work if they touch, for example, Gerald Ford, but just pick any article that's already tagged with {{Refimprove}} or {{BLP sources}} and you can more or less make up/change whatever you want as long as it looks like it may be true. If someone died in 1927 and that's true but unreferenced, anyone could change it to 1926 and nobody would notice. Then if you wait a while some random website will think Wikipedia is reliable, not mention Wikipedia as a source, and another Wikipedia editor comes along and adds the website's page as a ref. Recently I made this change, because everything it says in that section including the entire quote ("I think vegetarianism is really great, and I stand really strongly behind it...I think that an animal goes through a lot of pain in the whole cycle of death in the slaughterhouse; just living to be killed...I just don't think it's worth eating that animal...There's so much other food out there that doesn't have to involve you in that cycle of pain and death.") may be utter nonsense. The editor who added that should've been stopped. At least that particular quote is tagged with {{Citation needed|date=June 2013}}, but you and I both know that Wikipedia is full of nonsense that random people added based on things they heard their friends say. I think that almost all of those problematic changes are from editors with less than 100 constructive edits. This edit lasted over 1.5 years. From an IP editor who has made only seven edits, all vandalistic edits. The very first edit we should've been there to say to warn this person and say we check edits. More than 1.5 years "He also lost from the lange dunne By TKO" and "2011 won the Dutch Koekhappen open in Amsterdam". Yes, koekhappen. Oh, and I also disagree with WP:BLUE and in my opinion every single thing on Wikipedia should be properly referenced, and references should be attached to material, so someone can't change "They have 2 dogs: x and y.[1]" and change it to "They have 3 dogs: x and y and z[1]" even though ref 1 only mentions two of the dogs. But let's not go there, let's start with changing what new editors can get away with. No 100 constructive edits, then your edits get checked. Your edits are no longer being checked but you deliberately make a non-constructive edit (not good faith), you're back to 0 and we're checking your edits again. --82.136.210.153 (talk) 17:44, 8 February 2015 (UTC)
Reading the above, I think that most editors commenting have some sympathy for the idea; but are troubled whether it can be reasonably be implemented. Your koekhappen example is indeed problematic. However, as you said yourself, that should have been picked up, and fixed even within the current system. Why would a new list of edits to be checked result in these edits being actually checked and corrected?
If we would go somewhere in this direction I think an automatic notification in the history of an article along the lines of "editor without track record" would be more likely to work. Editors working on an article can than decide whether this needs to be fixed immediately, later on, or ignore it and leave as is.
In addition I think your 100 edits reset to 0 can play out overly harsh. A simple disagreement can already set you back to 0 if you encounter an overzealous admin/reviewer. If you would go to something like this I would rather set the penalty at 10 points (or so) and set any score above 90 as good enough. That allows editors in good standing one minor hiccup once in a while. Arnoutf (talk) 17:56, 8 February 2015 (UTC)
  • Well, firstly, giving us lots of specific examples of things that were wrong doesn't really provide any support for your actual proposed solution - we *know* that things go wrong, and what we need to be doing here is assessing your proposed solution and not simply restating that things go wrong. Secondly, you say "I very much disagree with your assessment that it's "at least doubling the amount of work"", and sure my guesswork might be wrong. But we do need to quantify the work needed for any proposed solution, and anything that requires editors to do more work will be much harder to implement - simply because we cannot enforce what people do here. You say "Even if it would double the amount of work - not true, but hypothetically - it's still better to do what we do right instead of doing more half-cocked", and I agree - but you seem to be missing the fundamental point that we cannot simply order people to do that. Seriously, if you want to make a proposal for doing things better, it first needs to be quantified in terms of effort required, and only then can its feasibility be determined. Ideals are brilliant, but ideals don't turn wheels - to turn ideal into reality requires some serious practical work, and I don't see any interest from you in doing the legwork that would quantify your proposal and help get it closer to practicality. Sorry if you think I'm being a sourpuss, but that's the way critical analysis of ideas works. Squinge (talk) 18:06, 8 February 2015 (UTC)

Cite this page

Would it be feasible to have at the bottom of each page a box similar to a navbox that had the full citation for the page it was used on in different formats, ALA, MLA, etc.? And would the community support such a change?

There are many possibilities for implementation:

A template like {{reflist}} that we put at the the bottom of each page under external links with its own section

A mediawiki feature that is automatically put in every page

We might have to restrict the usage, however, because not all pages are of citable quality, and there might be a backlash by academics if more people cite badly written pages on their college reports.

Should it be only for FAs? FAs + GAs? The aforementioned plus A or B class?

Or should it not use the Wikiproject quality system and use some other bar for entry such as a peer review?

The reason I am proposing this is to try to raise awareness of the great articles we have here on-wiki, that anywhere else would be a reliable source if not for the stigma surrounding Wikipedia. Hopefully this initiative will help remove this stigma and make at least some of Wikipedia a reliable, citable source.

The first phase of this proposal is simply discussion-What articles you want it to be restricted to, how it will be implemented, whether you support the general idea of posting cite information or not, etc. When a general consensus arrives at what different models the community would most like it to use, I will put together 1 or several different proposals and create a formal RfC on VPR.

Thank you and I hope to see your input on the idea. KonveyorBelt 01:12, 29 January 2015 (UTC)

Discussion (citing)

Well, Jimbo himself has said that people shouldn't be citing Wikipedia. Yes, we have some great articles, but the role of Wikipedia is to provide the overview and point to where the best sources are. Oiyarbepsy (talk) 04:36, 29 January 2015 (UTC)

  • Are you (Konveyor Belt) aware that there is already a "Cite this page" link, under "Tools" in the left-hand margin of each article, that leads to a page giving full citations in various formats? Deor (talk) 11:24, 4 February 2015 (UTC)
The current "Cite this page" is made by mw:Extension:CiteThisPage and MediaWiki:Citethispage-content. I don't see a reason to duplicate that feature. We might consider a more prominent link to the feature for quality articles but I wouldn't support it. PrimeHunter (talk) 15:22, 6 February 2015 (UTC)
And it also already has multiple style formats. And indeed, encylopedia's are poor sources and shouldn't be cited in formal, news reporting, or academic writings. — xaosflux Talk 20:37, 6 February 2015 (UTC)

Well Jimmy Wales is often wrong; if you haven't witnessed this fact for yourself, just wait a while. There are some good reasons to cite Wikipedia:

  • Opinions expressed on topics by editors, even anonymous IPs. One could assert with a straight face that researching how people argue over certain real-world topics may provide insight on what the general public thinks about that topic. (Examples include George W. Bush, or Gamergate. It might be enlightening to watch how the article changes in framing & presenting the subject over hundreds of revisions.) Not necessarily The Truth (tm), but popular perception of that subject -- which can be harder to document than The Truth (tm).
  • Source for citations. A lot of people do not have access to decent libraries, & even if they have access to Inter-Library Loan due to deadlines they may not be able to access a given source directly. Wikipedia articles can provide quotations of those sources.
  • And whether we like it or not, Wikipedia is an example of individual interaction. Memes, fads, in-jokes, etc. appear, cascade, then vanish from our pages. Sometimes the most useful information for future historians will be the verbiage we ignore or despise.

The best advice we can give these researchers is to make sure they reference a given version of an article, talk page, or meta page, & not the general URI of that page. -- llywrch (talk) 07:28, 10 February 2015 (UTC)

I agree with llywrch here. While Wikipedia might generally not be suitable for citing at university-level where students should be using primary-source papers, etc, encyclopedias are good sources for school kids and learning how to cite them is surely useful. Also, people do a lot of research into social interaction, web development, etc, and Wikipedia is itself sometimes the subject of it - and that's exactly when people will want to cite Wikipedia. Squinge (talk) 09:25, 10 February 2015 (UTC)

Beta for everyone

I think that the beta features should be made available to everyone, even if they are not logged in. I constantly miss the hovercard feature when I am not logged in. Perhaps instead of being allowed to comment, people should be given a vote - Did you like (feature)? Yes, No, what could be better. Awesomeshreyo (talk) 19:17, 9 February 2015 (UTC)

Hi Awesomeshreyo, and thanks for your comments. There's been some talk about making Beta Features available to logged-out users, but I don't think that will happen any time soon.
Hovercards itself is being studied at two other Wikipedias to see whether it is satisfactory or if it needs improvement. It seems to be a popular feature among the people who have tried it. If it meets the success criteria, it will probably graduate and thus become available to everyone by default, including logged-out users. If it doesn't, then they'll probably redesign it. Whatamidoing (WMF) (talk) 23:29, 12 February 2015 (UTC)

Interactive Multimedia Elements

I used to really enjoy the Encarta multimedia encyclopedia (90s). It made exploring and learning new things much more fun and facilitated learning new things in a really good way. For instance there was a page with musical instruments on and you could hover or click each one to get it to play the sound of that instrument. Or you could have the globe and spin around it to find the continents, countries and cities (combine with Google earth?). You could also do 3d tours of capital cities (combine with Google street view?) Wikipedia is really missing this kind of fun and interactivity. Even the pictures are usually dull and sometimes restricted to one picture per article. If you click on the maps often all the borders and place-names are removed so you can't even zoom in on it or get a larger view.

There is just one catch I can think of: Power consumption and server load. If the whole world was using interactive features then it could actually increase global power consumption considerably and I'm not for that so adding features would have to be done sensitively and realistically. Nibinaear (talk) 12:28, 12 February 2015 (UTC)

There was a proposal to allow scripting on articles which enables the development of interactive elements. However, since those scripts are run on the readers' computers, security should be considered. Zhaofeng Li [talk... contribs...] 12:42, 13 February 2015 (UTC)
Anyone else remember the old Encarta? Nibinaear (talk) 12:25, 5 March 2015 (UTC)

Ideas for when users die in real life

I spotted this news story about Facebook. I don't think we have any options, other than offering a sympathetic ear to the requests of family members. It would be a relatively simple thing to include somewhere a low or high tech option for users to indicate what they'd like to happen to their userspace when they eventually die. --Dweller (talk) 17:05, 12 February 2015 (UTC)

See Wikipedia:Deceased Wikipedians/Guidelines. PrimeHunter (talk) 17:10, 12 February 2015 (UTC)
Thanks, helpful. I don't see any discussion there of my suggestion. --Dweller (talk) 09:12, 13 February 2015 (UTC)
But you know how to use talk pages. That seems like the right place to discuss it. PrimeHunter (talk) 12:54, 13 February 2015 (UTC)
Ah, now I'm with you. OK, will do. Cheers. --Dweller (talk) 13:04, 13 February 2015 (UTC)

Is showing the date of cleanup tags really necessary?

Why is it so necessary that the date of an added cleanup template be displayed on the articles? I think these should be removed and only work behind the scenes. Back when Wikipedia was new, it may have made a little sense, but today I see articles using Template:Multiple issues showing dates as far back at 2007, and it is very off-putting. It makes us look lazy and was obviously not helpful in drawing people in to clean up the problem. Sure, adding the date better-sorts the template into categories, but if an article requires cleanup, should it really be announced on the page that it still has not been done after so many years? Thoughts? — CobraWiki ( jabber | stuff ) 08:48, 6 February 2015 (UTC)

I agree with the thrust of your proposal. It is useful for an editor to know how long the tag has been in place. If I see a tag dating back to the dawn of Wikipedia then my starting position is to check whether it should just be removed because the issue has been addressed. One common scenario I see is that multiple editors have made small changes and collectively dealt with the original issue but none has presumably reviewed the whole article or felt confident enough to remove the tag. So the date is useful to me. Is it useful to the reader to have the date? Not at all and does indeed make us look lazy. QuiteUnusual (talk) 09:37, 6 February 2015 (UTC)
I like the dates, even for the cleanup tags. Letting people, especially editors, know when the article was tagged is helpful in a number of ways, not the least of which is knowing how to proceed from there -- check the edit history since then, check who added the tag, check and see if they posted anything on Talk around that time, check why they added it, check to see what the state of the article was when the tag was added and what its state is now, etc. In terms of "it makes us look lazy" (or bad) (1) if Wikipedia cared about looking bad it would not let IPs edit, and do many other things differently; I think the date on a tag is very low on the list of how and why Wikipedia looks bad (2) if a random outsider thinks it looks bad, they can always do some cleaning themselves. As it is, nowadays the cleanup tag cannot be added without filling in what exactly needs cleaning up (if I'm not mistaken), so that at least has solved some of the problem right there. Some articles have really old tags because they are so seldom visited. Softlavender (talk) 10:00, 6 February 2015 (UTC)
One man's "it makes us look lazy" is another man's "it gives readers a window into how much attention a particular article receives". Wikipedia tends to be pretty highly trusted among online resources—sometimes much more so than it should be. (Frankly, the earned reputation of our high-popularity, high-traffic, closely-watched, well-maintained articles is probably giving our less-maintained, rougher-edged long tail an undeserved boost.) I actually think it's a good thing to conspicuously remind readers, where appropriate, that some (many!) Wikipedia articles are very much works-in-progress.
Above, QuiteUnusual suggests that it is "common" for issues underlying an older maintenance tag to be remedied without the tag being removed, and that this might unfairly taint a particular article's reputation. Is that actually generally true, or is it just because the articles that QuiteUnusual (or any other editor) are most likely to see are the ones being more-actively maintained? In other words, if we look at the issue from the other end – examining where the tags are distributed, rather than by considering articles with active editors – by using the dated maintenance categories, what do we find? I looked at the first few entries in Category:Articles lacking sources from October 2006, and all the ones I checked are still lacking sources. The articles listed in Category:Orphaned articles from May 2008 still seem to be orphans. Editors should, perhaps, be encouraged to be a bit bolder in removing no-longer-needed maintenance tags, but I have yet to see convincing evidence that more than a small fraction of these tags deal with resolved issues.
That said, if someone with a bit (or a lot) more know-how than I were to create a bot or script to pick out articles with a lot of 'old' tags that had also received a substantial number of edits in the interim as 'priority' candidates for screening and re-evaluation, it's possible it could be a useful tool. TenOfAllTrades(talk) 17:01, 6 February 2015 (UTC)
I like the dates on the cleanup tags in part because often a very-old cleanup tag indicates issues that just don't exist any more - and if a reader notices the old date, he can re-assess whether it still applies. – Philosopher Let us reason together. 18:57, 6 February 2015 (UTC)
I feel there's a lot of value to readers to knowing how long a tag has been in place. I agree that many do get resolved incrementally without the tag ever being removed (the same is true for stub tags, my pet annoyance) - but that's something for us to resolve by patrolling older tags, rather than remove the information completely. Andrew Gray (talk) 19:15, 6 February 2015 (UTC)
  • As well as having the dates there for potential reviewers/editors who might want to fix the articles, I think it's useful for readers to see the tag dates too. Rather than trying to avoid looking lazy, we should be as open as we can in saying "Be careful, this could be a bad article and it's been that way for a long time". The reliability of Wikipedia's good articles is very very good, but the reliability of bad ones is horrid, and that's a common cause of valid criticism of the project. Being open about the bad stuff is a sign of honesty and is a step in helping address that criticism. We should not try to cover it up. Squinge (talk) 11:28, 8 February 2015 (UTC)
  • If most people don't think that the date is helpful to logged-out users, then I believe that it could be set to show only to logged-in users. Personally, I want tags to change their content after a year (or three), to say "If you believe that this tag is outdated, please remove it." WhatamIdoing (talk) 21:01, 12 February 2015 (UTC)
That last bit is an interesting proposal. I might go with something more along the lines of "If the issues this tag refers to have been resolved, please remove it." (Heck, it might be worthwhile to have that sort of reminder on all maintenance tags.) I would be hesitant to use wording like "outdated" that might implicitly suggest tags should simply expire, even if the underlying issue hasn't been fixed.
I'm reluctant to encourage hiding tags from non-logged-in readers (i.e. nearly everyone who reads a Wikipedia article). At best, the maintenance tags provide specific cautions that a reader should bear in mind about the content of a particular article. And even at worst, a really old maintenance tag flags that an article probably doesn't receive very much attention. TenOfAllTrades(talk) 02:49, 14 February 2015 (UTC)
I agree that tags (and dates) should not be hidden from readers, as they're the ones who most need to be made aware of problems with articles. I also agree that the word "outdated" is not the one to use. Squinge (talk) 10:29, 14 February 2015 (UTC)

Quick Vote

For discussion pages, I think there should be a quick poll at the top to see the general opinion - eg. Do you think ()? Yes, No, Other This would help especially with issues such as mergers and biased sections, as well as the beta area of Wikipedia where it could be used to see the general consensus in a new feature. Awesomeshreyo (talk) 19:20, 9 February 2015 (UTC)

Hm... often, polls are easier but not better. Decisions on Wikipedia are not made on straight votes, but by consensus, and consensus is reached through negotiation and consideration of each side's arguments. While polling can facilitate discussion, a quick poll option for general use could increase the risk of canvassing, might give editors the wrong impression (majority/head count v. strength of arguments), and may be divisive. The argumentum ad populum is a dangerous one. A "quick" vote in particular sounds like something that goes against Wikipedia policy - we're not a democracy - and could lead to polarization. --82.136.210.153 (talk) 03:41, 10 February 2015 (UTC)
Quick polls are not and should not ever used for things such as mergers, moves, etc. That must be done publicly, with site-wide viewership, via the standard official procedures. And for other matters, as in all things, consensus and debate is not a !vote -- consensus is arrived at via policy-based dialogue and discussion. If discussion stalls, then the next steps in dispute resolution are used -- third opinion, public RfC, etc. Lastly, "the general opinion" is not going to be reached by a random few people who happen to see and participate in a so-called "Quick Vote" -- Wikipedia is so sparsely populated these days (so many editors leave), and so few editors have any given article on their watch lists, that any attempt at a "Quick Vote" on most articles is going to result in a tiny few responses not indicative of general policies, opinions, and guidelines. Softlavender (talk) 04:13, 10 February 2015 (UTC)

User:Awesomeshreyo, there are some article talk pages that have FAQs addressing questions that are asked over and over again. This can be seen at Talk:Waterboarding or Talk:0.999.... If you think there is another article talk page that can benefit from that, raise it at that talk page. Oiyarbepsy (talk) 18:09, 14 February 2015 (UTC)

Mapping categories to page sections

So, right now we have a task of automatically mapping wikipedia pages to different topics. E.g. pages about politics goes to politics, pages about computer games goes to entertainment and so on. This is done by first mapping our topic structure to top-level wikipedia categories. Then if some category is assigned to page, we select topic associated with some super-category of it. Sometimes this mapping is ambiguous: one page could be assigned to multiple topics.

So we decided to build a system that assigns a subset of page categories to each section on the page (and then rerun our mapping tool on section level).

Do you think it is a good idea to assign categories to sections? For well-developed pages it works great, but for the most of them it is either really hard to do or doesn't make sense.

Can you think of the practical applications of this idea (other than our task)? Like, for example, we can suggest to improve sections that doesn't relate to page categories (or add a new category), or even suggest to write more about a category that is not represented on the page at all (or just briefly described in the first paragraph).

Does it make sense? — YNechaev (talk) 18:56, 16 February 2015 (UTC)

"Archive.org BOT"?

This must be a silly idea (because I cannot imagine someone else would NOT have proposed it by now). Ok, still: Why not have a bot archive all newly added refs on archive.org website (if not already done by this website already) and automatically add a link in the corresponding WP article's reference using the "wayback machine". This would be a tremendous plus for all editors encountering WP:link rots.67.87.51.51 (talk) 08:50, 15 February 2015 (UTC)

Have a look at this: Wikipedia:Using WebCite Oiyarbepsy (talk) 03:22, 16 February 2015 (UTC)
Thanks. I know this website (i am a registered editor - user:SSZ.) You can do the same at archive.org now. The point was automation (i.e. no need to go to the website each and every time, save and archive the reference on WP - for economy articles which I often edit, it is a CUMBERSOME task.) May be this new feature could be optionally available for WP users? (with a check-box in the preference section.) 67.87.51.51 (talk) 08:14, 16 February 2015 (UTC)
Comment on the archive bot notion in general -- I think that there should be a pair of sister-bots: one which checks to see if an external link is archived at archive.org and/or webcite and a second which invokes the archiving if the first finds that it is not present. There are problems with serial archiving of 404 warnings sometimes; queries against some sites return a soft-404, i.e. wrapped in the target website's domain site. Unfortunate that these pages do not tell browsers/bots "here be a hard 404, but we are softening it for humans." --User:Ceyockey (talk to me) 12:46, 16 February 2015 (UTC)
Tracked in Phabricator
Task T89438

Also, Mediawiki is currently working on an automated citing service for WP:Visual editor, called Citoid. It will allow you to enter a DOI, ISBN, URL or other identifier and the software will fill in all the details. There is currently a request to add auto-archiving to this new software. However, it's at a very early stage. Oiyarbepsy (talk) 15:31, 16 February 2015 (UTC)

Automated submission of links to archiving sites drives up the cost for the site and may be against the ToS for that site. Furthermore, this has been suggested in the past (see RotlinkBot and Archive.is debates of usefullness) with at best mixed results. I believe the last time this was brought up, the community's will was for WMF to develop a storage solution that was a DoA pidgin at the foundation's steps. Hasteur (talk) 15:47, 16 February 2015 (UTC)

I think the issue of traffic between WP and archive.org servers should be made separate from the discussion regarding the usefulness of the bot itself. WP could have an arrangement with archive.org to pay for storage capacity (all queries would be handled from a WP permanent IP address where the bot would be located). ..and NSA could donate one of its "old"* servers to archive.org for free. (*which are still two generations ahead of all commercially available servers :) — Preceding unsigned comment added by 67.87.51.51 (talk) 09:56, 17 February 2015 (UTC)
NSA... Oh, come on. Not again... Zhaofeng Li [talk... contribs...] 10:44, 17 February 2015 (UTC)
:) — Preceding unsigned comment added by 67.87.51.51 (talk) 11:51, 17 February 2015 (UTC)

My second "silly" idea of the night?

Why not have a "boot camp" for new editors (to be made mandatory may be?) Objective: get new WP editors become familiar with WP guidelines and policies SO AS THEY DON'T TAKE THINGS PERSONALLY AND LEARN THE PROCESS OF WP EDITING AT THE SAME TIME. MAKING THE PROCESS *FUN*. The big plus is that ego is removed while training since there is no convictions and no personal confrontation about it (since new WP editors would be required to edit WP:sandbox articles) and it would help a great deal editors IMHO (new and old editors* alike, sometimes). *e.g. This could be used as an alternative to blocking someone. This could even be handled by a BOT on the other side (simulating other editors and a reference to WP guidelines and procedures being explained or tested as an example) through predetermined algorithms. 67.87.51.51 (talk) 08:59, 15 February 2015 (UTC)

We have The Wikipedia Adventure which is what you are looking for, except that it's completely optional. We shouldn't force new editors to take the blue pill and edit in "the Matrix" before they can do anything meaningful. Zhaofeng Li [talk... contribs...] 09:24, 15 February 2015 (UTC)
Great! This should be advertised More IMO. Also it should be made mandatory for some editors who have skills and good intentions but lack skills relating to other editors' edits. Also I would like to add that this project you refer to should be more detailed. Also Explanations regarding the TOOLS, avenues and procedures should be given (for dispute resolution, so as to refer people to the specific tasks they need to work on.) MY 2 cents as always! — Preceding unsigned comment added by 67.87.51.51 (talk) 09:34, 15 February 2015 (UTC)

International idea: sign of the existing discussion on interwiki box

After comparing different Wikipedians of discussion pages of articles I suggest to somehow to do notice-sign on to the interwiki box. This means that, for example, if you know some topic well, then you can easily see that on the other language Wikipedia has also discussion page of the same topic. Some drafts can be seen here: File:Discussion sign on iw box --Bioneer1 (talk) 08:16, 20 February 2015 (UTC)

Brainless importing from Word with citations from EndNote or other reference software

Fantasy probably, but I'd love to draft text in MS word or my antique wordperfect, with embedded citations from my reference software (EndNote) and then be able to import the text, with some behind the scenes formatting of all the references.

The advantages to this are so obvious (to me anyway) that I'm surprised this has not already happened.

Thoughts? NewsAndEventsGuy (talk) 19:15, 20 February 2015 (UTC)

Editors exempt from 3RR

I closed the 3RRN discussion; nothing else to discuss here--Ymblanter (talk) 22:05, 21 February 2015 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Given the way this 3RR report is (not) being dealt with, what would y'all think about creating a category of "editor exempt from the 3RR rule"? If we're going to do it in practice, perhaps we should make it a matter of explicit designation. Nomoskedasticity (talk) 18:38, 21 February 2015 (UTC)

Forum shop much? 3rr is clear in showing that BLP articles and reverts may be exempt from the bright line rule.User:Maunus ·ʍaunus·snunɐw· 18:58, 21 February 2015 (UTC)

Interjection: @Maunus. Please could you explain what your edit means! Links to what you are talking about would be great. Using English rather than WikiLanguage jargon would be better. Thank-you __DrChrissy (talk) 19:20, 21 February 2015 (UTC)

@DrChrissy:"Forum shop" means to go to a different forum to gain support for ones viewpoint when consensus is against one in the first forum. That is what Nomoskedacity is doing, since several editors in the edit warring discussion had already told them that Collects edits were not problematic because they were essentially protecting a special kind of article, namely a BLP. BLP means "biography of living persons", and to avoid defamation of living people BLP articles are specially protected, so that removing problematic content from BLP articles is specifically not covered by the 3rr rule, which is what 5 other editors were telling Nomoskedacity in the discussion. 3rr means "three revert rule" which stipulates that an editor may never make more than three reverts on the same article within a 24 hour period - unless they are reverting simple vandalism or protecting a BLP article. So all in all Nomoskedacity's suggestion that User:Collect is somehow exempt from the rules is ill-founded.User:Maunus ·ʍaunus·snunɐw· 22:04, 21 February 2015 (UTC)
They might be. But it depends on whether there's a reasonable argument to that effect, as against a mere assertion. Nomoskedasticity (talk) 19:00, 21 February 2015 (UTC)
See WP:POINT. Don't make silly edits or suggestions in the hope of getting support or attention for something else. PrimeHunter (talk) 21:58, 21 February 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Show branching tree of articles and sub-articles in graphic form

Is there a way to map the branching tree of big topics? For example, Climate and Global warming are top articles on those subjects, with lots of sub levels and subsublevels. Text based outlines are nice, but can we show the branching tree in a picture also? NewsAndEventsGuy (talk) 19:19, 20 February 2015 (UTC)

There is {{category tree}} - example on the doc page, or try it in your sandbox. It might not be exactly what you're looking for. Ivanvector (talk) 01:12, 24 February 2015 (UTC)
That is the vcat tool (formerly known as Catgraph), which shows the category structure. See vcat:Global warming. And compare to the german equivalent vcat:Globale Erwärmung (German WP has a more stringent categorization).
Other possibility is showing wikilinks. See for example http://en.inforapid.org/index.php?search=Global_warming Hope this helps, @NewsAndEventsGuy --Atlasowa (talk) 20:36, 27 February 2015 (UTC)

Bot to find potential RfA candidates

Over the last few years, the number of candidates for RfA has been in decline. There are many reasons for this, not all of which we can do anything about. One thing we can do to get more candidates, however, is to ask more people if they want to run. Some people are proactive about wanting to run for adminship, but others are more reluctant and need some persuasion. I myself only ran for adminship after Worm That Turned nominated me, probably about a year and 10,000 edits after I should have.

There are a few seasoned RfA nominators out there willing to hunt for potential candidates, but it is an imprecise science at best. For my part, my thought process usually goes something like, "Hey, I've seen you around before, and you seem to know what you're talking about; why don't I see if you'd be a good RfA candidate?" That happens quite a lot, but I usually only get round to looking at that editor's edits if a) I have a reasonable amount of time to spare at that moment, and b) I'm not doing in the middle of doing some other wiki-task. And if I do get round to looking at that user's edits, then I might find they have a recent block, or a userbox that says "I will never be an admin, ever." And even if a preliminary check indicates that they would be a good candidate, when I actually ask them if they want to run, it happens quite often that I get the reply "no", or "not yet".

I propose that we take the guesswork out of this process, by creating a bot that check's users' contributions to try and gauge if they are ready for adminship. For example, we could say that a user is a potential admin candidate if they a) have at least 10,000 edits, b) no blocks within the last six months, c) have 50 AfD comments... The exact criteria can be worked out later. Then if the bot thinks that a user is a good potential candidate, then it could leave a message on that user's talk page asking them if they would be interested in running for adminship. This message would only be delivered once for any user, once they satisfy the criteria. The bot would keep a record of users that had already received notices, so that no-one would get any duplicate messages. With just this talk page message, users might think about running for RfA where they wouldn't have before, and people watching their talk page might well chime in with messages of encouragement.

Also, this bot could update a website on Tool Labs that kept track of all the possible admin candidates. So users could indicate whether they want to run on or not on that website, and then users looking for potential RfA candidates could just check the website for eligible users that indicate that they want to run. For nominators, this would be a vast improvement over the current hit-or-miss approach to finding candidates.

I envisioned this system as being most useful for up-and-coming editors that might not have thought about running for adminship otherwise. For established non-admin editors, it may be a good idea to place further limits on who gets asked, to avoid thousands of editors getting talk page messages on the bot's first run. We obviously aren't going to be able to deal with thousands of concurrent RfAs, so we shouldn't be asking thousands of users concurrently if they should run.

Would people be interested in an idea like this? I'd love to hear your thoughts. — Mr. Stradivarius ♪ talk ♪ 11:50, 25 February 2015 (UTC)

As long as we aren't giving the potential candidates false hope, I like the idea - perhaps they should be pointed to somewhere they can request a nomination? Hard criteria is by no means any sort of guarantee of a pass, but it's certainly a good place to start. WormTT(talk) 12:06, 25 February 2015 (UTC)
I'm going to have a think about how best to notify the users about RfA, but at the very least a bot which generates a list of candidates who pass the typical admin threshold sounds like a great idea. Sam Walton (talk) 12:32, 25 February 2015 (UTC)
  • Comment Could a bot be programmed to ignore blocks such as the current candidate at AfD has in his history? (Unblocked within the minute with the comment 'ooops', to be exact.) I haven't nominated anyone yet because of a distaste for digging in stats, and because someone else usually nominates them before I get around to asking. This could be useful, if it can show a wide spread of editing rather than 10,000 edits made up of small edits solely to articles about beauty queens, the history of Jammu, and glass frogs. On the other hand, quite a few of the high contributors on the list of such aren't exactly the sort you would want as admins for assorted reasons (but quite of few of those are currently blocked or banned, or keeping a low profile). Would the bot be able to spot (thought there for a new game - Spot the Bot) the cantankarous sods that never get blocked, but turn up everywhere to disrupt with their PoV? Peridon (talk) 14:49, 25 February 2015 (UTC)
    Bots could be programmed to ignore blocks that lasted less than, say, a couple of hours, yes. On the other hand, I'm afraid that bots are very bad at spotting cantankerous sods. :) It's possible that we could build in some kind of human-run cantankerous-sod-spotting system into the website, but we'd have to think very carefully about how that would work. — Mr. Stradivarius ♪ talk ♪ 15:02, 25 February 2015 (UTC)
    I think it would easily be the case that the bot generates a "here's some possibly, by numbers alone, good candidates" list, which would then require investigation from users looking to nominate who could pass their judgement as to whether any given editor is a cantankerous sod or not. Sam Walton (talk) 17:22, 25 February 2015 (UTC)
    Darn, now I'm disappointed that WP:CANTANKEROUSSOD doesn't exist... ansh666 02:25, 26 February 2015 (UTC)
  • Comment - Good idea, but I think it would be best if the bot compiled a list of potential candidates for further vetting by prospective nominators, but did not notify the candidates directly, per WP:BEANS. Some people who meet whatever criteria are set would not make good admins, and I feel like that particular pool of unsuitable candidates would be the ones most likely to ignore the WP:RFA Guide and lead to unnecessary drama. Ivanvector (talk) 16:11, 25 February 2015 (UTC)
  • Neat idea. I'd say to keep the criteria pretty minimal. Don't require that the editors worked in certain areas, for example. The bot shouldn't disqualify a vandal-fighter due to lack of featured articles, nor an article writer for an absence of speedy delete noms. I'd say a one-year and 5,000 edit criteria, with removal from the list for certain red flags (such as blocks, frequently declined speedy deletes, excessive activity at admin's noticeboard, a more than one accusation at sockpuppet investigations, etc). And I agree that the bot should only generate a list for humans to review. The bot could also list the non-ideal editors and state what tripped its red-flag detector. Oiyarbepsy (talk) 19:33, 25 February 2015 (UTC)
  • For those who don't remember, Scottywong had an Admin Score Tool to calculate an editor's readiness for RfA. See User:Scottywong/Admin scoring tool results for an example of the results as of 4 March 2013. Unfortunately, with the migration to WMFlabs, many of the inputs for that tool can no longer be accessed and so the results of the calculations don't have the desired meaning now. But this approach could be updated and used as a model if someone is interested. --Arxiloxos (talk) 19:57, 25 February 2015 (UTC)
    I'm going to place a comment here to emphasize that this has been done but no one moved/maintained the tool for Labs. (I happen to be listed there too as of that date—I have a big gaping hole in my contributions from a recent wikibreak but have been returning slowly to editingpontificating here.) --Izno (talk) 22:29, 25 February 2015 (UTC)
  • I emphatically applaud Mr. Stradivarius for thinking outside the box here. This idea certainly has the potential to be useful, however I agree with Ivanvector that it wouldn't be ideal for the bot to notify prospective candidates directly. Perhaps a table of prospective candidate could be compiled. Nominators could survey the table and approach candidates they deemed to be qualified. If the candidate declined the offer, a note could be made of this on the table. (In other words, this would be very similar to the admin score table above.) Mellowed Fillmore (talk) 21:07, 25 February 2015 (UTC)
  • If this bot was created, there'd need to be a thing you could put on your user page to exclude you from being considered if you don't have any interest in being an admin. Reyk YO! 21:12, 25 February 2015 (UTC)
  • I agree with everyone else who has said this is a good idea; but have the bot make a chart or list for others to peruse. ~ ONUnicorn(Talk|Contribs)problem solving 21:44, 25 February 2015 (UTC)
  • I have no objection to such a bot as long as it is exclusion compliant and I can opt out if I so choose (for example if I'll be on wikibreak (like I kind of am now)). — {{U|Technical 13}} (e • t • c) 22:26, 25 February 2015 (UTC)
  • As others have said, simply creating a list for human review would be best. Also, although I agree candidates shouldn't be excluded for not performing a certain activity, such as AIV or FAs, I think there should be something - so, perhaps, 6000 edits, 1 year tenure, no significant blocks, as well 50 AfDs or 100 AIV reports or 1 FA - just an example. BethNaught (talk) 22:38, 25 February 2015 (UTC)
  • Can the bot also look at the user's number of recent edits and account age, as well as anti-vandalism, new page patrol, etc., then put them in a table for human nominators to review? I will support such a scheme, but not a bot nominating candidates directly. Epic Genius (talk) 23:00, 25 February 2015 (UTC)
@Epicgenius: To be clear, that isn't the proposal, the bot would only leave a message suggesting they might think about running. BethNaught (talk) 23:02, 25 February 2015 (UTC)
@BethNaught: Sorry, I may be a bit confused about what this bot should do. This function can be run using another bot that documents all these things. (Also, this other bot should document the number of blocks that the candidate has, complaints about the candidate, SPIs, etc. Epic Genius (talk) 23:05, 25 February 2015 (UTC)
  • Strong oppose: Oh the devilish tangles created by the well intentioned. Everyone thinks this is a good idea. Look down the road. People will be referring to it saying candidate so-and-so wasn't picked up by the bot. This will codify a nightmare; the perennial proposal of prerequisites to adminship, which only just recently went up in flames. The well intentioned here tried to draw a connection between a potentially good candidate and AfD. Guess what? I recall a study that showed the more someone participated in AfD the less likely they were to succeed at RfA. Here's the reality; you don't need a bot to tell you who is likely a good candidate. If you're obsessed with finding high edit count people who aren't admins see Wikipedia:List of Wikipedians by number of edits. It's nicely marked to tell you who is already an admin. More importantly, people who are experienced enough and potentially ready to be administrators already know about RfA and don't need to be told. This bot isn't going to increase the number of candidates at RfA, much less good candidates. --Hammersoft (talk) 23:23, 25 February 2015 (UTC)
    People could still run if they weren't picked up by the bot, so the criteria wouldn't be official. I can see the problem with unofficial criteria becoming perceived as official criteria, though. How about instead of a simple yes-or-no decision, we have the bot generate a score, like Scotty Wong's admin score tool does, and just make a list of every editor with their score? Also, I have tried finding admin candidates from Wikipedia:List of Wikipedians by number of edits, and there are a number of drawbacks with it. The biggest one is that you have no idea if someone has looked at that person's edits before, or whether they are actually interested in running for RfA. That can lead to a lot of wasted effort. And as for saying "you don't need a bot to tell you who is likely a good candidate", you should try it some time. :) If you are the kind of person that doesn't like to rely on just gut feeling, there are quite a few things that you need to check when you review a candidate (see my checklist, for example). Quite a few of those checks could be automated to some degree, which would save nominators time. — Mr. Stradivarius ♪ talk ♪ 00:50, 26 February 2015 (UTC)
    In the UK, an educational test called SATS was introduced to see how well kids of certain ages were achieving. Great idea. But... Parents quickly regarded it as an exam to be passed. And the teachers proceeded to teach the kids TO pass it, even though there wasn't a pass/fail standard as such built in. Regardless of the intention of assessing both the progress of the kids AND the success rate of the teachers, it became a source of stress to kids and teachers alike. Why am I telling you this? Because I reckon, like Hammersoft, that this list of potential candidates WILL become a list of those who fit the pattern and only those will get !voted for. The intentions are great. But a hell of a lot of safeguards need to be built in to avoid having a SATS disaster and a load of cloned candidates. Like the cloned MPs that the UK has at present. Peridon (talk) 17:53, 26 February 2015 (UTC)
  • Just adding my thoughts. Overall I like the idea, very much. However, as other people have indicated, I seem to think it'd be better if the bot were to compile a list of possible candidates for OTHER nominators to peruse. This will be a more realistic determination on a candidate's suitability, and is less likely to instil false confidence/hope. Also, one must not get drawn into making the bot have high targets in specific areas of contribution. Whilst people may have their criteria, each candidate will always be stronger or weaker in certain areas than others. Orphan Wiki 23:41, 25 February 2015 (UTC)
  • Neutral, having a bot might be going a bit too far, but we do need to have a good admin score tool up and running. This one is missing some things (because of blah blah blah, aka a bunch of technical jargon-filled reason) and I brought that up once before about getting it fixed, but nothing ever happened. Let's get the tool fixed first. --AmaryllisGardener talk 03:06, 26 February 2015 (UTC)
  • Comment I don't think the problem is a technical one, so using a technical solution seems counterintuitive for me. All too often, the problem isn't locating them, it is convincing them to run for a variety of reasons. RFA itself is infrequently quoted as the reason, the hassles of simply being an admin is the biggest concern, and a valid one. The Editor of the Week program at WP:WER has found us 4 or 5 people who are now admin in a very short period of time, and the nominations are by any and everyone, then vetted by volunteers at WER. Perhaps more programs like this would be helpful, as they engage the entire community to find quality contributors. Dennis Brown - 2¢ 08:41, 27 February 2015 (UTC)
  • Strong support I think this is a great idea. For all we know there are dozens of potential admin candidates out there who might be interested in running if they are told they can. The bot would just find the account, the RFA process remains the same so there is no problem there. I'd love to see this implemented. §FreeRangeFrogcroak 18:11, 27 February 2015 (UTC)
  • Hmm? If the issue is letting people know they can run for adminship, then spam all accounts with a notice that adminship is available to those who pass RfA, and give them a pointer to relevant documents. We don't need a bot. --Hammersoft (talk) 18:41, 27 February 2015 (UTC)
  • Yes it does, it says "Then if the bot thinks that a user is a good potential candidate, then it could leave a message on that user's talk page asking them if they would be interested in running for adminship." --AmaryllisGardener talk 19:50, 27 February 2015 (UTC)

Would this bot be too complicated?

Reading the above, one issue is that this bot would be very complex, which is concerning. We would need a top-notch code writer to make this happen, and the potential for errors would be high. Oiyarbepsy (talk) 19:34, 25 February 2015 (UTC)

I don't think it would be too complex; check if the user has made over some number of edits, if they are not blocked, if they have made so many AfD votes, if they have been active for the past 6-12 months, etc. I'm no bot coder and obviously we'd put some more parameters in but I can't imagine that's hard to search for. Sam Walton (talk) 20:06, 25 February 2015 (UTC)
We've already had something like this: the adminscore tool. It's not working anymore - it can't access most of the things it checks for - but it would probably be a good starting point. However, I don't think a bot would solve all our problems; it should only be used to identify potential potential candidates, then checked by hand and taken with a couple bushels of salt (I remember when adminscore was still working it had several editors who the community would never have approved among its top scores). Also, feature creep would be something to be careful of - start adding in every single possible factor and then yes it would eventually become too complicated to the point of uselessness. ansh666 02:21, 26 February 2015 (UTC)
Next time I should read the entire thing before commenting...oops. ansh666 02:22, 26 February 2015 (UTC)

List or notification

So should such a bot directly ask users to run for adminship, or should it produce a list with humans given the job of asking? Oiyarbepsy (talk) 21:22, 27 February 2015 (UTC)

As I mentioned above, I would go more in the direction of the latter suggestion. Producing a list of potential candidates. Then, experienced users/admins/nominators can study potential candidates, and decide if it's definitely worth contacting the editor with a view to running for RfA. It's a more thorough job, RfAs will have a better chance of success, and false hope/confidence will not be instilled. Orphan Wiki 20:40, 28 February 2015 (UTC)
If it was a list I would be willing to support. --AmaryllisGardener talk 20:43, 28 February 2015 (UTC)
I'm in the "list" camp as well, per my comments above. I'm not against the idea of notifying users directly, but given the trial by ordeal nature of RfA, I think there's some non-trivial risk of driving good but not quite admin-candidate editors away if they are invited by a bot to run with no prior human vetting, only to face the mob. Ivanvector (talk) 23:46, 2 March 2015 (UTC)

So what about a bot that periodically goes through all external links of all pages (mainly being references) to check if they are offline/down?

Then, associated with that, there could be some kind of (explicitly or not) a "offline-link-checking-task-force" which then goes through these links to replace them with archived, newer or alternative versions of the pages that are still online. And(/or) those who are watching the article could be notified somehow that a link is down so that they search for an archived (mostly via the Wayback Machine - web.archive.org), newer (sometimes sites just relocate their content) or alternative version. The simplest way this could be done would probably having the bot do a small edit on the page (like a tag or a comment - this would nevertheless require a corresponding change in the Wikipedia platform).

--Fixuture (talk) 19:26, 2 March 2015 (UTC)

Well, so I just found this: https://wiki.riteme.site/wiki/Wikipedia:Link_rot#Automated_tools
It says There have been bots (the semi-automated RjwilmsiBot) that automatically identify and flag dead links with [dead link]. - However note the have been -> why aren't there any active bots of that kind? I think such would be truly useful. But I guess I should move this request to the page... --Fixuture (talk) 17:45, 5 March 2015 (UTC)
I also just found: https://wiki.riteme.site/wiki/User:Dispenser/Checklinks --Fixuture (talk) 18:41, 24 March 2015 (UTC)

Make this page more visible / improve user-feedback-ability (suggestions) / Betterific

I found this page relatively hard to find so maybe it could be linked on some pages to improve its visibility etc. Also the user friendliness (for the submission of suggestions) could be improved in various ways. One of the problems is that it's hard to find whether or not a suggestion has already been made -> there should be some easy search for this - and maybe also something like tags.

advertisement for private web site removed

--Fixuture (talk) 19:40, 2 March 2015 (UTC)

Well someone removed the link. It's not advertisement though. I have no interest in that (and am not affiliated in any way with the site). But the site's for collecting ideas. Those ideas are grouped by topic. One of those is Wikipedia. So what I linked is a 3rd party website for ideas/suggestions for Wikipedia. Just wanted to clarify this. What's the reason it's considered "advertisment" even though it's related to the post here? Other external links in such discussions don't get removed. (That's not the point of the above post though) --Fixuture (talk) 22:18, 3 March 2015 (UTC)
Just found this: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Ideas#idealab-new - I think that goes into the direction I was speaking about here. Is this just for Wikimedia? One reason I linked the betterific-site was to show that many people actually have suggestions for improvement / ideas for the site but don't post it on this site / use a feedback-function of it etc. --Fixuture (talk) 15:24, 5 March 2015 (UTC)
For a while we had the article feedback tool that let readers comment on article. Unfortunately, we don't have nearly enough volunteers to go thru the comments and we turned it off. Another third-party site that frequently comments on improving the project is Wikipedia Review, altho most of their coverage is negative. Oiyarbepsy (talk) 16:07, 5 March 2015 (UTC)

A tool to watch for additions to Categories

That would be truly useful. When I first used the watch function on a category-page I actually thought that's what it's for. In 2009 there has been a request for this before. But it remained unresolved. Should one file an issue on the wiki-code or something (if so where)? Or maybe is there any news on that?

--Fixuture (talk) 20:36, 3 March 2015 (UTC)

This is definitely something I would make use of. Sam Walton (talk) 19:02, 4 March 2015 (UTC)
I'm not a technical whiz but it seems like this would be difficult to implement since the changes are made to the article, talk, user or policy page (when a category is added or removed) and not to the category page itself. I work with categories and every time I edit a category on a page, the page is added to my watchlist so I can see when categories are altered on those pages but since categories are a form of sorting, the category page itself wouldn't hold much information unless the category page is recategorized itself. Liz Read! Talk! 16:29, 5 March 2015 (UTC)
Well eventually it would require a different approach for tracking changes to category-articles. Technically it should be relatively easy to detect a change of the html-document/site, it's just a bit different from how changes to articles are tracked (so eventually one also wouldn't see a "difference-comparison" but an entry like "Article [[X]] added to Category [[Y]]" on ones Watchlist). --Fixuture (talk) 17:29, 5 March 2015 (UTC)
I thought we had something similar on Toolserver, we have the cl_timestamp in the categorylinks table. I'd whip up something easily, but I'm blocked on Labs. — Dispenser 17:43, 5 March 2015 (UTC)

Hi Fixuture, check out these:

Do also have a look at https://tools.wmflabs.org/magnustools/ -> categories, awesome stuff! --Atlasowa (talk) 20:51, 5 March 2015 (UTC)

A wish list for images of objects/places/buildings/memorials/... -> photo-requests with location

Often, when writing an article one might think of a fitting photo with no photo of it being available on the net (at least not with creative commons license or in good quality).

So a wish list for photos would be truly useful in such cases. One could simply file a new photo-request there and someone living in proximity of it could go and take a photo of it.

For this there the requests should also include the geolocation of the object/.. so that people could look up requests for their local area. There could also be photo-requests that aren't confined to specific locations but access to specific objects and the like - for these type of photo-requests there could be tags that describe or name the object.

If something like this already exists I couldn't find it.

--Fixuture (talk) 22:39, 3 March 2015 (UTC)

Sounds like a job for {{Image requested}}. Place on the talkpage of the article and it gets listed in various categories of picture-needed based on location or subject. DMacks (talk) 22:51, 3 March 2015 (UTC)
Where would this geographical based list be? If we could get a reasonably specific sort, then some of us who do upload pictures could know what needs to be shot when we are in a particular area. Frankly, its too massive a job to search individual articles, so suck a list that sorts by location would be very useful. Trackinfo (talk) 01:31, 4 March 2015 (UTC)
See various subcats of Category:Wikipedia requested photographs in places. Different levels of "reasonably specific" depending on what geographical area you have in mind. DMacks (talk)
I did need to search 7 layers deep, but I was able to zero in on an area I drove through since the previous message. Had I known, I could have snapped the perfect picture. Great light, I had plenty of time. It might be months before I go there again, but now I have a list of a few places I can get. Now how do we make this more public? Trackinfo (talk) 06:43, 4 March 2015 (UTC)

Hi Fixuture and Trackinfo, have a look:

  • wikishootme with map
  • alexz's tool: Geotagged pages needing image (Search for pages near the coordinates on another article)
  • commons:Commons:Unvisited app: Unvisited is a Google Play application for planning photography trips for images for Wikipedia. Unvisited finds Wikipedia articles that are missing an image in the vicinity of the user's GPS coordinates and plans trips to get as many photographs as possible in the shortest distance. An iOS version is currently in beta.

Happy hunting! :-) --Atlasowa (talk) 21:07, 5 March 2015 (UTC)

Something similar to WikiTrust

Not sure if this is the right place to bring this up, but anyway. A few years ago there was a tool developed by some people at UCSC called WikiTrust (see also WP:WikiTrust and http://wikitrust.soe.ucsc.edu/home). It worked like this: "When installed on a MediaWiki website it enables users of that website to obtain information about the author, origin, and reliability of that website's wiki text. Content that is stable, based on an analysis of article history, is displayed in normal black-on-white type, and content that is not stable is highlighted in varying shades of yellow or orange." (from WP:WikiTrust) I found this to be very useful, since I've found that vandalism often gets past unnoticed at Special:RecentChanges because another, constructive edit is made on top of the vandalism, or a bot reverts the most recent vandalism but misses vandalism by a different user directly before the reverted user. WikiTrust also allowed the user to click on a word and be taken back to the diff in which it was added, which is a lot easier than having to laboriously go back through the changes by hand. Unfortunately, for whatever reason, the tool was taken offline in 2012 and hasn't been back since. WikiTrust itself naturally had many bugs and flaws, but the idea, I think, has a lot of potential. The WikiTrust is opensource, so the original code could be relaunched, or something new with a similar function could be created. I know next to nothing about coding myself, so I've brought this here. Maybe it could be developed by MediaWiki?  Liam987(talk) 01:45, 4 March 2015 (UTC)

Schnark artikel-statistik of de:Inversor von Peaucellier, old version
Hi Liam987, i'd recommend de:Benutzer:Schnark/js/artikel-statistik. At your own risk, and better use it on small-to-middle-size articles. Add the user script in Special:MyPage/common.js:
mw.loader.load('//de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/artikel-statistik.js&action=raw&ctype=text/javascript'); //[[Benutzer:Schnark/js/artikel-statistik.js]]
See also my collection at de:Benutzer:Atlasowa/edit_history_visualization, especially "Xtools Articleinfo / Article blamer" and "Replay Edits". --Atlasowa (talk) 21:22, 5 March 2015 (UTC)

Where is a good place to notify editors of a new service?

I'm offering a diff lookup service. Where would be a good place to let others know about its existance?Two kinds of porkMakin'Bacon 06:45, 7 March 2015 (UTC)

Here. Or Village Pump Misc. Or, if you change this to a project page, you could link it from WP:Diff in the see also section. BTW, I would suggest not providing oversight diffs, or because of how sensitive they are, maybe not even telling users you found them. Oiyarbepsy (talk) 08:53, 7 March 2015 (UTC)
Good point. Turns out I will only provide URL's, so any oversighted diff won't reveal anything. @Oiyarbepsy: could you help me turn this concept into a project page? I'm a bit out of my depth on this.Two kinds of porkMakin'Bacon 04:35, 8 March 2015 (UTC)
Well, I guess you wouldn't have to make it a project page to link it at WP:Diff, but it would be preferable. Making a project page means renaming it to WP:Diff lookup service or something, and allowing any editor to look up diffs for people. Oiyarbepsy (talk) 05:19, 8 March 2015 (UTC)

General opinion on physically restricting access to the New Pages Feed

(Note: This discussion was moved from Wikipedia:Village_pump_(miscellaneous)#General_opinion_on_physically_restricting_access_to_the_New_Pages_Feed per a suggestion at the beginning of the discussion. --Biblioworm 20:33, 18 February 2015 (UTC))

As of late, there have been plans by Jim Carter to start an RfC concerning physically restricting access to the the New Pages Feed. He has even started a JavaScript file that could perform that function. I have personally made it clear that I would oppose such a proposal, but that's not the point of this thread. I'm curious to see what the general community's opinion about this is before the formal RfC, should it go live sometime in the near future. I think it would be good to have a more public discussion about this. Thanks, --Biblioworm 01:57, 11 February 2015 (UTC)

  • Biblioworm, first thing I'll note is that this should have been at WP:VPI instead of here. Second, while I strongly oppose using user generated JavaScript to restrict access to an extension written and maintained by the Foundation, I would support a proposal to encourage newer users to obtain more experience before reviewing pages at NPP using whatever tools the Foundation finds appropriate. I'm even willing to contribute my time to work directly on the extension PHP/JS code to make appropriate changes so that wikis can customize their experience as to what requirements are set if any at all. Since the changes I'm willing to make to the extension are not enwp specific, the only question here will be whether or not enwp wants to participate and take advantage of the additional control. — {{U|Technical 13}} (e • t • c) 02:36, 11 February 2015 (UTC)
  • I don't like the idea of making the new pages feed invisible to all but some people. One of the advantages of Wikipedia over traditional encyclopedias is its transparency - that the history of drafts and revisions of articles is available to all readers, as is the discussion over how to present information. I think it's potentially useful to persons who might be non-editors to be able to see recent changes and new pages. Also, as someone whose first edits to Wikipedia involved pointing out a page that clearly needed to go (although at the time I didn't know how to go about doing it), I think having these pages available for viewing tells potential editors that their help is needed. ~ ONUnicorn(Talk|Contribs)problem solving 20:24, 11 February 2015 (UTC)

I see no reason to block anyone from seeing the new pages feed. I don't even see a reason to restrict access to the curation toolbar. The potential damage from misuse is pretty much nil. Oiyarbepsy (talk) 23:38, 11 February 2015 (UTC)

I strongly oppose to restrict users from accessing the New Pages Feed. --NaBUru38 (talk) 13:55, 14 February 2015 (UTC)
  • Per the above comments, this seems like a solution seeking a problem. Even if there was a problem, though, this is the wrong solution as basic features of Wikipedia need to be available to all editors. – Philosopher Let us reason together. 19:02, 20 February 2015 (UTC)
  • Oppose. I can see there are problems with incompetent new page patrol and that it needs to be addressed, but actually preventing the non-elite from even seeing the list of new pages is anathema to the egalitarian founding principles of Wikipedia - there are perfectly valid reasons for readers to want to see what is being newly created, and they should not be prevented from doing so. Squinge (talk) 19:15, 20 February 2015 (UTC)
  • Oppose. It's regrettable that we have to restrict anything to some editors. In many cases, of course, we have to, but it should only be done when absolutely necessary. As far as I can tell, and I am a frequent New Page Patroller, there has not been an issue with new users misusing the New Pages Feed. Most new users probably don't even realise it exists. This may well be a huge problem I simply have not heard of, but I find that hard to believe.  Liam987(talk) 01:56, 4 March 2015 (UTC)
  • Comment: While I applaud the creative thinking, I'm not sure that there's been enough of a demonstrated problem to justify resourcing to build a solution. As a general rule, I tend to favor openness over a closed system; transparency over opaqueness. It's one of our original values, and one that I believe was correct then, and remains correct now. In short, unless I were to see some demonstration of a wide-spread problem, if asked, I would likely advise that the WMF would not support such a switch. Philippe Beaudette, Wikimedia Foundation (talk) 15:05, 15 March 2015 (UTC)

A insane idea about reliable sources

About the topic of sources and reliability. The commentfield in the sources should be able to help out since there's some (Not all of course) intelligent discussions back and forth between several/many people on how they have read the situations (And for most comment field in most sources that has them enable). Wouldn't that be a point of interest for an observation depending on how well recieved a source is? The less comments complaining (If generally has been viewed/read of course) point out how well that source is? Perhaps something to think about, although maybe not relevant in the current situation but just a thought for the future since if they have a consensus it should be as objective as possible. Although it would hamper controversial articles but the more people that gather at a source the more fact splitting would come up to point of wether that part of the article can be trusted. Hmm. This is just a thought I just had when I was reading several articles and noticed the comment field below. As Such this is, as stated, a crazy hypothesis idea. Anything to gain from it? TheRealVordox (talk) 20:56, 8 March 2015 (UTC)

I guess you could use that as a basis, to detect when usually reliable sources fuck up. However, unreliable sources tend to have readers that believe the BS the source is spouting. Oiyarbepsy (talk) 20:22, 11 March 2015 (UTC)
Well it's true that the readers that the person writing the article has gathered with a followerbase will not often critize the article itself. If only there was a way for fact or source checking in the comments to be appreciated and more widespread. But perhaps it's too early for this kind of thought. It's a fun little thought though if used in the future when people are little bit more skeptic.TheRealVordox (talk) 10:58, 15 March 2015 (UTC)

WikiLink: Make it easier to look stuff up.

"WikiLink"

I'm not sure if this idea has been posed before, but most websites now come with the Facebook, linkedin, twitter icons that allow you to share articles etc.

An idea that came to me recently was a similar WikiLink icon. Once clicked, the website or news article would allow you to click on certain words right within the text itself and would bring up the relevant wiki page (perhaps a pop up window or embedded in the website itself). This would remove the need to open a new window, log into wiki and look up an item. You could click right on the text of the news article (for example). If you don't want the hyperlinks, just click back on the WikiLink icon to switch it off.

I think this development would widen wiki's reach (even more!) and help people look up info faster and easier.

This may have been posed before, so apologies if it has! I for one would find it useful and kinda fun.

Thoughts / comments / critique welcome!

Best

Tom--Tompope999 (talk) 15:53, 12 March 2015 (UTC)

You mean for other websites? That would have to be an browser extension. Still, its something that the WMF should look into. KonveyorBelt 17:33, 12 March 2015 (UTC)
I for one find those bloody popups with icons on them to be dire and they often interfere with the reading of a page - especially those ones that cling to the edge and obscure part of the text. You don't have to log into Wikipedia to read pages (unless you hate the Vector skin as I do - using WP on someone else's machine is torture). This idea has good points, but it would be up to the owners of the sites to implement, not us. There are some already that have underlined words that link here (via a new window or (spit) tab. It has to be built into the text of the page as it will be one hell of a lot of links overall. The four normally on the popups are just four things and they are not tied to specific text. (They're just there to annoy people like me.) Peridon (talk) 17:56, 16 March 2015 (UTC)

Free audio book recordings

I have begun listening to audio books (.mp3 files) and find there are thousands of them available for free on the web, many of these are in the public domain because the copyright on the underlying text expired long ago. I think it wold be a nice feature to have links to these recordings on the "book pages" in wikipedia; Not as a requirement, but an encouraged option. What do you folks think of this? There are various locations on the web where these files can be found and perhaps we could come up with a standardized, boiler-plate, template for referencing them. (each site with a different template) TimoleonWash (talk) 01:36, 14 March 2015 (UTC)

@TimoleonWash: Just because the book is free (as in freedom) doesn't mean that the recording is. Book and recording are two different works with two different copyrights. However, if you can demonstrate that both the book and the recording are free (as in freedom), you can upload them to commons and link the audio file to the article on the book. If the book itself is free, you can upload it to wikisource and link that to the article. This wouldn't require any special permission, it would just need someone to start doing it. Oiyarbepsy (talk) 03:13, 14 March 2015 (UTC)
Thanks Oiyarbepsy (talk) for the good info on copyright. I have checked both the text and the recordings and they are in the public domain. Regarding uploading files to wiki... Could I just provide a link much as I see being done with book pages linking to gutenberg.org? TimoleonWash (talk) 09:29, 14 March 2015 (UTC)
@TimoleonWash: We actually have a template for Project Gutenberg links at Template:Gutenberg. However, we do generally prefer that you upload things on Commons so that we aren't dependent on external websites. After uploading, you'd add it to the article with Template:Listen. Uploading would start at commons:upload. Also, none of these recordings would be in public domain because copyright expired, so you'll need to have some kind of documentation that the speaker has released it. Oiyarbepsy (talk) 14:46, 14 March 2015 (UTC)
Good news to have Oiyarbepsy (talk), thanks. I think loading things in to the common area would make a great project for someone sometime. I am interested in these templates though. Can you refer me to information about them; where they are stored, how they are used, how are they created, how is the community informed of them, etc.? TimoleonWash (talk) 15:28, 14 March 2015 (UTC)
Templates are elements used in a large number of pages that will appear the same in all of them. They include things like infoboxes, navboxes, standard ways of linking to particular sources, things like that. The mentions of those particular templates I discuss above are links. You would put them in an article kind of like this {{example}} if editing in wikitext, and visualeditor can put in templates as well. Click the links provided above and it provides instruction on how to use these templates in articles. Oiyarbepsy (talk) 17:38, 14 March 2015 (UTC)

I have investigated the links you provided and learned a lot, thx again Oiyarbepsy (talk). Then I discovered a template for an outfit called LibriVox which is the website where I have downloaded most of my .mp3s from. It looks like the template doesn't work anymore. How would I go about creating a new template for LibriVox and how would I go about locating all the existing wikipedia pages that use the existing, broken link to fix them? TimoleonWash (talk) 01:23, 15 March 2015 (UTC)

Hmm, Template:Librivox seems to work just fine at Anna Christie, The Time Machine and others, so I'm not sure why you're having trouble. Look at how those articles do it and try to emulate it on articles that don't have these links. The documentation that goes with the template shows how it should work, something like {{Librivox|The Time Machine}}. Oiyarbepsy (talk) 05:17, 15 March 2015 (UTC)
Once again you've rescued me Oiyarbepsy (talk). I thought the template didn't work because of what it said in the template so I'll update that. I saw how it is done in Anna Christie, etc and will follow this format. I think I'm set and I'm looking forward to this project because I love wikipedia and free audio books! TimoleonWash (talk) 23:10, 15 March 2015 (UTC)

Gun lobbying

Wikipedia shouldn't be a vehicle for gun lobbying, however the Americans have done exactly that. There is a gun_control article which is hopeless, mostly telling readers how "complex" the issue is . The several country articles all harmonised to say Gun politics in XXX, even though it's only a political issue in the US, and these articles are about the uncontested and implemented policy. Let the Americans enjoy their school-hall massacres, if that's what they want. I'm sure it makes gripping television*. If you're a proud citizen of a developed country, don't let Americans twist your laws, as politics. Call it what it is: gun control or gun policy, and make sure your children have easy access to stable, unbiased information. (*this is sarcasm. The US situation is unbelievably appalling.) 120.136.34.176 (talk) 06:28, 15 March 2015 (UTC)

We do have Gun_law_in_the_United_States Gun_laws_in_the_United_States_by_state and pages like Gun laws in Alaska, in addition to gun politics in the United States.
I'm not sure, but I think the reason we have Gun politics in Australia is because that allows for a wider scope of information than Gun laws in Australia would. Anyway, it seems that whether it is "Gun laws in X" or "Gun politics in X" varies a bit currently. We should always strive for WP:NPOV here. I personally dislike guns and don't like the laws in the USA either, but that is my POV, not encyclopedic. SemanticMantis (talk) 16:09, 16 March 2015 (UTC)
If "Gun politics in XXX" is not a notable topic, then there is a process in place for removal of such articles. But if suitable references can be found to demonstrate notability, then that presumably indicates the topic is valid for that nation-state. Wikipedia's neutrality policy should allow for suitable balance in representation of the main political views; ergo it's not "a vehicle for gun lobbying". Praemonitus (talk) 19:44, 19 March 2015 (UTC)

Not only but also

When looking for how to use Not only...but also (grammar) the answer is impossible to find unless you know they are conjunctions. 117.221.177.142 (talk) 00:49, 23 March 2015 (UTC)Biblio

Idea for a bot

This came up on review for an article at FAC: "In some places where there are two citations covering one fact, they are not arranged in numerical order." It took a gnome to fix it, but seems like something a bot could handle, at cheaper wages. Does anyone know if that is a possible task for a bot? If so, how does one go about getting it made or learning to make it? Sorry if this is not correct forum. --Gaff (talk) 07:46, 24 March 2015 (UTC)

  • I dislike putting cites inside a sentence. If a sentence has two facts supported by two cites, I would arrange the cites in the same sequence as the facts they support:
Smith obtained an MD in 1883 and a PhD in 1886.[14][11]
A bot would not be able to see that the two cites cover two facts rather than one. Aymatth2 (talk) 13:07, 24 March 2015 (UTC)
Where dies this rule come from? -- Gadget850 talk 14:35, 24 March 2015 (UTC)
  • I don't think there is a rule that says the cites should have the same sequence as the facts they support, or a rule saying they should be in numerical sequence. Probably it is a question of personal preference. The example above could dodge the issue by using cites within the sentence:
Smith obtained an MD in 1883[14] and a PhD in 1886.[11]
That seems cluttered to me. The issue can also be avoided by bundling citations. Aymatth2 (talk) 15:46, 24 March 2015 (UTC)
The numbering (and relative ordering) is subject to change when the WP:NAMEDREFS are moved around in the article as a whole. I agree it might not be that often, but the proposed task is not a one-time cleanup, and would probably need to do lots of parsing of the whole recent-changes feed to keep track. But more significantly, there might be some encyclopediac reasons to put them in some particular order, such as date. DMacks (talk) 14:45, 24 March 2015 (UTC)

New to Wikipedia

I think that three articles

  • Dear Boys (manga)
  • Kuroko's Baksetball
  • Cross over

need editing

any suggestions thanks! — Preceding unsigned comment added by NatsukiKazuhiko (talk • contribs) 23:13, 20 March 2015 (UTC)

@NatsukiKazuhiko: yes; be bold and make the edits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 25 March 2015 (UTC)

Wikipedia Code

I remember when I had just joined Wikipedia a little over a year ago. I remember feeling really confused and wondering where I should look for information on policy, guidelines, and rules. I have spent the last year learning about these policies, guidelines, and rules, yet I am still learning new policies every day. Part of this is because there is no central collection of policies guidelines, and rules.

My proposal is to start the equivalent of the US Code and United States Reports for the English Wikipedia and if successful for the Wikimedia community at large. The Wikipedia Code (as I am calling it) shall follow the following guidelines:

  1. Policies, guidelines, and rules contained in the code shall have reached consensus or for other reasons be enforceable.
  2. Notable discussions shall be included to give context and usage to policies, guidelines, and rules. However, when consensus has not been reached in a discussion that shall be made clear.
  3. Notable decisions by committees on cases shall be included to give context.

What do you think? StudiesWorld (talk) 19:59, 20 February 2015 (UTC)

The problem is that we don't have a "code" as is understood in government. All of our pages have exceptions, and all can be ignored if it clearly improves the encyclopedia. That said, provide more history and background to our policies and guidelines is a good idea. Oiyarbepsy (talk) 20:04, 20 February 2015 (UTC)
A list of everything would be, quite frankly, impossible, though Category:Wikipedia policies and guidelines tries. A full list would also be impossible to ever read - for that matter, it may just be impossible to read the entire Manual of Style! There are useful summaries at Wikipedia:List of policies and guidelines and the Wikipedia:Simplified ruleset. The useful templates {{Wikipedia principles}}, {{Wikipedia policies and guidelines}}, and {{Policy list}} are on both of those pages as well, and serve as a useful index. Do any of these serve the purpose you want, or is there something particular that is still missing? – Philosopher Let us reason together. 22:17, 20 February 2015 (UTC)
@Oiyarbepsy: By "code" I mean solely in the sense of an organized structure. It would also include explanatory text to take in to account the exceptions and notices explaining how rules can be ignored.
@Philosopher: I understand what you are saying but this would aim to be an all inclusive guide. Also, it would not be intended to be read in full but as a resource and reference.
Would you like me to make a draft in my userspace and move this discussion there? StudiesWorld (talk) 22:52, 20 February 2015 (UTC)
If you like. @StudiesWorld: - just be sure to ping me again when it's done! – Philosopher Let us reason together. 01:34, 21 February 2015 (UTC)

In case you hadn't seen it, Cinderella157 brought up something similar (but not, I think, the same) at WP:VPR#Suggested improvement for accessibility by editors. – Philosopher Let us reason together. 01:38, 21 February 2015 (UTC)

@Philosopher: I skimmed through Cinderella157's proposal and I noticed the community portal. I think that if this idea ever comes about it should be integrated with the community portal. Also, I will try and throw together a draft over the next few days. StudiesWorld (talk) 11:07, 21 February 2015 (UTC)
UPDATE: I started the Wikipedia Code at User:StudiesWorld/Wikipedia Code. StudiesWorld (talk) 11:57, 21 February 2015 (UTC)
I am sympathetic to this problem—I remember spending a lot of time immediately after I joined simply reading help and Wikipedia pages and getting attenuated to the sheer mass of all of the policies. However I suggest you formalize some sort of list for discussion before putting it for comment, and then look for refinements from there. ResMar 04:18, 23 February 2015 (UTC)
@Resident Mario: I am working on a example to use in further discussion. StudiesWorld (talk) 11:43, 24 February 2015 (UTC)
The Five pillars are a starting point. The other two Very Important Documents would be AGF and the MoS. Whatever you do, though, definitely emphasize AGF and CIVIL. Eman235/talk 01:41, 9 March 2015 (UTC)
Oh man, just found this! Template:Wikipedia principles Eman235/talk 01:42, 9 March 2015 (UTC)
Start it up in user space. Grognard Chess (talk) Ping when replying 00:46, 12 March 2015 (UTC)

Possible Framework

The Original Poster has suggested that a code, in the legal sense, be developed. I would be very interested in seeing a framework or draft in user space for the code, which could consist of pointers to existing policies, or could actually work the policies together. The main criticism that I have seen is actually an argument in favor, which is that every policy has exceptions. In a legal code, the exceptions are also codified as exceptions. It is also stated that there is too much to codify. That is also an argument in favor of codification. Has anyone actually seen the entire United States Code, which took my grandfather at least ten years to codify and which occupies a whole shelf in bound form (which is seldom used anymore because it is now on-line)? The large number of disjointed policies and guidelines are an argument in favor of codification in some form, probably an index with pointers to the multiple policies and guidelines. The one problem that I see is the concept of Ignore All Rules, which does not really mean what it appears to mean anyway, but means to use common sense when the rules are too restrictive. Its problem is that it is sometimes cited by editors who don't have common sense. (Fortunately, most administrators do have common sense, and the RFA process usually gets editors who have common sense.) Some sort of a code framework seems to me to be an excellent idea, at least as a draft. Robert McClenon (talk) 16:09, 9 March 2015 (UTC)

Please be careful with categories

Don't copy any categories that are reserved for Wikipedia space into user space (such as the Wikipedia content policies category). - Dank (push to talk) 20:05, 25 March 2015 (UTC)

Link to specific content in article (with highlighting)

There is currently a proposal on Phabricator to add a new feature to MediaWiki where one could link to a specific part of an article's content. When someone visits this special link, they would be scrolled down to the relevant part of the content and possibly, the specific portion would be highlighted.

Before we get started with work on this, we wanted to know if this would be useful at all or whether it would help in any way. Comments? — Preceding unsigned comment added by Vghaisas (talk • contribs) 19:04, 19 February 2015 (UTC)

I don't think this would be significantly useful, as we already can create links to any kind of section header, footnote anchor, etc. If a section is too long for such a link to be useful, it's a sign that the section should be split, not that a new kind of link is needed. It would actually be unhelpful, I'm sorry to say, because it creates yet another feature for new users to have to learn, making Wikipedia editing appear even more complicated than it already is. – Philosopher Let us reason together. 18:59, 20 February 2015 (UTC)

The proposed feature isn't really meant for editors. It's a feature that will let readers link to arbitrary portions of the content. So it won't add any complexity to the work of editors.

However, I do agree with the other objection you raised. Sections shouldn't be so long that parts of them need to be linked to. However, how many pages match that objective? If there are still enough pages whose sections are long, would it not help readers to be able to link to specific portions of the content? — Preceding unsigned comment added by Vghaisas (talk • contribs) 19:04, 19 February 2015 (UTC)

"will let readers link to" - and creating a link is an article is editing. The use of these links in articles will be inevitable (unless prohibited by a filter) and would complicate the code, confusing new editors.
As for the section length, Wikipedia is not finished. That we don't yet meet an ideal doesn't mean that we should create a tool, but that we should strive to meet the ideal. – Philosopher Let us reason together. 00:37, 24 February 2015 (UTC)
I'm not sure we're on the same page here. The feature I'm talking about will provide an interface to let a random reader of Wikipedia select an arbitrary portion of the content of an article and generate a link to that selected content. To give a crude example, I could choose to link to the words "Predominantly nocturnal" in the second paragraph of European Wildcat , which could result in a link like (completely random example) https://wiki.riteme.site/wiki/European_wildcat?specific=p2w2. When someone visits that link, they will be scrolled down to that section and the two words will be highlighted. This will not involve making any changes to wiki markup.
Were you, though, referring to the fact that then links like https://wiki.riteme.site/wiki/European_wildcat?specific=p2w2 would be used in articles for inter-article linking? — Vghaisas (talk) 12:35, 25 February 2015 (UTC)
You mean something like the way Google does it with books, like this? Squinge (talk) 13:22, 25 February 2015 (UTC)
Yes, exactly. Thank you for that example. Something similar to that. Vghaisas (talk) 13:28, 25 February 2015 (UTC)
@Vghaisas: Yes, hat was exactly my concern. – Philosopher Let us reason together. 00:26, 27 February 2015 (UTC)
Philosopher: So, your opinion is that the availability of such links will lead to an extra complication in editing of articles and hence, is not a good idea? — Vghaisas (talk) 02:33, 27 February 2015 (UTC)
Yes, that is my primary concern. If there was some compelling reason that we needed such links, it could overcome it, but as I noted above, section headers are more than sufficient for linking to specific areas of the content - our sections are significantly shorter than most Google Books! and should never be so long that it's hard to find specific content within them - so there is no such need. – Philosopher Let us reason together. 02:39, 27 February 2015 (UTC)

Vghaisas, what would happen to your link when someone removes those words from the article? Text changes more often than section headings. Or what happens when someone adds multiple copies of those words, and I meant to highlight the third instance? WhatamIdoing (talk) 00:36, 27 February 2015 (UTC)

WhatamIdoing: The example I gave of ?specific=p2w2 was very random. The challenge is developing a method that can account for changes in text, possibly by using identifiers that do not depend on how many times the words appear in the article. In addition, if the given text gets deleted, there is the option of looking at the history of pages. The basic question is, is it a good enough idea to try and attempt this at all or is there something which makes it too bad an idea to even give it a try. — Vghaisas (talk) 02:33, 27 February 2015 (UTC)
Interesting idea. Definitely more of a reader-focused feature. Not an easy problem. Throwing anchors everywhere in the wikitext is not really an option.
I think direct-linking-to-Wikipedia-sentence is interesting for Wikipedia readers: "Fact checking to resolve disagreements" is one of our biggest use cases. :-) Giving a direct link to the Wikipedia sentence and say "See i told you so" and "Wikipedia agrees with ME, see" or "You were right, according to the Wikipedia article" etc. The Wikipedia mobile app for android wants to experiment with a feature "Tweet a fact" (Example tweet), which turns the highlighted sentence in a picture (afaics). A bit, ehm, indirect for linking... I'd be interested how this sentence-level-linking could be done differently! :-) --Atlasowa (talk) 13:50, 27 February 2015 (UTC)
Major Wikipedia use case: Fact checking to resolve disagreements!
Mark Wikipedia text in android app and "Tweet a fact" (Example tweet)

More tweets! Looks really good, except for the CC-BY-SA image attributions... Ping User:DarTar? --Atlasowa (talk) 22:11, 5 March 2015 (UTC)

@Atlasowa: Thanks for the interest! I've been working very closely with the Legal Team to make sure that the attribution in these images is appropriate. We have signoff from Legal for the present state that this feature is in, so we're good for now. --Dan Garry, Wikimedia Foundation (talk) 01:25, 7 March 2015 (UTC)
Dan Garry, i'm curious: There is no attribution to the photographer (CC BY 3.0 Biso, File:Fender_bw.jpg), not even a link to the image file, how did you get "signoff from Legal" for that? And on the other hand "Wikipedia®" gets a Registered trademark symbol? Really strange. Can you provide a link to this signoff/decision?
BTW, what happened to the GDFL licence in the app, how can that disappear (only CC-BY-SA, compare with licences in desktop/mobile Wikipedia edit window)? --Atlasowa (talk) 15:45, 11 March 2015 (UTC)
I am not a lawyer so am not qualified to answer your questions. These would be good questions to direct to Stephen LaPorte, the Legal Team's liaison to Product and Engineering. --Dan Garry, Wikimedia Foundation (talk) 16:21, 11 March 2015 (UTC)
Hi Atlasowa, the icons in the interface reflect the license for the text of Wikipedia articles, which may also contain media with other compatible free licenses (or public domain content). The limited amount of space in the card is our biggest design constraint. The icons provide a reasonable amount of information about the license for the card, and they communicate that it can be shared and remixed. If users wish to get the full licensing details for content, they can follow the URL that the app generates with the card. Thanks, Stephen LaPorte (WMF) (talk) 19:59, 12 March 2015 (UTC)

Linking to text in a specific revision wouldn't have any of those complications and shouldn't be to hard to do, and still useful. Oiyarbepsy (talk) 03:26, 7 March 2015 (UTC)

Oiyarbepsy, how would you do it? --Atlasowa (talk) 15:46, 11 March 2015 (UTC)
Atlasowa Well, once Mediawiki does it, it would be like en.wikipedia/wiki/ArticleName&oldid=1234567&starthighlight=78&endhighlight=85, where oldid is the specific revision, starthighlight is the character to start highlighting on and endhighlight is the character to end it on. The challenge is creating some kind of interface that makes it easy to create such a url, since without it, this would be exceedingly difficult to do. Perhaps a feature where you could select text, right-click it, choose "create link with this text highlighted" and the Mediawiki software would create the URL, with oldid and everything. Oiyarbepsy (talk) 20:10, 11 March 2015 (UTC)
Oiyarbepsy, fair point. With the revision id also included in the URL, most of the issues raised earlier aren't relevant any more. We, would, however, need to ensure that the page clearly states that "the updated version of this page exists elsewhere and may have been edited in the meantime" or something like that. In any case, you think it would be a useful feature to have? — Vghaisas (talk) 16:42, 26 March 2015 (UTC)

Editor retention message

What do people think of this idea... Posting a message to user talk pages of users who have not edited in X amount of time but made constructive edits before to try coaxing them back into editing. An obvious factor that would exclude a user is they are on a break, either involuntarily (user is currently blocked for any reason) or voluntarily (a template in Category:Wikibreak templates is on their user page). Included in the message would be mentions of things that either didn't exist when they stopped editing, or a user may not know exist. Here's my impetus for this suggestion: I was speaking in person to a user who said that although they received a welcome template when they started in 2009, they didn't know that there are so many help resources available, specifically the Teahouse, the Help Desk or the IRC channels because they weren't mentioned in the welcome. The Teahouse was created in 2012, so it wouldn't have been. If there is opposition to bot-placed messages of this kind, is there a way of compiling a list of users who haven't edited in say, 6 months, and are not blocked or on break so it could be done manually? --Geniac (talk) 16:31, 8 March 2015 (UTC)

It's a great idea. GoodDay (talk) 18:38, 8 March 2015 (UTC)
  • This would assume they are logging in regularly, but just not editing, a premise that I'm not prepared to accept without evidence. If they quit logging in, they won't see it. You could email, if they have an email, but that borders on spam. Good intention, but not sure how effective that would actually be. Dennis Brown - 2¢ 19:20, 8 March 2015 (UTC)
Actually, Dennis, I get an email anytime someone posts on my talk page. I expect this is the case for most editors. This email generally only gives the heading for the posts, so the heading would have to be chosen carefully. Oiyarbepsy (talk) 19:46, 8 March 2015 (UTC)
It isn't that I can tell, that is an opt in. Many users don't have email enabled or listed here to begin with. Until we had stats on how many opt in, it is hard to say with any authority. Dennis Brown - 2¢ 19:53, 8 March 2015 (UTC)
Yup, getting emails about edits to our own usertalkpage, are opt-in (see Special:Preferences#mw-prefsection-echo, and I just reset my preferences (on a test account) to confirm.
I support the general idea proposed. Quiddity (talk) 22:22, 8 March 2015 (UTC)
I, too, think the idea has merit. I'd like to see a structured and controlled A/B test to measure impact - which shouldn't be too hard - but I love the idea. Philippe Beaudette, Wikimedia Foundation (talk) 14:54, 15 March 2015 (UTC)
See also this 2012 experiment. Regards, HaeB (talk) 15:43, 16 March 2015 (UTC)
That's an interesting project with promising results. I don't know how to go about conducting a research project like that, but perhaps we could conduct one with similar metrics as that, and adding talk page posting as a separate group, to test results between the two methods of contact. --Geniac (talk) 20:56, 21 March 2015 (UTC)
I think if most (or even some) users can receive the message properly, it is a great idea. Good luck! Tony Tan98 · talk 19:27, 26 March 2015 (UTC)

Link to specific content in article (with highlighting)

There is currently a proposal on Phabricator to add a new feature to MediaWiki where one could link to a specific part of an article's content. When someone visits this special link, they would be scrolled down to the relevant part of the content and possibly, the specific portion would be highlighted.

Before we get started with work on this, we wanted to know if this would be useful at all or whether it would help in any way. Comments? — Preceding unsigned comment added by Vghaisas (talk • contribs) 19:04, 19 February 2015 (UTC)

I don't think this would be significantly useful, as we already can create links to any kind of section header, footnote anchor, etc. If a section is too long for such a link to be useful, it's a sign that the section should be split, not that a new kind of link is needed. It would actually be unhelpful, I'm sorry to say, because it creates yet another feature for new users to have to learn, making Wikipedia editing appear even more complicated than it already is. – Philosopher Let us reason together. 18:59, 20 February 2015 (UTC)

The proposed feature isn't really meant for editors. It's a feature that will let readers link to arbitrary portions of the content. So it won't add any complexity to the work of editors.

However, I do agree with the other objection you raised. Sections shouldn't be so long that parts of them need to be linked to. However, how many pages match that objective? If there are still enough pages whose sections are long, would it not help readers to be able to link to specific portions of the content? — Preceding unsigned comment added by Vghaisas (talk • contribs) 19:04, 19 February 2015 (UTC)

"will let readers link to" - and creating a link is an article is editing. The use of these links in articles will be inevitable (unless prohibited by a filter) and would complicate the code, confusing new editors.
As for the section length, Wikipedia is not finished. That we don't yet meet an ideal doesn't mean that we should create a tool, but that we should strive to meet the ideal. – Philosopher Let us reason together. 00:37, 24 February 2015 (UTC)
I'm not sure we're on the same page here. The feature I'm talking about will provide an interface to let a random reader of Wikipedia select an arbitrary portion of the content of an article and generate a link to that selected content. To give a crude example, I could choose to link to the words "Predominantly nocturnal" in the second paragraph of European Wildcat , which could result in a link like (completely random example) https://wiki.riteme.site/wiki/European_wildcat?specific=p2w2. When someone visits that link, they will be scrolled down to that section and the two words will be highlighted. This will not involve making any changes to wiki markup.
Were you, though, referring to the fact that then links like https://wiki.riteme.site/wiki/European_wildcat?specific=p2w2 would be used in articles for inter-article linking? — Vghaisas (talk) 12:35, 25 February 2015 (UTC)
You mean something like the way Google does it with books, like this? Squinge (talk) 13:22, 25 February 2015 (UTC)
Yes, exactly. Thank you for that example. Something similar to that. Vghaisas (talk) 13:28, 25 February 2015 (UTC)
@Vghaisas: Yes, hat was exactly my concern. – Philosopher Let us reason together. 00:26, 27 February 2015 (UTC)
Philosopher: So, your opinion is that the availability of such links will lead to an extra complication in editing of articles and hence, is not a good idea? — Vghaisas (talk) 02:33, 27 February 2015 (UTC)
Yes, that is my primary concern. If there was some compelling reason that we needed such links, it could overcome it, but as I noted above, section headers are more than sufficient for linking to specific areas of the content - our sections are significantly shorter than most Google Books! and should never be so long that it's hard to find specific content within them - so there is no such need. – Philosopher Let us reason together. 02:39, 27 February 2015 (UTC)

Vghaisas, what would happen to your link when someone removes those words from the article? Text changes more often than section headings. Or what happens when someone adds multiple copies of those words, and I meant to highlight the third instance? WhatamIdoing (talk) 00:36, 27 February 2015 (UTC)

WhatamIdoing: The example I gave of ?specific=p2w2 was very random. The challenge is developing a method that can account for changes in text, possibly by using identifiers that do not depend on how many times the words appear in the article. In addition, if the given text gets deleted, there is the option of looking at the history of pages. The basic question is, is it a good enough idea to try and attempt this at all or is there something which makes it too bad an idea to even give it a try. — Vghaisas (talk) 02:33, 27 February 2015 (UTC)
Interesting idea. Definitely more of a reader-focused feature. Not an easy problem. Throwing anchors everywhere in the wikitext is not really an option.
I think direct-linking-to-Wikipedia-sentence is interesting for Wikipedia readers: "Fact checking to resolve disagreements" is one of our biggest use cases. :-) Giving a direct link to the Wikipedia sentence and say "See i told you so" and "Wikipedia agrees with ME, see" or "You were right, according to the Wikipedia article" etc. The Wikipedia mobile app for android wants to experiment with a feature "Tweet a fact" (Example tweet), which turns the highlighted sentence in a picture (afaics). A bit, ehm, indirect for linking... I'd be interested how this sentence-level-linking could be done differently! :-) --Atlasowa (talk) 13:50, 27 February 2015 (UTC)
Major Wikipedia use case: Fact checking to resolve disagreements!
Mark Wikipedia text in android app and "Tweet a fact" (Example tweet)

More tweets! Looks really good, except for the CC-BY-SA image attributions... Ping User:DarTar? --Atlasowa (talk) 22:11, 5 March 2015 (UTC)

@Atlasowa: Thanks for the interest! I've been working very closely with the Legal Team to make sure that the attribution in these images is appropriate. We have signoff from Legal for the present state that this feature is in, so we're good for now. --Dan Garry, Wikimedia Foundation (talk) 01:25, 7 March 2015 (UTC)
Dan Garry, i'm curious: There is no attribution to the photographer (CC BY 3.0 Biso, File:Fender_bw.jpg), not even a link to the image file, how did you get "signoff from Legal" for that? And on the other hand "Wikipedia®" gets a Registered trademark symbol? Really strange. Can you provide a link to this signoff/decision?
BTW, what happened to the GDFL licence in the app, how can that disappear (only CC-BY-SA, compare with licences in desktop/mobile Wikipedia edit window)? --Atlasowa (talk) 15:45, 11 March 2015 (UTC)
I am not a lawyer so am not qualified to answer your questions. These would be good questions to direct to Stephen LaPorte, the Legal Team's liaison to Product and Engineering. --Dan Garry, Wikimedia Foundation (talk) 16:21, 11 March 2015 (UTC)
Hi Atlasowa, the icons in the interface reflect the license for the text of Wikipedia articles, which may also contain media with other compatible free licenses (or public domain content). The limited amount of space in the card is our biggest design constraint. The icons provide a reasonable amount of information about the license for the card, and they communicate that it can be shared and remixed. If users wish to get the full licensing details for content, they can follow the URL that the app generates with the card. Thanks, Stephen LaPorte (WMF) (talk) 19:59, 12 March 2015 (UTC)

Linking to text in a specific revision wouldn't have any of those complications and shouldn't be to hard to do, and still useful. Oiyarbepsy (talk) 03:26, 7 March 2015 (UTC)

Oiyarbepsy, how would you do it? --Atlasowa (talk) 15:46, 11 March 2015 (UTC)
Atlasowa Well, once Mediawiki does it, it would be like en.wikipedia/wiki/ArticleName&oldid=1234567&starthighlight=78&endhighlight=85, where oldid is the specific revision, starthighlight is the character to start highlighting on and endhighlight is the character to end it on. The challenge is creating some kind of interface that makes it easy to create such a url, since without it, this would be exceedingly difficult to do. Perhaps a feature where you could select text, right-click it, choose "create link with this text highlighted" and the Mediawiki software would create the URL, with oldid and everything. Oiyarbepsy (talk) 20:10, 11 March 2015 (UTC)
Oiyarbepsy, fair point. With the revision id also included in the URL, most of the issues raised earlier aren't relevant any more. We, would, however, need to ensure that the page clearly states that "the updated version of this page exists elsewhere and may have been edited in the meantime" or something like that. In any case, you think it would be a useful feature to have? — Vghaisas (talk) 16:42, 26 March 2015 (UTC)

Editor retention message

What do people think of this idea... Posting a message to user talk pages of users who have not edited in X amount of time but made constructive edits before to try coaxing them back into editing. An obvious factor that would exclude a user is they are on a break, either involuntarily (user is currently blocked for any reason) or voluntarily (a template in Category:Wikibreak templates is on their user page). Included in the message would be mentions of things that either didn't exist when they stopped editing, or a user may not know exist. Here's my impetus for this suggestion: I was speaking in person to a user who said that although they received a welcome template when they started in 2009, they didn't know that there are so many help resources available, specifically the Teahouse, the Help Desk or the IRC channels because they weren't mentioned in the welcome. The Teahouse was created in 2012, so it wouldn't have been. If there is opposition to bot-placed messages of this kind, is there a way of compiling a list of users who haven't edited in say, 6 months, and are not blocked or on break so it could be done manually? --Geniac (talk) 16:31, 8 March 2015 (UTC)

It's a great idea. GoodDay (talk) 18:38, 8 March 2015 (UTC)
  • This would assume they are logging in regularly, but just not editing, a premise that I'm not prepared to accept without evidence. If they quit logging in, they won't see it. You could email, if they have an email, but that borders on spam. Good intention, but not sure how effective that would actually be. Dennis Brown - 2¢ 19:20, 8 March 2015 (UTC)
Actually, Dennis, I get an email anytime someone posts on my talk page. I expect this is the case for most editors. This email generally only gives the heading for the posts, so the heading would have to be chosen carefully. Oiyarbepsy (talk) 19:46, 8 March 2015 (UTC)
It isn't that I can tell, that is an opt in. Many users don't have email enabled or listed here to begin with. Until we had stats on how many opt in, it is hard to say with any authority. Dennis Brown - 2¢ 19:53, 8 March 2015 (UTC)
Yup, getting emails about edits to our own usertalkpage, are opt-in (see Special:Preferences#mw-prefsection-echo, and I just reset my preferences (on a test account) to confirm.
I support the general idea proposed. Quiddity (talk) 22:22, 8 March 2015 (UTC)
I, too, think the idea has merit. I'd like to see a structured and controlled A/B test to measure impact - which shouldn't be too hard - but I love the idea. Philippe Beaudette, Wikimedia Foundation (talk) 14:54, 15 March 2015 (UTC)
See also this 2012 experiment. Regards, HaeB (talk) 15:43, 16 March 2015 (UTC)
That's an interesting project with promising results. I don't know how to go about conducting a research project like that, but perhaps we could conduct one with similar metrics as that, and adding talk page posting as a separate group, to test results between the two methods of contact. --Geniac (talk) 20:56, 21 March 2015 (UTC)
I think if most (or even some) users can receive the message properly, it is a great idea. Good luck! Tony Tan98 · talk 19:27, 26 March 2015 (UTC)

CitationHunt

Hello everyone!

I'd like to share something I've been hacking on in the past few days. It's a simple tool for exploring articles with unsourced statements, currently hosted at https://citationhunt.herokuapp.com. The full code can be found at https://github.com/guilherme-pg/citationhunt. I mostly built this to explore a few technologies I wasn't too familiar with, but I hope it could be useful to the community: it seems to me that adding citations where they're needed could be a good entry point for new editors, so I tried to make that a little easier. There's lots of room for improvement, of course, but I would love to hear any feedback you might have, and I'm definitely willing to work on making this better suited for real-world usage if the idea is any good.

Thanks, and apologies if this is the wrong place to share this. -- Surlycyborg (talk) 22:36, 26 February 2015 (UTC)

This is pretty cool. One thing that would be useful to implement is stopping the tool flagging lead sections when there are other sections in the article. Lead sections don't need to be referenced if the information is sourced elsewhere in the article but the site showed me a number of sentences from article's leads. Sam Walton (talk) 23:30, 26 February 2015 (UTC)
Thanks for the suggestion! If I understand it correctly, it looks like citation needed templates should generally be removed from lead sections, right? If that's the case, then perhaps we do want to flag them, except the site could suggest removing the templates instead of adding a reference? I've filed an issue on the project so I don't forget about this. – surlycyborg (talk) 13:19, 27 February 2015 (UTC)
It's more complicated than that, unfortunately. I think you might want to look at WP:MINREF for a list of What Must Be Cited in a quick cheatsheet format. Then, if you haven't found WP:CITELEAD yet, that would be your next stop. Things like direct quotations and contentious matter about BLPs need to be cited in the lead, but for most other things, it's optional (assuming that a citation exists later on the page). WhatamIdoing (talk) 19:24, 2 March 2015 (UTC)
I see, thanks for the links! I'm still inclined to keep lead sections on the site, but with a concise note somewhere summarizing the rules – in fact, your last sentence does a great job at that! –, and links to WP:MINREF and WP:CITELEAD for further reading. Does that make sense, or do you think omitting them would be more productive (that is, if, even with these hints, newcomers are still likely to get it wrong, then perhaps they should be omitted)? surlycyborg (talk) 18:45, 4 March 2015 (UTC)
I added a short message linking to WP:CITELEAD, which seems to contain the most relevant information here. For example, here's a page in which it appears: https://tools.wmflabs.org/citationhunt/?id=01156c31&cat=all. -- surlycyborg (talk) 11:28, 17 March 2015 (UTC)
Hi Surlycyborg, that is awesome! Love it. Excellent minimalism in design. Simple and beautiful.
Your tool makes me almost wish for the [citation needed] template in German WP (we deleted this pest years ago ;-) Well, we have instead the big de:Vorlage:Belege_fehlen, 26.228 inclusions...)
I added your tool to my collection de:Benutzer:Atlasowa/ref citation tools, but it is very different, new and unique. Excellent work, Surlycyborg! --Atlasowa (talk) 21:44, 5 March 2015 (UTC)
Thank you very much, your comment made my day! Please feel free to file issues on the project page if you have any thoughts on how it could be better. surlycyborg (talk) 23:13, 5 March 2015 (UTC)
Hi Surlycyborg, could you upload a screenshot to commons? I'd like to show your tool for example to people at wikidata, who are trying to build a Primary sources tool (d:Wikidata talk:Primary sources tool), and elsewhere. I like the playfulness and concision of the tool. There have been some discussions about that kind of features (sometimes called "microcontributions" or "gamification", not the best words: it's more than micro and more than a game). We need that kind of stuff for Wikipedia. Not just for Wikidata as in Magnus wikidata-game and meta:Research:WikiGrok. And this Wiki Quiz (Wikipedia Powered) for example only works the other way around (not producing refs).
I'm starting to dream of integrating your tool with other tools. :-) For example with finding good sources from a kind of "white lists" (i'm simplifying, it's a more ambitious idea: meta:Grants:IEG/find sources 2.0). And with a tool to make ref-generation easier: Citoid. And with tools to detect copyright violations (de:user:Atlasowa/copyvio tools). etc. :-)
Anyway, a free-licence screenshot would be great! Oh, and the filtering by category is really smart and useful. --Atlasowa (talk) 11:06, 6 March 2015 (UTC)
Sure, here you go: https://commons.wikimedia.org/wiki/File:CitationHunt.png. Let me know if you need any more. Thanks for your interest in this, Atlasowa! -- surlycyborg (talk) 12:36, 6 March 2015 (UTC)
@Surlycyborg: It seems that this is a focusing application which (in principle if not practice) encapsulates and enhances the existing Special:WhatLinksHere/Template:Citation_needed. My thinking is that people looking for citation needed tags to apply effort against could be directed to either this focus app or to the whatlinkshere pages, and it would be useful in the documentation text for the application to indicate the alternative, non-wrapped approach. --User:Ceyockey (talk to me) 12:51, 6 March 2015 (UTC)
Good thinking, Ceyockey. Another approach would be to take CitationHunts filtering by category and turn it around: Every category could have a link to CitationHunt only in this category. For example Category:Comics characters would have a template:
I think that would be nice to present CitationHunt with a topical interest link. But integrating/transcluding an external link into category pages like that is probably a problem (privacy, IP etc). If the tool would run on https://tools.wmflabs.org it would be no problem. Surlycyborg et all, other opinions or ideas? --Atlasowa (talk) 15:19, 11 March 2015 (UTC)
Before anything else, apologies for not replying this idea before, I've been a bit too busy these past few days. I think that the list of all articles needing citations is definitely something that would interest CH users, but I think we can provide a richer experience than just linking to it. For example, it would be nice (and not hard to implement) if it were possible to search and filter by article names from CH itself, as we currently do with categories. But yes, linking is the very least we can do, and could be a good start.
As for Atlasowa's idea, I think that sounds really great, and I'd love to see that happen. Zhaofeng Li and I have already discussed a bit the possiblity of moving CH to Tool Labs and I see no reason not to. I'll find some time later this week(end) to see what it would take to move CH there, even if keeping the static database for now instead of using queries against the live database. -- surlycyborg (talk) 16:29, 11 March 2015 (UTC)
I've just licensed CH under the MIT license and hosted it in Tools Labs, still using a static database. It is now accessible at https://tools.wmflabs.org/citationhunt/. This opens a bunch of new possibilites for using the live WP database (or, at least, auto-update CH as new dumps are released), and should address the privacy concerns Atlasowa mentioned. Let me know if you run into any issues! -- surlycyborg (talk) 22:44, 13 March 2015 (UTC)
I've just finished work to make the CitationHunt database auto-update weekly, always using the latest Wikipedia dump available on Tools Labs. It is currently using the 20150304 dump, the latest as of this writing. Assuming a regular dump schedule, we can expect CH to always contain reasonably recent information. Happy hunting! -- surlycyborg (talk) 16:19, 29 March 2015 (UTC)

Sometimes I need to find a section which I have edited and go back to my edit history. I then click on that link (e.g. "Archive.org BOT?") but the section is no more there because it has been ARCHIVED. It would be nice to have an script that retrieves that section automatically if it has been archived. 67.83.6.149 (talk) 18:03, 19 March 2015 (UTC)

Flow will eventually solve the issue of broken links, whether due to the thread being archived, or moved to a different active page, or even just a thread-title-change. The Flow URLs still needs some improvement (phab:T59154) but the UUID element will make broken links as in those examples, a thing of the past. Quiddity (WMF) (talk) 16:36, 30 March 2015 (UTC)

ANI discussion structure and lack thereof

After seeing a number of recent ANI discussions reach several thousand words and dozens of postings each with little or no admin input, some later archived without a single admin comment, I would like to look at possibilities for focusing ANI discussions in general. I participated in an RFC/U a few years ago and found the structure imposed by that system beneficial. I recognize that RFC/U had its problems and has been depreciated, but its highly structured design had merit. There doesn't appear to be any structure to many of the longer discussions at ANI. This is a problem because reading through and making judgements on long, tangled threads is a waste of admin time, and because large amounts of tangential commenting and sub-discussions can derail resolution of what would otherwise be clearcut issues.

Given the range of issues raised at ANI, a rigid structure could be difficult to apply, but there is a wide area between a highly codified discussion and a totally open one. A few possibilities: (1)limit post word count by non-admin users other than the filer and the target of the filing to 1000 words, perhaps a voluntary limit (2)add a default structure to new ANI posts, something like RFC/U's Statement of the dispute, Response, Additional views, Proposed solutions sections (3)put in place some limitation on posting new 'charges' outside of the scope of the initial dispute being raised later in the discussion (4)have separate sections in each ani for non-admin and admin responses. I am not proposing these, just throwing them out as a starting point, and I am sure there are other alternative solutions.Dialectric (talk) 14:38, 30 March 2015 (UTC)

I support this idea. ANI discussions are currently very messy and sometimes spin out of control. However, I do see one problem: what about routine reports, such as reporting suicide or death threats? Should we really make the reporter go through all that formality? --Biblioworm 16:08, 30 March 2015 (UTC)
@Biblioworm: I agree that edge-cases (which can be prolific on high-volume pages) need to be kept in mind. Ideally though, WP:EMERGENCY says those 2 particular situations should be reported privately. Quiddity (talk) 17:17, 30 March 2015 (UTC)
I also support a basic framework or suggested format. Anything to make the "drama board" less dramatic... --Scalhotrod (Talk) ☮ღ☺ 16:59, 30 March 2015 (UTC)
I guess one option could be similar to the one "used" in Lithuanian Wikipedia (lt:Vikipedija:Naudotojų elgesio svarstymai - lt:Specialus:Diff/4040662, lt:Vikipedija:Naudotojų elgesio svarstymai/Svarstymo šablonas - lt:Specialus:Diff/4040663) with separate sections for evidence (and a request to state what is wrong clearly - with an alternative that should have been chosen). Of course, no one has ever initiated a discussion there, but that is probably a good thing... --Martynas Patasius (talk) 00:19, 31 March 2015 (UTC)
No, per "not a bureaucracy." If you add rules to ANI, folks will just argue about the rules on ANI. NE Ent 01:43, 1 April 2015 (UTC)
This isn't a proposal, just a discussion of possible alternatives to the current one. Do you think there is no way to improve upon the current format?Dialectric (talk) 01:50, 1 April 2015 (UTC)

Grouping article redirects

Sometimes, multiple redirects should always point to the same article because they refer to the same thing. However, the way Wikipedia currently works, some redirects end up pointing in inconsistent ways. Let me explain with an example. Here are the redirects to the article Spirited Away:

  • Chihiro (Spirited Away)
  • Chihiro Ogino
  • El viaje de Chihiro
  • Haku (Spirited Away)
  • Miyazaki's Spirited Away
  • No-Face
  • Sen To Chihiro No Kamikakushi
  • Sen and Chihiro's Spiriting Away
  • Sen to Chihiro
  • Sen to Chihiro no Kamikakushi
  • Sen to Chihiro no kamikakushi
  • Sen to chihiro no kamikakushi
  • Spirited Away (film)
  • Spirited away
  • Sprited Away
  • The Art of Miyzaki's 'Spirited Away'
  • The Spiriting Away of Sen and Chihiro
  • Yubaba
  • 千と千尋の神隠し

These redirects can be grouped by the following:

  • Redirects that refer to the title of the movie
    • El viaje de Chihiro
    • Miyazaki's Spirited Away
    • Sen To Chihiro No Kamikakushi
    • Sen and Chihiro's Spiriting Away
    • Sen to Chihiro
    • Sen to Chihiro no Kamikakushi
    • Sen to Chihiro no kamikakushi
    • Sen to chihiro no kamikakushi
    • Spirited Away (film)
    • Spirited away
    • Sprited Away
    • The Spiriting Away of Sen and Chihiro
    • 千と千尋の神隠し
  • Redirects that refer to Chihiro, the character
    • Chihiro (Spirited Away)
    • Chihiro Ogino
  • Other redirects
    • Haku (Spirited Away)
    • No-Face
    • The Art of Miyzaki's 'Spirited Away'
    • Yubaba

It is conceivable that an article about the character Chihiro Ogino could be newly written, or essentially for any subtopic. Some redirects end up pointing to the new subtopic, while some stale redirects end up pointing to the old parent topic. Because of this, and many other ways, redirects can become stale even if editors can have a forethought of how similar redirects should point to the same target.

Solution-wise, there are several options.

  • Non-text solution - define redirect groupings by GUI drag-n-drop, click-n-click
  • Allow double redirects to support this use case, but only one additional hop
  • Introduce a new directive: #REDIRECT_TO_RELATED. When used in page A to point to page B, it indicates that the title of A is intended to be a canonical title for topic A, but it is at one time for whatever reason deemed not worthy of an article of its own, so it points to B instead. The traditional #REDIRECT would change to more explicitly mean redirect source and target refer to the same topic. REDIRECT_TO_RELATED must point to an actual article, while REDIRECT must point to a canonical title, which may have a #REDIRECT_TO_RELATED page, or an actual article.
  • Keep current syntax and UI mostly the same, but when a user tries to persist a change for one redirect, a warning and a bulk edit view appears to allow the user to edit a bunch of redirects.

--Makkachin (talk) 14:27, 4 March 2015 (UTC)

A consensus to allow double redirects if the intermediate redirect is one with possibilities was achieved at Wikipedia:Village pump (proposals)/Archive 112#Allow some double redirects. I don't know if anyone is working on implementing it.
I had an idea for a new redirect template to mark redirects that should be updated if another redirect is changed into an article. Using your example, Chihiro (Spirited Away) could include this template with "Chihiro Ogino" as parameter. The template message would depend on whether or not Chihiro Ogino is a redirect, and the template would add a maintenance category if it no longer is. That would ease correcting such redirects until the software is changed to allow double redirects. SiBr4 (talk) 17:00, 4 March 2015 (UTC)
To illustrate what such a template would look like, I drafted one at Module:Sandbox/SiBr4. See testcase 1 (parameter is another redirect to the same title) and testcase 2 (parameter is not a redirect). SiBr4 (talk) 21:17, 4 March 2015 (UTC)
@Makkachin and Oiyarbepsy: Any comments on this idea? A bot could figure out for itself which redirects to update, as proposed below, though it would be easier if the template dynamically changed its message and/or set a maintenance category for bots (or just humans) to patrol. SiBr4 (talk) 15:24, 15 March 2015 (UTC)
I'm confused by your post. What the heck is that flag stuff on your testcases? And I don't know modules enough to have any comment on it, although your module seems very long and complex for a simple instruction to update a redirect. Oiyarbepsy (talk) 16:57, 15 March 2015 (UTC)
An unrelated test of a different template. The test of the redirect template is in the "Lua test 5" section. The module currently includes a number of error messages for when the template is used incorrectly; the main two messages, at the end of the "rrpos" function (note that the "fgg" function is also an unrelated test), are displayed on the testcase pages. SiBr4 (talk) 17:15, 15 March 2015 (UTC)
Tracked in Phabricator
Task T32359
As far as double redirects, there is a complex and difficult to fix software issue holding it up. That said, double redirects would solve a lot of the problems noted above. Oiyarbepsy (talk) 19:56, 4 March 2015 (UTC)
Without double redirects, could some kind of template system work? You could have a template on a page {{same target as|other redirect}}, which bots could read and then use to automatically update the redirect if the other changes. Oiyarbepsy (talk) 19:56, 4 March 2015 (UTC)
I like this idea; and we can do this for multiple levels (a seires of movies, followed by an individual movie from the seies, followed by a character who is primarily from that movie - as soon as one of these becomes an article, the bot can update all the redirects which go through it. עוד מישהו Od Mishehu 17:55, 26 March 2015 (UTC)
It sounds like an easy enough bot task. What's the intended behavior if the "same target as" page isn't a redirect? But we could get the same behavior for redirects by calling it {{would redirect to|target}}. We'd also have to decide whether WP:CSD#G8 applies if target is deleted. Anomie⚔ 12:50, 28 March 2015 (UTC)
I think that the answer to the G8 question is simple: a page is speedy feletable only if every revision in its history is. עוד מישהו Od Mishehu 20:12, 28 March 2015 (UTC)

I BOLDly moved my draft live as Module:R avoided double redirect and made a wrapper at Template:R avoided double redirect. It probably needs some improvements to its messages, and possibly a better name, though the template will be easier to understand if it's used at an actual article redirect. See it at Makkachin's original example of Chihiro (Spirited Away). SiBr4 (talk) 20:01, 3 April 2015 (UTC)

Requested articles

If any of you have ever looked at WP:Requested articles you know it's an absolute mess. The issue is there's a huge amount of pages on Wikipedia that link here, the article wizard, the navigation bar on the proposal village pump, AfC, the list goes on and on. This leads to a huge amount of article ideas listed here,

Take a look at the size of the pages
Page sizes from Wikipedia:Requested articles
shortcut Page Bytes
/Afghanistan 2,849
/Albania 7,203
WP:RA/AA /Applied arts and sciences 55,489
/Applied arts and sciences/Computer science, computing, and Internet 249,970
/Applied arts and sciences/Engineering 63,948
/Applied arts and sciences/Law 110,284
WP:RA/MED /Applied arts and sciences/Medicine 126
/Applied arts and sciences/Pharmacology 139
/Applied arts and sciences/Transport 94,011
WP:RA/AE /Arts and entertainment 396,197
/Arts and entertainment/Fashion 90,685
/Arts and entertainment/Film, radio and television 583,552
/Arts and entertainment/Internet and tech culture 52,105
/Arts and entertainment/Literature 241,074
/Arts and entertainment/Literature/Books 122,415
/Arts and entertainment/Performing arts 170,629
/Arts and entertainment/Print media 115,923
/Arts and entertainment/Speculative fiction 16,740
/Arts and entertainment/Unclassified 39,210
/Arts and entertainment/Visual arts 246,088
/Biographies/Anthropologists 23,017
/Biographies/Jewish figures 23,752
/Biographies/Political figures 141,399
/Biography/Biologists 39,248
/Biography/By nationality 266,097
/Biography/By profession 577,919
/Biography/People in medicine 87
/Business and economics 160,500
WP:RA/CO /Business and economics/Companies 322
/Business and economics/Companies/A-E 306,933
/Business and economics/Companies/F-L 196,347
/Business and economics/Companies/M-S 235,621
/Business and economics/Companies/T-Z 242,588
/Business and economics/Organizations 459,371
/Business and economics/People in business 228,762
WP:RA/D /Deaths 7,025
WP:RA/I /Images 6,302
WP:RA/J /Japan 50,584
/Japan/Anime and Manga 111
/Japan/Anime and Manga/Refused Requests Archive 136
/Japan/Government 8,849
/Japan/Seiyū 10,923
/Lists of basic topics 1,641
WP:RA/M /Mathematics 113,049
/Mathematics/Logic 5,684
/music 122,387
/music/Albums 40,536
/music/Classical composers 69,137
/music/Instruments 16,140
/music/Jazz 19,831
/music/Performers, bands and songwriters 292,537
/music/Performers, bands and songwriters/I–O 185,332
/music/Songs 64,885
WP:RA/NS /Natural sciences 59,361
/Natural sciences/Biology 70,531
/Natural sciences/Chemistry 40,556
/Natural sciences/Environment and geology 56,834
/Natural sciences/Physics 62,959
/Other 52,103
/Philosophy 87,936
/Philosophy/Journals 42,665
/Social sciences 104,628
/Social sciences/Defunct United States military academies 14,161
/Social sciences/History 183,962
/Social sciences/Geography, cities, regions and named places 18,319
/Social sciences/Military and military history 50,634
/Social sciences/Politics and government 257,999
/Social sciences/Psychology 22,087
/Social sciences/Religion 117,453
/Sports 234,574
/Sports/Association football (soccer) 58,242
/Sports/Martial arts 49
/Sports/Motor sports 38,626
Index Page sizes from Wikipedia:Requested articles
shortcut Page Bytes
WP:RA / 12,317
WP:RA/B /Biography 596
/Business and economics/Businesses and organizations 618
/By country 5,871
/Social sciences/Geography, cities, regions and named places/Kosovo* 4,997

every page has an absurd amount, the thing is, there are some that are legitimately good ideas. Granted some of them aren't notable or don't have any potential content, but a lot of them are. The issue is requested articles is a never ending black hole, tons of additions are made every day but none of them are ever created, presumably because of the level of difficulty to dig into them.

The way I see it one of two things have to happen, either the entire thing has to be shut down, and all links to it across the project need to be removed, or a process that allows for a systematic review of every selection (without having to edit the entire thing by hand), and getting the lists to editors who'd be interested in doing it. I believe that latter is the better option, as this could lead to hundreds of good articles, though I'd like to hear some ideas on what the best way of going about this is, or if they entire thing should be scrapped.

Thanks! Kharkiv07Talk 02:00, 19 March 2015 (UTC)

Yes, some form of peer review process may be needed to elevate the more notable entries to a 'preferred' status. The remainder could then be archived. The current length of the list seems prohibitive though; it could take several years to process. Praemonitus (talk) 19:39, 20 March 2015 (UTC)
We could take them to projects and advertise them. Or find prolific article writers and see if they want to address them. Graeme Bartlett (talk) 12:24, 24 March 2015 (UTC)
Nobody is going to want to deal with them in their current state though, I can try to take them to projects, or even advertise them, I'm just worried with thousands of article nobody is going to want to have to deal with them, what we need is a good way to classify them... I'm just not sure how. Kharkiv07Talk 03:16, 25 March 2015 (UTC)
Perhaps some custom inline templates could be useful? For example, they could let others know what type of research has already been attempted for a particular topic and why no article was created. Possibly it could use small, two-letter codes with mouse-overs: [IS] → insufficient sources available; [TC] → technically complex, requiring an expert; [FL] → foreign language version available, &c. Praemonitus (talk) 17:55, 25 March 2015 (UTC)
Hmmm... that may work, I'll look into it. Kharkiv07Talk 23:50, 25 March 2015 (UTC)
Getting these lists more integrated to their relevant wikiproject(s) would also be a good triaging step, and potentially help give interested writers/researchers a more closely connected place to find new subjects. I wonder if @Harej: is already thinking about this with regards to WP:WikiProject X? --Quiddity (talk) 16:41, 30 March 2015 (UTC)
Quiddity, Kharkiv07, Praemonitus, Graeme Bartlett: I have been thinking, at some level, about how to better integrate WikiProject lists of requested articles into WP:RA. Some discussion on IRC led to a wonderful idea of setting up a Flow board for article requests. Flow facilitates, essentially, talk page section-level categorization, so there could be a topic (Flow's version of talk page sections) for each requested article with the option to categorize in one or many categories, including WikiProjects. There would also be a triage system. I've asked the WMF to set up Flow for Wikipedia:Article request workshop here. Harej (talk) 00:31, 31 March 2015 (UTC)
@Harej and Quiddity: That sounds great! However, in the mean time MusikAnimal and I were looking into something here too, with a bot that forwarded it to a talk page. That being said a flow would work too, an easy system for reviewers that can be forwarded once approved is what's needed. That being said I'd love to see the flow, but not that the Wikiproject associated with RA is all but completly dead, with it's coordinator being long inactive. Kharkiv07Talk 00:40, 31 March 2015 (UTC)
I 100% agree that aligning sections to a WikiProject is the best way of keeping Requested Articles organised and focused on notable material. I've done that myself occasionally for track and field and completed requests I had the knowledge and interest to do. I've no problem with there being long-standing unworked requests if the requests are still valid. They may eventually be the topic that gets a new content creator going. SFB 21:42, 3 April 2015 (UTC)

ThePhantomBot reporting to noticeboards

I'm currently working on ThePhantomBot, (bot request for approval) a bot that looks for LTA and other issues that aren't as obvious as the ones found by bots like ClueBot. Since there's a lack of certainty with some of the things the bot looks for and since not all of it is something that would be handled at AIV, the bot would need some way to notify users that it has come across something needing attention. I don't think this can be done effectively by users just coming across the bot and following a page in its user space used to post reports, it would require that every time a user takes action on something the bot notices they credit the bot, which is not something users are likely to do and could bring unnecessary attention to the bot from the problematic users it targets. Here's a list of the things the bot currently detects (or will be detecting soon) and how I think it would best be reported:

  • Bad page recreation - Log to user space page - These are detected very frequently and showing them to people who don't care to know would get annoying very fast
  • High probability sockpuppets - Report to SPI - I don't know of any bots that currently report to SPI so it could be tough to get consensus for this
  • Lower probability sockpuppets - Log to user space - These haven't been coming up very often but at a certain level of certainty human review is required
  • LTA detection - Report to AIV if certainty is very high or report to AN/I otherwise
  • Newly added LTA filters, including ones with very low certainty - Log to user space
  • IPs using administrative templates - Report to AN/I
  • Sleeper account detection - Not implemented yet so I don't know how often it will go off, if its often log to user space otherwise report to AN/I

The best idea I have so far for reporting to AN/I is to have a permanently transuded template at the top of AN/I which includes a list of reports along with a row of links to the user pages the other reports are filed on. The transclusion prevents users who don't care about the bot's reports from getting updates in their watchlist but makes users on AN/I aware the bot exists. I'm wondering if anyone has any better ideas for how the reporting should work or thinks there are problems with my current plan, after a bit of discussion here I'll decide what the best way to implement the reporting is and seek consensus at Wikipedia:Village pump (proposals). Here is the bot's current debug log and what the bot currently detects. PhantomTech (talk) 05:51, 27 March 2015 (UTC)

I'm not sure I understand why the bot is needed to do edit filter suitable tasks, could you elaborate on why it should be used in place of some on-wiki edit filters? Sam Walton (talk) 08:23, 27 March 2015 (UTC)
Quick summary for people who see the long thing I typed out after the summary and decide it's too much, the bot can
  • Do more complicated checks
  • Take more time on some edits
  • Take infrequent cases, and lots of them
@Samwalton9: While many of the long term abuse cases could easily be handled by the edit filters, the bot has access to any information it can get from querying Wikipedia. If there was an LTA case where a user frequently made good edits to articles in a specific category to become autoconfirmed, then made problematic edits on a semiprotected article, filters would be mostly restricted to use any pattern in the problematic edits to identify them, if the problematic edits didn't adhere to a strict pattern, a filter would have to be written to catch a wide range of edits which could result in false positives. In the same situation this bot would be able to match the edit against the wide range of problematic edits performed, then check the user's contribution history to see if their other edits matched the problematic pattern and to see if the articles they edited before becoming autoconfirmed were from the category the LTA user tended to edit in. I'm not aware of this specific case existing and the LTA filters the bot currently uses aren't yet this complicated so this is more of a potential for the bot that will likely not be done until after the more simple LTA cases are being detected. Another advantage over filters is that filters cannot take infrequent cases, the time it takes to check an edit against the edit filters needs to be somewhat low because it's done on the fly. While a single filter doesn't necessarily have a big impact, putting a bunch together can, for this reason edit filters aren't setup for every case where they can stop or detect a problematic user. Not only can the bot take on many infrequent cases, it doesn't need to be quick on every edit because it checks edits after they've been made, it can take even a few minutes to check a single edit (hope it never has to) as long as it doesn't have to do that very often so that after it has it doesn't get backlogged. The LTA edit filters I can think of that the bot couldn't take are ones that need to be blocked because of what the edits contain, as someone who can't see private filters I'm not sure if any of these exist. PhantomTech (talk) 15:53, 27 March 2015 (UTC)
  • Why don't you just do something like the Miszabot page archiving configuration? Make template:ThePhantomBot_config with bunch of different fields for how people can get your bot's report on their user page. So sock_prob = yes or sock_prob = daily could be used at the discretion of the editors at SPI to get a constant or daily list of probable sock puppets, while LTA_high = daily and Admin_template_misuse = daily would allow WP:ANI to get a daily report on possible long-term vandalism and IPs using administrative templates. A given editor who is interested in any or all of the information your bot comes up with can likewise have the same information delivered at regular intervals, eg all = yes, all = 12h | sock_low = no | LTA_low = no, all = daily, bad_page_detect = 2d, etc. VanIsaacWScont 18:32, 29 March 2015 (UTC)
@Vanisaac: Not a bad idea but I'm not sure how well it would scale. Unlike archiving, this bot's task is time sensitive, posting to a bunch of user pages could cause a decent delay and even if that delay only happens once a day it might be an issue. I'm not exactly sure if this could be done but it might be possible for interested users to use javascript in their common.js to asynchronously check the bot's log pages for updates. Another option could be posting a message in an IRC channel, but that would be a supplement to something on-wiki. PhantomTech (talk) 19:33, 29 March 2015 (UTC)
@PhantomTech: There's nothing that prevents you from limiting the number of reports your bot has to make with a whitelist or namespace limitation - when report_X = yes is used outside the Wikipedia / Wikipedia talk namespaces, just transclude User:ThePhantomBot/report_X and give the option report_X = transclude for within the Wikipedia namespaces. That page would get the same constant updates of your ANI/AIV/SPI reports, so someone could check their user or user talk page to see whatever reports they want in real time. Periodic reports (eg, daily) could still be used in user talk spaces, and it could be as simple as doing a WP:subst of that report page onto those user talk pages. VanIsaacWScont 19:47, 29 March 2015 (UTC)
@Vanisaac: Right now the plan is to have any reports that can't go to AIV or SPI go on a page with one of those pages transcluded to ANI so users transcluding any of those pages to their user page is certainly possible, making another thread (didn't think about that before) in my bot to subst reports daily on to user pages probably won't slow it down much so that's a possibility too. PhantomTech (talk) 20:59, 29 March 2015 (UTC)
Notice posted at WT:AN to get more input. PhantomTech (talk) 01:16, 4 April 2015 (UTC)

Administrative templates

Please define this. I don't understand what it means. This has the potential to put a huge amount of useless garbage on the admin noticeboard. Oiyarbepsy (talk) 01:55, 29 March 2015 (UTC)

@Oiyarbepsy: {{Blocked user}}, {{Banned user}}, {{Sockpuppeteer}}, {{Locked global account}}, {{Uw-block}}, etc. Based on current detections this is very rare but was reported here. Ideally, anything with very frequent detections would also have a low rate of false positives and could be reported to AIV or similar to avoid spamming ANI, something with very frequent detections that doesn't have a great false positive rate or doesn't require immediate attention would probably work best by having the bot log it in its user space. PhantomTech (talk) 02:38, 29 March 2015 (UTC)

Concept navbox

I've made a navbox at my sandbox that could be placed right under the header at ANI. My bot would log to a page (the main log) that the template gets info from along with other page's in its user space which are linked to in the navbox this way people can put the main log on their watchlist if they want updates but won't be updated if ANI is the only thing on their watchlist. The template automatically changes colors depending on if the main log is empty, has something or is backlogged and automatically collapses if it is backlogged so it doesn't take too much space on the page at ANI. I have it setup on my sandbox simulating a few "random" pages as if they were the main log to show what it looks like in its three different states and I put some placeholders in it for links to other logs so you can see what it would look like. The thresholds for page size are just rough estimates and will have to be modified depending on what format the reports are in. PhantomTech (talk) 04:48, 31 March 2015 (UTC)

Infobox templates to discourage edit warring

The other day I noticed an edit war over the music genres in an infobox, and I think I might have an idea that could all but eliminate that type of time sink. What if articles that have a long history of this kind of dispute had a dedicated template for the infobox? I don't know much about them, but if we had {{Infobox Thriller (album)}} that transuded all the agreed upon information from a fully-protected template, it would be nearly impossible to edit war over it.

Anyone wanting to make a change to the infobox template would be required to first gain consensus at the relevant talk page before asking for the change to be made at the template page. Of course not every article would need them, but editors working on pages where routine edit warring occurred over the infobox could request them on a case-by-case basis. This way we could "lock down" only the infobox during edit wars related to it. Rationalobserver (talk) 21:35, 31 March 2015 (UTC)

  • I think it would be much, much, much more useful to eliminate the "genre" field entirely from any kind of music infobox. They are edit-warred from here to kingdom come on a huge number of articles, are almost never based on reliable sources, are susceptible to vandalism and modification, and in most cases reflect such micro-genres that only true aficionados of the artists involved have any idea what they mean. Further, most artists perform music from *multiple* genres or having elements from multiple genres. It's not worth it to have this stuff in an infobox. Risker (talk) 23:16, 31 March 2015 (UTC)
I agree, but that's been discussed and rejected, so this is a possible end-around. Rationalobserver (talk) 23:18, 31 March 2015 (UTC)
  • (edit conflict) I somewhat agree with Risker: infobox genres don't impart much useful information (which could be said about infoboxes generally) but attract an inordinate amount of drive-by vandalism and revert wars. We wouldn't lose much (or anything) if the genre was simply eliminated. It should be based on reliably-sourced information contained in the article anyway, and it rarely is. However, full-protecting infobox templates seems to be a form of the perennial proposal to lock "finished" pages, and pages are never perfect and never finished. Ivanvector (talk) 23:23, 31 March 2015 (UTC)
Or I guess what I'm saying is that locking down just the infobox would just move the problem to the article itself, and not really solve anything. Ivanvector (talk) 23:24, 31 March 2015 (UTC)
Maybe, but at that point you might have to lock down the entire article anyway, which from what I gather is undesirable. At least this is a step before that, so the article can remain open. I think genre warriors like having influence on the infobox more than actual prose, but I could be wrong. Rationalobserver (talk) 23:35, 31 March 2015 (UTC)
No, I agree with Risker. Remove the genres in infoboxes. --AmaryllisGardener talk 00:05, 1 April 2015 (UTC)
I support that idea, but who is going to spearhead it? Rationalobserver (talk) 00:08, 1 April 2015 (UTC)
What about Risker himself? He She seems pretty sharp! *ba dum tss* --AmaryllisGardener talk 00:15, 1 April 2015 (UTC)
She. Risker (talk) 00:46, 1 April 2015 (UTC)
So are you willing to spearhead an effort to remove genres from infoboxes? Rationalobserver (talk) 15:35, 1 April 2015 (UTC)

Ivanvector per your above comment: "However, full-protecting infobox templates seems to be a form of the perennial proposal to lock 'finished' pages, and pages are never perfect and never finished." Some aspects of article content are determined by prior consensus, and that's all this would do; lock-down the infobox when consensus has determined what info it should include. WP:CITEVAR, for example, says that you cannot change one style to another without first gaining consensus, and music genres should be treated the same way. Rationalobserver (talk) 18:59, 2 April 2015 (UTC)

But we never lock down an article to enforce consensus, nor should we, because consensus changes, and it goes against anyone can edit. The only instances I know of where pages are ever locked from editing are to stifle active disruptions (and even this is somewhat controversial), or to prevent changes to very frequently used templates which would break things (and WP:OFFICE actions, but that's another kettle of fish). Genre warriors are disruptive, but not anywhere near the level where we should take such drastic action as to preemptively prevent all music infobox edits. Perhaps I'll support this as an experiment if we use pending changes instead of full protection. However, in that case, it might just be easier to PC-protect articles where genre-warring is an issue, rather than create separate templates. Ivanvector (talk) 19:14, 2 April 2015 (UTC)
Also, I'll support taking the genre field out of infoboxes, if that is proposed. Ivanvector (talk) 19:19, 2 April 2015 (UTC)
I also support that idea, but why would locking down the infobox just turn the disruption to the article, but taking away the genre field wouldn't? Rationalobserver (talk) 19:33, 2 April 2015 (UTC)

@Risker and AmaryllisGardener: As a recent changes patroller I always come across this kind of vandalism without any clue if it's right or not and I'm more than willing to propose the change, are you guys thinking removing the genre field from all music related infoboxes, or just certain ones? Kharkiv07Talk 01:11, 4 April 2015 (UTC)

Contesting a CSD

Of all the CSDs I've seen contested the number of times I've seen it done right is a fairly low percentage, even for reasonably experienced editors. I think we need clearer, simpler and less error-prone text offered to the editors contesting CSDs. Bazj (talk) 22:07, 20 February 2015 (UTC)

@Bazj: It's simply a matter of removing the speedy delete tag, saying why in the edit summary, and optionally posting on the nominator's user talk page, right? What so you see being done wrong? Or are you talking about page authors contesting tags? Oiyarbepsy (talk) 20:17, 11 March 2015 (UTC)
Basically, there is one way for the author of the article to contest deletion - click the button on the template and give a reason on the talk page. Yes, some do copy the warning notice they received onto the article talk page, and some for some totally mysterious reason copy it onto the article page. You can never eradicate oddities like these. As to anyone else, if inexperienced in editing, they can do the same - click the button. If more experienced, they can detag and say why. Things that puzzle me are, first, why do some apparently new authors use the 'hangon' template which I don't think is anywhere to be seen in the template? And second, why do some, whose article is very clearly up for deletion on grounds of significance, make a great play of showing that it isn't a copyvio (and similar strange confusions)? Peridon (talk) 19:25, 12 March 2015 (UTC)

What about modifying the templates? Some templates work where it takes you to an edit screen with all the required information pre-filled. So, when clicking on the contest button for the a7 tag, the edit screen could be pre-filled with something like this: 

<!-- Please explain why this topic is significant. The best way to do this is to show us a reliable source that isn't connected with the subject of the article.
Don't tell us that the article is correct - we're not saying that it's wrong, but that it doesn't meet our inclusion criteria.
Please explain why the article shouldn't be deleted below this line. -->

<!-- Please only type above this line. --> ~~~~

This should help new editors know what to do, and also ensures that the message is signed. Each criteria would need a different pre-filled message. Oiyarbepsy (talk) 20:16, 12 March 2015 (UTC)

@Oiyarbepsy: That is easy to do, seems like a good idea and I think you should be bold. Just in case you would not know where to find them, all of the relevant templates are at the name form Template:Hangon preload XX, with XX replaced by the letter/number combination of the criterion, i.e., A7's is at {{Hangon preload A7}} and so on. Regarding signing, it's already included in them. However, just note we had a problem back at the beginning when we implemented the contest button with commented out text – users were placing their protests inside those tags hiding their CSD contest basis resulting in this edit, but I don't think the same commented out tags issue will arise with any instructions set off above with a few lines skipped. Please note a secondary reason for providing the diff in the last sentence. It shows you the coding gyrations you must go through to place the commented out notes, so they pass through to the pages from the template (i.e.., you can't just use <!-- TEXT -->) --Fuhghettaboutit (talk) 04:15, 17 March 2015 (UTC)

Discouraging biting the newbies

Feedback was excellent, and resulted in major changes to the original concept. The resulting proposal is at Wikipedia:Village pump (proposals)#Discouraging biting the newbies

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.

We are short of new editors, particularly women. If a new editor is "bitten" as soon as they start a new article, they may give up on Wikipedia in disgust. This is to ask for feedback on the idea of adding a process to Wikipedia:Please do not bite the newcomers similar to that for Wikipedia:Vandalism, a series of escalating warnings to compulsive biters that eventually lead to blocks. The details are tentative, so any suggestions would be welcome to improve the concept before putting it to the vote. Aymatth2 (talk) 12:55, 24 March 2015 (UTC)

Definitions

I would define a new editor as an editor with less than 100 edits, and a new article as one that is less than 24 hours old.

Type A bite: This kind of "bite" adds cleanup templates to a new article by a new editor, e.g.

There is nothing wrong with adding cleanup templates in general (although fixing the problem is better), but a lot wrong with greeting a new editor with a banner like this. An experienced editor would shrug it off, but a new editor may well see it as hostile, saying Wikipedia is not a friendly, collaborative site. Much better to leave a {{welcome}} note on the new editor's talk page, explain the problem and offer to help. Again, this would apply only to a new article by a new user. They make their first rough outline, save it, get a coffee, and come back to see an aggressive criticism of their work. Wikipedia does not want them.

Type B bite: This kind of "bite", more serious, is an inappropriate request to delete a new article by a new editor (Speedy, PROD, AfD). The request is "inappropriate" if it is rejected: the nominator did not do their homework. Some well-meant requests will of course be rejected, which is fine. But if an editor is repeatedly requesting deletion of new articles by new editors on inadequate grounds, they are doing damage. An inappropriate Speedy request on Natalie Smith Henry managed to get attention from the New York Times and BBC News, and a year later from Huffington Port. We do not need this sort of publicity, which may discourage potential new editors from even starting. Aymatth2 (talk) 12:55, 24 March 2015 (UTC)

Proposed new process

We could add teeth to Wikipedia:Please do not bite the newcomers by defining an escalating series of user warning templates to be placed on the biter's talk page:

Type A bites (Cleanup banners)

Welcome, and thank you for adding a cleanup template to Sample article. This is a new article by a new editor, so adding a note explaining your concern to their talk page would be more appropriate. See Wikipedia:Please do not bite the newcomers for a discussion of this concept.
Please refrain from adding cleanup templates to new articles by new editors such as Sample article. See Wikipedia:Please do not bite the newcomers.
Please stop adding cleanup templates to new articles by new editors, as you did with Sample article.
You may be blocked from editing without further warning if you continue to add cleanup templates to new articles by new editors, as you did with Sample article.

Type B bites (Deletion requests)

Welcome, and thank you for suggesting deletion of Sample article. Your suggestion has been declined. This is a new article by a new editor, so you should be very careful about proposing deletion without careful research and discussing your concerns with the creator. See Wikipedia:Please do not bite the newcomers for a discussion of this concept.
Before requesting deletion please take more care to check whether a new article by a new editor such as Sample article does in fact meet the criteria for deletion. See Wikipedia:Please do not bite the newcomers.
Please stop requesting deletion of new articles by new editors on inappropriate grounds, as you did with Sample article.
You may be blocked from editing without further warning if you continue to add propose deletion of new articles by new editors on inappropriate grounds,, as you did with Sample article.

I do not see a proposal like this in Wikipedia:Perennial proposals. Perhaps it is crazy? Aymatth2 (talk) 12:55, 24 March 2015 (UTC)

Comments?

This is unnecessary WP:CREEP. Type B, persistent bad deletion tagging, is already sanctionable as disruptive editing. Your process for type A amounts to a ban on maintenance templates; while a WP:SOFIXIT attitude is desirable, your proposal would prevent unfixed articles from being tagged for cleanup and so they would fall behind the metaphorical sofa and never see the light again. BethNaught (talk) 15:25, 24 March 2015 (UTC)

WP:Disruptive editing states Disruptive editing is a pattern of editing that may extend over a long time or many articles, and disrupts progress towards improving an article or building the encyclopaedia. I would contend that repeated bad deletion tagging would fall under that definition. BethNaught (talk) 23:41, 25 March 2015 (UTC)
I suppose it does, although some might quibble. I was hoping for something more explicit. I will keep looking. Aymatth2 (talk) 00:48, 26 March 2015 (UTC)
  • Remember it only applies to new articles, defined as less than 24 hours old. New editors may well create a minimal version, save it, then start adding the details. The idea is to not slam them with criticism after their first save. The person spotting the problem should leave a note on the creator's talk page, and tag the article if nothing is done in 24 hours. Or fix it. Aymatth2 (talk) 16:03, 24 March 2015 (UTC)

We already have quite a few templates... Template:Uw-bite, Template:Uw-csd, Template:Uw-hasty, as well as four levels of assuming good faith Template:agf1 and harassment Template:harass1. Besides, in general, the people who are going to be tagging this are people who you should probably talk it out on their talk page instead of templating them. Right? Kharkiv07Talk 03:09, 25 March 2015 (UTC)

  • The editors who frequently make poorly researched deletion requests on new articles, or swiftly tag new articles with clean-up templates, may not be particularly receptive to polite warnings about the damage they are doing in driving away new editors. They certainly are not concerned with Wikipedia:New pages patrol#Be nice to the newbies. But they will respond to an escalating series of user warnings that may lead to a block. Templating them when closing a declined deletion request would be a simple, optional step in the closure process, which could be done by any user. Similarly, it will be simple for any user to do a "biter" patrol to check for rapid addition of clean-up templates to new articles by new users, and to template the biter. The advantage of the proposed approach is that it does not require any one user to gather evidence and launch a case for sanctions based on disruptive editing. The escalation just happens naturally as different editors template the user for biting, like templating them for vandalism. Aymatth2 (talk) 11:32, 25 March 2015 (UTC)


  • I'll reserve my opinions on the specific process proposed above, but this is certainly an issue that needs addressing. We also need to deal with the problem of AFC submissions being declined because they are not (nearly) perfect, rather than because they would fail an AfD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 25 March 2015 (UTC)
  • I did not even think of that. I took a quick look at AFC and immediately found a serial decliner. I checked one article at User:Lograssolaw/sandbox, did a quick Google check, and am fairly confident that "World Head of Family Sokeship Council" is in fact notable, with plenty of sources, despite being three time declined. Maybe the way to approach this, though, is to start with a narrow focus and very clear damage such as rapid Speedy Deletes for newly created articles by newbies, then expand the scope afterwards. Not sure. Aymatth2 (talk) 15:43, 25 March 2015 (UTC)
  • AFC is a whole new world to me. I have always started articles in mainspace. I suppose some editors first need validation that their article is o.k. Presumably they are also very sensitive to negative feedback. I checked three more AFCs at random, found the same decliners, found one recently declined editor with a black "Retired" notice. This is obviously a form of biting. I am still unsure how to introduce this proposal. If it is too complicated there will never be consensus. Aymatth2 (talk) 00:48, 26 March 2015 (UTC)
  • In my opinion the problem is with the AfC helper script, it provides upward of 20 reasons for rejection making it tempting to use one if it remotely falls into that category. But my problem with your proposal is the people who are making these declines are experienced editors and templating them all the time isn't probably the best way to go about it. Putting a personalized message on their talk page is probably the way to, and if needed take it to a noticeboard. So, with that rationale, my suggestion would be to make a policy that stops all the things we've mentioned. Kharkiv07Talk 00:59, 26 March 2015 (UTC)
  • The biters are mostly experienced editors who keep on biting. The policies and guidelines explain why and how to avoid biting, but the biters ignore them. Their victims do not know how to get together and appeal on a noticeboard – they are newbies. Talk page messages from the bitten newbies clearly do not work. The biters keep biting. We badly need new editors, so have to be rougher with the biters. A template-based escalation process leading up to a block, like the vandalism template process, seems the only effective way to help the biters break their bad habits. Aymatth2 (talk) 01:37, 26 March 2015 (UTC)
But currently its not written anywhere about, say AfC for example, as a matter of fact WP:Bite is extremely vague. Granted biting is a very broad topic that has so many different ways it can happen, I think if we get some of this in writing and then see how it sits we can better institute a warning system later, these people who are doing the things you're saying are borderline on the current policy, and while I completely agree with you that it's wrong, there's nothing that tells them not to at the moment. Full disclosure: I could be wrong about any of what does or doesn't exist in policy Kharkiv07Talk 01:58, 26 March 2015 (UTC)
I am moving towards proposing a clarification to Wikipedia:Disruptive editing, along the lines of "Actions that tend to discourage newcomers, such as hastily nominating new articles for deletion or tagging new articles with clean-up templates, may be considered disruptive if constantly repeated without exploring alternatives on the article creators' talk pages." Something like that. If that were accepted, there should be no objection to escalation via multi-level templates. Aymatth2 (talk) 14:13, 26 March 2015 (UTC)
I see a real problem with Wikipedia:WikiProject Articles for creation/Reviewing instructions#Notability and verifiability. With deletion, the nominator is expected to first do some research to confirm that the subject is not notable. With creation, it seems that the onus is on the creator to provide evidence of notability. Endless resubmissions like Draft:Next Level Purchasing Association would be avoided if the reviewer called the shot on notability based on a web search. If the subject is notable, accept the submission. It can be improved. This is a separate issue from biting, but one that should be fixed. Aymatth2 (talk) 12:37, 26 March 2015 (UTC)
I'd propose changes on WP:Bite as well. Kharkiv07Talk 15:21, 26 March 2015 (UTC)
  • Maybe the same addition both places? "Actions that tend to discourage newcomers, such as hastily nominating new articles for deletion or tagging new articles with clean-up templates, may be considered disruptive editing if constantly repeated without exploring alternatives on the article creators' talk pages." I am looking for a proposal that really looks simple and obvious. Of course there are bound to be some editors who think biting is fun and others who think that if newbies can't shrug off biting they do not belong, so it may be hard to get consensus. Aymatth2 (talk) 15:42, 26 March 2015 (UTC)
  • I believe that an article should never be tagged for speedy deletion within the first couple weeks, unless it's a blatant case of one of the general deletion criteria (excluding G4 for a deletion discussion from over a year ago); nor for PROD/AfD unless it's a borderline case of one of these criteria. Same goes for a user page within the author's on userspace, except for U1 cases. עוד מישהו Od Mishehu 17:49, 26 March 2015 (UTC)
What about an autobiography from an insignificant person? Or if somebody writes about their band, or their cat? I think CSDs are completely justified in some of these. Kharkiv07Talk 14:34, 27 March 2015 (UTC)
The first version of a legitimate article may not look like much, but if it is not a Wikipedia:Attack page there is no great urgency to delete it: it is not doing any harm. A note on the creator's talk page is much less biting. That is particularly true with articles that do not at first give enough context, lack content or fail to indicate importance. The person may be more significant than the first draft shows, their garage band may be a huge success now, perhaps their cat is called Mr. Nuts. But if the article still looks hopeless after 24 hours, no problem with a speedy. Aymatth2 (talk) 16:06, 27 March 2015 (UTC)
How about all article csds (with the exception of the general criteria and A10) can be speedily deleted 24 hours after a friendly message is left on the creator's talk page? Kharkiv07Talk 23:13, 27 March 2015 (UTC)
  • I do not want to change the deletion criteria and processes, which have been carefully defined and tested over time, just to detect the small number of editors who consistently abuse them. A CSD or AfD request that is rejected, or a hasty A1 or A3 nomination, or excessive clean-up tagging may all be seen as bites – but may all be legitimate. If a number of different editors see biting, there may be a persistent biter that needs sanctions. Best to leave it a bit loose, so "may be considered". Aymatth2 (talk) 01:14, 28 March 2015 (UTC)
The problem with the warning system is it would be extremely subjective, unlike vandalism or test edits, this would be completely up to the reviewer's discretion which may lead to problems. Kharkiv07Talk 01:24, 28 March 2015 (UTC)
  • There is always an element of subjectivity. See Calton weavers. An editor nominated it as "G3:blatant and obvious hoax ... the deception is so obvious as to constitute pure vandalism." An admin agreed and speedy deleted the article. It was recreated and went on to DYK. In this case, if a number of different editors looking at different events see symptoms of biting that should be enough to trigger a review to determine whether there has indeed been disruptive editing. Aymatth2 (talk) 02:16, 28 March 2015 (UTC)

@Aymatth2: What if, when a page is tagged for speedy deletion and it's not pure vandalism, an admin userfies the article instead of deleting it, and leaves a notice? Kharkiv07Talk 00:15, 1 April 2015 (UTC)

  • That is always an option that an admin can follow, and that I hope they often do. I am more concerned with the impact of the deletion nomination or the maintenance template on a newbie. They walk in the room, get punched in the face, then someone tells them they came in the wrong door. Aymatth2 (talk) 01:47, 1 April 2015 (UTC)

Maintenance tags

No all maintenance tags are created equal. There are a couple issues that I pretty much always tag on new page patrol - {{linkrot}}, {{No categories}} and {{stub}}. Linkrot and categories are "just so you know" kind of tags that would apply to a very well-written article with these issues that a new editor wouldn't know about. If you tag as a stub, you shouldn't put any other tags on the article, since that is part of it being a stub. Oiyarbepsy (talk) 01:53, 29 March 2015 (UTC)

  • @Oiyarbepsy: Any tags at all will be very alarming to a newbie if they pop up almost immediately after they save their first version of an article. The first version may well just be a placeholder to check that they are indeed allowed to start an article. Better to place a helpful note on the newbie's talk page instead of hasty tagging. If the newbie ignores the note, then tag the article. This makes new page patrol a but harder, but if it reduces the number of newbies that give up on Wikipedia is a valid trade-off. Comments? Aymatth2 (talk) 02:13, 29 March 2015 (UTC)

@Aymatth2: Are you saying that cleanup and/or deletion tags should not be added to new articles created by newbies? --AmaryllisGardener talk 00:11, 1 April 2015 (UTC)

  • I am struggling to formulate this correctly, which is why I am asking for help here. I am starting from the premises that:
  1. Wikipedia has a serious shortage of new editors, particularly women
  2. Many potentially valuable contributors are not particularly combative
  3. The first attempt by a newbie to start a new article will often result in hasty tagging for cleanup and/or deletion
  4. This first attempt may be little more than a placeholder to test that they can indeed start an article
  5. A newbie will often think they have walked into a room full of hostile strangers, and will turn around and walk out again
  6. Wikipedia has a serious shortage of new editors, particularly women
I am thinking of imposing a delay between article creation and tagging (assuming the article is not immediately damaging to Wikipedia), using the newbie's talk page rather than clean-up templates to suggest improvements, and sanctioning editors who are consistently very aggressive to newbies. I strongly feel that something should be done. Aymatth2 (talk) 01:39, 1 April 2015 (UTC)
@Aymatth2: Then the solution would be to have a red notice (instead of a white one) at the top of the article creation page. That notice currently tells newbies to read YFA before creating an article, and it's their fault if they don't. Don't get me wrong, I think it's good to leave a personal message on their tp if you think they're confused, I speak as a Teahouse host and Co-op volunteer. I remember being a noob (back in December 2012), and guess what I did on my second edit (thirty minutes after my first)? I created an article! And guess what happened? It got tagged because it didn't have any refs!, and you know what I did then? I added a ref! I didn't get all teed off because what the tag said was true, I just wanted to fix it. Once you click that save button, it's out there, so I think it's perfectly fine to tag an article for a problem (or CSD it) as soon as it's there. This doesn't mean I don't care about newbies. --AmaryllisGardener talk 02:29, 1 April 2015 (UTC)
  • @AmaryllisGardener: A red notice would be scary to everyone. Some newbies will respond positively to cleanup tags, as you did, but many will not. Most will be crushed by a speedy deletion tag on the first save of an article they are just starting to write. The Natalie Smith Henry tag got Wikipedia a lot of publicity, none good. Wikipedia has a serious shortage of new editors, particularly women, but is hostile to newcomers. Facebook is more welcoming and fun. Aymatth2 (talk) 02:58, 1 April 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Dark alternative color theme

To increase power-saving awareness (and actually save a lot of electricity)[citation needed], as well as to make reading easier for users in some cases, especially on mobiles phones when reading in the dark - I suggest adding a dark Wikipedia color theme, and add a button to change between the regular and the alternative color modes.

There's a Stylebot theme for Wikipedia which is called "Dark Wikipedia Rounded", and I believe this is how the dark Wikipedia theme should look. It's very nice and easy on the eyes. You can see how it looks in the style's page. — Preceding unsigned comment added by 89.138.33.253 (talk) 01:40, 29 March 2015 (UTC)

I'm all for skins for styles sake, but do you have any RS's that this is actually a power savings? techlogg.com disagrees with you for most monitors. — xaosflux Talk 02:15, 29 March 2015 (UTC)
Apparently it depends on the display. Praemonitus (talk) 22:44, 8 April 2015 (UTC)

Synonyms available in Wikipedia

Hi Wiki Team,

I request you to keep right click option on every English word if we do not understand the word, We can right click on the word and check synonyms then and there, So we would not need to go away from Wikipedia to understand a word.

Keep Synonyms option the way Microsoft kept in MS Outlook and MS word.

Please do it as soon as possible. It would be very useful for the world specially who uses English as their secondary language. — Preceding unsigned comment added by Shanus444 (talk • contribs) 08:54, 6 April 2015 (UTC)

It isn't clear what you mean by "keep", as this hasn't been a feature of Wikipedia at any time that I can remember since mid-2004. One can select a word or phrase in Wikipedia text with the mouse, then right-click on the selected text and launch a search from the context menu with one's favourite search engine. This is a feature of most Web browsers, not Wikipedia, as such. — QuicksilverT @ 18:19, 8 April 2015 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_16&oldid=1109789969"