Wikipedia:Village pump (proposals)/Archive 109

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

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

A webpage archiving wikiproject (?)

Is there a wikiproject for archiving wepages? I think there should be one so it can be convenient for editors who have no idea how to archive pages, and for those who simply don't have the time.So that those who are always or most often available can archive it for the other editor. if this already exists, i'm sorry for bringing this up again. I checked WP:ARCHIVE, and WP:WEBCITE.

I'm not sure what name its under if it exists, but if it doesn't exist, i believe this would be helpful and would save alot of other editors time in moving onto other edits, while other editors who like to archive other sites would be able to help the other's workload and improving wikipedia even more.Lucia Black (talk) 02:25, 11 January 2014 (UTC)

Do you mean something like archiving a talk page? There's already a help page for this. I don't think there needs to be an entire Wikiproject devoted to archiving pages. -Well-rested^Talk 06:54, 11 January 2014 (UTC)

I don't think Lucia is talking about wikipedia pages, but rather things like source pages. VanIsaac_{WS Vex}^contribs 09:18, 11 January 2014 (UTC)

If Lucia is talking about archiving source pages, this may be of interest. Novusuna ^talk 09:38, 11 January 2014 (UTC)

I'm asking for help archiving sources that we used in articles so that readers don't have any doubt. however, i thought if a group of editors wanted to dedicate to it, then maybe this will streamline the archiving page simply by request. i will inform those editors on the current proposal, if their active.Lucia Black (talk) 09:54, 11 January 2014 (UTC)

@Lucia Black: please see Wikipedia:Using the Wayback Machine and Template:Wayback's documentation. I hope this will be helpful. --Rezonansowy (talk • contribs) 13:31, 12 January 2014 (UTC)

@Rezonansowy: this proposal is to create wikiproject is intended to those who simply don't have the time to do or are too forgetfull to do it, and other members who are willing to archive pages, will help out. Similar to a place to request for grammar help.Lucia Black (talk) 23:59, 12 January 2014 (UTC)

I think Lucia is some how right in his sense. Archiving sources may be helpfull to readers Nechlison (talk) 18:02, 12 January 2014 (UTC)

Back to top

A definite improvement would be a BACK TO TOP option at the bottom of your pages ! Thanks — Preceding unsigned comment added by 66.27.220.198 (talk • contribs)

@66.27.220.198: Here you are - User:Numbermaniac/goToTop.js. --Rezonansowy (talk • contribs) 13:26, 12 January 2014 (UTC)

I tried this and it works well. Thanks, Rezonansowy. GenQuest ^{"Talk to Me"} 01:16, 14 January 2014 (UTC)

As an alternate, non-Javascript solution, there is also the "home" key on the keyboard. Novusuna ^talk 20:34, 12 January 2014 (UTC)

Or, for Mac users, ⌘ Cmd and ↑. Killiondude (talk) 00:21, 14 January 2014 (UTC)

Technical Outreach at Wikimania 2014

Hi all,

I'm organising Wikimania 2014 in London. It'll be the largest Wikimania ever by quite some way (we're expecting 4000+), and an excellent opportunity for outreach and awareness raising about the projects. Recognising London as increasingly a hub for technology, I'm especially keen to recruit new technical contributors. I've tried to do that by picking conference themes that would be enticing to people interested in tech, and I'll be heavily publicising in those circles; if you can help me improve The Wikimania London Wiki in any way, especially with suggesting interesting technical projects people could get involved with and generally improving the way that the technical details are described, that would be really helpful. Particularly, take a look at the 5 "theme" articles on the front page, and please, be bold! This is a great opportunity to recruit some really skilled new people, who I think have never really considered Wikimedia as an open source project before.

Any questions or if you're interested in helping out in some other way, please feel free to get in touch with me directly. EdSaperia (talk) 23:45, 13 January 2014 (UTC)

Proposal for a Template Documentation: namespace

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is a clear consensus against the creation of a separate namespace. Anomie's idea at the bottom seems like it might have gotten traction had it been proposed earlier or more prominently, but right now there is not enough commentary on it for me to issue a formal close one way or the other, so it's "no consensus - needs more discussion". Sven Manguard Wha? 19:56, 14 January 2014 (UTC)

---

This proposal is moved from the Idea Lab. That discussion may be found at Wikipedia:Village pump (idea lab)/Archive 12#Proposal for a Template Documentation: namespace. Update this link if it moves!

Any template with even a shard of complexity has a corresponding documentation file... the end result being that AllPages for templates is chock full of /doc, /doc, /doc. For such a ubiquitous feature, I feel that it would be very justified for a new Template Documentation: namespace to contain all of these documentation pages. This way, we could have a clear dichotomy between template code to be transcluded, as opposed to whatever needs to be said or explained about the template (but, of course, not transcluded with the template).

Let's also consider taking the idea a few steps further. By its direct association with an existing Template: namespace, the new TD namespace has potential for some features not usually found in a run-of-the-mill new namespace.

Automatic transclusion

We could make the function of the {{Documentation}} template automatic: a Template: page, requiring no individually-paged code or template to do so, could automatically check for a corresponding Template Documentation: page and display that on the bottom of the Template page, with a little explanatory divider/footer separating the two - explanation similar to the format currently in place on {{Documentation}}. And of course, none of that documentation or divider explanation would be transcluded onto any pages using the Template page. If we did this, it would be very feasible for a fully-developed, fairly complex template, complete with documentation, to use zero includeonlies, and zero noincludes. None of that crap. {{Documentation}} could become a thing of the past.

No documentation exists? "No documentation exists for this template. Click here to write some! <link>"

Special pages

Hard-coded associations between Template: pages and their Template Documentation: pages would enable us to look into additional Special pages: "Special:WithoutDocumentation", et cetera.

Intelligent categories

An infobox template about birds might be in Category:Infobox templates. It might transclude Category:Birds onto host pages which use it. This is logical, but to restrict the application in those ways we need more include rules. Ugly! My understanding is you simply must have include rules to use categories on a template page - because honestly, how often do categories apply to both templates and their host pages?

A better system: we could declare that categories in the Template: page's code would only apply to host pages, while categories one wishes to apply to the Template: page itself are placed in the Template Documentation: page.

I think that this would be a really useful thing to have on Wikipedia, and if it's adequately implemented it opens the door for similar features on other wikis. =)

Support

• As proposer: − Elecbullet (talk) 06:34, 12 December 2013 (UTC)
• See no reasons to object thus far; anyone who has worked on templates know how unwieldy the /doc subpage workaround system is for documentation. Not sure how much of this would also apply to Modules though. TeleComNasSprVen (talk • contribs) 07:04, 12 December 2013 (UTC)
  • I know very little about Modules, in fact I learned they existed in the process of writing this proposal, so I have little ability to comment. I foresee much commentary about how if we can have documentation for user scripts, CSS, modules, et cetera, why should templates have special treatment?

If a decision is made to implement Template Documentation as I have proposed, then (due to the bold-faced features I listed) my meager understanding of the software indicates it would probably require the writing of an extension, rather than just a simple new namespace. I think this extension could very easily have the capacity to work for every kind of namespace, and it could implement a system by which the individual installation selects which namespaces are document-able. So we could enable it for Templates if the consensus is as much, and if it is decided to apply to Modules as well, we could enable it there too. And if someone chooses to install the extension on their own wiki, the webmaster can implement documentation on whichever namespaces they please. Maybe I'm just rambling though. − Elecbullet (talk) 07:33, 12 December 2013 (UTC)

As in something like a new super-namespace in the hierarchy? Like Documentation: Documentation\Template: Documentation\Modules: etc... (Well for now I mean we should just concentrate on Template Documentation: )TeleComNasSprVen (talk • contribs) 07:38, 12 December 2013 (UTC)

Modules could already use such a system by changing MediaWiki:scribunto-doc-page-name if the target namespace existed. And if I were to implement such a thing more generically I'd do it along the lines of MediaWiki:ns10-doc-page-name. Personally, I'd recommend a pattern along the lines of "Documentation:Template:Foo" and "Documentation:Module:Foo" for a documentation namespace. Anomie⚔ 12:56, 12 December 2013 (UTC)

That honestly sounds really great. An administrator here suggested to me a master "Documentation:" namespace, which I kinda brushed aside 'cause I never thought of it like that.

Maybe that would be a better way to go about it. − Elecbullet (talk) 17:52, 12 December 2013 (UTC)

Going one step further, I note we already have a "Help" namespace, and both Special:PrefixIndex/Help:Template: and Special:PrefixIndex/Help:Module: are empty. OTOH, Patrick87 does have a good point below about /doc subpages matching with /sandbox and /testcases subpages. Anomie⚔ 19:48, 12 December 2013 (UTC)

Help: was mentioned in Idea Lab. I thought that it would be wise to keep generic, wide-scoped help pages like "Help:Editing" distinguished from specific, definitively page-associated documentation like "Template:Infobox bird/doc", which is why I didn't much like the idea of extending the use of Help. − Elecbullet (talk) 02:52, 14 December 2013 (UTC)

• Support, although the technical details need to be discussed and ironed out first. The namespace could have the same relationship to Template: space as the Template talk: namespace has, or it could be a new Documentation namespace, where identically-named Template, Module, and perhaps MediaWiki pages would automatically tie to -- similar to the way edit notices are handled. There should be a discussion on the pros and cons of each. equazcion → 02:38, 13 Dec 2013 (UTC)

Part of me thinks that a master Documentation namespace with "Documentation:Template:Infobox" as name format would be best. But part of me thinks also that if that were the case, why would it not be at "Talk:Template:Infobox" too?

It seems that everyone seems to agree that the basic idea of segregating template documentation in some more intelligent manner is a good idea - if I interpret his message correctly, even the fellow under "oppose" (but feel free to correct me). If we can move toward that goal in some form or fashion I think it'd be really good. − Elecbullet (talk) 22:15, 13 December 2013 (UTC)

• Support the spirit of the proposal. It would be nice it there were a simple, obvious, 1-click way to add documentation to a template. I'd support the idea of asking the foundationy/experty types for their advice on how to implement an improvement in the workflow. Maybe they'll say namespace, maybe they'll say gadget. But Elecbullet is making a useful point here. --HectorMoffet (talk) 04:49, 2 January 2014 (UTC)

Oppose

• Support the idea behind it, but oppose the proposed implementation. A new namespace for everything (I still have the whole "Draft" NS discussion in mind) will clutter up the UI to a point were it becomes impractical and it will definitely not improve clarity, especially for beginners. A documentation page is a fixed part of a template and should therefore be a subpage of it (I love logical hierarchical structures were appropriate!). The same goes for template sandboxes and everything else linked to the template.

TL;DR: I would favor an implementation similar to WP:Editnotices. – as long as it is technically feasible. {{Documentation}} offers some functionality that would probably need some thought to carry over to the proposed system. Other projects have much more sophisticated documentation templates, e.g. commons:Template:Documentation which automatically creates WP:TemplateData, takes care of translations and much more. All this has to be considered and made available, too, which I currently have no idea how it could be done in a clear and easy way (without recreating the same problem - that this proposal aims to avoid - again) --Patrick87 (talk) 09:20, 12 December 2013 (UTC)

• This seems pointless when there is already a help: namespace for documentation. Graeme Bartlett (talk) 11:25, 14 December 2013 (UTC)

• Help: is very broad when it comes to Wikipedia, and covers mainly How to Write X (where X = article, redirect, portal, etc), How to Join the Education Program, How to Use the Watchlist, How to File a Username Change, in short how to use Wikipedia's front end. This namespace is used to document the code or the backend for the MediaWiki software among other things. (And then the really really far backend of this is on mediawiki.org) Sort of like when Help: was split from Wikipedia: as a namespace. I'll still take Help: into consideration as another place for documentation. TeleComNasSprVen (talk • contribs) 11:51, 14 December 2013 (UTC)

• Oppose we don't need another namespace. Documentation works fine the way it is. This is a solution in search of a problem. -- Ross Hill • Talk • Need Help? • 17:00, 15 December 2013 (UTC)
• Oppose The reasons for this are unconvincing. /doc pages represent only 5% of the template namespace. What is preventing AllPages from being an effective way to search through templates is the fact that we have half a million templates, making an alphabetical list an inefficient way of searching. Not having to use noinclude to transclude the documentation seems like a pretty trivial benefit, when you consider the tens of thousands of pagemoves and edits it will require to implement this. We could already do things like Special:WithoutDocumentation as a database report. You will still need include rules for categories to avoid categorizing the template itself in article categories. Saying that categories on the template page don't apply to the template is confusing and would require even more thousands of edits to create documentation pages for the thousands of templates that are categorized, but undocumented. As I mentioned, only around 5% of templates have a /doc page, but 90% have at least 1 category. Mr.Z-man 18:05, 15 December 2013 (UTC)
• Oppose. The benefits do not even come close to the cost in time; energy; resources; effort; etc. to implement this. GenQuest ^{"Talk to Me"} 18:10, 15 December 2013 (UTC)
• Oppose. This should be implemented properly as a MediaWiki extension, if it is to be done at all. — This, that and the other (talk) 06:31, 16 December 2013 (UTC)

• Well I'd imagined that anything beyond a simple addition of a namespace would require as much. I figured that if the great Wikipedia showed interest in a system, an extension would soon follow. − Elecbullet (talk) 08:21, 16 December 2013 (UTC)

• Oppose. While I could see some advantage to it, it seems to be a huge cost in maintenance and conversion, for very little gain, and it introduces rules that bring in a whole new set of issues with common documentation pages. It ain't broke, so why are we trying to fix it? VanIsaac_{WS Vex}^contribs 06:42, 16 December 2013 (UTC)
• Oppose per Patrick87. I think the idea of moving documentation transclusion out of community edited templates and into something supported by mw is valuable. It likely doesn't need to be a namespace, but we should push toward hand-rolling less of the template infrastructure as time goes on. Protonk (talk) 18:05, 16 December 2013 (UTC)
• Oppose the method, but Support the desire to make it easier to manage template documentation. Is this something that could be done with a template that automatically transcludes the documentation page "Foo Template/doc" within "Foo Template"? I agree that the whole include/noinclude syntax is a bit daunting for moderately experienced article editors who are trying to figure out how templates work and how to improve their function or documentation. I also agree with the proposer that it should be easier to add missing documentation to a template. – Jonesey95 (talk) 16:07, 19 December 2013 (UTC)
• Oppose – per Ross Hill. United States Man (talk) 02:17, 21 December 2013 (UTC)
• Oppose – per above. — MusikAnimal ^talk 00:37, 30 December 2013 (UTC)

Comment

• Some possibly relevant Bugzilla pages:
  • mediazilla:50512
  • mediazilla:51849 (one I sent in myself)
  • mediazilla:54140

− Elecbullet (talk) 06:39, 12 December 2013 (UTC)

• What about Help:Template:Infobox officeholder instead of Template:Infobox officeholder/doc? --MZMcBride (talk) 01:43, 15 December 2013 (UTC)

Similar things have been mentioned in other sections. An outline of proposals put forth:

1. Template:Foo/doc (unchanged, ofc)
2. Template documentation:Foo
3. Documentation:Template:Foo
4. Help:Template:Foo

Of the four, I am afraid that I must see #4 as the least desirable, because I think that the Help: namespace, which is currently reserved for broad subjects such as Help:Editing, does so very well, but would not do well to be mixed with individual-page-specific documentation such as "Template:Infobox/doc". I honestly don't know if I would prefer that over no change at all. − Elecbullet (talk) 06:34, 15 December 2013 (UTC)

• I note there are really two separate issues here: (1) Automatically transcluding documentation (which could do /doc subpages) like in the Module namespace, and (2) a separate namespace for documentation. Anomie⚔ 20:01, 15 December 2013 (UTC)

  When you put it that way, simply having /doc be auto-transcluded without a new namespace really doesn't seem like a terrifically bad option. If we could find a way to move toward that it would be very good. − Elecbullet (talk) 03:49, 23 December 2013 (UTC)

  I think we have a winner for the technical implementation in Anomie's proposal. It seems most people agree that template documentation has room for improvement, but namespace isn't quite the right tool for the job. Auto-transclusion of a /doc subpage looks like the perfect tool for the job. --HectorMoffet (talk) 05:00, 2 January 2014 (UTC)

  I agree, Anomie's proposal is the winner here. We don't need to make a new namespace when we can simply auto-transclude a /doc subpage. On a side note, this solution seems so simple that I have to wonder how we didn't think of it before now. Novusuna ^talk 19:50, 3 January 2014 (UTC)

Brilliant, elegant, acceptable. Motion to close as 'problem solved' --NickPenguin_(contribs) 20:16, 3 January 2014 (UTC)

• Anomie's solution would also help small wikis, as they would get /doc support without all the template infrastructure that is currently required. \o/ John Vandenberg ^(chat) 11:26, 8 January 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.

How to make all the proposals from now on get more attention

Everybody should have the option of setting up their own Wikipedia account in such a way that every time anyone writes a proposal, they get notified. It should also be possible to be possible to make it so that you get notified when ever an article gets created but since there are about 4,000,000 articles, that might be too often so maybe they should only be notified of the ones that get created while using Wikipedia. In addition to that, it should be possible to make it so that you get notified every time somebody edits a talk page of a specific WikiProject so that you can respond to the suggestions and edit many articles really fast to make them better.

Some people are really good at editing all sorts of Wikipedia articles. Just below the link Random article should be another link Random stub. In addition to that, everybody should be able to set up their own account in such a way that when ever anyone adds a stub tag to any article, they get notified by the notification box at the top of the Wikipedia web page they're on. There should also be a method of picking a random article from a specific category or a specific WikiProject so that people who are good at editing articles in that WikiProject can keep on editing more and more articles in that category to make them better. There should also be a method of picking a random uncategorized article so that people will be able to keep on going to random uncategorized articles to add categories to make other people who are good at editing articles in that category find that article more easily. It should even be possible to set up your own account in such a way to get notified every time anything happens in any subset of the subset of the following list that's mathematically possible: An edit to certian labs of community portal, an edit to the Teahouse, an edit to an article or talk page in a specific category or Wikiproject, creation of a new section for any of the above except for an article itself, creation of an article, requesting an article, and creating a previously requested article, creation of one's own requested article, closing of a discussion, an edit to one's own created article or its talk page, and creation of a red link in an article in hope of an article for that link getting created. For anybody with a Wikipedia account, every time any section with a part that was signed by them gets edited, they should automatically get notified. It's such a hassle for me to keep on going back and looking at all the talk pages I ever edited that I never got an answer to and be unable to remember all of them making it so that some answers I got, I might never go back and see because I forgot about that article entirely. Blackbombchu (talk) 04:20, 7 January 2014 (UTC)

You can do pretty much do all this now. Use the "Watchlist". View "Recent Changes" (on the left menu panel) of any page. Type in any combination of letters in the search bar and hit enter for a list of random articles. Review "Categories" for maintenance needs. Join a "Projects" page. These are all in place now. GenQuest ^{"Talk to Me"} 05:41, 7 January 2014 (UTC)

Is it also possible to watch just one section of a talk page? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)

