Jump to content

Wikipedia:Village pump (proposals)/Archive 114

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). 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: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Should the MediaWiki software be modified to include an option for specialized (such as blacklist / whitelist) blocks?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

There is some support for the idea, but there's no clear consensus, not least because participants are having to imagine how this feature would work and several raise concerns as to whether the work needed to create such a feature would outweigh its potential benefits. If the supporters feel this proposal is worth pursuing, I suggest discussion with developers might be the best way to progress the idea. HJ Mitchell | Penny for your thoughts? 19:49, 6 September 2014 (UTC)

Would a system of specialized blocks be helpful? Dustin (talk) 02:41, 24 July 2014 (UTC)

Note: This was partly discussed beforehand at Wikipedia:Village pump (idea lab)/Archive 14#Specialized blocks, and I have decided to bring my proposal here. Please read that page first, though. I have started this as an RfC because I consider it to be of significant importance.

(The following has been copied from the idea lab)

The following is a proposed change to the MediaWiki software.

I don't know if something like this has already been proposed, but a brief search on my part didn't turn up something like this, so I will put forth my ideas. Here is my possible proposal, but I am going to give it here first just so we can discuss it and refine the idea beforehand. I would propose that we modify the MediaWiki software as to allow for specialized blocks. Blocks currently only have two options: a block on editing all pages except for a user's own talk page, or a block on all pages, including the user's own talk page. In my new "specialized" block system, there would be many more options.

  1. An administrator could block a user for disruption from editing either a specific, individual page, or the block could apply to a selection of pages. In cases where a user cannot be trusted to follow a topic-ban or does not feel that he/she can follow his/her restrictions, then an administrator could simply block that user from editing a list of manually selected pages which are "at risk".
  2. An administrator could block a user from editing all pages (minus manually chosen exceptions) that have a certain prefix. For example, if one user was being overly disruptive on SPI pages (and I am not talking about vandalism), then an administrator could block that user from editing all pages starting with "Wikipedia:Sockpuppet investigations/".
  3. If there were situations where it was desired that an editor requesting an unblock edit one page apart from his/her talk page similar to this recent instance (but where the user could not be yet trusted to stay on only his/her talk page and the one exception page), then the block could be modified to ignore that one page.

I do not know how we would implement this because it is necessary that someone would develop this feature, but that is something to consider at a later point. I just want to know the opinions and/or ideas of editors. Dustin (talk) 02:42, 24 July 2014 (UTC)

  • I support the general idea, though the specifics of what kind of granularity we want is up for grabs. In particular, one thing I definitely would find useful is the ability to block IP ranges (perhaps as large as /8) from specific pages. Currently the only way to do this is with an edit filter, which impairs performance. -- King of ♥ ♦ ♣ ♠ 02:50, 24 July 2014 (UTC)
    Actually, what Graeme Bartlett said makes a whole lot of sense. And it should be possible to select an IP range as the user to be restricted by the filter. -- King of ♥ ♦ ♣ ♠ 03:43, 26 July 2014 (UTC)
  • Oppose because it would require development support from the WMF. These are essentially topic-bans with supporting block. Robert McClenon (talk) 02:52, 24 July 2014 (UTC)
  • Strong oppose The discussions on blocks have been extensive and the community has been pretty clear...no further options are required or needed. No support from me. Sorry.--Mark Miller (talk) 02:59, 24 July 2014 (UTC)
    • You obviously have neither looked at the previous discussion like I suggested, nor at the links at that discussion. Back in 2005, nine years ago, there was another proposal like this one, and it received over 80% approval. I know that was a long time ago, but why should we not reconsider? Dustin (talk) 03:04, 24 July 2014 (UTC)
      • I don't give a crap about that as you don't give a crap about other discussions so just stop complaining and let this go to the community now. You said your piece. If that isn't enough, you failed.--Mark Miller (talk) 03:08, 24 July 2014 (UTC)
  • Having this discussion here somewhat clouds the purpose of the discussion. If the goal is simply to come up with a technical specification of what such a system would look like, mediawiki.org would be a better location. A discussion here will inevitably involve local policy implications and we need to have some concrete idea of what the feature's capabilities are before such a discussion could reasonably proceed. Mr.Z-man 04:20, 24 July 2014 (UTC)
