→Discussion: "Don't be evil" |
|||
Line 1,082: | Line 1,082: | ||
*'''Neutral''' if it remains targetted at US IPs only, '''oppose''' if it's expanded to include non US IPs. Having read our lawyers response and some follow up comment, the actual extent of any threat to wikipedia seems to remain fairly unclear. Therefore, I remain opposed to any action involving non US IPs, particularly since the ability of non Americans to directly influence the bill is limited anyway. As also per my earlier comments, I'll let those from the US decide what they wish to do about it themselves. [[User:Nil Einne|Nil Einne]] ([[User talk:Nil Einne|talk]]) 20:46, 20 December 2011 (UTC) |
*'''Neutral''' if it remains targetted at US IPs only, '''oppose''' if it's expanded to include non US IPs. Having read our lawyers response and some follow up comment, the actual extent of any threat to wikipedia seems to remain fairly unclear. Therefore, I remain opposed to any action involving non US IPs, particularly since the ability of non Americans to directly influence the bill is limited anyway. As also per my earlier comments, I'll let those from the US decide what they wish to do about it themselves. [[User:Nil Einne|Nil Einne]] ([[User talk:Nil Einne|talk]]) 20:46, 20 December 2011 (UTC) |
||
*'''Support''': I preferred the tools-down global blackout (as several countries follow the US example and might try restrictive laws of their own, and action should be taken there too), but any action is good action. '''[[User:Sceptre|Sceptre]]''' <sup>([[User talk:Sceptre|talk]])</sup> 02:55, 21 December 2011 (UTC) |
*'''Support''': I preferred the tools-down global blackout (as several countries follow the US example and might try restrictive laws of their own, and action should be taken there too), but any action is good action. '''[[User:Sceptre|Sceptre]]''' <sup>([[User talk:Sceptre|talk]])</sup> 02:55, 21 December 2011 (UTC) |
||
*'''Did Google pay us to shut down Wiki?''' Just wondering. Supposedly we are discouraging large individual grants (to not be beholden). But then we just got a half million from the founder of Google. And he has given us a LOT over the years too. And he has billions tied up in Youtube and Google and all. When we read the Wiki counsel's advice, we find out that Wiki itself is not under much danger. But Google has a lot of problems. And they are a ginormous, for profit, entity. So...just wondering on the timing of that last grant. 03:12, 21 December 2011 (UTC) |
|||
=== Committee meets on Wednesday === |
=== Committee meets on Wednesday === |
Revision as of 03:12, 21 December 2011
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
New ideas and proposals are discussed here. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals.
- Consider developing your proposal on Wikipedia:Village pump (idea lab).
- Proposed software changes that have gained consensus should be filed at Bugzilla.
- Proposed policy changes belong at Wikipedia:Village pump (policy).
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
Multilingual search results for registered Wikipedians.
RfC tag added on 23:59, 23 November 2011 (UTC).
Proposal: Enable users who have registered Wikipedia accounts to receive search results from multiple Wikipedias automatically.
Synopsis: Single language search is the wisest decision for the majority of users, but multilingual search results are incredibly useful for multilingual users, allowing them easier and more reliable access to information.
Cons against multi-language searches: Currently, there is a fairly fast and effective way to search for items in a language other than the wiki a user is visiting. By typing in the country prefix at the beginning of a search, we can navigate to a page that is not on the originating project. This is a smart balance between usability and technical performance when considering the average usage of the Wikipedias. For most users, the side language options in an article and the ability to specify a country prefix are more than enough options for effective information gathering. On top of that, it would be horribly inefficient to force the server to crawl every language whenever an anonymous user searched for something. It would also be hard on the servers to attempt to detect a language for each search call. Searching every database for a single item would be a Herculean task to perform even once, and the time it would take to do such a comprehensive search would severely detract from a usability standpoint. Although I am currently unfamiliar with Lucene, I am under the impression that a single call is made to a language's index when a search is made. The functionality of the searching and the availability of individual wikipedia language stats suggest that the articles reside on separate indexes. If this is the case, to find articles in multiple languages would require multiple searches to be made for a single request. This would also be a very large no-no from a performance standpoint if there were a large amount of languages being searched by a significant amount of active users.
Pros for multi-language searches: For articles that exist in both the language of the original search term and in the originating wikipedia's language, the user will most likely be redirected to the originating language version of the article. This is certainly a simplified explanation, as one might end up on a disambiguation page for that word. For example, if one searches for 愛 in the English Wikipedia, that user will be served with Love. Searching for Amore(Italian for love), however will redirect you to a disambiguation page for Amore. That page provides a link to the English article for love. It should be noted, however, that neither search will allow you to immediately reach the existing articles for love in the languages in which they were searched. It would be necessary to reach the article in the language of the wiki first before clicking on the language sidebar. This is acceptable, but not as user-friendly as it could be.
The above only relates to searches that involve articles that represent the concept in the searching wiki's native language. If a user creates a basic search for an article that does not exist in the language of the wiki being searched from, then the results page will display nothing. If one searches for the Japanese celebrity 温水洋一 (Yōichi Nukumizu) in the English wikipedia, it displays nothing. If you search for the romanization of his name, there is still no link to the Japanese article, but there are suggested articles that contain his name. As there is no article in English at the moment which talks about this person, there are much more limited search results on the English Wikipedia. This makes sense if the person doing the search doesn't understand Japanese, which would be understandably assumed about most users on the English Wikipedia. This isn't a valid assumption for users that explicitly specify that they would like to be unified with both the Japanese and English Wikipedias.
There will be much fewer users who unify their accounts with multiple languages. Therefore, the load would be significantly less taxing on the server to search those unified languages for a single search term.
Possible Solution: A registered Wikipedia User can specify whether or not they wish to receive search results from multiple languages. This option would be disabled by default. If this is still not a large enough limit, we could require the user account to be unified with the languages they selected.
For performance issues, I would recommend that by default when a user opts in to this functionality, all searches would be performed as they currently work. Therefore, if multiple languages have articles for the same concept, the user would be served with the page on the Wikipedia that was originally queried. Only when no result was found on that Wikipedia would there be a search for the other languages that had been opted for. If the user wishes, however, they could specify that they wish to given a choice of articles in the languages for which they opted. This would require some new functionality. The new manner of search could be done in multiple ways. If an Article exists on the language of the Wikipedia being searched, it could check for a corresponding interlanguage link and display all relevant choices from that information. This would save resources as there would be no need to search for a second time. Another option would be to run a separate search on the wikipedias opted, so that if an article exists in language, but has yet to receive an interlanguage link, the information won't be lost. Either way, I'll leave that up to people who are in charge of the technical matters and who have much more experience than myself. I'd think that it would be best to combine the two. If an interlanguage link exists, give those choices, if it doesn't exist for one of the languages opted for, make sure to search that language explicitely. This would also be a good way to find and report articles which should related via interlanguage links!
Example process flow for the various ways a search could be handled depending on the type of user:
anonymous Wikipedia user or registered user who has not opted for multilingual support:
(no change from current method)
registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support without specifically wishing for a choice of articles in both languages:
searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in the current manner -> redirects user to Love. (no change from current method)
searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in the current manner -> redirects user to 愛. (no change from current method)
searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the current manner -> no results found -> runs a search for “ja: 温水洋一” -> redirects user to 温水洋一
registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support and specifically wishes for a choice of articles in both languages:
searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love
searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love
searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the new manner -> no results found. runs a search for “ja: 温水洋一” -> redirects user to 温水洋一
Thanks for reading! I hope you think this is a worthwhile idea and look forward to your ideas. Also, I apologize for the informal nature of this proposal. It's my first wikipedia page and I'm just a dumb art student. Subcogitate
- Oppose: We've considered it before, but most people don't know all the 20+ languages Wikipedia uses. One word in one language can mean something else in another, so users could get misinformed. I don't think it's worth the increased server latency. By the way, this is not a unique page - see Wikipedia:Your first article.Jasper Deng (talk) 23:42, 19 November 2011 (UTC)
- ---Thanks for the feedback! If you notice, however... My proposal doesn't say anything about searching all the languages. Just ones that the users select. You might want to reread the entire article and gain a better understanding of what I am suggesting. Also, you are right about this not being a unique page, so thanks! :) Subcogitate
- I like the idea, but there are a few things that need to be sorted out (logistics).Jasper Deng (talk) 04:04, 21 November 2011 (UTC)
- Nice idea. Well considered and presented. I'll think about it a bit before deciding one way or another though. First impression is that it could be a boon for those who speak multiple language to more quickly find matches across all Wikipedias. fg 01:43, 20 November 2011 (UTC)
- Previously proposed umpteen times, it is languishing at Bugzilla unloved and uncared for at https://bugzilla.wikimedia.org/show_bug.cgi?id=1837. Fences&Windows 00:59, 22 November 2011 (UTC)
- -- It's nice to see people hoping for the same thing. The title of that bug is "search all languages" which is a bit different from what I'm suggesting... If that's not what the bugfix is supposed to do, then maybe it needs to be re-written to be more specific :) Thanks for the tip! I'll look into bugzilla from this point forward! Subcogitate
Personally, I think this could be quite a good idea. ACEOREVIVED (talk) 20:55, 23 November 2011 (UTC)
- You might want to use http://www.qwika.com/, but I am not sure how relevant or how useful it is.
- —Wavelength (talk) 21:29, 23 November 2011 (UTC)
- Support Can't think of any down sides. I don't speak or read any other languages but English (except programming and scripting languages but that's different) so would not get the benefit but, I can see how useful it would be to a user who is multilingual. I can well imagine it being a boon for Wikipedia too since it would encourage cross language Wikiknomery etc. I also imagine it would be quite simple to implement. A quick extension to some php and a couple of tweaks to related UI and Bob's your uncle (as we say in blighty). fredgandt 23:53, 23 November 2011 (UTC)
- Comment: I have listed this proposal at Template:Centralized discussion to canvass wider input. Cunard (talk) 00:01, 24 November 2011 (UTC)
- I'd love to be able to search the French and German Wikipedias at the same time as I search the English one. We'd need to think about how the results were displayed, because with many things -- biographies, geographical locations, the sort of thing you'd actually want to use a foreign-language Wikipedia for -- the articles will have the same titles. I suggest using the standard Wikipedian prefixes, if this is technically possible, so if I used the search term "Goethe" the results would be listed as en:Goethe, de:Goethe and fr:Goethe.—S Marshall T/C 12:18, 24 November 2011 (UTC)
- Support. As I'm regularly using the English, the French, the German and the Slovene Wikipedia, I find it a great idea to have the results for all of them listed in one place. This makes finding the relevant information easier, simplifies the comparison between the different versions and cross-checking and also allows for easier building of articles using information and references from different language versions. I'm really looking forward to have this enabled. --Eleassar my talk 12:50, 24 November 2011 (UTC)
- I'm doing some translation right now, and this would certainly be helpful, especially as a little option on the search page. What would be cool would be having the interwiki result(s) pop up next to each search result so people can also see which languages have an equivalent article to what they're looking for. /ƒETCHCOMMS/ 19:01, 24 November 2011 (UTC)
- Comment Don't forget Google "goethe site:wikipedia.org" - not great but better than nothing. Rich Farmbrough, 17:38, 25 November 2011 (UTC).
- Support Sounds like a good idea. Dusty777 (talk) 23:56, 25 November 2011 (UTC)
- Comment Could this somehow be linked to the Babel userboxes on user pages? So, when enabling the feature, you won't need to select languages you're interested in. Bazonka (talk) 09:48, 26 November 2011 (UTC)
- Support as a checkbox option, disabled by default. It will clutter results (the same sequence of chars can bear different meanings in different languages), so using it by default is not a good idea. P.S.: the Babel comment right above mine makes some sense: it would be nice if language skills would influence sorting. — Dmitrij D. Czarkoff (talk) 17:33, 28 November 2011 (UTC)
- Restored for further discussion before it is closed by an uninvolved admin. Cunard (talk) 06:18, 13 December 2011 (UTC)
- Support As long as it's optional.Zlqchn (talk) 12:04, 15 December 2011 (UTC)
- Support as an opt-in, not appropriate as a default. Could also fuel further quality improvements in other wikipedias which are at an earlier stage in their lifecycle compared to en.wikipedia.... bobrayner (talk) 19:56, 15 December 2011 (UTC)
To be able to own Wikipedia.
I have a suggestion that might make some money for Wikipedia and serve its goals at the same time.
I would like to be able to BUY a copy of a certain year of the entire site. I cannot say if this would be a set of DVD's or a large stand alone hard drive, but I would LOVE to have my own copy of the whole site. There are times that one's internet is not working and to have your own copy of the closest thing to an Encyclopedia Galactica would be delightful.
A second reason I think this is a good idea is that it would allow a researcher to document changes over time. For example, the word "soandso" only has a placeholder in Wikipedia 2011, but by 2012 it is a huge document. The phrase "soandso" appears to have entered the popular lexicon between 2011 and 2012.
We can learn a great deal about the past by looking at a popular encyclopedia at that time. What were the prevailing attitudes on certain subjects and what subjects might have been taboo. It would be a shame for Wikipedia to be moving forward in time and to leave nothing historical in its wake. The evolution of Wiki's or Wikipedia itself is a subject worthy of study, but unless there exists a static snapshot of a moment in time, that historical context is lost.
In the final analysis there is the fact that when civilization collapses, I'd like to know a few backups are out there somewhere.
- See Wikipedia:Database download. You can download the whole site to your hard drive, for free. However, if civilization collapses, I think that the internet would be among the bottom of social priorities. Cambalachero (talk) 02:25, 17 November 2011 (UTC)
- Do you know about page history? You can see all versions of every page, ever. For example, So and so began as a rather odd redirect in 2005 [1], and gradually expanded [2] [3]. (Not a great example; it's far more interesting to look at the historic versions of more substantial articles). Also, you might find nost:HomePage interesting, which is a frozen snapshot of Wikipedia from 2001 - e.g. nost:Earth.
- There's various plans in place to provide a 'snapshot' of Wikipedia in various formats. I just hope they remember to write Don't Panic in large, friendly letters. Chzz ► 09:09, 17 November 2011 (UTC)
Wikipedia has never been for sale - Wikipedia always has been, and probably always will be, a free internet site, which is able to be accessed by any one who has access to the world wide web. ACEOREVIVED (talk) 20:53, 23 November 2011 (UTC)
- Oh and by the way: you can also buy printed editions of Wikipedia! mabdul 11:55, 30 November 2011 (UTC)
- Oppose It's a good idea, but the encyclopedia is too large to try to document the entire thing. At this point, how would we easily make a distinction between actual articles and "Wiki" pages, such as the projects and special pages? What articles should be included/excluded from a printed addition. At this stage, with American culture moving away from print media and embracing the digital age, it would be like taking a step backward, rather than a step forward. Tarheel95 (Sprechen) 16:57, 5 December 2011 (UTC)
- There are various (free) versions that you can own, but they do suffer form some limitations. Cambalachero's idea is a good one in principle. Rich Farmbrough, 21:29, 5 December 2011 (UTC).
Provided you don't care about the images, this provides a dedicated offline copy of Wikipedia in a handheld package. Dragons flight (talk) 21:39, 5 December 2011 (UTC)
- Proposal is out of place. There is no policy or guideline of the English Wikipedia that has much to do with this. If you want to buy a physical copy from the Wikimedia Foundation, contact them directly and see if you can come to a mutually agreeable price. Alternatively, it doesn't have to be the Foundation; nothing stops anyone, really, from downloading the whole site and selling you a physical copy, but if you want to place an ad for such a person, this is probably not the right place to do it. --Trovatore (talk) 21:44, 5 December 2011 (UTC)
- My studies show that the English Wikipedia would fit on a large external hard drive, along with all media it uses (although they may have to be at reduced size). I think this could be sold for $100 USD, possibly less. I think it's an excellent idea for someone to do this. I might do it. WMF isn't going to do it, as they generally leave commercialization of content to others. Dcoetzee 10:25, 8 December 2011 (UTC)
- Sure, go for it. Anyone can; it's (almost entirely*) free. Anyone can do anything they want with it, as long as they give credit.* Many people have copied various parts of Wikipedia to various formats; that's all great. No problem. And if they make $$$ from it, good luck to 'em. Chzz ► 10:23, 14 December 2011 (UTC)
- If you want to buy and carry a copy of Wikipedia, consider the WikiReader which retails for less than 100USD. You can download updates yourself or subscribe to their service and receive new copies of Wikipedia via the post. I have one on my coffee table and I love it. LeeColleton (talk) 04:11, 20 December 2011 (UTC)
Be able to watch talk and main pages separately
This has been brought up before, but has not got much attention. See #Watch_talk_pages (2005) and #Watchlist_without_talk_pages (2008)
It would be nice on occasions to watch a talk page without watching its main page or vice versa. The default behaviour should stay as it is insofar that any watched page automatically has its associated page also watched, but if we chose, we should be able to watch un-watch just one or the other. fredgandt 02:00, 30 November 2011 (UTC)
- It's been brought up before at least a couple times, but I agree, I'd love this. ♫ Melodia Chaconne ♫ (talk) 03:07, 30 November 2011 (UTC)
- Support. But this is the programmers', not our, problem.Jasper Deng (talk) 03:37, 30 November 2011 (UTC)
- Support. When brought up before, was there a technical reason this wasn't possible or did we just decide not to implement it? --Philosopher Let us reason together. 04:02, 30 November 2011 (UTC)
- Support This option may be useful for some editors. Don't see a downside.--JayJasper (talk) 05:48, 30 November 2011 (UTC)
- Weak oppose, as it will lead to increased amount of out-of-context edits. — Dmitrij D. Czarkoff (talk) 09:20, 30 November 2011 (UTC)
- Oppose. This would have negative consequences on editor interaction. Edit warriors could simply claim that they were not aware something was discussed on the talk page because they 'forgot' to watch it. Sometimes absence of a feature is a big advantage. Hans Adler 13:12, 30 November 2011 (UTC)
- Anyone wishing to claim ignorance can already do so. I proposed that this would not be a change to the norm but an addition to it. An extra feature that would allow the un-watching of one or the other page, without un-watching both. There could be no forgetting as they would have to actively undo default behaviour. fredgandt 13:23, 30 November 2011 (UTC)
- I still think this would cause confusion, plausible deniability and disruption. However, we can already restrict display of changes to just one namespace. It should be easy to write a JavaScript tool that you can install yourself and which just displays several namespaces and filters out certain others, or which sorts changes according to namespace. Hans Adler 17:08, 30 November 2011 (UTC)
- Well, being able to watch talk pages but not the article pages shouldn't be a problem, at least. I often don't care about the changes on the 'article' page (such as with Wikiprojects) or am curious about the talk page temporarily on a heavy-watched page (like the FA of the day). ♫ Melodia Chaconne ♫ (talk) 19:16, 30 November 2011 (UTC)
- I still think this would cause confusion, plausible deniability and disruption. However, we can already restrict display of changes to just one namespace. It should be easy to write a JavaScript tool that you can install yourself and which just displays several namespaces and filters out certain others, or which sorts changes according to namespace. Hans Adler 17:08, 30 November 2011 (UTC)
- Anyone wishing to claim ignorance can already do so. I proposed that this would not be a change to the norm but an addition to it. An extra feature that would allow the un-watching of one or the other page, without un-watching both. There could be no forgetting as they would have to actively undo default behaviour. fredgandt 13:23, 30 November 2011 (UTC)
- Weak oppose. My guess without looking at the software is that this is a Mediawiki matter not a WP matter. IMHO, the diversion of scarce resources from other matters isn't justifiable. Wtmitchell (talk) (earlier Boracay Bill) 14:10, 30 November 2011 (UTC)
Template:Bug "There is no user preference to automatically watch talk pages edited" seem pretty close the proposal. ---— Gadget850 (Ed) talk 18:03, 30 November 2011 (UTC)
- Not quite related. Anyway, watchlist entries are bound to the article's titles in the database, which encompas both the atricle and it's talk page. They are unseperable in that respect, so this would require rewrite in the software (and possibly restructering of the database). — Edokter (talk) — 18:11, 30 November 2011 (UTC)
- I would imagine (I know a bit about PHP and MySql) it would be quite simple to split them up at one level or another. I would look at the last script to handle the providence of Special:Watchlist and flag those tagged. The tagging could also be easily appended to the database. Bitfileds come in handy for this sort of thing. Just create two new values and carry on camping! fredgandt 21:13, 30 November 2011 (UTC)
FWIW, Wikipedia:Hide Pages in Watchlist shows that it should be possible to write a user script to do this. Rd232 talk 19:24, 30 November 2011 (UTC)
- User scripts can change the display in almost unlimited ways. So yes it could be done that way. the question would be whether enough people would like it to make it more practical and/or desirable to add it to the software. fredgandt 21:13, 30 November 2011 (UTC)
- Support as opt-in. I would find this practical. ~~Ebe123~~ → report on my contribs. 22:58, 1 December 2011 (UTC)
- Comment I don't understand when this would be useful and would like to see clear examples. Dcoetzee 09:38, 4 December 2011 (UTC)
- Now and then and here and there!
fredgandt 10:00, 4 December 2011 (UTC)
- Now and then and here and there!
- Support CharlieEchoTango (contact) 08:23, 6 December 2011 (UTC)
- Oppose - I can't see the value in this. Why would you want to watch one and not the other? Major changes to an article are discussed on the talk page and if I had forgotten to add the talk page to my watchlist, by the time I saw those changes, it might be too late to do anything about them. I would support a 'Hide Talk Page' option such as the 'Hide bots' option we currently have but the default should be to watch both pages.--Ykraps (talk) 08:53, 6 December 2011 (UTC)
- You could not forget to watch one or the other as the default behaviour would not change. This is a proposal to allow the un-watching of the pages separately as a special option. As for when or how it might be useful, it might be (personally has been). I just like options!
fredgandt 09:13, 6 December 2011 (UTC)
- You could not forget to watch one or the other as the default behaviour would not change. This is a proposal to allow the un-watching of the pages separately as a special option. As for when or how it might be useful, it might be (personally has been). I just like options!
- Support. - Dank (push to talk) 18:57, 6 December 2011 (UTC)
- Oppose Increases user interface complexity without any clear benefit. (If this "feature" is thoroughly hidden then okay, but I'd rather see the MediaWiki developers spend their time on developing more useful features.) —Ruud 21:53, 6 December 2011 (UTC)
- Personally, I'd rather be certain that I always have both the page and the talk page watched. I absolutely do not want to see the behaviour of unwatching be changed (by default), nor would support adding any additional user interface elements (confirmation dialogs, tab or menu items) be added (without enabling this feature in your preferences.) Some additional checkboxes etc. on the watchlist would be fine. —Ruud 12:43, 7 December 2011 (UTC)
- Oppose - What's the point? Why can't you just ignore the extra watchlist entry? What if you're watching the talk page of a low-traffic article without watching the article itself, and it gets vandalised? →Στc. 23:09, 6 December 2011 (UTC)
- And since when is it anyone's obligation to revert vandalism? And if you're going to say "why not ignore that page" than it wouldn't get reverted ANYWAY now would it? ♫ Melodia Chaconne ♫ (talk) 01:16, 7 December 2011 (UTC)
- I would like to watch WT:AIV but not WP:AIV.Jasper Deng (talk) 23:45, 6 December 2011 (UTC)
- AIV gets many edits each day that I don't want to watch. It's the talk page I want to watch.Jasper Deng (talk) 01:56, 7 December 2011 (UTC)
- It was actually AIV that inspired this proposal. I wanted to keep an eye on discussions there but didn't want to be pointlessly flooded with the constant stream of edits to the main page. If I were an admin, it would be important for me to watch the page. I'm not though. And watching the bot tidy up the reports 1000 times a day was more than I could stand. fredgandt 22:38, 11 December 2011 (UTC)
- Support, no good reason not to do this. There are plenty of circumstances where a user might want to follow changes to an article and not its talk page, or vice versa, and why shouldn't they be able to do so? Robofish (talk) 12:45, 7 December 2011 (UTC)
- Oppose only a small benefit, at the risk of considerably more complexity and potential for things to go wrong - such as you think you're watching an article, but you aren't. Grandiose (me, talk, contribs) 13:58, 7 December 2011 (UTC)
- Oppose It might lead to a user not seeing a question raised on a talk page about an article that is pertinent to them. If someone doesn't want to look at the talk pages (or vice versa) in their watchlist then they can just filter the Namespace themselves. Zangar (talk) 19:19, 7 December 2011 (UTC)
- If I just wanted to not watch one particular talk page, how could i do that by use of the current filters? That could only be done with a user script. This proposal is to add functionality for all users, not just those who manage to think of the idea, then find or write the script to allow it, fredgandt 22:45, 11 December 2011 (UTC)
- Oppose: would be too complex. Try to envision how "EditWatchlist" would look, and then think about Special:EditWatchlist/raw: do you want to have 3 separate textboxes: watching_main / watching_ talk / watching_both ? — AlexSm 19:52, 7 December 2011 (UTC)
- Support There are numerous pages where I want to be aware of changes to the text, but not participate in the voluminous discussions (much of the MOS, for example). DGG ( talk ) 04:04, 8 December 2011 (UTC)
- Oppose in principle. This will almost certainly result in even less discussion and collaboration. —Justin (koavf)❤T☮C☺M☯ 10:20, 8 December 2011 (UTC)
- Support, but it needs to go farther. We don't just need the ability to watch just the talk page or just the main page, but to watch just one section. Many times I have tried to watch one particular low-activity noticeboard case only to end up drinking out of a firehose as some unrelated case gets a large number of comments. --Guy Macon (talk) 18:55, 8 December 2011 (UTC)\
- Indeed, I'd love to be able to watch just one section of CFD, or ANI for instance. ♫ Melodia Chaconne ♫ (talk) 19:11, 8 December 2011 (UTC)
- Awesome idea! Maybe too far reaching for the tiny step society, but great if it could be added. Options are great if they don't actually do any harm. I fail to see how this could. fredgandt 22:32, 11 December 2011 (UTC)
- Support this, but not the main: Watching only a section of a talkpage would be great. You are right, this happens so many times. However watching either talkpage or the main page separately would be confusing. This specific suggestion should be applied as an opt-in (from preferences) as well. --lTopGunl (talk) 18:40, 13 December 2011 (UTC)
Oppose Increases user interface complexity for no apparent reason and proposer gives no rationale for this change other than "It would be nice on occasions".Switched to Neutral below. Toshio Yamaguchi (talk) 19:03, 8 December 2011 (UTC)- Why must I give a rationale? If you can see any value in the idea, support it. If you think it is harmful, oppose it. If you don't care one way or the other, don't comment. Why must people have to work so hard to impose thoughts on to other editors here? I propose an idea. How it sits in your head is your business. fredgandt 22:28, 11 December 2011 (UTC)
- You don't have to give a rationale. I don't think it is harmful, but I also think it is not useful, since I can think of no situation where I would ever want to watch only one of the two pages. Thus my 'Oppose'. If you have an example of such a situation, however, by all means feel free to present it and convince me otherwise. I just say that my oppose is rather weak. Some proposals might have a negative effect on the encyclopedia but I don't think that's the case here. I just wanted to make transparent why I oppose this proposal. Toshio Yamaguchi (talk) 22:56, 11 December 2011 (UTC)
- Plenty of examples have already been given, but I'll repeat a very obvious one I mentioned above -- Wikiprojects. I know I'm hardly the only one who never pays attention to what's on the 'project' page but is quite involved in the discussions in them. The other case, as I said above, is FA of the day; perhaps a better example, even, as on the day they are featured they get tons of edits, and I for one an often only interested in the talk page. ♫ Melodia Chaconne ♫ (talk) 04:52, 12 December 2011 (UTC)
- Personally not liking something does not strike me as fair grounds to oppose something. I am not Christian, but do not oppose others being Christian. If that's what they want to do, good luck to them! If however, I thought Christianity was dangerous or harmful (wow, that's a contentious subject right there), I would oppose it on the grounds that it would do that harm to others and future others. Analogy aside, if you see no harm in this, please don't oppose it. Just state your neutrality if you have to state anything at all. fredgandt 07:27, 12 December 2011 (UTC)
- You don't have to give a rationale. I don't think it is harmful, but I also think it is not useful, since I can think of no situation where I would ever want to watch only one of the two pages. Thus my 'Oppose'. If you have an example of such a situation, however, by all means feel free to present it and convince me otherwise. I just say that my oppose is rather weak. Some proposals might have a negative effect on the encyclopedia but I don't think that's the case here. I just wanted to make transparent why I oppose this proposal. Toshio Yamaguchi (talk) 22:56, 11 December 2011 (UTC)
- Why must I give a rationale? If you can see any value in the idea, support it. If you think it is harmful, oppose it. If you don't care one way or the other, don't comment. Why must people have to work so hard to impose thoughts on to other editors here? I propose an idea. How it sits in your head is your business. fredgandt 22:28, 11 December 2011 (UTC)
- Neutral Proposal says default will be watching both pages (which I wouldn't like to see changed) and one of the pages will not be watched only if the editor chooses to do, thus neutral, as some people seem to find it useful. Toshio Yamaguchi (talk) 08:00, 12 December 2011 (UTC)
- Absolutely. I wouldn't want the default to change either; that would get terribly confusing. This is just an available option to un-watch a page without un-watching its partner. I envisage a drop-down (open to ideas) like the "move" drop-down, that shows when hovering over the "this page is watched" icon (not when hovering over the "watch this page" icon) that gives the choice to un-watch the page without un-watching the other. If we were to click on the star as normal, the normal behaviour is carried out (both are un-watched). On a personal note Toshio, thanks for being such a good sport. fredgandt 10:03, 12 December 2011 (UTC)
- Support (Sort of) Wasn't there some talk of making it possible for a user to have a hotlist of pages that are really important to them? I for one would like to have pages I created appear bolded in my watchlist, rather like pages in my watchlist appear bolded in Recent changes. Perhaps a system could be developed along those lines? Speciate (talk) 05:19, 12 December 2011 (UTC)
- Although bolding preferred pages would conflict with other highlighting (proposed and presently implemented), I'd support a weakening (by fading to grey or reducing font size) of those pages we chose to un-watch as a compromise. I think though if the scripting was in place to allow that kind of marking (application of a class probably), it would make more sense to go the whole hog and not show those pages marked. fredgandt 07:27, 12 December 2011 (UTC)
- Neutral - I don't see any purpose in this, but, if other people want it, and it can be done, then fine. It doesn't matter that much.--Unionhawk Talk E-mail 13:10, 20 December 2011 (UTC)
Enable "Show changes since last visit" on watchlist
I propose that the option $wgShowUpdatedMarker be enable on the English language Wikipedia, as seems to be the default on many other projects. This will enable users to see which pages on their watchlist have been updated in a single glance. The default styling is to bold the page title, but we could style it any way we want, e.g. with a subtle background color instead. — Edokter (talk) — 14:10, 2 December 2011 (UTC)
- Support This feature is especially good for those who (like me) show all changes instead of just recent changes. And since it's just a matter of switching it on, there's no big fuss about how we go about doing it. A nice simple upgrade with the flick of a switch (kinda). fredgandt 19:16, 2 December 2011 (UTC)
- Comment This would be toggle-able yes? If so, there's no reason not to. If not, however, I would oppose on the grounds of stuff like that being annoying. ♫ Melodia Chaconne ♫ (talk) 20:48, 2 December 2011 (UTC)
- As the function almost only adds a class wrapper to certain entries in your watchlist, even if it weren't togglable, one line of css could override (I'm fairly sure but Edokter can confirm) the effects. So one way or another, yes. fredgandt 20:52, 2 December 2011 (UTC)
- Support I like this feature on other projects. I find it particularly useful when looking at history pages for active discussions, because I can't always remember how many of the recent comments I've already read. I've been wondering recently why it wasn't enabled on en.wiki. Are we too big, perhaps? WhatamIdoing (talk) 21:33, 2 December 2011 (UTC)
- Weak oppose - I know what's been different when I see my watchlist, and I don't need to be reminded. But I would support as an opt-in.Jasper Deng (talk) 23:41, 2 December 2011 (UTC)
- There's no opt-in, but as I said above, it's overridable. — Edokter (talk) — 00:15, 3 December 2011 (UTC)
- Not in a way that I could simply go to Preferences with. Not every user knows CSS.Jasper Deng (talk) 00:17, 3 December 2011 (UTC)
- There's no opt-in, but as I said above, it's overridable. — Edokter (talk) — 00:15, 3 December 2011 (UTC)
- The change could be opt-in. Nothing would change unless the class was given special treatment. If it was ignored there would be no visual change at all. If users then wanted to, they could use css to show the new feature, instead of css to override it. This is an option. Keep the ball rolling. fredgandt 00:38, 3 December 2011 (UTC)
- I think this would be very useful as a gadget (I'm sure no sysadmin intervention is needed for that, eh?). In that case I would support it.Jasper Deng (talk) 00:40, 3 December 2011 (UTC)
- Actually it is. That's why the proposal. In order for the correct class to be applied to the appropriate titles in our watchlist, we need part of the Mediawiki software to be switched on. It will then apply a span wrapper with a class attribute to all appropriate titles and we then use css to style that class. None of this can be done without the support in the PHP connection between us and the database. fredgandt 00:47, 3 December 2011 (UTC)
- The opt-out was what I was talking about here. Jasper Deng (talk) 00:50, 3 December 2011 (UTC)
- No, the opt-out can be done locally. But let's first focus on the general proposal. Styling (or opt-out) is always an option. — Edokter (talk) — 01:33, 3 December 2011 (UTC)
- I don't think it's a good idea but am not opposed to allowing other users have it, provided that I don't.Jasper Deng (talk) 02:15, 3 December 2011 (UTC)
- Jasper: Would you be opposed to
<s>...</s>
ing out your "weak oppose" and replacing it with "neutral" per your last statement? fredgandt 21:13, 3 December 2011 (UTC)- I cannot support this proposal if there won't be an opt-out.Jasper Deng (talk) 23:33, 3 December 2011 (UTC)
- Fair enough Jasper. Thanks for responding. Although, bare in mind (as discussed) there is a very simple way to override the effect even if it were installed without an opt-in. So opting out would be a doddle. fredgandt 23:45, 3 December 2011 (UTC)
- I cannot support this proposal if there won't be an opt-out.Jasper Deng (talk) 23:33, 3 December 2011 (UTC)
- Jasper: Would you be opposed to
- I don't think it's a good idea but am not opposed to allowing other users have it, provided that I don't.Jasper Deng (talk) 02:15, 3 December 2011 (UTC)
- No, the opt-out can be done locally. But let's first focus on the general proposal. Styling (or opt-out) is always an option. — Edokter (talk) — 01:33, 3 December 2011 (UTC)
- The opt-out was what I was talking about here. Jasper Deng (talk) 00:50, 3 December 2011 (UTC)
- Actually it is. That's why the proposal. In order for the correct class to be applied to the appropriate titles in our watchlist, we need part of the Mediawiki software to be switched on. It will then apply a span wrapper with a class attribute to all appropriate titles and we then use css to style that class. None of this can be done without the support in the PHP connection between us and the database. fredgandt 00:47, 3 December 2011 (UTC)
- I think this would be very useful as a gadget (I'm sure no sysadmin intervention is needed for that, eh?). In that case I would support it.Jasper Deng (talk) 00:40, 3 December 2011 (UTC)
- Strong support, this is the bare minimum of Watchlist usability, which is still not met. — Dmitrij D. Czarkoff (talk) 15:05, 3 December 2011 (UTC)
- Strong support, Kudpung กุดผึ้ง (talk) 16:34, 3 December 2011 (UTC)
- Strong support the minimal inconvenience of not retaining the status quo isn't a good reason for impeding progress which helps make editors more productive in their daily (or several times daily) routines. - ʄɭoʏɗiaɲ τ ¢ 19:15, 3 December 2011 (UTC)
- Support Armbrust Talk to me about my editsreview 21:42, 3 December 2011 (UTC)
- Support Helder 21:54, 3 December 2011 (UTC)
- Question. Some people seem to understand what this is supposed to do, but I don't. The description sounds as if it would make every line of the watchlist bold. What am I missing? On which other project(s) is this activated? Hans Adler 22:13, 3 December 2011 (UTC)
- When we visit our watchlist we see either the last changes to the pages we watch or (if chosen) all changes in chronological order that have been applied to those pages. With this functionality applied, what we see are all the same entries, but with some page title links highlighted (the style of highlight can be changed by CSS). Those that are highlighted are those pages we have not visited since the change indicated/reported. So, we view our watchlist changes at 1pm and see that we were the last person to edit Example. We then do some other stuff and come back at 2pm and see that someone has edited the page. Because we haven't yet revisited Example, it is shown highlighted. We then visit Example to see what has changed, and do some other stuff. We revisit our watchlist at 3pm and see that no one has edited Example since we visited it and there is no highlighting. So the highlighting is to let us more easily see those entries on our watchlist, that we have not visited since the last changes were made. A way therefore to keep track of which changes we have patrolled and which we have yet to.
- This functionality is being used on Mediawiki for example (and many others including commercial Wikis such as The Second Life Wiki).
- With this change to the watchlist there is also a new button. It is featured in the watchlist controls section above the entries. It (when clicked) allows that we can "Mark all entries as visited".
- We have yet to discuss what the style of hghlighting would be, but we should first discuss whether or not we want it. The class is already in use here, and can be seen highlighting (in bold) pages that we are watching, when we see those entries in Special:RecentChanges fredgandt 23:19, 3 December 2011 (UTC)
- Thanks for the explanation, and thanks Edokter for the pointer to Commons. I have tried it out now. I think if this were used here it would fundamentally change the way I am using my watchlist. At the moment, I load it once and then go throught it chronologically. With the new feature, I would probably go through my watchlist thematically and reload it all the time in order to see the markup change. If it's the same for others, this could increase server load. Maybe that's why it's currently turned off. Hans Adler 00:03, 4 December 2011 (UTC)
- I use JavaScript to update my Wacthlist every 60 seconds while I'm on that page. It also checks my Watchlist every 60 seconds while I'm not viewing it and shows me if it has changed by making a little box turn green (then it stops checking until I've looked at my Watchlist). I was unsure if this would be considered inappropriate use of the servers and asked Wikimedias top programmer guy what he thought. He said "Be bold! If there are any problems someone will let you [me] know.". fredgandt 00:11, 4 December 2011 (UTC)
- Thanks for the explanation, and thanks Edokter for the pointer to Commons. I have tried it out now. I think if this were used here it would fundamentally change the way I am using my watchlist. At the moment, I load it once and then go throught it chronologically. With the new feature, I would probably go through my watchlist thematically and reload it all the time in order to see the markup change. If it's the same for others, this could increase server load. Maybe that's why it's currently turned off. Hans Adler 00:03, 4 December 2011 (UTC)
- The option is enabled on Commons, Meta and MediaWiki, to name but a few. (BTW. Funny to see the class applied in RecentChanges.) — Edokter (talk) — 23:31, 3 December 2011 (UTC)
- I already checked, and the
<strong>...</strong>
tag carrying the "mw-watched" class can have its strength (boldness) overriden. The body of the "Special" pages each has their own class, so a change to how "mw-watched" is treated on Special:Watchlist does not have to apply to other uses of "mw-watched". I'm sure you (Edokter) already knew this but others reading this may not have. fredgandt 23:45, 3 December 2011 (UTC)
- I already checked, and the
- Support - overwhelmingly sensible. Pesky (talk …stalk!) 07:19, 4 December 2011 (UTC)
- I have listed this proposal at Template:Centralized discussion. Cunard (talk) 09:01, 4 December 2011 (UTC)
- Support This feature is enabled on Commons and I love it and find it extremely useful. On enwiki the only way I can be sure all the edits on my watchlist are new is to wait a few days :-P Dcoetzee 09:33, 4 December 2011 (UTC)
- Really? Do visited and unvisited links not show in different colors for you? ♫ Melodia Chaconne ♫ (talk) 14:56, 4 December 2011 (UTC)
- All the links are visited, because all pages on my watchlist are already in my history (because I've viewed them before). Dcoetzee 04:51, 6 December 2011 (UTC)
- Really? Do visited and unvisited links not show in different colors for you? ♫ Melodia Chaconne ♫ (talk) 14:56, 4 December 2011 (UTC)
- support, would be useful. sonia♫ 09:49, 4 December 2011 (UTC)
- Question One thing I was curious of -- is this a real 'last visited' type of tracking, where it actually resets if you aren't on WP for a couple hours, or does it only track what you actually visit (or use the 'mark as visited' button)? The later I can get behind much more, ESPECIALLY if it simply tracks if you've visited WP or not. I utterly HATE when the 'visited' flag is raised anytime you even step onto a website, but as my WP Watchlist is my home page, it often gets refreshed when I have to reset the browser because of an error, or have been streaming lots of videos, etc. Of course as I said above, it NEEDS to be a tolerable option rather than forcing it on everyone. ♫ Melodia Chaconne ♫ (talk) 14:56, 4 December 2011 (UTC)
- Yes please --Guerillero | My Talk 21:56, 4 December 2011 (UTC)
- I think that I support this proposal, although I find the explanation rather unclear and I'm not sure that I really understand it. At present, I keep track of what I've looked at on my watchlist by seeing the blue links turn that purplish color they turn when the browser (Firefox, in my case) has put the URL into history. If I understand correctly, this proposal would make that functionality more robust, which I would like, and there would be ways to opt out of it if I turn out not to like it. --Tryptofish (talk) 20:01, 5 December 2011 (UTC)
- There are only two ways you could have page title links change colour that way in your watchlist: 1) If you regularly clear your browsing history 2) If you add pages to your watchlist without ever actually visiting the page (possible by adding the titles to Special:EditWatchlist/Raw). This proposal is not to highlight what pages you have visted, but what pages have changed since you last visited them. Please see my explanation above. fredgandt 20:15, 5 December 2011 (UTC)
- I've read your explanation numerous times, and, well, I guess I support this proposal anyway. --Tryptofish (talk) 21:01, 5 December 2011 (UTC)
- There are only two ways you could have page title links change colour that way in your watchlist: 1) If you regularly clear your browsing history 2) If you add pages to your watchlist without ever actually visiting the page (possible by adding the titles to Special:EditWatchlist/Raw). This proposal is not to highlight what pages you have visted, but what pages have changed since you last visited them. Please see my explanation above. fredgandt 20:15, 5 December 2011 (UTC)
OpposeSupport - I want to oppose just to make a WP:POINTy edit to show that consensus doesn't have to be unanimous (as it almost is here), but I actually like this idea. Ian.thomson (talk) 20:10, 5 December 2011 (UTC)- Strong support A useful function, especially for those of us with longer watchlists. --Philosopher Let us reason together. 20:20, 5 December 2011 (UTC)
- Support, this would save me a lot of time, I am often unsure of what I have already checked on active pages. Peter (Southwood) (talk): 05:24, 6 December 2011 (UTC)
- Support. I love it in Commons and can't understand why it's not allowed here. Jim.henderson (talk) 19:31, 6 December 2011 (UTC)
- Comment. It seems that the majority of people want this enabled so I'd feel like a bit of a dick if I opposed. But if it is implemented, can it please be made opt-in? (Or, at the very least, make an easy way to opt-out – and by easy I mean something that doesn't require me to learn CSS). Jenks24 (talk) 00:42, 7 December 2011 (UTC)
- Support. I've found it extremely useful at Commons, and I've wished for a long time that we had it here. I'm not sure if it can be made optional, but I'd support making it so if it can be (why force something on Jenks24 that he doesn't want?), although the best situation in my mind would be to make it default with opt-out being a simple option in the Gadgets part of Preferences. Nyttend (talk) 03:35, 7 December 2011 (UTC)
- Support. I find it very handy on Commons. —Bruce1eetalk 06:07, 7 December 2011 (UTC)
- Support, but only if there is an easy option to toggle this either within Preferences, or on the Watchlist page itself, so users don't need an understanding of CSS to opt-in/out. But I've always wanted something like this. Zangar (talk) 09:34, 8 December 2011 (UTC)
- For those who don't like or want this, the css required to override the effect is minimal and will be made easily available by myself and others (should we have this feature enabled). For those who do not want to mess about with css, there will be a clearly labelled button on Special:Watchlist to "Marked all pages visited". One click of this and the stylistic change is immediately undone. So in effect there is a toggle to switch the effect off. If the feature is enabled, I would imagine the conversation would move to MediaWiki talk:Common.css, where the preferred default styling can be discussed along with other options. For example: If enabled, I will choose to set the style in my common.css. Some may prefer not to bother and use the default. Others may like neither the default or my style and want a particular style or have it overridden completely. I (and I imagine others) would be pleased to provide code for specific styles including full overriding. So all in all, if it is enabled, no one will have to put up with it if they don't want to. fredgandt 10:02, 8 December 2011 (UTC)
- Strong support - very useful for people with long watchlists, like myself. And can we make it optional? Sure. I suppose. And I think it'd be most useful for the savvy wikipedians, so I wouldn't be opposed to an opt-in.--Unionhawk Talk E-mail 19:39, 9 December 2011 (UTC)
- Support as a preference option - I think its more useful to more serious members. -- Eraserhead1 <talk> 22:01, 11 December 2011 (UTC)
- Strong support: I'm sure editors have better things to do than repeatedly check their watchlist timestamps and remember the last timestamp so as not to miss anything on their next login. Hope this highlighting won't require the watchlist to remain open and rather still show the highlightings that were supposed to be bold when signed in from a different terminal. I was wondering why wikipedia didn't have this feature! --lTopGunl (talk) 18:56, 12 December 2011 (UTC)
- Comments have slowed. With almost unanimous support, could we do the next step now? Who says what to whom about switching it on? fredgandt 18:09, 14 December 2011 (UTC)
- Indeed. No need to wait the full 30 days. I'll post a request at Bugzilla. — Edokter (talk) — 18:48, 14 December 2011 (UTC)
- Request has been filed. — Edokter (talk) — 18:54, 14 December 2011 (UTC)
- Indeed. No need to wait the full 30 days. I'll post a request at Bugzilla. — Edokter (talk) — 18:48, 14 December 2011 (UTC)
- Good to see the gears are turning already. I would strongly support this too; it would help the watchlist do what I really use it for (all too often I look at the last diff, then click through to the history to look at changes since I was last there...). bobrayner (talk) 19:53, 15 December 2011 (UTC)
Call talk pages "Talk"
RfC tag added on 09:01, 4 December 2011 (UTC).
Hi. A lot of Wikipedia instructions tell people to post "on the talk page". However, it isn't obvious where this means, since the page is not labelled "talk page" but is labelled "discussion". This is very confusing, especially for someone unfamiliar with all the Wikipedia rules. Wny not change the text on the tab from "Discussion" to "Talk page" to match all the instructions? (By instructions I am referring to everything you get when you click Help, as well as so many of the templates used to tell posters why their edit was not accepted and how to fix it. (184.147.120.119 (talk) 23:07, 2 December 2011 (UTC))
Just a note: the page which will need to be changed is MediaWiki:Talk. sonia♫ 09:48, 4 December 2011 (UTC)
At 17:14, 8 December 2011 (UTC) I changed the title of the post from 'Call talk pages "Talk Page"' to 'Call talk pages "Talk"', because there is a massive consensus among people supporting this change for using 'Talk' in specific and some opposition to 'Talk Page' in specific. Sven Manguard Wha? 17:14, 8 December 2011 (UTC)
- Support this one per 2011 "State of the Wiki" address. Rich Farmbrough, 23:39, 2 December 2011 (UTC).
- Support continuity I don't much mind which is prefered or even if another name like "chatter" or "gobledigook" (well maybe not) is chosen, but I do think we would be better off with one name for all "talk pages" across the whole site. fredgandt 00:42, 3 December 2011 (UTC)
- There is a 2007 discussion at Wikipedia:Village pump (proposals)/Archive AN#Talk Pages. PrimeHunter (talk) 02:20, 3 December 2011 (UTC)
- How about just calling it Talk. That one is even more heavily implied than discussion, although to me, discussion is so obvious that I feel this change is unneeded. Sven Manguard Wha? 02:53, 3 December 2011 (UTC)
- Uh, yes I didn't read properly. Talk is what I support. Rich Farmbrough, 13:04, 3 December 2011 (UTC).
- Uh, yes I didn't read properly. Talk is what I support. Rich Farmbrough, 13:04, 3 December 2011 (UTC).
- I support discussion. This is primarily because of the popularly brought up rule "This is not a forum for general talk about the article's subject". Georgia guy (talk) 14:31, 3 December 2011 (UTC)
- I support Talk because that's what most people call it anyway. @Georgia guy, talk and discussion are basically synonymous, so that rule could be changed to "This is not a forum for general discussion about the article's subject". There's not really any difference. Bazonka (talk) 17:28, 3 December 2011 (UTC)
- How about suggested improvements pages?? Georgia guy (talk) 18:25, 3 December 2011 (UTC)
- That is a little too specific. It would also only make sense for article talk pages. The proposal (I agree with in principal) is to name all talk pages the same way so that wherever users are guided to talk pages they are not confused by finding a "discussion" page but no "talk" page. fredgandt 18:57, 3 December 2011 (UTC)
- P.s. Also it would be a massive tab!
fredgandt
- How about suggested improvements pages?? Georgia guy (talk) 18:25, 3 December 2011 (UTC)
- I support Talk because that's what most people call it anyway. @Georgia guy, talk and discussion are basically synonymous, so that rule could be changed to "This is not a forum for general discussion about the article's subject". There's not really any difference. Bazonka (talk) 17:28, 3 December 2011 (UTC)
- Support. I've idly wondered about why this isn't labelled "Talk" on and off for years. Thryduulf (talk) 01:59, 4 December 2011 (UTC)
- Strong support for Talk page. I have also wondered about this many times myself. It may also be confusing for non native speakers. Kudpung กุดผึ้ง (talk) 02:28, 4 December 2011 (UTC) - or just simply 'Talk'. Kudpung กุดผึ้ง (talk) 06:16, 4 December 2011 (UTC)
- Support "Talk". The name "discussion" is simply never used for talk pages, so it is simply counterproductive to use it in the most prominent place of all. 124.168.87.221 (talk) 05:29, 4 December 2011 (UTC)
- Support. Improving clarity is rarely a bad thing, and I can't remember ever seeing "discussion" used except in the tab. Alzarian16 (talk) 06:14, 4 December 2011 (UTC)
- Support "Talk". As pointed out previously, it's the most commonly used term for the page, so it would be the most user-friendly.--JayJasper (talk) 06:20, 4 December 2011 (UTC)
- Minor Oppose I don't want to be the lone dissenter here....and my reasons are mainly aesthetic. On places where it DOES say 'talk' it just kinda looks...off. It's probably just a matter of getting used to one over the other, but also the word 'discussion' seems to carry a better connotation, IMO, than 'talk'. ♫ Melodia Chaconne ♫ (talk) 07:05, 4 December 2011 (UTC)
- Don't worry Melodia, you're not alone. I've already stated my feelings but not my personal preference, since my preference goes against what I see as the best course of action (if any). I prefer "Discussion" too, but as is being mentioned time and time again here, "Talk" is a colloquialism we can't escape. If this proposal has any value (and I believe it does), it will be to set a standard, continuous use of one word across the site. If we were to choose "Discussion", we would have to change so many policies and templates etc. we would get nothing else done for years. Quite simply, "Talk" is too engrained to oust now, so supporting continuity may mean not getting the word we prefer, but we do get less confusion. fredgandt 07:37, 4 December 2011 (UTC)
- Support Many templates use "see the talk page" or similar for direction, and it's more common to see "talk page" in discourse than "discussion page". Do international language versions of Wikipedia use the same word? In any case, it feels more natural and intuitive to use "talk" and I fully support the motion to change it doktorb wordsdeeds 07:12, 4 December 2011 (UTC)
- Strong support for "talk". It should be labelled as what we call it to avoid completely unnecessary confusion (I'm thinking especially of non-native English speakers, as well as newbies who didn't get enough sleep last night) - and it's always called "the talk page". Pesky (talk …stalk!) 07:15, 4 December 2011 (UTC)
- Strong Support Talk- been waiting for this for a long time. New people only realizes it's the "talk page" after they click the tab and see the page is actually called the "talk page". Plus all our "informative" pages call it "Talk page" like with Wikipedia:Talk page guidelines - Help:Using talk pages - Wikipedia:Talk page layout - Wikipedia:Talk page templates. So lets not confuse our editors right off the bat when there reading introductory pages. Lets make it all match. Moxy (talk) 07:27, 4 December 2011 (UTC)
- I have listed this proposal at Template:Centralized discussion. Cunard (talk) 09:01, 4 December 2011 (UTC)
- Support. "Talk page" is a jargon term, which we should normally avoid in the UI. The name "discussion" is more accessible. But considering how likely it is that we'll change all the help pages, policy pages, and user comments to stop saying "talk pages" (read: will never happen), this is the more prudent alternative. Dcoetzee 09:36, 4 December 2011 (UTC)
- Weak support "Discussion" makes a bit more sense especially to the newcomer than the (relatively vague) "talk", but "talk pages" is simpler and easier for most purposes. sonia♫ 09:48, 4 December 2011 (UTC)
- Weak oppose. If I remember correctly, the tabs for the talk pages were labelled "Talk" when I joined the project. I think it was changed along with the switch from Monobook to Vector, and I think this particular change was based on the findings of the usability project. Apparently, we used to have a lot of readers who had no idea that Wikipedia articles have associated discussion pages and had no desire to try out the cryptic "Talk" tab. Hans Adler 13:57, 4 December 2011 (UTC)
- This was not as you describe. Some versions of Twinkle and Friendly used to include a script which changed the title of the "discussion" tab to "talk". This script was disabled a while back (around the time of the change to Vector). — This, that, and the other (talk) 04:10, 5 December 2011 (UTC)
- Strong support Talk for the sake of consistency with namespace: Talk:Example suggests the link to Talk page. Calling things by their names is an important aspect of usability. — Dmitrij D. Czarkoff (talk) 16:05, 4 December 2011 (UTC)
- Support. PaoloNapolitano 16:36, 4 December 2011 (UTC)
- Oppose On the contrary, we should change the help, docs, etc. to speak of "discussion pages" rather than "talk pages". "Discussion" seems to make more sense as a descriptor, particularly for outsiders. --Cybercobra (talk) 21:37, 4 December 2011 (UTC)
- Discussion name has already failed replacing the Talk name in general use. No need to revive dead. — Dmitrij D. Czarkoff (talk) 10:29, 5 December 2011 (UTC)
- Tentative support, but also question for clarification: are we talking only about the link in the tab row at the top of each page, where it now says "Article | Discussion" or "Project page | Discussion", or is "Discussion" also found somewhere else? If it's only that one link, I'd go for changing it, for consistence with the actual namespace labels, but perhaps go for "Talk page" rather than plain "Talk". Fut.Perf. ☼ 21:47, 4 December 2011 (UTC)
- Just that tab link I believe, and the original proposer did say "talk page", although it's gotten a bit garbled along the way. sonia♫ 22:06, 4 December 2011 (UTC)
- Yes, I am the proposer and that is what I meant. "Talk" would be just as clear. I am glad the idea has support. What happens next? Do I have to request anyone in particular anywhere in particular to make the change? Or do I wait more time and then request? Or something else? Thank you everyone for understanding. (184.147.120.119 (talk) 02:11, 5 December 2011 (UTC))
- Here's what happens next. This change appears to have significant support, so this discussion has become a request for comment to get input from the broader community. It will run for 30 days gathering input. After the 30 days, somebody that hasn't participated in the dicussion will judge the consensus and close the discussion with a summary of what the community has decided. If there is consensus for the change, somebody will file a Bugzilla request to have the software changed to make the pages show talk instead of discussion. That may seem like a long time, but once started the process runs until it's completed. So you aren't required to do anything else, but you are certainly welcome to if you'd like to. Best regards. - Hydroxonium (T•C•V) 04:30, 5 December 2011 (UTC)
- This does not require a bugzilla request or a software change. An admin can just modify Mediawiki:Talk to make the change. --Yair rand (talk) 04:35, 5 December 2011 (UTC)
- Cool, thanks for the info. (184.147.120.119 (talk) 22:16, 5 December 2011 (UTC))
- Here's what happens next. This change appears to have significant support, so this discussion has become a request for comment to get input from the broader community. It will run for 30 days gathering input. After the 30 days, somebody that hasn't participated in the dicussion will judge the consensus and close the discussion with a summary of what the community has decided. If there is consensus for the change, somebody will file a Bugzilla request to have the software changed to make the pages show talk instead of discussion. That may seem like a long time, but once started the process runs until it's completed. So you aren't required to do anything else, but you are certainly welcome to if you'd like to. Best regards. - Hydroxonium (T•C•V) 04:30, 5 December 2011 (UTC)
- Oppose The argument is flawed because in many pages, we tell users to look at the "discussion page". "Discussion" is much much more easy to understand than "talk" for a new user—what's a "talk page"? Do we call conference rooms "talk rooms" or forums "talk boards"? Discussion is more newbie-friendly; if we need to reword help pages, then we should do that to make it more sensible in the long run. /ƒETCHCOMMS/ 02:37, 5 December 2011 (UTC)
- In which pages do we tell users to look at the "discussion page"? Thanks, —{|Retro00064|☎talk|✍contribs|} 05:26, 5 December 2011 (UTC).
- There are some that refer to the "discussion page", that is true. But there are far, far more that refer to the "talk page". Take a look around. — This, that, and the other (talk) 06:30, 5 December 2011 (UTC)
- "Discussion page" results, etc. Just because more pages use "Talk" over "Discussion" is no reason to change to "Talk". "Discussion" is far more understandable to new users—and that's what counts, no matter how many changes we have to make on our end. We must make Wikipedia simpler to understand and navigate for newbies. /ƒETCHCOMMS/ 15:23, 5 December 2011 (UTC)
- There are some that refer to the "discussion page", that is true. But there are far, far more that refer to the "talk page". Take a look around. — This, that, and the other (talk) 06:30, 5 December 2011 (UTC)
- Hey, come on! Both talk and discussion describe the same process. The difference is too small. — Dmitrij D. Czarkoff (talk) 10:29, 5 December 2011 (UTC)
- In which pages do we tell users to look at the "discussion page"? Thanks, —{|Retro00064|☎talk|✍contribs|} 05:26, 5 December 2011 (UTC).
- Support. We should name it what we call it. Kaldari (talk) 03:10, 5 December 2011 (UTC)
- Comment - I would absolutely love for this to happen. Absolutely.--Jorm (WMF) (talk) 05:02, 5 December 2011 (UTC)
- Support: (edit conflict) It would make sense to have consistency between what the tab's text is and what users refer to the page as. It seems to me that "talk page" is the common term, so if we are going to continue to use "talk page" in our comments, help and policy pages, templates, etc., then we should change the tab to say "talk" or "talk page" to achieve that consistency. If we are going to continue to have the tab say "discussion", then we should actually start calling the page to which it links the "discussion page" instead of the "talk page" in our comments, help and policy pages, templates, etc. Regards, —{|Retro00064|☎talk|✍contribs|} 05:26, 5 December 2011 (UTC).
- Support "Talk" for consistency and clarity reasons. --TorriTorri(talk/contribs) 06:37, 5 December 2011 (UTC)
- Oppose The word talk is misleading because we don't talk there; we write. Readers might confuse this with an audio interface such as Siri. Warden (talk) 09:30, 5 December 2011 (UTC)
- This is actually a good argument for renaming the whole talk namespace to discussion. Good luck getting consensus on that though. Yoenit (talk) 09:33, 5 December 2011 (UTC)
- Actually I hadn't considered that: "talk" could give the misleading impression that it is possible to hear the article read out to you by clicking that tab. Make of that what you will, though. — This, that, and the other (talk) 10:33, 5 December 2011 (UTC)
- Support But "Talk", not "Talk page". The latter is ghastly. If you prefer "Discussion", I'm sure we can write some CSS/JS to give you the old style. —Tom Morris (talk) 14:48, 5 December 2011 (UTC)
- Neutral If you are concerned about 'Talk' being an audio interface, then you could change the tab to Discuss, though it's not as friendly as Talk. Whatever is the consensus is fine, but I do agree that consistency is best either way. ʘ alaney2k ʘ (talk) 17:05, 5 December 2011 (UTC)
- Strong Support for "Talk". Click on "Discussion", and what does it take you to? A page that has the title "Talk:Page" right there at the top. The proposal makes very good sense, per the principle of least surprise. I've also noticed when I talk to non-editors in real life that when I explain to them how we use talk pages, they ask me how they can find the talk page for a given article. I find that I have to tell them to click on "Discussion", and that's the way to get to "Talk". Admittedly, it's not that hard to figure out, but it really is more user-friendly to make this change. --Tryptofish (talk) 20:09, 5 December 2011 (UTC)
- Support with comments - I agree that if someone wants to call their talk page something else its fine and that the default would be better as Talk page. However, it would be fairly easy to create a script to rename the page so an individual can call it whatever they want (i.e. talk, Talk page, discuss, etc). --Kumioko (talk) 21:49, 5 December 2011 (UTC)
- Support new, and especially foreign language editors are often confused about our nomenclature. We need to be consistent, and it's typically easier to change a label than to change what many people call them. Buddy431 (talk) 00:05, 6 December 2011 (UTC)
- I'm in favor for consistency, but then we should go with Discussion. It describes the function of the page much better than the vague 'Talk' . —TheDJ (talk • contribs) 00:18, 6 December 2011 (UTC)
- Oppose - Fetchcomms is right, 'talk page' is not user friendly, actually it's such a weird name that if I were not a regular Wikipedia I would probably be confused as to what it means. In fact just a few days ago I changed my signature and talk page header from 'talk' to 'contact' for this reason. If the problem is the lack of consistency referring to the namespace, then the change is needed at the help page level, not in the display tabs. For what it's worth, I would support moving the namespace to
Discussion:
; in the meantime I will oppose changing the displayed tab to "talk page", as 'discussion' is much more straightforward. CharlieEchoTango (contact) 08:14, 6 December 2011 (UTC)
- Many people at first do not know what "wiki" means, and they also learn what "talk page" means. -Wikid77 13:32, 6 December 2011 (UTC)
- So you're saying that new users should just learn random things about how Wikipedia works before contributing? Just because people learn what "talk page" means later does not mean we should expect people to take the time to figure that out before they get impatient and just give up. /ƒETCHCOMMS/ 01:42, 7 December 2011 (UTC)
- Many people at first do not know what "wiki" means, and they also learn what "talk page" means. -Wikid77 13:32, 6 December 2011 (UTC)
- Strong support "Talk". The menu option "Talk" is shorter than "Discussion" and the term "talk-page" provides a distinctive, while still short, name for such wiki-pages. A Google search for "talk-page" reveals it is closely linked (80%) to wiki websites, whereas a search for "discussion page" reveals wide, rambling use in many other websites, with no specific meaning as to what "discussion" entails. For over 6 years, many Wikipedia users have understood that a "talk-page" is not an open forum to blog about ideas; however, "discussion" might be imagined as a different type of page, perhaps open to blog-forum posts or other general discussions. Name the menu tab "Talk" to be more precise and avoid confusion. -Wikid77 13:32, 6 December 2011 (UTC)
- Support for the purpose of consistency, I support "talk". "Discussion" is overly long and the page is called a talk page, not a discussion page. We shouldn't rename the talk namespace to discussion though. Talk and Discussion have the same meaning, the only difference being "Discussion" is much longer lengthwise. Alpha_Quadrant (talk) 17:48, 6 December 2011 (UTC)
- Support. - Dank (push to talk) 18:50, 6 December 2011 (UTC)
- Comment - Classic skin (which doesn't have tabs) links to talk pages in the sidebar with the link Discuss this page. Would there be any change to this? — An optimist on the run! 21:38, 6 December 2011 (UTC)
- Question How would this affect Monobook? I like the idea for the default skin, since it's simpler for people not already familiar with Wikipedia, but I prefer "discussion" for my own purposes simply because I'm accustomed to it. Nyttend (talk) 03:40, 7 December 2011 (UTC)
- Support "Talk" - as a volunteer in #wikipedia-en-help connect, I've found that many new users find it disorienting when we direct them to the "talk page". Often, the reaction is "Wait, where is that?" and we have to explain how "discussion" == "talk". ~ Matthewrbowker Say hi! 05:42, 7 December 2011 (UTC)
- Support Talk Per common name, common sense, it's shorter, it's more inviting, it's consistent with the namespace. A small step towards UI sanity. Ocaasi t | c 07:29, 7 December 2011 (UTC)
- Support this obvious and long-overdue change. I don't know what caused it, but I'm impressed by the sudden outbreak of common sense in this thread. Robofish (talk) 12:42, 7 December 2011 (UTC)
- Support talk An obviously good idea--why was this ever changed to "discussion?" —Justin (koavf)❤T☮C☺M☯ 10:18, 8 December 2011 (UTC)
- Support, although I also think its neither here nor there. Even if English is not your first language, if you can't find the "talkpage" by clicking on the word "discussion", you should probably think about whether editing Wikipedia is the best use of your time. --FormerIP (talk) 18:49, 8 December 2011 (UTC)
- Oppose, though I would support a broad effort to update references to "talk pages" to "discussion pages". Not sure on the namespace; I don't think keeping it "Talk" is necessarily confusing. Powers T 19:13, 8 December 2011 (UTC)
- Oppose I don't mind informal mentions and references to talk pages, but changing the actual tab seems to imply (intentionally or otherwise) a morphing of the pages' purpose, to general debate about the article rather than for content development as it is now. That's an erosion of wp:NOTFORUM. 66.127.55.52 (talk) 17:42, 9 December 2011 (UTC)
- Support Talk - It's a common name, and it's more consistent with the namespace and what everyone calls it. Very rarely have I ever seen someone say "discussion page".--Unionhawk Talk E-mail 19:34, 9 December 2011 (UTC)
- Support–It's not only far more commonly used, it's also the name of the namespace. "Discussion" does sound a bit more formal, but the consistency with most usage and with the namespace system makes it preferable to me. oknazevad (talk) 14:22, 10 December 2011 (UTC)
- Oppose I prefer keeping it "Discussion" especially for new readers and editors. In many dialects of English talk and discussion are not the same thing. Discussion implies for many of us civil, rational analysis and discourse. It is not surprising that in shorthand discussions talk is used more often than discussion; it is shorter. That does not mean we should formally accept "Talk" as the default tab. There should be no problem in providing an optional display for those editors who wish to use a "Talk" tab. But for new users "Discussion" is clearer and more appropriate. --Bejnar (talk) 22:18, 10 December 2011 (UTC)
- On the other hand, when we say "talk page" all the time, when several of the templates we use (such as {{Expert-subject}}) say "talk page", and when all the namespace names use the word "talk", it probably makes it confusing to new editors when the tab doesn't also say "talk". and while the second and third could be fixed, the first can't - both because we would need to go through all the pages in the Discussion: namespace, the User discussion: namespace, etc. to fix them, and since users are so used to using this term that they will keep doing so, even to new users. עוד מישהו Od Mishehu 09:01, 13 December 2011 (UTC)
- Support - Neither term is precisely correct, and arguments could be made either way. "Discussion" is not precisely correct, because a user talk is not for discussing the user or the user page. It's important to keep things simple, and consistent. Any potential benefit of "discussion" being more clear than "talk" is lost through the constant confusion (new) users have, wondering what we mean by a "talk page". Especially when their own 'user talk' is called what it is. The word "talk" is short, snappy, matches the internals, and isn't all that mystifying. Keep it simple. I think this is a classic case where a 'usability study' did not truly consider all ramifications of a change - if we were designing a new mediawiki from scratch, we might go for 'discussion' - but we're not; "talk" is ingrained into our culture; it is unrealistic to change "talk" to "discussion" in every place (indeed, for historical discussion, it's effectively impossible). Changing "discussion" (tab) to "talk" is simple. Chzz ► 00:30, 11 December 2011 (UTC)
- Support - For consistency with the mainspace and with what we actually call it, and to be less confusing to newcomers. I think their nature won't change regardless of what is actually written on the tab, so no possible harm done. Zidanie5 (talk) 13:02, 11 December 2011 (UTC)
- Support unless we are going to change the talk namespace to be a discussion name space. The current setup is unclear. -- Eraserhead1 <talk> 22:03, 11 December 2011 (UTC)
- Support, since the page in question is always Talk: (or NamespaceName talk:), not Discussion:. עוד מישהו Od Mishehu 09:11, 12 December 2011 (UTC)
- Support - greater consistency; less likely to cause confusion among newer users. Chris (talk) 00:22, 13 December 2011 (UTC)
- Oppose. In simple, it makes sense. Here, no. theMONO 03:11, 13 December 2011 (UTC)
- Here, we talk about "talk pages", not "discussion pages". And the namespaces of these pages all use the word "talk", never "discussion". עוד מישהו Od Mishehu 05:31, 13 December 2011 (UTC)
- Oppose Instead of changing the tab labels, we should rename the namespace from Talk to Discussion. Why? Because I think it is more natural to advice someone to participate in an article discussion by editing the discussion page and talk gives a stronger impression that the page is for general talk about the article topic. Should I make a counter proposal to rename the namespace? Toshio Yamaguchi (talk) 16:21, 13 December 2011 (UTC)
- I, personally, could only support that if you can also have all past discussions changed from "talk page" to "discussion page", and make sure that all Wikipedians, including those who happen to be on Wikibreak in paralell to the discussion, will use the word "Discussion page" in stead of "talk page" - and I don't think that you could do that. עוד מישהו Od Mishehu 16:25, 13 December 2011 (UTC)
- Support. Strongly needed. Rcsprinter (gas) 16:42, 13 December 2011 (UTC)
- Oppose per most of the other oppose reasons. That and I just like the way it is now. - Purplewowies (talk) 17:20, 13 December 2011 (UTC)
- Ovbious Support. Well, yes. It seems obvious that some people who are unfamiliar with Wikipedia, might say, "Talk page? Where's the talk page?" and all they would see is "Discussion". All I'm saying is that it seems obvious. yrtneg talk contr 23:19, 13 December 2011 (UTC)
- P.S. I also oppose this in some matter, such as the word "discussion" being more, eh, mature than "talk". My vote is now neutral. yrtneg talk contr 23:19, 13 December 2011 (UTC)
- Comment. Did nobody read two week ago's signpost, where it becomes clear that such inconsistencies are exactly (one of) the kind of difficulties newcomers are experiencing, or why is it that this is not mentioned a single time? Unfortunately, topics like these always result in wikiarguing, so I prefer abstaining from further input on this. Nageh (talk) 23:32, 13 December 2011 (UTC)
- support duh. It is the talk page. Protonk (talk) 05:10, 14 December 2011 (UTC)
- To people seriously think that the tab being called discussion somehow elevates the level of discourse on the page? And that the solution is to change the namespace to "discussion"? Even worse, are people serious in renaming both to "collaboration" or something likewise obfuscatory and multi-syllabic?! That's pretty surprising, so I apologize for my incredulity. It seems to be much easier to change the site CSS to say "talk" than change every single link and mention of the talk namespace in order to satisfy our sense of superiority. The only cogent argument I can see against using "talk" is that it mischaracterized what actually goes on in talk pages--we don't "talk", we write. But that seems needlessly pedantic. I guess we can chalk this up to the community's willingness to accept the status quo because they are used to it, consequences for new users be damned. Protonk (talk) 23:44, 16 December 2011 (UTC)
- Support That was one of my first questions when I discovered non-Mainspace Wikipedia. BTW, it's already done over at the Simple English Wiki. Zlqchn (talk) 12:44, 15 December 2011 (UTC)
- Oppose; discussion was never a good alternativ to talk - same problems. I suggest Collaboration - and change the Namespaces accordingly (I think we can set up a namespace redirect from Collaboration->Talk and change relevant links). Then make an effort to stop saying "talk page" :) --Errant (chat!) 13:06, 15 December 2011 (UTC)
- Oppose. I oppose for reasons of dignity and the value of description. "Discussion" is a nicely dignified word, appropriate for the prominent position given to it on each article in this encyclopedia. "Talk", in the sense of discussion, as opposed to exposition or demonstration, seems quite the opposite. And "discussion" is a better descriptor, in part because "talk" can only clearly have a sense which is general for the page. Click on the "discussion" link and you are brought to a page which hosts a discussion, a particular discussion. You are not brought to a page which hosts a talk, unless one takes "talk" in an obscure sense for such a usage. Even in the case of their general senses, "discussion" seems to be a better descriptor. What happens, or is supposed to happen, on the page, "discussion" accurately describes that; and that is a discursive conversation in any medium focused on a particular matter. "Talk" can have a sense which can refer to such a thing by subsuming it under a more general heading, but as such it does not pick out it so specifically. Lastly, "talk" having many other senses, if it is taken in these, it is prevented from referring to such as "discussion" does. This last point has been partly illustrated above by others.--Atethnekos (talk) 03:43, 16 December 2011 (UTC)
- Support—aside from consistency, it's more inviting to newbies to see a tab that says "talk". Tony (talk) 10:55, 18 December 2011 (UTC)
- Support This would make things easier for new editors, and would have some consistency when linking to the talk page. And changing the name to something different than "disucssion" or "talk" and trying to get editors to change their habits is untenable. Let's call a spade and spade. Angryapathy (talk) 15:06, 19 December 2011 (UTC)
- Support: I found this slightly confusing when I first started editing, and I have seen cases of new users not understanding what the "Talk" page was or how to find it because it was labelled "Discussion". The pages are actually named "Talk:" in the urls, links, and search box. We could easily change any mentions of "Discussion" pages in the Help section etc to "Talk"; I think that a majority already refer to "Talk". If some people think that "Discussion" is clearer or sounds "better" I don't see that as rationale to leave the current fractured terminology the way it is. And it would be a whole lot easier to change everything to "Talk" than change everything to 'Discussion". And "Talk" is already the term most users use in posts. -MsBatfish (talk) 01:02, 20 December 2011 (UTC)
- Support the use of "Talk:". It's confusing for new editors when they try to search for the talk page and all they find is "Discussion". In addition, FWIW, it has already been changed to "Talk" for User talk pages. —mc10 (t/c) 17:25, 20 December 2011 (UTC)
- Support - There is no word that can make what happens on those pages dignified, we might as well be consistent. ▫ JohnnyMrNinja 18:21, 20 December 2011 (UTC)
Insert-able edit points without creating a new section
Proposal to create a new magic word we can insert into long threads to create an [edit] link without creating a new section.
- I envisage being able to add the magic word (e.g. {{EDITPOINT}}) anywhere within a section, and have an [edit] link created at that point in the thread (floated to the right of the page as with all normal edit links). This would not create an {{anchor}}, section or subsection heading, or be recognised by the toc.
- When followed, the editor would be presented with an edit page populated by all the text of the section the EDITPOINT is in,
from that point onward(including text in sub-sections),as would be normally expected, but not any text from that section that is above the EDITPOINT.An alternative to this would be that all text from that section is presented as normal, with the exception thatthe raw text is then automatically scrolled to the point at which the EDITPOINT is featured.This may be a more practical and appealing usage, but may have technical difficulties the primary proposal doesn't.
- The reasoning is that when wanting to edit half way through a long section, we are presented with the whole section and its subsections, with little to no obvious indicators throughout the unformatted raw text to follow in order to find the point at which we wished to make our edit.
- With EDITPOINTs inserted at intervals, we could access the section far nearer to the point we wish to edit than at present. We could simply use the nearest EDITPOINT that is above the focus of our attention.
- I believe this would make editing easier, would be relatively simple to create and install, and would have few downsides.
- There is one obvious possible downside: Overuse. A simple solution for this is to Assume good faith. A more cynical approach might be to allow only a given number per section. Uses of templates are already limited (good thing too), so the scripting is almost entirely in place to handle the task already. This possible downside (even if not monitored or controlled by the software) is as easily dealt with as all other editing faux-pas, so would cause little extra work for guardians.
- Summary: A simple new mark-up that creates an [edit] link without creating a section. When followed, the editor gets an edit page populated by all text from the section the EDITPOINT is in, but automatically scrolled to the point in the raw text where the EDITPOINT used is situated.
only from that EDITPOINT onward.This would make it easier to hone in on the point in that thread we wish to edit (reduced searching of the raw unformatted text).
- Thanks for reading. fredgandt 08:43, 4 December 2011 (UTC)
Questions about EDITPOINT
Questions: I am concerned that the feature would just be used to make every paragraph an EDITPOINT and deter people from making logical section headers, as they would have in the past.
- Q1: Would points be overused, and flood a page with [edit][edit][edit][edit][edit][edit]?
- Q2: Since headers were no longer needed, would header titles suffer?
- Q3: How about create non-indexed headers "==Break2=={{nonindex}}" shows header "Break2" as [edit] but not in Table-of-Contents box?
- Q4: Should a page be "fractionalized" instead, by a menu option "Fract" which re-displays the page with dozens of "[edit]" links, for each paragraph of the page (with no need to embed editpoints)?
- Q5: How would a page redisplay to the edited thread unless editing by header? I do not think it could, and after an edit, the page would display to the top and no longer jump down to the section just edited.
Those are some other questions to consider before stating Support/Oppose. -Wikid77 14:27, revised 18:23, 6 December 2011 (UTC)
Compare to header [Edit] as a name: The concept is intended to not list any EDITPOINT headers in the Table-of-Contents box. However, that it might be ok to name a small section header as "====[Edit]====" to show a left-side "[Edit]" break (with a right-side "[edit]" button). For example, there is an header as "[Edit]" here:
[Edit]
This section, with header "==== [Edit]====" is a 4th-level header which clearly indicates that it can be edited, without needing to create an {EDITPOINT} marker here. However, the header "[Edit]" will also appear in the Table-of-Contents box, above. Logically, users might see such break points are obvious edit-buttons, without the need to conceal editpoints. As more users insert headers named "[Edit]" as text edit-points, then the concept would be understood more widely, without adding special features. Does that seem like a good idea? -Wikid77 18:18, 6 December 2011 (UTC)
Support/Oppose of EDITPOINT concept
- Strong support - eminently sensible. Pesky (talk …stalk!) 08:53, 4 December 2011 (UTC)
- Support. Seems like a good incremental short term solution, and I'm pretty confident it could be implemented easily (but would require minor Mediawiki code changes). Some concerns: if the page is very large, including all text all the way to the end might be too much text. Perhaps just to the end of the section? Also, should the {{EDITPOINT}} tag itself be included or not? How would edit conflicts be handled? Alternatives: I think the better long-term solution here is a real in-place WYSIWYG editor that lets you edit as you read without switching views or formats, but that's a long way off and very hard to get right. As an intermediate alternative, it might be nice if there was some kind of "edit here" feature that let you just right click any piece of text and choose "Edit here" and it would open up an editing view scrolled directly to that location. Dcoetzee 09:25, 4 December 2011 (UTC)
- As I see it, this is a small step in the right direction, not a giant leap. I proposed that the text presented in its raw format is all the text from the section the EDITPOINT is in, from that point onward. Edit conflicts would be dealt with in exactly the same way as they are now. This is basically just an invisible section heading that even the toc doesn't see. The actual tag would of course be visible in the edit window, otherwise nobody could ever remove or more them. fredgandt 09:54, 4 December 2011 (UTC)
- Support. The number of times I'd have used this recently just at WT:NOT would have saved me a good hour at least (not including fewer edit conflicts). Thryduulf (talk) 12:45, 4 December 2011 (UTC)
- Weak support: to me it seems that those edit points are useful before inserting them, not after; another concern is that the articles would get littered with edit points. Still, that might be useful, so why not? Though I would prefer an option to add (visually) tiny edit point to every block element on the page. — Dmitrij D. Czarkoff (talk) 13:27, 4 December 2011 (UTC)
- What do you mean by "block element"? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- It was about HTML elements with block properties, though I get that Mediawiki abuses HTML markup, so this could be limited to the topmost sub-elements of the article (each text block, blockquotes, etc...) — Dmitrij D. Czarkoff (talk) 16:09, 4 December 2011 (UTC)
- What do you mean by "block element"? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- Comment: this isn't going to happen; the devs will say it's covered by LiquidThreads, and anyway editing is based fundamentally on sections, so the best you can do is scroll to a pre-specified point in the wikitext. That latter idea though can be done by a script. The timestamp with (UTC) at the end of each signature is fairly unique; a script could add a little mark at the end of each (UTC), and when clicked it goes into edit mode and searches for that timestamp in the wikitext. Rd232 talk 13:45, 4 December 2011 (UTC)
- Is liquid threads ever coming though? It's being trialled on some user talk pages on Wiktionary, but it's not ready for general release yet and hasn't had any significant changes for a couple of years. It's good in theory, but I've yet to be convinced it will actually do what it's trying to do. So in the meantime, why not implement this interim proposal that is technically possible without requiring years of development? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- Well for one thing, the client-side script I suggested would be a better solution than the magic word. For another, I severely doubt that if a bug was filed today it would result in a change to Wikipedia's functionality in less than 2 years, even if the developers agreed in principle. Developer time is simply too limited. Rd232 talk 19:39, 4 December 2011 (UTC)
- The Extension:LiquidThreads is being rewritten, and you can follow the status of the LiquidThreads 3.0 development on this page: mw:LiquidThreads_3.0/status#2011-10-31. Helder 22:20, 4 December 2011 (UTC)
- LiquidThreads is for discussion pages, not articles... I don't see the relevance. Dcoetzee 04:49, 6 December 2011 (UTC)
- Is liquid threads ever coming though? It's being trialled on some user talk pages on Wiktionary, but it's not ready for general release yet and hasn't had any significant changes for a couple of years. It's good in theory, but I've yet to be convinced it will actually do what it's trying to do. So in the meantime, why not implement this interim proposal that is technically possible without requiring years of development? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- Rd232 is correct: whatever the merits, this proposal will not be implemented. For one thing, inserting "===Break 1===" is almost equivalent (yes, it's not the same and has defects, but it's very similar). Re LiquidThreads: That's the knockout; devs would not want to work on some tweak that would be obsoleted by LQT. My opinion: LQT would kill good editors, and I hope the community manages to repel it (in brief: too obtrusive; encourages "this is a forum"; POV pushing would never end; too hard to remove unhelpful comments). Johnuniq (talk) 02:25, 5 December 2011 (UTC)
What about automatically inserting edit points every x bytes in a section over a length of y bytes? That way it would be impossible for people to go nuts with it. Add an option to show/hide edit points in the preferences, or for each page individually, and anybody that doesn't like them wouldn't have to deal with them. Put me down for a Weak support. Falconusp t c 11:58, 5 December 2011 (UTC)
- Although I agree with those suggestions and think they would improve the overall proposal, I think asking for more than the simplest upgrade could lead more certainly to it not being added. I'm going to be updating the proposal to simplify it (technically) with just that in mind. Very basically, I think proposing the alternative (in the proposal lead) method is more likely to be considered for creation and installation, since it is nothing more than an adaptation of the code controlling nd displaying section headings. fredgandt 20:36, 5 December 2011 (UTC)
- Support. They don't have to be used in articles. If an article section is that long we would make section breaks.Jasper Deng (talk) 22:42, 5 December 2011 (UTC)
- I've struck out (crossed through) and inserted (shows underlined) some text in the proposal lead since having a think about it. The proposal seems to be getting bogged down in technical details. Can we first establish simply if there is a rough consensus for some sort of functionality that allows this kind of thing? Once we know if the basic idea is worth exploring, we can get techy-wid-it!
- I've started work on a user script and a template that may or may not amount to something useful. I'll keep you posted. I would prefer the function/feature to be part of the Mediawiki software though. fredgandt 19:42, 6 December 2011 (UTC)
- Support - sensible idea for pages with longer sections. A can see issues arising with these edit points being overused, however, so there would need to be clear instructions on how to use them (perhaps a new WP namespace page on edit point guidelines). Chris (talk) 00:54, 13 December 2011 (UTC)
- Week support: "==Break2=={{nonindex}}" could be used too.. as well as the normal breaks. Weighing it with the possible litter we can get yet the usefulness of such edit-point. --lTopGunl (talk) 23:47, 13 December 2011 (UTC)
End of EDITPOINT thread
To add a Support/Oppose note, edit this section and place text above the header "End of EDITPOINT" so that new text will be listed in the Support/Oppose section. -Wikid77 14:03, 6 December 2011 (UTC)
Proposal for minimising the number of relisted AfDs
The Articles for deletion process currently operates as follows:
Deletion discussions |
---|
|
Articles |
Templates and modules |
Files |
Categories |
Redirects |
Miscellany |
Speedy deletion |
Proposed deletion |
In some cases, this process is unsatisfactory. If no meaningful contributions are made to a discussion on its first day, it is likely not to be visited by contributors until the eighth (closing) day. Many people will only click on today or closing, and not seek out any of the intermediate days. So some AfD's disappear, undiscussed, into limbo for a week, during which time nothing happens - the AfD is effectively inactive.
So, I propose the creation of an AfD holding pen for new discussions. The following process will then take place:
- A discussion is opened in the AfD holding pen (or whatever we want to call it). This pen can be accessed through the Deletion discussions box - technically, it will be just the same as a daily deletion log, but won't be limited to one day's AfDs only.
- It stays in the pen (potentially for several days) until the discussion has properly begun, i.e. someone has contributed who is not the deletion proposer or the page's creator. It is then moved to that day's deletion log.
- The AfD then follows the current procedure until closing day. Perhaps the length of discussion time can be reduced to less than a week.
This will reduce the number of AfDs that are relisted by ensuring that all undiscussed AfDs are still easily accessible via the Deletion discussions box.
I don't think that the holding pen would get overloaded, because things should be moved out of it fairly quickly. We may want to consider a maximum holding time before an Admin can retire the AfD as unresolved, though I suspect that this would not be reached often. Bazonka (talk) 22:33, 5 December 2011 (UTC)
- An interesting idea, but is there really a problem with the current system? It only takes a few seconds to relist a debate and most articles up for AfD aren't of the "urgent that this be deleted" variety. --Philosopher Let us reason together. 04:31, 6 December 2011 (UTC)
- The problem is not with the few seconds to relist, but the fact that it can take a week to get there, during which time it is likely that nothing will happen because the discussion isn't readily accessible. I do take your point about urgency though; perhaps it's just me that gets frustrated by these unnecessary delays. Bazonka (talk) 07:51, 6 December 2011 (UTC)
- I disagree that the debate isn't readily accessible. CAT:AFD, for example, is a great way to view all the active debates in a particular topic area - or in all areas, if you have time to kill. To be honest, I doubt I've ever used the discussions template posted here. UltraExactZZ Said ~ Did 20:28, 6 December 2011 (UTC)
- That is indeed useful, if you know it exists. I didn't, and I bet plenty of other people don't either, because there is no simple route to it from WP:AFD. Perhaps this should be made more prominent. Bazonka (talk) 20:49, 6 December 2011 (UTC)
- You could also promote Article Alerts that sorts deletion discussions by topic. </shameless plug> — HELLKNOWZ ▎TALK 10:14, 7 December 2011 (UTC)
- As you can see, I have added some all options to the Deletion discussions template. This should help people to more easily find discussions that aren't on their first or last day. This does not necessarily mean that discussions won't remain undiscussed though, but it might reduce the number a bit. Bazonka (talk) 20:51, 8 December 2011 (UTC)
- Someone has been reverting my edits to the "Deletion discussions" template claiming that it is "completely unusable", which I dispute. Some other opinions at Template talk:Deletion debates would be appreciated. Thanks. Bazonka (talk) 07:20, 14 December 2011 (UTC)
- As you can see, I have added some all options to the Deletion discussions template. This should help people to more easily find discussions that aren't on their first or last day. This does not necessarily mean that discussions won't remain undiscussed though, but it might reduce the number a bit. Bazonka (talk) 20:51, 8 December 2011 (UTC)
- You could also promote Article Alerts that sorts deletion discussions by topic. </shameless plug> — HELLKNOWZ ▎TALK 10:14, 7 December 2011 (UTC)
- That is indeed useful, if you know it exists. I didn't, and I bet plenty of other people don't either, because there is no simple route to it from WP:AFD. Perhaps this should be made more prominent. Bazonka (talk) 20:49, 6 December 2011 (UTC)
- I disagree that the debate isn't readily accessible. CAT:AFD, for example, is a great way to view all the active debates in a particular topic area - or in all areas, if you have time to kill. To be honest, I doubt I've ever used the discussions template posted here. UltraExactZZ Said ~ Did 20:28, 6 December 2011 (UTC)
- The problem is not with the few seconds to relist, but the fact that it can take a week to get there, during which time it is likely that nothing will happen because the discussion isn't readily accessible. I do take your point about urgency though; perhaps it's just me that gets frustrated by these unnecessary delays. Bazonka (talk) 07:51, 6 December 2011 (UTC)
IP Editors
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm all for IPs being able to edit. However, with ClueBot being down there is a growing amount of vandalism and it is gettiing hard to control. I would like to sugest a tempoary suspesion of IP editing rights until ClueBot is fixed. I sugest this because the majoraty of vandalism I see is by IPs. Oddbodz (talk) 19:54, 6 December 2011 (UTC)
- Support Unfortunate but true. Can't say much else due to unclean feelings of IPism and guilt. I'd prefer to feel bad than watch WP get trashed. fredgandt 20:07, 6 December 2011 (UTC)
- Strong Oppose - ClueBot did not rule Wikipedia and its absence should not affect the spirit of openness that we should have. Sure, vandalism is a problem, but it is not insurmountable. We must not let the vandals spoil Wikipedia for the vast numbers of well meaning IPs. See WP:HUMAN. Bazonka (talk) 20:20, 6 December 2011 (UTC)
- There's nothing to debate here. It's not even a consensus issue -- the foundation wants IP editors to be allowed to edit. I normally hate killing discussions with archive boxes, but in this case it's probably a good idea. ♫ Melodia Chaconne ♫ (talk) 21:05, 6 December 2011 (UTC)
- Strong oppose How is that going to stop vandalism? Vandals will simply take the extra minute to get an account. On the down side, Wikipedia will loose good content contributers. Over 60% of IP edits are good edits. Alpha_Quadrant (talk) 21:10, 6 December 2011 (UTC)
- Strong Oppose for the above reasons and for the fact if we go this far whats to stop peopel requesting ip ranges being blocked in the future, requesting isps be block or countries???. i have edited under ip before just because it was easier to makea quick edit that log in just fora something minor i wouldnt liek to think i need to worry about logging in evr time--Andrewcrawford (talk - contrib) 21:23, 6 December 2011 (UTC)
- My personal feeling is that most vandalism is opportunism or accident. I think very few acts are thought through. Obviously some are, but that's not really what ClueBot ever dealt with. The tens of thousands of little '''boldtext''' that get dumped and left because the editor was not really sure what they were doing or were just bored are where ClueBot ruled. I am fully on the side of free editing, but 60% isn't a massive majority. Another way to view that figure is that 40% are vandals (or at least not helpful). As a temporary measure to at least calm the flow of rampant destruction (if people realise the opportunity exists for their work to be shown off for longer) by the deliberate IP vandals, it would not be truly a bad idea. Once ClueBot is back, then so could be the IP editors. I know we are all supposed to strongly oppose because the IPs are wonderful, but if you've ever watched WP:AIV, you'll know damn well that IPs far out-way logged users in the vandalism league and it takes a constant and concerted effort by many people to just keep up. fredgandt 21:29, 6 December 2011 (UTC)
- Oppose per Wikipedia:Five pillars, Meta:Founding principles, Wikipedia:Perennial proposals#Prohibit anonymous users from editing. Absolutely no chance that this proposal would be accepted, even as a temporary measure. Chzz ► 09:46, 7 December 2011 (UTC)
Does it just have to be ClueBot who fixes vandalism? I am sure that many acts of vandalism on Wikipedia get corrected by users who are not bots. ACEOREVIVED (talk) 10:59, 7 December 2011 (UTC)
- I actually noticed during some recent huggling that a number of IPs were reverting vandalism (manually). In fact, I'm pretty sure that one IP was following the huggle feed in the IRC, because I ran into him or her reverting stuff about 20 times in two hours. Sven Manguard Wha? 16:47, 8 December 2011 (UTC)
- Past research has indicated that for every IP-based act of vandalism, there are three or four well-intentioned edits by unregistered users. It's not at all uncommon to see unregistered editors fixing vandalism. WhatamIdoing (talk) 23:37, 12 December 2011 (UTC)
This discussion appears that it should be totally closed now, as it appears that ClueBot is again active - look at the history of the article Higgs boson, and if you click on the article's history, you will see that an act of vandalism was corrected by ClueBot today (December 15 2011). ACEOREVIVED (talk) 16:09, 15 December 2011 (UTC)
- I would like to see the data regarding IP users, where can I find the analyses? WP:HUMAN has a graph from 2007 (4+ years ago — donkey's years for a website). Thanks --Squidonius (talk) 19:21, 15 December 2011 (UTC)
Add a 'Cleanup' tab to articles
I propose to move all templates such as those from WP:TC of an article to a new 'Cleanup' page. This page could be located in a new namespace, such as Cleanup:Tree for the article Tree. The rationale for this proposal is, that we have two main groups of people coming in touch with an article: our readers and our editors. The cleanup templates are primarily targeted at our editors, not at people who only read articles. Now obviously, we want to encourage our readers to be bold and fix things themselves when they see something needs to be fixed. However, a reader who is interested in a specific subject is likely to notice a shortcoming of the article without the extra 'hint' that something is wrong with the article. And of course our readers are already invited to do something to improve an article via the article feedback tool. The benefits of this proposal are:
- less clutter in article namespace
- more seriously looking articles
- a centralized place for the article listing what needs to be done, which might encourage boldness, since it will be more specific than generic cleanup templates
Such a new page could become a detailed 'To Do list' for an article independent of WikiProject specific lists in the WikiProject banners on the article talk page. This would also be useful, if an editor recognizes something in need of improvement in an article, but does not have the time to fix it right now. The main difference to an article talk page would be, that no signed comments should be made on that page in order to keep a clean appearance. Toshio Yamaguchi (talk) 16:08, 7 December 2011 (UTC)
- Similar proposals have been rejected in the past. (See Wikipedia:Perennial proposals#Move_maintenance_tags_to_talk_pages) It is true that cleanup templates are more important to the editors than the reader. However, some cleanup templates, such as Template:Unreferenced, do serve as a warning to readers. Alpha_Quadrant (talk) 16:27, 7 December 2011 (UTC)
- Let me say what I think about about the points at PEREN:
- 1. Is there statistical data providing evidence that readers motivation to become editors is ignited by the cleanup templates? I think many readers are motivated by errors or missing information in an article that interests them, regardless of whether there are cleanup templates or not.
- 2. Blindly believing something one reads somewhere (for example here on Wikipedia) is never a good idea. As a competent reader of Wikipedia, one should expect that there may be problems.
- 3. To be honest, this is one of the most nonsensical things I have ever read on Wikipedia.
- 4. True, but any substancial change has its 'cost'. And it is at least my personal belief (and please feel free to prove me wrong) that this 'investment' has a potential for an overall improvement of Wikipedias content. Toshio Yamaguchi (talk) 16:45, 7 December 2011 (UTC)
- I do not believe any statistics have been taken on how the cleanup tags affect non-registered users. The problem I see with moving the cleanup tags to a separate page, is that it hides the problems with the article. If the readers don't know there is a problem, how will they be educated so that they know that the issue needs to be fixed. Some cleanup tags would work poorly on a separate page. For example, how would we address the section templates (i.e. "This section requires expansion") or the specific cleanup templates such as [citation needed]. Editors trying to track down and address the issues would need to jump back and forth between the pages. As pointed out by point four, there are about one million articles with some sort of cleanup tag and there are over 200 different cleanup tags. The massive amount of work that would be required to implement such a feature would be astronomical. A new namespace would need to be created. All of the cleanup bots and tools would need to be updated. We would need to alter the cleanup templates. Then we would need to actually go through and make the conversion. Even with a bot, that could take months to complete. If there is a problem with cleanup templates displaying for readers, it might be simpler to just alter the cleanup templates to only display for logged in users. There is a way to hide categories from users without the preference enabled. It shouldn't be too difficult to do the same with templates. Alpha_Quadrant (talk) 17:09, 7 December 2011 (UTC)
- Regarding 'hiding problems with the article', we could include a link at the top of all articles (a wikilink pointing to the Cleanup page) saying something like
- "Click here to check whether there are problems with this article"
- Regarding the large amounts of work required to implement this, I agree. Whether that is a reason not to do it, I don't know. Regarding cleanup templates referring to a specific section: it should be no problem to provide a wikilink to the section in question on the cleanup page.
- "If the readers don't know there is a problem, how will they be educated so that they know that the issue needs to be fixed."
- This will be done by a link, as explained above. There should be a general notice such as
- "Please note that many articles are still unfinished and there might be things needing improvement. Check the Cleanup page to see what needs to be improved in this article." Toshio Yamaguchi (talk) 17:32, 7 December 2011 (UTC)
- I do not believe any statistics have been taken on how the cleanup tags affect non-registered users. The problem I see with moving the cleanup tags to a separate page, is that it hides the problems with the article. If the readers don't know there is a problem, how will they be educated so that they know that the issue needs to be fixed. Some cleanup tags would work poorly on a separate page. For example, how would we address the section templates (i.e. "This section requires expansion") or the specific cleanup templates such as [citation needed]. Editors trying to track down and address the issues would need to jump back and forth between the pages. As pointed out by point four, there are about one million articles with some sort of cleanup tag and there are over 200 different cleanup tags. The massive amount of work that would be required to implement such a feature would be astronomical. A new namespace would need to be created. All of the cleanup bots and tools would need to be updated. We would need to alter the cleanup templates. Then we would need to actually go through and make the conversion. Even with a bot, that could take months to complete. If there is a problem with cleanup templates displaying for readers, it might be simpler to just alter the cleanup templates to only display for logged in users. There is a way to hide categories from users without the preference enabled. It shouldn't be too difficult to do the same with templates. Alpha_Quadrant (talk) 17:09, 7 December 2011 (UTC)
- Similar proposals have been rejected in the past. (See Wikipedia:Perennial proposals#Move_maintenance_tags_to_talk_pages) It is true that cleanup templates are more important to the editors than the reader. However, some cleanup templates, such as Template:Unreferenced, do serve as a warning to readers. Alpha_Quadrant (talk) 16:27, 7 December 2011 (UTC)
- Support with comments - As before I like the idea of this suggestion. A couple suggestions though.
- I do think that the templates should be placed on the article itself (they could be generated or not based on a setting set by the editor in the same way we do for Person data template).
- I do agree that there are certain templates such as Unref, Unref BLP and a select few others that would probably need to stay on the article but for the rest a cleanup (or other name) tab could be very useful and would make the articles much less noisy.
- I also think that we should refine the rules for the placement for some of these tags at the same time. For example, there are a lot of stubs that have templates like expand, cleanup, etc. on them and as stubs it rather goes without saying that a stub needs to be expanded. --Kumioko (talk) 16:59, 7 December 2011 (UTC)
- Oppose. I find the arguments at Wikipedia:Perennial_proposals#Move_maintenance_tags_to_talk_pages persuasive. Cleanup tags that are relegated to a separate page will be ignored, not just by readers but by most editors too. A lot of my cleanup gets done when I look up something just to read it and find things that need fixing. On pages I watch, it's a constant reminder and TODO. I find that removing tags is in itself one of my motivations for doing cleanup ("can finally get rid of that tag now"). And while people should not blindly believe anything they read on Wikipedia, I really believe it does a service to our readers to explicitly point out content that is problematic, so they can treat it with an even greater level of suspicion than usual. Dcoetzee 10:02, 8 December 2011 (UTC)
- Oppose per Dcoetzee. Sven Manguard Wha? 10:48, 8 December 2011 (UTC)
- Oppose We're having an RFC on this again? As far as I am concerned, nothing has changed since last time. It's the same old "I think they're ugly!" versus "They have the potential to convert readers into editors, and in a way that is more likely to lead to editor retention" debate, and I still support the latter. Anomie⚔ 12:08, 8 December 2011 (UTC)
- Oppose Clean-up notices fall into the same category as {{Citation needed}} (and similar) in one important respect; they inform readers as well as editors that the article is not perfect. This honesty adds to Wikipedia's trustworthiness. The public at large are now getting used to Wikipedia being reliable since it is fairly common knowledge[citation needed] that wherever we (editors) are not completely satisfied, we will say so, clearly. To hide that statement of dissatisfaction from passers by, could reverse the firm trend seen in the media and by ordinary folk, that Wikipedia is a great source of reliable knowledge (even the stuff that's wrong is labelled as being so). We should continue to flaunt our errors with gay abandon! "If we deny our demons, we give them power over us" (something like that anyway (Monkey (TV series)). fredgandt 22:07, 11 December 2011 (UTC)
- Oppose for the very convincing reasons put forth in previous similar proposals. There will never be 100% of people that agree with cleanup templates, but it's clear that a substantial majority - including myself - think they're appropriate. Chzz ► 10:18, 14 December 2011 (UTC)
- Oppose: the cleanup tag is placed in the article to draw attention of the passing by editors; the suggested alternative fails to accomplish that task. Furthermore, the overhead of a separate namespace doesn't correspond to the task of building todo lists, which can be done on the talk page. P.S.: Wikipedia doesn't make difference between editors and readers, and it's one of the reason of its growth. I wouldn't change that without very good reason. — Dmitrij D. Czarkoff (talk) 09:19, 19 December 2011 (UTC)
Add link to sandbox on the top right corner
hello,
can't we add a link to the user sandbox somewhere in the top left? I mean ahead "my talk", "my preferences", etc? "My sandbox" would be nice; the user can rename the {User Name}/Sandbox page anytime.--♫GoP♫TCN 18:35, 7 December 2011 (UTC)
- Strong support I actually added this a while back via user script (along with all kinds of other changes). I think having an immediate link to a user sandbox in the
p-personal
navigation menu for all logged in users would be a fantastic and simple way to encourage the use thereof. When users first create an account, both their user page and user talk page are red-links in the navigation menu, so what harm could there be to add another? Whole hearted support! fredgandt 08:58, 8 December 2011 (UTC) - Support great idea. Yoenit (talk) 09:49, 8 December 2011 (UTC)
- Support, but it would be nice if the page contains an informational message explaining what their sandbox is for. It'd mystify me as a new user to click on a link and see a new page and then wonder "okay what is this for?" Commons recently added "My uploads" to the upper right and there was no real concern about the space it occupied. Dcoetzee 09:56, 8 December 2011 (UTC)
- this link preloads a users sandbox with a template. That is the sort of simple solution that could be employed to address your wise concern. fredgandt 10:12, 8 December 2011 (UTC)
- Support I think that is a good idea and would be especially useful for new editors. Toshio Yamaguchi (talk) 10:00, 8 December 2011 (UTC)
- Support only if it can be turned off in a "My preferences" setting - I have four sandboxes and their talk pages, I very much like having sandboxes, but I'd rather not have the tab. Many other users also would probably not like it. If you want to have it opt-out (and a large enough consensus emerges as to allow for opt-out) that's fine, but if there's no opt out, I'd be rather miffed. Sven Manguard Wha? 10:46, 8 December 2011 (UTC)
- Although I'm not going to oppose an opt-out, note that you could make your sandbox page into an index/list of your sandbox pages, so they'd always be two clicks away, which is nice. Dcoetzee 11:56, 8 December 2011 (UTC)
- It already is: User:Nabla#Sub (Ok, 2 clicks and a scroll :-). Not against it, though it will force all of us to have a needless link in order to patronise new users. - Nabla (talk) 23:20, 9 December 2011 (UTC)
- Support only if it can be turned off Per Sven Manguard. I think I have 12 sandboxes now, and I have no need to index them. When I want one, I just type e.g. "User:Anomie/Sandbox6" into my browser's search box. As for the technical implementation, should this find consensus it could be made an "enabled by default" gadget. Anomie⚔ 12:04, 8 December 2011 (UTC)
- Support if turned off by default Most new users won't know what it is for, or will use it inappropriately, filling the Wikipedia servers with unnecessary rubbish. But for more advanced users who want and will use this sort of functionality, it should be easily available. Bazonka (talk) 12:35, 8 December 2011 (UTC)
- The whole point of sandboxes is that nobody cares if they are filled with rubbish. The alternative if to have the confused users post their rubbish elsewhere, most likely in mainspace. The concern that users don't understand what it is for could be solved with a simple editnotice. Yoenit (talk) 13:11, 8 December 2011 (UTC)
- I concur. Something like User:Toshio Yamaguchi/Template:User sandbox notice should work. Toshio Yamaguchi (talk) 16:38, 8 December 2011 (UTC)
- Support I can't add much more than the support already given. doktorb wordsdeeds 16:45, 8 December 2011 (UTC)
- Support with opt-out. CharlieEchoTango (contact) 16:48, 8 December 2011 (UTC)
- Comment: I just wanted to say that from a Wikimedia Foundation/new editor retention perspective, this is a really great idea. I would propose that if we try this, we make an effort to see how many new editors create/use their sandbox, and how they do so. Steven Walling (WMF) • talk 22:26, 9 December 2011 (UTC)
- Perhaps the foundation could set up a test that creates the proposed tab for 10 or 20 percent of all not yet autoconfirmed new users. You could then study the use/misuse/disuse/strawberry-mouse of it and see if it could be considered a worthy new feature to roll out for all new users. If then after further study it was found to be the best thing ever!, it could be added to the UI as a simply toggleable option (via prefs) (suggest if tests results prove sandbox tag favourable that it is enabled by default with opt-out toggle). Something along those lines anyway (I know you like testing things Steven
) fredgandt 01:07, 10 December 2011 (UTC)
- Perhaps the foundation could set up a test that creates the proposed tab for 10 or 20 percent of all not yet autoconfirmed new users. You could then study the use/misuse/disuse/strawberry-mouse of it and see if it could be considered a worthy new feature to roll out for all new users. If then after further study it was found to be the best thing ever!, it could be added to the UI as a simply toggleable option (via prefs) (suggest if tests results prove sandbox tag favourable that it is enabled by default with opt-out toggle). Something along those lines anyway (I know you like testing things Steven
- Support - great idea. I use custom-js to add a couple of buttons to "my test page", and a "notes" page; they're invaluable to me. If all users had one easy-to-access 'Sandbox' of their own, that'd be a massive improvement. I support it being on by default (because it is of most benefit to new users), with an option to turn it off. Shouldn't we 'pre-populate' it with a header, similar to {{userspacedraft}}, if it does not exist yet? Chzz ► 00:56, 11 December 2011 (UTC)
- Agreed on prepopulating with some useful links etc. Steven Walling (WMF) • talk 18:01, 12 December 2011 (UTC)
- Support this proposal. More generally, I think the "personal toolbar" needs a bit of work to make it more discoverable - maybe some Tipsy tips on newbies' (red) user page and talk page links? — This, that, and the other (talk) 01:18, 11 December 2011 (UTC)
- Support if opt-out is available I'm all for additional features if people find them useful, but I don't want to be forced to have it. Nyttend (talk) 21:49, 11 December 2011 (UTC)
- Conditional support - I would welcome this as an opt-in, but I would oppose having users have to opt-out. – Allen4names 22:14, 11 December 2011 (UTC)
- Conditional support if we can opt out of it. I personally use a user script to include links in the "p-personal" space, but this is better.~ Matthewrbowker Say hi! 06:36, 13 December 2011 (UTC)
- Oppose the already available buttons Edit and Preview do the trick. Don't think sandbox is needed at all. — Dmitrij D. Czarkoff (talk) 07:31, 14 December 2011 (UTC)
- I disagree with this. A preview does for example not produce a diff that is visible to others. If a newbie makes actual edits in their sandbox, this allows for others to give feedback and advice on eventual problems with the newbies editing behavior. Toshio Yamaguchi (talk) 09:45, 14 December 2011 (UTC)
- Support with opt-out and expand to IPs: I like the idea, new users would find it quite helpful, but users who are experienced enough to go to preferences and remove it deserve not to have a clutter if they don't want it. On a sidenote who says users will use the sandbox link instead of testing it out in the main since they can already test in their user-space but no, they test it out there. And wait, what about IPs? How about putting up the WP:SANDBOX as a link in the tab for them? After all they do most of the 'tests'. Something like adding a sandbox tab along with the "login/create account" option that would read "Test edits here" on mouse hover. That might reduce random text entries by IPs who are merely checking out. --lTopGunl (talk) 22:17, 14 December 2011 (UTC)
Namespace and watchlist
There should be an option to not watchlist by default pages in a certain namespace. For example, I have enabled watchlisting by default as it is very convenient, but I try to keep my watchlist below 600-700 pages at any given time. It's fairly tedious to do, because everytime I edit a WT:AFC page, block a user, or leave a message to a user talk page, the page is watchlisted. I would like a feature that enables automatic watchlisting only for specific namespaces. This also addresses the above proposal on separating pages from their talk pages (e.g. WT from WP, etc). Any support for this? — Preceding unsigned comment added by CharlieEchoTango (talk • contribs) 06:22, 8 December 2011 (UTC)
- Oppose due to this being potentially a pain in the rear end. I can imagine too many occasions when I would have to override the exclusion of a particular namespace manually. This proposed feature would actually more than likely cause the very issues being cited as reasons to oppose the above proposal to be able to un-watch talk and other pages etc. etc. In particular the potential to forget to watch and to think that you are when you're not seems rather strong. With the other proposal, the normal behaviour (we have now) would have to be manually undone on a per page basis, meaning the likelihood of forgetting is significantly reduced (to basically zero). Simply speaking: I wouldn't want to automatically not watch all (for example) talk pages, since more often than not I want to watch both the talk and main (just occasionally not both). Blanket exclusion of a particular namespace from being auto watched is too harsh for my liking. fredgandt 09:16, 8 December 2011 (UTC)
- Support. Anything that helps customization of autowatch would be useful. I wouldn't expect most users to use it, but I don't think it would hurt. I think a prototype of this could potentially be implemented in pure Javascript, and then anyone who wants to try it out can just include it. Dcoetzee 09:54, 8 December 2011 (UTC)
- Support as an opt in with the suggestion that it be made a "gadgets" feature - I wouldn't use this, but I understand how it could be useful. If it isn't possible to do opt-in, the simple alliterative would be to have autowatchlisitng on for all namespaces or for none of them, creating results identical to the two options we have now. Sven Manguard Wha? 10:43, 8 December 2011 (UTC)
- Comment: I would certainly think that an admin who blocks a user should, for at least a reasonable time, have that user's talk page in his watch list. I would also expect this if you leave a message. Communication is two-way. If you initiate it, you have the obligation to be reasonably attentive to replies. --Stephan Schulz (talk) 11:59, 8 December 2011 (UTC)
- Note that for some users like myself, I currently have autowatch disabled (because I make minor changes to many articles) but would be more likely to enable it for the User talk namespace, for precisely that reason. So your argument seems to actually favor the proposal. Dcoetzee 13:12, 8 December 2011 (UTC)
- Yes, this is a two-headed snake, which is why I put it in as a comment, not a !vote. --Stephan Schulz (talk) 15:02, 8 December 2011 (UTC)
- Well, my message wasn't very well worded, heck, wasn't even signed, of course I keep the page on my watchlist when I leave an open-ended message, what I'm referring to is mostly related to script sent messages on user talk pages; e.g. welcomes, "Your submission at AfC was created", user warnings, CSD notices, etc. No point in watching most of the time and it grows very quickly to an unmanageable (for me) watchlist. I get your point on communications, but I also see no point in keeping hundreds of declined AfCs or various WP pages (like this one). Removing them manually every other week is tedious. Regards, CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)
- I suspect this will get lost, but it reminds me of a feature I would like, the ability to watchlist a page, with the watchlist expiring after a month or so. Perfect for this situation and many others--SPhilbrickT 15:58, 14 December 2011 (UTC)
- Note that for some users like myself, I currently have autowatch disabled (because I make minor changes to many articles) but would be more likely to enable it for the User talk namespace, for precisely that reason. So your argument seems to actually favor the proposal. Dcoetzee 13:12, 8 December 2011 (UTC)
- Yes please! -- John of Reading (talk) 16:02, 14 December 2011 (UTC)
- Yes, that's something I also would like to see. Toshio Yamaguchi (talk) 16:18, 14 December 2011 (UTC)
- A biodegradable watch of a page? So after n time it auto un-watches? Yep, I'd go for that. As long as it was something that could be selected on a per page basis and was not default behaviour. Perhaps this should be separately proposed. fredgandt 18:07, 14 December 2011 (UTC)
- Opppose You could do this with a simple user script. And I echo Stephan Schulz's comment above. Anomie⚔ 12:05, 8 December 2011 (UTC)
- Which script? CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)
if (wgAction == "edit" && [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 100, 101, 108, 109].indexOf(wgNamespaceNumber) != -1) {
document.getElementById('wpWatchthis').checked = true;
}
- Customize the numbers in the list as needed; namespace numbers in the list will be auto-watched if you add this to your user JavaScript page. For a namespace-number-to-English guide, see Wikipedia:Namespace#Programming. Numbers -2 and -1 need not be added as you probably won't be editing in those namespaces. {{Nihiltres|talk|edits|⚡}} 16:00, 8 December 2011 (UTC)
- Well this would certainly solve my problem, thanks! I added it to my User:CharlieEchoTango/common.js, but it doesn't seem to work. Purged the cache, logged out logged in, tested on two namespaces. :/ CharlieEchoTango (contact) 16:14, 8 December 2011 (UTC)
- Nevermind, I had to disable automatic watchlisting first. Silly me. Thanks a lot, Nihiltres. :-) CharlieEchoTango (contact) 16:20, 8 December 2011 (UTC)
- It seems to watchlist the associated talk namespace regardless of the script (e.g. if I choose to watch ns4, ns5 is included with it even if left out in the script). Not a big deal, though. CharlieEchoTango (contact) 16:33, 8 December 2011 (UTC)
- That's inherent to the watchlist feature. If you watch a page, you also necessarily watch the associated talk page or content page. My script merely chooses which namespaces will have auto-watch enabled: it might make sense to auto-watchlist page pairs when you edit a talk page, but not when you just edit content. {{Nihiltres|talk|edits|⚡}} 16:50, 8 December 2011 (UTC)
- Support as an option that should probably be available by default, but I'll otherwise make my above 30-second script into a more user-friendly Gadget as soon as Gadget preferences are available (hopefully, an upcoming feature). {{Nihiltres|talk|edits|⚡}} 16:10, 8 December 2011 (UTC)
- Support with comment - I don't see that this would be a bad thing as long as its opt in and not required. I think that there is a lot of room for improvement in the way Wikipedia handles Watchlists and any functionality that allows users some flexibility in it is helpful. --Kumioko (talk) 16:14, 8 December 2011 (UTC)
- Oppose I do not see the need for such a feature. When the 'Add pages I edit to my watchlist' feature is enabled, you can just uncheck the 'Watch this page' checkbox above the 'Save page', 'Show preview' and 'Show changes' buttons. Toshio Yamaguchi (talk) 17:43, 10 December 2011 (UTC)
- Support I also agree with an opt in comment, as not every user (including myself) are user script literate. Only a few are, and I agree that so many articles I tagged for deletions, users I warned and so forth gets automatically watchlisted and removing it can be a pain. Secret account 06:29, 13 December 2011 (UTC)
- This proposal would offer you the opportunity to not watch any talk pages or all; any articles or all. Are you really sure that will be helpful? fredgandt 06:59, 13 December 2011 (UTC)
- Comment Some people here might find user:js/watchlist useful. It's fairly easy to install and to use in my opinion (see instructions on that page)
. I have it installed, since I also have "Add pages I edit to my watchlist" enabled (hell I would miss a whole lot of stuff if I hadn't) and it makes killing unwanted pages popping up on your watchlist mostly painless. Toshio Yamaguchi (talk) 22:58, 14 December 2011 (UTC)
- Support Per Sven Manguard. Rcsprinter (state the obvious (or not)) 20:36, 16 December 2011 (UTC)
Bot to maintain and auto update a list
I would like to get consensus for the following bot task:
Automatically update Sony Corporation shareholders and subsidiaries#Shareholders with information from http://www.sony.net/SonyInfo/IR/stock/information.html where it says Principal Shareholders. That is, the shareholder rang, name and percentage should be checked by the bot against the information present on the website and automatically updated, when there is a discrepancy between the two pages. Toshio Yamaguchi (talk) 17:16, 10 December 2011 (UTC)
- confused why this is here and not on the Bot request page.Crazynas t 00:34, 11 December 2011 (UTC)
- I am not a bot programmer. I want to reach a consensus here and then file a request at WP:BOTREQ. I thought such a task should have a consensus before being requested. Toshio Yamaguchi (talk) 00:56, 11 December 2011 (UTC)
- You can still post your request at WP:BOTREQ. I will do it as a courtesy. PaoloNapolitano 10:56, 11 December 2011 (UTC)
- Botreq would likely ask for consensus. Funnily enough I have been thinking about this sort of thing. The development cost for a single section of a single page is fairly high, but a generic solution (also called AI) is attractive. Rich Farmbrough, 21:19, 11 December 2011 (UTC).
- Botreq would likely ask for consensus. Funnily enough I have been thinking about this sort of thing. The development cost for a single section of a single page is fairly high, but a generic solution (also called AI) is attractive. Rich Farmbrough, 21:19, 11 December 2011 (UTC).
- You can still post your request at WP:BOTREQ. I will do it as a courtesy. PaoloNapolitano 10:56, 11 December 2011 (UTC)
- I am not a bot programmer. I want to reach a consensus here and then file a request at WP:BOTREQ. I thought such a task should have a consensus before being requested. Toshio Yamaguchi (talk) 00:56, 11 December 2011 (UTC)
Straw Poll on Jimbo's talk page
Jimbo is looking for input regarding the passage of SOPA and how it will effect Wikipedia.here. Crazynas t 22:55, 10 December 2011 (UTC)
- Wikipedia:SOPA initiative in the unlikely event that we get to that point, some advance planning would be good. Crazynas t 10:31, 13 December 2011 (UTC)
The catastrophically failing merge process
- Please visit this discussion on Wikipedia talk:Merging to comment. Protonk (talk) 00:53, 14 December 2011 (UTC)
"Liking " others' edits
- 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.
- SNOW close. Sven Manguard Wha? 08:56, 15 December 2011 (UTC)
Oftentimes I come across edits where I think, "that's a really useful bit of editing". Little things like adding sources, tweaking grammar, tidying up section headers - gnomish things which all contribute to improving the encyclopedia, but aren't especially showy. Whilst we do have barnstars (and kittens, cookies and all sorts of other crap) to show approval for this sort of thing, sometimes that level of Wikilove seems excessive for individual edits. What would be nice would be a "Like" (or "Approve", or "Commend" or something else that doesn't make us look like Facebook) button, perhaps next to the button for "Undo", that appeared when an edit was viewed. Users could then show their approval for one another's more minor edits without having to slap a barnstar on their talkpage ("Thanks for deleting that one extraneous apostrophe! I hereby award you this award! Keep up the good work!").
It would also be motivating for new users to see that their edits were approved of - it can take a while to get positive feedback when you first start out (far easier to receive a warning template), and this would show newer users that their efforts were appreciated.
Just a thought - second opinions solicited... Yunshui 雲水 14:52, 12 December 2011 (UTC)
- On the other hand, editors would assume that their 'liked' contentious edits (whether by other similar editors or not) have support from all those editors and would wrongly assume consensus or quote such in a talkpage discussion. --lTopGunl (talk) 17:15, 12 December 2011 (UTC)
- Absolutely irreversible oppose Adds useless clutter to the database / edit history and would enable a new level of WP:MEAT that is practically impossible to prove or disprove. If you think an edit is fine, just drop the editor a note on his or her talkpage. This also could lead to newbies having their absolutely worst crap liked by their friends and would make it even harder to communicate Wikipedias principles to them. (Sorry for the strong language). Toshio Yamaguchi (talk) 20:56, 12 December 2011 (UTC)
- Intensely oppose - whatever gloss you put on it, this would add to the further degenerative Facebookification of Wikipedia, even worse than the contemptible Wikilove. If you wish to communicate with a fellow editor, take the four extra seconds to click on the link to her/his talk page and actually communicate with them like human beings. Templated "goodies" are cheap and sleazy substitutes for actual human interaction. --Orange Mike | Talk 22:08, 12 December 2011 (UTC)
- Oppose upon every grounds possible and with the right to oppose on any ground as yet undiscovered I remain bemused and somehow impressed by the inventive ways editors invent to turn Wiki into a social media platform doktorb wordsdeeds 22:15, 12 December 2011 (UTC)
So that's a "no", then? Okay, bad idea... Yunshui 雲水 00:10, 13 December 2011 (UTC)
- Yeah, but Template:The Minor Barnstar can be awarded to the aforementioned "gnomish" editors. —David Levy 00:18, 13 December 2011 (UTC)
- Oppose and suggest a "For Christ's sake, not another Facebookification proposal" template. Ian.thomson (talk) 00:24, 13 December 2011 (UTC)
- Strongly Oppose per previous objections, WP is an encyclopedia - not Facebook or a social media site. Let's please keep it that way. Per Orangemike, we can "like" other editor's contributions by dropping them a note of appreciation on their talk page.--JayJasper (talk) 05:42, 13 December 2011 (UTC)
- Taking bets that WMF will implement this before long Think about it and you'll realize it's only a small step from the "WikiLove" business to something like this. Those of us who lament the Facebookization of Wikipedia need to get used to the fact that we're fighting a losing battle. Short Brigade Harvester Boris (talk) 05:50, 13 December 2011 (UTC)
- The WMF should seriously think about what they actually want. Do they want to alienate their established editor community in favor of a bunch of "Ey yo don't undo ma ediz where I addez that image I finded in Google and it looks more cool naw cuz I tell my homies to dislike all you edits!!!"? Toshio Yamaguchi (talk) 12:32, 13 December 2011 (UTC)
- Oppose per Ian.thomson --Guerillero | My Talk 05:56, 13 December 2011 (UTC)
- Comment – More or less in response to Toshio Yamaguchi's and my orange colleague's comment, isn't this already being done with the Article Feedback Tool, in which absolute pieces of crap and obvious speedy deletable articles get up-voted 5's across the board for being "Trustworthy", "Objective", "Complete", and "Well-written", when they are in reality not? (I think somebody on WikiEN-l a while back said that the Feedback Tool would be "griefed like with YouTube comments".) Those are not true assessments (at least there is virtually no validity behind it), but rather a measure of how people like an article. –MuZemike 06:03, 13 December 2011 (UTC)
- Sorry, but no. I see too many potential issues with this, apart from the whole "Wikipedia is not facebook" issue. Imagine the history of an article, with each edit having a like button next to it. Imainge an edit war with one edit saying something like "3 people like this" and another saying "5 people like this". It could create some sort of voting system, where people "like" the version they prefer. If someone sees an edit they find is good, post a friendly, handwritten talk page message. Makes one feel a lot better than an automated "like". Wikipedia is becoming too impersonal nowadays... Steven Zhang Join the DR army! 06:10, 13 December 2011 (UTC)
- Neutral. A lot of people here are just knee-jerk reacting to "anything similar to Facebook is bad" without considering its merits. Some kind of system for fine-grained feedback for individual edits could benefit editor motivation on a continual basis, increase community engagement with low investment, and just as importantly, help people reviewing changes to focus on those changes that someone else hasn't already carefully reviewed. Despite all this, I share Steven Zhang's concerns about the number of likes being used as some sort of edit-comparison metric. I think a superior and less controversial proposal would be an "edit review" system would you can mark an edit as "reviewed" to indicate you've checked it out and it looks okay. A bit like pending changes but purely voluntary. Then at least we'd know people are looking at what we're doing. Dcoetzee 17:04, 13 December 2011 (UTC)
- "Some kind of system for fine-grained feedback for individual edits"
- We already have that. It is called a talk page. Toshio Yamaguchi (talk) 17:11, 13 December 2011 (UTC)
- GIANT, Strong Oppose per Toshio Yamaguchi and Steven Zhang. As a rollbacker, I already have an extraneous link on the end of the descriptions in the edit history, and I sometimes feel even that link is too much. Adding a "like" button would add useless clutter, especially since it is not a function I would use often here, if at all. If a user's contribution(s) have moved me enough to want to hit a "like" button, I consider that grounds for showing them a bit of Wikilove. - Purplewowies (talk) 17:42, 13 December 2011 (UTC)
- Oppose. I'm not a fan of this whole WikiLove thing in the first place, and I just see this as a useless addition that doesn't add any value or quality to Wikipedia, but rather adds a distraction for editors away from doing productive work. New additions to Wikipedia should be focused on improving quality.--Slon02 (talk) 01:53, 15 December 2011 (UTC)
- Oppose. A good-faith proposal, but it would clutter us too much and make it too Facebooky. In disputes, good arguments might get overwhelmed by a big "like count" even if the likes lack any context. I'm open to other, less disruptive proposals to promote WikiLove. Lagrange613 02:04, 15 December 2011 (UTC)
Grafting the external links numbering mechanic onto IP signatures
I feel that when multiple non-registered users are participating in a discussion on a talk page it is sometimes difficult to keep track of who is saying what (as strings of numbers are less memorable IMO than names). Therefore I propose that the current mechanic which governs how external links in square brackets are displayed (i.e. by labelling them as the nth link on the page, where the number changes automatically – e.g. [4] [5] [6]) be grafted/exported/whatever onto IP signatures, so that in future they automatically look something like this:
- Comment 1. 1.23.456.78(1) (talk) 14:56, 12 December 2011 (UTC)
- Comment 2. 9.01.234.56(2) (talk) 14:56, 12 December 2011 (UTC)
- Comment 2a. 1.23.456.78(1) (talk) 14:56, 12 December 2011 (UTC)
- Comment 3. 7.89.012.34(3) (talk) 14:56, 12 December 2011 (UTC)
- Comment 3a. 9.01.234.56(2) (talk) 14:56, 12 December 2011 (UTC)
- Comment 3b. 1.23.456.87(4) (talk) 14:56, 12 December 2011 (UTC)
Except that this is evidently a mock-up, and the aesthetics can be played around with, but you get the idea. My thinking is that the "[7] [8]" technology already exists, so it would reduce the workload in creating this feature? It Is Me Here t / c 14:56, 12 December 2011 (UTC)
- Just a note, and I say this as a someone not very familiar with the underlying software and mechanics of Wikipedia, but when you create three external links, of which the first and third are the same, they will not have the same number (see here). So I am not sure, whether applying the external links mechanics to the IPs (if that's possible at all, I don't know) would have the effect you want to achieve. Toshio Yamaguchi (talk) 15:09, 12 December 2011 (UTC)
- I don't think there's much chance of this being incorporated into MediaWiki, but it would be easy enough for someone to write a userscript that adds your indicator after all IP sig links. Anomie⚔ 16:51, 12 December 2011 (UTC)
- There is no way to do this with the current method of applying the link icons; see Help:External link icons. -— Gadget850 (Ed) talk 17:40, 12 December 2011 (UTC)
The proposer is presumably thinking of citation links, which can be made to repeat numbers, but which involves quite a bit of overhead. --erachima talk 18:30, 12 December 2011 (UTC)
- Those are done by the Cite software extension. ---— Gadget850 (Ed) talk 12:53, 13 December 2011 (UTC)
Making Special:Protectedtitles a restricted special page
After spending some time recently RevDeling and RFOing salted titles I now believe that Special:Protectedtitles should become a restricted special page. This is because some of the deleted and salted pages I sent to RFO were (a) themselves suppressed and (b) associated logs were suppressed, meaning that when you now try to create such a page no indication is given (unless you are an Oversighter, presumably) that it ever existed, except for the fact that it is create-protected. However, even these pages which have been hidden from public view using some of our most stringent technical means still show up for all to see at Special:Protectedtitles, because they are still salted, even if their protection logs, owing to the nature of the pages' titles, are suppressed.
Therefore, if there is to be any point in the RevDel and Suppression tools in removing grossly offensive article and user names from public view, then Special:Protectedtitles must also be removed from public view.
N.B. restricting Special:Protectedtitles to Sysops and above would still leave the problem of Admins having access to a sort of oblique Oversight log, but at least this move would be a start. It Is Me Here t / c 10:52, 13 December 2011 (UTC)
- I think a better solution would be that if you RevDel (or RFO) a SALTing of a page, you unSALT it, RevDel (or RFO) the unSALTing log, and if necessary add an approrpiate entry in MediaWiki:Titleblacklist. This way, you don't have the problem of admins seeing RFO material; you don't restrict the community's ability to view Special:Protectedtitles, a restriction which should only be done if absolutely necessary; and frequently the user who was thwarted in recreating the SALTed page due to SALT will try to get around it by homoglyphs - and Titleblacklist is a better way to stop such users. עוד מישהו Od Mishehu 16:30, 13 December 2011 (UTC)
- But surely that would not solve my main concern (publicly viewable/un-hideable gunk, whose existence means that we are not following through with WP:DENY fully), since in your situation we would simply have gunk at MediaWiki:Titleblacklist rather than at Special:Protectedtitles?
- Having said which, another thought has just struck me: is it possible to have the software check whether a salted page cannot now be created by non-autoconfirmed/non-Sysops anyway (since a lot of the titles I was sending to RFO were quite old, possibly predating AbFil, Titleblacklist and the rest of it)? If so, perhaps a list of such "over-salted" pages could be drawn up, and an OS could go through them and remove them from Protectedtitles in the way you suggested? It Is Me Here t / c 17:25, 13 December 2011 (UTC)
- I imagine it would be relatively simple for a bot to take all the pages listed at Special:Protectedtitles, and check if each one of them has a SALT log entry which it can find. If the bot in question is run from an admin account, it will find just the "over-salted" ones; if it runs from an account without admin access, it will also find the salted ones where the log was admin-hidden. עוד מישהו Od Mishehu 20:04, 13 December 2011 (UTC)
RfC on making {{Orphan}} tag invisible
There's an RfC on making the the {{Orphan}} tag invisible. It's at Template talk:Orphan#Proposal - Change this to a hidden category template. I'm spamming it here because it's a highly visible template and so this is an important issue. (Arguably a CENT RfC might be in order since this is template that many readers see often. It might be called for to bump it up to that level if anyone wants to.) --Herostratus (talk) 16:48, 13 December 2011 (UTC)
I've started playing around with database dumps and I have had an idea, however I will need more eyes/hands to get this idea off the ground. I am going to be running regular scans of database dumps for typos, see User:Δ/Typos for the first report that I have generated there are 388 pages with "the the". A few of them are valid uses but most are just typos. If I could get some interested users to lend a hand with creating the list of typos and fixing the located typos we could do a lot for the project. ΔT The only constant 20:42, 13 December 2011 (UTC)
- Is there any way your search could exclude everything except for "the the"? Although this is useful, I do see a lot of "the then", "then the", and things like "the theory". Could that be narrowed? Nolelover Talk·Contribs 21:02, 13 December 2011 (UTC)
- Yeah, that's fairly simple, must have forgotten about those. Ill adjust the regex and update the list. ΔT The only constant 21:04, 13 December 2011 (UTC)
- Actually that wasn't an error with the regex, there is a user already working on the list :) ΔT The only constant 21:07, 13 December 2011 (UTC)
- Need to exclude The The as well. -- WOSlinker (talk) 21:20, 13 December 2011 (UTC)
- Already done. (for some reason my IRC bot posted this edit twice, once now with your current timestamp the other 9 minutes before.) ΔT The only constant 21:22, 13 December 2011 (UTC)
- The lists would be more useful if they included a timestamp, or were held on-wiki so that they could be watchlisted. -- John of Reading (talk) 08:10, 14 December 2011 (UTC)
- Already done. (for some reason my IRC bot posted this edit twice, once now with your current timestamp the other 9 minutes before.) ΔT The only constant 21:22, 13 December 2011 (UTC)
- Need to exclude The The as well. -- WOSlinker (talk) 21:20, 13 December 2011 (UTC)
- Actually that wasn't an error with the regex, there is a user already working on the list :) ΔT The only constant 21:07, 13 December 2011 (UTC)
- Yeah, that's fairly simple, must have forgotten about those. Ill adjust the regex and update the list. ΔT The only constant 21:04, 13 December 2011 (UTC)
(←) I love this idea! I am watching that page :) and I'll be going through some if not all of them using AWB. How often will they be updated? Hazard-SJ ㋡ 00:01, 18 December 2011 (UTC)
- Right now Im trying to get the logistics worked out. But my plans are to update the list regularly, and upon each database dump release. ΔT The only constant 03:23, 18 December 2011 (UTC)
Now that's a massively helpful use of automated technology. Running through with a few other perennials ("diety" - the slimming god, "and and" - the overexcited conjunction, the well known online encyclopaedia "Wikipeida" and so forth) to create specific lists, so editors are not distracted would be a cool resource. Elen of the Roads (talk) 16:37, 18 December 2011 (UTC)
- As soon as the current dramafest that is my arbcom case is over Im going to move this into full throttle. ΔT The only constant 16:42, 18 December 2011 (UTC)
- Are you reviewing each individual AWB edit manually for proper grammar following your change? "... the The ..." should not necessarily become "... The ..."; it might need to be "the" (e.g. [9] [10] [11] [12]). –xenotalk 16:20, 19 December 2011 (UTC)
- Yes, in that case I defaulted to assuming that in those cases The was part of the proper noun and edged on the side of caution to leave it capitalized. As for correct grammar, I am not a specialist in English grammar, but it does look correct to me. ΔT The only constant 16:26, 19 December 2011 (UTC)
request explicit user consent before moving a file to commons
I uploaded files to here and not Commons with good reason; I'm fine with them being on commons, but they are easier to manage from en.wiki (such as tracking where they are, for instance) and it is a rather a rude shock when you're tryimg to assemble an article months or years later and you find they are no longer in your contributions list or upload log (yes, they somehow...disappear). Could people please obtain the explicit consent of users before rudely moving their image to commons? John Riemann Soong (talk) 05:34, 14 December 2011 (UTC)
- Bear in mind that you consent to allow this with any of your contributions. Photos simply happen to be most likely to be moved off wikipedia entirely (rather than text which is edited, deleted, moved around, etc.). I have a number of files uploaded here rather than commons for a variety of reasons and I don't usually have an issue with someone else reuploading them to commons and deleting the copy here. IF that happens just download the commons copy and re-upload it. Protonk (talk) 06:11, 14 December 2011 (UTC)
- The problem is when people delete your files and you have no idea where they went (because they disappear from your upload log, and they don't show up as a redlink because they are on Commons). John Riemann Soong (talk) 07:35, 14 December 2011 (UTC)
- Use the {{keep local}} tag, designed for this purpose. Making requesting user consent mandatory would make the majority of cases, where the uploader is no longer active, rather difficult. However, I personally find that keeping them all on commons makes them easier to track, especially with the ListFiles function. sonia♫ 06:34, 14 December 2011 (UTC)
- You're free to use {{keep local}} if you really want, but keep in mind this means any improvements made to the images or their descriptions on Commons, possibly long after you've departed the project, will not be seen on enwiki. This should not be a long-term solution. I agree that tracking files moved to Commons by user is an important issue and hope that once it's solved it'll eliminate this concern. Obtaining permission beforehand is infeasible because many departed users are impossible to reach. Dcoetzee 07:36, 14 December 2011 (UTC)
- While I sympathize with your inconvenience here, having to get the permission of the author to move or change something flies in the face of so many principles, policies, and standards on Wikipedia that the answer is, flat-out, no. --erachima talk 08:01, 14 December 2011 (UTC)
- There's nothing wrong with having the file kept locally. Yes, it can be copied freely -- but deleting a perfectly good, encyclopedic, functional copy without the author knowing about it at all is an issue. John Riemann Soong (talk) 08:18, 14 December 2011 (UTC)
- Deleting an encyclopedic, functional copy where it is redundant is common and sensible-- say, for example, if a user made the same article twice under different names. Unifying all possible images in one place means that changes made will apply across all projects, making things more efficient (not to mention it being easier to find free files in one place). I doubt that anyone has meant to be rude in moving your files; they're just doing their job. The simple solution is to use {{keep local}}; it's created as a courtesy to users like you who prefer it this way, as much as it's not ideal. But your proposal is impractical and its implementation would slow file work dramatically. sonia♫ 08:36, 14 December 2011 (UTC)
- I seems that an automatic notification if/when a file is moved would be helpful. At least then people would know if the (not their) files were moved, and where to. fredgandt 08:43, 14 December 2011 (UTC)
- Yeah, notification could be done, but "explicit consent", no. It'd just add bureaucracy. Choyoołʼįįhí:Seb az86556 > haneʼ 08:51, 14 December 2011 (UTC)
- Oppose: moving to Commons no way harms editor — the image can still be watched, tracked and whatever. Moving images to Commons is in line with word and spirit of Wikipedia rules, and explicit author's content would just make matters worse for Wikimedia with no one's benefit. — Dmitrij D. Czarkoff (talk) 09:07, 14 December 2011 (UTC)
- Oppose, but see the problem: As WP:5P says 'all of your contributions can and will be mercilessly edited and redistributed.' However I do think that something better really should be done about the contribution list rather than deleting history. I find the business of contributions to deleted articles disappearing from history worrying too, I'd prefer they be listed even if one could not look at them. Personally I always upload to commons if possible, I view uploading to Wikipedia as something that only should be done for things with a restrictive license. Dmcq (talk) 10:26, 14 December 2011 (UTC)
- Oppose: Sleeping editors shouldn't block a move forever. A little background, before sending thousands of pix to Commons I sent hundreds (mostly more useful ones) to en and many of those have later been found by other edtitors and moved to Commons. Problem is, sometimes I don't see the notice in the original file, thus fail to follow the link and watchlist it in Commons, with the result that they are poorly categorized and not geotagged. So, if I fail to see the pre-announcement or otherwise do not object in a few days, the transfer ought to go ahead anyway. Silence implies consent. On the other hand, the thing I wish is, the moving bot should also watchlist it for me in Commons. Jim.henderson (talk) 19:39, 15 December 2011 (UTC)
- Oppose. I like the idea of an automatic notification if it's possible, but requiring consent would be problematic indeed. Commons exists for the sake of making media available to all WMF sites, so all images should be there unless there are copyright issues — please establish a Commons account and upload images there, rather than here. Nyttend (talk) 13:20, 18 December 2011 (UTC)
- Oppose per WP:OWN. I'm no fan of {{Keep local}} which is why I proposed a long time ago that it needs an optional reason parameter, but sadly that got shot down because, well, people who like OWNing their images and having to actually specify a reason for their desire to OWN might cause cognitive dissonance. And that would be bad. —Tom Morris (talk) 09:31, 20 December 2011 (UTC)
- oppose seaking permission before hand. I think it would be a good thing when the bot transfers the image to commons to post on the users talk that the move has occured, as user talk pages dont get deleted, if in the event that user becomes inactive the notifications will just sit there so that when the user is active again they'll know what happened. Gnangarra 09:51, 20 December 2011 (UTC)
Create a new userright
I propose to create a new userright. Users with this right would be able to circumvent the spam filter. The rationale behind this is that it would make my work archiving reference links MUCH easier (see also this discussion). The way I want to work is I copy all the reference links to a page in my userspace, then go through this list, archive the links with WebCite and add the archive link to the reference links in my userspace. Then I would go back to the article and add the archive link to the corresponding reference. Toshio Yamaguchi (talk) 20:27, 14 December 2011 (UTC)
- What happened to administrators? We can ask them to make necessary modifications if necessary. This doesn't often happen, so I wouldn't support. Hazard-SJ ± 03:48, 15 December 2011 (UTC)
- Last I checked, administrators can't get around the spam blacklist; other than adding something to the whitelist. This was last week I had this problem.--v/r - TP 03:58, 15 December 2011 (UTC)
- Bypassing the spam blacklist would render the page uneditable to all other users. No. T. Canens (talk) 04:13, 15 December 2011 (UTC)
- Not exactly, since approx. 2010 you can edit and save paged with blacklisted links: spamlist only prevents new blacklisted links. Still, I don't think a new userright is a proper solution to Toshio's problem. — AlexSm 04:29, 15 December 2011 (UTC)
- Bypassing the spam blacklist would render the page uneditable to all other users. No. T. Canens (talk) 04:13, 15 December 2011 (UTC)
- Last I checked, administrators can't get around the spam blacklist; other than adding something to the whitelist. This was last week I had this problem.--v/r - TP 03:58, 15 December 2011 (UTC)
- If it's any help, I recently submitted a patch that would help by telling you all the instances of offending links in one go. This makes it even easier to write a script that automatically 'nowiki's the bad links. - Jarry1250 [Weasel? Discuss.] 00:22, 18 December 2011 (UTC)
Turn Wikipedia off RfC
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm not sure what the state of play with the proposed shutdown of WP is. It looks like we will probably do nothing. But this is a last-ditch attempt at a concrete proposal. Please note that there is not much time left for fine detail, so please oppose this if you oppose the idea of a protest. If you support the idea of a protest but have quibbles about exactly how to do it, quibbling may well mean no clear consensus so nothing happens. Apologies but I will not be around for much of the discussion. Amend and tweak in good faith as you will.
I also have no knowledge about whether this will be technically do-able at short notice, so apologies if the RfC succeeds but still nothing happens.
Editors are asked to bear in mind that there was strong support for the general idea of action of the type described at User_talk:Jimbo_Wales#Request_for_Comment:_SOPA_and_a_strike.
The proposal
English Wikipedia articles will be made inaccessible to everyone geolocate-able to the United States from one minute past midnight EST on Thursday to midnight PST on Thursday.
The Wikipedia homepage will either stay as it is or consist of something appropriate to the action being taken, as decided by community consensus. Attempts to reach a particular page on en.wp will result in a redirect back to the homepage.
The lockout will apply to all readers and editors in the US except those who are absolutely needed for technical purposes.
Users outside the United States are encouraged to support the "strike" by not editing during it, except to undo vandalism.
Please vote support or oppose. --FormerIP (talk) 00:36, 15 December 2011 (UTC)
- Comment I would point out that RFCs customarily run a month. In a matter of such moment, how would it be fair to decide this based on whoever votes in the next four hours? I would say that would be very ill advised.--Wehwalt (talk) 00:44, 15 December 2011 (UTC)
- OK, well you've said it. Thank you for saying it. --FormerIP (talk) 00:45, 15 December 2011 (UTC)
- Its a good point; but, this is the best effort at process that can be made given the limits of the community's neglect of processes for snap actions and/or the threat of this law to it. It is an attempt more in line with process than private consensus building attempts that appear to have no actionable component. Fifelfoo (talk) 00:50, 15 December 2011 (UTC)
- It's past midnight in the UK. Generally, in societies where people's rights are valued, sneaking things through in the middle of the night is disfavored. While their access, of course, would not be blocked, for certain they might have something to say about the politicization of this website. As might those Americans and Canadians who only edit during the day.--Wehwalt (talk) 01:05, 15 December 2011 (UTC)
- This is an excellent reason to argue that this RfC not be abnormally closed, or abnormally closed early. I notified WP:AN/I of this RfC, and suggest that you restate this point there as well. Despite supporting this RfC, I support your argument that it not be abnormally closed, and will make this point at AN/I myself right now. Fifelfoo (talk) 01:14, 15 December 2011 (UTC)
- It's past midnight in the UK. Generally, in societies where people's rights are valued, sneaking things through in the middle of the night is disfavored. While their access, of course, would not be blocked, for certain they might have something to say about the politicization of this website. As might those Americans and Canadians who only edit during the day.--Wehwalt (talk) 01:05, 15 December 2011 (UTC)
- Support. I support the en.wikipedia taking action where another body poses a serious threat to the encyclopaedic process; but, where our action does not compromise our responsibility as encyclopaedists by altering content. Given the timeframe, this "snap action" combines a symbolic representation of outrage, with a real economic threat presented by locking out US geolocated users and by forming a moral picket against use of the encyclopaedia amongst non-US users. It is far more strategic than either an indefinite withdrawal of service, or a purely symbolic advertisement. This balance represents the broad balance of a consensus building straw poll on a well trafficed user page. This gives us "currency" and would allow us time to make a more considered action or inaction decision after the highly time critical element of the US state's process has occurred. Fifelfoo (talk) 00:50, 15 December 2011 (UTC)
- Support I have no hesitation in joining anything which helps build this movement doktorb wordsdeeds 00:53, 15 December 2011 (UTC)
- Support. Ironholds (talk) 00:54, 15 December 2011 (UTC)
- Comment. If the proposal goes through it has my moral support. However I am uneasy about the precedent. Until now, as far as I'm aware, English Wikipedia has never taken an explicit political stand on anything. If we do it once, will the next one seem like something all right-thinking people should agree with, but it's less directly connected with our mission? And then the one after that maybe I don't agree with? If this is adopted I think it needs to be with the clear understanding that it does not open the floodgates to political action on WP's part on just any issue where say 80% of editors happen to be on the same side; it's an exceptional action that should be taken only when the legislation is a direct threat to the encyclopedia as such. --Trovatore (talk) 01:03, 15 December 2011 (UTC)
- Agreed. —David Levy 01:09, 15 December 2011 (UTC)
- Support, but the only realistic way this is going to happen in the required timeframe is bold action by Jimbo Wales, not through an RfC. He had his informal poll, for what it's worth; not ideal, but certainly an indication of where the community stands. CharlieEchoTango (contact) 01:07, 15 December 2011 (UTC)
- Support. Replace the main page with an explanatory message and point all pages to it (or something comparable). And just as the French Wikipedia's strike wasn't restricted to France, I don't believe that this one should be restricted to the United States (given the fact that the proposed legislation stands to affect readers around the world). If that's a sticking point, however, a U.S.-only protest is better than nothing. —David Levy 01:09, 15 December 2011 (UTC)
- Oppose until we get a wider and more authoritateve consensus than can come from the relatively few who watch VP and respond to a day's notice. For example, a week's worth of replies to a banner replacing the money-begging ones.Jim.henderson (talk) 01:12, 15 December 2011 (UTC)
- Oppose. Time to take a deep breath. Let Jimbo and the WMF decide how they want to communicate with the US government. No one in the government is going to shut us down in the next few days, so we don't need to over-react. Jimbo said very clearly on his talk that any actual shutdown would require thorough evaluation and consensus by the community. That's going to take some time. --Tryptofish (talk) 01:14, 15 December 2011 (UTC)
- I guess I should support as OP. And add a request for the closer to consider in conjunction with the discussion on Jimbo's talkpage. --FormerIP (talk) 01:16, 15 December 2011 (UTC)
- Oppose; if consensus is to lockdown we need to a) write a proper notice to explain the action to our users (otherwise the event is pointless) b) estalish proper media coverage (or the event is useless - simply reporting us being down is useless if there is no organised media response) c) confusing. Rushing it through in a few hours with probably minimal input is also problematic. (FWIW I don't think it is technically possible to implement a US geolocated lockdown with any tools available to admins - unless we find a way to hack geonotices). If the community is in favour of a shutdown, fine. But we need to do it properly, with (as Jimbo said), careful discusion as to options. This can only hurt our cause. --Errant (chat!) 01:17, 15 December 2011 (UTC)
- Oppose - With respect, this RfC is pointless. Jimbo has had plenty of response on his talk page, and if he intends to play god with the site, he will do so regardless of this RfC. (I would also note that we do have a process for things that require "snap action": WP:BOLD.) If this RfC is felt to be required because the discussion at Jimbo's has not yielded a firm consensus, then we already have the answer. Giving 3-4 hours for the few people who are on right now, and read this page to determine the ability of everyone to edit and read would be a complete farce. I might be in favour of blanking the main page only, but at this point, it is too late for the community to achieve a legitimate consensus on shutting the entire site down at midnight EST. Resolute 01:18, 15 December 2011 (UTC)
- The discussion on Jimbo's talk page has yielded a firm consensus, but it explicitly wasn't intended to determine a specific implementation. —David Levy 01:23, 15 December 2011 (UTC)
- And there is absolutely no possible way that such an implementation could be determined in three hours. More over, the community does not have the power to shut the site down for just American users. Even if it did, to allow a couple dozen dictate something this big to the thousands who will not have even the opportunity to give input would be ridiculous. Let Jimbo and/or the foundation decide what to do, or pick another date that allows time for the entire community to weigh in. Resolute 01:29, 15 December 2011 (UTC)
- Those are valid points, and I agree that this proposal is unlikely to succeed. I'm merely addressing your comment regarding "the discussion at Jimbo's [possibly having] not yielded a firm consensus." —David Levy 01:39, 15 December 2011 (UTC)
- And there is absolutely no possible way that such an implementation could be determined in three hours. More over, the community does not have the power to shut the site down for just American users. Even if it did, to allow a couple dozen dictate something this big to the thousands who will not have even the opportunity to give input would be ridiculous. Let Jimbo and/or the foundation decide what to do, or pick another date that allows time for the entire community to weigh in. Resolute 01:29, 15 December 2011 (UTC)
- The discussion on Jimbo's talk page has yielded a firm consensus, but it explicitly wasn't intended to determine a specific implementation. —David Levy 01:23, 15 December 2011 (UTC)
- Oppose until we have a firmer starting point with drafts.--Guerillero | My Talk 01:20, 15 December 2011 (UTC)
- Support. I very strongly agree with the proposal. Time and again issues like this in the US have been decided solely by legislative agenda because those of us who care - the members of a certain community, or even the whole Internet community - have raised awareness among ourselves but not enough with the general public. I feel that something on the scale of "turning off" English Wikipedia is absolutely necessary to raise the public awareness this cause needs. And make no mistake, this is an issue which can shake the Internet as we know it today to its foundation. I would furthermore suggest that, during the time English Wikipedia is disabled, site-wide headers be added to all other Wikipedia sites explaining the situation. Jantman (talk) 01:20, 15 December 2011 (UTC)
- Oppose Even if all the dots were crossed and the ts dotted, this would still be an ill-advised proposal. As it is, it will set the community at each other when people realize what happened who do not edit Wikipedia incessantly.--Wehwalt (talk) 01:22, 15 December 2011 (UTC)
- Strong support - (edit conflict)x2 We have never had something so directly threaten Wikipedia and basically the vast majority of the internet in the past and I feel that due to the unprecedented threat an equally unprecedented response is fully justified. Barts1a | Talk to me | Yell at me 01:23, 15 December 2011 (UTC)
- Oppose – The deadline for this proposal (less than four hours from when this comment is posted) is outrageous. This doesn't leave much time for the community to be involved in planning stages of this proposal. We haven't even constructed "Learn why SOPA will be bad for Wikipedia and the Internet" message that the readers will see. This proposal is being rushed through. We should at least be on the same page as Jimbo and the WMF. --Michaeldsuarez (talk) 01:25, 15 December 2011 (UTC)
- As one of 47,553,696 who actually knows what this rushed mess is all about, I have to say; for a web site that prides itself on neutrality and protection of copyrights, to throw a hissy-fit and shut itself down out of fear of something that might not even happen, that might actually do some good, that might not be as bad as pundits predict even if not good, or that at worst could be undone if found to have been a bad idea, is plain bloody stupid.
- As for this half-arsed RfC, shockingly shoddy and painfully panic inducing. fredgandt 01:27, 15 December 2011 (UTC)
- Oppose trying to get this done in less than five hours. --Yair rand (talk) 01:28, 15 December 2011 (UTC)
- Send him to the stocks You're trying to shut the site down with a six hour poll? I recognize that people aren't sanctioned for idiodic proposals, but this is ridiculous. Buddy431 (talk) 01:30, 15 December 2011 (UTC)
- Oppose Whilst I completely disagree with SOPA, I do not think that it is in our best interests to blank Wikipedia. SmartSE (talk) 01:34, 15 December 2011 (UTC)
- Moral support for the proposal, but I'm with Buddy— send him to the stocks. The previous RfC was crystal clear, and if Jimbo wants to turn off Wikipedia based on that, then he should do so by all means. But starting a "concrete proposal RfC" to supposedly determine this in only a few hours is absurd. The vast majority of users who supported this in the previous RfC may well not get to comment on this at all. Swarm X 01:37, 15 December 2011 (UTC)
- Strongly Oppose Isn't fair to shut down a website without a fair and reasonable proposal and at least some time to debate over it. People rely on Wikipedia on a daily basis, and doing this would be too risky. --Radiokid1010 (talk) 01:46, 15 December 2011 (UTC)
- Moral support, practical oppose. If people who've looked at the current SOPA proposals think it would have a serious, deleterious effect on Wikipedia editing then a protest like this is appropriate. But it should be done with wide consensus and careful consideration to getting the most benefit. I would support a similar proposal for a temporary shutdown next week or next month. Will Beback talk 01:47, 15 December 2011 (UTC)
- Oppose. I've opposed it on Jimbo's talk page, and I'll oppose it again. Going on strike will damage Wikipedia's reputation as a neutral encyclopedia in the eyes of the global community, and it will be a betrayal of every editor who contributed with the expectation that Wikipedia would remain neutral and not become a political tool. I will not !vote for the destruction of Wikipedia's reputation, and I will not !vote for the splintering of our community and the breaching of our contributors' trust.--Slon02 (talk) 01:50, 15 December 2011 (UTC)
- Oppose procedurally and substantively. Procedurally, this is completely unfair to users who live time zones where the few hours this would be open are inconvenient for editing, or who are traveling for the holidays, or who don't edit on Wednesday/Thursday. Way to go countering systemic bias. Substantively, it is inappropriate for the community to compel any user to edit or not edit to make a political point. It would also set a truly awful precedent, with unknowable consequences. If some threshold of consensus is all it takes to turn Wikipedia into an instrument of politics, then Bill O'Reilly can take over the encyclopedia if 1% of his three million nightly viewers respond to a call to register accounts. Even if nothing like that happened, Wikipedia would be permanently politicized. Every time a controversial piece of media legislation got introduced, it would be "How will Wikipedia respond?" all over the news. Lagrange613 01:52, 15 December 2011 (UTC)
- Meaningless RFC that should be closed and ignored. I've had meals that lasted longer than the proposed duration of this RFC. Townlake (talk) 01:56, 15 December 2011 (UTC)
- Oppose on procedural grounds for reasons stated by Errant. This was never proposed to be implemented immediately and the decision to do so should not be rushed. Also opposed on substantive grounds for the reasons I stated on Jimbo's talk page. I think there is a better than 50/50 chance that if Wikipedia does this, we are going to regret it later. Many of the "votes" on Jimbo's talk page simply expressed opposition to the legislation, and I oppose it too, but that doesn't mean that this is the correct strategy to fight against it. Neutron (talk) 01:57, 15 December 2011 (UTC)
- Oppose as not a meaningful process. I happen to have woken up in the middle of the night in the UK and spotted this odd discussion. It may be a hoax or perhaps just an exercise in pointiness, but I have no intention of spending time investigating as I need to get back to sleep. Please close this non-RFC as malformed. --Fæ (talk) 01:58, 15 December 2011 (UTC)
- Support - If we aren't willing to stand up to a threat to our operations, then why are we contributing in the first place? I'd also point out what Jimbo, the WMF and many others have said; that Wikipedia is political by it own nature. Sharing knowledge freely and openly has always been inherently subversive and a political act throughout recorded history, including modern times. - Hydroxonium (T•C•V) 02:06, 15 December 2011 (UTC)
- (edit conflict × 5)*Support - as I said at the original RfC, this is not about politics, but what is good for the encyclopedia. This bill gives control of the internet to whoever wants to spend the most money censoring it, which is the pretty much the opposite of the egalitarian and free access to knowledge this site provides. We've already had an RfC about this (and those who opposed should not ignore that they got outside votes as well), so this should really be a discussion of whether we're going to do a banner or a complete blank. Ian.thomson (talk) 02:13, 15 December 2011 (UTC)
Making editing easier
This is something that had bugged me for a very long time: How come the way we edit on Wikipedia is needlessly complicated? Although I have come to terms with it (at least with most of it), I imagine that a turn off for many new editors is how confusing everything is. They would not know how to use templates/categories/infoboxes etc. or even know how to bold or use headings. On many online sites, where you can contribute to discussions etc, there are buttons at the top of the editing box, not unlike microsoft word, that allow you to easily edit colour/bold/size etc. and a lot of other stuff without having to worry about three lines for bold and a copy and pasted line of text for colour etc. In other words, what you see is what you get. Whilst editing, you would see stuff in bold or coloured etc. Also if there were buttons along the "Advanced", "Special Characters", "Help", "Cite" row that had all the infoboxes/templates etc.. or something like that... it would make all our lives soo much easier. Why isn't this done?--Coin945 (talk) 11:19, 16 December 2011 (UTC)
- There is wikiEd – is that what you were looking for? It Is Me Here t / c 15:04, 16 December 2011 (UTC)
- And see Wikipedia:Village pump (technical)#Visual editor. – ukexpat (talk) 15:18, 16 December 2011 (UTC)
Reply link/button at the end of talk page sections
Currently editing the section loads the whole source and sections are sometimes very long and all that content is loaded in to the edit-box as well. How about placing a small reply link (or button) at the end of talk page sections, clicking which will load the same section as an almost empty edit box and by default will have only the indentation suitable for a reply to the last comment which could be changed if required by the editor. This will prevent loading the whole text if some one only needs to reply and will also prevent mistaken editing of other comments. Or maybe even better than the reload, clicking the reply link expands into an edit box of the same format as mentioned above and clicking a save button in that would simply post the reply at the end but not reload the page instead become "your reply has been saved - reload page to see it" or something similar. The normal editing can still take place by clicking the 'edit' link while this will be an additional help. The proposal is open to be further decided as an opt-in/opt-out option that would be adjustable by individual users for themselves so as to see or not to see the reply link. --lTopGunl (talk) 15:27, 16 December 2011 (UTC)
- The Liquid Threads extension does this, but we don't use it. I would however oppose implementation of the extension as many talk pages would need reconstruction. Hazard-SJ ㋡ 23:54, 17 December 2011 (UTC)
Remove fundraising banners once a person has contributed
Would it be possible to remove fundraising banners for IPs from which donations have already been received this year? — Preceding unsigned comment added by Heymisterbill (talk • contribs) 20:54, 16 December 2011 (UTC)
- technically, probably, but that would involve tracking and finding out whether it's a public computer (removing it from a shared computer is not good). And it would only work with cookies or something. Choyoołʼįįhí:Seb az86556 > haneʼ 22:16, 16 December 2011 (UTC)
- In theory, it already does that. --Yair rand (talk) 05:42, 19 December 2011 (UTC)
RfC on eliminating the comment from the Persondata template
There's an RfC on eliminating the need to add the <!-- Metadata: see [[Wikipedia:Persondata]] --> comment from the persondata template and perhaps even eliminating it from the articles as more significant edits are made. It's at eliminating the comment from Persondata. I'm spamming it here because it's a highly visible template and this issue has come up multiple times in multiple venues for multiple reasons and I would like to put it to rest once and for all. --Kumioko (talk) 04:10, 17 December 2011 (UTC)
Change "My talk", "My preferences", etc to "Your talk", "Your preferences", etc
Reading on the direction the WMF is going in with the Athena skin as well as what is already implemented on other sites such as Flickr, I propose a change in terminology from "My talk", "My preferences", etc. to either "Your talk", "Your preferences", etc. or even simply "Talk", "Preferences", etc. Some of the reasons laid out on the MediaWiki page and other websites include the following:
- "My" is akin to labels being placed on objects. This goes against the fact that the website (i.e. Wikipedia) has provided people with a talk page, tweakable preferences, watchlist, etc.
- Something like "Your..." is more indicative of a two-way conversation and is not as asocially suggestive as "My..."
- It serves to discourage the mentality of page ownership, reenforcing a key aspect of open wikis in that there is no ownership of pages.
- As a more general corollary to the above point, it would distance us from individual-centric sites such as Myspace and bring us closer of sharing, community-centric sites such as YouTube.
- It's easier to tell someone to "Go to 'Your preferences'" instead of "Go to 'My preferences'".
Thoughts? –MuZemike 01:52, 18 December 2011 (UTC)
- Any reason why there is a "My" in the first place? On GMail, I click on "account settings", not "my account settings". Why is this not the case here?
p-personal
is obviously a user-specific panel, so there is no need to make it more obvious through the use of pronouns, it seems to me like we could do without them (e.g. <userpage> | Messages | Preferences | Watchlist | Contributions | Log out)... In any case, to address the actual proposal, I don't really find the argument convincing. Asocial is open to interpretation (for example English is considered by some an asocial language for being individual-centric (e.g. by its extensive use of possessive pronouns), but that's true only if one accepts that individualism is a bad thing.) I'm not opposed to the proposal per se, but what's the concrete benefit of changing 'my' to 'your'? For example, re point 3, why should we discourage ownership of watchlist pages, which are private and user defined (therefore "owned"), or contribution pages, which are specific to a user? The only page affected here is "My talk", but we do (thankfully) give much leeway on how users manage their talk page, which implies some level of ownership. As for having conversations with a software, well... that's beyond me. But sure, go ahead, your, my, nothing, whatever. :-) CharlieEchoTango (contact) 06:50, 18 December 2011 (UTC)- "My" is the only way to convey that these pertain to the user who's viewing the page: "Your" is not specific (from my point of view, any other person is "you", but I'm not "you" to myself), and without any pronouns at all, the links don't convey the fact that these pertain to the individual user. Moreover, Charlie has a good point: WP:OWN doesn't affect what you set for your preferences or the content of your watchlist, "my talk" goes to the user talk page for the person who clicks it, and "my contributions" goes to the contributions for the user who has made them. Nyttend (talk) 13:06, 18 December 2011 (UTC)
- I certainly think My expressions like 'I've said a bit more about this on your My Talk page but you open your My Preferences and ...' sound rather strange. I'm happy enough to go along with just keeping to the WMF My decision but I hope you excuse me making my fun of it every so often ;-) Dmcq (talk) 18:37, 18 December 2011 (UTC)
- Seems to me to be change for the sake of change. If "My" is not considered appropriate as it implies (to heavily) ownership, surely something like "User preferences" and "User talk" would make more sense. If I give something to someone and say "This is now yours", I expect them to feel a sense of ownership of the gift. Playing with words for no practical gain is a waste of time. If this were a technical fix, I might support it. fredgandt 19:22, 18 December 2011 (UTC)
If/when Athena arrives, we can change things. Until then, as Fred Gandt says, this is change for change's sake. —Tom Morris (talk) 09:28, 20 December 2011 (UTC)
Proposal to add -suppressredirect to the filemover user group
Currently, when a filemover moves a file, a redirect is always left behind. However, after all instances of the file have been replaced with the new file name, the redirect becomes obsolete and the redirect is deleted. I would like to propose that -suppressredirect be added to the file mover user group. It would allow a file mover to move a file without leaving a redirect behind, and save an admin from having to come by and delete the obsolete redirect. Alpha_Quadrant (talk) 04:26, 18 December 2011 (UTC)
- Would there be any cases where a redirect being left behind was desirable or even necessary? fredgandt 04:37, 18 December 2011 (UTC)
- There may be exceptions where the current title serves as attribution, something like Template:Copied. There wouldn't be any problem with keeping the redirect unless the image is non-free. If a redirect is used instead of the actual filename, the use will not display in the "File usage" section on the file description page. This poses a potential challenge for non-free content enforcement, as every use of an un-free file should have a specific fair use rationale. While the use would still be listed in WhatLinksHere, it would not be listed in the "File usage" section, making it a bit more difficult in tracking the usage. Alpha_Quadrant (talk) 04:58, 18 December 2011 (UTC)
- Very bad idea. The creation of a redirect should only be suppressed when the redirect qualifies for speedy deletion, and in the vast majority of cases, that's not the case with the image. In particular, redirects never qualify for R3 (newly created and unlikely) unless the original title is new; if File:IMG 2222.jpg was uploaded in 2005 and you move it to File:Descriptive Title.jpg in 2011, it does not qualify for R3, because despite what the history of File:IMG 2222.jpg says, the title has existed since 2005. Nyttend (talk) 13:01, 18 December 2011 (UTC)
- There may be exceptions where the current title serves as attribution, something like Template:Copied. There wouldn't be any problem with keeping the redirect unless the image is non-free. If a redirect is used instead of the actual filename, the use will not display in the "File usage" section on the file description page. This poses a potential challenge for non-free content enforcement, as every use of an un-free file should have a specific fair use rationale. While the use would still be listed in WhatLinksHere, it would not be listed in the "File usage" section, making it a bit more difficult in tracking the usage. Alpha_Quadrant (talk) 04:58, 18 December 2011 (UTC)
- Is this proposal for the generic supress-redirect or a new image specific one? Yoenit (talk) 13:23, 18 December 2011 (UTC)
- This proposal is for the generic -suppressredirect. It would require additional unnecessary work to implement the tool for just the file namespace. File redirects do qualify for G6, G7 (if nominated by the mover), and R3. If the file has just been moved, the redirect was just created. It doesn't matter how long there was an image there, the redirect is still new. The deletion of these redirect are non-controversial providing all incoming links are corrected. The previous name was incorrect for some reason. And if the redirect is tagged by the file mover, then it is a valid author requested tagging. I have seen some file movers take redirects to RfD, but I am yet to see one of these redirect nominations challenged and kept. It would be excessively bureaucratic to have to send all of these obsolete redirects to RfD, where they are always deleted after 7 days.
- If an image is renamed under file move criterion #1, the original uploader has requested a move for some reason. Usually these requests are made because of an error they made. Redirects can safely be deleted, as the reasons for the move are often based on one of the other below reasons.
- If a file is renamed under file move criterion #2-5, the original file name was completely incorrect. The redirect left behind is completely implausible and can be deleted after all file usages are corrected.
- If a file is renamed under file move criterion #6-7, the file was moved to harmonize with the rest of a group of images or disambiguate images with very similar names. These redirects are obsolete after all instances are corrects, and the redirect can safely be deleted.
- If a file is renamed under file move criterion #8, the redirect must be deleted, as the original file name was pejorative, offensive or crude. If this file redirects to a file depicting a living person, the redirect would potentially violate the biography of a living person policy.
- All of the above reasons are non-controversial. There may be the occasional exception, but overall, these redirects are obsolete once the file instances are corrected. Alpha_Quadrant (talk) 17:10, 18 December 2011 (UTC)
- I support this: people with the permission can choose if the redirect is left or not, so in case it's needed to keep it, they would just not check it. Petrb (talk) 13:57, 18 December 2011 (UTC)
- Oppose: Deleting image redirects should only happen in exceptional circumstances, and the need for this ability is therefore substantially decreased. I worry that if this right is given to all file movers, it will be misused unintentionally. This right is handed out fairly liberally (and rightly so), but in the rare circumstances where redirect deletions are needed, they should be tagged and reviewed by administrators. PeterSymonds (talk) 18:25, 18 December 2011 (UTC)
- Deletion of delinked file redirects are a commons occurrence though. For example Wikipedia:Redirects for discussion/Log/2011 October 26. Once the redirects have been delinked, the deletion is non-controversial. Suppressredirect does not allow users to delete anything. The flag just allows the user to skip auto-creating a redirect. Failing to create a redirect after a file move has no more potential damage than moving files themselves. As far as finding the renamed files, the move log will be visible, directing to the new file name. Alpha_Quadrant (talk) 19:43, 18 December 2011 (UTC)
- What about proposing a trial for limited time (1 month) to check if this feature would be misused or constructive update of configuration? Maybe it would be better than permanent change, Peter's point makes a lot of sense, however it's hard to know if it would be really misused or not, file moving does happen rarely on english wikipedia and people who do that are probably familiar with the rules enough. Petrb (talk) 20:50, 18 December 2011 (UTC)
- Oppose - A recurrent complaint from uploaders is that files are moved (either on this project or to Commons) without appropriate linkages or notification, and subsequently cannot be relocated. At least with the redirects, people have a chance to find their now-moved uploads. Risker (talk) 18:29, 18 December 2011 (UTC)
- Even after a file redirect has been deleted, it still leaves behind text pointing to the new page.
“ | 19:20, 18 December 2011 (UTC) Example (talk | contribs) moved File:Example.jpg to File:New filename.jpg (Move reason here) | ” |
- So even if the redirect is deleted, the author can still find the upload quite easily. The problem is when the image is transfered to commons under a new name, and the administrator does not make a note in the deletion log as to what the new commons name is. Alpha_Quadrant (talk) 19:20, 18 December 2011 (UTC)
- Oppose. Even if we assume that eliminating these redirects is desirable (which is disputed), how does it make sense to do so before transclusions have been updated (thereby breaking them in the interim)? —David Levy 20:10, 18 December 2011 (UTC)
- The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move. In the off chance there are a large number of file tranclusion replacements needed, AWB or a script could be used to quickly make the replacements. Over at commons, User:CommonsDelinker goes through and makes the translusion corrections after the file rename. How is keeping the file redirects desirable? As I have linked above, they are deleted after they are delinked. There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial. Alpha_Quadrant (talk) 20:20, 18 December 2011 (UTC)
- The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move.
- No, the two scenarios aren't comparable.
- Firstly, a double redirect merely adds an additional step (a link that must be followed). This is inconvenient, but it doesn't sever access to the desired content. Conversely, if an image were to be moved without leaving behind a redirect, all transclusions would simply be broken (resulting in red links instead of media).
- Secondly, the need to repair double redirects is unavoidable (unless settings are changed to enable them to function as normal redirects, which I believe proved too resource-intensive). Conversely, the current setup already prevents broken transclusions from arising as a result of file moves.
- How is keeping the file redirects desirable?
- It's been noted that this assists users seeking files under their original names (who might otherwise have difficulty finding them) and prevents transclusion breakage in historical page revisions.
- As I have linked above, they are deleted after they are delinked.
- And if we assume that the redirects should be eliminated, that's the proper means of accomplishing the task (deleting them after they're delinked).
- There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial.
- Some users are expressing opposition now. Has a relevant community discussion ever occurred? RfD isn't a high-traffic forum, so it's possible that the practice has gone largely unnoticed. —David Levy 21:21, 18 December 2011 (UTC)
- A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location. This move notice provides an easy way for the user to find the file. If a uploader is looking for an old file they uploaded, it is more plausible that the uploader would look at their contribution page, rather than searching for it manually. This is especially true considering that most of the file moves are done because the images have random strings of numbers. If a user checks an old page revision with a moved image, they will find the image after clicking the red link. File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all. There are a fair number of users involved in RfD. Hundreds, if not thousands, of badly named files have been renamed in that time period. That is not something that can go unnoticed. If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up. Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale. Alpha_Quadrant (talk) 21:41, 18 December 2011 (UTC)
- A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location.
- The latter statement is true for administrator/confirmed/autoconfirmed accounts. Please log out and click on File:PICT3902.JPG.
- Regardless, would you honestly expect most readers to follow such a link? And are you suggesting that this would result in an experience comparable to the media's transclusion in the article ("merely [adding] a second step" to its access)?
- If a user checks an old page revision with a moved image, they will find the image after clicking the red link.
- See above.
- Regardless, that isn't the same as viewing the image in its intended context.
- File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all.
- Again, there appears to be opposition now. I'm expressing neither agreement nor disagreement. I'm merely acknowledging its existence.
- There are a fair number of users involved in RfD.
- You linked to a page on which numerous nominations simply went unchallenged. That establishes an absence of expressed opposition, but it provides no indication of wide awareness or consensus within the Wikipedia community.
- If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up.
- Setting aside your description of the redirects as "useless", such opposition has been raised in this thread. Are you suggesting that it's too late for these opinions to be considered?
- Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale.
- Of course it is. It just doesn't necessarily outweigh one or more deletion rationales. —David Levy 23:23, 18 December 2011 (UTC)
- A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location. This move notice provides an easy way for the user to find the file. If a uploader is looking for an old file they uploaded, it is more plausible that the uploader would look at their contribution page, rather than searching for it manually. This is especially true considering that most of the file moves are done because the images have random strings of numbers. If a user checks an old page revision with a moved image, they will find the image after clicking the red link. File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all. There are a fair number of users involved in RfD. Hundreds, if not thousands, of badly named files have been renamed in that time period. That is not something that can go unnoticed. If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up. Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale. Alpha_Quadrant (talk) 21:41, 18 December 2011 (UTC)
- The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move. In the off chance there are a large number of file tranclusion replacements needed, AWB or a script could be used to quickly make the replacements. Over at commons, User:CommonsDelinker goes through and makes the translusion corrections after the file rename. How is keeping the file redirects desirable? As I have linked above, they are deleted after they are delinked. There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial. Alpha_Quadrant (talk) 20:20, 18 December 2011 (UTC)
- Support there is no reason to keep behind redirects to titles like File:IMG_156987. If the mover does what he is supposed to, all uses of the file are switched over to the new better name. I do think that we need to patrol people's file moves more like they do at commons. I have seen people move files that do not need to be moved in any way --Guerillero | My Talk 20:26, 18 December 2011 (UTC)
- To the contrary, one reason that we keep these titles (like all other titles) is that their deletion causes problems in article histories. That's a major reason that we have RFD: it exists to get rid of titles that aren't useful, but a title that's been linked in an article is generally useful. The speedy deletion criterion only permits the deletion of new titles, and proposing a solution that will get around this is entirely unacceptable — the criterion may only be ignored in unusual circumstances, so making it easy for deletion policy to be ignored is a very bad idea. Nyttend (talk) 20:45, 18 December 2011 (UTC)
- RfD is designed to determine whether or not a redirect meets the redirect guidelines. We do not keep redirects just because it is linked to in a previous page revision. Now if the redirect has useful page history, then in that exception, we would keep it. If we were to keep all pages just because it was linked once, there is very little that we could delete. When we have XfD discussions, no votes "Keep, it was linked to once, so we need to keep the page so that it doesn't show up as a red link if someone looks at an old revision of the page." It isn't a valid reason for keeping a page. For example, this diff from 2005. There are a large number of red links there, that, at the time the edit, were blue links. Wikipedia changes constantly. Red links in old revisions are inevitable. Alpha_Quadrant (talk) 21:02, 18 December 2011 (UTC)
- No one has asserted that historical usage automatically precludes a redirect's deletion. But there should be consensus that the harm caused by retaining a redirect (or type of redirect) outweighs the benefits. If a redirect (or type of redirect) causes no significant harm, even a minor benefit is a sufficient reason to retain it. (This is hypothetical. I'm not expressing an opinion regarding the harm:benefit ratio.) —David Levy 21:21, 18 December 2011 (UTC)
- Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect. The names are inappropriate for some reason. Given that we are transferring our free images to commons, that will just leave non-free images and a few free images that cannot yet be transfered there. As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page. Alpha_Quadrant (talk) 22:04, 18 December 2011 (UTC)
- Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect.
- Benefits have been clearly noted. It's reasonable to argue that they're minor and outweighed by detriments, but it's unreasonable to claim that they don't exist.
- As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page.
- That's a valid argument as to why the detriments of retaining redirects to non-free files presently outweigh the benefits, not evidence that no benefits exist.
- This problem strikes me as something potentially fixable via a MediaWiki improvement. —David Levy 23:23, 18 December 2011 (UTC)
- Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect. The names are inappropriate for some reason. Given that we are transferring our free images to commons, that will just leave non-free images and a few free images that cannot yet be transfered there. As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page. Alpha_Quadrant (talk) 22:04, 18 December 2011 (UTC)
- No one has asserted that historical usage automatically precludes a redirect's deletion. But there should be consensus that the harm caused by retaining a redirect (or type of redirect) outweighs the benefits. If a redirect (or type of redirect) causes no significant harm, even a minor benefit is a sufficient reason to retain it. (This is hypothetical. I'm not expressing an opinion regarding the harm:benefit ratio.) —David Levy 21:21, 18 December 2011 (UTC)
- RfD is designed to determine whether or not a redirect meets the redirect guidelines. We do not keep redirects just because it is linked to in a previous page revision. Now if the redirect has useful page history, then in that exception, we would keep it. If we were to keep all pages just because it was linked once, there is very little that we could delete. When we have XfD discussions, no votes "Keep, it was linked to once, so we need to keep the page so that it doesn't show up as a red link if someone looks at an old revision of the page." It isn't a valid reason for keeping a page. For example, this diff from 2005. There are a large number of red links there, that, at the time the edit, were blue links. Wikipedia changes constantly. Red links in old revisions are inevitable. Alpha_Quadrant (talk) 21:02, 18 December 2011 (UTC)
- To the contrary, one reason that we keep these titles (like all other titles) is that their deletion causes problems in article histories. That's a major reason that we have RFD: it exists to get rid of titles that aren't useful, but a title that's been linked in an article is generally useful. The speedy deletion criterion only permits the deletion of new titles, and proposing a solution that will get around this is entirely unacceptable — the criterion may only be ignored in unusual circumstances, so making it easy for deletion policy to be ignored is a very bad idea. Nyttend (talk) 20:45, 18 December 2011 (UTC)
- Comment I am really happy to see that most of opposing are sysops :) that implies that although it might look bothering to them to fix file moves after file movers, they probably don't have problem with that. It seems that proposal was started to spare them of that activity, but maybe it's not necessary. However I still believe that giving this bit to file movers would cause no harm. Petrb (talk) 20:54, 18 December 2011 (UTC)
- Breaking file transclusions is harmful. —David Levy 21:21, 18 December 2011 (UTC)
- Oppose David explains it well; Nyttend brought up points I didn't even think of. Choyoołʼįįhí:Seb az86556 > haneʼ 21:46, 18 December 2011 (UTC)
- Oppose - deleting redirects is often unnecessary and user hostile; adding 'suppressredirect' to filemover would extend deletion privileges to 235 users who have not been vetted for the same. –xenotalk 16:09, 19 December 2011 (UTC)
- Support- I support this fully. Also, if to compromise, would it be possible to ask the developers to create a new right
'suppressredirect-file'
and only allow it to work in the file namespace? JoeGazz ♂ 01:51, 20 December 2011 (UTC)
Ability to delete latest revisions of files
While I'm doing my part to reduce the huge backlog in Category:Non-free images with orphaned versions more than 7 days old, I've several times found images in which an old version, not the current version, is preferable; for example, if the latest version is of substantially higher resolution than an older version. Unfortunately, in such cases I must delete the entire image, rather than just deleting the version, and then I need to restore the older version. If it's possible, I'd like to see the (del/undel) text for the latest revision be just as useful as it is for all older versions. Is it possible? Nyttend (talk) 13:11, 18 December 2011 (UTC)
- For an example of what I'm talking about, look at the logs for File:Beastie Boys - Ch-Check It Out CD cover.jpg. Nyttend (talk) 13:15, 18 December 2011 (UTC)
Coordinated SOPA reaction in early 2012 RfC
It was announced on December 16, 2011 that a floor vote on SOPA is delayed, likely until early 2012. While the threat of this legislation still looms, the brief reprieve gives our community time to reach a meaningful consensus about whether to take action, and what action to take.
Background information
The Stop Online Piracy Act ("SOPA", H.R.3261) is a piece of proposed federal legislation in the United States. The bill would expand the ability of law enforcement and copyright holders to fight online trafficking in copyrighted intellectual property and counterfeit goods. It has seen widespread opposition from all corners of the Internet, and poses a unique threat to Wikipedia's continued operation.
Two proposals for a response from the Wikipedia community have been advanced so far (first proposal, second proposal), but neither was conducted with enough lead-time to reach a meaningful consensus.
Proposal
Here is a proposal that we believe strikes a reasonable compromise, chosen as a moderate sampling of the ideas posted on Wikipedia:SOPA initiative:
- Triggering event: When SOPA has passed committee and is scheduled for a floor vote in either the House or Senate. The banner runs for the week before the vote, and switches to the blackout on the day before.
- Scope: Response is geotargeted to United States IP addresses only
- Duration: Maximum of 7 days for banner component, maximum of 24 hours for blackout component. Blackout is triggered on the business day before the vote. If the vote is on a Monday, blackout runs for 24 hours starting Friday.
- Action (banner): Banners encourage people to contact their Senators and Representatives (priority given to whichever is urgent, House or Senate).
- To the maximum extent possible, readers are given instant information on how they can take action. Campaign is designed to mobilize the public maximally.
- The focus is on generating high-value congressional contacts (phone calls and in-person contacts vs letters or emails)
- A VOIP-based callback system (such as the one used recently by tumblr) is an option if we can find one that fits our needs and allows us to remain acceptably independent.
- Banners operate like the fundraising banners (served via CentralNotice, can be closed per-user, etc).
- Action (blackout): All requests are answered with a black page. The page is semi-protected Wikitext. Once the page is displayed, a cookie is set which prevents its display again. Exact wording to be decided, but it hits the following points:
- SOPA puts Wikipedia, and the rest of the free Internet, at risk
- You can help by contacting your representative and senators (with maximally easy help with ways to do that)
- A "Learn more about SOPA" link which points to the relevant article on the English Wikipedia
- A "Why am I seeing this" link which points to a page detailing the process for reaching this consensus
- A link to click through to the originally requested page
- "You will only see this page once"
This gets the message across clearly, explains how to help, is targeted to people who have the ability to effect change, shows that the protest was a community decision, and doesn't reduce the utility of Wikipedia for readers.
To set this proposal in the context of similar actions in the past, see this summary.
Need
While most of us understand the power that Wikipedia has in this situation and the size of our audience, some are still skeptical that a citizen response can change the course of this legislation. Rep. Zoe Lofgren, member of the House Judiciary Committee addressed this concern on Reddit:
My best assessment is that most members of the House who do not serve on the Judiciary Committee have not yet focused on SOPA. People should realize that incredible power they have to impact the thinking of their own Representative on the subject. For example, a very intelligent colleague who is not on the Committee approached me today asking about the bill. Why? He had received an urgent and forthright telephone call from a small business person in his district who is tremendously opposed. He wanted to know more about our Open Act Alternative. This is the power that each of you have with your own Representative. --Rep. Zoe Lofgren
Critique
The most common critique of this proposal is that it controverts NPOV (the spirit, not the letter which specifically regards article content). This came up often in response to previous proposals, so it's worth addressing directly. We'll try to re-state the objection and respond:
Objection: Presenting unbiased information is one of Wikipedia's most important values. This sort of action demonstrates a clear bias, undermines our integrity, and sets a dangerous precedent with regard to the possibility of future actions.
The encyclopedia should be neutral. Nobody is suggesting that we make biased pages to wreck the careers of politicians who vote the wrong way, or that our page on SOPA itself should be biased. "NPOV is non-negotiable."
However, the project space need not be NPOV, the Foundation need not be NPOV, the community need not be NPOV. There are very good reasons to avoid general political activism that might split the community or cause drama, but that's more about practicality than principles. There are also very good reasons to embrace political activism when the core policies that make the Internet successful are threatened, and when that activism can actually draw our otherwise diverse community into a sense of unity around a cause that we can nearly all support by the nature of being Wikipedians. Such an event is so rare and extraordinary that we can't imagine this sort of protest becoming common practice.
SOPA threatens the very same values that the many well-meaning editors making this argument seek to protect. User:Neilk articulated this in a comment on a previous proposal:
I believe that NPOV is a reason to take a public stance. This proposed law would ensure that some points of view are not represented on Wikipedia. It would be as if the government were removing information from Wikipedia, and then threatening jail time for anyone who dared to revert. It is appropriate for Wikipedia to take a stance on issues that directly threaten our project and our values.
We agree that there is value in staying out of political discussion. It's important that the world perceive Wikipedia to be neutral, and distinctions between content and community are often lost on the uninvolved public. Ultimately, the question we're asking is this: is the potential for harm to Wikipedia's reputation worth enduring to oppose legislation that could threaten its very existence, and undo years of work in creating a free and open Internet? We believe it is.
Personal statements from proposal authors
Ian Baker: While I work for WMF as a developer, this proposal is made by myself as an individual. I am aware that the Foundation officially opposes SOPA, but am in no way representing the Foundation when I write this. I care about Wikipedia deeply, and am therefore very concerned about this bill's imminent passage. raindrift (talk) 00:09, 19 December 2011 (UTC)
Jimbo Wales: I have sought to assist Ian in trying to make this proposal mild and widely acceptable. We do not have a lot of time for debate, as markup is set to begin again on December 21st and this could still make it to the floor of the House quite quickly.--Jimbo Wales (talk) 12:28, 17 December 2011 (UTC)
The above comment signed by Jimbo, was not added here by Jimbo. fredgandt 00:20, 19 December 2011 (UTC)
- Sorry about that. It's from this userspace draft raindrift (talk) 01:10, 19 December 2011 (UTC)
Discussion
- I support this proposal, but I believe that a full-scale, international blackout (à la the Italian Wikipedia) would be more effective.
SOPA stands to affect readers around the world (not merely those in the United States). During the Italian Wikipedia's strike, users in various countries contacted ambassadors of Italy to express their concerns. It would be helpful if the same were to occur with ambassadors of the United States.
I also worry that a one-off message (with the ability to click through to the desired article) would be treated as little more than a nag screen (dismissed and forgotten). As upsetting as it is to deprive readers of the encyclopedia, that might be the only way to get their attention and prompt them to take action. —David Levy 00:45, 19 December 2011 (UTC) - Purely technical issues/concerns Some readers may not have cookies enabled. Session id? Could this cause accessibility problems for some users? fredgandt 00:53, 19 December 2011 (UTC)
- If cookies are disabled, the user will see the blackout page once for each article they visit. --Carnildo (talk) 01:37, 19 December 2011 (UTC)
- Could be done with both a cookie and a session id. Session id would ensure it only comes up once per visit where cookies are disabled. Cookie could ensure it only comes up once at all. So someone with cookies disabled will see it everytime they close their browser and then come back to Wikipedia but not on every article.--v/r - TP 16:33, 20 December 2011 (UTC)
- If cookies are disabled, the user will see the blackout page once for each article they visit. --Carnildo (talk) 01:37, 19 December 2011 (UTC)
- Against First, quite likely several US presidential candidates (to candidates) have different views on this subject. Which candidate(s) will WP support? Second, I do not know anything about SOPA in particular, but I strongly believe that defending intellectual property is extremely important (unless we want to descend into a dark age of search and copy, as creating does not pay for your food and bed) This is highly ridiculous, this is - I thought - a encyclopaedia, not a political platform. - Nabla (talk) 00:55, 19 December 2011 (UTC)
- You acknowledge that you "do not know anything about SOPA in particular". If you were familiar with the bill, perhaps you'd understand why opposing it isn't remotely the same as opposing the defense of intellectual property (just as opposing the USA PATRIOT Act isn't tantamount to supporting terrorism).
Indeed, Wikipedia is an encyclopedia — one based on specific principles. If a politician happens to disagree with said principles, that can't be avoided. —David Levy 01:20, 19 December 2011 (UTC)- I take the criticism - of not knowing - as fair and took a look at our article. Actually I have already seen it sometime. Overall it looks fine. Sites facilitating copyright infringement should be stopped. It supports my guess that this is "the internet at large" being against copyright. That includes WP. WP - as a community, not every member - show little respect for copyright. I once uploaded a few photos, the copyright tags I placed on them were changed several times by some random users a couple times or so. WP also leaves up to community discussion several legal matters (like fair use for images) while we are no court at all. WP has no moral authority at all to protest. Joking a little, this is like a bank robber opposing a law against robbing banks. But all that is my opinion about copyright and its (poor) implementation at WP, subject for a nice calm, or heated, internal discussion. This discussion here is about WP direct and intentional interference in USA politics. First, that is completely against WP purpose, as I see it; Second, the WMF may natuirally do turn WP into a political platform, as they may, and probably have the right to. Me, I am against. - Nabla (talk) 02:01, 19 December 2011 (UTC)
- Thanks for clarifying your position. I was unaware of your bias. —David Levy 02:15, 19 December 2011 (UTC)
- Bias?!, prejudice, lack of objectivity? Where do your opinions come from? Out of thin air? Because someone told you? You born with them implanted in your brain? They come out of your pure and kind heart? Or are they born out of your life experiences, just like mine? Your life experiences are good reasons, mine are «bias»? Campaign as much as you want, but cut the crap, do'n play all saintly, and do not insult others's opinions. - Nabla (talk) 02:00, 20 December 2011 (UTC)
- Thanks for clarifying your position. I was unaware of your bias. —David Levy 02:15, 19 December 2011 (UTC)
- I take the criticism - of not knowing - as fair and took a look at our article. Actually I have already seen it sometime. Overall it looks fine. Sites facilitating copyright infringement should be stopped. It supports my guess that this is "the internet at large" being against copyright. That includes WP. WP - as a community, not every member - show little respect for copyright. I once uploaded a few photos, the copyright tags I placed on them were changed several times by some random users a couple times or so. WP also leaves up to community discussion several legal matters (like fair use for images) while we are no court at all. WP has no moral authority at all to protest. Joking a little, this is like a bank robber opposing a law against robbing banks. But all that is my opinion about copyright and its (poor) implementation at WP, subject for a nice calm, or heated, internal discussion. This discussion here is about WP direct and intentional interference in USA politics. First, that is completely against WP purpose, as I see it; Second, the WMF may natuirally do turn WP into a political platform, as they may, and probably have the right to. Me, I am against. - Nabla (talk) 02:01, 19 December 2011 (UTC)
- You acknowledge that you "do not know anything about SOPA in particular". If you were familiar with the bill, perhaps you'd understand why opposing it isn't remotely the same as opposing the defense of intellectual property (just as opposing the USA PATRIOT Act isn't tantamount to supporting terrorism).
- Oppose Is this not what could be fairly called "a perennial proposal"? It has been knocked back twice already. How many more times do we have to go through this? I emailed Jimbo stating my concerns regarding the hypocrisy of this proposal. It went something like this: For Wikipedia to state loudly that it is against proposed laws that are (from most peoples perspectives) designed to protect copyrights, will be a media nightmare. Who honestly thinks the media at large will stand shoulder to shoulder with us, and sing our praises for doing the right thing? They sell dung; and the stinkier the better. This is delivering it to them in truck loads. Wave buh-bye to our reputation folks! fredgandt 01:24, 19 December 2011 (UTC)
- Firstly, you're referring to two very different proposals, both of which failed for reasons irrelevant to this one. The original RfC (which focused on the general idea instead of specific implementations highly unlike the one proposed above) generated broad support.
Secondly, you seem to suggest that we should worry more about PR than about defending principles that enable Wikipedia's existence. Obviously, I disagree. —David Levy 01:44, 19 December 2011 (UTC)- Irrelevant'? Excuse me for looking bemused O.o. PR matters. If the aim of this proposed fiasco is to protect Wikipedia, consider the harm it might do. This is surgery with a rusty spoon. There are better ways. fredgandt 01:51, 19 December 2011 (UTC)
- 1. Yes, irrelevant. Those proposals failed because they entailed rushing into implementations substantially different from the one proposed above. The general idea received broad support.
2. I didn't say that PR doesn't matter. However, it will cease to matter if Wikipedia fades into history.
Also note that the Italian Wikipedia engaged in a significantly more extreme variant of this protest with positive results.
You say that "there are better ways." What do you suggest? —David Levy 02:15, 19 December 2011 (UTC)- Not responding to the end of the world posturing.
I suggested to Jimbo by email that he use his own clout to raise awareness without dragging Wikipedia through the shit in the process. How ever many readers Wikipedia has each day, it will be nothing compared with the numbers that read the papers and watch the telly. He, without the backing of WMF could easily get any audience he chose, and no one could deny him the right to claim the limelight as creator of Wikipedia (although many try). This is now for certain my last comment on this thread (my last was but I was asked a direct question). Not being dramatic, just said my bit and moving on. fredgandt 03:09, 19 December 2011 (UTC)- I don't believe (and I don't think that Jimbo believes) that he commands such power and influence. He's well known, of course, and he is doing his best to raise awareness of the issue. —David Levy 03:35, 19 December 2011 (UTC)
- Not responding to the end of the world posturing.
- 1. Yes, irrelevant. Those proposals failed because they entailed rushing into implementations substantially different from the one proposed above. The general idea received broad support.
- Irrelevant'? Excuse me for looking bemused O.o. PR matters. If the aim of this proposed fiasco is to protect Wikipedia, consider the harm it might do. This is surgery with a rusty spoon. There are better ways. fredgandt 01:51, 19 December 2011 (UTC)
- Firstly, you're referring to two very different proposals, both of which failed for reasons irrelevant to this one. The original RfC (which focused on the general idea instead of specific implementations highly unlike the one proposed above) generated broad support.
- Support but go further. Blackout all articles about movies made by MPAA members, with no possibility of viewing the article for the 24 hours. Jc3s5h (talk) 01:38, 19 December 2011 (UTC)
- Yeah and then permanently blackout all pages to do with Nazis and terrorists and child abusers and rapists and cheese and frogs... fredgandt 01:41, 19 December 2011 (UTC)
- But I like cheese. --Hobbes Goodyear (talk) 01:59, 19 December 2011 (UTC)
- Support: action could well go further into economic restraints on the utility of Wikipedia to the supporters and groups lobbying in favour of this bill. As an immediate proposal this is worth supporting and putting in place. Fifelfoo (talk) 03:05, 19 December 2011 (UTC)
- Support: Including internationally as described by David Levy at the top. Mark Hurd (talk) 07:20, 19 December 2011 (UTC)
- For the third time, support, though I'm concerned the proposal is not bold enough. A full, almost immediate, complete blackout is in order if we are to generate serious and significant media attention, which is basically the only thing politicians care about. But then that's only my view. I support WMF action against SOPA, though only if not associated with political organizations (e.g. those also associated with other causes than SOPA). CharlieEchoTango (contact) 07:27, 19 December 2011 (UTC)
- One attempt to workshop a stronger proposal exists at Wikipedia:SOPA initiative#Concrete proposal 1 Fifelfoo (talk) 07:36, 19 December 2011 (UTC)
- Strong oppose - Wikipedia should not appear to have political bias. An optimist on the run! 08:19, 19 December 2011 (UTC)
- Support, as Wikipedia is concerned with free access to the web. Thus it's a part of Wikipedia's mission to react on such events. The political bias issues are irrelevant here, as no politics concerned. — Dmitrij D. Czarkoff (talk) 09:25, 19 December 2011 (UTC)
- Strong Oppose - By carrying out these actions Wikipedia will sacrifice its perceived neutrality and the protecttion that it gives. Lose that neutrality and it will be much easier for companies (or people with an agenda) to take legal action as the FIRST step without the bad PR that would create now.Even worse are some of the suggestions above that want to censor Wikipedia - I mean "Blackout all articles about movies made by MPAA members, with no possibility of viewing the article for the 24 hours" and "action could well go further into economic restraints on the utility of Wikipedia to the supporters and groups lobbying in favour of this bill Then goodbye Wikipedia. That is just asking for Wikipedia to be sued or shut downNigel Ish (talk) 11:26, 19 December 2011 (UTC)
- Oppose. As I wrote previously, it is inappropriate for the community to compel any user to edit or not edit to make a political point. It would also set a truly awful precedent, with unknowable consequences. If some threshold of consensus is all it takes to turn Wikipedia into an instrument of politics, then Bill O'Reilly can take over the encyclopedia if 1% of his three million nightly viewers respond to a call to register accounts. Even if nothing like that happened, Wikipedia would be permanently politicized. Every time a controversial piece of media legislation got introduced, it would be "How will Wikipedia respond?" all over the news. Nigel Ish also highlights some upsetting avenues this could open toward liability. And as Nabla says, how far does this go? If it becomes an issue in the U.S. presidential campaign, which candidate do we endorse? Lagrange613 17:50, 19 December 2011 (UTC)
- Strong support - Having read the bill and numerous informed analyses of it, I believe that SOPA threatens the very existence of Wikipedia. This requires decisive action, and requires it urgently. It makes little sense for Wikipedia to refrain from action in order to uphold our apolitical ideals when so doing may well result in the elimination of the site itself. This is an extremely poorly-conceived and constructed piece of legislation, and it demands an unequivocal response. This is not a slippery slope. The Wikipedia community has historically shown great restraint against taking indiscriminate political action, and will continue to do so in the future, regardless of what decision is made here. The is no equivalency between an awareness-raising action regarding a bill that would necessitate universal censorship of Wikipedia and, say, the endorsement of a political candidate. To propose such is an insult to the intelligence and discretion of this community.
- Of the three SOPA-related action proposals thus far put forth, this is by far the best-articulated, and most immediately practicable one. It is respectful of the community, addresses all major the previously-raised objections, and is compatible with NPOV. It also—and I consider this crucial—includes a strong emphasis on creating high-value action on the part of the Wikipedia community and readership. The Tumblr auto-calling system mentioned in the proposal was a massive success, without which SOPA might have sailed through without the scrutiny that it is now receiving, and which it so needed. Without the tumblr action, our community might not even have the opportunity that we now have to draw further attention to this deeply-flawed legislation.AaronMuszalski (talk) 19:19, 19 December 2011 (UTC) — AaronMuszalski (talk • contribs) has made few or no other edits outside this topic.
- Strong oppose. As I have said, the statute as presently drafted is inapplicable to Wikipedia. End of story.--Wehwalt (talk) 20:17, 19 December 2011 (UTC)
- The Wikimedia Foundation's general counsel has advised the community that SOPA does pose dangers to Wikipedia. While the latest version exempts American organizations from some sanctions (such as cutting off payment processing), the WMF could still be subject to court orders to review every outgoing link from Wikipedia and to block certain domains. I find it hard to imagine a more direct attack on the freedom of the Wikipedia community. Do you have another legal opinion to cite? NeilK (talk) 02:54, 20 December 2011 (UTC)
- Support - I support this because while not being consistent with NPV, SOPA endangers the very idea of open internet sites like wikipedia Cat Cubed (talk) 20:26, 19 December 2011 (UTC)
- Support SOPA will effect the very nature of the internet --Guerillero | My Talk 20:55, 19 December 2011 (UTC)
- Support - I'm not fully understanding arguments against this action due to Wikipedia's perceived neutrality - Wikipedia is indeed not neutral in this situation and needn't behave as such. With lawmakers making comments such as "this worked in China" we, of all those on the web, should certainly be supporting any action that could help prevent this bill from going through in its current state. This is an effective option; take advantage of the opportunity to make an impact. LoriLee (talk) 21:37, 19 December 2011 (UTC)
- Strong support – I've previously opposed taking site-wide action since I had believed that Jimbo's voice in the media alone would be enough. Unfortunately, I don't believe that to be the case any longer. As a result of witnessing the rejection of so many amendments on December 16th, I believe that a stronger message from the WMF and the enwiki community is needed in order to spread awareness of this bill. --Michaeldsuarez (talk) 21:53, 19 December 2011 (UTC)
- Strong support - SOPA poses a direct threat to what Wikipedia stands for. As Vint Cerf wrote in a letter to Lamar Smith, SOPA opens the door to "unprecedented censorship" of the web. When statements like this - including an appeal from 83 of the internet's founders about the dangers of SOPA - fall on deaf ears within Congress, it's time to act. Wikipedia has the power to reach thousands of people, and that kind of power should not be taken lightly or used carelessly. The situation is dire, but there may be hope if Wikipedia contributes to the awareness effort. As representative Zoe Lofgren pointed out, people have a tremendous power to influence legislation, as illustrated by the story of one of her colleagues rethinking his position on SOPA after a phone call from a small business owner in his district. If more representatives hear from their constituents about how counterproductive and dangerous this bill is, maybe the tide will turn. This is a crucial moment in the Internet's history, and I think that Wikipedia should take a stand, because SOPA undermines every value that this community is built on. The neutrality that people are so protective of in this discussion can only thrive in an open internet. The sum of all human knowledge will not thrive in the balkanized internet that will result from SOPA being passed.Nadya lev (talk) 22:01, 19 December 2011 (UTC) This template must be substituted.
- Oppose as POV and a distraction by "movement groupies" over content creators. We should not restrict content to make a political point (to support or oppose a law). Similar to not censoring. This is censoring the entire site. I'm also concerned that this seems to appeal to people that would rather found a movement than write content. Wales and Gardner should worry about content problems we have (10 years into this thing). This is a distraction. It takes us further down the road of losing the best writers and retaining people that want to use the blank slate as part of some meta-battle. (And if you don't like it or think I'm not AGFing or shouldn't impute motives, tough titties. I would look anyone on this site in the eye and say what I beleive.)TCO (talk) 22:11, 19 December 2011 (UTC)
- If you're calling Jimbo a movement groupie, I'm not sure who you would consider a "real" Wikipedian. Jimbo continues to contribute to articles to this day. Furthermore you are proposing a false dichotomy, that we can only care about content quality or legal threats to the existence of Wikipedia. We can do both. NeilK (talk) 02:38, 20 December 2011 (UTC)
- Weak support for a weak proposal. Every media report will make reference to the fact that we considered a blackout but bottled it. --FormerIP (talk) 22:15, 19 December 2011 (UTC)
- Support I'd actually prefer a stronger action more like what the Italian Wikipedia did, but I can get behind this proposal. NeilK (talk) 02:58, 20 December 2011 (UTC)
- Also, I have a couple of questions. I can understand those who think this kind of protest is inappropriate, and would prefer something different. What I don't get are those who object to taking any sort of action. According to the WMF's general counsel, this is a serious threat to Wikipedia's independence (and if you disagree, please show us a different legal opinion). So are you arguing that it's more important to avoid any hint of POV -- even about issues of state censorship? Personally, when I look back on this episode in 10 years, I'm not sure I am going to feel good about concluding "well, we may have let Wikipedia become a collaborator with government and industry to keep people ignorant about certain things. But I'm glad that at least we never pushed any POV on our users with a banner ad or anything...." NeilK (talk) 03:20, 20 December 2011 (UTC)
- It's important to avoid any hint of POV even about issues of fill in the blank. Otherwise it will be "Wikipedia condemns anti-copyvio measures but not child pornography or AIDS denialism or overzealous gun control or spending time on copyright on the Internet instead of unemployment" or whatever bête noire you choose. We can't pick favorites with political causes, or do-gooders will be knocking down our door asking us to pick them. I reject collaboration with either side of this debate. We're an encyclopedia, so informing readers is part of our mission; we just can't inject the political views of the majority* of editors into that process. (*Really the majority of the minority that participates at this board.) By all means draw attention to the debate around SOPA, but do it within the bounds we set for ourselves: work the article up to FA and make it TFA around some appropriate moment, like one house or the other voting on it. Lagrange613 06:29, 20 December 2011 (UTC)
- Wikipedia, by its very existence, aligns itself with a POV contrary to SOPA's intent. You might as well argue that our "pro-free content" POV is inappropriate. —David Levy 06:39, 20 December 2011 (UTC)
- I disagree. Wikipedia is free content is one of the five pillars; Wikipedia provides links to copyright-infringing websites is not. SOPA would not outlaw free content. Lagrange613 07:04, 20 December 2011 (UTC)
- This isn't about a desire to provide links to copyright-infringing websites. Do you honestly not realize that? —David Levy 08:17, 20 December 2011 (UTC)
- "SOPA would not outlaw free content". Sure, but it'd give anyone a weapon to cause untold quantities of harm regardless. Someone with powerful lawyers gets pissy about the fact that we legitimately use their non-free logo under fair use, or perhaps that we disagree with them on Bridgeman v. Corel, the lawyers start making a ruckus and then god knows what happens. Or think of the child porn stuff a few years ago: it would have only taken one or two rogue prosecutors to go after Wikipedia: this is what you get when you detach intellectual property enforcement from due process. Wikipedians try very hard to keep the site free of copyvios and we still fail, and will continue to fail. SOPA is a gun pointed at our head and the trigger could go off at any minute. —Tom Morris (talk) 09:17, 20 December 2011 (UTC)
- My point was only that Wikipedia does not "align itself with a POV contrary to SOPA's intent." Tom Morris correctly identifies the stakes here as risk to the project, not some deep contradiction with Our Precious Values. And taking a public political stance like this is very risky indeed, for reasons opponents continue to spell out. Lagrange613 15:51, 20 December 2011 (UTC)
- 1. Wikipedia aligns itself with the POV that the online dissemination of free information should be unencumbered. SOPA threatens to make it too onerous for Wikipedia, let alone downstream users, to handle.
2. Has the Italian Wikipedia's protest — a significantly more extreme variant — resulted in adverse political consequences for Wikipedia or the Wikimedia Foundation? —David Levy 16:15, 20 December 2011 (UTC)- I guess I don't see Wikipedia aligning itself with any POV, because I don't see myself as part of a political movement. I understand that some people feel that way, but I don't think it's appropriate for them to impose their vision on the rest of the editing (and reading) community. I guess that makes me one of TCO's "content writers", though we're mostly a soft-spoken lot. I don't know much about the Italian Wikipedia's protest, but I do think it's a little early to evaluate all of its effects. In any case the English Wikipedia is so much more visible that I doubt the value of the comparison. Lagrange613 22:10, 20 December 2011 (UTC)
- Wikipedia is part of the free culture movement. When politicians threaten to harm said movement via onerous legislation, the lines between "social movement" and "political movement" are blurred.
The Italian Wikipedia is the fifth-largest. Its protest (which was worldwide, blocked article access with no option of clicking through, and had no predetermined duration) generated massive media coverage in Italy (the country considering the problematic legislation) and a substantial amount internationally. I've seen no evidence that the Italian Wikipedia's reputation (or that of the Wikimedia Foundation, which endorsed the protest) has been damaged. Many Wikimedians (myself included) initially expressed concerns similar to those discussed here, but the general public found fault with Italian parliament (and reacted accordingly). That protest's success inspired this proposal. —David Levy 00:14, 21 December 2011 (UTC)- Wikipedia is emphatically not part of any movement, social or political. It is an encyclopedia that anyone can edit regardless of membership in any movement, social or political. Individual contributors may feel they belong to a movement and that editing Wikipedia is part of their participation in that movement. Which is fine as long as they don't use Wikipedia as a soapbox. Lagrange613 01:29, 21 December 2011 (UTC)
- Wikipedia is part of the free culture movement. When politicians threaten to harm said movement via onerous legislation, the lines between "social movement" and "political movement" are blurred.
- I guess I don't see Wikipedia aligning itself with any POV, because I don't see myself as part of a political movement. I understand that some people feel that way, but I don't think it's appropriate for them to impose their vision on the rest of the editing (and reading) community. I guess that makes me one of TCO's "content writers", though we're mostly a soft-spoken lot. I don't know much about the Italian Wikipedia's protest, but I do think it's a little early to evaluate all of its effects. In any case the English Wikipedia is so much more visible that I doubt the value of the comparison. Lagrange613 22:10, 20 December 2011 (UTC)
- 1. Wikipedia aligns itself with the POV that the online dissemination of free information should be unencumbered. SOPA threatens to make it too onerous for Wikipedia, let alone downstream users, to handle.
- My point was only that Wikipedia does not "align itself with a POV contrary to SOPA's intent." Tom Morris correctly identifies the stakes here as risk to the project, not some deep contradiction with Our Precious Values. And taking a public political stance like this is very risky indeed, for reasons opponents continue to spell out. Lagrange613 15:51, 20 December 2011 (UTC)
- "SOPA would not outlaw free content"? The proposal keeps changing, but some versions would not outlaw free content, but would change who decides if complaints are valid from a court, which is obliged to be fair and neutral, to the ISP of the person or organization who puts up the disputed content. Of course, the primary interest of the ISP is minimising the amount of staff time devoted to content issues, and the quickest way to resolve issues is to cancel the account of the accused subscriber. So some incarnations of SOPA don't outlaw free content, but do deny due process of law to possibly free content. Jc3s5h (talk) 16:25, 20 December 2011 (UTC)
- I disagree. Wikipedia is free content is one of the five pillars; Wikipedia provides links to copyright-infringing websites is not. SOPA would not outlaw free content. Lagrange613 07:04, 20 December 2011 (UTC)
- Well, are you saying that there's nothing wrong with this action, but that it will lead inevitably to Wikipedians being dragged into other issues? I think there's no risk of that. First of all, SOPA is very clearly targeted at sites like us. Its entire intent is to affect internet entities where content is contributed by users, which were formerly shielded by the DMCA. We are not becoming exercised over this bill by accident. I think the Wikipedia community is smart enough to figure out when we must speak out and when we should be silent. If not, we can get legal advice from the WMF or others, and we can do what we're doing now -- talk it out. There's no slippery slope here. Nothing about this action commits us to other, future, unrelated actions. NeilK (talk) 18:31, 20 December 2011 (UTC)
- I'm less worried about getting dragged into future issues (though that is a concern) than I am about changes to our image. At the moment people read us as an encyclopedia, and this will lead to people reading us as an encyclopedia that crusades for one political POV at the expense of another. If we're pigeonholed like that it may be harder to attract new users, which is becoming more and more urgent. Lagrange613 22:10, 20 December 2011 (UTC)
- Wikipedia, by its very existence, aligns itself with a POV contrary to SOPA's intent. You might as well argue that our "pro-free content" POV is inappropriate. —David Levy 06:39, 20 December 2011 (UTC)
- It's important to avoid any hint of POV even about issues of fill in the blank. Otherwise it will be "Wikipedia condemns anti-copyvio measures but not child pornography or AIDS denialism or overzealous gun control or spending time on copyright on the Internet instead of unemployment" or whatever bête noire you choose. We can't pick favorites with political causes, or do-gooders will be knocking down our door asking us to pick them. I reject collaboration with either side of this debate. We're an encyclopedia, so informing readers is part of our mission; we just can't inject the political views of the majority* of editors into that process. (*Really the majority of the minority that participates at this board.) By all means draw attention to the debate around SOPA, but do it within the bounds we set for ourselves: work the article up to FA and make it TFA around some appropriate moment, like one house or the other voting on it. Lagrange613 06:29, 20 December 2011 (UTC)
- Also, I have a couple of questions. I can understand those who think this kind of protest is inappropriate, and would prefer something different. What I don't get are those who object to taking any sort of action. According to the WMF's general counsel, this is a serious threat to Wikipedia's independence (and if you disagree, please show us a different legal opinion). So are you arguing that it's more important to avoid any hint of POV -- even about issues of state censorship? Personally, when I look back on this episode in 10 years, I'm not sure I am going to feel good about concluding "well, we may have let Wikipedia become a collaborator with government and industry to keep people ignorant about certain things. But I'm glad that at least we never pushed any POV on our users with a banner ad or anything...." NeilK (talk) 03:20, 20 December 2011 (UTC)
- Strong support for action. I'm flexible on which proposal. Just like the DMCA, this law operates based on allegations. It operates in the absence of an actual court determination of infringement. The law requires Wikipedia to censor targeted sites, even when any allegation of infringement is clearly false. Even if a site actually contains nothing but Public Domain material. Even more significantly, I think it's wrong to say that Wikipedia itself actually is safe from being taken down or de-funded under this law. Wikipedia's supposed safety is conditional upon Wikipedia being confined within US borders. Imagine for a moment a law which explicitly prohibited Wikipedia from ever moving outside the US, prohibited us from ever utilizing any systems outside the US. Is there anyone here who would tolerate any such thing? It is impossible for anyone to assert or accept that Wikipedia actually is safe from the most catastrophic portions of this law, not unless you first imply and accept the radical position of forever prohibiting Wikipedia from moving or using any system outside the US. Alsee (talk) 06:05, 20 December 2011 (UTC)
- Wikipedia's Alexa rank is 6. Any bill about the Internet has the potential to harm (or benefit) Wikipedia. Where do we draw the line? Lagrange613 06:29, 20 December 2011 (UTC)
- The difficulty of knowing where to draw the line does not mean that we shouldn't draw the line. If you want a clear test, here's one: if a law forbids content that the community has come to a consensus on as being valuable to include in Wikipedia, we should oppose that law. Seems like a no-brainer to me. And I know that includes a lot of things like freedom of panorama or laws against Nazi imagery in Germany, and I'm not advocating that we protest those things as strenuously. But another issue is, when should we take action that interrupts the average reader's experience on the encyclopedia? I think that is a judgment call, and we'll have to talk it out every time, as we are doing now. The point is I don't think you can argue for no action merely by saying that it's hard to know when action is required. NeilK (talk) 18:43, 20 December 2011 (UTC)
- Wikipedia's Alexa rank is 6. Any bill about the Internet has the potential to harm (or benefit) Wikipedia. Where do we draw the line? Lagrange613 06:29, 20 December 2011 (UTC)
- Support I am an European, but I believe that any similar law aimed directly against the freedoms of people merit similar response. Wikipedia is global project and as such it should defend itself on a global level no matter government of which country is attempting to propose change which could affect it. Petrb (talk) 09:09, 20 December 2011 (UTC)
- Support When bad laws threaten the survival of Wikipedia, we must make a stand. The argument that it is a violation of WP:NPOV doesn't hold up because our very existence isn't a matter of neutrality. We prefer free content to non-free content, we prefer open source to closed, we prefer free access to closed access: the very parameters of the project aren't neutral, and rare, extraordinary action to protest dumb laws that threaten the survival of Wikipedia and the free Internet generally is a price we occasionally have to pay. —Tom Morris (talk) 09:22, 20 December 2011 (UTC)
- Support Wikipedia needs to inform readers that free access to information is being placed in jeopardy. The comments above about Wikipedia's neutrality misunderstand the situation: the best advice currently available indicates that the bill presents a unique threat to Wikipedia's continued operation (see link in proposal). It would be irresponsible to fail to inform readers of that unique threat. Johnuniq (talk) 10:51, 20 December 2011 (UTC)
- Strong support per my comments on Jimbo's talk page and elsewhere.--v/r - TP 16:33, 20 December 2011 (UTC)
- Neutral if it remains targetted at US IPs only, oppose if it's expanded to include non US IPs. Having read our lawyers response and some follow up comment, the actual extent of any threat to wikipedia seems to remain fairly unclear. Therefore, I remain opposed to any action involving non US IPs, particularly since the ability of non Americans to directly influence the bill is limited anyway. As also per my earlier comments, I'll let those from the US decide what they wish to do about it themselves. Nil Einne (talk) 20:46, 20 December 2011 (UTC)
- Support: I preferred the tools-down global blackout (as several countries follow the US example and might try restrictive laws of their own, and action should be taken there too), but any action is good action. Sceptre (talk) 02:55, 21 December 2011 (UTC)
- Did Google pay us to shut down Wiki? Just wondering. Supposedly we are discouraging large individual grants (to not be beholden). But then we just got a half million from the founder of Google. And he has given us a LOT over the years too. And he has billions tied up in Youtube and Google and all. When we read the Wiki counsel's advice, we find out that Wiki itself is not under much danger. But Google has a lot of problems. And they are a ginormous, for profit, entity. So...just wondering on the timing of that last grant. 03:12, 21 December 2011 (UTC)
Committee meets on Wednesday
Could we at least send some letter to the committee by Wednesday (when they reconvene!), asking for them to at least carve an exception for WP? It'd kind of suck to have to move the servers to Iceland next year, if we could have just politely asked right now. :-P --Kim Bruning (talk) 22:23, 19 December 2011 (UTC)
- Due to limited amount of time we have, if we pursue the open letter course, I would recommend the follow:
- Have Jimbo Wales or another member of the WMF craft an open letter to the Committee. The letter should be hosted on the web.
- Use Twitter to inform Committee members about the open letter.
- Convince a Congressperson (via Twitter) to mention Wikipedia and its concerns during the markup session.
- --Michaeldsuarez (talk) 22:59, 19 December 2011 (UTC)
- How would that work? If it's actually specific to WP, that wipes out our ability to fork, which would do away with Wikipedia being a "free encyclopedia", which is kind of important... --Yair rand (talk) 04:36, 20 December 2011 (UTC)
Reflist should be shown when previewing a section edit
When previewing a section, a presentation of a reflist should show beneath the preview, containing all references (as they would normally be displayed) from the section being edited. fredgandt 02:32, 19 December 2011 (UTC)
- Agreed. I would find it pretty useful, as it's time consuming to manually add a reflist to the section, preview, then remove the reflist before saving. CharlieEchoTango (contact) 07:04, 19 December 2011 (UTC)
- (ec)Great idea. I often manually add one my self and occasionally forget to remove it before saving... Mark Hurd (talk) 07:06, 19 December 2011 (UTC)
- Support. Would make adding refs to long articles so much easier. Can't see any downside, other than the opportunity cost of diverting WP programmers from other worthy projects. --Hobbes Goodyear (talk) 07:15, 19 December 2011 (UTC)
- Comment Note that you would have major issues with references defined elsewhere in the page and just referenced from your section (including all uses of WP:LDR). Anomie⚔ 12:21, 19 December 2011 (UTC)
- Could that be prohibitively major? Is the tech too tetchy? fredgandt 12:24, 19 December 2011 (UTC)
- Comment According to Help:Footnotes#Previewing edits you can work round this by using wikEd. -- John of Reading (talk) 12:46, 19 December 2011 (UTC)
- Seeing as that's a gadget, I would assume this can die peacefully. Right? fredgandt 12:49, 19 December 2011 (UTC)
- comment I'd recommend using user:js/ajaxPreview which does display the references. It's faster than regular preview, for me. Anomie is correct that there would be (and is with this method) a problem with elsewhere-defined refs, which are very common. sonia♫ 01:33, 21 December 2011 (UTC)
Interwiki and domain redirects via URL
Alright, this may sound silly, and may possibly be more appropriate on meta, but I don't use meta, so I'm asking here. I generally use the URL to navigate between wikis, for example if I'm looking at someone's Special:Contributions, I just have to change en.
to fr.
, and there I am. And then, if I need to go to commons.
, I don't need to change .wikipedia.org
, the software automatically translates it to .wikimedia.org
. My "problem" is that it doesn't do the opposite translation. So if I come from the French Wikipedia, e.g. Discussion utilisateur:
, I'm not redirected to User talk:
when I change fr.
to en.
, nor is wikimedia.org
redirected to wikipedia.org
once one changes the prefix. I propose that domain and subdomain redirects be established for all languages, at least to and from (from is already done) .en
for interlanguage, and from .wikimedia.org
to .wikipedia.org
when going from meta or commons to a wikipedia (the opposite is already done). This could also apply for other types of wiki though I'm not familiar with them. Thoughts? P.S. I'm technically incompetent, sorry if there is something preventing this in the software or some kind of technical conflict that I'm not aware of. Regards CharlieEchoTango (contact) 07:01, 19 December 2011 (UTC)
- This sounds similar to something proposed on the wikitech-l mailing list recently. Anomie⚔ 12:24, 19 December 2011 (UTC)
- Good to know, thanks! Was there any follow-up on the proposal? CharlieEchoTango (contact) 03:10, 20 December 2011 (UTC)
Watch the threads (as opposed to watch the whole page)
I would propose a feature for a Wikipedia: namespace to watch only specific threads. On big pages like this one or noticeboards the editor can be interested in a particular thread, but watching it becomes more difficult when there are many threads and some of them are buzzy. — Dmitrij D. Czarkoff (talk) 09:29, 19 December 2011 (UTC)
- Support with opt-in or opt-out: this would be useful as suggested in a thread above as well. --lTopGunl (talk) 09:34, 19 December 2011 (UTC)
- Support, but see Wikipedia:Perennial proposals#Allow watchlisting individual sections of a page. An optimist on the run! 09:35, 19 December 2011 (UTC)
- Support, though what we should be voting for is an opt-in beta of Wikipedia:LiquidThreads. They keep testing it out on other wikis, though things would move a lot faster if they allowed approved enWP users to try it out on their talk pages (or on a special beta page in their userspace). Liquid Threads is currently the only tech capable of making this happen on WP, and it was started in 2006! ▫ JohnnyMrNinja 09:49, 19 December 2011 (UTC)
- Suggest Unless you really meant threads, I recommend changing the proposal to "Watch sections (as opposed to watch the whole page)". I'd support that for sure. Saves doing it all by user script. And I imagine quite trivial to create and install. fredgandt 11:40, 19 December 2011 (UTC)
- Support as an "opt-in or opt-out" feature, providing it is not overly difficult to implement. Would be highly useful and convenient for editors interested in watching only a particular discussion.--JayJasper (talk) 22:57, 19 December 2011 (UTC)
- Support this idea, but acknowledge the complexity (and current impossibility) of implementing this. See bugzilla 738. Steven Zhang Join the DR army! 23:08, 19 December 2011 (UTC)
- Support the idea. On Portuguese Wikipedia/Wikisource Village pumps (example) it is used a system of subpages transcluded into the main page, so that people can (un)watch individual topics. There is also a proposal here for using a script to make the system a little more user friendly. Helder 00:18, 20 December 2011 (UTC)
- Comment We can all jump up and down and support this in principle, but unless there is consensus to install LiquidThreads, I'm not sure what we are going to achieve by writing comments and putting words in bold before them. And, trust me, to install LQT, we're gonna need a lot more consensus than this. —Tom Morris (talk) 09:09, 20 December 2011 (UTC)
- Support. I don't know which is the issue with liquid threads, but that was not the original proposal, nor it is unavoidable to achieve the desired result. See Template talk:Did you know, Wikipedia:Peer review, or Wikipedia:Featured article candidates (see their structure, not their specific purpose). They have individual pages for each nomination, transcluded into the main nominations page. So just change "nominations" with "discussions", and the system can work equally well for plain discussions. Cambalachero (talk) 13:15, 20 December 2011 (UTC)
- Comment it's very complicated to implement this and there is already LQT extension which support this and works great, so I don't believe anyone would be interested in integrating this feature. So even if this reach support I doubt it change anything. You should consider a proposal of installation of liquid threads instead. Petrb (talk) 14:09, 20 December 2011 (UTC)
- Comment AFAIK, all requests to enable LQT on new wikis are marked as LATER until the extension is completely rewritten (see mw:LiquidThreads 3.0 and the recent status updates). Helder 15:18, 20 December 2011 (UTC)
- Oppose While it would be useful to be able to watch a specific discussion, if the intent is to use LiquidThreads, this is a very bad idea. Liquid Threads adds unnecessary complexity to talk pages and gives talk pages an appearance similar to a forum. Alpha_Quadrant (talk) 15:42, 20 December 2011 (UTC)
- Not "my" proposal, but it isn't to install LiquidThreads; it's to enable watching sections (as I read it (see my suggestion above)). You're opposing comments made by others. fredgandt 18:20, 20 December 2011 (UTC)
- The exact wording of the proposal is threads. Current Wikipedia talk pages do not have threads, they have sections. I would support the implementation of section watching, providing it does not come in the form of liquid threads. Currently, LiquidThreads is the only technical way to implement this proposal. Until that changes, I am opposed. Alpha_Quadrant (talk) 18:24, 20 December 2011 (UTC)
Suggest we start a writer's workshop
May I suggest we start a workshop like they have on the French Wikipedia? I don't exactly know how they work, but the idea seems to be that they are pages where novices and experts congregate and discuss things. I know that sounds similar to the Ref Desks, and they are working well, but I mean starting workshops focused on specific goals, not linked merely to existing projects, but encompassing something broader. I think the best starting point would be a writers' workshop, focusing solely on improving the writing standard/ encyclopedic style of articles. The workshop would consist initially of one page, where we would nominate an article to work on, thrash out suggested improvements to the writing, and then post the changes back in the articles. Editing of content would be kept to the barest minimum. If successful, the idea could be expanded. IBE (talk) 13:50, 19 December 2011 (UTC)
- Haven't finished reading the proposal and a firm Support from me. Volunteers and students in a relaxed, easily found (and suggested (linked)) project space somewhere. would be awesome. Perfect way to boost quality, productivity, and retention (by way of encouragement). fredgandt 13:57, 19 December 2011 (UTC)
- Check with WikiProject Guild of Copy Editors. ---— Gadget850 (Ed) talk 13:59, 19 December 2011 (UTC)
Notate file pages with they articles they have been used on
![](https://upload.wikimedia.org/wikipedia/en/thumb/0/00/Perpignan_Pyr%C3%A9n%C3%A9es-Orientales_department_in_southern_France.jpg/200px-Perpignan_Pyr%C3%A9n%C3%A9es-Orientales_department_in_southern_France.jpg)
There are an amazing number of pictures that get uploaded to WP, with no (or poor) descriptive text, with ambiguous names, and the uploader disappears forever. Almost every single time an image is uploaded, the uploader edits an article to add that image, often with a descriptive caption or edit summary. Years go by and somebody edits the article so the image is no longer linked, the author is gone, so we now have no idea what the image is of. Sometimes the linked article is deleted so even the edit history is useless to regular editors. These images get deleted all of the time.
I am proposing we have bots add this information to the file pages, so that even if it is not currently being used, we will at least have descriptive text and know what article someone thought it would be useful for. I recently spent several days moving hundreds of images that were in this situation. I had to go through the uploader's edit history, sometimes I would just guess (the worst guess I had to make is now called File:Possibly Ecuador.jpg). Adding this information to the file pages would save so much time and effort. Specifically I am proposing two things:
- We run a bot that adds these tags as the file is added to the article. The information will be the User name, article and section heading the file was added to, edit summary of the addition (if one was provided), and caption (if one was provided).
- We run a bot for existing local images (starting with orphaned images), scraping info from histories.
For free images, this will make them a lot more useful when they are moved to Commons. Also, it might be a good idea to put this info in a collapsed template, so the page won't be cluttered, but the text will still hit searches. If this idea meets approval here, I will take it to bot requests. ▫ JohnnyMrNinja 04:17, 20 December 2011 (UTC)
- This sounds like a good idea to me. It would be very hard to search histories for unused images. Graeme Bartlett (talk) 10:50, 20 December 2011 (UTC)
Learn to be a Wikipedia Administrator - New class at MSU
Greetings. My name is Jonathan Obar, I'm a professor in the College of Communication Arts and Sciences at Michigan State University and a Teaching Fellow with the Wikimedia Foundation's Education Program. This coming semester I will be running a little experiment in one of my undergraduate classes. I thought that I would propose the idea to the community before things get rolling, and ask for your suggestions, feedback, criticism, and also your help!
Here's the idea... students these days (especially those studying communications) are fascinated by social media. The Education Program has done a fantastic job tapping into this fascination and the results are clear. A recent survey analysis that we completed suggests that more than 70% of the students (across the US) that have participated in the Education Program are enjoying the experience and prefer editing Wikipedia to writing "traditional" term papers. To students, social media is fun, but it's also relevant. Many communication students hope to get jobs with a new media focus and hope that their university experience prepares them for the position that they've been hoping for. This new class I'm developing, this small experiment, takes the Education Program to the next level. Instead of training students to be editors, why not train them to be administrators? The goal will be to provide students with a far more in-depth understanding of how Wikipedia operates, how the hierarchy of administration works, how policies are created (what the policies are), what admin tasks are completed daily, and so forth. What will also make this class different from most of the classes that are participating in the Education Program is that the entire class will be devoted to the "learn to be an administrator" concept, whereas most EP classes focus mainly on course content (depending upon the discipline) with the Wikipedia component being secondary.
In speaking with members of the Wikimedia Foundation and a variety of experienced administrators, it became clear right away that the students would not be able to actually perform advanced admin tasks. We had discussed potentially matching students up with admins as "buddies" so that the students could shadow them (it's an idea we're still considering), but I realized that this wouldn't allow students the freedom to participate in a truly active learning experience. Of course we wouldn't want students performing admin tasks without having gone through the formal RfA procedure, something that we won't be able to have the students do in such a short period of time (most of them probably don't have enough edits to get to the first level anyways). So, instead, the course will do the following:
Students will...
Step 1
- Study Wikipedia policies in general
- Study Wikipedia admin policies and procedures
- Learn how the community operates
- Introduce themselves to the community in a variety of ways
- Begin to integrate themselves into the community
- Begin to edit
Step 2 Conduct a variety of basic admin tasks like...
- New page patrol (will introduce themselves to the community first)
- Recent-change patrol (will introduce ...)
- Review images for copyright issues (will introduce...)
- Begin to organize a "bookshelf" for administrators
- Begin to build the bookshelf
Step 3
- Reach out to the admin community to chat
- Review different admin boards
- Reflect on their experiences and write about them
- (Hopefully) interview a few administrators about their experiences.
As you might imagine, I'm going to be figuring things out on the fly as I see how things go. For now, I thought that I would bring this idea to the community and ask for your feedback and suggestions. Personally, I think that this new idea will benefit all involved. From what I've heard there is a backlog of admin-related work on WP, our class could try to make a contribution in that area. I have also heard that the administrator community isn't growing at the rate it once was - our program is potentially training the Wikipedia admins of the future. The WMF likes the idea because it still gets students involved, connects a university class to WP and may lead to a new arm of the Education Program. The benefits to the students are obvious... learn the interworkings of one of the most popular social media/networking sites in the world.
Anyhow... What do you think? Anyone interested in helping out? I'd love to have some admins skype into our class, perhaps a few at a time for a discussion/debate? It'd be great if the students could interview a few admins too! Learn about what you do and why you love it!
Really looking forward to your comments.
Sincerely,
Jonathan Obar [snip] Jaobar (talk) 06:59, 20 December 2011 (UTC)
- I am supportive. We do need to train more admins. Having students learn about Wikipedia before they edit content I believe will be better then them trying to edit content before learning how Wikipedia works.Doc James (talk · contribs · email) 07:27, 20 December 2011 (UTC)
- From what I have seen in my experiences in admin coaching, people who edit for the purpose of becoming an administrator are like shooting stars: Bright at first, but they fade fast. I'm not convinced that what we need is to train administrators; what we need is to raise up editors who like what they're doing here. People who like it here and like what they're doing here tend to do a better job of things, from what I see. bibliomaniac15 07:37, 20 December 2011 (UTC)
- This is a great idea... but so far, only in theory. I don't know if you're aware of this, but the various Education Programs are on thin ice due to the vast amount of substandard content they generated -- skim WT:United States Education Program, the threads I linked to at WT:Canada Education Program and the whole of WT:India Education Program to get a feel for the issues. The most successful student projects on Wikipedia have professors that are experienced Wikipedians. This need for this is more acute since you are teaching Wikipedia and how we ward out unwanted content. This means you need to get your hands dirty shoveling crap, especially in the areas in which you want to teach (this will help you answer student questions). It's great to have the backlogs reduced, but doing so in an incompetent manner is counterproductive.
- Calling Wikipedia "most popular social media/networking sites" is cause for concern.
- Also, I have removed your email address as publishing it on-wiki is a Bad Idea(TM). MER-C 07:44, 20 December 2011 (UTC)
- Disclaimer: I have worked with Jaobar in the past, as an Ambassador, and he is a professor at the University I attend (I have not, nor will be taking a class with him due to being in different departments). That being said, Jonathan, is a knowledgeable Wikipedian [14] with over 800 edits, and has had a successful class within the program (ie: this one of which created many good articles such as this article - all of which were made by 1st year undergrad students and in this case classified as a DYK on April 19, 2011). Hence I would not worry about the experience of the professor - instead would ask/hope that users would make any suggestions to the type of tasks these students could perform without requiring admin rights. Epistemophiliac (talk) 16:20, 20 December 2011 (UTC)
- I'd downplay the "admin" side given that in spite of the community's frequent stated belief that adminship is "no big deal", it is a term of art in the Wikipedia community. They are really being taught how to administrative tasks, rather than tasks that require sysop powers. Given that people are likely to get a bit tetchy about this, and given that students might get the wrong idea and go around claiming they are now Wikipedia administrators because they do new page patrolling, I'd leave off the word "admin". Think about it like this: imagine if you taught a bunch of graduate students how to teach undergraduates. You might call said training course 'How to become a professor'. But that doesn't mean they are professors at the end of it, they are TAs who have skills that would be handy for them if they choose to stay in academia. The course could quite easily be called something like "How to be a Wikipedian" or "How to edit Wikipedia" or something like that. There does definitely need to be a better name for "that thing that non-admins do that is administrative". I've used the term "admin-like tasks" but that's kind of a mouthful. There's "WikiGnomes" which I use and like, but I have a funny feeling it might not play well outside of the Wikipedia community. (Of course, if we called admins "sysops" then saying that non-sysops are "administrators" doesn't imply that they have any kind of special powers. But, there are good reasons why we shouldn't call admins sysops!) —Tom Morris (talk) 09:06, 20 December 2011 (UTC)
- There should be more emphasis on building an encyclopedia. Everything on the syllabus is worthwhile for an administrator, but the students should actually know how to build an article as well. If they cannot do this there is not a chance that they would survive a WP:RFA. For a Wikipedia maintenance person (gnome) you should also introduce categories, interwikis, stubs, use of templates, different forums for help and problems, and projects such as WP:AFC WPBiography and the more specialised projects. Also article recognition and grading such as WP:DYK WP:good article and WP:featured article should be covered. Graeme Bartlett (talk) 10:46, 20 December 2011 (UTC)
- I'm broadly supportive of this: an introduction to Wikipedia's culture and policies would be a valuable course. In particular, there are a number of skills that are secondary to editing Wikipedia that nonetheless are highly applicable elsewhere that might be useful to include in a university course, such as the basics of copyright (and free licenses), or perhaps some rough ethical considerations on things like articles concerning living persons or editing with a conflict of interest,. I share some of Bibliomaniac15's concerns: a course with the implicit goal of adminship has a significant chance of giving contributors a fast rise followed by a quick burn-out. People see the "carrot", the implicit power of the admin position, but don't understand the reality that it is a position highly constrained by the community's agreements on how that power may be used, that it is a position whose purpose is often more "janitorial" than "administrative". People who succeed long-term in this role do so in part because they personally care about the project, and are willing to ignore insults and worse to help out. I'd like to help with your project regardless, but I think that you need to be extremely clear at the outset of the course about "the mop". {{Nihiltres|talk|edits|⚡}} 15:12, 20 December 2011 (UTC)
- "basic admin tasks like... New page patrol (will introduce themselves to the community first) Recent-change patrol (will introduce ...) Review images for copyright issues (will introduce...)" But these aren't admin tasks. These are tasks any editor can do. Are you trying to discuss the tools admins have (blocking, locking, deleted/restoring, editing certain pages) or just non-article writing tasks that everyone can do? Rmhermen (talk) 02:14, 21 December 2011 (UTC)
- Per Rmhermen, you're suggesting a course in social-media oversight editing. There's nothing wrong with that, but it doesn't require an admin bit; especially where wikipedia offers WP:AIV WP:ANI and the entire variety of disciplinary systems that depend on quality reporting of issues. Bit holders are just our drudges. More could be got out of protecting a day's Featured Article than by bit hunting. The final dot point would break ethics laws and expectations of professional conduct from teaching academics where I live; your professional and legal obligations may vary. Also, your course content seems kind of sparse if this is a 36 hour face to face contact / 120 hour total learning obligation course. It omits some elements of social-media oversight, like content evaluation (quality & importance rating, peer review, GAN, A-class review, FAC). It also seems a bit overbalanced towards "whack-a-mole" moderating, as opposed to community culture building. Fifelfoo (talk) 02:50, 21 December 2011 (UTC)
"Intermediate revisions by one user not shown"
Here is a typical diff between the current revision of a page and a much older revision. In the centre there is that extra message "(33 intermediate revisions by one user not shown)".
I'd like this message to be tweaked to say either "by this user" if those revisions were by the user who made the top revision, or "by one other user" if those revisions were by someone else. The distinction is important if you are thinking of clicking one of the "rollback" links. In the first case, you are about to re-instate the revision displayed on the left; in the second, you are about to roll back just one edit and re-instate a revision that you can't see. -- John of Reading (talk) 08:37, 20 December 2011 (UTC)
New Essay
I've read a few blogs and also some feedback on the dashboard and it appears to me that one of the reasons folks find Wikipedia confusing is that all of our policies "link" to more policies. So someone trying to get an understanding of Wikipedia would continually be reading a new policy, guidelines, or essay and never find "the end". I think we need an essay that does two things: 1) It explains why there is no "end" in the circular format of our policies, and 2) It explains why our policies are circular and sometimes contradictory. I think this essay needs to contain absolutely zero wiki-links except for a "see also" section at the bottom or some citations. It should explain that one does not need to know all the finer points of Wikipedia, give a brief explanation of the more major points, and suggest that a reader take each policy one at a time in full before trying to tackle another. It needs to explain why this all seems insurmountable and confusing and how to contextualize each part individually and collectively. The bottom line is: It needs to offer a "Be bold" message that suggests the reader be patient with themselves and Wikipedia but to give it a shot and be open to learning. WP:INSURMOUNTABLE with WP:THEEND and WP:CROSS LINKED as shortcuts? Thoughts?--v/r - TP 16:24, 20 December 2011 (UTC)
- Broadly support, but note that WP:IAR was the first policy anyway, introduced by Larry Sanger. The essay you suggest should at least mention this somewhere, as well as emphasising collaboration, consensus, and iterative solutions to problems (ie. don't try to do too much at once). IBE (talk) 19:48, 20 December 2011 (UTC)
- Larry was actually later a registered opponent of this policy.Sanger on the origins of this rule Rmhermen (talk) 01:47, 21 December 2011 (UTC)
- Support along with IBE's recommendations above. Such an essay would be immensely helpful to newbies and semi-active editors who get discouraged at times because they feel as though they are immersed in a bottomless pit of countless policies and guidelines. For that matter, it would probably be helpful to seasoned, established editors as well. Support the suggested shortcuts as well, and would add WP:PATIENCE, and maybe WP:HANGINTHERE.--JayJasper (talk) 20:59, 20 December 2011 (UTC)