No, it's not; that is a perenially-requested feature, but it has been deemed to technically difficult to implement, given how sections work. Writ Keeper ⚇♔ 20:05, 7 January 2014 (UTC)

@Blackbombchu: You can get part of the way there by setting your Preferences to Group changes by page in recent changes and watchlist and Expand watchlist to show all changes, not just the most recent. You can then see the section header for each edit in your watchlist for pages such as this one, and only come visit when a section you're interested in is added/updated. Hope this helps! GoingBatty (talk) 21:30, 7 January 2014 (UTC)

It looks like it somebody else has already done me the favour of setting up my account in that way because I actually got a notification about an edit to this section of Wikipedia:Village pump (proposals). Blackbombchu (talk) 21:40, 7 January 2014 (UTC)

Not really; you got notified about that because GoingBatty explicitly pinged you, which caused the notification. Not all edits to this section will notify you; only ones which include a link to your userpage (as the template {{ping|Blackbombchu}} that GoingBatty used does) will. Observe: my earlier reply did not generate a notification, but now that I include the ping thusly: @Blackbombchu:, you will get a notification for this. Writ Keeper ⚇♔ 21:46, 7 January 2014 (UTC)

A think it would be really great if Wikipedia also made a change where every time a link from a Wikipedia article to an article somebody's watching gets created, they get notified because the article that the link was created from could be a stub and that would bring a lot of attention to the stub, helping it get improved really fast. In fact, which people had the stub brought to their attention would probably further improve the stub because somebody knowledgeable about the topic of an article is more likely to be knowledgable about an article similar to it than an article on a totally separate topic and articles tend to link other articles that are similar to themselves. Blackbombchu (talk) 03:29, 8 January 2014 (UTC)

This has also already been done. Check the notifications section of your Preferences, you should find an option to be notified of page links. Novusuna ^talk 03:43, 8 January 2014 (UTC)

The "page-linked" Notification only works for pages that you are the original creator of. There's no way to add pages to the list of pages it will ping you about (although there's a request to be able to remove items from the list, somehow). However, see below... –Quiddity (talk) 19:11, 14 January 2014 (UTC)

I was watching the page Wikipedia:Articles for deletion/Google Feedback and an extra bullet has been added to the bottom of that page since the last time I looked at it and I still didn't get a notification of that edit. Blackbombchu (talk) 18:13, 11 January 2014 (UTC)

• You might also want to WP:transclude {{Centralized discussion}} onto your user or user talk page, where you can keep an eye on important discussions. That template is also transcluded at the top of this page. Wbm1058 (talk) 18:19, 7 January 2014 (UTC)
• Also you might want to subscribe to the Wikipedia:Feedback request service or transclude Wikipedia:Dashboard/Requests for comment. And, are you aware that you can watch pages? Alas, there is way more happening here than any one human can keep track of, so you need to pick and choose what you want to pay attention to. I tend to gravitate to things I find that aren't getting much attention from other editors, alas, there's a lot of that. Wbm1058 (talk) 18:42, 7 January 2014 (UTC)

I don't know how to subscribe on Wikipedia. Is it possible to subscribe in such a way that a get notified by the message symbol at the top of any Wikipedia page instead of by email? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)

I encourage you to read the information at Wikipedia:Feedback request service. The idea of this service is to draw in editors for comments in discussions of more specific article-related issues. You can pick and choose which area(s) you want to get notifications in, and how many notices you want to get. A robot randomly selects editors who opted into a topic and posts messages like the following on their talk pages.

Please comment on Talk:Genocide of indigenous peoples

Greetings! You have been randomly selected to receive an invitation to participate in the request for comment on Talk:Genocide of indigenous peoples. Should you wish to respond to the invitation, your contribution to this discussion will be very much appreciated! If in doubt, please see suggestions for responding. If you do not wish to receive these types of notices, please remove your name from Wikipedia:Feedback request service. — RFC bot (talk)

Of course, anytime a message is posted to your talk page you get the notification at the top of any Wikipedia page you're on at the time. Note that I just randomly picked an example from archives. Sorry it happened to be such a depressing topic. I wish that kind of stuff never happened, but it does. Wbm1058 (talk) 20:57, 7 January 2014 (UTC)

@Blackbombchu: The WP:Flow project aims to implement or solve many of the issues you raise - from "subscribing" to specific threads (eg just this thread, rather than the entire Village Pump page), to improving a variety of the other workflows we all use. It's starting off with a basic user-to-user discussion system (which has an initial implementation of automatic-Notifications any time you get replied to), and will be building in complexity over the coming months.