I would wonder if this is actually a local issue for Wikipedia as proposed by Dustin. I may think that dragging a discussion from 9 years ago, into this discussion isn't even relevant today but hey....lets let this go its course and see what happens.--Mark Miller (talk) 04:27, 24 July 2014 (UTC)
  • Support As I said on the idea lab this could be an edit filter just applying to one user (or IP). When optimised so that the filter only ran for 1 user there would be no performance impact on the rest. There would be plenty of fine grain here, denying uploads, moves, use of interaction banned users talk pages and so on. Graeme Bartlett (talk) 07:28, 24 July 2014 (UTC)
  • Support However, like Graeme Bartlett I would suggest to go into the direction of edit filters that apply to individual users or IP ranges. --AFBorchert (talk) 08:41, 24 July 2014 (UTC)
  • Not persuaded that usefulness outweighs the effort and complexity. For logged-in editors, this idea is a non-starter for me. If a particular user is subject to a topic or interaction ban, then either they stick to the terms of their editing restrictions, or they get blocked entirely. A user who lacks the maturity or restraint to adhere to an editing restriction (and, for that matter, who edited in a manner sufficiently disruptive to earn such a restriction in the first place) doesn't need additional technical constraints, they need to stop editing until they can control themselves.
    For IP addresses, I can see some argument for this as a way to reduce collateral damage (particularly when placing rangeblocks), but I suspect it will be more complicated than it's worth. Semi-protection already exists as a solution, though it does affect all IP editors of an article. (It's a bit blunt as a tool, but we already tolerate even long-term semi-protection of articles where warranted by circumstances.)
    From an admin standpoint, I can see this becoming rather complicated to manage and track. If I block an IP range from editing a particular article, does it show up in the IP's block log, or in the article's logs, or both, or neither? TenOfAllTrades(talk) 17:52, 25 July 2014 (UTC)
  • Oppose This is a solution looking for a problem. It introduces complexity where none is needed. If a user will not follow restrictions then a conventional block will work. Either a user is willing to follow community expectations or they are not. Specialized blocks would result in gaming of the system. Chillum 18:06, 25 July 2014 (UTC)
  • I wonder: Could selective whitelisting be used to keep someone blocked, but make it possible for them to clean up their own copyvios on specific, identified pages? That might be desirable. WhatamIdoing (talk) 18:49, 25 July 2014 (UTC)
    This goes to the point I made above. If we can't trust someone to follow editing restrictions without building a technical wall around their editing, I can't imagine we would trust them to perform a task requiring careful judgement like cleaning up copyvios—especially where they were the ones who introduced the copyright violations or plagiarism in the first place. TenOfAllTrades(talk) 19:03, 25 July 2014 (UTC)
    It's not unusual to see a request for someone to be fully unblocked so that they can help with copyright cleanup. That requires a lot more babysitting than providing access only to specified pages would. WhatamIdoing (talk) 23:16, 25 July 2014 (UTC)
  • Support the idea, assuming it is technically possible. This would make more sense than existing practice in a number of areas. In the case of 3RR violations, for instance, if an editor is causing problems by edit warring on an article then our only option for stopping them is to prevent them from editing every single page, anywhere, even though they are only causing problems on one page. It would make more sense to prevent them from editing the one page where the edit warring is taking place. Hut 8.5 10:54, 26 July 2014 (UTC)
  • Support - this would allow bans to be more-easily enforced, as well as a list of situations where it would be useful regarding blocked users (e.g {{2nd chance}}, unblock discussions in locations other than the user's own talk page). עוד מישהו Od Mishehu 19:56, 27 July 2014 (UTC)
  • Support Seems like this would be a valuable addition to the admin toolbox. Toohool (talk) 01:18, 31 July 2014 (UTC)
  • Support, ignoring the technical design requirements of which I know very little, but I think any idea worth implementing is worth doing the technical work. I'm a little concerned about difficulty using this for "broadly-construed" topic bans, but maybe we can implement a way to block users from editing pages in a particular category. It's a good idea, anyway. However, I also agree with what another user said above that if an editor can't play by community rules then full blocks and/or community bans are coming anyway. Ivanvector (talk) 15:41, 5 August 2014 (UTC)
  • Support. I like the idea behind this, in principle. Calidum Talk To Me 01:31, 18 August 2014 (UTC)
  • Strong oppose. This is not a good idea at all. Bans exist both to prevent disruptions to the community, and to give infringing editors the opportunity to remain a part of the community. They do this by abiding by the restrictions of their ban. If they are unable to do this, we gave them the WP:ROPE, and they have chosen by their actions to set themselves as being outside the community. Blocks are for those people who chose not to be a part of the community, either by contempt for the bans that the community has imposed on their editing, or by simply breaking obvious rules, eg vandalism. There is no "partial" being a part of this community. You either abide by the rules, or you don't get to participate here. Selective blocks just prevent those people who consider themselves outside of this community to demonstrate to us their decision to stand apart by violating their ban. Selective blocks open up a huge pandora's box of wikilawyering possibilities, and do nothing to promote the community. This is just plain a bad idea. VanIsaacWScont 01:46, 18 August 2014 (UTC)
    • Using the word "strong" doesn't give your !vote any more weight (I don't see why "strong support" and "strong suppose" are ever used), but that being aside from the point, I don't think you considered proposal #3. Dustin (talk) 16:31, 18 August 2014 (UTC)
      • The word "strong" indicates that it is a categorical objection or support of the proposal, rather than, say, a preferential or logistical consideration behind a person's position. And since this is a !vote, of course every !vote is weighted; that's the entire point of it being a !vote. Even though I don't understand how situation #3 can even come about - if we can't trust someone whose contribution history is logged in one place (so it's easy to revert) to have access to more than one page, how could their actions on that one page possibly instill enough trust to allow them access to any more of the project? - #3 can still be accomplished with the current permission scheme by simply copying that article content to their talk page, where they can edit away. VanIsaacWScont 18:59, 18 August 2014 (UTC)

Alternate proposal

Not sure if this is a proper format for an RfC, but here we go. Admins(explicitly not EFMs) are now permitted to make an edit filter that can block a user from editing certain pages while allowing them to edit others. This is to be treated as seriously as a block(admins are explicitly not to use these for TBANs unless a user made a TBAN infraction normally warranting a block.) For example, if a user requests to have their block discussed at ANI, that user would be unblocked and the filter modified so that the appealing user is blocked from editing any page except ANI. (To avoid confusion that would otherwise arise, admins would create one or two filters that would contain the entire system for blocking edits, something like: ((user_name==appeallingeditor) & (article_prefixedtext !='Wikipedia:Administrator's noticeboard/Incidents')) | ((user_name==TBANnededitor) & (article_prefixedtext =='ContentousArticle' | ...)) then block action, which would prevent appeallingeditor from editing any page but Wikipedia:Administrator's noticeboard/Incidents, and prevent TBANnededitor from editing ContentousArticle. (I'm sure someone can come up with some better code, I was just messing around) Cheers and Thanks, L235-Talk Ping when replying 21:31, 8 August 2014 (UTC)

  • I see that you got more into the code than I ever did... at least from the way it appears, I think I would support this proposal because it would allow for stronger enforcement by administrators, and it would meet some of the goals of my main proposal above. Dustin (talk) 21:44, 8 August 2014 (UTC)
  • Support in theory, but in practice, this may end up causing more trouble than it's worth if the number of edits which hit the EF condition limit is too hig (right now, it's at 0.77%, but it occasionally gets above 5%). עוד מישהו Od Mishehu 08:19, 13 August 2014 (UTC)
  • Well the hitting the EF limits is why I suggested getting special support for edit filter per user or IP in the code. This would make it very efficient, as it would only run for the affected user. Graeme Bartlett (talk)
  • This bot keeps on archiving this discussion, which is definitely an issue. What next now? I seem to have received at least some degree of support, so I don't think we should just archive this away. Dustin (talk)
    You could try filing a feature request at bugzilla and see if someone wants to program this functionality. And then perhaps another RFC to see if we want to enable it here if it ever gets programmed. –xenotalk 03:12, 3 September 2014 (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.

I don't know what the best venue for contacting the developers is, but I might try to register a bugzilla account and bring the issue up there as suggested by Xeno. I guess that's about it for this discussion for now. Dustin (talk) 23:02, 11 September 2014 (UTC)

Leading zero

Normal English does not use leading zeroes (e.g., 02 September 2014), so I wish we wouldn't in non-technical places. I am against have publication/birth/death/start/end dates in the right-hand boxes listed with leading zeroes in dates under 10 followed by a month and year. I couldn't find this in perennials. Has this been discussed? Is there a policy? Kdammers (talk) 03:27, 11 September 2014 (UTC)

Wikipedia:Manual of Style/Dates and numbers doesn't seem to mention anything about it. --NaBUru38 (talk) 03:42, 11 September 2014 (UTC)
Please link to an article showing the issue. Johnuniq (talk) 03:58, 11 September 2014 (UTC)
Yes it does, see table at MOS:BADDATEFORMAT, it's in the second column as "09 June"/"June 09" and in the third col as 'Do not "zero-pad" month or day'. --Redrose64 (talk) 07:00, 11 September 2014 (UTC)
O.K., then I'll start cleaning up sites that don't comply. Kdammers (talk) 07:13, 11 September 2014 (UTC)
@Kdammers: BattyBot removes the leading zeroes in citation dates where they cause CS1 errors. (e.g. this edit) If you notice places where BattyBot isn't making the fixes, please let me know so I can tweak my script. Thanks! GoingBatty (talk) 02:32, 12 September 2014 (UTC)

Articles for creation script upgrade

Hi all,

You may be interested in this discussion, concerning changing the script enabled in gadgets to review AfC submissions. Thanks. --Mdann52talk to me! 12:50, 12 September 2014 (UTC)

Can we set off in the direction of more Help

I'd like to suggest that we write manual pages for the most-often-linked-to (at personal talk pages) policies, including documentation on frequent mistakes and misunderstandings (which admittedly have no place in policies), so that policy is only used for edge cases (assessing deletion criteria and the like) — not for getting started.

I suppose I could do this by myself, but that'd not be collaborative, and I'm not currently comfortable with the lengthy FAQ pages format or contributing to them (I'd personally have 1 page for each FAQ or perhaps a separate namespace, or really anything close to a structured help section of the site with each help item of small size, focusing on a single point). --Gryllida (talk) 11:34, 13 September 2014 (UTC)

Category:Expired editnotice

Resolved

Category:Expired editnotice currently contains two types of editnotices:

  • editnotices which don't have an expiry time set, and
  • editnotices which have an expiry time, which has passed.

At Wikipedia_talk:Editnotice#Category:Expired_editnotice, I have proposed that editnotices which don't have an expiry time set (which are possibly/probably intended to be "permanent") should not be included in this category, in order to better identify editnotices which have an expiry time, which has passed (which are probably obsolete and likely candidates for deletion). In the interests of keeping the discussion in one place, please express any views you may have on the matter at Wikipedia_talk:Editnotice#Category:Expired_editnotice. Thanks. DH85868993 (talk) 03:16, 11 September 2014 (UTC)

The template error has been fixed. The category is now named Category:Expired editnotices with an "s". -- John of Reading (talk) 06:27, 14 September 2014 (UTC)

Widen usage of Draft-class

Background

The Draft namespace was enabled in December 2013 (see Wikipedia:Drafts) and some WikiProjects (currently 1,485) have opted to use the Draft-class assessment to keep track of draft articles within their scope. The advantage is that it facilitates editors in a project to work on improving draft articles within their knowledge and interest to get them ready for mainspace.

Proposal

This proposal is about whether this usage should be widened by making it one of the default assessment classes used by projects. There are 3 options:

  1. Status quo: projects can opt-in to using Draft-class.
  2. Add Draft-class to FQS: all projects currently using the "Full Quality Scale" (FA, A, GA, B, C, Start, Stub, FL, List, NA, Category, Disambig, File, Portal, Project, Template) (approximately 1300) will automatically have Draft-class enabled, unless they choose to opt-out.
  3. Add Draft-class to all: all projects using the standard quality scale (FA, A, GA, B, C, Start, Stub, FL, List, NA) (approximately 1900) will automatically have Draft-class enabled, unless they choose to opt-out.

For more details (including how this would be done), see Template talk:Class mask#Protected edit request on 1 September 2014

Discussion

  • The Draft namespace is here to stay and is proving to be a useful place to develop articles. Currently, virtually all namespaces (e.g. templates, portals, categories, project pages) have their own assessment class and are included in the full quality scale. The File-class was the most recent one to be added. Therefore projects which have selected to use the FQS are probably interested in using the Draft-class, so I think option 2 is probably the most sensible. — Martin (MSGJ · talk) 13:22, 3 September 2014 (UTC)
  • I choose Option 2 (Add Draft-class to FQS). --Redrose64 (talk) 13:58, 3 September 2014 (UTC)
  • Good thinking, Martin. I support option 2. --122.109.102.172 (talk) 11:19, 4 September 2014 (UTC)
  • Well, on the one hand, there are already a lot of rating classes as it is, but on the other hand, "Full" should really mean "Full", so I guess I would weakly support Option 2... Cooljeanius (talk) (contribs) 16:01, 4 September 2014 (UTC)
Note, Full doesn't include Book either. -- WOSlinker (talk) 11:46, 5 September 2014 (UTC)
It also doesn't include User, MediaWiki, Help, Education Program, TimedText, Module, Topic. --Redrose64 (talk) 12:10, 5 September 2014 (UTC)
As those namespaces do not contain articles, draft articles, or components of articles such as templates, they are not actually relevant. Roger (Dodger67) (talk) 09:24, 9 September 2014 (UTC)
Modules are components of templates (see, for example, Module talk:AUshield); and TimedText pages are components of Files (e.g. TimedText talk:03 Pink Try.ogg.en.srt). --Redrose64 (talk) 11:32, 9 September 2014 (UTC)
  • I prefer option 2, but I won't be heartbroken by option 1. Protonk (talk) 13:00, 5 September 2014 (UTC)
  • As a regular AfC reviewer I prefer Option 3 but Option 2 would be acceptable too. The lack of a mechanism to routinely "notify" WikiProjects of the existence of drafts within their scope has been a perennial issue at AfC - thus I support the full implementation of this proposal. Roger (Dodger67) (talk) 09:24, 9 September 2014 (UTC)
  • I was summoned here via Feedback Request Service, and I'm really not sure what Draft class provides that isn't already catered for by stubs, specifically as draft class seems to be intended to be used in conjunction with the draft namespace, which hides articles from potential contributors. Maybe someone can explain how this is a benefit to the everybody-can-edit model. Samsara (FA • FP) 00:29, 13 September 2014 (UTC)
    @Samsara: As you surmise, many drafts get created with few people knowing of their existence - the page creator, and those people who routinely check Draft: space for new creations. In order to bring these to wider attention (and hopefully encourage others to assist with bringing the draft up to a suitable standard for mainspace), Draft talk: pages may be tagged with WikiProject banners in the same way as the talk pages of regular articles. For those WikiProject banners which have already opted in to Draft-class, such as {{WikiProject Albums}}, if the banner is given |class=draft, or if the |class= parameter is left blank or is omitted, then the talk page is placed in a category like Category:Draft-Class Album articles. For those WikiProject banners which have not already opted in to Draft-class, such as {{WikiProject Jazz}}, the talk page is placed in a category like Category:NA-Class Jazz articles, even if the banner is explicitly given |class=draft. As I write this, there are two Draft talk: pages tagged for WikiProject Jazz, but Category:NA-Class Jazz articles has 81 members. Segregating the Draft talk: pages into a category of their own - which would be Category:Draft-Class Jazz articles - will help those two to be found more quickly, and shouldn't go unnoticed among the 70+ pages marked with |class=redirect that seem to comprise the bulk of the cat. This segregation may either be done by WikiProject Jazz opting in, in a similar manner to WikiProject Albums; or it may be done by a general change affecting the majority of WikiProjects. --Redrose64 (talk) 10:44, 13 September 2014 (UTC)
    I see that there's a complaint that the use of Draft space is associated with a growing review backlog. Is it really sensible to further encourage its use? In other words, is the review backlog a net benefit to Wikipedia, compared to allowing the articles to be stubs in regular space? For years, there has been concern that the rate of article creation is in decline. What has the effect of draft space on this been? It would seem possible to collect and publish some relevant data - maybe someone already has? Thanks for any further insights. Samsara (FA • FP) 15:13, 13 September 2014 (UTC)
    If the WikiProjects are made more aware of the drafts, perhaps some of their members will take up AFC reviewing, and so reduce the backlog. --Redrose64 (talk) 19:36, 13 September 2014 (UTC)
  • Support Option 2. It fits better in the full list than the cut down standard list. If the draft space is "here to stay" as mentioned above, it needs to included correctly in the pretty WikiProject article counts tables - see my query here. The-Pope (talk) 10:47, 14 September 2014 (UTC)
  • Support 3, but 2 is acceptable as a first step, tho I don;t see why it has to go in steps--it is hardly going to be disruptive. Any wikiproject or individual editor that doesn't want to use the information can easily ignore it, but if even 1 person from each project pays attention to it it will help get better reviews. DGG ( talk ) 09:06, 23 September 2014 (UTC)

Should we move Editor Retention to the Wikipedia Name Space?

The discussion's initiator has withdrawn the proposal. —David Levy 02:05, 15 September 2014 (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.

I propose we move Wikipedia:WikiProject Editor Retention from the project space to the Wikipedia:Namespace. The reason for the move would be to establish the project as more than just another WikiProject in hopes that we can gain consensus on guidelines for retaining new and old editors in a more structured manner.

  • Support as proposer The project has become one of the few projects that is known for more than just a simple collaboration of a handful of editors to become one the encyclopedias better known attempts at addressing editor retaining issues, similar to the Teahouse.--Mark Miller (talk) 08:25, 14 September 2014 (UTC)
  • Comment The Wikipedia namespace is the Project namespace, see WP:Project namespace. What you probably mean is dropping the "WikiProject" part from the page title. But what would the new title be? Just "Wikipedia:Editor Retention"? That sounds like a place where you would find the final consensus guidelines, not the project working on them. And what's wrong with being a WikiProject? Just that they come in vastly different sizes and scopes doesn't mean they're all unimportant. — HHHIPPO 08:51, 14 September 2014 (UTC)
    I ask because you write that you want to establish the project as more than just another WikiProject. That sounds to me like you see a disadvantage of this project being classified as a WikiProject, but I don't see why. I don't claim there is no reason, I just don't see it, that's why I ask.
    Let me use an example: we have a WikiProject on Accessibility. Their project page is at Wikipedia:WikiProject Accessibility and the guidelines they worked out at Wikipedia:Accessibility (in their case behind a redirect). Similarly, I think it would be a good idea to put guidelines regarding editor retention at Wikipedia:Editor Retention, but I don't see why one should move the whole project page with all it's subpages to that name.
    I'm not sure what you mean by name space. Technically, Project: and Wikipedia: are aliases for the same namespace. Try for example Project:Village pump, that points to the same page as Wikipedia:Village pump. So you can't possibly move from the project space to the Wikipedia:Namespace, all you can do is dropping the "WikiProject" part in the pagenames of all the pages belonging to this WikiProject. And all I'm asking is why you want to do this: what's wrong with the old names, and shouldn't the new place hold the results rather than the project pages? I hope I made that a bit clearer now. — HHHIPPO 09:55, 14 September 2014 (UTC)
    Not really. Jumping to conclusions with me is not the best route. You seem to be taking a leap to accuse me of bad faith with the WikiProjects and that is incorrect. That is your accusation. It is not fact and really just takes a huge leap of bad faith. I get what you are trying to say, but we do have two separate spaces. While a WikiProject is in the Wikiname space it is a project space and my hope is to elevate editor retention to more than just a local consensus of editors and bring it under the wider scope of the general community. Thanks.--Mark Miller (talk) 10:04, 14 September 2014 (UTC)
    I'm no trying to accuse you of anything, sorry if I wasn't clear enough. I'm just asking you what you're actually proposing and why. I'm a scientist, when I ask a question that doesn't mean I want to insinuate the non-existance of an answer, it simply means I'm interested in what the answer is! So could you please explain what you mean by Wikiname space and what by project space? In your original post you explicitly linked to the technical meaning of "namespace" in the framework of the MediaWiki software, but I'm not sure if that's really what you mean.
    Note that I didn't ask what's wrong with WikiProjects, I asked what's wrong with calling Editor Retention a WikiProject. That doesn't imply anything bad about WikiProjects and it neither implies that you have anything against WikiProjects. It just means that I'm interested in why you want to change the current situation. Is it really so condemnable to ask "why?" when someone proposes something? — HHHIPPO 10:54, 14 September 2014 (UTC)
    Thank you very much for the above. Wikipedia has two pages for these definitions. While the wording would make one assume they are, together, the same thing... they are, in fact not. The Wikipedia:Namespace is simply the Wikipedia page with no further extension and has been defined as the wider consensus of the general community, while the Wikipedia:Project namespace is the local consensus of a small band of collaborating editors. A local consensus cannot override the broader community consensus. If the two were actually the exact same thing, Wikipedia would not feel inclined to have two, separate pages defining the space. I seek to bring Editor Retention to the broader community to begin forming guidelines that could help improve the Wikipedia project as a whole. How that can be achieved is only through the broader community. It is never condemnable to ask "why?", but only to assume there is something "wrong" with being a WikiProject. But...WikiProjects have their limitations and I truly believe that Editor retention has outgrown the boundaries of the WikiProject space and could be a true improvement to Wikipedia in many ways. Not just by advancing proposed guidelines but by actually taking a more proactive approach to editors learning how the encyclopedia functions and helping to guide both the new editor and the old editor in a direction to make their experience more positive and productive. I do apologize for my taking offense. It was only in the wording of assuming I have an issue with the projects. I do not. I have been very active with the projects in a number of ways, including attempts to revive Project Rome as well as founding a few other projects myself...although Editor retention was founded by Dennis Brown, it is something I have taken to be a vital part of my contributions at Wikipedia. There are many editors who also contribute to the project and it is my hope to bring their work to the forefront of the overall project we call Wikipedia. As always consensus will determine if this should happen. I hope it succeeds but...if it remains a WikiProject, it will simply continue along the same lines, as limited as that may or may not be. Thank you once again!--Mark Miller (talk) 11:41, 14 September 2014 (UTC)
    @Mark Miller: I think that you may be misinterpreting the page titles.
    • Wikipedia:Namespace is a page which explains what a namespace is, and describes all of the namespaces in general terms. It is itself in the Wikipedia namespace - you can tell this because its name is prefixed with "Wikipedia:". The same page can be reached in two other ways: Project:Namespace and WP:Namespace. If you follow either of those links, you'll find that they end up at exactly the same page
    • Wikipedia:Project namespace is a page which describes one specific namespace: the Wikipedia namespace, which is also called the Project namespace. Its name is prefixed with "Wikipedia:", so like Wikipedia:Namespace, it is also in the Wikipedia namespace; and like that page, it can also be reached in two other ways: Project:Project namespace and WP:Project namespace.
    Any page whose name is prefixed "Wikipedia:" - such as Wikipedia:WikiProject Editor Retention - is in Wikipedia namespace, but it is also in Project: namespace. The two are inseparable.
    So, to take your original proposal, to move Wikipedia:WikiProject Editor Retention from the project space to the Wikipedia: namespace, this cannot be done - because it is already there. What I think you are requesting is that the existing page in Wikipedia: namespace that is called Wikipedia:WikiProject Editor Retention should be renamed Wikipedia:Editor Retention. That is a simple page rename, and does not involve a change of namespace. --Redrose64 (talk) 16:26, 14 September 2014 (UTC)
    Thanks. I think it is a matter of perspective to me as I do see that the project space is in the name space area but that the project space is still limited as a local consensus.--Mark Miller (talk) 22:14, 14 September 2014 (UTC)
    Project space = Wikipedia space. Wikipedia space = Project space. There is no difference, no distinction. --Redrose64 (talk) 23:29, 14 September 2014 (UTC)
  • Oppose, for now, until/unless a more compelling reason is presented. I like the "working group" aspect of the WikiProject, and the list of participants is helpful since not all editors care to work on editor retention. I agree that the plain WP: is currently used more for information, essays, policies, etc.. The Teahouse shows that it can be used for discussion as well, bit it's really a help desk, not a discussion and consensus building forum. There are also the Village Pumps, which draw a lot of general discussion, but have less focus that a WikiProject. I agree, though, that WP:WER has an important role and could use wider participation. —Anne Delong (talk) 11:52, 14 September 2014 (UTC)
  • Oppose for the same reasons as Anne Delong - it is a project and a good one, and the name fits. Dougweller (talk) 16:54, 14 September 2014 (UTC)
  • Oppose. Setting aside Mark Miller's misunderstanding of the namespace setup (which has been explained above), I disagree that it would be helpful to drop the "WikiProject" designation in this instance. WikiProject Editor Retention functions exactly as WikiProjects normally do, and I see no reason to change that (or to alter an accurate description). —David Levy 16:57, 14 September 2014 (UTC)
  • Withdrawn per the advice and comments above, as well of the discussion on my talk page with isaacl I am withdrawing this proposal as not needed for the goals I seek. We don't need to tear down something, to build something else up. Thanks for all the input!--Mark Miller (talk) 00:00, 15 September 2014 (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.


Proposal concerning scope of verifiability and definition of original research

There is a proposal here that concerns our stance towards local interpretations of verifiability. Currently, most of the responses to the proposal are from members that are closely associated with the WikiProject that gave rise to the discussion. I believe the proposal could benefit from some broader perspectives. Thank you. Samsara (FA • FP) 16:54, 13 September 2014 (UTC)

This is primarily a discussion about whether you can use an image in an article if there are no published reliable sources that says this photo that looks exactly like the San Francisco skyline really is a photo of the San Francisco skyline (all the way down to far more complicated cases). WhatamIdoing (talk) 00:11, 16 September 2014 (UTC)

new namespace: taskforce...or clubs

I feel that we need a space where people can create loose groupings, i.e. social groups or task-oriented groups, to gather some like-minded editors to help them edit entries in particular topics in areas of relevant interest. I propose that we have a new namespace, to be called "taskforce." alternately, it could be called clubs, but that is my second lesser preference for this idea.

I know we already have portal spaces for this and wikiprojects, but it is not the same. this would be more informal, and group on any topic or set of topics that people might wish.

It would have the benefit of drawing more interest here and generating more energy and activity in editing wikipedia.

comments? --Sm8900 (talk) 13:39, 12 September 2014 (UTC)

What would the difference betweeen this and WikiProjects be? Sam Walton (talk) 14:09, 12 September 2014 (UTC)
thanks for your comment. there can only be one WikiProject for a particular topic. this would allow any person or group of people to set up their own club for editing for a topic or for an area within a topic, even if there is already a wikiproject in existence precisely for that area or topic. --Sm8900 (talk) 14:19, 12 September 2014 (UTC)
Not seeing a difference. Project members will periodically do that now. Is your proposal designed to just add more social interaction into Wikipedia? GenQuest "Talk to Me" 14:24, 12 September 2014 (UTC)
WikiProjects often have overlapping areas. There can be more than one WikiProject for a particular topic, and these are often associated through the taskforce system. For example, railways come under WikiProject Trains; railways in the UK come under WikiProject UK Railways; railways in Scotland under WikiProject Transport in Scotland; and railway locomotives under WikiProject Trains/Locomotives task force. So a talk page like Talk:NBR 224 and 420 Classes has one WikiProject banner - {{WikiProject Trains}} - but with various parameters |UK=yes|Scotland=yes|locos=yes to bring in all those other projects and taskforces. Moreover, an article's talk page can have more than one WikiProject banner template. --Redrose64 (talk) 15:11, 12 September 2014 (UTC)
I think that our existing taskforce structure handles these things just fine. bd2412 T 16:33, 12 September 2014 (UTC)
I am trying to tap into the vast potential for interactive collaboration which exists on the Web. we can generate a lot more input if we give people much more leeway tos et up their own informal groupings of editors who can share interests and activities. I am saying that there should not be just one Wikiproject United States, for example; there should be ten, if people would like that. so this would be more informal, and more interactive. --Sm8900 (talk) 20:52, 12 September 2014 (UTC)
That sounds like chaos. If the ten groups agree with each other, it's duplication of effort; if five of them disagree with the other five, what happens then? --Redrose64 (talk) 21:07, 12 September 2014 (UTC)
well, any disagreements would only occur in the editing of the articles themselves. and there's no reason to think that this would generate that much more editing or conflicts on any single article in particular. It is much more likely that this would generate a marginally greater amount of activity on a number of separate articles which each appeal to different interest groups.
so therefore, for example, I would not expect 100 new editors to try to edit United States simultaneously; rather we might get one group which would pay more attention to the Civl War and the Old West, and another one to pay more attention to Theodore Roosevelt and the Progressive Era, and so forth. --Sm8900 (talk) 22:12, 12 September 2014 (UTC)
I still don't see why the article talk pages are not the most suitable venue for discussions which cover that specific article, nor why WikiProject talk pages are not the most suitable venue for discussions which cover more than one article. --Redrose64 (talk) 22:41, 12 September 2014 (UTC)
I'm also wary that it might encourage POV-oriented interest groups. Alsee (talk) 02:41, 13 September 2014 (UTC)
I'm sceptical as well. We already have article and user talk, WikiProjects, taskforces and various more specialized discussion venues. I don't see a use case that's not covered by this. And even if we would want to establish yet another type of discussion pages, why would it need it's own namespace? Even WikiProjects don't have that. — HHHIPPO 11:03, 13 September 2014 (UTC)
hm, ok. how about implementing this as a new type of item, but without a new namespace? let me know what you think. --Sm8900 (talk) 00:49, 14 September 2014 (UTC)
I still think the same as yesterday: I don't see a use case that's not covered by the existing types of discussion venues. — HHHIPPO 09:59, 14 September 2014 (UTC)

hm, ok. anyone else wish to comment? --Sm8900 (talk) 19:08, 15 September 2014 (UTC)

You wrote above, "there can only be one WikiProject for a particular topic". This is not true. The guideline says, "there is no rule that prohibits two separate groups of editors from being interested in the same articles". We don't recommend it, because it's inefficient, but it's perfectly "legal" to set up a WikiProject that happens to have the same scope as a pre-existing one. WhatamIdoing (talk) 00:08, 16 September 2014 (UTC)

Call to close

Consensus seems to be "not needed" (per HHHippo above), or it is too unclear/unfocused and needs refinement and resubmission at a later date. Call to close this proposal by lack of consensus. GenQuest "Talk to Me" 18:56, 16 September 2014 (UTC)

About the community portal

This portal's section "help out" should have "Create these articles", "Represent a worldwide view" and "Add historical information" as well, since in English Wikipedia there are still plenty of uncreated notable articles and articles requiring globalization or historical information, and these issues are not less important than articles requiring update. By the way, in the past this section has the block "Create" (I forgot its exact name, it refers to uncreated articles).--RekishiEJ (talk) 15:39, 16 September 2014 (UTC)

And {{Recent changes article requests}} should be transcluded to the block "Create these articles", since the template contains some uncreated notable articles.--RekishiEJ (talk) 15:41, 16 September 2014 (UTC)

Personal Names

As an encyclopaedia Wikipedia is a force for education, yet in the area of personal names it all too often fails. The particular names that I have in mind are East Asian names. In all parts of China, Japan and Korea surnames, clan names, call them what you will, are placed before given or personal names. Some articles follow this convention, but most don't.

Would it be polite for East Asians to call Jimmy Wales "Wales Jimmy" or Abraham Lincoln "Lincoln Abraham"? If not, shouldn't we use the proper order for other peoples' names? — Preceding unsigned comment added by 80.177.125.188 (talk) 10:56, September 18, 2014 (UTC)

It depends on the relevant Manual of Style. AFAIK, modern Japanese names should be presented in the western convention of Given name-Surname order, which is in accordance with MOS:JAPAN, while most other East Asian names should be in Surname-Given name convention. The reason for this is because English-language reliable sources will almost always use the western convention for Japanese names, but isn't consistent with the other on East Asian names. —Farix (t | c) 11:45, 18 September 2014 (UTC)
As TheFarix says, Wikipedia rules states tha we should follow the style of sources. So if the American and British press writes K. J. Choi, we don't use Choi Kyung-Ju. --NaBUru38 (talk) 17:57, 18 September 2014 (UTC)
My comment is not about article titles but just a note that the cite templates allow for this. If you have an Asian name where the family name comes first, instead of using "last=" and "first=" to give the author name, use just "last=" for the whole name, or as I prefer "author=". See, for instance, Template:Cite_book#Authors for details. Jason Quinn (talk) 19:04, 18 September 2014 (UTC)

Option to not break watchlist by day

It would be nice to have the watchlist NOT broken by day. When I log in in the morning, I want to see all changes for the last X hours. Not all changes since midnight, and then changes up to midnight somewhere else. Thoughts? Gaijin42 (talk) 14:38, 4 September 2014 (UTC)

  • Support I would also like to see this. I tend to check multiple days worths of edits at a time on the articles on my watch list. The break down by days just adds a bunch of extra clicks I have to do to find all the changes since I last looked at the article. In particular the behavior of the preference "Expand watchlist to show all changes, not just the most recent" is less than ideal when a page has changes covering multiple days. I really would like a single click from my watch list to the diff of a page between the last time I checked it out to the current version. The changes since last visit link however is restricted to the current day. PaleAqua (talk) 00:24, 5 September 2014 (UTC)
@Gaijin42 and PaleAqua: I can see several days at once, so I'm trying to work out the problem here. What are your settings at Preferences → Recent changes for:
  • Group changes by page in recent changes and watchlist
  • Show Wikidata edits by default in recent changes
and at Preferences → Watchlist for:
  • Days to show in watchlist:
  • Maximum number of changes to show in watchlist:
  • Expand watchlist to show all changes, not just the most recent
  • Hide minor edits from the watchlist
  • Hide bot edits from the watchlist
  • Hide my edits from the watchlist
  • Hide edits by anonymous users from the watchlist
  • Hide edits by logged in users from the watchlist
  • Show Wikidata edits in your watchlist
Not all of these will have a direct bearing on the matter: but I want to see how your setup differs from mine. --Redrose64 (talk) 08:46, 5 September 2014 (UTC)
I'm in the same situation as Gaijin42 and PaleAqua: I can see several days in my watchlist but they're grouped by day. The "n changes" link for a busy article that appears in yesterday's group and today's group too only shows that day's changes. The entry in today's group doesn't have a "changes since last visit" link for an article that's changed not just today but also yesterday since I last visited it. It would be great if you have a combination that works better. My settings are:
at Preferences → Recent changes for:
Y Group changes by page in recent changes and watchlist (de-activate for the "Show Wikidata" option below to work)
- Show Wikidata edits by default in recent changes and watchlist (does not work yet with enhanced changes)
and at Preferences → Watchlist for:
3 Days to show in watchlist:
999 Maximum number of changes to show in expanded watchlist: (I suppose I had a reason - I wonder what it was)
Y Expand watchlist to show all changes, not just the most recent
- Hide minor edits from the watchlist
- Hide bot edits from the watchlist
- Hide my edits from the watchlist
- Hide edits by anonymous users from the watchlist
- Hide edits by logged in users from the watchlist
Y Show Wikidata edits in your watchlist NebY (talk) 11:44, 5 September 2014 (UTC)
My preferences are very similar to NebY's. 10 Days, 1000 changes, Checked yes for expand, hide my edits, show wiki data, group changes. ( all else off ) PaleAqua (talk) 12:34, 5 September 2014 (UTC)
  • Support. @Redrose64: I think the relevant settings are "Group changes by page in recent changes and watchlist" and "Expand watchlist to show all changes, not just the most recent". With those two activated, the watchlist basically contains, for each page, the part of that page's history within the given day. However, when there are unvisited changes from several days (which could be as trivial as last night before and after midnight), the history snippet for each page is not in one place, but there is one snippet for each day. In principle there are two possible solutions to this: a) get rid of the grouping by day entirely; b) keep the section headings, but show all changes to a certain page in a single expandable list positioned at the day and time of the last change. In both cases the disadvantage would be that we need to indicate not only the time, but also the date for each individual change. But I think that's a price worth paying for having all changes to a page in a single list, so this would be nice to have at least as an option (that is, user preference).
Regarding a single click from my watch list to the diff of a page between the last time I checked it out to the current version, that is not exactly the same: with or without grouping by day, such a link is available if and only if the last visited change to a page is within the chosen time span of the watchlist. In this case the "cur" link of the last visited change has the described (and very useful) function. It would be nice if such a direct link would be available even if the last visited change is not within the selected time span. For example, the link "xx since last visit" could refer to "all unvisited changes", rather than "all unvisited changes within the time span of the watch list" or currently "all unvisited changes on that day". — HHHIPPO 22:01, 7 September 2014 (UTC)
  • Support: Any way this can be revived? It has always annoyed me that all your frequently-changing watchlist items appear twice in a watchlist that you bring up after an overnight break. Too common on this village pump page: someone comes up with an obviously good idea, a couple of people support, and there the matter ends and after no time here it is buried two archives back! I realise developers cannot pick up on every possible improvement but who decides what to pick up? and how?: Noyster (talk), 10:33, 22 September 2014 (UTC)
    • Based on the comments above, you can solve this problem either by turning off "Expand watchlist to show all changes, not just the most recent" in Special:Preferences#mw-prefsection-watchlist or by turning off "Group changes by page in recent changes and watchlist (de-activate for the "Show Wikidata" option below to work)" for Recent Changes.
      On the procedural question, when people have good ideas for software changes, they file them at bugzilla:, which is where most volunteer and staff devs keep track of software ideas. RedRose64 has an account there, as do many other people who read this board. (Accounts are free, but [a] they display your e-mail address to spammers and [b] Bugzilla is being replaced by Phabricator soon, which doesn't have that flaw.) Whatamidoing (WMF) (talk) 15:10, 22 September 2014 (UTC)
      • Thanks Whatamidoing, your first suggestion "turn off 'expand watchlist to show all changes...'" does seem to have achieved the desired result, namely that pages that changed both yesterday and today are now shown only in today's watchlist if it spans both days. (The second suggestion made matters worse). Problem solved.
        On the other matter do I understand then that 20 users can support Change A here at Village Pump, while a lone wolf requests Change B at Bugzilla which everyone else might disagree with, and it's Change B that gets made? A discussion that should no doubt take place elsewhere, but where?: Noyster (talk), 16:36, 22 September 2014 (UTC)
        • That's complicated. Ideas tend to be discussed all over the place. There have been some attempts to centralize discussions at Meta, but single-project editors (and people who don't speak English and/or German well) would ideally prefer that everything is discussed at their own project, in their own language, because it's hard to keep track of discussions that happen elsewhere (we need global watchlists, and we might get them...in a few years...assuming that SUL finalization is successful next year). However, there are 800+ WMF wkis and they cover more than 250 languages. You can't force someone to talk about Idea X at Location Y if they'd rather talk about it on a different page. (Think about how often you see a note that says "please discuss this on the other page!" and the replies are on this page.) The good news is that the larger projects, at least, have some good tech ambassadors, who spend a lot of time linking information from one to the other. With luck, one of them will notice your Change B request and provide the other side of the story. Also, the devs (staff and volunteers) will block bug tickets as requiring evidence of community consensus if it's something that their experience suggests is likely to be contentious.
          If you've got the perfect solution for this, then my boss wants to hear from you. Whatamidoing (WMF) (talk) 23:11, 22 September 2014 (UTC)
      • @Whatamidoing (WMF): No, that doesn't fix it for me. I do want to see all recent changes, not only the last one, so turning off "Expand watchlist to show all changes, not just the most recent" is not a viable option for me. But I would like these changes primarily grouped by page, and within each group sorted by date/time. Right now "Group changes by page in recent changes and watchlist" gives me the choice between (a) no grouping, only sorting by date/time and (b) grouping by date, within that by page, within that by time. So the primary grouping is always per day, even with "group per page" enabled. The only reason I can see for having this grouping per day is that it simplifies the timestamps for the individual entries. But then history pages don't do this and seem to work fine. — HHHIPPO 18:45, 22 September 2014 (UTC)
        • So if I understand this correctly, what you're getting is this:
22 September 2014
12:04 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Hajiguru‎; Pcoombe (WMF)‎]
20 September 2014
00:15 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [186.218.110.176‎; Jdforrester (WMF)‎]
and what you want is this:
22 September 2014
12:04 VisualEditor/status‎‎ (4 changes | history) . . (0)‎ . . [Hajiguru‎; Pcoombe (WMF)‎, 186.218.110.176‎; Jdforrester (WMF)‎]
Right? Or do you want this:
22 September 2014
22 September 2014 12:04 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Pcoombe (WMF)‎]
22 September 2014 7:41 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Hajiguru‎]
20 September 2014 00:15 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Jdforrester (WMF)‎]
20 September 2014 00:07 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [186.218.110.176‎]
Whatamidoing (WMF) (talk) 23:11, 22 September 2014 (UTC)
Well, both, kind of. Your 'what I get' examples are the summary lines with the actual edit lists collapsed, and so is the first 'what you want' example. The last example is similar to the uncollapsed version of what I want, but it would actually look more like this:
22 September 2014‎, 12:04 (cur|prev) . . (-433)‎ . . Pcoombe (WMF) (talk | contribs)‎ (Undo revision 1177949 by Hajiguru (talk))
22 September 2014‎, 07:41 (cur|prev) . . (+433)‎ . . Hajiguru (talk | contribs)‎ (new status update)
20 September 2014‎, 00:15 (cur|prev) . . (-23)‎ . . Jdforrester (WMF) (talk | contribs)‎ (Undo revision 1173489 by 186.218.110.176 (talk) – test edit.) (Tag: HHVM)
20 September 2014‎, 00:07 (cur|prev) . . (+23)‎ . . 186.218.110.176 (talk)‎ (new status update) (Tag: Anonymous updated project status)
That, or just like the history page, if that's easier. — HHHIPPO 20:03, 23 September 2014 (UTC)
  • This section is slightly TL;DR since I am sick and not feeling well, but if you set it to display the 500 most recent changes, and set the days to 3 or 7, then it doesn't break it by day because it always shows no more than 500 (about 24 hours worth for me, your number may be different based on how many pages and which pages you have on your list). — {{U|Technical 13}} (e • t • c) 17:52, 22 September 2014 (UTC)
No, that doesn't do the trick for me, I still have grouping by day. I guess works if the 500 edits limit restricts your watchlist to the current day, but I have only about 100 changes per day, and would like to see several days.
P.S.: Get well soon! — HHHIPPO 18:45, 22 September 2014 (UTC)
So, I wasn't clear. You get about 100 changes per day, and you want to see about 72 hours worth. So, you set it to display 300 changes over the last 5 days and it will always show the max 300 changes (which rounds it to about 72 hours). If you just want to get rid of the header lines for the days, that should be easy for you to do with a user script (without digging into it a little I can't say if it would be a css or js script) that hides them for you. — {{U|Technical 13}} (e • t • c) 13:37, 23 September 2014 (UTC)
Watchlisted pages are edited at unpredictable frequencies, it will not always be the case that 100 changes corresponds to 24 hours - or to any other duration. To show all changes within the last three (or five) days, set Days to show in watchlist: to 3 (or 5), and Maximum number of changes to show in watchlist: to zero. You can hide the watchlist date headings with CSS, there is no need for Javascript: 
div.mw-changeslist h4 { display: none; }
That would go in Special:MyPage/common.css. --Redrose64 (talk) 16:49, 23 September 2014 (UTC)
I don't have a problem with defining what edits I want to see, it's just the grouping I don't quite like. Hiding the date headings doesn't really fix that, since the history snippet I get for each page will still be split in several non-consecutive pieces, one for each day. I guess that could be re-ordered by JavaScript, but I'm not very familiar with that. I'd be more likely to write a perl script that pulls the watchlist from the API and formats it as I like. But then, it's not really that urgent. I was just happy to see that somebody posted what I thought was the same idea. It would be nice if I manage to make clear what I suggest and why, but if it won't be implemented, so be it. — HHHIPPO 20:03, 23 September 2014 (UTC)

Adding a navigation menu to the desktop version of the website

As you can see, the mobile Wikipedia application has a navigation menu which allows users to navigate to other parts of the page without having to scroll just to look for a specific section.

I would like to propose that a similar navigation menu be added to the desktop version of Wikipedia to allow users to navigate to different parts of the page without having to go all the way back up to the contents table. Sam.gov (talk) 21:36, 23 September 2014 (UTC)

Hi! I'm a bot operator and I wish to hear your opinion about a new task I'm working on. It's all about improving the wikilink specificity and clarity. In order to understand exactly what I mean, I suggest to take a look at

These guidelines could sound a bit pedant at first sight, but they are very important in order to get pages with useful links for the reader. For example:

  • Flatline is an [[independent record label]].

is better than

  • Flatline is an [[Independent music|independent]] [[Record (music)|record]] [[Record label|label]].

because independent record label is a much more specific link for that topic. Linking three different more generic articles is not "more information", just overlinking. Too many different links can make the choice difficult on a pc, and a matter of luck on a mobile device. Note that it is better also than

  • Flatline is an [[independent record label|independent]] [[record label]].

because the link "independent" lacks of clarity. The piping has to be as much intuitive as possible because the reader does not see the wikitext (Principle of least astonishment). Moreover there is no need to link also [[record label]] because clicking on the narrower topic (independent record label) the reader will find either a link to "record label" or an explanation of the meaning. There are around many wikilinks with a low level of specificity and lack of clarity/intuitiveness, but actually I noticed that some of them can be improved safely with a bot. Some examples:

  • single specific link with unneeded piping
    • attack on [[Attack on Pearl Harbor|Pearl Harbor]] --> [[attack on Pearl Harbor]] (Will the link point the harbor or the japanese attack? Lack of clarity.)
    • canton of [[Canton of Bern|Bern]] --> [[canton of Bern]] (Will the link point the city "Bern" or the "canton of Bern"? Lack of clarity.)
    • [[Canton of Bern|canton]] of Bern --> [[canton of Bern]]
  • general+specific pairs
    • [[golf]] [[Golf club (equipment)|club]] --> [[golf club (equipment)|golf club]] (Lack of clarity on the second link, it's better a single specific and intuitive link, inside golf club (equipment) there will be a link to golf if related)
    • [[Bible]] [[Bible translation|translation]]s --> [[Bible translation]]s (Lack of clarity on the second link, it's better a single specific and intuitive link, inside Bible translation there will be a link to Bible)
    • [[Central Intelligence Agency|CIA]] [[CIA World Factbook|World Factbook]] --> [[CIA World Factbook]]
    • [[Bristol Aeroplane Company|Bristol]] [[Bristol Blenheim|Blenheim]] --> [[Bristol Blenheim]]
    • [[Lake County, Ohio|Lake County]] [[Lake County Courthouse (Ohio)|Courthouse]] --> [[Lake County Courthouse (Ohio)|Lake County Courthouse]]
  • specific+general pairs
    • [[weak base|weak]] [[basic (chemistry)|base]] --> [[weak base]] (the reader will find a link to basic (chemistry), or an explanation, inside weak base)
    • [[Newark, New Jersey|Newark]], [[New Jersey]] --> [[Newark, New Jersey]] (the reader will find a link to New Jersey in Newark, New Jersey, the topic here is Newark)
    • [[Hesychius of Alexandria|Hesychius]] of [[Alexandria]] --> [[Hesychius of Alexandria]] (as above)
    • [[open architecture|open]] [[computer architecture|architecture]] --> [[open architecture]] (as above)

I will pay some attention also to the letter case, for example I will not change the capitalization choice of the editor in order to avoid mistakes:

  • [[Aurès Mountains|Aurès]] and [[Atlas Mountains|Atlas]] mountains --> [[Aurès Mountains|Aurès]] and [[Atlas Mountains|Atlas mountains]]
  • the [[The Exodus|Exodus]] --> [[the Exodus]]

At the moment I'm not going to fix links like these:

  • [[aqueous]] [[solution]] --> [[aqueous solution]] (Exists an article about the whole expression, but who knows, is the text talking about aqueous solution or another homograph topic?)
  • [[Sand]] [[Casting (metalworking)|casting]] --> [[Sand casting]] (as above)
  • [[web]] [[page]] --> [[web page]] (as above)

It could be useful to create a collection of substituions for some common "mis-linkings" of this kind, but it would be a drop in the ocean.

Later I could be able to fix also links like these:

  • [[chemical]] [[base (chemistry)|base]] --> [[chemical base]] (the whole expression "chemical base" is a redirect to base (chemistry), one of the linked articles)

As you can see I'm just enforcing the Linking guideline where I can be sure of the correct target article, nevertheless the overall linking quality will be improved. Few days ago I opened a discussion at Wikipedia talk:Manual of Style/Linking#Improving link specificity, but a more wider and deeper discussion was needed. So, what do you think about the idea? -- Basilicofresco (msg) 01:12, 24 September 2014 (UTC)

I like what you are setting out to do. I think you're more likely to find linkages like:
  • [[Attack on Pearl Harbor|attack]] on [[Pearl Harbor]] (instead of attack on [[Attack on Pearl Harbor|Pearl Harbor]]) and
  • [[Cantons of Switzerland|canton]] of [[Canton of Bern|Bern]] (instead of [[Canton of Bern|canton]] of Bern).
These could easily be built into that logic in your regexes.
Then, there are other commonly-seen combinations like
  • [[List of Prime Ministers of India|15th]] [[Prime Minister of India|Prime Minister]] of [[India]]( or [[List of Prime Ministers of India|15th]] [[Prime Minister of India]]);
  • [[President of the United States|President]] [[Barack Obama]] (or [[President]] [[Barack Obama]]);
  • [[Secretary-General of the United Nations|Secretary General]] of the [[United Nations]], [[Kofi Annan]] (or [[Secretary-General]] of the [[United Nations]], [[Kofi Annan]]) that could be rationalised.
-- Ohc ¡digame! 01:46, 24 September 2014 (UTC)
Thank you. Your suggestions 1 and 2 are already included by the regex scheme. What are you suggesting for #4? [[Barack Obama|President Barack Obama]]? -- Basilicofresco (msg) 06:09, 24 September 2014 (UTC)
I agree with your proposal, with the exception of the Newark, New Jersey example (i.e. hierarchies of places); especially in infoboxes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:47, 24 September 2014 (UTC)
I agree, but including the Newark, New Jersey case. There have been discussions elsewhere within the last five years- although it's hard to recall exactly where - but the feeling was that a separate link for New Jersey was superfluous, because if they don't know where New Jersey is, they're hardly likely to know where Newark is either; and if they really need to know where NJ is, it's only one click extra. Often I have seen people changing from the [[Newark, New Jersey]] form to the [[Newark, New Jersey|Newark]], [[New Jersey]] form - and I'm about to revert when somebody else does it first. --Redrose64 (talk) 11:57, 24 September 2014 (UTC)

Turn off automatic generation of reference lists on talk pages

Apropos of the discussion here, I would like to propose that the automatic generation of reference lists be turned off on talk pages. It is almost never the case that a reference list is wanted at the end of a talk page. It confuses the end of the talk page, and seems to be attached to the last thread, which is in fact normally unrelated. Most of the time, references are present on talk pages only incidentally due to content being copied and pasted from the article. Usually there is no requirement for these to be expanded. Where there is a requirement, users can explicitly include the list within the relevant thread, where it belongs. 86.190.50.118 (talk) 13:51, 23 September 2014 (UTC)

Already requested via T70324 - Cite: Add namespace detection for automatically generated reference list. Vote for it and some developer may work on it. --  Gadget850 talk 14:49, 23 September 2014 (UTC)
That is marked as "RESOLVED WONTFIX". I don't see any mechanism for voting on it. Do you mean we should comment that we would find it useful? I would think that a discussion here would be inappropriate. Personally, I'm a big fan of the idea. I can't think of a use case for automatic reference generation in anything but the main namespace and maybe in the "Wikipedia" namespace. Certainly it should be turned off in Talk.
The only question I'd have about the implementation is how you'd want it to handle <ref> tags - should the superscript numbers still be generated? Should the reference be placed in-line, or should the content be effectively ignored? I'm thinking content-ignored is the best way to go.0x0077BE [talk/contrib] 15:02, 23 September 2014 (UTC)
I'd be opposed to a change like this. Like I said on the other thread, if you don't want a reference list, then don't use ref tags. Jackmcbarn (talk) 15:03, 23 September 2014 (UTC)
I think that's a bad way to look at things. It's a design flaw if you're requiring users to be "smart" about things. People do use ref tags in talk pages, often times in one conversation thread of many, and often the people who do that are exactly the kind of people who don't know to put a references tag at the end of the section. What that means is that for everyone else there's now pointless citations (which no one wanted) at the end of the page, and someone else has to go find the relevant section and add a section reference tag to it. Even if you think people "shouldn't be dumb enough to make that mistake", they are making the mistake and it is annoying people. So the question is, is there a reason not to add this feature (i.e. is anyone actually making use of the automatic reference generation in Talk pages?). I would argue that they are not, so it's a no-brainer to put this on the to-do list, even if you feel the priority is relatively low. 0x0077BE [talk/contrib] 15:10, 23 September 2014 (UTC)
People copy chunks of articles without specifically wanting the refs, just that it's a nuisance to go through removing them. There are lots of existing talk pages where this change is now being applied retrospectively. At the time when people originally copied the content no reflist would have appeared, so there would have been seemingly no need to do anything further. Now the layout is suddenly messed up. In new cases, where a new thread now triggers the auto-reflist for the first time, it would presumably appear correctly positioned to the editor as the new thread would be the last one. Only later, as new threads are added, would the layout break. Many people in any case would not know how to suppress the reflist (I didn't; although I'm somewhat aware of the mechanism for putting them in articles, I did not realise that inserting the appropriate directive in the middle of the talk page would suppress the auto-generated list at the end.) The design of this is the wrong way round for talk pages. People who want to include the reflist should be obliged to do something to make it appear, not the other way around. 86.190.50.118 (talk) 17:07, 23 September 2014 (UTC)
The reflist can be hidden; see {{reflist hide}}, but I don't see where that helps. --  Gadget850 talk 23:43, 23 September 2014 (UTC)

The ideal would be for the automatic reflist on talk pages (and probably some other non-article pages) to be created at the end of the relevant top-level section. PamD 07:56, 25 September 2014 (UTC)

That is a pretty obvious idea! Support. — HHHIPPO 20:21, 25 September 2014 (UTC)
This would be an improvement on the current situation, but still not ideal. Generally the newest discussions are at the bottom of a given section, and having a bunch of references there is not always going to be a good thing - probably OK if it's one or two, if you get towards 6 or 7 that's a significant chunk of text to delineate from conversation.
I think the default should be that no reference list is generated on talk pages unless you explicitly ask for one. I think people are way more likely to be annoyed by unwanted references at the bottom of a given section than they are likely to be annoyed by having to put the <references /> tag at the end of their section. I also think people are way more likely to know to put <references /> at the end of a section to generate a reflist than to know to put {{reflist hidden}} to hide one, so it seems to me that the default on Talk pages should still be no reference list generated.0x0077BE [talk/contrib] 15:20, 26 September 2014 (UTC)
T32763 (Cite: If there's no <references /> block on the page, insert the wikitext for one automatically in the right place) --  Gadget850 talk 19:24, 26 September 2014 (UTC)

Should we transition the rename process to m:SRUC?

Please see Wikipedia:Bureaucrats' noticeboard#Should we transition the rename process to m:SRUC? and discuss. –xenotalk 18:42, 29 September 2014 (UTC)

Distinguishing between New Pages Patrol reviews and AfC reviews

Closing per request at WP:ANRFC. Consensus was in favor of changing the terminology from "reviewed" to "patrolled" for New Page patrolling as way to distinguish it from formal reviews at Articles for Creation; this has also already been implemented. That said, while it was agreed that it is an improvement, there were legitimate concerns about the term "patrol" still being misunderstood. It may suggest to an editor that their article has been broadly accepted if they are unfamiliar with what "patrolling" actually means; it may also introduce confusion/frustration if their page is later nominated for deletion or held up at AfC. Given the fairly low participation about a very common message that many newcomers receive, I believe that if anyone has any better ideas, they should consider proposing them. I, JethroBT drop me a line 03:59, 21 November 2014 (UTC)

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

Following a discussion at the idea lab, I would like to propose specifying that New Page Patrols are patrols, not reviews, in user notifications. A common question I see asked at the Teahouse, Help Desk, and IRC help channel is from users who are confused about why their article draft/user page/sandbox has been 'reviewed' and yet they can see no change. This is particularly confusing for new users who have submitted an Article for Creation - their article being reviewed seems to suggest that an accept or decline decision has been made, and they are confused when no such decision is obvious. This stems from both New Page Patrol and AfC reviews being described as 'reviews'; when a page is patrolled the user receives an email and notification informing them that their "page has been reviewed" when in fact it has been patrolled. I suggest changing the following interface messages (thanks to Jackmcbarn for finding them) to specify that the page has been "patrolled" not "reviewed":

Additionally it could be beneficial to include either a brief explanation of what NPP is or some link to WP:NPP in the notification or email. Sam Walton (talk) 22:40, 2 September 2014 (UTC)

Hear hear, this word "review/reviewed/reviewing" has too many meanings in Wikipedia, as also seen in a recent discussion on user right naming: Noyster (talk), 09:37, 3 September 2014 (UTC)
Support, this also makes it consistent with the autopatrolled right. BethNaught (talk) 10:05, 3 September 2014 (UTC)
  • I would certainly support getting the terminology right. As one user who has been extremely concerned about NPP for many years I have never referred to NPP as anything other than 'Patrolling'. As I never create pages as a new user, I was oblivious to the confusion that it causes among the newbies. Kudpung กุดผึ้ง (talk) 10:54, 4 September 2014 (UTC)
  • What do you think of "checked" rather than "patrolled"? WhatamIdoing (talk) 22:29, 4 September 2014 (UTC)
    • In harmony with the current usage and the thousands of times the term has been employed around the site and on templates, etc., I think there's nothing broken that needs fixing other than the OP's original suggestion. Besides which, 'checked' evokes a cursory glance while patrolling requires somewhat more action, and carried out by competent users. Kudpung กุดผึ้ง (talk) 05:49, 5 September 2014 (UTC)
      • "Patrolled" is wikijargon that won't mean anything to new users. It's not even grammatically sensible, since patrolling is the act of going from page to page, not the act of marking this one as being okay. "A passing user said that your page probably didn't qualify for immediate deletion" would be the most accurate, but that's very wordy. "Okayed", "accepted", or "checked" might make sense to a new person. "Checked" has the advantage of evoking the checklist, even though most NPPers don't follow it. Outside the mainspace, pages are often marked as patrolled after only a cursory glance, and not everyone believes that patrolling requires tag bombing, so that would be an accurate implication. WhatamIdoing (talk) 18:56, 8 September 2014 (UTC
WhatamIdoing, 'Patrolled' is the best term we have and as it isn't broken, why fix it? The proposal is to change any confusing terminology to 'patroll/ed' and not to find some other term. "checked" evokes "passed"/"authorised" just as much as "Okayed" or "accepted", which at NPP are most usually not the case - almost all new pages are in need of some attention of one kind or another whether they are rife for deletion of not. We must avoid any suggestions that NPP is a cursory glance - it s not, or it is cerataily not supposed to be. I realise that there are some NPP skeptics out here, but NPP is not only our only firewall against unwanted/unsuitable/inappropriate content, but it should also, if used correctly, encourage those whose articles just scrape through, to do better, while nevertheless, tag-bombing is totally counter productive. KudpungMobile (talk) 08:59, 9 September 2014 (UTC)
I disagree that it "is the best term we have", and I disagree that it "isn't broken". Patrolled is not understood by new users. It is, therefore, "broken". It is merely the most common term among people who are familiar with wikijargon, which is not the same as "best" or "not broken". WhatamIdoing (talk) 16:02, 9 September 2014 (UTC)
  • Support - Reviewed is a poor choice as it infers that there is some sort of feedback process involved. Patrolled, although not ideal is consistent with the terms, 'New page patroller' and 'Autopatrolled'.--Ykraps (talk) 12:46, 6 September 2014 (UTC)
Doesn't the notification say "your page was approved", which is an adequate description of the "this draft or main namespace article has been accepted for main namespace"? Gryllida (talk) 22:15, 11 September 2014 (UTC)
I'm confused what this has to do with the above - "your page was approved" is a fine description of a draft being accepted. The confusion comes from WP:NPP being referred to as a 'review'. Sam Walton (talk) 22:21, 11 September 2014 (UTC)
I don't use Echo, but I thought it says 'your page was approved' for NPP, as well... --Gryllida (talk) 23:09, 11 September 2014 (UTC)
Umm, no, it definitely says reviewed. I have just checked my notifications.--Ykraps (talk) 04:56, 12 September 2014 (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.

updating Instrumentalism for the 21st century

GUIDANCE REQUEST: Instrumentalism in the 21st century. I propose updating the article on “Instrumentalism” to explain how John Dewey and Karl Popper have been reinterpreted, making instrumentalism an active part of the philosophy of science project relevant to inductive reasoning, technology, and pragmatism. Please evaluate my proposal at talk: Instrumentalism, entries 20 and 21.TBR-qed (talk) 19:44, 6 October 2014 (UTC)

This discussion should take it to the article's talk page. This is not the place for your proposal. Good luck. GenQuest "Talk to Me" 21:45, 6 October 2014 (UTC)

Conflict infobox - 4 sides needed

The Syrian Civil War infobox has been the subject of a long-running content dispute (see Talk:Syrian Civil War#Infobox very misleading). Just about everyone involved agrees that the proper way to present this complex conflict would be to have four distinct combatant "sides" in the infobox, rather than trying to split hairs over whether the nationalist Kurds (who are explicitly not allied with either the government or the rebels, having clashed with both throughout the conflict, but have cooperated with both groups in some areas) should go in the government or rebel column. Clearly we are past the point where the Islamic State, which has been in the news a lot lately, can credulously be presented in the same column as the rebels they are at war with, much less the Kurds they are also at war with. Just about all of the Syrian war graphics we have been using (maps and the like) show four sides. The limitations of infobox coding do not allow us to present the conflict appropriately, and because of that, I believe the content dispute will continue and readers will continue to get a confusing and inaccurate picture of what is going on unless and until we are able to build an infobox with four sides. -Kudzu1 (talk) 17:43, 5 October 2014 (UTC)

Yeah, just to explain this more generally (since this proposed change will not only affect the article in question), there is a technical limit that only allows three columns in the war infobox, and we basically want to enable a fourth one. Could be useful in other articles about complex wars as well. FunkMonk (talk) 17:57, 5 October 2014 (UTC)
I also think that we need make four distinct combatant "sides" in the infobox. And it would be a great solution to our problem. Hanibal911 (talk) 18:01, 5 October 2014 (UTC)
Fully support. I just edited the heading by adding "- 4 sides needed" to make the request easier to find. Legacypac (talk) 18:03, 5 October 2014 (UTC)

I argee,we need a infobox for 4 sides.Alhanuty (talk) 18:04, 5 October 2014 (UTC)

I'll rework Template:Infobox military conflict to support this. When I'm done, I'll let you know so that you can fix Template:Syrian Civil War infobox to use it. Jackmcbarn (talk) 18:13, 5 October 2014 (UTC)
Thank you very much, Jackmcbarn! -Kudzu1 (talk) 18:24, 5 October 2014 (UTC)
  • I think the better solution is just to not have any "combatant" section at all. It is quite clear that situation in Syria is too complex to be adequately summarised in the infobox. Remember, the purpose of an infobox, as laid out by the guidelines on this matter, is to summarise key points, not to become an endless mire of information. The infobox is not a substitute for prose. Adding a fourth column will only create a giant mess that will be hard to read, and will infringe upon the page's layout. Given that this situation is so complex, and given that an infobox simply cannot do it justice, the best thing to do is to let the prose stand. Eliminate the combatants section. RGloucester — ☎ 18:15, 5 October 2014 (UTC)
Most people won't read the article, so the infobox gives a quick overview. In any case, we can discuss this further at a later point, right now it couldn't hurt just to make the fourth column possible. FunkMonk (talk) 18:20, 5 October 2014 (UTC)
There is nothing "quick" or "overviewish" about the present infobox, or about the idea of adding a fourth column. It flies in the face of the guidelines on infoboxes and their innate purpose. RGloucester — ☎ 19:22, 5 October 2014 (UTC)

Oh, the combatants infobox really helps get a grasp of the situation quickly.

  • A | B | C | D or
  • A | B

line here (hard to show this!)

  • C | D

in the interest of not eating up too much width. Legacypac (talk) 18:18, 5 October 2014 (UTC)

Support creating a 4th side to a conflict. Although strictly speaking, the disputed Kurdish faction is in fact formally opposed to the Assad regime faction ("Syrian Kurds may have added appeal for the back channels they provide. Despite claiming to be opposed to Mr Assad’s regime, there are reports that they may be co-ordinating with his forces in the fight against Isis."), as well as only forming official alligences with the Syrian opposition factions since the conflict began, this is a complicated situation that could change. Nulla Taciti (talk) 18:20, 5 October 2014 (UTC)
  • I would agree with this in concept, but the consequences could turn out to be a bit unpleasant (visually, I mean), especially with the amount of references we have. Right now I've temporarily dealt with the Kurds' issue (see [1]) and bordered them so that the dividers in the first 2 columns don't go up and down. I believe this solves the problem for now. Thoughts? Fitzcarmalan (talk) 18:23, 5 October 2014 (UTC)
It is an innovative solution, but can the Kurdish "Commanders and leaders" section and the Kurdish "Strength" section also be bordered in an identical manner to the Kurds in the "Belligerents" section, to avoid confusion? Nulla Taciti (talk) 18:35, 5 October 2014 (UTC)
I agree that a fourth column might be the solution. Hopefully it won't look too crammed... But that's just the nature of this conflict. Jushyosaha604 (talk) 18:44, 5 October 2014 (UTC)
I like Fitzcarmalan's layout (similar to an earlier one by Kudzu). Clearly shows Kurds have been fighting, depending on the situation and location, beside both the Assad forces and the opposition against ISIS (contrary to an earlier statement that the YPG has been fighting alongside the rebels only). But I would also support a fourth column for the Kurds (if it wouldn't be too cramped). EkoGraf (talk) 20:01, 5 October 2014 (UTC)
Guys, this section is not the place to discuss configurations that are already possible for us to make, but strictly for discussing stuff we need outside help to implement. FunkMonk (talk) 05:42, 6 October 2014 (UTC)
4 columns side by side infobox would be ridiculously cramped. If there is really desperate need for 4 side infobox then practical solution would be 2+2 columns. But current arrangement in Syrian civil war article is quite solid so I don't see need for 4th column there anyway.--Staberinde (talk) 18:14, 6 October 2014 (UTC)
Let's see how it actually looks, and not complain about how we think it might look. No one has seen a war infobox with four columns before. Also, this is a "ridiculously cramped" war, so an infobox that reflects this will be closer to the truth than whatever arbitrary compromise we come up with. FunkMonk (talk) 20:53, 6 October 2014 (UTC)

Ready to use

@Kudzu1: @FunkMonk: @Hanibal911: @Legacypac: @Alhanuty: @Nulla Taciti: @Jushyosaha604: @EkoGraf: I've just finished updating Template:Infobox military conflict to support a 4th combatant (though I haven't fixed the documentation yet, every field that previously supported a 1/2/3 now supports a 4 as well). I'm not going to try converting Template:Syrian Civil War infobox myself (because I'm sure that someone won't like the way that I do something), but any of you should now be able to do it. Let me know if there's any questions about how the new functionality works. Jackmcbarn (talk) 15:08, 7 October 2014 (UTC)

Thank you -- very good work! Just one note: is it an optical illusion, or is the third column slightly wider than the other three? -Kudzu1 (talk) 16:13, 7 October 2014 (UTC)
Thanks! FunkMonk (talk) 17:09, 7 October 2014 (UTC)
Awesome :) Legacypac (talk) 17:26, 7 October 2014 (UTC)

It looks like Outernet needs a little help

I believe it would be a noble move if the Wikipedia foundation assisted the Outernet project with server capacity or what minimal funding is required to cover (apparent) bandwidth limits on their web site during the start up phase. They share synergistic goals.

https://wiki.riteme.site/wiki/Outernet

https://www.outernet.is/ Over Quota This application is temporarily over its serving quota. Please try again later.

Perhaps someone who knows how such things are arranged would be kind enough to forward this suggestion to the correct offices.

Idyllic press (talk) 06:34, 2 October 2014 (UTC)

Hi, Idyllic press. I asked and was told that they might qualify for a grant, but it would need to be applied for. meta:Grants:Start would hopefully have the information necessary for you or, if you know somebody involved with the organization, them to proceed. --Maggie Dennis (WMF) (talk) 12:25, 7 October 2014 (UTC)
Maggie Dennis (WMF) Hi I have sent an email suggesting this with a link to here, perhaps they will apply. I am just a bystander who happened to bump into a quaota limit that should seldom be found these days in the western world so thought to see if connecting people could help. -- Idyllic press (talk) 17:34, 7 October 2014 (UTC)

Yearly donations instead of monthly donations

I would like to subscribe to Wikipedia and to make yearly donations. I noticed that at https://wikimediafoundation.org/wiki/Ways_to_Give there is the "Monthly gift" option, but no "Yearly gift". For example if I decide to donate 30 euros / year, it's more convenient to pay each year a single payment of 30 euros (for example each 1st of January), instead of paying 2.5 euros every month. It's simply annoying to make such small payments every month. Is it possible to implement yearly payments with PayPal? —  Ark25  (talk) 14:08, 2 October 2014 (UTC)

Hi, User:Ark25. :) Your best bet is probably to address that question to donate@wikimedia.org. Thanks for supporting Wikipedia! --Maggie Dennis (WMF) (talk) 12:21, 7 October 2014 (UTC)
Hi User:Ark25, just as a follow up, I can tell you we get this question occasionally on the Fundraising team. Unfortunately, at this time we don't have the technical capability to recur donations annually. We try to reach past donors once a year via email and banners as a reminder, but we are always looking into ways to offer more options, and annual recurring donations is on our list of potential future improvements. I'm sorry I can't be of more help at the moment, but truly thank you for the generous offer of support! --CCogdill (WMF) (talk) 18:12, 7 October 2014 (UTC)
Thanks for your answer. I hope you will fix this one day. Until then, I will make payments once every 5 years with 5 x 30 euros, so I can be sure that every year is paid (Somehow I forget to make donations every year, looks like it's too frequent for my speed). Thanks again. —  Ark25  (talk) 16:48, 8 October 2014 (UTC)

"Prompt me when entering a blank edit summary" - option to suppress when "minor edit" is selected

Hi, I appreciate the "Prompt me when entering a blank edit summary" - it reminds me when I occasionally forget to enter one or rarely accidentally save the edit before finishing. But I find it a bit annoyoing when I'm just making a minor change and I have checked the "This is a minor edit" checkbox. Can we have an option (preferably just below the "Prompt me..." option) such as "Don't prompt me when I'm making a minor edit" - preferably turned on by default? Keep up the great work everyone! Facts707 (talk) 13:33, 24 September 2014 (UTC)

I have concerns that that might encourage editors to inappropriately mark edits as minor rather than dealing with the "inconvenience" of entering an edit summary. In any case, I may be amenable to the inclusion of the option, but I oppose having it turned on by default, especially when turning it on would require minimal effort for editors who wish to utilize it. DonIago (talk) 13:40, 24 September 2014 (UTC)
With the existing system, you just have to add a space to the edit summary and it will not prompt you; is this not sufficient? —Quondum 16:34, 24 September 2014 (UTC)
Comment Perhaps, alternatively, checking the 'minor edit' box can be made to force a space, or even the single letter, "m", into the edit box. No need to opt in or out, just an automatic entry. As far as @Doniago:'s concern, some editors do that now. GenQuest "Talk to Me" 19:12, 24 September 2014 (UTC)
Shouldn't all edits have a summary, even if they're minor? Personally, when RC patrolling if I see a minor edit without a summary, I give the edit extra scrutiny for potential vandalism. Ivanvector (talk) 19:48, 24 September 2014 (UTC)
It's hard enough to get people to leave summaries as it is. Please don't encourage them not to, particularly not on minor edits which can be anything. Britmax (talk) 19:50, 24 September 2014 (UTC)
Same here. I feel we should have more edit summaries, not less. DonIago (talk) 20:17, 24 September 2014 (UTC)
Nonsense. Those who leave edit summaries will continue to do so, those who usually don't leave edit summaries will continue to not leave edit summaries. The proposal addresses an issue which is a time saver for wikignomes and those editors who are constantly making maintenance and other minor edits to better the encyclopedia, and shouldn't be dismissed off-handedly. GenQuest "Talk to Me" 02:27, 29 September 2014 (UTC)
What sort of "maintenance edit" warrants a blank edit summary? I like knowing what changed without having to scour diffs. Ivanvector (talk) 03:03, 29 September 2014 (UTC)
I make lots of minor edits and I try to always use a summary. I don't see any valid reason to leave a summary off unless you're relying on WP:AES. --NYKevin 14:15, 2 October 2014 (UTC)

FWIW, I understand what the OP is talking about. Casually reading thru Wikipedia articles, I'll often find typos, misspellings, minor grammatical errors, & so forth, which take maybe 15 seconds to fix -- depending on server latency at that moment. In many of those cases, I find that the edit summary is far longer than the edit, & will often require me to write multiple sentences to intelligently explain my change. (An example might be, "A previous editor confused double quotation marks with a pair of single ones; this results with the last half of the paragraph being italicized. So I changed the extraneous double quotation marks to a pair of single ones to fix this mistake." Some incidents are even more involved, & no matter how terse I try to be, a lengthy explanation may result.) As a result, anyone perusing my contribution history will find that many of the edits I marked as minor have cryptic edit summaries. I dare say, the simpler the edit, more cryptic the summary will be; sometimes I'll make my edit summary even more cryptic out of spite at the requirement to document the change.

Now I'm not arguing that edit summaries should never be left, but any veteran editor will find her/himself frustrated when the summary may require as many as 100 words to explain adding/removing a single character -- so we should all be a little sympathetic to the OP's proposal. Even if, in the long run, it isn't a good idea. (And if I really wanted to be a jerk, I could leave useless edit summaries with little effort. Hmm. Maybe I'll demonstrate.) -- llywrch (talk) 20:56, 8 October 2014 (UTC)

What he said. ;-) GenQuest "Talk to Me" 11:43, 9 October 2014 (UTC)
"Formatting", "fix typos", "fmt", "WP:TONE", "misc. minor corrections", "clean-up"... DonIago (talk) 14:04, 9 October 2014 (UTC)

Move pronunciations, other names and other language names from lead to a note or sidebox

Take this example. This is the lead of Hebron.

Hebron (Arabic: الخليلⓘ al-Khalīl; Hebrew: חֶבְרוֹן‎ⓘ, Standard Hebrew: [Ḥevron] Error: {{Transliteration}}: unrecognized transliteration standard: (help), Tiberian: Ḥeḇrôn ISO 259-3: Ḥebron; Ottoman Turkish Halilürrahman, Ancient Greek Hebrṓn, Χεβρών) is a Palestinian[1][2][3][4][5] city located in the southern West Bank, 30 km (19 mi) south of Jerusalem.

What an average reader will wish to see is:

Hebron is a Palestinian[1][2][3][4][5] city located in the southern West Bank, 30 km (19 mi) south of Jerusalem.

The problem here is, the pronunciations and other language names simply clutters the beginning of lead terribly decreasing its readability. This is worse in some other articles where there are other names for the subject of the article, meanings of each one explained inline.

Why shouldn't we make it a policy that such items should be placed in a note or a side-box? --PrinceMathew (talk) 07:59, 2 October 2014 (UTC)

I quite agree overloading lead sentence with naming info is a bad habit on Wikipedia, and the Hebron example you cite is a particularly horrible example that needs to be changed. I'm not too certain though whether a sidebox is the best place for it (although I guess it could be optionally integrated in the infobox templates, as virtually all geographical articles do have infoboxes these days.) My own favorite solution, as long as it's just a simple list of two or three names in local languages, is an extra sentence at the end of the first lead paragraph ("The city is called "X" in A, "Y" in B and "Z" in C.) Anything more complex than thathe (such as multiple transcriptions or pronunciation guides for the same name, as here with Hebrew) should go into a separate "naming" section below. One of the things that makes the present state worse is the pedantic obsession with cramming all sorts of names in for purely political/historical reasons, such as giving a symbolic nod of recognition to all language communities that live in a place by listing all their name variants, or to all historical states that once governed it, as here by listing the – otherwise completely irrelevant – Ottoman name. As a rule, the slot at the beginning of the lead sentence should be reserved exclusively to names that are or have been used in English (including possibly the one current official name in the official local language, as that might also sometimes be used in English-language maps, atlases and so on.) Fut.Perf. ☼ 08:16, 2 October 2014 (UTC)
I've taken the freedom to remove the live "ref" tags from the examples above and replace them with fake ones, just so we don't have to carry a spurious references list around here on the talkpage. Fut.Perf. ☼ 08:19, 2 October 2014 (UTC)
Assuming that every place has "one current official name" or one "official local language" seems unwarranted. For example, it appears that part of Hebron is controlled by the State of Palestine (official language Arabic) while another part is controlled by Israel (which has two official languages, Hebrew and Arabic). For another example, Switzerland has four official languages: German, French, Italian, and Romansh. Anomie⚔ 11:28, 2 October 2014 (UTC)
The important point is that we should de-emphasize this whole idea of using the inclusion or non-inclusion of names as a symbolic sign of our recognition of the role of this or that state/ethnicity/historical period etc. We are not writing our articles in order to please this or that group of locals. We are writing them in order to serve the English-speaking reader, and the only reason names need to be included in that spot is because English-speaking readers might have been led to the article after seeing the place referred to by that name in an English-speaking environment. My reference to local official names was due to the fact that some otherwise English-speaking publications, such as atlases, may have a policy of using local names (such as München) even where English prose otherwise strongly prefers an anglicized name (e.g. Munich). That's the only reason "München" would have to be there. So, we should ask ourselves: would an English atlas that uses "München" and "Athīna" also include "Ḥevron" or "al-Khalīl", or maybe both? If yes, they go in; if not, they don't. For historical names, the question is similar: would history books in (present-day) English refer to the place by name XYZ (without immediately glossing it with the modern name)? If yes, the historical name goes in; if not, it doesn't. Everything else should be treated somewhere a bit further down, where it is less obtrusive (perhaps still in the intro, but not in the lead sentence). Fut.Perf. ☼ 11:50, 2 October 2014 (UTC)
We definitely need some way to make the ledes more visually appealing and readable. A side bar might be the best solution. But what other options are there? Mosue-over pop-ups, footnotes, a double lede? Kdammers (talk) 09:15, 2 October 2014 (UTC)
I support this - overloading the lede with alternate names and pronunciations hinders readability, and I agree that we're building an encyclopedia for English readers, thus only the most common English name(s) should be in the lede, just like how we choose article titles. Frankly, this is one of the increasingly few proposals that comes along that actually quite significantly increases the readability of pages, and that should be what we're going for. I think adding an "alternate names" or "local names" or some such section to the infobox would be an elegant solution. In fact, if you look at Hebron, there is already an "other transcriptions" section right at the top of the infobox. Why not there? Ivanvector (talk) 14:46, 2 October 2014 (UTC)
Strong support. Lead sentence cruft is totally out of control. Let's go back to having readable articles. Kaldari (talk) 19:59, 5 October 2014 (UTC)
Support this definitely impacts the reader and moving to a sidebar would be very useful. I know WikiProject China already uses such a system to manage transliterations and simplified/traditional, which is quite similar. --Tom (LT) (talk) 23:01, 5 October 2014 (UTC)
Strong support. As I've been saying for years, our lead sentence model is broken. The lead sentence is not a database table where every conceivable record related to the subject's name is stored for machines to read. The lead sentence is where we tell human readers what a subject is in a neutral, simple, plain-English, due-weight, and accessible format. The additional information – pronunciation, transliteration, obscure historical and geographical alternatives – are welcome but they absolutely belong outside the first sentence. A footnote, the article body, a sidebox, whatever. The lead sentence is not a database.
I know someone will come along to say "Hey, if a particular lead sentence gets too packed, then we can start removing those items on a case-by-case basis without creating a new rule." I just don't agree with this at all. Our standard should be only one name goes in the lead, with no pronunciation or transliteration, unless someone makes a strong unique case. Not the other way around. —Designate (talk) 23:39, 5 October 2014 (UTC)
Separate name section This is a classic case where the article should have a separate name section. This way, we can explain why there are so many names and where they all come from and why they aren't all the same. Oiyarbepsy (talk) 02:26, 6 October 2014 (UTC)

As much as I'm in favor of this idea, may I remind everyone of the naming disputes we had over German & Polish names a few years ago? I suspect in many cases this verbiage is the outcome of resolving numerous ethnic & cultural disputes. Unless you are willing to engage in dealing with the recrudescence of these disputes (few of which I suspect will be resolved rationally), I'd suggest that either (1) agree on a reliable source to use for place names to use to avoid these disputes; or (2) do a quick survey of places whose names are in serious dispute to see what the scale of these disputes may be. Better the devil we know (bad-looking lead paragraphs) than the one we don't (endless cultural & ethnic conflicts over what place name to prefer for places few of us have heard.) -- llywrch (talk) 22:21, 8 October 2014 (UTC)

Even if you stuff the lead with alternate names, article can reside only in one namespace to which all the alternate names should be redirected. So if we give in to the interest groups like those mentioned above, there may occur further conflict saying X must be redirected to Y rather than vice versa, etc. The rule of thumb here is this is English language Wikipedia and here Deutschland, Polska & Österreich are always redirected to Germany, Poland & Austria, not vice versa. I hope you get my point. --PrinceMathew (talk) 11:20, 10 October 2014 (UTC)
I refer you to the well-known dispute over the name of the Baltic seaport, Gdansk/Danzig. Since then, at least one native Polish speaker has insisted that a certain river be known by its Polish name Odra instead of its more familiar English form Oder, apparently because the latter is identical with the German name. And then there are instances where a place with a name familiar to most English speakers has been renamed (e.g. Kolkata & Calcutta). The point is that a lot of these disputes don't pop up because someone has an agenda, but because most Wikipedians aren't aware a conflict actually exists, & the resulting misunderstanding often goes thru at least one cycle of name calling (one side are labelled "trolls" & cranks", the other "bigots" & "Wiki-Nazis") before cooler & more empathetic minds prevail with some form of a compromise.

If I'm being overcautious here, well I'll be happy to be proved wrong; I agree with the OP that the lead is getting mangled by inserting these alternative names in the first sentence. And I suspect that if handled with some sensitivity & wisdom, making this change could be a non-event. But, as I said before, I'm writing from what I've witnessed over these last 12 years. Making this change without first doing this kind of prep work will inevitably lead to bruised egos, nasty edit wars, work for ArbCom, & valued editors quitting. -- llywrch (talk) 15:57, 10 October 2014 (UTC)

This proposal doesn't alter the fact that we already have to pick one title for every placename article, providing redirects from alternative names. It refers only to the location on the page where alternative names are shown (together with any non-Latin scripts and pronunciation links). And I'd agree that the very first sentence is not the ideal location, even if it's traditionally been done this way in printed works of reference. Could we have a few proposed layouts to comment on?: Noyster (talk), 16:51, 10 October 2014 (UTC)
I was directed to this discussion from a post made at Wikipedia talk:WikiProject Infoboxes. It was about whether tennis player Peangtarn Plipuech should have her Thai spelling in the lead or above the infobox, as in the example. The page had it in both places and it seemed to me like that was overkill but I wasn't sure what guidelines or consensus was leaning towards here at wikipedia. In a new edit, an editor has left it in the lead but removed it from above the infobox and placed it inside the infobox with a "|native_name =" header. Now this particular instance only has one addition to the lead as opposed to the ridiculous Hebron example above. It seems like if there is one extra spelling and perhaps one pronunciation, it's no big deal. After that it gets very hard to read and should have a separate "name" section. But since you all seem to have a better grasp on this then me I wanted to ask what the general consensus is about having the extra spelling in both the lead and the infobox? I do like it better inside the infobox rather than two spellings above the box, but should it be in both lead and box, or is one place good enough? Fyunck(click) (talk) 18:46, 10 October 2014 (UTC)

Llywrch, your concern is quite valid, of course, however I think this can be dealt with rationally. We ultimately have to decide what to title an article, and we have geographic place name conventions which are intended to guide disputes. I suppose this proposal would be altering that slightly, and it might be worthwhile to link to this discussion from that talk page. Essentially, the vast majority of places have a single name widely given in English sources, or one which is far more commonly known to English readers. Such articles would read like:

London is the capital city of England and the United Kingdom.[4]

Where there are places with different names substantially equally likely to be recognized by English readers, (and which have redirects from other common names):

Gdańsk, also known as Danzig, is a Polish city on the Baltic coast, the capital of the Pomeranian Voivodeship, Poland's principal seaport and the center of the country's fourth-largest metropolitan area.[1] The city is known by several alternative names.

For places with a once-common name which is still used, but another name has become more commonly used in English:

Kolkata, known historically in English as Calcutta, is the capital of the Indian state of West Bengal.

As for the Oder river, with respect to the native Polish reader, the argument to use the Polish name as the title is a poor one. This is not the Polish Wikipedia, and it doesn't matter if the common English name is similar to another language or different from the native language. We use the English name. The other names (of which Odra is only one of several given in the article) would be indicated in the sidebar or whatever alternate location is decided.

The Oder is a river in Central Europe. It rises in the Czech Republic and flows (generally north- and northwest-ward) through western Poland, later forming 187 kilometres (116 mi) of the border between Poland and Germany, part of the Oder–Neisse line.

Just one more example, from my home and native land:

The Saint Lawrence River is a large river flowing approximately from southwest to northeast in the middle latitudes of North America, connecting the Great Lakes with the Atlantic Ocean.

The current convention calls for including local names in the lede, and I can see why but I think that advice is misguided. It interrupts the flow of what is supposed to be a summary. Much like in the Hebron example, the average English reader looking for a summary of the article is not likely interested in seeing the French, Tuscarora and Mohawk names, along with the meaning of the Mohawk name, stuck awkwardly right in the middle of the first sentence. This detail is important, but should be moved elsewhere. We're building an encyclopedia for English readers, so we should include this information elsewhere. Ivanvector (talk) 18:34, 10 October 2014 (UTC)

I support the comments made by Ivanvector. The guidance at WP:LEADCLUTTER is weak, and I would like to see the examples at LEADCLUTTER replaced with Ivanvector's suggestions. Barryjjoyce (talk) 07:22, 12 October 2014 (UTC)
That's a good point too. Per WP:CITELEAD, the lede should be a summary of what appears in the body, so in many cases there should be no need to provide inline citations in the lede. However there are some cases where it may be required, such as WP:MINREF. Ivanvector (talk) 13:31, 12 October 2014 (UTC)
  • The Hebron example is just poorly done—it's unhelpful information that should be put somewhere in the body and not into a box. Curly Turkey ⚞¡gobble!⚟ 04:48, 12 October 2014 (UTC)
  • Oppose sidebox - please no, have mercy (see disputes about infoboxes). Support decluttering lead sentences, but the best solution should be found case by case. Add a few recommendations from experienced editors to the guidelines, but no fix "rule" for it. GermanJoe (talk) 14:35, 12 October 2014 (UTC)
Seems reasonable. The "alternate transcriptions" infobox seems to work for Hebron, but Gdansk uses an "alternate names" section instead. I think this proposal is limited to just "don't pepper the lede with them". Ivanvector (talk) 15:05, 12 October 2014 (UTC)

AfC resubmit

One thing I've noticed on AfC is that there are a lot of resubmits without any changes, or ones that are resubmitted in minutes. We have over 2,500 AfC's that need to be reviewed at the moment, and that takes a long time. Therefore, I'm proposing that declined AfC's cannot be resubmitted without any changes, and/or that AfCs must wait 1 week to be resubmitted. The week will give the authors time to revise the article thoroughly. Origamiteⓣⓒ 17:50, 28 September 2014 (UTC)

I'd be more willing to support something like this if you were able to guarantee that all declined AFCs were validly declined, and not, e.g., because the AFC reviewer disapproved of the formatting of the sources or some other equally trivial point. WhatamIdoing (talk) 23:29, 28 September 2014 (UTC)
Note that new editors (who AfC is aimed at) aren't likely to know whether a decline is valid, so that's not really something this should focus on IMO. Anyway, I support this, and it's doable from a technical perspective. Jackmcbarn (talk) 14:23, 2 October 2014 (UTC)
& That is a wonderful proposal. Are you suggesting to make it a bit-task to monitor these submissions? --Tito☸Dutta 21:22, 12 October 2014 (UTC)

Admin training: a good idea?

I propose that after someone becomes an admin, they should be required to spend a certain amount of time (I'm not sure how long, but it would be defined in # of admin actions) in a training program. This program, under my proposal, would involve them (in addition to making normal edits) making the same decisions (such as blocking and protecting) as real admins do, but it would have no effect. The purpose would be for existing admins to determine if they know how to conduct themselves in tough situations admins frequently find themselves in. I think this is a good idea because it will help ensure that new admins are at least a little experienced before they assume their new responsibilities. Thoughts would be appreciated. Jinkinson talk to me 01:35, 8 October 2014 (UTC)

BTW, I saw this at WP:Perennial proposals but most of the section about this is actually about allowing some people to have some, but not all, admin rights, which is a totally different issue from what I am proposing. Jinkinson talk to me 01:37, 8 October 2014 (UTC)
See Category:Administrator instructions.—Wavelength (talk) 03:25, 8 October 2014 (UTC)
The thing is...the vast majority of situations admins find themselves in are not "tough situations". The vast majority of uses of the admin tools are entirely uncontroversial and not at all difficult. Look at the raw block log. Look at the raw deletion log. What do you find? Clear and conspicuous vandals and vandalism. Gross edit warring. Obvious housekeeping. Out of several thousands of admin actions in any given day, you can usually count on one hand the number which are brought up at AN/I; only a tiny fraction of that minuscule number are overturned.
Any given admin will be 'first on the scene' of a controversial situation only seldom. No admins is ever compelled to take any action in any case—we can always leave the situation for someone who feels better able to handle it. Worse, the proposal implies – incorrectly – that any given "tough situation" will actually have a 'correct' response—that controversial admin actions are the result of a lack of admin education, rather than genuine disagreements about how to interpret or apply Wikipedia policy.
In any event, before this goes farther Jinkinson (or anyone) should make some effort to actually substantiate the implicit claim that (the very small number of) new admins actually represent a problem that would justify implementing such a clunky and bureaucratic process. TenOfAllTrades(talk) 04:02, 8 October 2014 (UTC)
Would they learn how to block badly behaved Admins? Most don't seem to be able to do it. HiLo48 (talk) 05:38, 8 October 2014 (UTC)
So like.... WP:ADCO. Legoktm (talk) 07:56, 14 October 2014 (UTC)

A Simple Partnership with the Embryo project Encyclopedia

I am the editor in chief of the Embryo Project Encyclopedia, an online open access publication aimed for inclusive audiences. We propose to incorporate our content with Wikipedia pages.

Allow me first to describe the encyclopedia, then why we are posting here, and finally our proposal to partner with Wikipedia.

The Embryo Project Encyclopedia publishes articles about embryology, developmental biology, and reproductive medicine. The intended audience for the articles includes people with between roughly 9 and 16 years of education. The purpose of the encyclopedia is to increase scientific literacy among its readers about the fields of science listed above. To achieve that aim, articles in the encyclopedia use historical methods to situate scientific results in social contexts.

The encyclopedia is funded by the US National Science Foundation, and it is the product of a collaboration between the Center for Biology and Society at Arizona State University and the Marine Biological Laboratory. All articles receive rigorous peer and editorial review to be factual, non evaluative, and to connect readers to online resources for verification of contents. The publication has an ISSN of 1940-5030, all contents are Creative Commons licensed (CC BY-NC-SA 3.0), and the articles are indexed in scholarly databases like Google Scholar.

We'd like to partner our content with Wikipedia. Through various channels, we learned that that this forum provides the most appropriate venue to propose a plan to share our content on Wikipedia, but if we should instead use another means, please let us know.

The following plan describes an initial proposal.

Background We have just under 600 articles in our encyclopedia, but we publish three new articles per week.

Goal We'd like to incorporate into our editing process some steps to link our articles on relevant Wikipedia pages under 'External links' headers. For instance, as we just published an article on Francois Jacob, we'd like to include a link to it under 'External links' on the Francois Jacob Wikipedia page.

Issue In trials runs of that practice, Wikimedians have understandably deleted many of our links. They claim that such links are spam, self-promotional, and thus violate Wikipedia's principles of editing and posting. We appreciate the need for the antispamming principles, and we see how Wikimedians might construe our practices as potentially spam. We think, however, that the spirit of the antispamming principles shouldn't exclude us from linking to articles in the Embryo Project Encyclopedia. We aren't selling anything, we have no grant deliverables related to Wikipedia, nor do we bias our articles except to ensure that they they are accurate about their topics, as free from evaluation as possible, and verifiable.

Proposal

1) We'd like to designate a single Wikipedia account by which we'd post links on Wikipedia articles to articles in our encyclopedia. The one I'm using now works for that function.

2) We'd like that account to have limited immunity to the antispamming principle, in that it can be used to link to articles in the Embryo Project Encyclopedia, but no other website. Furthermore, the account can be used to link to Embryo Project Encyclopedia article only on relevant Wikipedia page. That way me might link to our Jacob article on Wikipedia's Jacob page and on it Pasteur Institute age, but not on the gauge physics page, for example.

3) We'd like other Wikimedians to be able to somehow see that limited immunity status of our account when they check our page edits.

4) We DON'T propose that such a limited-immunity account be indefeasible, and Wikimedians may still delete our links if they judge them inappropriate. We only seek to avoid deletions based on blanket application of the antispamming principle.

5) We propose a standard link syntax of:

Example:

Final Remarks Please treat our proposal as an initial step. No one on our editorial team has much experience with the policies and practices for Wikipedia, and we're not sure if our proposal maps on to Wikipedia's capabilities and policies. In one sense, we're not quite sure what to ask for, but given our explicit goal and the issue that prevents us from reaching it, we anticipate that you have ideas about how to move forward. — Preceding unsigned comment added by Embryoproject (talk • contribs) 20:38, 10 October 2014‎ (UTC)

I suggest you contact relevant wikiprojects (probably WT:BIOG) and ask someone there to evaluate the proposal. The first step would be to see if people who edit in the area believe there would be some benefit. Johnuniq (talk) 23:12, 10 October 2014 (UTC)

•Will do. We appreciate your advice. Embryoproject (talk) 17:29, 11 October 2014 (UTC)

I don't this this is impossible, but:
Your account appears to break WP rules as a role account - see WP:ROLE. It is essential that whatever account you use has a user page that fully explains who you are and what you are doing. Yours is not yet set up.
You should look at User:WilliamDigiCol/Working page 2014 for a good way to manage this - "review" of proposed links by an established Wikipedian with no COI (myself in that case). Mind you, though I've looked at some of your articles and think they are worth linking to, they are not in the same class as PDF books from the Metropolitan Museum. The Khan Academy have also very many external links, but placed by Wikipedians with no COI issues. Your articles might well meet WP:RS, but not I think WP:MEDRS for medical articles. Johnbod (talk) 20:27, 11 October 2014 (UTC)
  • Oppose "We'd like that account to have limited immunity to the antispamming principle", in other words, you want an official license to spam. Absolutely not. Andrew Lenahan - Starblind 13:03, 12 October 2014 (UTC)
  • Out of the five proposals only (#5) looks sensible. We could probably have a template for this. However since the license is compatible, material from the Embryo Encyclopedia could be used here. The target audience may differ however, so that editing may be required. Also User:Embryoproject please change your name to represent a person eg User:Francois Jacob at Embryoproject. Graeme Bartlett (talk) 22:33, 12 October 2014 (UTC)
The licence isn't actually compatible if it is CC-BY-NC-SA , as Wikipedia uses just CC-BY-SA. ie, any reuse by us would violate the -NC-SA (non-commercial share-alike) provisions, as we would be publishing under a different licence that allows commercial reuse. - Evad37 [talk] 11:55, 13 October 2014 (UTC)
You are right, I have struck out that part of my comment! Graeme Bartlett (talk) 21:55, 13 October 2014 (UTC)
  • Wikipedia allows people who want to place an external link, but have a conflict of interest, to place said link on the talk page of an article (WP:ADV). That way a second, neutral editor can check the usefulness of the link and place it on the article for you. No special permission is needed to do this, and you could start anytime you want. Maybe acompany the sugested external link with a text explaining the link. You could make a standard text for this. Sincerely, Taketa (talk) 12:11, 13 October 2014 (UTC)
  • Your third item is problematic: We'd like other Wikimedians to be able to somehow see that limited immunity status of our account when they check our page edits. Editors that see a dubious link will often remove it without checking the history to see who placed it, especially if there have been many intervening edits or the editor is purging an accumulation of dubious links from one article. A technical solution might be to set up a template similar to {{IMDb title}} (as used in Embryo (film), for example). Editors might be more likely to leave such links alone, understanding that the existence of such a template implies community approval of such links. Of course, you'd still have to gain that prior approval. NebY (talk) 12:30, 13 October 2014 (UTC)
  • Thanks for the input, everyone. It greatly clarified things for me. We'll pursue at least the following tasks:
o) I already requested a username change for my account.
i) We'll use the talk function on specific Wikipedia pages to ask editors to review our articles and link to them.
ii) We'll develop a user page that is similar to User:WilliamDigiCol/Working page 2014 as a means to systematically ask established wikipedians without COIs to approve external links to our pages.
iii) We'll look to establish a template for external links along the form of IMDB.
Given all of that, and I'm sorry to ask a simple question, but how do I find established Wikimedians in broad subject fields? Once found, do I propose to them a template for external links, or should I pursue other means?Embryoproject (talk) 22:39, 13 October 2014 (UTC)
Welcome, Embryoproject. You can find some interested people at WP:WikiProject Anatomy, WP:WikiProject Medicine, and WP:WikiProject Physiology. Leave a note on the talk pages for these groups, and then check back later see if anyone has replied. WhatamIdoing (talk) 17:09, 14 October 2014 (UTC)
Tracked in Phabricator
Task T2424
  1. Add a toggling "unwatch"/"watch" link to the "diff | hist" links at the start of each entry (and use a dot/interpunct as the separator between them rather than a pipe?);
  2. Means to view/reorder the list in reverse, i.e. according to how long pages on the list have remained unchanged.