There's some extreme complexity (and varying personal preferences) for how it can/should integrate with watchlists. "Multiple watchlists" have been widely requested for years (see bugzilla:5875 and bugzilla:33888 which link to everything related). Building Flow, Echo (the current/new Notifications system), and Watchlists, so that they harmonize with each other, and work well for all the different types of editor, is going to take a while (slow & steady wins the race), and much experimentation and user-feedback, over the coming months.

However, for random uncategorized pages, see Special:UncategorizedPages. See also the specific WikiProject task pages that you're interested in, via User:Svick/WikiProject cleanup listing, eg Veterinary medicine.

HTH. Quiddity (WMF) (talk) 19:13, 14 January 2014 (UTC)

The Wikipedia Library seeks renewal (please comment)

The Wikipedia Library has grown from a collection of donations to paywalled sources into a broad open research portal for our community. New partnerships have been formed, new pilot programs started, new connections made with our library experts and likeminded institutions. We have tried to bring people together in a new sense of purpose and community about the importance of facilitating research in an open and collaborative way. Here's what we've done so far:

• Increased access to sources: 1500 editors signed up for 3700 free accounts, individually worth over $500,000, with usage increases of those references between 400-600%
• Deep networking: Built relationships with Credo, HighBeam, Questia, JSTOR, Cochrane, LexisNexis, EBSCO, New York Times, and OCLC
• New pilot projects: Started the Wikipedia Visiting Scholar project to empower university-affiliated Wikipedia researchers
• Developed community: Created portal connecting 250 newsletter recipients, 30 library members, 3 volunteer coordinators, and 2 part-time contractors
• Tech scoped: Spec'd out a reference tool for linking to full-text sources and established a basis for OAuth integration
• Broad outreach: Wrote a feature article for Library Journal's The Digital Shift; presenting at the American Library Association annual meeting

We've proposed a 6 month renewal request to continue and deepen this work and would appreciate your comments, concerns, thoughts, questions, or endorsements.

Cheers, Jake Ocaasi ^{t | c} 12:32, 16 January 2014 (UTC)

Wikipedia Visiting Scholar (please apply now)

Want to gain free access to a top research university's library so you can improve Wikipedia articles? Apply to be a Wikipedia Visiting Scholar!. George Mason University's position is now open: Application. Cheers! Ocaasi ^{t | c} 15:53, 18 January 2014 (UTC)

Possible proposal to redirect people searching for Java

While looking at trending articles on the English Wikipedia I noticed that the island of Java tops the list. This isn't the first time I've noticed something like this. You can see the list here. At over 8.5 million views, it far exceeds most articles. If you look down the list to #4, you see that it's Hypertext Transfer Protocol (HTTP).

Is it possible that millions of people are being directed to the wrong article and that what they are really looking for is Java (programming language), which is why it's not surprising that HTTP is #4 on the list.

Although the island of Java has a large population, it is not an English speaking country. Regarding potential English speaking tourists searching for this location, the Java article only mentions the word tourism once so I'm not sure how substantial that industry is. But that still wouldn't explain why that one article would far outweigh any other potential tourist destination with an article on the English Wikipedia. Where are the searches for Java originating from?

Please offer your feedback. Thanks. -- Somedifferentstuff (talk) 17:49, 18 January 2014 (UTC)

• Procedural close: Wrong venue. Jackmcbarn (talk) 17:54, 18 January 2014 (UTC)

The Talk Page at Java has ample evidence that Java as a term starts with the island and that everything else is derivative, and as a consequence hat notes/redirects et al should in fact acknowldge the stubject, not the geographically or terminologically challenged. satusuro 02:34, 19 January 2014 (UTC)

This is not the place to make your argument. There is currently a discussion taking place on the Java talkpage entitled, "Possible proposal to redirect people searching for Java." -- Somedifferentstuff (talk) 03:31, 19 January 2014 (UTC)

Topicon DYK

There's a proposal to roll out {{DYK topicon}}; which has also been nominated for deletion. The proposal is to recognize DYK-recognized content with a topicon, similar to how GA and FA class articles are currently recognized with a pictoral element on the article page. For the discussion, please see WT: Did you know -- 70.50.148.122 (talk) 14:29, 19 January 2014 (UTC)

Moved to Wikipedia talk:Did you know

Allow user preferences in References section

I think we should develop a gadget to allow users to choose the reference format, like in Special:Cite. --Rezonansowy (talk • contribs) 12:50, 11 January 2014 (UTC)

That presumes we have a standard method of formatting references. Citation Style 1 templates are popular, but not pervasive. --  Gadget850 ^talk 15:28, 11 January 2014 (UTC)

Yes, quite unlikely to come about. A better use of time and resources, and of greater service to the readers, would be adding references, or cleaning them up. ~ J. Johnson (JJ) (talk) 21:32, 11 January 2014 (UTC)

Can someone else could comment? Cite format option would be very necessary, please post in this thread comments only about this. --Rezonansowy (talk • contribs) 13:26, 12 January 2014 (UTC)

This is unlikely to happen globally, because we have more than 1 reference format. CS1 is prevalent, but not exclusive. We could only format one of them, like CS1, but that's pretty much forcing users into either using it or readers won't be able to format. We would need to allow to format all styles, but that's impossible. Hand-written references, for example, cannot be "re-styled" autoamtically. —  HELLKNOWZ  ▎TALK 14:13, 12 January 2014 (UTC)

I see, but I mean only these generated by Template:Citation which can be easily done, I think. --Rezonansowy (talk • contribs) 14:36, 15 January 2014 (UTC)

I can't imagine how a template could read a global setting and then apply the formatting. --  Gadget850 ^talk 14:50, 15 January 2014 (UTC)

Yes. Reader-controlled formating only where it "can be easily done" seems to be a null set, perhaps even intrinsically contradictory. Unless Rezonansowy can otherwise enlighten us I would reiterate my initial comment: quite unlikely to come about. ~ J. Johnson (JJ) (talk) 22:06, 20 January 2014 (UTC)

Fully protect closed AFDs, MFDs, RFAs, etc

I previously proposed this at the idea lab, but it has not received any feedback there, so I am bringing it here instead. I am proposing that everything that has either been closed (in the case of deletion discussions and requests for adminship) or archived (as in the case of ANI and other noticeboards, as well as all of the village pumps) be fully protected indefinitely, as there is no reason for anyone to edit them. Also, such discussions are occasionally a target of lots of trolling (e.g. WP:Articles for deletion/Brian Peppers and WP:Articles for deletion/Gay Nigger Association of America), so this would prevent this from happening. Jinkinson talk to me 02:06, 15 January 2014 (UTC)

Oppose Bots and AWBs fix stuff in archives sometimes, and once in a while a template is converted to subst-only. I don't see why semi-protection wouldn't work. Jackmcbarn (talk) 02:16, 15 January 2014 (UTC)

Don't see the need. Very rarely have I seen such a page edited when it shouldn't be and it's usually a mistake of venue that's easily corrected with a reversion and a friendly message. The pages just aren't siginficant targets for vandalism as they aren't read or of interest. Which leaves legitimate edits which too happen rarely but often enough (Deletion Review notices for AfDs, bot actions, fixes of closure errors) that protection would be an inconvenience. Individual pages which are heavy vandalism targets can be individually protected but I see no need for a blanket change.--JohnBlackburne^words_deeds 02:30, 15 January 2014 (UTC)

Oppose: It's not really necessary. Yes, people should not be editing those pages, but nothing problematic will happen if they do (but, in the vast majority of cases, it won't happen at all anyway). If there is a closed AFD and I add my opinion, and nobody notices and reverts it... what? It won't change what happened, the article will still be deleted. Cambalachero (talk) 02:31, 15 January 2014 (UTC)

I don't see the need for blanket protection, but I wonder if {{noindex}}ing all AFDs (as part of a closing template) would reduce the problem. Individual "attractive nuisances" could always be protected as needed. WhatamIdoing (talk) 20:24, 15 January 2014 (UTC)

AfD's are already noindexed because MediaWiki:Robots.txt blocks them. Jackmcbarn (talk) 20:34, 15 January 2014 (UTC)

• How many cases are there where this would have been of use? Looks like a solution without a real problem. Peridon (talk) 15:54, 19 January 2014 (UTC)
• There are many reasons to edit such pages. Incidentally, also user talk archives shouldn't be fully protected but stay open for image rename, template substitution, bypassing redirects before deletion/repurposing and username-change-to-remove-real-name type edits. All of these reasons apply to closed discussions as well. In general, any change from the default "anyone may edit any page" should have a specific reason. —Kusma (t·c) 16:02, 19 January 2014 (UTC)
• Oppose. Too much effort with little benefit. -- King of ♥ ♦ ♣ ♠ 01:10, 20 January 2014 (UTC)

Pending Changes for large amounts of text insertion

Hi,
I understand that this might be hard to do/not desired, but I had the idea that if a user was inserting over a certain number of bytes of text--say, 50,000--that the edit would be treated as if it was to a page that had pending changes level 1 protection applied. I am proposing this because I find it hard to believe that there would be very many non-vandalism edits that fufill these criteria, and that it would be a good check on certain kinds of vandalism. Anybody else think this makes sense?
Thanks!
Cogito-Ergo-Sum (14) (talk) 17:49, 18 January 2014 (UTC)

That's currently not technically feasible. Jackmcbarn (talk) 17:53, 18 January 2014 (UTC)

Thanks! Sorry for wasting your time!Cogito-Ergo-Sum (14) (talk) 18:20, 18 January 2014 (UTC)

You could probably get an WP:Edit filter or tag that made a list of such edits, so that they could be checked by people who patrol Special:RecentChanges. That might be almost as good. WhatamIdoing (talk) 20:06, 21 January 2014 (UTC)

Have WikiProjects give a list of all articles that are part of that WikiProject

That way, people who specialize in a specific WikiProject will be able to find an article that's part of that WikiProject that they otherwise wouldn't have been able to find and either improve it or watch that article to notice when somebody writes on the talk page of that article and then from from the talk page, judge how to improve the article. The article Linear induction motor got so little attention that I'm the only person who ever wrote on its talk page and it probably would have gained alot more attention and become a better article faster if the WikiProject Engineering had given a list of all articles that are part of that project. Blackbombchu (talk) 03:28, 20 January 2014 (UTC)

See Category:WikiProject Engineering articles, and equivalent categories for other WikiProjects. bd2412 T 03:39, 20 January 2014 (UTC)

That's already done. The WikiProject Engineering tag on Talk:Linear induction motor was placed in 2012. It adds three categories for the WikiProject. Just click the category links at the bottom. PrimeHunter (talk) 03:44, 20 January 2014 (UTC)

You can also get the whole list at http://tools.wmflabs.org/enwp10/cgi-bin/list2.fcgi?run=yes&projecta=Medicine&limit=250&offset=1 (just change the name of the project). WhatamIdoing (talk) 20:10, 21 January 2014 (UTC)

Random Article on Google Android App

I use the Android app and thought it would be nice to see a random page feature on it Thetiesthatbind (talk) 09:23, 21 January 2014 (UTC)

Handling new article submissions

Please discuss at User:Gryllida/Handling new article submissions; I've placed the thing there, to evade archival bots. Thanks. --Gryllida 09:46, 21 January 2014 (UTC)

Substituting {{unsigned}} templates

Hey folks. I recently stumbled across the fact that there are literally thousands of un-substituted {{unsigned}}-templates across many namespaces. I've been thinking about BRFA-ing for that, as I've always been interested in doing some mass bot work. Now, I realize that, given that it hasn't been done yet, it is probably not "extremely needed". I'm also aware that we're not supposed to worry about performance. But it certainly couldn't hurt, could it? What to you guys think? Cheers. ~ | twsx | ^talk_cont | ~ 12:36, 21 January 2014 (UTC)

• Anomie already has a subst bot... You could gain a consensus and just add it to the list of templates AnomieBOT is supposed to subst. Good luck! Technical 13 (talk) 12:59, 21 January 2014 (UTC)