I don't think these are persistent / perennial or already possible, but apologies if either or both are either or both (and please indicate how/where I should look). Sardanaphalus (talk) 11:54, 8 October 2014 (UTC)

  1. Have a look at User:Js/watchlist.
  2. That's not trivial, since the watchlist is getting its data from the recentchanges table, which only covers the last 30 days. So for showing anything older than that you would need not just a change in sort order, but a different way to extract these data from the database. It's probably possible, but would be less efficient. — HHHIPPO 21:41, 8 October 2014 (UTC)
  • Thanks for your responses and sorry for the time before this one. I've just installed User:Js/watchlist – which looks interesting – and, yes, I wondered if the "reverse/inverse watchlist" might be relatively demanding. On the other hand, if the software has to work through a watchlist to see which items have been changed in the past N hours/days, wouldn't it be looking up when each item had last been changed and so would only be a step or two away from producing a list which it could then present in reverse..?
Regards, Sardanaphalus (talk) 23:02, 15 October 2014 (UTC)

TWL volunteers needed

The Wikipedia Library is seeking volunteer Account Coordinators to help manage new and ongoing partnerships. We are interested in having both active local volunteers and those with cross-wiki experience (particularly in non-English Wikipedias). It requires a commitment of a couple of hours per week, on average. To apply, visit Wikipedia:TWL/Coordinators/Signup. Nikkimaria (talk) 16:53, 16 October 2014 (UTC)

New bot suggestion

I am not sure that this is the correct forum for such a suggestion. But I would like to suggest that a bot who combines duplicate references are created, such a bot would come in handy for editors who creates new articles or find it hard to combine references overall. One such bot is not operative at the present.--BabbaQ (talk) 15:20, 19 October 2014 (UTC)

@BabbaQ: The venue you're looking for is WP:BOTREQ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 19 October 2014 (UTC)
Yes, sorry I found it right after posting here. Made a request there now. --BabbaQ (talk) 15:30, 19 October 2014 (UTC)

Request for community input on IEG proposal: editor interaction data sets and visualizations

As you may have heard, Editor Interaction Data Extraction and Visualization is an individual engagement grant proposal. I am working on this proposal with volunteer assistance and advice from Aaron Halfaker (WMF), Haitham Shammaa (WMF), and Fabian Flöck (Karlsruhe Institute of Technology).

We would greatly appreciate your comments on whether you support or oppose the general concept of this project, and any suggestions about how to refine the proposal.

Additionally, we would like to hear from you about which sets of editor interaction data, and what visualizations of editor interaction data, would be most relevant to your interests. We intend to prioritize our outputs with your comments in mind.

Please comment on the proposal talk page. Questions and feedback, both positive and critical, are helpful to us as the proposers, and also help the Individual Engagement Grants Committee [1] to assess the proposal.