Per Category:Wikipedia templates to be automatically substituted, it appears you could add {{substituted|auto=yes}} to Template:Unsigned to get AnomieBot to do the substituting. Looks like Template:Unsigned/doc already says the template should always be substituted. (Maybe someone should see which documentation pages contain {{subst only}}, and check that the associated templates have {{substituted}}.) GoingBatty (talk) 02:52, 22 January 2014 (UTC)

Increasing visibility of full protection

Are readers already aware of full protection on an article? We have "view source" and a protection lock icon/banner; visibility comes in mind. For indefinitely fully-protected articles, shall we mostly (if not always) use banner ("big") or a small lock (small top icon)? What about treating temporarily fully-protected articles? --George Ho (talk) 07:45, 17 January 2014 (UTC)

• It's not a maintenance issue, so a banner is not appropriate. There's already an edit notice, so there's really nothing else to do. Is there a specific problem you are having? VanIsaac_{WS Vex}^contribs 07:49, 17 January 2014 (UTC)

It's just.... going to find a page to copy-and-paste {{edit protected}}... how else can we immediately notify the editors without finding the template if we can't use big banner? --George Ho (talk) 08:05, 17 January 2014 (UTC)

• I don't understand why readers would need to be aware that an article is protected. What are you trying to achieve? Do you have some specific indefinitely protected articles in mind? - Pointillist (talk) 10:19, 17 January 2014 (UTC)

Perhaps you mean editors rather than "readers"? - Pointillist (talk) 21:44, 17 January 2014 (UTC)

• No offense, but it seems like an unnecessary waste. If they miss the lock and try to edit it, they can't. If they don't need to edit it, does it really make a difference? Supernerd11 (talk) 15:14, 17 January 2014 (UTC)

I realized that the way to edit is clicking "View Source" and then a button to request edit. Sounds about right? George Ho (talk) 20:28, 17 January 2014 (UTC)

• When the user clicks view source, there is a huge banner there George with very clear instructions and a big "request an edit" button. I suppose, it might be condusive to encourage editing by changing to color of that button to blue or green (to offset it a bit, the gray does kind of blend in for those with color blindness issues). The only other thing that I could think of to do, which would be a bit of work to create, is make a userscript/gadget that allows non-sysops to edit in the "view source" window, show preview, show changes, but instead of a save page button, it could be changed to request edit. The script would then create a very accurate "please change X to Y" style edit request and apply the request properly on the talk page. This is a script that I might be interested in trying to write if no-one beats me to it. I'll have to get back to you on that. Technical 13 (talk) 21:03, 17 January 2014 (UTC)

• Simple solution would be to leave a note at the "Page notice" link whenever a page has been protected. Then all editors would need to do is get into the habit of checking to see if it is still a red link, then reading the notice lft there. Ideally, this would then allow other editors & admins to determine if a page protection is still appropriate. -- llywrch (talk) 20:46, 23 January 2014 (UTC)

RfC: Should article feedback be restricted to articles?

Please comment at Wikipedia talk:Article Feedback Tool/Version 5#RfC: Should article feedback be restricted to articles?. Jackmcbarn (talk) 20:30, 24 January 2014 (UTC)

Integrating QR Code with Each article and with Wikipedia Android app

There should be some simple way one can count/track/manage number of articles a person reads (over a period of time). This can be done with Wikipedia App with great ease. How nice if Wikipedia app could be used as a personal Wikipedia diary! To achieve this QR code can do the trick. Consider there is a link saying on every article - "Show QR Code for this article" which will show a Dialog box with QR code for link. Mobile devices and apps are ubiquitous these days, so one can take snap of qr code while the are reading the article and get the link saved in their personal library as articles visited/articles read, arrange them in user created folders, download them for later reading. swarnkar rajesh kumar r

I'll bite. Why not just bookmark the URL? The only use-case I see for this is someone with a mobile device handy who is reading a paper copy of the article. Hardly a core demographic. That said, if there is a real use-case, the permalinked version ID is already generated in the printfooter, so morphing that to make a QR code shouldn't be too tough. There are MIT-licensed javascript implementations available, e.g. this on github, which generate the QR code in the browser. LeadSongDog come howl! 22:26, 17 January 2014 (UTC)

Agreed. Thanks for the input. swarnkar rajesh kumar r

Another possible use would be if someone starts reading an article on a PC, has to go somewhere, and wants to open the page on a mobile to finish with it. —rybec 12:27, 25 January 2014 (UTC)

A Modest Proposal

Instead of the current adrenaline-prompting message --

Edit conflict!!!

-- how about if we change to something less martial. Here are some suggestions:

Too many cooks spoil the broth!

There seems to a minor disagreement here

No doubt they didn't mean it...

Oh! Bad luck!

Remember: Two heads are better than one.

Rejoice! Another editor is doing you the compliment of choosing to help Wikipedia in the same place you are!

EEng (talk) 19:40, 20 January 2014 (UTC)

Tough crowd, I guess. EEng (talk) 04:46, 22 January 2014 (UTC)

I think that the current version is better. עוד מישהו Od Mishehu 06:23, 28 January 2014 (UTC)

Mentioned time in my timezone

Does anyone know of an existing template, where if you give in a particular time and date, and the template would automatically converts that to the timezone set in Special:Preferences (for logged-in users) or from the reader's IP region (for IPs)? For example (I'm editing from Sri Lanka): The hypothetical template {{Template|2014|01|26|17|30|PST}} would show: 26 January 2014 17:30 PST (27 January 2014 06:30 Sri Lanka Time). Further, the dating format could also be made to fetch from the user's preferences.

Does anyone know if this exists? If not, can we get a few template experts and work on creating this? I'm strongly towards expanding an existing template ({{Time}}?) rather than creating yet another one... Rehman 04:58, 26 January 2014 (UTC)

Try the following that I got from another user, just adjust hour differential to Sri Lanka (mine is -6):

<!--beginclock--><center> <div style="padding:10px; text-align: justify;"> <div style="float: left; border:solid #aaa 1px; margin: 1px;"> {| cellspacing="0" style="width: 238px; background: #333;" | style="width: 45px; height: 45px; background: white; text-align: center; font-size: {{{5|{{{id-s|14}}}}}}pt; color: {{{id-fc|black}}};" |[[Image:Crystal Clear app clock.svg|42px]] | style="font-size: {{{info-s|8}}}pt; padding: 4pt; line-height: 1.25em; color: {{{info-fc|white}}};" | It is approximately '''{{#time:g:i A|{{CURRENTHOUR}}:{{ {{{|safesubst:}}}#time:i}} <includeonly>{{{1}}}</includeonly><noinclude>-6</noinclude> hours}}''' where this user lives. |}</div> <noinclude><br> <!--endclock--><br></center>

Goodluck! GenQuest ^{"Talk to Me"} 06:40, 26 January 2014 (UTC)

The Wikipedia Adventure, new page patrol

Hi folks! For the past 18 months we've been building an interactive guided tour for new editors called The Wikipedia Adventure (TWA). We just finished our beta test and had some very nice results, both quantitatively and qualitatively.

One issue has come up and I'd like some guidance. The TWA game takes place in an editor's userspace, at user and user talk subpages. This allows a modicum of verisimilitude--it looks and feels like Wikipedia--without actually burdening articles with test edits and vandalism. So that's good.

The challenge is that these new userspace pages are still patrolled by some hardworking editors, and they have asked if it would be possible to mark those pages as autopatrolled.

These pages are generally created using a mediawiki guided tour that pushes an edit through the mediawiki API. In other words, it's the editor themselves making an edit, but the TWA guided tours engine actually puts it on Wikipedia (it shows up in the page history as though the editor made it themselves, but is edit-summary tagged as part of TWA).

After these pages are created, the editor is asked to interact with and improve them, as part of the learning process. So, here's my question: would it be appropriate to mark only those userpages created automatically through TWA as autopatrolled, and if so, is there a way to do that using the API:EDIT?

• The Wikipedia Adventure
• Phase 1 impact metrics and results
• Mission 1 (the mediawiki code including the API)

Cheers! Ocaasi ^{t | c} 14:13, 26 January 2014 (UTC)

Interesting question. I'm not sure that can be done through the API because then anyone could edit through the API and have all their edits marked as patrolled and it would be a hole in the system. I would think the better possibility would be for an edit filter (the one that tags them as TWA edits in the first place might be good, if there is one as your introduction to the question implies to me) to mark those edits as patrolled. Technical 13 (talk) 16:21, 26 January 2014 (UTC)

Hey Technical 13, thanks for the feedback. The code lives in the mediawiki namespace and only admins can access it. Not sure if that leaves a more secure API option. I like your edit filter idea, too. I'd want to autopatroll any new page created with the edit summary:

New Message (simulated automatically as part of The Wikipedia Adventure)

Any idea how I go about this? Cheers, Ocaasi ^{t | c} 17:01, 27 January 2014 (UTC)

• Where the code for this tour lives would have no bearing on the ability for someone to maliciously use the API in other ways. We can ping legoktm as I know he is an edit filter creator/maintainer, and I'll look into the docs and see what might be needed to pull this off (it may require a patch to the edit filter extension to make it work) but I see this as likely the best option here. Technical 13 (talk) 18:09, 27 January 2014 (UTC)

Strike UKrViki and support Ukraine

Dear Colleagues English Wikipedia, I am a representative Ukrainian Wikipedia. I invite you to join the strike UkrViki (as did Georgian colleagues) in connection with the recent developments in Ukraine.Jphwra (talk) 09:09, 27 January 2014 (UTC)

I support adding a black banner to the top. --NaBUru38 (talk) 18:57, 28 January 2014 (UTC)

This says that the 721-VII law has been repealed. The New York Times [1] and NBC News [2] reported about it without mentioning the specific law. —rybec 21:21, 28 January 2014 (UTC)

Make in possible to show a preview in the Teahouse

I don't fully know the Wikipedia code and I want to be able to make sure what I'm asking at the Teahouse is exactly the way I want even if the question includes complex stuff like a hyperlink to a section of another Wikipedia page or a mathematical expression. Blackbombchu (talk) 01:18, 29 January 2014 (UTC)

That's a good idea; it should be doable. Writ Keeper ⚇♔ 01:38, 29 January 2014 (UTC)

One-click install for userscripts

Hi folks, I know we have lots of neat userscripts in our community but they are somewhat foreign for new editors to use. I built one that has a 1-click install feature using mw:Guided tours and the mw:API:EDIT. It requires a script in the English Wikipedia mediawiki namespace which only admins can access. I could make it pretty easy to adapt this method for any/all userscripts. Would that be appropriate? Would there be interest in setting up such a page?

Example: Wikipedia:FindDPLA

Thoughts? Ocaasi ^{t | c} 12:21, 29 January 2014 (UTC)