Regards, --Pine✉ 18:29, 19 October 2014 (UTC)

[1] I am a member of the Individual Engagement Grants Committee. I am recusing from reviewing proposals in this funding round.

Blank or Delete the User Talk Pages of: Users Who are Banned Indefinitely, Users who are Revoked Talk Page Access Indefinitely, Accounts Associated with those who frequently attack Wikipedia

I was thinking if somebody designed a bot to blank un-used/unusable User Talk Pages (such as some of the ones referenced in the headline) it could save Wikipedia's servers some space in the long run (the content of the pages might add up, trolls might realize they could waste Wiki resources by creating a very large or resource intensive user talk page and then purposefully get banned to decrease the likelihood of such content being deleted, etc). Thoughts? — Preceding unsigned comment added by 67.164.188.243 (talk) 03:02, 16 October 2014

Actually, that would slightly increases storage usage. Blanked and deleted pages are still stored in history (even if that history isn't visible to normal users). The proposed edit would just be adding to the page history. Alsee (talk) 10:41, 16 October 2014 (UTC)
A blanking might remove other things like link table and search index entries. I don't know the net effect but see Wikipedia:Don't worry about performance. It's best to keep the talk page content if some of their actions are examined later. PrimeHunter (talk) 11:07, 16 October 2014 (UTC)
Also, indefinite blocks are not necessarily perpetual; they just don't expire automatically. It's not unusual for an editor to appeal an indefinite block and return to making valuable contributions. They should be able to do so with their talk pages intact. Furthermore, some editors return by socking; old talk pages help us deal with that. NebY (talk) 11:12, 16 October 2014 (UTC)
@67, you may discusss this if you wish, but you are not permitted to unilaterally implement your proposal. I just reverted a change you made to a blocked (not banned) user.--Bbb23 (talk) 14:00, 16 October 2014 (UTC)
We used to do this, but stopped as it was kind of pointless. Mr.Z-man 15:08, 16 October 2014 (UTC)
Bad idea. It makes it more difficult to handle (and report handling) long term abuse by not-logged-in editors and by sockpupperts, if we cannot point to the user who was blocked and the reasons he/she/it was blocked. — Arthur Rubin (talk) 16:27, 16 October 2014 (UTC)
I support doing nothing at all. Just let them exist, and do nothing about them. --Jayron32 23:18, 16 October 2014 (UTC)
This looks like an example of the classic "solution in search of a problem", thus it's pointless. Indefinite ≠ Permanent. Roger (Dodger67) (talk) 10:51, 18 October 2014 (UTC)

You're probably thinking of something like WP:OLDIP. Deleting these user pages has been explicitly rejected at criteria for speedy deletion - see Wikipedia talk:Criteria for speedy deletion/Archive 33#U4. These are absolutely necessary for various reasons, most importantly spam tracking - A spam patroller, seeing a spam link added, will check if users have added that spam link before, and if another account has been warned for the exact same spam, they can dispense with warnings and block immediately. This is not possible is the pages are deleted. If you want to blank an IP page for the benefit if the IP address's future owners, feel free to do so, but never delete them. Oiyarbepsy (talk) 00:54, 23 October 2014 (UTC)

Repeal Wikipedia:Spam

At this instant, Wikipedia:Spam is severely undermined by the AfD-process. No matter how spammy an article is, they are hardly removed for that reason. A common reasoning with that is spam and advertising can be solved by normal editing, but nobody does the actual editing. Effect is that Wikipedia is slowly undermined by spammers and talking-but-not-acting-good-willing editors. latest example in my experience is Wikipedia:Articles for deletion/Mydala.

This makes WP:SPAM a hollow phrase and repealing it should be best. The Banner talk 05:17, 18 October 2014 (UTC)

I hope I have addressed most of your concerns about the article with my recent copy edit of the piece. No need to throw the baby out with the bathwater. Regards, GenQuest "Talk to Me" 08:38, 18 October 2014 (UTC)
Thanks for the edit but it happens so often. The Banner talk 09:55, 18 October 2014 (UTC)
Absolutely oppose This proposal is like suggesting that because all burglars are not arrested red-handed at the scenes of their crimes, burglary should no longer be a crime. WP:SOFIXIT is the usual cure for failure to act on the result of discussion. Roger (Dodger67) (talk) 11:12, 18 October 2014 (UTC)
Strongest oppose, obviously. AfD is not cleanup. Respectfully, Banner made exactly two edits to Mydala: flagging it for speedy deletion (rejected with the note "not even close"), and flagging it for AfD, which was snow-closed as an obvious keep when not a single editor !voted delete. We have a speedy criteria for articles that are obvious spam, and as for the repeated failures of your nominations at AfD, maybe you should take it as an indicator of community consensus that your spamming of the process with apparent pattern of frivolous nominations is itself undermining AfD. Ivanvector (talk) 14:30, 18 October 2014 (UTC)
You are exactly using all the bogus arguments used in AfD's nominated as advertising in order to keep the spammy article. The Banner talk 15:46, 18 October 2014 (UTC)
But when I nominate an article for deletion as advertisement, I don't ask for clean up. I do ask for deletion. But nearly all the time I get replies as "AfD is not for clean up", something I am not asking for. The Banner talk 20:01, 18 October 2014 (UTC)
Right. "AFD is not cleanup" means "If the article could be cleaned up don't nominate it for deletion." AFD is used primarily for articles whose subjects don't deserve a Wikipedia article. If the subject deserves an article, but the text of the article is substandard (i.e. it is "spammy") then AFD is inappropriate. --Jayron32 01:11, 19 October 2014 (UTC)
The main problem is that after closure of such a AfD in most cases absolutely nothing happens and the dodgy and/or spammy article stays in place. With all the advertising problems, conflicting with WP:SPAM, still there. In effect, "AfD is not for clean up" acts as protecting promotion and advertising. By now, the only way to enforce WP:SPAM is by means of AfD or CSD and get the article removed, as the editing part to enforce WP:SPAM is hardly done. A policy without means to enforce it, is useless. The Banner talk 15:12, 19 October 2014 (UTC)
in most cases absolutely nothing happens WP:SOFIXIT applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 19 October 2014 (UTC)
Ever realised that AfD is also a way to fix spammy articles, but by deleting them? The Banner talk 03:04, 23 October 2014 (UTC)
If "nearly all the time" people tell you you're getting it wrong, try not doing the same thing again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 19 October 2014 (UTC)
Personal attacks

User:The Banner refuses to listen to numerous editors who keep telling him the same thing (a list I documented in my sandbox and he had deleted, his only successful recent AfD). Almost daily he submits new articles to AfD, each without a WP:BEFORE, each with no editorial contributions by The Banner (to solve any of the problems he observes), each since I've been watching has been overturned. "The definition of insanity is doing the same thing over and over and expecting different results." I guess it would be OK if he were to be insane in his own world, but he takes up the time and effort of a lot of other people in the course of all these frivolous AfDs. His behavior is tantamount to a serial vandal and I've monitored his activity accordingly. I've anticipated we might have to solve this with disciplinary action, but really all he needs is some instruction on how to use Google. He clearly knows how to edit. If he were to take the time he spends creating AfD entries, posting tags, citation needed remarks and arguing; and instead apply it to fixing the problems, he wouldn't be here whining to change policy and we wouldn't be here telling him he's wrong. Seriously, how do we make him listen? Trackinfo (talk) 17:15, 20 October 2014 (UTC)

And you were told to stop harassing me and stop the personal attacks. You are so preoccupied on attacking me and blemishing me, that you not even bother to get your facts right. Of my last 50 nominations, 21 are deleted, 2 are merged, 9 kept (including two nominations withdrawn) and 15 are still open. So what you are telling here pure nonsense and lies. The Banner talk 18:01, 20 October 2014 (UTC)

Requesting community input on suggestions for DYK/Stats

Hi, I posted a set of suggestions here a week ago and have only been able to get responses by pinging people. Basically it boils down to this:

  1. - I think the talk page should have an archive
  2. - I think the DYK alert templates should link to the official versions of the rules in projectspace instead of the outdated version of the rules in userspace.
  3. - I would like to make corrections to improper calculations based on the outdated rules.

I'm happy to do all of this myself if given the greenlight. Please review my suggestion and weigh in. Thanks in advance. -Thibbs (talk) 14:25, 23 October 2014 (UTC)

Bookmarks

I was looking for a place where I could list my bookmarks on Wikipedia. I couldn't find one, so I propose that we make a bookmarks bar along the top of the page. It should go with the compact personal bar, so it would make the screen less cluttered with all of the bookmarks one might have.

--maximum_capacity12

Articles or any other Wikipedia pages can be linked from your userpage. Also, they can be placed on your watchlist to flag up when any changes are made. By the way, please sign your posts to talk pages with four tildes (~~~~): Noyster (talk), 09:40, 25 October 2014 (UTC)

Tables with collapsible columns

I would like to be able to collapse (hide) certain columns of tables, sometimes. For example, when I (double-)click on the third column on the following table ("Motor vehicles"), to hide the fourth and the fifth column, because the third column is the sum of the fourth and fifth. And then, if I click it again, to show them. Sometimes tables can have too many columns and then, when you first look at the table, some columns would be better to be hidden, in order for the reader to see the essential. Then, if the reader wants, they should be able to able the not-so-essential columns.

Did anyone think about implementing such a feature?

Vehicle production of SouthVulcania (millions):

Year Bicycles Motor vehicles Trucks Cars
2010 30 100 80 20
2009 29 90 70 20
2008 28 80 65 15

—  Ark25  (talk) 22:23, 17 October 2014 (UTC)

Judging from MediaWiki:Common.js, section Collapsible tables, it should be possible with a little Javascript, but implementation will need a fair bit of testing. Adam Cuerden (talk) 10:35, 18 October 2014 (UTC)

I would find it useful. Keep in mind, per MOS, that columns should be open initially, but I could see value in giving the reader the option to close some columns. Please also note that in the case of a sortable table, one sorts simply by clicking on the column heading, so it the table is to be sortable and allow column hiding, one have to think through how to do each option separately.--S Philbrick(Talk) 21:56, 19 October 2014 (UTC)
More often than not I find collapsed by default content obnoxious. If an information relevant to the topic of an article, then it should be presented openly. Please don't play hide and seek and make me look for magic buttons to click on.-----<)kmk(>--- (talk) 03:44, 26 October 2014 (UTC)

Black (or dark) Wikipedia template

I was looking for a while if a black or dark design of Wikipedia has been ever proposed. Like I was not able to find it, I start a proposal.

I think this is not something I only thought about. There is many people who suffer from white backgrounds. Most of the web services I use can be configured in black background (DuckDuckGo, Gmail, Google, etc.). Moreover, dark backgrounds help to save energy, which is better for everyone.

I was wondering if it is possible to set Wikipedia with a dark template. Cerilet (talk) 12:33, 24 October 2014 (UTC).

(Note: This is my first edit on Wikipedia. I would appreciate if someone can move this to a more convenient place or edit it if there is something that should be changed.)

Set Preferences → Appearance → Skin = MonoBook and save, then check Preferences → Gadgets → Use a black background with green text on the Monobook skin. --  Gadget850 talk 12:42, 24 October 2014 (UTC)
However, the energy savings are an urban legend, I'm sure a Google search can confirm this.--S Philbrick(Talk) 12:56, 24 October 2014 (UTC)
Yep. Unless you're using a cathode ray tube monitor where black is a result of the screen actually being off, and the green is the type that requires very little energy to be read (same reason night vision goggles are usually green). If your monitor was made this century (well, this side of the century mark), chances are that displaying a black screen uses as much energy as a white screen, plus the additional work of diffusing the light so it looks black. Now, I do recall that if you turn the overall brightness down on an LCD monitor, that can chew up less energy (and have experienced this with my phone).
Still there are lighting conditions where I have an easier time reading white or green on a black background, and could understand how some people would have trouble with black on white. Ian.thomson (talk) 13:06, 24 October 2014 (UTC)
LCD displays work by blocking/unblocking the backlight. Their energy consumption is basically independent of the pattern they display. In theory, there is a small energy cost when switching images, but that is very marginal. For OLED displays, the energy used does depend on the brightness of the image, and the effect is significant enough to affect battery life for portable devices. --Stephan Schulz (talk) 13:14, 24 October 2014 (UTC)
Old-school LCD screens (like Amazon Kindle) work the other way around, am I right? --NaBUru38 (talk) 22:12, 25 October 2014 (UTC)
Old-school LCD's (as in digital watches or many alarm clocks) work without a backlight, i.e.you only see the light reflected from behind the liquid crystal pane. Most Kindles use fancy e-ink displays that work on a very different system - there the display itself reflects or absorbs light. But both don't need energy just to maintain a static picture (modulo minor technical losses, as always in real systems). --Stephan Schulz (talk) 07:29, 26 October 2014 (UTC)

Proposal Trusted Tester user group

On 20:39, 14 May 2013 (UTC) I suggested WMF to create "trusted testers" user group. Someone from WMF called that a good suggestion. After that, I don't know what happened.

I can see someone has started an RFC in this page on MediaViewer. I clearly support that RFC, but, I am too reluctant to write there. Does WMF care?

Anyway, currently when WMF makes a change (call it VisualEditor, MediaViewer etc.), it is forced on all/thousands of editors and for next many weeks, hundreds of editors report dozens of errors, and WMF keep on fixing/improving those.

Can't we create a "trusted tester" (TT) user group like Google or Microsoft? The trusted testers (TT) will be the first editors to test a feature and report good" or "bad" or anything. --Tito☸Dutta 17:41, 13 October 2014 (UTC)

I don't think there was any shortage of people testing MediaViewer - the complaints about it started when it was in beta and have not stopped to this day. One of the biggest problems with MediaViewer is that it's been imposed not without consultation with the community, but rather over the community's vigorous protests. I'm not sure why we need a separate "Trusted Tester" user class when people can always opt in to the beta features from the WMF labs. 0x0077BE [talk/contrib] 17:53, 13 October 2014 (UTC)
Agree, no need for a usergroup that gets forced features that can just be handled by opt-in. I don't see a problem where "unauthorized" testers were using beta features that caused harm. — xaosflux Talk 18:11, 13 October 2014 (UTC)
The reply said:
"That's a good suggestion :). I know that Erik (Eloquence) is very keen on the idea of deploying things in a beta on enwiki, in future, rather than testing elsewhere; hopefully this will allow us to discover problems 'natively' before they become a problem for many users. Okeyes (WMF) (talk) 20:49, 14 May 2013 (UTC)"
Beta came six months later: Wikipedia:Village pump (technical)/Archive 120#Introducing Beta Features and Media Viewer. PrimeHunter (talk) 00:31, 17 October 2014 (UTC)
I see no benefit from a user right here. There is already far too much software-enforced hierarchy. If a group of "neutral" testers is to be identified so that "people who just want to find fault in everything" can be ignored, you can do that socially. To deny random users the opportunity to test and comment on beta features before they are made mandatory would be yet another major step backward in terms of community input. Wnt (talk) 21:36, 17 October 2014 (UTC)
This is not a user right. This is a user preference. Add a checkbox to the preferences panel "Always enable new experimental features." Oiyarbepsy (talk) 00:48, 23 October 2014 (UTC)
The term "trusted testers user group" is confusing. I agree with having an option to "always enable new experimental features", and I disagree with adding a new MediaWiki user permission group. --NaBUru38 (talk) 22:03, 25 October 2014 (UTC)
Are you aware that a checkbox "Automatically enable all new beta features" already exists? It's at the top of the beta features tab. — HHHIPPO 15:19, 26 October 2014 (UTC)

Shortcut T for Template namespace

I see in this previous RFC there was a rejection of using "pseudo-namespace shortcuts" such as T: for Template: namespace. I didn't read the whole RFC but I do know that I get tired of typing "Template:" into the search box each time I want to find a template. The name space "T" is unused so I don't see why there can't be a change made where this could be implemented. Comments? ~Technophant (talk) 03:35, 20 October 2014 (UTC)

More reading material for you: Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. When re-making a proposal for something that has already been repeatedly rejected, you really should address the reasons for it being rejected previously. Anomie⚔ 10:38, 20 October 2014 (UTC)

Better idea

How about changing the search box so that if I type in {{infobox}}, the search box is smart enough to suggest Template:Infobox? That would address @Technophant:'s issue - they could just copy and paste it from the wikicode. Oiyarbepsy (talk) 01:03, 23 October 2014 (UTC)

How about alowing any page to be included/transcluded with parameters? If there is none, then it would render without any extra computing. --NaBUru38 (talk) 22:09, 25 October 2014 (UTC)
I'm not sure how that would help anything. Oiyarbepsy (talk) 21:05, 28 October 2014 (UTC)
The better place to raise this issue would be Wikipedia:WikiProject Football. --Jayron32 01:14, 30 October 2014 (UTC)

And I just moved it there - Wikipedia talk:WikiProject Football#Team divisions on player pages. Oiyarbepsy (talk) 06:20, 30 October 2014 (UTC)

Watchlist with watch/ignore talk page threads

As an IEG proposal, I have proposed making a user script which permits you to watch or ignore threads on talk pages. With this script, for talk pages your watchlist will only show the threads you have chosen to watch. Alternately it will show all threads except those which you have indicated you desire to ignore. In addition, the script will permit you to display entries from your watchlist on other Wikipedia projects and languages. If would like to see this functionality happen, please go to the IEG page and indicate your support (endorse). — Makyen (talk) 23:52, 30 October 2014 (UTC)

Commons admins/OTRS access to deleted files? Opt-out?

Hi. Since this seems to be mostly ignored on VPT, and someone on the RfC said it was not a good place to put it, I'll put this link here too: m:Requests for comment/Global file deletion review. πr2 (t • c) 00:51, 31 October 2014 (UTC)

Creation of the "Special talk:" namespace

Moved from Wikipedia:Village pump (technical)/Archive 131 § Creation of the "Special talk:" namespace

It's not obvious where to discuss Special pages, but it seems the typical place for them is Wikipedia:Talk:Special:Foo. On the other hand, sometimes they are at Help:Talk:Special:Foo, so it's not even consistent. In my view, this should instead be Special talk:Foo, and Special:Foo should have a discussion tab just like any other page. This would give a place for people to discuss special pages that they would actually be able to find. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)