This might be problematic from a security standpoint. Currently, one has to go through a mildly thought-requiring process, together with receiving a big red warning about what malicious code might do. If something allows users to just start turning on and off loads of scripts (that haven't been checked by admins prior to gadgetizing), well... --Yair rand (talk) 13:37, 29 January 2014 (UTC)

Because the scripts are in mediawiki namespace, an admin would have to approve each one, so there'd be oversight. Ocaasi ^{t | c} 14:56, 29 January 2014 (UTC)

• How does your script differ from Equazcion's User:Equazcion/ScriptInstaller script? Technical 13 (talk) 14:46, 29 January 2014 (UTC)

  Well, for one, it doesn't require installing a userscript to work :) !! That's kinda the whole point, avoiding people having to copy and paste code places they don't understand. Ocaasi ^{t | c} 14:56, 29 January 2014 (UTC)

• That doesn't really explain how it technically differs. If Equazcion's script was turned into an on by default gadget, it also wouldn't require installing a userscript to work. So, I ask again, how does it technically differ as to what the end result of what it does goes? Technical 13 (talk) 15:45, 29 January 2014 (UTC)

On a related point, I'd like a one-click link to change prefs. Then you could say, "I think you've encountered that bug with 'Near this page' Beta feature. Click here to turn it off and see if that helps" instead of saying, go to prefs, switch tabs, find this item, tick it, don't forget to save.... WhatamIdoing (talk) 17:11, 29 January 2014 (UTC)

Good work, Ocaasi. There are lots of security issues and other details to sort out, but I feel like wikipedia needs a lot more '1-click" options. The "Add this line to your css/js file" method just isn't realistic for our userbase. --HectorMoffet (talk) 20:59, 30 January 2014 (UTC)

CHU requests from users who have RfA page(s), etc.

You are invited to join the discussion at Wikipedia talk:Changing username #Username requests from users who have RfA page(s), etc.. -- Trevj (talk · contribs) 13:38, 30 January 2014 (UTC)Template:Z48

Userpage deletion permission

I propose that a new very minor permission be created, either separately or as part of one of the existing permissions, to allow experienced and trusted editors to delete and undelete their own userpage and subpages only. It would involve about the same level of trust as given to users with autopatrolled rights, and could possibly be included as part of autopatrolled rights. I would expect there to be a minimum thrsehold, perhaps requiring 1,000 edits, but I'm open to suggestions for a minimum limit.

This permission would also help reduce the workload of administrators, albeit miniscually, so that editors would not have to request deletion through speedy criteria WP:U1, although I've no way of finding out how many U1 requests are made in any timeframe. As with U1 currently, I wouldn't envisage it being extended to user talkpages (unless the user was the only contributor to the talkpage) and obviously blocked userpages would not be deletable in this way. Admins would still be able to undelete such pages if necessary, and obviously the permission could be withdrawn for bad behaviour. Note also that I'm not proposing getting rid of speedy criteria U1. Green Giant (talk) 14:49, 26 January 2014 (UTC)

A snag is that this would provide an illicit means of deletion. You could move a page to your userspace and then delete it. I suspect this could escape scrutiny. The remaining redirect would likely get speedy-deleted as WP:CSD#G8 or WP:CSD#R2. Perhaps there could be technical ways of blocking such deletions. Thincat (talk) 15:20, 26 January 2014 (UTC)

U1s are not a significant part of admin workload. —Kusma (t·c) 15:25, 26 January 2014 (UTC)

• Thincat, I had considered that and that's why it would only be granted in the same way as the other permissions are. I think it could be coded in such a way that deleting pages from cross-namespace moves would still need U1.
• Kusma, I suspected that U1 isn't a major group of requests but it is a trivial task that doesn't really need two people to perform it i.e. a requesting editor and an admin. It occurred to me recently when I wanted to delete one of my subpages and thought it would be so much simpler if I could do it myself in two clicks i.e. select a tab and click OK. Instead I had to click the CSD tab, click on U1, click on Submit Query and then wait for an admin to perform the task. I think the admins have more important tasks than this.

• I've never waited more than a few minutes for a U1 to be granted for me. I suppose there could be an adminbot to delete U1's if there were no moves involved. Honestly though, I believe this is a solution in search of a problem. Technical 13 (talk) 23:59, 26 January 2014 (UTC)

• Technical 13, to be honest, the speed of the response is not the problem. Everyones experience is going to be different, and personally I've had some responses for U1 within minutes and other times it's taken a couple of hours. However the main reason for proposing this was that it doesn't make sense to have two people to carry out such a trivial request. Even a bot wouldn't really make much difference, because it would just be simpler to be able to do it with two clicks. Green Giant (talk) 09:31, 27 January 2014 (UTC)

I'd support a bot to handle U1 cases which don't have moves in their history (trivial enough to check this), but I don't see the need to create this new user right (which would also require changing the software, since the current ine doesn't distinguish between deletiung user pages and other pages). עוד מישהו Od Mishehu 06:20, 28 January 2014 (UTC)

This is a brilliant solution. If you're the only contributor, you shouldn't have to ask permission to delete content you're done with. I appreciate the speedy response admins give, but it's plainly a waste of their time. Three lines of code ought to do it-- we don't need to waste a human mind on this. --HectorMoffet (talk)

• I agree with Kusma. I do a good many deletions from CAT:CSD, and U1s are not a significant part of the work. There is not enough benefit from this proposal to make software changes or creation of new user-rights worthwhile. JohnCD (talk) 11:41, 28 January 2014 (UTC)

• Seriously overdue software feature. As a general rule, trusted editors should have a 1-click path to deletion of their own sandboxes. It's a small matter, but U1 is a job for a script, not a human being, and definitely not worth the attention of an especially valuable human being like an admin. --HectorMoffet (talk) 11:49, 28 January 2014 (UTC)

• JohnCD, the major benefit would be to trusted editors, not to admins, because this feature would make it just that bit easier to start an article in the userspace and be able to delete it when necessary, e.g. the article was moved into article space or you've realised that perhaps there just aren't enough sources to make a worthwhile article. Right now, I generally avoid creating subpages, precisely because it is easier to delete a document on my desktop than it is to delete a subpage. If, as you say, U1's are not a significant portion of the admins work, having such a feature would encourage more editors to work on articles in userspace instead of doing it offline. As for a bot, Od Mishehu, it is not much different to having an admin do the deletion, because you would still need somebody to operate the bot; as HectorMoffet says, it is something a script could do. Ultimately it would help the project because we already have trust-dependent permissions like filemovers, reviewers, autoreviewers and rollbackers, and having this small but useful feature would let editors feel that they are trusted to delete their own userpages and subpages. Green Giant (talk) 12:44, 28 January 2014 (UTC)

A bot could run completely automated and would be no work beyond writing it in the first place, which would probably be far less work than proposing and implementing a software change. I think the issue Thincat mentioned would be a major impediment, if not a complete blocker, to adding support for this in the MediaWiki software. Mr.Z-man 15:20, 28 January 2014 (UTC)

I think a bot would have the same effect as a Mediawiki change, and would probably be alot easier to implement. The important thing is that we don't send a highly skilled human to manually execute a very simple "if-then" statement. --HectorMoffet (talk) 01:49, 29 January 2014 (UTC)

• Mr.Z-Man, the issue of moved articles is easily dealt with by checking the move log and by the fact that most articles are on someone's watchlist. Although I would prefer a simple script, I'd accept a bot too. Green Giant (talk) 03:21, 30 January 2014 (UTC)

Checking the move log will not always give you the correct result. Say Article is moved to User:Example/A, which is then moved to User:Example/B, then User:Example/A is re-purposed for something else. Just checking the move log would prevent you from deleting User:Example/A, which should be allowed, but might allow deleting User:Example/B (because in the move log, it was just a move from one subpage to another within the same userspace), which shouldn't be allowed. To really be foolproof without being overly conservative, it would have to scan through the history and potentially follow the move log across multiple pages, which is probably too inefficient to build into the software. Mr.Z-man 04:12, 30 January 2014 (UTC)

• Scanning the history is something done by several tools at the moment, such as the edit counters, the contribution checker and the "DYKChecker". Certainly it would take time to check a history with hundreds of edits but articles that have been moved recently to user space would still indicate in the history that a cross-namespace move had been done. Malicious users would probably try to delete a moved article almost immediately, so how much scanning would be needed? It wouldn't be difficult to code the script or bot to refuse to delete a recently moved cross-namspace article. It wouldn't be long before other users notice the move in their watchlist and raise the issue. The malicious page moves of the past are much more difficult to do these days, when high-risk articles have pagemove protection and numerous watchers. Bear in mind that this feature wouldn't be automatically available to everyone, just trusted editors via WP:PERM, a process that has resulted in 3,000 autopatrollers, 6,000 reviewers, and 5,000 rollbackers, although obviously some editors have multiple permissions. It would take a really dedicated vandal to make hundreds of good edits including significant userpage edits, just so they could get any of these permissions and then cause havoc. The vast majority of vandals simply don't have that kind of patience. Anyone misusing the privilege could easily have it removed and damage can always be repaired, because the deletion permission would not mean that admins couldn't undelete something if necessary. Green Giant (talk) 06:14, 30 January 2014 (UTC)

Yes, and all of those tools are separate software, like a bot. I didn't say it was impossible, just not feasible to do in MediaWiki where performance is more critical. You keep mentioning a "script", but I'm not really sure what you mean by that. If you mean something the user uses in their browser like Twinkle or Popups, that would require a change to the MediaWiki software to support it and "close enough" isn't good enough for a feature in the core software. Dedicated vandals and sockpuppeteers have managed to get adminship a couple times in the past, so if we add a new, much easier way to get a limited subset of admin tools, with a known security hole that would allow them to delete almost anything, you can bet some people would start working right away. You mention another thing that is potentially problematic, which is that any mistakes or misuse would require an admin to undo. This would actually be a fairly significant departure from how things have generally worked, which is that any action can be easily undone by any user with the same level of permissions. Of course, giving users the ability to undelete content in their userspace could lead to even more problems, as it would allow them to do history merges, which can be very tedious to undo. Mr.Z-man 15:35, 30 January 2014 (UTC)

• Had Sublimeharmony (talk · contribs) had this permission, I might not have noticed that there was something unusual about User:Sublimeharmony/sandbox11. —rybec 07:27, 30 January 2014 (UTC)

• How would Sublimeharmony have gained this permission, because it wouldn't have come automatically with a new account? That group of puppets is a good example of malicious editing, but look at their method of operating. The sandbox was in an account with just a few hundred edits. Requesting the proposed permission would have mean't exposing their activities because an admin would definitely have checked their contribution history and noticed that they had edited almost exclusively in the userspace. The vast majority of the other accounts only made sure that they got autoconfirmed status and very few of them made more than a hundred edits. Would it have helped them if they had had the proposed permission, when their entire work seems to have depended on having copies of their articles stored in the history of Sublimeharmony's sandbox separated by blankings? Hypothetically, Sublimeharmony could have deleted the sandbox loads of times, but what good would that have done for their cause because they needed to have the code ready to copy and modify? There is no reason that we couldn't have a flag being raised if a user deletes and undeletes a page several times, alerting admins to this activity. Green Giant (talk) 10:11, 30 January 2014 (UTC)

So you envisage that this permission wouldn't be granted by the software, like (or as part of) autoconfirmed status, but instead an editor would have to request it, after which an administrator would review the account's history, and a few hundred edits wouldn't be enough to justify having it? It might take more effort to do such a review than to handle several deletion requests. Also, what if this were more like WP:G7? Then one could delete pages in one's own user-space--or anywhere--so long as no one else contributed to them. That seems less questionable than deleting others' writing that happens to be in one's user-space. —rybec 21:49, 30 January 2014 (UTC)

Oh no, definitely not granted by the software. It would be approved by an admin in the same way as the other trust-based permissions on WP:PERM. For example, autopatrolled requires 50 articles to have been created by the user before being given that permission, whilst template editor is even more stringent, generally requiring users to have been registered at least 1 year, made at least 1,000 edits including 150 to templates, no behaviour blocks or 3RR for the previous 6 months. I was thinking along similar lines. As for the G7 suggestion, I would be equally supportive of that, but I was hestitant about mentioning that because it extends to pretty much anything a user might have created. Green Giant (talk) 15:57, 31 January 2014 (UTC)

There are, on occasion, instances where a U1 deletion request might not be granted by the reviewing admin; for example, a user subpage that contains a widely-transcluded message or userbox, a user's talkpage (though I think I'm right in assuming that this is treated as a separate namespace, and could therefore be excluded from this proposal), or a page which is being used as evidence in some sort of investigation. U1 deletions are a privilege, not a right (remember that userspace still technically belongs to the community), and so having an admin cast an eye over them before removing them is only appropriate. Speaking as someone who does a fair number of these deletions, I can honestly say that the work involved is usually minimal; this solution isn't going to suddenly free up hours of admin time. Besides, they're about the only deletions we ever actually get thanked for... Yunshui 雲‍水 15:56, 30 January 2014 (UTC)