Note: Please see Wikipedia talk:Criteria for speedy deletion#Proposal to update R2 criterion for "Special talk:" redirects for the discussion that prompted this one. Steel1943 (talk) 18:52, 18 October 2014 (UTC)
  • Per my comment in the other discussion Steel linked to (please respond there), creating a NSA for the "Special talk:" to point to "Wikipedia talk:Special:" is pretty easy. To get a "discussion tab" on Special pages would be more difficult to do in core because, as I understand it (which isn't always the way it is), special pages aren't normal pages in a normal namespace (hence the NS number of -1); that said a gadget could be created that would simulate a "discussion tab" on most special pages (there are a couple where .js won't run for security reasons). — {{U|Technical 13}} (e • t • c) 21:41, 18 October 2014 (UTC)
Struck-out text that is no longer pertinent to the current discussion, but has been retained here for historical purposes. Steel1943 (talk) 15:31, 22 October 2014 (UTC)
I wonder if the Special_talk.php from this very old bug report [2] is still a going concern? This was referenced in Wikipedia:Village pump (technical)/Archive_61#Enable Special talk.php. jni (delete)...just not interested 20:33, 20 October 2014 (UTC)
  • As I said below in the discussion before this became a RfC: "Special:" is a technical namespace, and it will be easier to create a technical solution (which had this RfC not been started could have been implemented within a week or so I'm sure, but now should wait until this has concluded) than it will be to add this exception and then enforce it. As such, I oppose the creation of this CNR where a NSA[disambiguation needed] would do a much better job. For those that might not be clear on what this alternate proposal is exactly: I'm proposing to make an actual namespace alias that will load "Project talk:Special:" when "Special talk:" is given for a namespace just like "Wikipedia talk:" and "WT:" both take us to "Project talk:" themselves. Doing this means there will be no redirect involved at all and none of that hassle or issues that come with it.

Support the creation of the "Special talk:" namespace

  1. As proposer. — {{U|Technical 13}} (e • t • c) 14:56, 22 October 2014 (UTC)
    Support, as above. Steel1943 (talk) 15:22, 22 October 2014 (UTC) I would rather see this as an actual functional namespace than an alias. I don't know why this discussion has had to be reconfigured as so. Now, the fine line between an actual functional namespace and an alias has been totally blurred. Steel1943 (talk) 19:51, 22 October 2014 (UTC)
  2. Support Oiyarbepsy (talk) 00:45, 23 October 2014 (UTC)
  3. Support --Fauzan✆ talk✉ mail 05:11, 23 October 2014 (UTC)
  4. Support 2A02:8420:508D:CC00:56E6:FCFF:FEDB:2BBA (talk) 13:38, 1 November 2014 (UTC)

Oppose the creation of the "Special talk:" namespace

  • Oppose as basically useless. You can't add Special pages to watchlists, severely reducing the chance of anyone seeing your comments. Comments about special pages can go to VPT or something similar, where they will get a lot more attention usually. Fram (talk) 09:32, 28 October 2014 (UTC)

Discussion about the creation of the "Special talk:" namespace

Alternate proposal 1: update speedy deletion R2 criterion for "Special talk:" redirects as exceptions

Moved from Wikipedia talk:Criteria for speedy deletion/Archive 54 § Proposal to update R2 criterion for "Special talk:" redirects

I propose that that the wording of the R2 criterion be updated to include this wording at the end as an exception to the criterion:

...and redirects titled "Special talk:Foo" that target the "Wikipedia talk:" or "Help talk:" namespaces.

I'm proposing this since the "Special talk:" namespace does not exist, and I have on multiple occasions found myself in a situation where I wanted to discuss the function behind a tool in the "Special:" namespace, but could not find its discussion page. I recently discovered that the naming convention for these talk pages seems to be "Wikipedia talk:Special:Foo". It makes sense for the talk page to be in the non-existent "Special talk:" namespace, but since the namespace doesn't exist, creating a page in that namespace defaults it into the main namespace, which would currently make it eligible for speedy deletion for this criterion if the "Special talk:" title was made a redirect. Steel1943 (talk) 16:49, 18 October 2014 (UTC)

Support the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

Assuming Steel1943, as proposer. I'd rather see the creation of the namespace as a whole, as stated in the above sections. Steel1943 (talk) 15:22, 22 October 2014 (UTC)
  1. Assuming Thryduulf, per discussion below.

Oppose the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

  1. Oppose creating as a CNR. Please see alternate proposal. — {{U|Technical 13}} (e • t • c) 14:56, 22 October 2014 (UTC)
  2. Assuming Jni, per discussion below.
  3. Assuming Oiyarbepsy, per discussion below.

Discussion about the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

  • Exactly, which is why I'm trying to propose that it be made an exception. And as for this being a pseudo-namespace, if that's the case, then essentially "Wikipedia talk:Special:" is a pseudo-namespace in an actual namespace. The fact that these redirects currently don't exist is essentially harmful. The only other option I see is a proposal to actually create the "Special talk:" namespace. (I'm trying this route first, since it doesn't require an update to the actual function of the Wikimedia software built on the English Wikipedia.) Steel1943 (talk) 18:11, 18 October 2014 (UTC)
    • I'd actually rather see it implemented as a NSA. This is a technical solution that doesn't require a namespace to be created (that really can't exist as I understand it). Prevents all drama. @Steven (WMF):, can we get a little input from the developers, please? I'm sure Jackmcbarn could put this up for merge in Gerrit (or phab, if we are using that now).  :) — {{U|Technical 13}} (e • t • c) 19:59, 18 October 2014 (UTC)

I'm okay with this temporarily, but for the long term I oppose, since this exception is a hack. The real solution is a Special Talk namespace, which probably should exist. I'll bring it up at Village Pump Technical. Oiyarbepsy (talk) 18:43, 18 October 2014 (UTC)

Wikipedia:Village pump (technical)#Special talk namespace. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)
@Oiyarbepsy: Essentially, I agree with your reasoning. Thanks! Steel1943 (talk) 18:50, 18 October 2014 (UTC)
I think that the exception to R2 should be something along the lines of "other than approved pseudo-napespaces", and not mention any true namespaces; at the same time, we approve the CAT:, H:, MOS:, Special talk:, etc. Any subsequent discussion about topics like this would then go to WT:Shortcut. עוד מישהו Od Mishehu 19:46, 18 October 2014 (UTC)
  • Support this exception. Such redirects can still be nominated at RfD and discussed on their individual merits (or lack of merits) balanced against any harm that it does (or doesn't) do. Just because many CNRs are harmful, does not mean that all CNRs are or that being a CNR is harmful in and of itself (hence the need to have exceptions in the first place). Thryduulf (talk) 01:15, 19 October 2014 (UTC)
  • Oppose this exception. This is just WP:BURO rule creep. Not needed in practice. No harm is done if we just wait for Special talk: namespace (the correct solution). All admins already know about "Wikipedia talk:Special:Foo" talk pages and therefore can make a smart decision on the spot, if there is a need to speedily delete a redirect pointing there. It was recently noted in Template_talk:Db-r2 that the R2 warning template had had inconsistent namespace applicability instructions compared to CSD policy itself for over four years, and nobody noticed or cared. We will get more inconsistencies like that if start inventing detailed rules and exceptions for every marginal use case of our wiki-editing tools. jni (delete)...just not interested 10:45, 19 October 2014 (UTC)
  • How is this instruction creep? The basis of this proposal is the usefulness of the creation of such redirects that are intended to target the talk pages for the discussion of pages in the "Special:" namespace. At the present time, there are no redirects titled "Special talk:Foo" that exist, (obviously, given my statement in the nomination.) Also, just because administrators, in practice, should know about the existence of the "Wikipedia talk:Special:" titles (I'm certain that several administrators do not know about that standard naming practice), the ability to find these pages should be easy to find by all editors who may need to discuss a page in the "Special:" namespace, admins and non-admins alike. However, I do agree that I'd rather just see the creation of the "Special talk:" namespace; however, as stated above, there is the possibility that it would not be technically possible due to how the "Special:" namespace is programmed in the English Wikipedia. Steel1943 (talk) 16:40, 20 October 2014 (UTC)
  • I agree that it is instruction creep actually. It's an attempt to introduce wording to a social method of moderating what does or does not happen on wiki when there is a much simpler technical approach. I see no objection to adding the NSA here, and will request it added on bugzilla tomorrow afternoon (about 28 hours from this post) if it remains unopposed for the simple technical solution. The technical solution makes adding it to policy unnecessary and moot. — {{U|Technical 13}} (e • t • c) 17:01, 20 October 2014 (UTC)
  • In regards to if the technical resolution is not possible, I assure you the technical resolution is not only possible, it's easier than trying to impose a change to existing social sanctions. Since your if clause is false, then it is reasonable to assume that it is indeed instruction creep. I can't see a use case where "Special talk:" shouldn't take the user to a talk space where they can talk about a "Special:" page (even in cases where "Wikipedia talk:Special:Foo" for "Special:Foo" where "Wikipedia:Special:Foo" doesn't yet exist). I welcome cases I may not have thought of, if you have any. :) — {{U|Technical 13}} (e • t • c) 18:45, 20 October 2014 (UTC)
  • It is instruction creep because exactly 7 such pages have ever existed (at least after last time the deleted revisions were purged from database - and last time that happened was before I was made admin here close to 10 years ago!). No redirect with prefix "Special talk:" targeting the Help talk namespace has ever existed. 3 of the deleted pages were not redirects at all and were deleted per G2 (or close to it) reasons. Details are in User:Jni/Special talk redirects review, for benefit of non-admins participating to this discussion. For the 4 redirects, some of which were deleted multiple times, 2 deletions were done without citing a specific criteria, R2 was cited 2 times and G6 was given as reason 3 times. Note the prominence of G6; I would use it instead of R2 for deleting this kind of weird artifact relating to pseudo-namespaces myself. Your proposal seems to silently limit applicability of G6, making the already convoluted and somewhat arbitrary set of CSD rules even harder to remember or apply correctly. There have indeed been some misunderstanding about this matter - see logs for Special talk:Cite where Rossami makes a circular argument, claiming that his invalid use of admin's restore tool (assuming R2 was the same as today in 2007) invalidates a later G6 CSD as well. Overall, there has not been any need for this exact kind of redirect because only 4 were ever created during last decade. If something has hardly ever existed, there is no need to make special rules for it's deletion! jni (delete)...just not interested 19:04, 20 October 2014 (UTC)
  • Oiyarbepsy, I called his argument circular ("dubious" would have been a better word), because there was a five year gap between the two deletionsrestores. The controversy, if any, cannot last for that long and later day admins are allowed to take a fresh look and are not bound by some very old actions of their peers. Besides, a really detailed analysis would require understanding the deletion policies, CSD rules and unwritten conventions as they were during each and every of the events in the log. jni (delete)...just not interested 19:53, 20 October 2014 (UTC)
  • On taking a closer look of several speedy restores Rossami did ~7 years ago (we all have important investigations like this going on from time to time, right?), it seems the then-controversial matter was eventually settled in RfD and consensus that "Special talk:Foo" redirects are not needed was established. Now it is proposed here to override this earlier consensus, but is this talk page or exception to CSD R2 really even the right forum or mechanism for this? jni (delete)...just not interested 19:50, 20 October 2014 (UTC)
  • (edit conflict) @Jni: I did not see it above, so would you be able to provide a link to the RfD discussion where consensus was formed (in one way or another) deeming the usefulness (or lack thereof) of "Special talk:" titles? (I'm, more or less, quite curious to see it, given that I had no idea that any form of consensus was established for this very matter in the past. I'm in no way saying that this changes my opinion at the present time.) Steel1943 (talk) 20:10, 20 October 2014 (UTC)
By the way, your question about if this is the right forum for this discussion, I'm actually wondering that as well, given that this discussion has turned into something more than just trying to add an exception to the R2 criterion; this discussion is turning into a discussion about whether or not a "Special talk" namespace (or an pseudo-namespace namespace alias, as Technical 13 has eluded above) should exist. If this discussion continues as it has, I'm thinking the whole discussion may need to be moved, and maybe even converted to an RFC if it continues to gain as much momentum as it has in the past day alone. Steel1943 (talk) 20:24, 20 October 2014 (UTC)

Looking at the deletion logs for those seven pages, it's pretty much adds a lot of strength to the idea that we need Special talk. Almost all of them were either redirects to a corresponding Wikipedia talk page or were the type of material that you'd expect to see on a talk page. The fact that these pages are so rare is because the special pages don't link any talk pages, so the majority of users just get lost and give up trying to discuss them. Others guess Special talk and either post a comment or make redirects. Oiyarbepsy (talk) 20:02, 20 October 2014 (UTC)

Rename "View history"

NO THANK YOU
I see no benefit in allowing this discussion to continue, regardless of whether the filing party is serious or not. Beeblebrox (talk) 20:02, 2 November 2014 (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.

Wikipedia has been accused of being gender biased. By renaming "View history" at the top of every article to something else like "Past edits" wikipedia would become more gender neutral and welcoming to women. This small change would have a huge positive impact in my opinion. Thank you. Brian Everlasting (talk) 20:13, 1 November 2014 (UTC)

@Brian Everlasting: What does that have to do with gender bias? Jackmcbarn (talk) 20:15, 1 November 2014 (UTC)
Some people confuse "history" with "his story". Brian Everlasting (talk) 20:17, 1 November 2014 (UTC)
Are you for real?--BabbaQ (talk) 20:22, 1 November 2014 (UTC)
Yes I'm very serious. Brian Everlasting (talk) 20:23, 1 November 2014 (UTC)
Those who might complain about "history" being confused with "his story" needs to get a job. Or a hobby. --BabbaQ (talk) 20:24, 1 November 2014 (UTC)
"history" = "his story" LOL! I had never even heard that before. --Obsidi (talk) 20:32, 1 November 2014 (UTC)
LOL, LOL, LOL.--BabbaQ (talk) 20:38, 1 November 2014 (UTC)
Brian Everlasting is also changing a lot of "History" section headings to "Background". I don't have time now but somebody might want to look at this nonsense. PrimeHunter (talk) 20:39, 1 November 2014 (UTC)
Brian Everlasting, please do not change these kind of things without consensus. It becomes kind of ridiculous.--BabbaQ (talk) 20:41, 1 November 2014 (UTC)
Completely off-topic, a solution for those who see sexism in the word is to replace it with ourstory. Oiyarbepsy (talk) 20:37, 1 November 2014 (UTC)

Changing to past edits would be good simply because it's more clear what it is. On an article like USA, some might think the button leads to the History of USA, cause that's what it sounds like. Past edits more clearly explains what it really is. Oiyarbepsy (talk) 20:42, 1 November 2014 (UTC)

Has this actually happened, or are you guessing at what someone could think? Sounds a bit unlikely to me that anyone thinks that's how Wikipedia is navigated. 0x0077BE [talk/contrib] 21:29, 1 November 2014 (UTC)

What? I don't use completely blunt wording very often, but this is an absolutely ridiculous suggestion. (And, yes, I have heard the "history" and "his story" joke.) But seriously, since when do people actually confuse "history" with "his story"? --Biblioworm 21:21, 1 November 2014 (UTC)

Or we could separate it into 'history' and 'herstory'. Then figure out a name for the other gender identities. Then work on racial/ethnic/national splits. Is this April Fools in November? (It is six months off). --  Gadget850 talk 21:25, 1 November 2014 (UTC)
What is it with gender-stuff? We already get editors who insist that, when someone decides they want to change their public gender identification, we must immediately rename the article and change all the pronouns, even on the parts about stuff years in the past to the point of "she attended an all-boys school" or "he gave birth to his first child". But recently I saw one of these editors complaining that we kept a redirect from someone's old name to the article using their new name. Anomie⚔ 01:16, 2 November 2014 (UTC)
  • Hrmmm... This is quite amusing... I do agree that "View history" is a poor label. I would prefer "Page history" to be clear that mean the history of the page on Wikipedia and not Viewing the history of the topic (I've talked to many "non-Wikipedians" about this and that part is confusing). This gender bias crap, is just that, crap... — {{U|Technical 13}} (e • t • c) 01:44, 2 November 2014 (UTC)
I definitely think that "View history" is too ambiguous per Oiyarbepsy; We shpould go with some indication that this is the history of the page, or the old versions of it. I don't buy the gender claim here, though. עוד מישהו Od Mishehu 04:30, 2 November 2014 (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.

"Notable residents"

I suggest that any person who is listed as a "notable resident" (or similar) in any article should be removed from the article unless that person has an article named for them. There are far too many of these "notable residents" who are mentioned in many articles without justification. If they don't have an article named for them then they are not notable and therefore not "notable residents". Jodosma (talk) 19:27, 14 October 2014 (UTC)

I'm amenable to a third-party source discussing the individual as an indicator of notability, but if there's no article or sourcing, I can't imagine why they'd be listed. DonIago (talk) 19:36, 14 October 2014 (UTC)
All over Wikipedia individuals are mentioned as if they are "notable", e.g. in articles about colleges or schools or minor authorities (councils and the like), the tutors and senior members of the staff (or council) are often mentioned, in many cases stated in the article as being "notable", as if the statement that they are notable makes them notable. I would like to remove all of these if they don't have an article named for them. When these people are named then the person naming them should first of all create the article about them. This kind of thing also occurs in many articles about businesses or companies, with no justification. Jodosma (talk) 19:57, 14 October 2014 (UTC)
I think it is fine if a no-article notable resident is listed along with a third-party reference that establishes their notability. This sort of entry aligns with WP:REDLINK, the expansion of the encyclopedia. Binksternet (talk) 22:13, 14 October 2014 (UTC)
I agree with Binksternet. We do not tell WP:VOLUNTEERs that they must first create an article to be permitted to make a small improvement to another article. Your definition of WP:Notable is wrong: a person is notable when s/he qualifies for a separate article on the English Wikipedia. You can be notable for decades before anyone actually starts writing the article.
If there's no source for such an entry, then please find one yourself. If you're not willing to make that much effort, then add a {{fact}} tag, and check back in a couple of months (yes, months, not days) to see whether anyone has done so. Don't just blank them because you don't like them and can't see the value in them. WhatamIdoing (talk) 22:19, 14 October 2014 (UTC)
If red links obviously merit an article leave them. In most cases they do not and should be removed there and then.Charles (talk) 22:26, 14 October 2014 (UTC)
Comment: Red links in articles are different than those found in links lists. The ones in articles probably have a chance of being expanded someday, probably by the person who put it there to begin with. Lists are different, however. Any name can (and repeatedly are) added to lists that are never, ever going to be notable, or are actually tagging/vandalism. If they are in a list, the name, item, or whatever needs at least a reliable source citation if there is not an existing article in Wikipedia. Red links in wiki-lists are meaningless. PS: "Notable Residents" sections are, imo, list sections. GenQuest "Talk to Me" 23:30, 14 October 2014 (UTC)
The Notability standard only applies to creating an article. The standard for including information in an article is a lot lower. Alsee (talk) 10:32, 16 October 2014 (UTC)
On the other hand, many of these additions are supposedly living people. I say supposedly because they could be someone's boyfriend, dog, worst enemy, whatever. With no sources we simply don't know and such entries may be WP:BLP violations if not simply promotional. A fact tag isn't enough to prevent a BLP violation. Dougweller (talk) 16:10, 16 October 2014 (UTC)
I agree that they are essentially lists, which on Wikipedia are advised to have inclusion criteria so they don't become indiscriminate, and all content on Wikipedia is required to be verifiable. Often content in lists is verifiable via the bluelink, so if an entry in this sort of list is redlinked or not linked at all, it is probably non-verifiable and should be flagged; however Dougweller is right that such entries in lists of people are likely enough to be information about living persons (who are alive unless confirmed deceased) which is to be removed immediately if not verifiable. You may also be interested in WikiProject Laundromat which is aimed at cleaning up such lists. Ivanvector (talk) 16:28, 16 October 2014 (UTC)
If someone wants to put a non-linked name in a list, it is incumbent on them to show why that name belongs on the list. Otherwise, it is OR and should be immediately removed as such. Lists inclusions are different from inclusions in articles; per the the comments above. GenQuest "Talk to Me" 01:20, 17 October 2014 (UTC)
No, that's not OR. "Original research" involves material that has never been published, anywhere on the planet, at any time. "Uncited" is what we call material that someone has added without showing why that name belongs on the list. WhatamIdoing (talk) 19:31, 17 October 2014 (UTC)
I should've also included "Uncited" above, as both apply. In either case, those entries can be removed immediately, no tagging necessary, per BLP. GenQuest "Talk to Me" 22:41, 17 October 2014 (UTC)
The above discussion appears not to consider the situation where a good, referenced source document says "Bloggs, Smith and Jones did a very important thing (X)" but only Bloggs and Smith have WP articles, AND Jones was otherwise so non-notable that no WP article for him is even likely. IMHO his name (without a redlink) belongs in the articles for Bloggs and Smith (and for X if it has one) It also belongs (with ref but no redlink) in a list of people related to X, or of people in an occupational group etc related to X. Downsize43 (talk) 10:37, 19 October 2014 (UTC)
I think in a case like this it belongs in the article; it does not belong in a list of people associated with the subject. Article content does not have to be notable. The best rule for people in such a list is that they either have to have an article or be obviously qualified for one--with a reference. DGG ( talk ) 18:31, 20 October 2014 (UTC)
I propose to remove the term "notable" and just write: "City/town residents include Alicia and Bob". --NaBUru38 (talk) 22:05, 25 October 2014 (UTC)
No, no, no. That would result in a random list of self-publicisers who happen to have heard of Wikipedia. It would not be useful to our readers. DGG has it right - people in the list should either have an existing article, or be demonstrably notable in Wikipedia's sense, with a reference to prove it. JohnCD (talk) 11:14, 30 October 2014 (UTC)
Would cast lists be affected by any of this? A Greek Slave has a list which should be old enough not to be a problem. More modern plays might well have a mix of notable and not. Sorry if this is off topic.SovalValtos (talk) 19:10, 31 October 2014 (UTC)
To be included in a list of people with some characteristic it is not enough for the person to have their own article: it should be reliably sourced that they have this characteristic. We could create a List of people from Mars and add blue links for a lot of famous names, but that wouldn't mean they were qualified to be on this list, and some of them might even object: Noyster (talk), 09:50, 3 November 2014 (UTC)
An excellent proposal. And ditto for alumni lists. Allahabad University currently has blue links, a significant minority of which actually come with references. Compare Tokai University, which Somebody Who Likes both Penicillin (band) and Capitalization has pumped with Penicillin, and Siddharth College of Law, with no-links. Yes, red links are fine. But if these people are notable, redlink them in a context that suggests their notability. Residence, birthplace and university (whether graduated from or dropped out of) don't confer notability. ¶ Of course it's possible that adding redlinks within these lists could prompt somebody to create an article. But if so, then more appropriate and more persuasive would be a paragraph within the relevant talk page. -- Hoary (talk) 12:01, 3 November 2014 (UTC)
The guidance at WP:NLIST is useful, particularly For instance, articles about schools often include (or link to) a list of notable alumni/alumnae, but such lists are not intended to contain everyone who attended the school — only those with verifiable notability and the much-neglected Furthermore, every entry in any such list requires a reliable source attesting to the fact that the named person is a member of the listed group. NebY (talk) 14:03, 3 November 2014 (UTC)
User:NebY is absolutely right - I see lists or sections all over with blue linked names of people said to be from a certain place, a certain ethnic group, etc with no reliable source. And it isn't enough for the blue linked article to have a source, the source must be in the list or section. Dougweller (talk) 15:32, 3 November 2014 (UTC)

Do we need to replace RfA?

CLOSED
It seems like most people think this discussion is a duplicate, and therefore, I don't see any purpose in allowing it to continue. --Biblioworm 23:37, 3 November 2014 (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.

Since it is rather reasonable to predict that the current RfC is going to fail, I think it would be a good idea to have a separate discussion to determine whether or not the majority of community members think RfA needs to be replaced. This discussion is not intended to collect new ideas for admin election reform. That can happen in a future discussion.

If you think we need a new system to replace RfA, put #'''Yes''' - (Your rationale here). If you think RfA does not need to be replaced, put #'''No''' - (Your rationale here). Thanks for your input. --Biblioworm 22:10, 3 November 2014 (UTC)

Since when do we replace things? We should just edit it until it is better. Chillum 22:57, 3 November 2014 (UTC)
Apparently if the RfC doesn't pass the answer is to just immediately have another one now? — xaosflux Talk 23:04, 3 November 2014 (UTC)
Isn't this exactly the same question as the RfC up the page is asking? I mean, the vote options there are "maintain/abolish" RfA, and you're asking "replace/don't replace" RfA. What's the difference? C628 (talk) 23:05, 3 November 2014 (UTC)
It was not intended to be the same question. The RfC above is proposing that we mark RfA as historical right now and immediately start working on a new system. I'm asking if the community generally feels that RfA needs to be replaced by a new system. In my opinion, this is a separate topic, because some people who have voted above support the idea that we need to replace RfA, but they do not support the idea that we should get rid of RfA immediately and hope that we'll find a way to come up with a new system. --Biblioworm 23:13, 3 November 2014 (UTC)
because some people who have voted above support the idea that we need to replace RfA— I'm not sure this RfC is strictly necessary, though I understand that it might make the matter clearer. As this information is already available in the above RfC, and you're not seeking to discuss new ideas, I ultimately don't think it's necessary to rehash this out again. That many editors would like to see improvements made to RfA is evidenced well enough already. I, JethroBT drop me a line 23:21, 3 November 2014 (UTC)
I can see how this is a separate but related discussion. We went into the last (above) !RfC with the assumption of consensus that RfA is broken, but a number of editors have responded that it isn't broken, for various reasons. However, the RfC you're proposing is really already happening at WT:RFA so why not consolidate the discussions instead of opening a new one? Ivanvector (talk) 23:24, 3 November 2014 (UTC)
I wasn't aware of the the discussion at WT:RFA (it's not on my watchlist). In any case, everyone seems to agree that this is a duplicate discussion, and there's no purpose in hearing that over and over again, so I'll just close this. --Biblioworm 23:33, 3 November 2014 (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.

Result of clicking on a file

First off, let me note that this is intended to be completely separate from the Media Viewer issue: my proposal addresses only what happens when Media Viewer isn't used, whether because you disabled it or because you brought up the file in a new tab.

Numerous Wikipedias besides en: allow free and nonfree material, and many other Wikipedias (with exceptions, e.g. es:) permit people to upload images locally. Some that do both, e.g. fr:, have a direct link to the Commons page when a Commons-hosted image is clicked. For example, go to fr:Accueil principal and click the lead image for today's featured article, and you'll reach https://commons.wikimedia.org/wiki/File:US_Cr%C3%A9teil_-_Colmar_National_(1).jpg rather than https://fr.wikipedia.org/wiki/File:US_Cr%C3%A9teil_-_Colmar_National_(1).jpg. Wouldn't this be desirable for us to do as well? My proposal shouldn't affect locally hosted images. Again, back to fr: — if you go to fr:Liste des émissions de franc français depuis 1960 and select the image immediately above 10 francs Mathieu, you'll go directly to https://fr.wikipedia.org/wiki/Fichier:10_francs_Mathieu_1987_F365-28_revers.jpg because it's locally hosted.

In most cases, edits to image descriptions and image talk pages should be conducted at Commons, and the few exceptions (e.g. adding FP and appeared-at-DYK notes to descriptions) can always be done by changing the URL, e.g. adding en: before the filename. Inexperienced users won't know how to do things such as FP notices; they're only going to know how to edit the actual description and make talk page comments, so we ought to make it harder for them to add misplaced comments and create misplaced file description pages. Since most file notices are done by bots, it presumably wouldn't be that hard to tell the bot to follow a slightly different pathway in order to leave a note. By doing this, we can make it much simpler even for us experienced editors (we won't need to click an extra link every time we open a Commons file), and much simpler for inexperienced ones. Nyttend (talk) 15:45, 3 November 2014 (UTC)

  • I'm sorry Nyttend, I am having a hard time following what you are saying, as you seem to be talking in circles around an idea (which should make it easier since I do the same thing all the time). Are you saying that if an image is hosted on both en and commons, then the software should default to the local copy. If this was the case (I don't see why it wouldn't be), then on the File: page, there would/should be a link to the commons version/page as well. Is this summary correct? — {{U|Technical 13}} (e • t • c) 16:28, 3 November 2014 (UTC)
  • I actually wasn't addressing that idea. If an image is only local, clicking the image goes to the local image (as it does now). If an image is both local and at Commons, clicking the image goes to the local image (as it does now). If an image is only at Commons, clicking the image goes directly to Commons, as it does at fr: but unlike what it does here right now. I believe that this is something that's simple for the developers (they simply toggle a setting) but impossible for everyone else, comparable to the setting that is toggled to allow a wiki to use images from Commons. Nyttend (talk) 16:34, 3 November 2014 (UTC)
    We already have a gadget called "Redirect image links to Commons for files that are hosted there" that seems to do what you want. Jackmcbarn (talk) 16:59, 3 November 2014 (UTC)
  • Technical 13, currently, if an image is hosted on Commons and is in an English Wikipedia article, upon clicking the image you go to a page on en-wiki, from which you can then click through to the page on Commons. This is assumedly to reduce confusion for readers who don't want to inadvertently end up on Commons. Nyttend was proposing an option to go directly to the page at Commons, which apparently already exists. Sam Walton (talk) 18:21, 3 November 2014 (UTC)
I'm not sure that I agree with the assumed rationale, but if we accept it (for the sake of argument), then that gadget, which I only recently discovered myself, should be default-enabled for all logged-in editors. WhatamIdoing (talk) 22:08, 3 November 2014 (UTC)

I agree with Nyttend, so I think that the option should be enabled by default. --NaBUru38 (talk) 19:19, 4 November 2014 (UTC)

  • Agree, though I do respect the reasons for having "disable" as the default. All the best: Rich Farmbrough, 23:57, 11 November 2014 (UTC).
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_114&oldid=1086982989"