• Good points Yunshui, that would have to be added as a check in any bot written (as this is the way this seems to be leaning). There would have to be no transclusions or protections on the page (I'm assuming, of course, if the page was evidence in an investigation that it would be protected in some way, perhaps cascading protection from the investigation?). I think the proposal is less about freeing up admin time (as valuable as that is) and more about expediting the process to be able to "re-use" sandboxes. To that I say, subpages are cheap, make a new one for each draft (shameless self promo: there are even templates that you can use to keep track of them and make the process easier like {{User:Technical 13/SandBox/DraftHeader}} (which is almost ready to move into template space for all to use)). Technical 13 (talk) 16:49, 30 January 2014 (UTC)

Y Shamelessness noted. Template added to List Of Things To Try Out. As for cheapness of subpages, very true, but pretty much everything here is done on the cheap → volunteers for editing, sainted volunteers for janitorial work, bots for tedious edits, begging bowls regularly sent out by the WMF... Green Giant (talk) 15:57, 31 January 2014 (UTC)

• Indeed the U1 cases are among the easiest to handle. The admin time savings would be negligible. Another permission for hat collectors would just create more red tape and complexity, not lessen administrative burdens. We could unbundle and grant the entire delete/undelete machinery to trusted users who could then process deletions for others, not just limited to one namespace or their own user area. Just a part of admin's mop, but mainly without protection and block tools. jni ^(delete)_{...just not interested} 20:35, 30 January 2014 (UTC)

• Yunshui, I agree that examples such as widely transcluded templates and user talkpages shouldn't come under this proposal. I'm all for admins casting their eyes about the place, which is why I think it should be granted by admins in a similar way to autopatrolled and rollbacker. Jni, I have been thinking about suggesting that admins could have helpers somewhat like the bureaucrats have their clerks for account renaming. As for red tape and complexity, I don't think the project will ever become simpler; indeed I foresee a great expansion in the future when the noble knight Sir Jimbo, returns from his holy quest, to fight the dragons of ignorance and the ogres of vandalism. :) Green Giant (talk) 15:57, 31 January 2014 (UTC)

User contributions and list size

How about disabling the link denoting currently selected list size on Special:Contributions? Currently, newest (ordering) and newer 100 (pagination) are disabled depending on the currently selected options and position within the contributions list, for example; disabling the currently selected list size would be like a cherry on top.

Hope it makes sense. Thoughts? — Dsimic (talk | contribs) 00:29, 31 January 2014 (UTC)

Any thoughts? — Dsimic (talk | contribs) 02:32, 3 February 2014 (UTC)

Limit creation of talk pages to logged-in accounts

Given that only logged-in users can create articles in the article namespace, I don't see exactly why we allow IP addresses to create any page in the Talk: namespace they want, and I think that it would be more consistent if we only allowed logged-in users to create either articles or talk pages. Jinkinson talk to me 16:57, 30 January 2014 (UTC)

A solution looking for a problem IMO. Is there a issue with IPs mass creating talk pages without a article page? KonveyorBelt 17:10, 30 January 2014 (UTC)

• This limit would prevent anons from requesting edits on talk pages if the talk page didn't exist. Against the spirit of the 5 pillars... Technical 13 (talk) 17:13, 30 January 2014 (UTC)
• I can see the point, and we do get occasional flurries of fakearticles posted in talk by IPs. I don't think it's enough of a problem to require blocking the space for IPs, however. Peridon (talk) 17:12, 3 February 2014 (UTC)
• What would work, IMO, is preventing IPs from creating talk pages which neither have an asociated non-talk page, nor are subpages of existing talk pages. However, I don't think it's enough of a problem to bother with. עוד מישהו Od Mishehu 04:31, 6 February 2014 (UTC)

Talk pages without an associated article are already speedy deletable under WP:G8, so it's moot anyway. VanIsaac_{WS Vex}^contribs 06:48, 6 February 2014 (UTC)

Proposal to move stats.grok.se to Wikimedia Labs

Per the discussions on Henrik's talk page, it appears as though the page periodically going down is bugging people from many different wikis. Due to the fact that we are relying on one person to be our fail point, are people up to discuss moving the site's available data and start recording this information on Labs? I know that we would be leaving a lot of the material behind, but right now Henrik hasn't edited in over three months, so if he continues with this, the complaints will continue to land on deaf ears, and we risk losing more data. When or if he returns, we could move any remaining information over, and clean up any remaining lose ends. What do others think, as I would love to have something more stable than a page that is going down more than once a week. Kevin Rutherford (talk) 01:29, 3 February 2014 (UTC)

Support: Totally makes sense, and to me it's unclear why it hasn't been part of the Labs since day one. — Dsimic (talk | contribs) 02:31, 3 February 2014 (UTC)

The source code for it is freely available, so if anyone wants to set it up on labs, they're free to do so, regardless of the outcome of this proposal. Unless you're proposing the WMF do it, in which case, get in line. Note that there already is a tool on labs that already replicates most, if not all, of the functionality - https://tools.wmflabs.org/wikiviewstats/ Mr.Z-man 03:35, 3 February 2014 (UTC)

It appears to do that, and more. I guess we could just start unlinking the stats page on all of the major sites, but I am unsure of how to do it for the DYK template. Kevin Rutherford (talk) 15:13, 3 February 2014 (UTC)

diffs in signatures

Proposal : Make the timestamp portion of the signature link to a diff of the post (or a highly filtered subset of the history page for the relevant time period?). This would break down for posts which are updated retroactively, but would make linking to a particular post much easier. Gaijin42 (talk) 20:01, 3 February 2014 (UTC)

Live feed for submissions at Articles for Creation

A proposal has been made to create a Live Feed to enhance the processing of Articles for Creation and Drafts. See Wikipedia:WikiProject Articles for creation/RfC to create a 'Special:NewDraftsFeed' system. Kudpung กุดผึ้ง (talk) 05:18, 4 February 2014 (UTC)

Wikimedia Commons wikilinked in templates

I noticed Wikispecies is already wikilinked in its sister Wikimedia project template, but Wikimedia Commons is not. I thought it was non-controversial to suggest this be fixed, but it was deemed I need consensus for it.

Examples on the RHS.

Looking at all the templates that use Sister (you need to manually change to only see Templates) I see it wikilinking the sister site is somewhat inconsistent in general.

Mark Hurd (talk) 01:53, 2 February 2014 (UTC)

• Support I see no reason why we shouldn't link to this. Also, I can make the edit if consensus is established, as I have the rights to edit that template. Kevin Rutherford (talk) 01:33, 3 February 2014 (UTC)
• Controversial? No way. Feel free to invoke WP:IAR. OhanaUnited^{Talk page} 04:44, 7 February 2014 (UTC)
• Support linking all of the sister projects' articles from the template. This is helpful to readers, who might be unfamiliar with them.
  WP:IAR seems irrelevant, as I'm not aware of any rule from which such links would deviate. —David Levy 05:01, 7 February 2014 (UTC)

• Just waiting for an admin to carry it out since that template is apparently so important it is cascade protected... — {{U|Technical 13}} ^{(t • e • c)} 05:07, 7 February 2014 (UTC)

• From a user interface standpoint, I don't know if I agree with the idea. The wikilink to information about commons will end up having greater prominence than the link to the commons search that is the primary purpose of the template. I've provided a sandboxed version to the side. Monty₈₄₅ 05:19, 7 February 2014 (UTC)

• Personally, the reason I initially closed the request saying there should be a consensus is because I think that it might be confusing to readers to have extra wikilinks not pertaining to the topic. I wouldn't mind if all of the "project" words were unlinked and instead the icons were the links. However, it seemed as it often does I was alone in thinking this based on the responses above, so I reactived the request. That's really all I've got to say about that. — {{U|Technical 13}} ^{(t • e • c)} 07:22, 7 February 2014 (UTC)

• Not helpful It's overlinking and the result may mislead a reader. Look at the "Cats" sample box above—I would expect the "Cats" link to go to some article telling me what a cat is (and would not click it), and would tend to click the first link. Johnuniq (talk) 22:50, 7 February 2014 (UTC)

• Oppose The extra link just causes confusion about where to click. These don't link the article either: {{Wikibooks}}, {{Wikiquote}}, {{Wikiversity}}, {{Wikivoyage}}, {{Wikinews}}. But {{Wikidata}} does. {{Wikisource}} links but {{Wikisourcecat}} doesn't. We are not completely consistent but linking seems like the exception and not the norm. PrimeHunter (talk) 00:31, 8 February 2014 (UTC)

Do you think Wikipedia/Wikisource should have a Kindle (.mobi) putout?

(also posted on Wikisource) Hi! I am a Kindle user. I use Kindle in any my free time available because of its convince and feel. It uses e-ink, the look of which is very close to ordinary ink on paper. Sometimes, I use it to read some long Wikipedia article, but I have to convert it manually because the clumsy PDF format works poorly on my kindle, and I believe it's also works badly on other portable devices when compared to .mobi. If Wikimedia projects support this format natively, I think it will be very continent for Kindle and other e-readers users like me, and promote wiki content to be read by users in a further depth. What is your opinion?--The Master (talk) 15:46, 3 February 2014 (UTC)

Unfortunately, the MOBI file format is not an open standard. In general, wikimedia projects refrain from supporting closed and proprietary standards, since they can require licensing and expose the foundation to copyright and patent claims. The Kindle does not support the newer PDF reflow feature, which means that even if Wikipedia produces PDF files that are technically able to be displayed easily on e-readers, the Kindle still won't display them correctly. The way to do this might be to instead support the open EPUB standard for wikipedia output, which can easily be converted to many standards, including MOBI. VanIsaac_{WS Vex}^contribs 16:30, 3 February 2014 (UTC)

Thank you for replying. But one user at Bugzilla pointed out "the wikimedia foundation will replace mwlib with their own rendering pipeline. epub, zim and odf output will be removed.", which means the conversion were to be more difficult. And I've wrote a letter to Amazon to urge them to authorize Wikimedia Foundation to use that format for free. Although the chance of their approval may be small. --The Master (talk) 18:10, 3 February 2014 (UTC)

The software itself is free to use. But it is proprietary/closed source. The WMF will only use proprietary tools "where there is currently no open-source tool that will effectively meet our needs." (see Gratis versus libre) Since PDF and EPUB exist as widely-adopted open standards, chances of the WMF deciding to support Mobipocket are pretty slim. The community doesn't even want to support mp4 video files, and the free alternatives to that have much less support than EPUB. If you want to contact Amazon about it, complain that they don't support any open formats on their devices. Even the normal kings of walled gardens, Apple, support EPUB in the iBooks app. Mr.Z-man 19:40, 3 February 2014 (UTC)

There are FLOSS options to explore, such as calibre (software) on the user's side, or Writer2ePub (an OpenOffice.org extension) or Scriba ebook maker (a Java program) on the publisher's side. Some work would clearly be necessary to implement, but it looks possible in principle. LeadSongDog come howl! 21:51, 6 February 2014 (UTC)

Proposal to create page listing all nutshells

Not sure if this already exists, but a brief check suggests it does not. So here it is, in a nutshell:

{{nutshell}} would be modified to have an "external publish" flag. A page with a name like "Policies and guidelines in a nutshell" would be created, with subsections. Each subsection would contain the nutshell for the relevant core policies/guidelines. A bot would update the nutshell page regularly for any changes to any policy/guideline nutshells.

The benefits of this would be:

• Users could read one page and get the main idea of all policies/guidelines
• Page would be updated only by a bot, meaning that it would not have to be policed individually like other pages
• Content could be organized in a hierarchy, so sub-policies are associated closely with their parent policy

Thoughts? --NickPenguin_(contribs) 00:27, 12 February 2014 (UTC)

Not sure about that last bullet, but sounds neat to me. --Izno (talk) 00:30, 12 February 2014 (UTC)

I was thinking of cases like how WP:BIO or WP:NBOOK are subpolicies of WP:N. --NickPenguin_(contribs) 00:37, 12 February 2014 (UTC)

• Seems Wikipedia:List of policies does something along these lines wrt info but not automated. Alanscottwalker (talk) 01:01, 12 February 2014 (UTC)
  • Ditto for Wikipedia:Nutshell. Merge/improve those 2, if anything. Definitely don't create a 3rd (or more) location! –Quiddity (talk) 01:43, 12 February 2014 (UTC)

We could also consider to use Help:Labeled section transclusion to transclude nutshells so they can be shown anywhere. But it requires each nutshell to be marked in the page source. It isn't possible to make the marking in the template {{nutshell}}, and my testing indicates it doesn't work when the marking is done in the parameter to {{nutshell}}. It apparently has to be marked outside the {{nutshell}} call (diff), so the box with image and "This page in a nutshell" is included. That would make it ugly to display many on one page, but here is an example with only one. The nutshell of Wikipedia:Notability is:

PrimeHunter (talk) 02:54, 12 February 2014 (UTC)

@Quiddity and Alanscottwalker: I don't want to duplicate effort, so having one instantly updated overview page makes sense to me. Every policy nutshell has been carefully worded by years of discussion, and they are closely monitored. The kind of transcluding @PrimeHunter: has come up with is brilliant. It would make sense to put this system in place on some existing page, and redirect duplicate pages there. --NickPenguin_(contribs) 03:13, 12 February 2014 (UTC)

• Are you sure that the tags of the page can't be transcluded through the template? Please give me a few hours to look into that, I had thought I had done it on another wiki with LST. — {{U|Technical 13}} ^{(t • e • c)} 12:41, 12 February 2014 (UTC)

• Prime Hunter suggested the page would be ugly, I don't know, perhaps, Nick, you should partially mock something up using one of the existing pages talk pages or a sandbox. (As an aside, if I recall correctly, there has been discussion about how comprehensive to make those pages -- because we have so many policies and guidelines, and the page would be long. Note the WP:TOU nutshell, if you click through to it, is quite long by itself. However, what would it mean if a policy (or "important" guideline) is not set out on this proposed page -- is also something to think about) Alanscottwalker (talk) 13:01, 12 February 2014 (UTC)

As it stands, my proposal wouldn't necessarily look much different from the current versions of WP:LOP and WP:LGL, just that they would always be up to date. If length is the primary concern, then we could collapse certain subsections. We could have WP:N, and then a show/hide box that has all the specific subguidelines beneath it WP:NBOOK, WP:NMUSIC, WP:NEVENTS ect. --NickPenguin_(contribs) 17:38, 12 February 2014 (UTC)

I am not sure if this could work, but I think it would be highly pernicious if it did. Nutshells usually oversimplify and not infrequently misstate the pages they are supposed to summarize. That is a problem when nutshells are on the page, but at least the user has only to scroll down to get the full text. A page listing the contents of the various nutshells will be taken by may as listing the sole significant aspects of the relevant policy and guideline pages. This is not a good thing. Indeed I would propose any such page for deletion as a misstatement of policy. DES ^(talk) 18:12, 12 February 2014 (UTC)

This kind of content already exists at WP:LOP and WP:LGL (and Wikipedia:Nutshell, which should be deleted). I would just like to see it kept up to date. --NickPenguin_(contribs) 18:26, 12 February 2014 (UTC)

I didn't know those pages. Thanks for the tip! --NaBUru38 (talk) 22:02, 13 February 2014 (UTC)

Deleting a list of summarized policies because there are inaccuracies in the summaries would be the definitive example of throwing the baby out with the bathwater (or if you prefer, treating the symptom rather than the cause). As Nick notes, this kind of content already exists, and needs manual frequent manual attention to prevent it going out of sync. — Scott • talk 16:21, 14 February 2014 (UTC)

Also, yes, I agree that Wikipedia:Nutshell should be deleted. — Scott • talk 16:38, 14 February 2014 (UTC)

Front page idea: Trending topics?

I may or may not have seen something similar proposed before, but my logic and methodology for this is a little different. This would be a sort of variation of DYK, as they would apply to recently created articles that are related to recent, encyclopedic occurrences. But this would be tailored more to viral, but encyclopedic subjects, so we can help direct curious readers towards them to learn more about potentially popular subjects as Doge, Flappy Bird and Dumb Starbucks when they become relevant.

This would be handled like a cross between In the news and Did you know; they would be more "long-term" like what we see in In the News, but the articles themselves wouldn't need to be "new" (like the DYK, and the hooks, if any, could be more like DYK.

This is just a rough concept, but it could be expanded upon. Any critique? ViperSnake151  Talk  00:13, 13 February 2014 (UTC)

In the news has the perennial problem of localism, things with a really big hype in the local news, but that nobody abroad cares about. It is already hard to select news of international interest, and this proposal would simply make things more complicated. Cambalachero (talk) 01:39, 13 February 2014 (UTC)

Unless we keep the In the news we've got now, then you can expand it to see news stories in Iowa or Kamchatka or Gibraltar. Once you click it, it shows you something along the lines of "Recent news articles in [Belize], [New Delhi], [Chihuahua]..." (the brackets show WikiLinks to the pages with the news articles). It wouldn't cover everything, that'd be way too unfeasable, but the big stories in those places would show up. Supernerd11 :D Firemind ^_^ Pokedex 02:57, 13 February 2014 (UTC)

There have been various ideas regarding displaying the top ten (or so) viewed Wikipedia articles on the main page. Seems like a pretty good idea to me..--Coin945 (talk) 02:17, 13 February 2014 (UTC)

The two questions that come to mind are: how would find trending articles and how would we present them? I assume that we'd want to have this generated automatically, rather than by hand. Getting the data about articles recently increasing in pageviews or edits is one challenge, but far from impossible. Presenting this data on the Main Page would probably require a rethinking of how the Main Page actually works however. Right now it's a wiki page no different than an article, primarily constructed from templates. In the long run, we're probably going to need to transition to having the Main Page be constructed from proper code, and have it import/use certain kinds of editable modules based on what each community prefers. It sounds big and scary, but other projects, like translatewiki.net and wikiHow, have done this in similar forms. Steven Walling (WMF) • talk 03:08, 13 February 2014 (UTC)

ITN would be kept. What I thought would work could be a weekly, curated list of "hot" articles, with explanations of the thing that made it popular/notable recently, if any. ViperSnake151  Talk  03:36, 13 February 2014 (UTC)

• Would the Main page be listed in the top ten viewed pages (since it is the top viewed by page hits)? — {{U|Technical 13}} ^{(t • e • c)} 04:08, 13 February 2014 (UTC)

If this happened, we'd definitely exclude it from itself. Jackmcbarn (talk) 04:12, 13 February 2014 (UTC)

"Main Page: The English Wikipedia's home page continues to receive mainstream attention from internet users" ViperSnake151  Talk  06:46, 13 February 2014 (UTC)

Heh. Herostratus (talk) 22:40, 13 February 2014 (UTC)

I imagine that a few hours after an automatic thing was implemented we'd see people scheming to artificially inflate the views of various pages to get them in this new Main Page section. You may want to consult with the people behind The Signpost's traffic report for the issues seen when number of pageviews isn't something in the public eye. Anomie⚔ 13:23, 13 February 2014 (UTC)

• Support. I always find the top-ten articles in the Signpost interesting, I'll bet readers would too. This would allow us to leverage our synergy to create a new paradigm. Herostratus (talk) 22:40, 13 February 2014 (UTC)

• Support as long as it doesn't become an excuse to mass-create permastubs about a single hashtag or the like. KonveyorBelt 16:27, 14 February 2014 (UTC)

• Comment I'm not sure how this would be useful. Wikipedia articles are already invariably among the top hits when someone searches for info on the latest fad. --NeilN ^{talk to me} 16:37, 14 February 2014 (UTC)

Cite errors: add namespaces

Currently Cite errors show only on article, template, category, help and file pages. I propose to add portal, wikipedia and draft pages. I am in the process of updating namespace detection for {{broken ref}}. --  Gadget850 ^talk 14:46, 16 February 2014 (UTC)

Protest proposal

Here and here, you can see that on our friendly project, Wikia, has been launched some kind of digital protest against massive surveillance by the U.S. National Security Agency (NSA). Maybe we should start something like that and send a good message to the world. Please post your opinions and ideas how that could be realised. Also, we should probably vote on this? Alex ^{discussion ★} 21:01, 16 February 2014 (UTC)

There were proposals to participate in The Day We Fight Back on February 11. However, like that protest in general, it failed to materialize. - Floydian ^τ _¢ 22:04, 16 February 2014 (UTC)

Maybe we could try again? What is needed for that protest to materialise here? Alex ^{discussion ★} 22:59, 16 February 2014 (UTC)

Wikipedia head is now floating!

FloatHead on Flower article

I've recently done a user script - FloatHead. It makes your Wikipedia headbar floating and I think it really enhances the navigation across the wiki, especially on long pages.

Cheers! --Rezonansowy (talk • contribs) 12:49, 20 January 2014 (UTC)

Does it only work for Vector? Neither this nor Equazcion's script works for me (using Monobook). — Huntster (t @ c) 23:40, 20 January 2014 (UTC)

I think I have vector, and it's great! Dlohcierekim 01:25, 21 January 2014 (UTC)

I use Vector and it works. It does constrict the field of view a bit (top-bottom) when editing, which will take a little getting used to. I'm giving it a try. I like having the tabs available, especially on loooooong articles. Thanks again. GenQuest ^{"Talk to Me"} 02:41, 21 January 2014 (UTC)

Perfect! This way, people who used to say Wikipedia sucks can now say it gives great head! EEng (talk) 04:48, 22 January 2014 (UTC)

I would use it if it got disabled when editing a page. But I totally agree, having the top bar there is very helpful. --NaBUru38 (talk) 18:54, 28 January 2014 (UTC)

I've got no complaints. The slightly smaller space'll take some getting used to, but that's a small price to pay for this! Two questions, tho: Are there other things like this? And if so, how do I find them? Supernerd11 :D Firemind ^_^ Pokedex 04:42, 13 February 2014 (UTC)

I was looking for this. Now al it need is a pin/unpin button. — Edokter (talk) — 16:28, 5 February 2014 (UTC)

See also the Winter prototype. —TheDJ (talk • contribs) 09:48, 19 February 2014 (UTC)

Winter sports in Category:Sports by year

Winter sports are often played autumn-spring, making one "year" span two half-years. Shouldn't they be treated that way in the year categories too? So the "year" is not like 1990 but like 1989/90 and 1990/91? Bandy boy (talk) 08:46, 17 February 2014 (UTC)

To editor Bandy boy: By winter sports, do you mean snow and ice sports, or sports that are traditionally not played in the summer?

It is already done for some sports. See for example Category:1996–97 in English football.

What changes to which categories do you propose?

--Hroðulf (or Hrothulf) (Talk) 15:14, 17 February 2014 (UTC)

I mainly thought of snow and ice sports, particulary the categories under Category:Years in bandy, but I suppose the same would go for any sport where the traditional season is autumn-spring rather than spring-autumn. Bandy boy (talk) 21:54, 17 February 2014 (UTC)

For hockey, we put (e.g.) 2012–13 NHL season into both Category:2012 in ice hockey and Category:2013 in ice hockey. The league seasons often cross two calendar years, but most tournaments are in one or the other. Resolute 20:18, 20 February 2014 (UTC)

Android Nearby

Is there a better page for this? Anyway the Android app has a nice feature to read our GPS location and show a map of nearby articles. Handy, but it could be far more useful:

1. Atlantic Ocean. The first thing that comes up is a sea of blue. That's because it hasn't read GPS yet, and assumes we are at Longitude Zero, Latitude Zero, mid-Atlantic. If you're indoors or for some other reason GPS isn't giving a location, it stays that way. Needlessly confusing, hence wrong. Should show a world map until it finds a location, or at least a "No GPS yet" indicator.
2. True GPS only. I generally keep GPS turned off because it drains my battery too fast. Google Maps for Android still knows where we are, presumably due to cell tower triangulation and WiFi footprints. Wikipedia app should do the same, or ask GM.
3. Battery. Wikipedia app drains my battery even faster than GM does when GPS is on.
4. Desert. If we're in an area that has no Wikipedia articles, it shows nothing. Or if it thinks we're in mid-Atlantic. Should adjust zoom level until there's a reasonable number of points to show, say five to thirty or some such range.
5. Comeback. It's useful to tap on an article, find out that it's not one we want to visit, and use the back arrow to go back to the map for another go. Except, the map shows mid-Atlantic again because the app has already totally forgotten where we are. Should be able to remember for, like, even a whole minute.
6. Nearby what? We're looking at an article when we hit the menu key, right? If the article has coords, the menu should ask something like, "Near to you, or where this article is?" If it's a list of a hundred coords, show them all and let us zoom and pan for the right ones.
7. Pictures. Should have an option to see where the Commons pictures are in this neighborhood, with a different and preferably smaller icon.

Again, I hope someone can direct me to a forum or discussion place for this kind of thing. Jim.henderson (talk) 22:36, 17 February 2014 (UTC)

You are looking for the Mobile team. In general their active discussion happens on their mailing list, but i'll ping them on IRC to read their feedback page. —TheDJ (talk • contribs) 09:45, 19 February 2014 (UTC)

Open letter from EFF, Demand Progress on re-opening Wikipedia:Surveillance awareness day

EFF and Demand Progress have written an open letter to the members Wikipedia community asking them to re-open Wikipedia:Surveillance awareness day, which failed to reach consensus. I'd appreciate hearing some responses from the community to this! Thanks, ParkerHiggins ( talk contribs ) 20:42, 5 February 2014 (UTC)

• With less than a week to go before the date, i don't think there is enough time for a valid RfC on such a major issue. If one were opened I would oppose on those grounds alone. And that is leaving aside the issue of whether that kind of advocacy is proper here. DES ^(talk) 20:46, 5 February 2014 (UTC)
• While Wikipedia's participation would undoubtedly give a substantial boost to this campaign, which is something many of us might like, political activism is something pretty much impossible to do while remaining neutral. If SOPA hadn't been an existential threat to Wikipedia, we probably wouldn't have done anything about it. We might like to think of Wikimedia as a major player in the activities of the "freedom"-oriented online community, but our policy of neutrality gives us far less freedom of action in these areas than other communities, even those that are corporate-run. And, as DES said above, the amount of time left wouldn't be enough for a valid RfC even if it was something widely supported. Good luck with the protest. --Yair rand (talk) 22:27, 5 February 2014 (UTC)
• (edit conflict) Oh how cute... the advocates for internet rights are attempting to bully/shame us into participating in their demonstration. Perhaps if the awareness day is celebrated again next year we can hold a "Re-call the question" RFC to close no less than 2 weeks before the event to see if there is a consensus to participate in the demonstration, as Consensus can change. Hasteur (talk) 22:28, 5 February 2014 (UTC)
• Are we not here to write an encyclopedia? Period? Take the POV social-activism to a blog or somewhere else. It does not belong here. GenQuest ^{"Talk to Me"} 03:39, 6 February 2014 (UTC)
• It became clear what was going to happen (nothing) when I posted Wikipedia talk:Surveillance awareness day/Archive 2#Proposal: Endgame Timeline and most of those participating didn't bother to respond. It was a bog-standard project management proposal for meeting a deadline: figure out what needs to be done before the deadline and start negotiating a schedule by working backwards. I had a rough draft of additional previous steps but didn't bother posting them once it became clear that there was no significant interest in making a schedule, much less meeting it. Everything I wrote in that proposal is still true. No matter what the EFF desires (full disclosure: I am a regular contributor to the EFF) we as a community blew right past the 23:59, 2 February 2014 deadline, and at that moment it became impossible to make up the lost time and meet the deadline. --Guy Macon (talk) 15:24, 6 February 2014 (UTC)

23:59, 2 February 2014

• Full disclosure, I oppose wikipedia taking sides in protests. However repeatedly I (among others)said If you want to get this done, there needs to be a centralized community discussion on the basic question, does the community support taking action. Weeks ago I (among others) said that, and not one supporter started that community discussion. It's too late now, and if you support it, when casting blame look first in the mirror for not even bringing this to the community.--Cube lurker (talk) 17:23, 6 February 2014 (UTC)

• The US conducts drone strikes in Yemen, some of which are acknowledged to be errors-- that is, killing of innocent civilians based of false conclusions. If there's a 13 year old student in Yemen who wants to read Wikipedia, I can't in good conscious recommend that they should feel free to read all our articles on chemistry without fear of becoming a 'false positive' killed by US drones for reading something suspicious.
  We didn't spend 10+ years making an encyclopedia that some parts of the world should be afraid to read!!!!
  I don't know precisely what we should do in response, but I'm confident that doing nothing is the wrong answer. --HectorMoffet (talk) 11:37, 7 February 2014 (UTC)

If you're that confident you should have taken my advice weeks ago.--Cube lurker (talk) 13:20, 7 February 2014 (UTC)

...or mine, which was posted much later and also largely ignored. These things don't just happen by magic. They require organization and cooperation. --Guy Macon (talk) 18:39, 7 February 2014 (UTC)

Hey, I make a lousy leader, what can I say. I've never read main page criteria before, I don't hang out at ANI, I'm not even an admin-- I'm a gnome who wound up in a position no gnome should be in. A true organizer could have done things a lot better-- most of the time I thought Jehochman was the leader who was going to organize cooperation, but he turned out an absentee leader. There was advice from all sides, obviously I should have taken more of it. Ya got me-- someone better than me should have handled this, and I still hope somebody better than me WILL. --HectorMoffet (talk) 03:00, 8 February 2014 (UTC)

• It's all about domestic American politics, thus outside the scope of the global Wikipedia community. SCOPA was a threat to Wikipedia's existence, this issue isn't. I really don't care if the NSA/FBI/CIA/<insert alphabet-soup de jour> wastes their time to read everything I have ever written here - they'll find it ridiculously boring (in the national security sense). Roger (Dodger67) (talk) 11:55, 7 February 2014 (UTC)

Yeah, but what if you lived in a place where killer robots controlled the skies. Would you really feel free to read whatever you wanted? --HectorMoffet (talk) 12:11, 7 February 2014 (UTC)

Is there any credible evidence that the "killer drones" have ever targeted anyone based purely on what Wikipedia articles they have read? AFAIK the only people who kill other people because they read "politically incorrect" literature are the radical Islamists - they kill people for possessing un-Islamic books. This is not a defence of US military policy, I'm simply pointing out the absurdity of your scenario. AFAIK the innocents killed in drone strikes have been due to simple target misidentification, none of them were actually intended targets (as your scenario requires). I'm done here - as non-American of a non-Islamic persuasion this is a total non-issue for me. Roger (Dodger67) (talk) 12:26, 7 February 2014 (UTC)

There is a lack of evidence because the targeting is secret. However, it is publicly known that militants can be selected by these things based on "behavioral characteristics" [3]. These characteristics can include (as that source explains) being a medical professional going to the aid of someone injured in a drone strike. So no, killing people for what they read on Wikipedia would not seem beyond the controlles' moral capabilities. Wnt (talk) 17:34, 7 February 2014 (UTC)

So, "killer robots" and "killer drones" have become buzzwords for surveillance awareness? That's pleasant, and yes, I'm in favor of awareness. Awareness of the world is the purpose of Wikipedia. And yes, more surveillance can also promote awareness of the world and there ought to be more well organized surveillance webcams. That way, millions of people can be more aware of millions of places. However, promoting awareness through surveillance is not in our purview. The most we should do is link to a few of the webcams that are surveilling a particular place, from our articles about a place. Jim.henderson (talk) 16:29, 7 February 2014 (UTC)

That is correct. "Killer robots" and "killer drones" have indeed become buzzwords for surveillance awareness, and rightly so. See The NSA’s Secret Role in the U.S. Assassination Program. --Guy Macon (talk) 08:12, 11 February 2014 (UTC)

I've taken the liberty of redirecting WP:Surveillance Awareness Day to WP:WikiProject Mass Surveillance. The EFF may have been misled by the "rejected" tag formerly at this page, which wasn't really the result of a consensus and applied only to some of the ideas discussed on the page. The "historical" tag doesn't belong on a page at all unless you don't blank the contents. Clearly those interested need to be redirected to the ongoing efforts. Bottom line: Surveillance awareness is no longer one day. Wnt (talk) 17:43, 7 February 2014 (UTC)

• Too Late Without even addressing the serious issue of whether Wikipedia should get involved, the timing issue is persuasive. Doing something right would take far more than a week, and doing something half-baked is worse than doing nothing.--S Philbrick(Talk) 15:53, 10 February 2014 (UTC)
• Too little, too late. Interesting, but Wikipedia does those things very, very slowly. Maybe if they keep on bringing this up we will have time to hold a wider discussion about doing this by next year. Also, it would be good if their activists would join Wikipedia:WikiProject Mass surveillance and help improve related content. Someone suggested that the best way to deal with such proposals is to write and feature related articles as DYKs/FA. I think it would be easiest to do just that, --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 15:58, 10 February 2014 (UTC)

• Bummer. I'm not knowledgeable about how the Wikipedia politics work but I read an article today discussing major websites supporting The Day We Fight Back and it described only Google and Wikipedia as being notably absent among those who participated in the SOPA protest (and even Google may be participating now according to a Facebook spokesperson who is part of joint task force with Google and other companies). Anyway, kinda disappointing that Wikipedia couldn't get its act together to do something as simple as add a few lines of javascript to the home page for one day. I certainly would have voted for it if there had been some kind of notice to editors. Took a good bit of searching and asking around to even find this page... :( Steevithak (talk) 02:54, 11 February 2014 (UTC)

• The Wikians have voted more than 95% for Wikia to join the Day We Fight Back protests. You can too. See Jimbo's talk page. The URL for voting is http://community.wikia.com/wiki/User_blog:Semanticdrifter/Digital_Protest_Against_the_FISA_Improvements_Act —Neotarf (talk) 18:29, 11 February 2014 (UTC)

You can tell it's accurate because it lets you vote even if you don't have a wikia account.--Cube lurker (talk) 18:38, 11 February 2014 (UTC)

• After getting a few requests from the EFF and similar groups to get engaged in this sort of activity, we started writing a draft guide on how organizations should approach working with Wikimedians -- you can find it at Asking Wikimedians To Support Advocacy on Meta. If you are interested in the topic, your input would be very helpful! Stephen LaPorte (WMF) (talk) 22:33, 21 February 2014 (UTC)

Add multiple pages to your watchlist at once

Is there a way to add multiple pages to your watchlist at once, i.e. all the links in a template on the bottom of a page? This could really come in handy for if you're into a topic that has a lot of subtopics, like Pokemon. Supernerd11 :D Firemind ^_^ Pokedex 01:34, 16 February 2014 (UTC)

The closest way would be to edit your raw watchlist. Alternatively, you might try Special:Recentchangeslinked/Template:Pokémon (for example). --Izno (talk) 02:41, 16 February 2014 (UTC)

These work, as well as what I was doing before (hovering over each one in the navbox on the bottom of the page and selecting "Watch" from the mouseover box), but I was hoping for something like "Watch all subpages". I don't have the developer know-how, is there someone who can do that? Supernerd11 :D Firemind ^_^ Pokedex 03:18, 16 February 2014 (UTC)

The "Related changes" feature reports all changes to pages linked from a given page. See Help:Related changes for more information. DMacks (talk) 05:05, 22 February 2014 (UTC)