Jump List support

Hi, as you know, Microsoft added in Internet Explorer 9 the support for website pinning on the taskbar ; I believe that Wikipedia should adopt this feature to increase its share and be easier to use and reach.

It's possible to use Jump List also in Chrome thanks to an extension (https://chrome.google.com/webstore/detail/foekkphhdncclpelbmngokikjnkikpad) and Mozilla is actively work to implement them in future releases of Firefox (http://areweprettyyet.com/5/desktopApps/).

More info at: http://buildmypinnedsite.com/

The Dark Melon (talk) 10:10, 2 July 2011 (UTC)

As far as I can make out, at the basic level, "pinning" means "put the URL in the taskbar", i.e., a feature that was implemented in Mac OS X years ago.
It appears that the advanced level adds all sorts of intrusive features, like reminding users that they ought to come visit your site. I can't imagine why we would want to spend our limited dev resources on a feature that sounds so irritatingly spammy and will only benefit that fraction of readers who have the misfortune to be using a poorly rated web browser on one of the most heavily attacked and expensive desktop operating systems in the world. WhatamIdoing (talk) 15:07, 2 July 2011 (UTC)
well if you love Mac it's not our problem, try to have an unbiased opinion. Nothing of what you wrote is actually true but maybe a mac fanboy considers all the rest just like shit..The Dark Melon (talk) 15:18, 2 July 2011 (UTC)
Two points:
  1. I would be correctly described as a fangirl, not a fanboy.
  2. My favorite OS is the one that runs the Frankfurt stock exchange. (Hint: Neither Microsoft nor Apple make it.) WhatamIdoing (talk) 23:45, 3 July 2011 (UTC)
Ok, sorry..anyway even if you use Linux you should understand that many people use other OS and you can't preclude them to enjoy feature that your so beloved os doesn't have..Jump list is a very cool addition to the standard user experience and they are really useful and not spammy. Maybe you should try other products before judging them.. The Dark Melon (talk) 19:38, 6 July 2011 (UTC)

Proposed partial solution to NFCC enforcement

Please see Wikipedia:Administrators' noticeboard/Archive248#Request exemption of restrictions ΔT The only constant 13:54, 6 July 2011 (UTC)

Align indents and lists

I propose tweaking the CSS of the English Wikipedia like so (this test sample may not work if you're not on Vector):

Outdated example, see below

Elected members

Name Party Constituency District
Ayepa Michael NRM Labwor County Abim District
Ababiku Jesca INDEP Women's Representative Adjumani District
Okot John Amos NRM Agago County Agago District
Obua Denis Hamson NRM Ajuri County Alebtong District
Obua Ogwal Benson UPC Moroto County Alebtong District
Okello Anthony NRM Kioga County Amolatar District
Lolem Micah Akasile NRM Upe County Amudat District
Eriaku Peter Emmanuel NRM Kapelebyong County Amuria District
Amero Susan NRM Women's Representative Amuria District
Olanya Gilbert INDEP Kilak County Amuru District
Ayoo Tonny NRM Kwania County Apac District
Akora Maxwell Ebong Patrick UPC Maruzi County Apac District
Ajok Lucy UPC Women's Representative Apac District
Atiku Benard FDC Ayivu County Arua District
Drito Martin Andi NRM Madi-Okollo County Arua District
Wadri Kassiano Ezati FDC Terego County Arua District
Okuonzi Sam Agatre INDEP Vurra County Arua District
Mbogo Kezekia INDEP Budaka County Budaka District
Khainza Justine NRM Women's Representative Bududa District
Baka Stephen Mugabi NRM Bukooli County North Bugiri District
Kakoba Onyango NRM Buikwe County North Buikwe District
Ssali Baker NRM Buikwe County West Buikwe District
Ekuma George Stephen NRM Bukedea County Bukedea District
Akol Rose Okullu NRM Women's Representative Bukedea District
Kiyingi Deogratius DP Bukomansimbi County Bukomansimbi District
Sabila Nelson NRM Kongasis County Bukwo District
Wamakuyu Mudimi Ignatius NRM Bulambuli County Bulambuli District
Biraahwa Mukitale Stephen Adyeeri NRM Buliisa County Buliisa District
Mpairwe Beatrice NRM Women's Representative Buliisa District
Matte Joseph Sibalinghana Kiregheya INDEP Bughendera Bundibugyo District
Ntabazi Harriet NRM Women's Representative Bundibugyo District
Tayebwa Odo FDC Bushenyi-Ishaka Municipality Bushenyi District
Magyezi Raphael NRM Igara County West Bushenyi District
Taaka Kevinah Wanaha Wandera FDC Busia Municipality Busia District
Mulimba John NRM Samia-Bugwe County North Busia District
Maganda Julius INDEP Samia-Bugwe County South Busia District
Dombo Emmanuel Lumala NRM Bunyole County East Butaleja District
Wangolo Jacob NRM Bunyole County West Butaleja District
Nebanda Florence Andiru NRM Women's Representative Butaleja District
Muwanga Muhammad Kivumbi DP Butambala County Butambala District
Nalubega Mariam Patience INDEP Women's Representative Butambala District
Migadde Robert Ndugwa NRM Buvuma Islands County Buvuma District
Egunyu Nantume Janepher NRM Women's Representative Buvuma District
Balyejjusa Sulaiman Kirunda NRM Budiope County East Buyende District
Mubito John Bosco NRM Budiope County West Buyende District
Babirye Veronica Kadogo NRM Women's Representative Buyende District
Okot Ogong Felix NRM Dokolo County Dokolo District
Nakato Kyabangi Katusiime NRM Women's Representative Gomba District
Okumu Ronald Reagan FDC Aswa County Gulu District
Acire Christopher FDC Gulu Municipality Gulu District
Kiiza Rwebembera James NRM Bugahya County Hoima District
Bigirwa Julius Junjura NRM Buhaguzi County Hoima District
Kyooma Xavier Akampurira NRM Ibanda County North Ibanda District
Kiboijana Margaret Namara NRM Women's Representative Ibanda District
Mugema Peter NRM Iganga Municipality Iganga District
Baliddawa Edward NRM Kigulu County North Iganga District
Muwuma Milton Kalulu NRM Kigulu County South Iganga District
Kabaale Kwagala Olivia NRM Women's Representative Iganga District
Kangwagye Stephen NRM Bukanga County Isingiro District
Byarugaba Alex Bakunda NRM Isingiro County South Isingiro District
Byarugaba Grace Isingoma NRM Women's Representative Isingiro District
Mwiru Paul FDC Jinja Municipality East Jinja District
Balyeku Moses Grace NRM Jinja Municipality West Jinja District
Mbagadhi Frederick Nkayi NRM Kagoma County Jinja District
Nabirye Agnes NRM Women's Representative Jinja District
Lokeris Samson NRM Dodoth County East Kaabong District
Akello Rose Lilly INDEP Women's Representative Kaabong District
Niwagaba Wilfred NRM Ndorwa County East Kabale District
Kasaija Stephen Kagwera NRM Burahya County Kabarole District
Businge Rusoke Victoria NRM Women's Representative Kabarole District
Omona Kenneth Olusegun NRM Kaberamaido County Kaberamaido District
Ongalo Obote Clement Keneth NRM Kalaki County Kaberamaido District
Ekwau Ibi Florence FDC Women's Representative Kaberamaido District
Badda Fred NRM Bujumba County Kalangala District
Lwanga Timothy Mutekanga NRM Kyamuswa County Kalangala District
Nanyondo Birungi Carolyn NRM Women's Representative Kalangala District
Lubogo Kenneth INDEP Bulamogi County Kaliro District
Nabugere Flavia NRM Women's Representative Kaliro District
Ssewungu Joseph Gonzaga DP Kalungu County West Kalungu District
Kintu Florence NRM Women's Representative Kalungu District
Ssebaggala Abdu Latif Sengendo DP Kawempe Division North Kampala District
Sebuliba Mutumba Richard DP Kawempe Division South Kampala District
Ssimbwa John NRM Makindye Division East Kampala District
Kyanjo Hussein JEEMA Makindye Division West Kampala District
Kasibante Moses INDEP Rubaga Division North Kampala District
Naggayi Nabilah Sempala FDC Women's Representative Kampala District
Nsereko Muhammad NRM Central Division Kampala District
Allen Andrew INDEP Bugabula County North Kamuli District
Mugabi Muzaale Martin Kisule NRM Buzaaya County Kamuli District
Byamukama Nulu NRM Kitagwenda County Kamwenge District
Nshaija Dorothy Kabaraitsya NRM Women's Representative Kamwenge District
Karungi Elizabeth NRM Women's Representative Kanungu District
Chemutai Phyllis INDEP Women's Representative Kapchorwa District
Bwambale Bihande Yokasi FDC Bukonjo County East Kasese District
Nzoghu M. William FDC Busongora County North Kasese District
Kafuda Boaz NRM Busongora County South Kasese District
Mbahimba James NRM Kasese Municipality Kasese District
Amodoi Cyrus Imalingat INDEP Toroma County Katakwi District
Alengot Proscovia Oromait NRM Usuk County Katakwi District
Alupo Jessica Rose Epel NRM Women's Representative Katakwi District
Lugoloobi Amos NRM Ntenjeru County North Kayunga District
Nsanja Patrick K. Mabirizi INDEP Ntenjeru County South Kayunga District
Bakeine Mabel Lillian Komugisha NRM Bugangaizi County East Kibaale District
Kasirivu-Atwooki Baltazar Kyamanywa NRM Bugangaizi County West Kibaale District
Besisira Ignatius NRM Buyaga County East Kibaale District
Tinkasiimire Barnabas Ateenyi NRM Buyaga County West Kibaale District
Nabbanja Robinah NRM Women's Representative Kibaale District
Kabajo James Kyewalabye NRM Kiboga County East Kiboga District
Mwebaza Sarah Wenene NRM Women's Representative Kibuku District
Barumba Beatrice Rusaniya Namala NRM Women's Representative Kiruhura District
Kwizera Eddie Wa Gahungu NRM Bufumbira County East Kisoro District
Kamara John Nizeyimana NRM Bufumbira County North Kisoro District
Nyirabashitsi Sarah Mateke NRM Women's Representative Kisoro District
Awongo Ahmed NRM Koboko County Koboko District
Baba Diri Margaret NRM Women's Representative Koboko District
Ebil Fred UPC Kole County Kole District
Acheng Joy Ruth UPC Women's Representative Kole District
Lokii Peter Abrahams NRM Jie County Kotido District
Amuriat Oboi Patrick FDC Kumi County Kumi District
Chemaswet Abdi Fadhil Kisos NRM Kween County Kween District
Chekwel Lydia NRM Women's Representative Kween District
Ssemugaba Samuel NRM Kiboga County West Kyankwanzi District
Nankabirwa Ann Maria NRM Women's Representative Kyankwanzi District
Kwemara Ngabu William NRM Kyaka County Kyegegwa District
Kabahenda Flavia Rwabuhoro NRM Women's Representative Kyegegwa District
Muhumuza David NRM Mwenge County North Kyenjojo District
Timbigamba Lyndah NRM Women's Representative Kyenjojo District
Lanyero Sarah Ochieng NRM Women's Representative Lamwo District
Omara Geoffrey NRM Erute County North Lira District
Akena James Micheal Jimmy UPC Lira Municipality Lira District
Atim Joy Ongom INDEP Women's Representative Lira District
Bagoole John B INDEP Luuka County Luuka District
Nabukenya Brenda DP Women's Representative Luwero District
Sejjoba Issac NRM Bukoto County Mid-West Lwengo District
Birekeraawo Nsubuga Mathius DP Bukoto County South Lwengo District
Kitatta Aboud NRM Bukoto County West Lwengo District
Nakabira Gertrude Lubega NRM Women's Representative Lwengo District
Namara Grace INDEP Women's Representative Lyantonde District
Mutonyi Rose Masaba NRM Bubulo County West Manafwa District
Kayagi Sarah Netalisire NRM Women's Representative Manafwa District
Lematia Ruth Molly Ondoru NRM Women's Representative Maracha District
Namayanja Florence DP Bukoto County East Masaka District
Mpuuga Mathias INDEP Masaka Municipality Masaka District
Kase-Mubanda Freda Nanzira NRM Women's Representative Masaka District
Bintu Jalia Lukumu N. Abwooli NRM Women's Representative Masindi District
Waira Kyewalabye Majegere S.J. NRM Bunya County East Mayuge District
Isabirye Iddi NRM Bunya County South Mayuge District
Bagiire Vincent Waiswa O. NRM Bunya County West Mayuge District
Gudoi Yahaya NRM Bungokho County North Mbale District
Wamanga Wamai Jack FDC Mbale Municipality Mbale District
Nakayenze Connie Galiwango NRM Women's Representative Mbale District
Yaguma Wilberforce NRM Kashari County Mbarara District
Bitekyerezo Kab Medard NRM Mbarara Municipality Mbarara District
Mujuni Vicent Kyamadidi NRM Rwampara County Mbarara District
Kamateeka Jovah NRM Women's Representative Mitooma District
Kiwanda Godfrey Ssubi NRM Mityana County North Mityana District
Kaddumukasa Ssozi Jerome INDEP Mityana County South Mityana District
Ssinabulya Sylivia Namabidde NRM Women's Representative Mityana District
Lokii John Baptist NRM Matheniko County Moroto District
Aleper Simon Peter NRM Moroto Municipality Moroto District
Iriama Margaret NRM Women's Representative Moroto District
Fungaroo Kaps Hassan FDC Obongi County Moyo District
Alero Tom Aza NRM West Moyo County Moyo District
Auru Anne NRM Women's Representative Moyo District
Kiyingi Bbosa Kenneth Joseph INDEP Mawokota County South Mpigi District
Nakawunde Sarah Temulanda NRM Women's Representative Mpigi District
Ssemmuli Anthony NRM Buwekula County Mubende District
Mulindwa Patrick NRM Kasambya County Mubende District
Lubega Godfrey INDEP Kassanda County North Mubende District
Bakaluba Mukasa Peter NRM Mukono County South Mukono District
Kafeero Ssekitoleko Robert INDEP Nakifuma County Mukono District
Kusasira Peace Kanyesigye Mubiru NRM Women's Representative Mukono District
Achia Remigio NRM Pian County Nakapiripirit District
Iriama Rose INDEP Women's Representative Nakapiripirit District
Sempala Mbuga Edward William NRM Nakaseke County South Nakaseke District
Mayende Stephen Dede NRM Bukooli County South Namayingo District
Okeyoh Peter NRM Bukooli Islands County Namayingo District
Makhoha Margaret NRM Women's Representative Namayingo District
Asupasa Isiko Wilson Mpongo NRM Busiki County Namutumba District
Mutyabule Florence Tibafana NRM Women's Representative Namutumba District
Achia Terence Naco NRM Bokora County Napak District
Anywarach Joshua Carter INDEP Padyere County Nebbi District
Acayo Christine Cwinya-Ai NRM Women's Representative Nebbi District
Epetait Francis FDC Ngora County Ngora District
Bahinduka Mugarra Martin INDEP Ntoroko County Ntoroko District
Mujungu Jennifer K. INDEP Women's Representative Ntoroko District
Tashobya N. Stephen NRM Kajara County Ntungamo District
Musinguzi Yona NRM Ntugamo Municipality Ntungamo District
Kabasharira Naome NRM Women's Representative Ntungamo District
Ogwal Jacinto Deusdedit UPC Otuke County Otuke District
Nyakecho Okwenye Annet NRM Women's Representative Otuke District
Ayena Krispus UPC Oyam County North Oyam District
Odonga Otto FDC Aruu County Pader District
Lowila Cd Oketayot NRM Women's Representative Pader District
Ochwa David NRM Agule County Pallisa District
Mutono Patrick Lodoi NRM Butebo County Pallisa District
Opolot Jacob Richards NRM Pallisa County Pallisa District
Amoit Judith Mary NRM Women's Representative Pallisa District
Kasamba Mathias NRM Kakuuto County Rakai District
Mandera Amos NRM Kooki County Rakai District
Kyeyune Harun INDEP Kyotera County Rakai District
Cadet Benjamin INDEP Bunyaruguru County Rubirizi District
Katoto Hatwib NRM Katerera County Rubirizi District
Mbabazi Betty Ahimbisibwe NRM Women's Representative Rubirizi District
Turyahikayo Kebirungi Mary Paula NRM Rubabo County Rukungiri District
Mugume Roland FDC Rukungiri Municipality Rukungiri District
Okupa Elijah FDC Kasilo County Serere District
Ochola Stephen FDC Serere County Serere District
Alaso Alice Asianut FDC Women's Representative Serere District
Katwiremu Yorokamu Bategana NRM Sheema County South Sheema District
Ssasaga Isaias Johny FDC Budadiri County East Sironko District
Wadada Femiar FDC Women's Representative Sironko District
Omolo Peter FDC Soroti County Soroti District
Ekanya Geofrey FDC Tororo County Tororo District
Tanna Sanjay INDEP Tororo Municipality Tororo District
Lubega Medard Sseggona DP Busiro County East Wakiso District
Mutebi Joseph Balikudembe DP Busiro County South Wakiso District
Kawuma Mohamed DP Entebbe Municipality Wakiso District
Kasule Robert Sebunya NRM Kyadondo County North Wakiso District
Kikungwe Issa DP Kyadondo County South Wakiso District
Nalubega Mary Tuunde INDEP Workers' Representative Workers District
Arinaitwe Rwakajara K. NRM Workers' Representative Workers District
Lyomoki Samuel NRM Workers' Representative Workers District
Nabulya Theopista Ssentongo NRM Workers' Representative Workers District
Achile Manoah Mila INDEP Aringa County Yumbe District
Oleru Huda Abason NRM Women's Representative Yumbe District
Asamo Hellen Grace NRM Representative of People with Disabilities
Katuramu Hood Kiribedda NRM Representative of People with Disabilities
Ndeezi Alex NRM Representative of People with Disabilities
Nokrach William Wilson NRM Representative of People with Disabilities
Karuhanga Kafureeka Gerald INDEP Representative of the Youth
Amoding Monicah NRM Representative of the Youth
Nakabale Patrick NRM Representative of the Youth
Ogwang Peter NRM Representative of the Youth
Katirima Manoni Phinehas Representative of the Uganda People's Defence Forces
Mpabwa Sarah Patience Representative of the Uganda People's Defence Forces
Oketta Julius Facki Representative of the Uganda People's Defence Forces
Owoyesigire Jim Representative of the Uganda People's Defence Forces


The benefits - mainly aesthetic - are obvious. Not sure about whether any pages would be adversely affected; I can't believe so, unless they're relying on stupidly precise measurements. Thoughts? - Jarry1250 [Weasel? Discuss.] 21:05, 5 July 2011 (UTC)

The lack of alignment is particularly difficult for threaded discussions. If we can fix it (even for most users) via CSS, that would be great. — Carl (CBM · talk) 14:32, 6 July 2011 (UTC)
I agree the lack of ability to have multiple paragraphs in a bullet-point is annoying. To clarify, if I understand, is to have the text of colon-indents and both types of list-items have the same indent? If so, I 'support. DMacks (talk) 14:38, 6 July 2011 (UTC)
I support as well but I want to clarify I think we still need a way to identify the comments from different editors. Even if we preced that comment by an arrow or something rather than stagger them we need to be able to tell different editors comments in a string. --Kumioko (talk) 14:45, 6 July 2011 (UTC)
I support this idea, it has annoyed me for a long time. Jc3s5h (talk) 14:45, 6 July 2011 (UTC)
One problem with this proposal is that ordered lists will throw themselves out of bounds:
  1. Technical Writing
<ol> has a left margin of 3.2em, which would have to be increased to 4em, which is way too wide. A possible solution is to make both <ul> and <dd> left margins 1.6em. Here's a tiny piece of personal CSS that will achieve this effect.Edokter (talk) — 14:59, 6 July 2011 (UTC)
ul, dd {
  margin-left: 1.6em;
}
I like this idea. One minor problem is that it would make bad formatting impossible to spot. Right now, when I see something incorrectly formatted (which is a problem for WP:ACCESS#Lists, it's obvious because it's ugly. WhatamIdoing (talk) 15:17, 6 July 2011 (UTC)
Interesting. If you could give some examples, there may be a way to remake them obvious. - Jarry1250 [Weasel? Discuss.] 18:49, 6 July 2011 (UTC)
Yeah, this sounds like a great idea to me. – Quadell (talk) 18:16, 6 July 2011 (UTC)
Nobody is going to write an ordered list with even 1000 entries, so the proposal above seems fine and a good improvement. -- Eraserhead1 <talk> 18:44, 6 July 2011 (UTC)
I agree; the existing system drops out at 100,000 anyway (for those tempted to misuse ordered lists). - Jarry1250 [Weasel? Discuss.] 18:49, 6 July 2011 (UTC)
You mean the original proposal or mine? Edokter (talk) — 19:11, 6 July 2011 (UTC)

This has been tried before. However much support there might be for aligning things, it's a technical impossibility. --Izno (talk) 21:45, 6 July 2011 (UTC)

And this discussion as well (linked in the above). --Izno (talk) 21:48, 6 July 2011 (UTC)
I'm sorry? How is it technically impossible? Edokter (talk) — 21:54, 6 July 2011 (UTC)
Let me rephrase: It breaks browsers. That's bad, no? (See the second discussion, which you in fact participated in.) --Izno (talk) 22:02, 6 July 2011 (UTC)
Yes, but neither of those discussions (neither of which were linked from the bug report that prompted me to propose this discussion, which is why I though they didn't exist; mea culpa) suggest impossibility, only the need to test, review and hammer out. Carnildo obviously has an unusual setup, which I shall try to emulate. If we can establish a consensus here that if we can avoid breaking anything, we want to make this change, then I shall proceed with testing. How does that sound? - Jarry1250 [Weasel? Discuss.] 22:08, 6 July 2011 (UTC)
It is very easy to implement. Back then, some list elements had no styling, which caused the inconsistencies between browsers. But now all lists have a margin set, but they are all different, making them inconsistent when used together. The current situation is as follows (for Chick, Modern*, Monobook and Vector):
  • <ul> has a margin left of 1.5em.
  • <dd> has a margin-left of 2em. (* missing in Modern)
  • <ol> has a margin-left of 3.2em.
You can see why this creates problems when mixing these elements, but they could easily be resolved. Above, I suggested setting the left margin for <ul> and <dd> to 1.6em, without touching <ol>. This means the bulleted list (*) will have 0.1em added (unnoticable) and the defenition list (:) will have 0.4em less space to it's left, lining them all up perfectly, and without any breakage. Edokter (talk) — 00:10, 7 July 2011 (UTC)

Test

Since there is support and no technical issues (that I know of), I have gone ahead and changed the left margins of <ul> and <dd> from 1.5em/2em to 1.6em in Vector and Monobook. Chances are noone will even notice, except for discussions lining up properly. Please report any issues here. This is a test. If succesfull, it can be expanded to other skins, and I even have a patch ready to go. Edokter (talk) — 13:23, 8 July 2011 (UTC)

Two RfCs for allowing bureaucrats to remove the admin bit

Two related Requests for Comment are now open to discuss giving bureaucrats the ability to remove administrator user permissions under specific circumstances. Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag proposes enabling the technical ability for bureaucrats to do this. Wikipedia:Requests for comment/Bureaucrat removal of adminship policy proposes the specific policy conditions under which they would be allowed to use that ability. Please visit both RfCs to give your input. Thanks. --RL0919 (talk) 20:14, 7 July 2011 (UTC)

Restrict use of the Special:EmailUser feature to autoconfirmed accounts

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There does not appear to be any support for this. SNOW close. Sven Manguard Wha? 05:25, 11 July 2011 (UTC)

<WP:BEANS redaction Rd232 public talk 23:31, 8 July 2011 (UTC)> While I can neither confirm nor deny that this has happened (but I'm pretty sure it has), I propose that access to the Special:EmailUser feature be restricted to accounts who have the autoconfirmed flag. ceradon 00:07, 4 July 2011 (UTC)

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

Proposal to standardize country color scheme in timelines

We, User:Y.golovko and I, want to have a standard for color scheme for countries. The actual situation is not good. Some examples are Template:Timeline Tour de France Winners and Template:Timeline Vuelta a España Winners]. The problem is that many countries have similar or identical colors. Here is our start of an proposal: Part of the information for the colors came from the articles called national colours and X11 color names:

mabdul 19:38, 6 July 2011 (UTC) Y.golovko (talk) 20:49, 6 July 2011 (UTC)

In theory this is a good idea, but I can see problems; having 200 or so different colors will lead to contrast problems in any scheme; you will always run into problems where some article or another will have 3-4 countries whose colors are nearly identical. So, why not allow for each article to choose 3-4 different highly contrasting colors for that article instead of devising a project-wide universal coloring scheme? I'm not saying I am opposed to choosing such a scheme, but the problem you note (having countries within one article having the same color scheme) isn't ammeliorated by your proposed solution. --Jayron32 20:40, 6 July 2011 (UTC)
What do you mean by "War"? --SPhilbrickT 12:50, 7 July 2011 (UTC)
Given that the context is sport, I would guess "[colour for that bit of the bar when no-one won the trophy because the championship was cancelled due to] war". 21:53, 7 July 2011 (UTC)
Why Dodger blue, rather than red for Russia? (I realize that you may be looking for general feedback on the concept, rather than specific discussion of particular choices, but I can't let this one go.)--SPhilbrickT 12:55, 7 July 2011 (UTC)

make it opt-in. Don't constrain others...but come up with a great system and spread it. Um...and England is PINK!

Splitting Files for deletion into separate processes for free images and non-free images

I would like to discuss the possibility of splitting Wikipedia:Files for deletion into separate processes for free images and non-free images. The rationale is that there are completely different considerations involved between the two - free images are deleted for reasons of usefulness or editorial discretion, while non-free images are deleted for reasons of compliance with policy. If you would like to discuss this idea, please see Wikipedia talk:Files for deletion#Proposal_-_split_non-free_files_and_free_files. Thanks. --B (talk) 16:18, 12 July 2011 (UTC)

Unless the activity in both spheres is likely to stay vigorous (I mean in volume, not tone), I recommend against splitting. I find discussion pages lose critical mass when too much splitting is done. Look at PUFD (a graveyard).TCO (reviews needed) 16:40, 12 July 2011 (UTC)
Are you referring to WP:PUF? If so, it's not a graveyard at all. --B (talk) 17:17, 12 July 2011 (UTC)
Yeah, I just ran something through there to try to get input on the rights status (was a complex concern) and got no participation. I looked on the day log for other images and there was not much going on for those other topics either. Take it for what it is worth...a "user data point".TCO (reviews needed) 17:20, 12 July 2011 (UTC)
Well, I think there are two problems there: (1) PUF also has the same disparity between "crap to delete" (maybe we need Wikipedia:Obviously unfree files?) vs images where someone needs actual assistance. (2) PUF has a two-week aging period, so a lot of times files just don't get noticed for awhile. I know that I usually look at files at the top of the page (in other words, ones that are near the end of their two weeks.) So I think there may be some systemic problems there too ... maybe if we had some kind of way to flag PUF submissions where you are really looking for help as opposed to ones where we're just waiting around for two weeks to see if the uploader wants to provide proof of the license? --B (talk) 17:35, 12 July 2011 (UTC)
Yeah, it is a puzzle. right now, I sorta like how Commons does it, just with a single-stage procedure. Find the "scrunch factor" of the impending deletion concentrates people's thinking. TCO (reviews needed) 17:39, 12 July 2011 (UTC)
Most of the decisions at PUF are just done by the closing admin without discussion. I'm not saying that discussion is not welcomed, but generally the admin can determine if a deletion is warranted just from what is presented by the requester and an understanding of the rules. --After Midnight 0001 03:14, 14 July 2011 (UTC)

Applying the speedy deletion button to unblock requests

I just had a thought. If we provide an easy way for users, especially newcomers to contest speedy deletions at the push of a button, couldn't we apply the same thing to unblock requests for blocked users, i.e. a "contest this block" button? To me, it would seem logical and helpful, as not all newcomers are going to be aware of how to contest blocks. –MuZemike 23:13, 12 July 2011 (UTC)

I think that's a good idea. WhatamIdoing (talk) 00:18, 13 July 2011 (UTC)
Yes, especially with users blocked for username issues; I frequently come across malformed unblock requests for usernames (I'm not an admin, but I do a lot of UAA work, and I sometimes check on users who appear to have been editing in good faith), and this proposal seems like it would help. I can say that it's tremendously helped with contesting CSD tags (even though the rationales are frequently missing the point, at least users are getting their say), and hopefully it would have the same effect with unblock requests. The Blade of the Northern Lights (話して下さい) 03:43, 13 July 2011 (UTC)
I agree, this is a good idea. - Hydroxonium (TCV) 05:45, 14 July 2011 (UTC)
Just try to be really careful formatting the preload content, it seems that every time preloads are used, new editors find a way to mess them up when filling in information requested. Just look at the number of people who put the reason after the signature when contesting a CSD with the button. Still a good idea, just be ready for the malformed requests. Monty845 06:47, 14 July 2011 (UTC)

About Walt Disney

Hi yes I have a complaint and a question..... Where did you get all this information? And how do you know its true? Because for the info he went to school in Umitilla Fl, because my great great grandfather was his best friend in school I know cause he would always tell stories about him to his children which led on to me I'm only 16 and I sure know more no affiance.... But please put this in their cause I'm not lying my grandfather would never lie to me my great great grandpa was one of the first to live in Eustis and I have proof too :) so please write me back. Thank You

From Rene'e Tremain!

Proposal: merge Community portal help section with Help:Contents

I've posted a proposal on Wikipedia talk:Community Portal regarding moving the duplicated help content off that page. Any and all feedback is appreciated. — Pretzels Hii! 01:32, 14 July 2011 (UTC)

Suggestion for a new adminbot - Deleting Unpopulated categories

Hi guys. I'm considering filing a WP:BRFA for an adminbot that will delete unpopulated categories per WP:CSD#C1. But firstly I would just like to establish if there is indeed consensus for such a bot. Essentially the bot will periodically (mostly likely once a day or week), go through Category:Empty categories awaiting deletion and delete categories that meet the follow criteria:

Any objections, complaints, ideas? Have I missed anything obvious? --Chris 12:49, 4 July 2011 (UTC)

You should definitely confirm that the category actually is empty. Additionally, in addition to Wikipedia:Categories for discussion, you should also check Wikipedia:Stub types for deletion. And you shouldalso exclude WikiProject categories (see Wikipedia:Database reports/Empty categories for how MZMcBride's bot, BernsteinBot, defines those) and for maintanence categories which haven't been populated yet (these are somt times created a few days in advance, and may already be valid for several hours before they get populated). עוד מישהו Od Mishehu 13:13, 4 July 2011 (UTC)
Can you throttle down the bot so that it doesn't immediately start deleting categories as soon as they're empty? We frequently get vandals who remove the cat from every member of the cat, if the bot were to go in and delete the cat because of the vandal's actions, reverting the vandalism would leave us with a red link to the category. The Mark of the Beast (talk) 21:41, 5 July 2011 (UTC)
If I understand the proposal correctly, it only deletes under C1. C1 already has a 96 hour hold time from when an empty category is tagged. Courcelles 06:17, 6 July 2011 (UTC)

@Sven, bear in mind, that this bot will only be deleting categories that have been tagged for deletion, not all empty categories; the false positive rate will be extremely low for the situation you describe.
@After Midnight, the idea was more to remove another mundane easily botable task from your workload, so you have time to do other things, but if your happy doing it then go ahead.
I honestly don't see this being a problem or causing any false positives (no greater than an human admin anyway), but well, if you guys don't want it, then so be it. --Chris 13:33, 15 July 2011 (UTC)

Recent Changes- tags for patrolled and reverted edits.

I've been doing a lot of RC patrol, and thought of this:

Observations

Proposal

Why I think it will be useful

What do you think?[good|not sure|thats crazy] :P

Staticd (talk) 06:49, 5 July 2011 (UTC)

Similar stuff has been raised thrice in the RCP talk page but came to no conclusion than "it would be nice "[1] [2] [3] Staticd (talk) 07:01, 5 July 2011 (UTC)

I don't think I understand how this could possibly work. According to Huggle, there are generally between 60 and 150 edits to Wikipedia per minute, at least when I edit. If I'm going at ultra-high speed, and only checking for obvious vandalisms (that is, not actually reading anything more than enough to determine if it's likely bad faith content, and ignore everything that could be bad but I'm not sure without investigating), I don't think I can cover more than 15 a minute (accounting for connection times, reading times, and the use of filtered edits on Huggle). That means that, unless there's 3 people working at that pace, within an average hour, there will be over 2000 edits that won't have been reviewed at all. And most of the time, I actually work much slower, because I don't only look for vandalism, and, when I see something questionable that I can't immediately determine the value of, I open up the page, look at the history, etc. And if I decide to make a personalized warning, I'm down to one page or less a minute. So, the end result of this would be that there would still be hundreds to thousands of "unreviewed" edits. That, however, is fine, because the majority of edits are good (or, at least good faith), and even those bad faith contributions that are missed will probably be picked up the next time an interested editor looks at their watchlist. When I first started Huggling, I thought something like this would be helpful. But, the more I do it, the more I feel like it would add more work for RCP, while not actually achieving the goal it sets out to. Qwyrxian (talk) 12:35, 8 July 2011 (UTC)
It's certainly an interesting idea. However I share some of the same reservations as Qwyxrian in that the practical implications of this measure is questionable. -Cntras (talk) 11:29, 9 July 2011 (UTC)

What I want is not perfect reviewing( complete cover ) but more efficient reviewing: maximise the benefits of the effort by the volunteers. This information will also help watchlisters. What i want to know is whether the resources (development and the running overhead) for are worth the increase in vandal catching efficiency and the satisfaction of editors.What says you ?Staticd (talk) 11:18, 15 July 2011 (UTC)

Translation support

I think that would be useful to set up a request page to ask a language check for new articles written by non-native english speakers. I created a some new pages, and many of them had few if any grammar fix in weeks. Since I don't think my english is that good the only option left is, being articles of specific interest, no one bothered to proofread them. A list of articles requiring proofreading could definitely do the job. --Jollyroger (talk) 08:46, 15 July 2011 (UTC)

See: WP:GOCE. You can also make the request by placing this ((copyedit)) template on the top of the article. It will be listed in the category of article requiring clean up`. The cat is monitored by the GOCE. Kudpung กุดผึ้ง (talk) 08:58, 15 July 2011 (UTC)
Spot-on. Thanks --Jollyroger (talk) 09:18, 15 July 2011 (UTC)

Require all new articles to contain at least one source

I'm sure this is a semi-perennial proposal by now. I am wondering why it isn't at this point, now that we are well beyond the initial hurdle of content creation and are working more towards making what we have more verifiable and properly sourced, that we don't require that all articles have at least one source. Our core policies of notability and verifiability surely demand this minimal requirement before a topic is worthy of an independent article, but for some reason we do not take the next logical step and demand that articles require at least one reference before being created. I'd like to see what the general sentiment would be on a proposal to make this the case.

Obviously its not realistic to enforce this on already existing articles, so: What is your opinion of requiring all new articles have at least one reference, or else be eligible for speedy deletion? - ʄɭoʏɗiaɲ τ ¢ 23:31, 10 July 2011 (UTC)

I hope that everyone sees this, and as such I am amending it to the first post I made. It seems that most of the opposition so far is based on a misunderstanding of this proposal. I am a planner and as such, I have a tendency to take things one step at a time to avoid opposition. This proposal is purely regarding the concept, and not the mechanics of how it would be accomplished, how long, which articles, etc. I don't want to see articles speedied immediately, nor do I want the system to prevent a page from being created when a reference isn't included. This is merely a proposal of deleting (in some manner) articles created after the enforcement date which lack a source after a certain period of time. The closest system currently in place would be BLPPROD.
I'd also like to take this opportunity to address the second most common reason for opposition, that we'd be biting newbies and making it harder to contribute. On the contrary; as it stands, these new, unsourced articles are generally nominated for deletion rather quickly, leaving the newbie diving head first into one of the most nasty processes we have here for new editors (second only to the Administrator Noticeboards IMO). This is by far and large more intimidating than the instruction that new articles (which already require signing up for an account) "contain at least one source, placed between <ref> and </ref> tags". There are many issues causing our present newbie/dwindling experienced editors situation, but this isn't one of them. It is the main contributor to our unsourced articles situation, however. - ʄɭoʏɗiaɲ τ ¢ 22:22, 11 July 2011 (UTC)
  • Tentative Support subject to hearing the opposition arguments. I hope anyone opposing will give a real example of an existing article with sources which is fine as is. I understand, at one time, there was a notion that one editor would write a stub with no references and someone else would add references, and this was part of what made WP great. I also suggest that what was true in 2001 is not necessarily still true in 2011. I suppose it is technically possible to pass WP:N without adding a source - there may be extensive discussion in reliable sources, but the editor just chose not to include them. I wouldn't be in favor of permitting an article without sources to be CSD'd, but I would support giving 48 hours notice, and then CSD. I would support extension of sticky prod (deletion if no RS after ten days).--SPhilbrickT 00:05, 11 July 2011 (UTC)
Indeed, I wouldn't want to see them speedied immediately anyways. Perhaps stuck in a PROD like category, where if they don't have a reference after a week they are deleted. There are plenty of ins and outs of the mechanics that could be refined if the general concept floats well with the community. - ʄɭoʏɗiaɲ τ ¢ 00:23, 11 July 2011 (UTC)
If the community salutes this flag then it's likely to be as an extension of the current WP:BLPPROD "sticky PROD" system. --Ron Ritzman (talk) 00:28, 11 July 2011 (UTC)
I agree. Coincidentally, I've been writing to OP looking for clarification of a couple issues, and my sense is that extension of sticky prod to all articles would be the best solution. It would mitigate the concerns of almost all opposes.--SPhilbrickT 15:56, 11 July 2011 (UTC)
We currently have a BLPprod team that manages to salvage a very high proportion of the BLPprods worth salvaging. I rather fear that extending the sticky prod process to a large group of low risk articles would both swamp that team and end any pretence that this was prioritising high risk articles. Remember the original motivation for BLPprod was to improve our BLP process, though the effect has been to shift resources from other areas, some of which are higher risk in BLP terms. Prioritising a low risk area inevitably means deprioritising higher risk areas, and undermines the whole self organising ethos of the wiki. ϢereSpielChequers 19:44, 11 July 2011 (UTC)
  • Support, conditionally, depending on what one means by "require" and how that's implemented. So far we've dealt with unsourced articles, and in particular unsourced BLPs, with after-the-fact deletion. I support, quite strongly, the need for some mechanism to ensure that we don't have unsourced BLPs, but I the way we've done it is about the most painful thing possible for the editors, particularly newer editors, who create these articles. They get themselves into an interface that lets them create new articles, but gives them absolutely no feedback at the time of article creation about what they've done wrong. Instead, we just hit them with templates and a handful of deletion processes and eventually delete the article. Compare this for a moment to a world where we have a line, below the article entry window, and above the edit summary, where we simply ask for the sources at article creation time--and don't honor the "submit" until something is in that field. In that case, we'd get decent sources at least half the time in cases where we get none today. Yes, we need to deal with incoming unsourced articles, but we need to do it in a way which encourages and assists editors, rather than confusing and frustrating them.--joe deckertalk to me 00:35, 11 July 2011 (UTC)
  • CommentIf a newbie created an article about some cool thing someone once told him about: Confederate General Nathan Forrest built a raft called the CSS Yazoo (raft) during the Civil War with cannons on it and fought Union boats on the Tennessee River," and the new interface says "This will not be posted until you provide a reliable source," being a newbie, he likely would add as a reference "My Dad told me about it and he heard it from his Granddad who served on the Yazoo." Then it would likely satisfy the interface but some sharp eyed new page patroller would promptly tag it for deletion, saying "Your Dad and his Granddad are not reliable sources." No net improvement in the loss of new editors. It is very hard to get editors to go to their library or Google Books to find references. Edison (talk) 15:49, 13 July 2011 (UTC)
  • Comment Sure, sometimes you'd get no useful information. I have been surprised, however, watching BLPPRODs, and pleasantly so, how often something arguably reliable gets included. That some cases wouldn't be helped doesn't change the fact that *some* articles would get more information. And even in the case you described, knowing that the author didn't have a RS at hand allows one to move more confidently (if a RS can't be found by those of us who clean up the mess of unsourced BLPs for other editors) towards whatever deletion process seems appropriate. --joe deckertalk to me 19:53, 13 July 2011 (UTC)
  • Oppose until such time as the necessary software support for this to be remotely approachable for new users is available and proven. Joe Decker has described one approach to this; there are others. But requiring someone to be an experienced Wikipedia editor before they can create an article is not okay, and that's what this would amount to if implemented with current software. Software development of some kind has to happen for this to be feasible, whether it's a "what are your references" box, Aguarxed pop-ups for common citation templates, or what-have-you. Since 1) community consensus has no particular power to drive software development, 2) a better UI for citing sources is something we need anyway and can be developed without a driving policy, we should get the software first. (Though sentiments in favor of the article creation restriction should be viewed as sentiments in favor of the citation software, as far as any programmers are concerned who are wondering whether the community would want them to put something together here.) —chaos5023 (talk) 00:47, 11 July 2011 (UTC)
  • Oppose proposal in current form. While I think the intention of this proposal is very good, why only one source? This means one could create a very long article and then simply provide one source, while there could still be plenty of unverified, possibly wrong information. In fact, I think if the editor has provided a (possibly unreliable) source and then the article gets deleted, he or she might be even more discouraged than in the current situation, because he or she might think "Well, I provided a source like you said and my article still gets deleted". Toshio Yamaguchi (talk) 00:57, 11 July 2011 (UTC)
Its just a bare minimum, as opposed to our current bare minimum, which is an indication of why the subject is notable. One is better than none, and at least verifies that the subject matter is notable. - ʄɭoʏɗiaɲ τ ¢ 04:04, 11 July 2011 (UTC)
  • Support  This proposal would go the right direction toward reducing the amount of time spent by volunteers in deleting or rescuing articles.  The speedy delete is the first stage, we'd almost immediately want to add some simple software support to query the article creator.  This would not require software intelligence, the responses would simply be posted on the Discussion page of the article.  I've previously here recommended requiring two content references, but I now suggest that we request an identifiability reference to explain the title of the article, and one content referenceUnscintillating (talk) 02:14, 11 July 2011 (UTC)
  • Comment  Can we get some feedback from the developers on this?  Unscintillating (talk) 02:14, 11 July 2011 (UTC)
  • It wouldn't require any sort of backend changes. - ʄɭoʏɗiaɲ τ ¢ 22:43, 11 July 2011 (UTC)
  • Oppose it is already difficult enough to make a new article in the first place without adding more mandatory requirements. This would drive away more new users and entrench the experts. Graeme Bartlett (talk) 02:39, 11 July 2011 (UTC)
  • I'd think that the process of writing an article without one and having it go through AfD is far more likely to discourage a potentially long term contributor than being told from the start that you must include at least one reference when creating an article. Editors who are discouraged by this concept are A) unlikely to remain beyond the initial article contribution (fly-by), and B) not the type of editors we need hanging around if they should decide to. - ʄɭoʏɗiaɲ τ ¢ 04:04, 11 July 2011 (UTC)
This is already the case. I think a template saying "This article has no references. Please add one within X time or it may be deleted" is overly confusing, creeping or abusable. - ʄɭoʏɗiaɲ τ ¢ 22:43, 11 July 2011 (UTC)

Apart from these there are 'many' articles which start off with no references and then acquire them - my Disgusted of Tunbridge Wells and Pal Maleter would be examples.

How many 'unreferenced' articles are deleted for other reasons (e.g. non-notability, more appropriate for other contributory websites, advert-like...)? Jackiespeel (talk) 14:07, 11 July 2011 (UTC)

I must be missing something. If a new user create an article with no references, and this proposal were enacted, they would receive a message informing them that the article is missing a reference, and they have ten days to address it. It's not automatic only in the sense that we (for reasons I do not follow) allow people to CSD and PROD without notification. But if we close that loophole, they would be automatically notified. Or, simply amend the rule that Sticky Prods cannot be deleted unless the editor is notified.--SPhilbrickT 21:03, 11 July 2011 (UTC)
Well, 'notifying' users isn't helping much when you do it with big red scary templates. It isn't exactly the most ideal way of dealing with someone who just possibly might be one of the majority of new users who didn't add a ref because they didn't know how to. As experienced users, can we actually believe that editors will intentionally omit references on a new article they just created for whatever reason other than simple ignorance?
Meanwhile, another speedy stipulation for unreffed merely adds yet another justification for deletions of a broad range of subject with or without correct context. It's this sort of big 'assembly-line' that makes admission and eventual retention of new editors so difficult in the first place.
What's wrong with deciding on a case by case basis? What's wrong with googling a subject and/or writing on someone's talk page requesting they reference their recently created article with links to things like WP:REFBEGIN and whatnot? There are enough people nominating articles for deletion out there without even ascertaining notability. We don't need to give them more justification by actually encouraging them to simply delete any unsourced articles they find. Nor should we lump all unreffed articles together with the non-notable or unencyclopedic that PROD and CSD A7 usually deals with. Or the sensitive topics that BLP PROD deals with.
We should not encourage nominators to simply stop at looking for the ((Reflist)), and not lift a single finger more if they don't find one. Even if some of them already do in practice, at least it's comforting that it's still considered better to make sure the problems can be fixed and references can be added. Making speedies for unreffed articles official will completely remove that element of WP:SOFIXIT in the deletion evaluations of new articles by new editors. Why try looking for sources when a policy already tells you you can delete it outright? -- Obsidi♠n Soul 23:00, 11 July 2011 (UTC)
That's what userspace is for. If there is no discussion on the topic, then there is nothing to put on Wikipedia except original research. - ʄɭoʏɗiaɲ τ ¢ 22:26, 11 July 2011 (UTC)
For what it's worth, I also oppose a "sticky prod" version of this. While sourcing is very-highly desirable, it is in no way mandatory as far as whether an article should be allowed to exist or not. We have ((unreferenced)) for a reason, and it's works just fine. Take an article like Quark and strips it of references. Now suppose we don't have an article on quarks, and that someone puts up the same version as this online, except it's not referenced. You'd have to be out of your damn mind to want to delete it purely on the ground that it's unreferenced. Headbomb {talk / contribs / physics / books} 21:44, 11 July 2011 (UTC)
You're right! A link to Google maps at the location of the village would be an acceptable reference. That way, any casual user can verify that the place exists. - ʄɭoʏɗiaɲ τ ¢ 10:55, 12 July 2011 (UTC)
Really? It's the OS Grid Reference I was mentioning - not Google Maps. That can't be counted as a true reference; it comes standard in the article's coordinates. Jaguar (talk) 15:06, 12 July 2011 (UTC)
However. This proposal has problems. Deleting material that is unsourced is not the answer - it's sourcing the material that we should be doing. And it doesn't matter when the material is or has been added. If material is unsourced it is problematic and needs sourcing. There is considerable focus on new articles already with New Page Patrollers, while the quarter of a million existing articles with unsourced statements continues to grow. Limiting the proposal to new articles is not going to actively address that neglected problem, and though I appreciate it is a step in the right direction, the proposal should be looking at where the major problems exist and where not enough attention is currently be directed.
We do need to do something, so I am in favour of the spirit behind this proposal. However, limiting attention to new articles, and offering only a solution of deletion, is not something I feel I can fully support. This proposal is flagging up the problem, but is not offering workable solutions.
Tagging articles is the first step. This alerts editors and readers to the problem. We then need to actively deal with the tagged articles. Perhaps a bot could highlight in red all statements (or entire articles) that have been tagged for over a year, send a message to the five main contributors to the article, and if the statement is still unsourced after 30 days comment it out, so it is still in the article but is not visible unless read by an editor. Leaving the comment in the article means a later editor can make a human decision, but in the meantime the dubious material is not read by readers and is not copied onto mirror sites. SilkTork *Tea time 11:14, 12 July 2011 (UTC)

Require all new articles to contain at least one source: Do something

I think many users are misinterpreting the proposal

I'd also like to take this opportunity to address the second most common reason for opposition, that we'd be biting newbies and making it harder to contribute. On the contrary; as it stands, these new, unsourced articles are generally nominated for deletion rather quickly, leaving the newbie diving head first into one of the most nasty processes we have here for new editors (second only to the Administrator Noticeboards IMO). This is by far and large more intimidating than the instruction that new articles (which already require signing up for an account) "contain at least one source, placed between <ref> and </ref> tags". There are many issues causing our present newbie/dwindling experienced editors situation, but this isn't one of them. It is the main contributor to our unsourced articles situation, however. - ʄɭoʏɗiaɲ τ ¢ 22:22, 11 July 2011 (UTC)
It's my impression that most articles written by newbies are being speedied, not sent through AFD. Increasing the proportion that get deleted because one eager NPPer and one jaded admin decide that the subject is, e.g., favorably described (called "unambiguous spam"), without any further input from the community about whether the article is capable of being improved or whether Wikipedia ought to have an article about that subject, does not seem like an improvement to me. WhatamIdoing (talk) 22:40, 11 July 2011 (UTC)
If anything this would reduce the number of new articles deleted because there is no evidence of their notability and no source. I don't see how my proposal has any effect for better or for worse on corrupted administrators deleting new articles as unambiguous spam, certainly nothing for honest admins that being informed well ahead of the change wouldn't solve. - ʄɭoʏɗiaɲ τ ¢ 22:46, 11 July 2011 (UTC)
One thing I would say those of us in opposition are not mistaken about is this–notability is not dependant on sources being provided in the article. Either something is notable or it is not. Notability is the defining factor for deletion. Not quality. In the end this proposal is about quality of an article. Deletion is not the option. Deletion, except in exceptional cases, should be a COMMUNITY decision, not a speedily arrived decision by one or two people, as What was describing. We are not a bureaucracy and this seems like substituting a bureaucratic process for a consensus based democratic one. Still oppose, and I am under no misunderstanding about what this proposal entails. This proposal flies in the face of what Wikipedia is about.Camelbinky (talk) 22:57, 11 July 2011 (UTC)
Well, perhaps you'll help me understand how deleting articles without citations reduces the number of deletions. Here's what happens now:
  1. Newbie creates an article on a notable subject, but does not type sources (into the first draft; most new articles are reviewed within minutes of the page creation).
  2. The NPPer (perhaps) happens to notice that it's a notable subject and tags it as ((unref)).
  3. The article does not get deleted.
You propose to change this to:
  1. Newbie creates an article on a notable subject, but does not type sources (into the first draft).
  2. The NPPer completely ignores any considerations like notability and tags it for deletion as containing zero citations.
  3. The article does get deleted.
This does not sound to me like a method of reducing deletions. WhatamIdoing (talk) 22:53, 11 July 2011 (UTC)
When you only look at sourceless articles, yes, more will be deleted. When you look at new articles in general, fewer will be deleted, as informing the user will become far more proactive.
  1. User creates a sourceless article
  2. NPP patroller tags with ((new-unref)), and a small warning appears at the top of the page saying "Please add a source to this article indicating where the information was retrieved from. Articles without a source may be deleted after one week", and leaves a seond message on the users template which explains the simplest method of creating citations (a bare url within ref tags), and explains why we reference our content.
  3. User learns and does, improving our encyclopedia, or user ignores and goes down the same road that all newbies go down at present.
That's how I see it, anyways. - ʄɭoʏɗiaɲ τ ¢ 23:58, 11 July 2011 (UTC)
That's a nice story, but I sincerely doubt that it will work that way. At present, 20% of our newbies are creating articles that survive the first few months. You propose to jeopardize some of those articles in return for the unsubstantiated hope that they will name "a source" (NB that you have not recommended "an WP:Independent source", which would tend to show notability) and then not be confused and offended when their source is declared insufficient.
BTW, the simplest method of creating a citation is to type the author's name, the title, and the publication date in plain text, underneath a section titled ==References==. WP:General references are simpler than WP:Inline citations and every bit as useful for showing notability. It's also preferable to teaching them how to exacerbate the WP:Linkrot problem that bare URLs pose. WhatamIdoing (talk) 00:26, 12 July 2011 (UTC)
Indeed. I believe that the first and most important point for a newly registered user is learning how to use our citation system. Sure unreferenced articles pose a larger workload, and take priority over link rot? I thought that's what we were here to do? Content creation can only go for so long without accumulating a never-ending backlog of cleanup work (which we already have). Newbies who do not learn how to reference what they write find out the hard way; its best that we point it, and only it, out to them from the very outset. - ʄɭoʏɗiaɲ τ ¢ 00:45, 12 July 2011 (UTC)
I do not think I misunderstood you at all. I simply look ahead at where this is leading and -to me- it doesn't look as positive as you describe it. Hoverfish Talk 22:59, 11 July 2011 (UTC)

Is this going anywhere?

I really don't see this going anywhere. Way too much opposition and not just that there needs to be a fix to certain parts of the proposal, but a fundamental opposition to the idea itself, at least at this moment, though as one recent comment stated a move in this direction may be warranted in the future. Unless it can be shown that some sort of compromise can be made I see this discussion as just a hypothetical at this point and no snowballs chance in being implemented and therefore no reason for further discussion since nothing productive can be achieved.Camelbinky (talk) 00:48, 12 July 2011 (UTC)

I'm sorry that you are getting frustrated. Regardless, there is plenty of productive brainstorming which can be formative towards later proposals, after only 24 hours. Sit back and take a break. - ʄɭoʏɗiaɲ τ ¢ 00:57, 12 July 2011 (UTC)
Or you can give up this ill-conceived unneeded bureaucratic instruction creep. Have you read all the opposition? Snowball applies to this proposal.Camelbinky (talk) 05:42, 12 July 2011 (UTC)
May I suggest that you calm down, tone down your language regarding the proposal which has actually received support from quite a few editors, and be patient? As Floydian says, there is still some useful discussion going on, and if this thread remains open beyond 24 hours, it's unlikely to hurt you personally. ╟─TreasuryTagpikuach nefesh─╢ 08:12, 12 July 2011 (UTC)
I definitely would like to see this play out - there are good points being made. That being said, this probably should have been introduced in the idea lab instead of here. Perhaps the next step should be to use the idea lab to build a complete proposal. --JaGatalk 17:30, 12 July 2011 (UTC)
Agreed. Worth a try. Rd232 talk 23:33, 12 July 2011 (UTC)
... we have an idea lab? Since when? — The Hand That Feeds You:Bite 20:22, 12 July 2011 (UTC)
WP:VPI has existed since April 2010. Rd232 talk 23:33, 12 July 2011 (UTC)

Comment: 28 occurrences of 'Support', 42 occurrences of 'Oppse' - some with 'strong'. --Kudpung กุดผึ้ง (talk) 09:18, 12 July 2011 (UTC)

Really? I'd not counted! Well, if there's a 40% 'support' rate then the SNOW-close suggested by Camelbinky (talk · contribs) is obviously completely inappropriate. ╟─TreasuryTagsenator─╢ 09:47, 12 July 2011 (UTC)

In the spirit of brainstorming, then, let's refocus the core idea: (i) we want articles to have sources (ii) a fair proportion of new articles from newcomers don't have sources, and we should try to reduce that proportion. This, I think, few will disagree with. So what can we do? a) A perennial idea is to make referencing easier, by developing MediaWiki so that reference-editing is separated from editing the body text. Some bugs in this area include T8535 T8933 T22441; there are probably others, maybe more specific to that concept. b) Above, someone said "I would support it if there was a way to automatically remind users who created the article to provide at least one source (through software)." - this and other comments in this discussion prompts the thought, what about having a bot which thanks new users for creating an article, and provides links to relevant policies and help for improving the article? Reliably detecting whether a new article has sources is difficult automatically (and not always done right manually...), but including source issues as part of a generic "thank you" avoids the need for detection. There might be issues about how such "thank you"s interact with speedy tagging/notification, but I'm inclined to think it wouldn't be a bad thing. (c) I had more thoughts but I keep getting interrupted and now they've slipped away :( Rd232 public talk 11:45, 12 July 2011 (UTC)

One of the things I've been taking notice of recently is the ways we introduce ourselves to newbies. There are dozens upon dozens of templates all tossing different sets of guidelines at editors. I personally believe that there are only a few simple things to teach people the moment they create an account. The rest they will learn through trial and error, and observation. Now that I know how to use our cite X templates (which, as much as many would like to argue, are the best choice for standardization across the project), I don't find them all that difficult. Title, author, publisher, date, url/accessdate if its online, location of publication if its offline. This could be taught with a single informative template, automatically posted on a userpage upon account creation. "Here's the bare minimum requirements; now go experiment" - ʄɭoʏɗiaɲ τ ¢ 20:31, 12 July 2011 (UTC)
RD232: I really support the "way to indicate a reference in interface", but any automation has to actually do its work at article submission time, even if error checking is minimal. If there's nothing there, or the field is clearly garbage, we can ask them to try again, with little BITE and even with an immediate, helpful targeted bit of advice. But once they've hit submit and seen their article go live, many editors are gone forever. Any hope of getting them to participate in helping the article is passed, and any requirement that they do so to save the article or see it deleted (should they see our note) is BITE. I should take a look at those bugs, but I do believe even the simplest check (a reference field and a check that something got put into it) would be a step up from the status quo. -joe deckertalk to me 21:27, 12 July 2011 (UTC)
I don't believe that asking for a source will discourage genuine editors (who have already signed up) from creating new articles. THey can still create them, editors can tag the article or search for sources themselves, and hopefully the admin that goes to delete it in the end also examines the topic for an exemption and searches for sources. This isn't requiring a source for every edit to an existing article. - ʄɭoʏɗiaɲ τ ¢ 03:46, 14 July 2011 (UTC)

Break - discussion requiring one source

Can we differentiate between newbies/occasional users - who need varying amounts of help in getting articles up to WP standards; and 'articles created without references' - for which there may be a variety of reasons. The two are not necessarily overlapping. Probably many of us have occasionally engaged in the WP equivalent of 'pass the parcel' - we can see topic X is worth an article but can only put in the basics, leaving it to others to develop (e.g. the Pal Maleter article above requiring input from the Hungarian article); some articles are created in the expectation that garage band Y will become notable (but they never do) etc.

What is needed is a set up that encourages people to add reasonably relevant references, or at least give, in the talk page indications of where to find such (newbies, persons in a hurry etc.). Perhaps there should be a longer timespan between article creation and 'deletion for non-presentation of references': some will be developed appropriately (including e.g. redirects to relevant main articles), some will be removed for non-WP notability reasons/sent to other websites (relevant TV-program wiki etc.), and, after say 1 month, there is a procedure of contacting the article creator, general alert, deletion. Jackiespeel (talk) 09:44, 12 July 2011 (UTC)

"As an example" - English words with diacritics is a useful article but has no references. Should it be deleted? Jackiespeel (talk) 11:01, 12 July 2011 (UTC)

I would say it shouldn't be deleted. It is neither offensive, nor promotional or satisfies anything that would justify a speedy deletion. It just lacks references. I myself have sometimes provided sources for unsourced statements in articles created by other users, so this source requirement seems to have a damaging effect in this case and destroys an editing process that is simply partitioned into contributions by more than one editor (1. one writes content, 2. another editor provides a source. We may just be in the middle of steps 1. and 2. here). Toshio Yamaguchi (talk) 13:26, 12 July 2011 (UTC)

The point I was making - this is a viable/useful article that, according to the proposal, should be deleted (along with others equally viable/useful). And did my Pal Maleter article become viable #merely# because I included a link to a small pine?

There is a case for deleting #some# articles without sources or which have irrelevant sources. Probably more should be done to encourage people to variously add references, link up to existing articles (e.g. if providing reference materials such as the article previously mentioned), and provide explanations on the talk pages. Jackiespeel (talk) 15:04, 12 July 2011 (UTC)

Actually this proposal wouldn't delete that article; it already exists. However, if you went to start that article (at which point it would have been incomprehensive) after this theoretically took effect, you'll be told to find a source for it. If you refuse to and continue freely adding content (from wherever on the planet you've gathered it), then yes it should be deleted. Could be a copyright violation for all we know. Could contain made up words. There are many variable, but as it is I would be reading that article with a grain of salt and wouldn't consider it anything more than an unreliable list of supposedly English words. Is that the direction we should be aiming the project? - ʄɭoʏɗiaɲ τ ¢ 20:38, 12 July 2011 (UTC)

The diacritics article is perfectly respectable, with or without references. The two present references to the PM article are only of marginal relevance - but he was a significant figure (as anyone reading the book referred to, and others on Hungary 1956 will see).

Shall we say that there is a case for encouraging the use of references, whether by the creator of the article or others in the spirit of Wiki cooperation. Possibly there should be some form of dialogue - a stub with no comments on the talk page can be squashed after a day, an article indicated on the talk page as a work-in-progress/expansion of a component of an established and referenced WP article is given more time etc. Jackiespeel (talk) 21:03, 12 July 2011 (UTC)

Indeed. I'd hope all editors would exercise enough discretion that if an article is clearly under construction that it shouldn't be deleted... Only if it been made and left; that two sentence stub can wait until a day when it will be created with a source. There is no excuse not to source what you submit, newbie or otherwise, and no reason an article should be intentionally left, devoid of sources. There is no reason to rush to create stubs that don't explain anything about the subject, or exhaustive lists with no indication of where the items listed were found. - ʄɭoʏɗiaɲ τ ¢ 21:22, 12 July 2011 (UTC)
Also I'd like to note that according to the user feedback poll at the end of that diacritics article, it is considered pretty unreliable, garnering 2.1 out of 4.0 (though only 7 people have offered feedback). Statements like "Diacritics appear to be more acceptable in Canada than in the US, because in Canada anglophones are used to seeing French on food packaging" are absolutely rediculous, and shouldn't be there because its just some random person's opinion. - ʄɭoʏɗiaɲ τ ¢ 21:38, 12 July 2011 (UTC)

This proposal will get new users going down the right path early on. References are indeed required per WP:V. This is an academic reference work. Doc James (talk · contribs · email) 03:57, 13 July 2011 (UTC)

The diacretics article may need rewriting - but serves a purpose/provides an explanation despite having no references; the PM article is a lead-off from a main article (Hungarian Revolution 1956) which will have more references in which he will appear.

Shall we say that (a) 'most to all' articles should be referenced, but there are different levels of priorities for reference-provision - which may include linking to other articles; (b) some people, especially newbies, give priority to/are better at writing articles than providing references, while other editors are prepared to do the research as a priority; (c) that there should be a breathing space of varying length between article creation and removal for being non-referenced (and some may well be removed for other reasons) - and emphasis should be given to 'putting in references' (or even just links to other relevant WP pages where the references can be found).

And - Wikipecia is a co-operative project - development should take priority over deletion. Jackiespeel (talk) 09:08, 13 July 2011 (UTC)

The main issue that I keep coming back to with this proposal, in my mind, is that a reference does not necessarily equate to verifiability. Quite often the correlation between a reference and verifiability is obvious, but not always so. I see what this proposal is attempting to address, but it seems to be missing the mark. I see that there's already been some acknowledgement of that, but I don't see where that's been taken into account and processed into an updated proposal, yet. To me, I think that the "solution" to the problem being addressed here has something to do with New Page Patrol, rather that some new proposal. I don't see a "magic bullet" proposal that would be generally helpful with few side effects as a realistic possibility, here (but maybe I'm just lacking imagination?).
— V = IR (Talk • Contribs) 19:04, 13 July 2011 (UTC)

Amen and ditto to Ohm's Law.Camelbinky (talk) 01:43, 14 July 2011 (UTC)
A reference, more often than not, would provide where the editor acquired their information. A more experienced editor can judge whether that source verifies that the subject is notable, and/or not a hoax. A fake source may be provided occasionally, and I agree that this is one kink that needs a solution; however, something is better than nothing in a case like this. The reason I haven't updated my proposal is that it already has many votes against it. I'd rather take in as much feedback as possible, and craft a set of proposals regarding our welcome messages to newbies, discouraging new articles without sources and the method with which to achieve that. - ʄɭoʏɗiaɲ τ ¢ 03:17, 14 July 2011 (UTC)
I understand. Take your time on any updated proposal... no real rush, and all (no need to dither either, of course). I'm just... I'm sympathetic to the place that this is coming from, and I'm generally supportive of the underlying idea, I just think that this is the wrong track to take is all. Not a big deal, I just hope that I can help with getting to a good proposal. Something to think about: some sort of talk page notice urging new article creators to add sources? There's a long standing precedent against automated messages to new users of course (and there's DTTR...), but I don't necessarily think that is an insurmountable barrier.
— V = IR (Talk • Contribs) 03:33, 14 July 2011 (UTC)
I'm willing to support and strongly push it through to policy, ANY proposal that is short of deletion. Tagging, talk page automated notices, etc, all sound like good compromises. But this talk of deletion needs to please come to an end and work on other ways to address what some feel is a concern- that articles dont have sources. Notability is the ONLY reason for deletion, NOT quality. Change policy all you want that you are going to go around putting up for deletion any new article without a source, but once the discussion at AfD begins you wont win on the arugment of "it has no sources" and editors will quickly find it is a waste of their time that they have to fight to win each AfD, and this will go back to discussion and the policy changed. It isnt workable as a deletion concept. Can we work on a concept that could win consensus, because currently Floydian I fail to see where your compromising or changing of tact on this proposal is. Come to the table with me having dropped any mentioning of deletion and I will get you your policy change.Camelbinky (talk) 04:35, 14 July 2011 (UTC)

Our problem is that Wikipedia has become almost like a lawyer's office floor piled with folders of policies, essays, and guidelines from the door to the desk. We present our new users with such balls of fire walls of text that they don't bother to read anything at all. They don't even see the glaring edit summary box and other disclaimers at the bottom of the edit window, and that's just for starters. From reading through this entire discussion again, I see three sets of suggestions that further examination could be focused on:

  1. Twinkle could put a polite message on the creator's tp when a 'noref' or 'refimprove' tag is placed on the articles. Those who are serious about developing their article will react to that, and they often do to manual ones.
  2. The BLPPROD system could be extended for completely unreferenced new articles. This would demonstrate who the SPAs are and sort the wheat from the chaff.
  3. Those made by WereSpielChequers. it would need a lot of site engineering, and a series of interminable discussion, but ultimately IMO is the best solution. If after seeing all the warnings, the article still get s PROD/CSD, the creators only have themselves to blame.

At the moment, I'm not in favour of simply insisting through a poll that all articles have a ref right from the start, whether manually or technically. I am however concerned that NPP is a broken manual process and will remain so until we can either educate those who do it, or make NPPer a user right such as 'reviewer'. Irrespective of the numerical oppose/support words in bold here, there is a strong consensus that something on the lines of Floydian's request for feedback needs to be done, and discussion should now focus on the concrete suggestions that have been made. We're still a long way off having a buletted poll on them. --Kudpung กุดผึ้ง (talk) 11:13, 14 July 2011 (UTC)

I agree with your view of NPP, and largely with what is probably needed to fix it. As for the warnings and all of the project documents that go largely unread... I have to admit that my feeling there is "good, that's the way it should be". If I had my druthers, we'd get rid if all but the really important warning templates, and a good chunk of the pages in the Wikipedia namespace. But, that's probably a topic for another day.
— V = IR (Talk • Contribs) 12:10, 14 July 2011 (UTC)

Summarising the argument

(and keep this section break, given the length of the discussion)

Anyone wish to summarise the rest of the discussions - and what would be practical proposals for dealing with the issue?

ArchiveLinks Extension

Over the past month and a half or so I have been working on a Google Summer of Code project to archive external links and putting a link directly after them linking to cached content. At this stage of the project I am moving closer to something that has a reasonable chance at getting deployed and would like to seek wider community input. For a WMF deployment we were considering partnering with another archiving organization such as the Internet Archive. I recently met with their staff via skype to discuss the implications of spidering (meeting notes available here. It turns out that they are already working on making some content available in the wayback machine much quicker than it currently is. (On the order of hours or days, not months.) Anyways I would like to seek the community's input on such a feature and what people would think about this partnership and about changing the way external links display on wiki. A mockup of what the links would look similar to is available here Thanks, --Kevin Brown (talk) 04:31, 18 July 2011 (UTC)

Wikipedia is not a directory for external links.Jasper Deng (talk) 04:40, 18 July 2011 (UTC)
@Kevin, thanks very much for all your efforts. Linkrot is the biggest issue we have with verifiability. For several years, we have been concerned with references/citations going dead, so I'm very happy you are working on this issue. When we discussed this elsewhere, one of the concerns with using the Internet Archive's Archive-It service was that it was a pay service and other solutions were free. Have you and the IA people discussed the issue of cost? Thanks again for helping us tackle this major issue. - Hydroxonium (TCV) 05:12, 18 July 2011 (UTC)
@Kevin A big thank you also from me. If we could use Internet Archive's service I would be very happy. I am also interested in the costs of this. Would this service be offered to the WMF for free? Toshio Yamaguchi (talk) 10:51, 18 July 2011 (UTC)
Yes, the Internet Archive is willing to do this for free. They are interested in the links on Wikipedia because they believe they are some of what is probably the highest quality links on the internet. The way they currently crawl is kind of like a "shotgun" approach where they just go through the web and hope they get stuff that people actually want. --Kevin Brown (talk) 13:42, 18 July 2011 (UTC)
By the way, a list of pros and cons from other archive partners is available here. Wikiwix is currently archiving all new external links for the English Wikipedia, but I don't think that they support rearchiving content. Which is something the Internet Archive already supports. --Kevin Brown (talk) 14:38, 18 July 2011 (UTC)

Female actor vs actress

I have proposed to split Category:Actors into actors and actresses in the same way male and female singers are split. However, there seems to be dispute that actress is no longer an acceptable term. I said to me Judi Dench will always be an English actress and it would seem natural to categorize her as a Category:English actresses. I need some input here as to what is desirable.♦ Dr. Blofeld 17:19, 18 July 2011 (UTC)

Add Contributions as a third tab in Vector

At the moment, the top of user pages show two tabs: User page and Discussions. I feel that Contributions should be added by default as a third tab, as it is a likely destination when people go to user pages. Currently, the only way to access someone's contributions is through a link in the Toolbox, which is very hard to find and invisible by default.

Alternatively, could a gadget that facilitates this be included in Special:Preferences? wctaiwan (talk) 13:15, 18 July 2011 (UTC)

I'm not sure if that's necessarily the case. Sure, editors look at contributions, but I'd hazard a guess that readers tend not to. Our user interface has to be orientated towards our largest stakeholder group - our readers - which is why the history tab (also very useful for an editor) is slightly hidden away. This could serve to confuse or flummox readers who aren't quite sure why there's this big page of seemingly randomised entries. Ironholds (talk) 13:23, 18 July 2011 (UTC)
The history tab is hardly hidden away—in fact, I think it'd be fine if Contributions was given the same treatment, the only issue being that it'd break the universal consistency of that part of the navigation across the site, which may bother some people. Also, someone who looks at user pages is likely not just trying to read articles, so the risk of confusion is inherently lower. wctaiwan (talk) 13:33, 18 July 2011 (UTC)
Ah, but there's a problem with this comparison: it presumes that readers spend a lot of time on user pages. If we had another tab in vector for user contribs only on user/user talk pages, I don't see how that would affect readers, but it probably would aid editors. Anyway, this probably needs to be proposed directly to MW devs. —Tom Morris (talk) 10:02, 19 July 2011 (UTC)
You can turn on a gadget that gives semi-direct access to the contributions at the top of a userpage along with other options as well. On the gadgets tab of preferences, the 4th item under user interface gadgets is: Add page and user options to drop-down menus on the toolbar. It gives a couple of extra dropdowns on the right side and contributions is one of the items on the list. GB fan please review my editing 17:34, 18 July 2011 (UTC)
I think we want to encourage our readers to look at the contributions, because the history of an article is, together with the talk page, the best evidence of its level of reliability, and having such a tab by default would call it to their attention. DGG ( talk ) 21:58, 18 July 2011 (UTC)
I should clarify that my intention behind this proposal is to help inexperienced editors, not experienced ones. Experienced editors wouldn't benefit much because they already know where the link is, but as it is now, inexperienced editors (with no gadgets) would have difficulty just trying to reach the page. So extensions that give access to the page, while helpful to me, aren't exactly solutions to this problem. wctaiwan (talk) 14:07, 20 July 2011 (UTC)
I agree this would be handy. In Monobook too. In the meantime, this is the script I use to show such a tab. --Cybercobra (talk) 10:40, 20 July 2011 (UTC)

Click tracking template

The current WMF click tracking software requires extra configuration and doesn't provide useful analytics. Thus, I propose we create a template that allows tracking of certain links, both internal and external.

This would be useful for: Template designers who would better understand the effects of different layouts. WikiProject would get to know their audiences better. And finally, GLAMs who have been requesting more detailed analytics then the simple traffic counter in (as discussed at m:GLAMcamp NYC). Their charter typically requires educating people in a particular geographic region thus can't justify spending money that doesn't further their charter.

Now for the technical details: The software would be run on the Toolserver and use custom software or one of the FLOSS analytics packages (like Piwki). It would be best implemented using a wrapper template (<span class="trackme">[[link...) which some JavaScript code would "ping" the Toolserver with an image request when the link is clicked. This method is faster and doesn't alter the URL like the typical redirect method. — Dispenser 13:50, 20 July 2011 (UTC)

Enable LiquidThreads

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.


LiquidThreads should be enabled on the English Wikipedia, even if only in some limited fashion (User talk pages only, for example).
— V = IR (Talk • Contribs) 11:20, 7 July 2011 (UTC)

Awful. Really, really horrible. Loses all the at-a-glance overview, especially for example when needing to see all the uw and block templates on a user page. Kudpung กุดผึ้ง (talk) 08:21, 10 July 2011 (UTC)

Can we please close this discussion? LQT3 doesn't exist yet, and LQT2 is not going to be enabled here. What is being discussed is enabling a system which not a single person here has even a basic understanding of, because it doesn't exist. --Yair rand (talk) 08:31, 10 July 2011 (UTC)

Andrew Garrett 2011-01-21 19:49:08 UTC

Hi all,

I've been thinking about this and having discussions with Erik, Alolita and
others.

As you know, LiquidThreads is undergoing major re-engineering, including
updates to both the architecture and the user interface (documentation is being
uploaded to MediaWiki.org as it is finished). You can find full details of this
project at MediaWiki.org. [1] Having the old version of LiquidThreads in
production adds complexity to the migration process that will occur once
re-engineering is complete. It also means that engineering time would need to
be spent supporting and maintaining the older version. This would distract from
the development work that is currently in progress on LiquidThreads. Being the
lead developer for LiquidThreads, my priority remains to focus on the
re-engineering work that we are doing, so that we can start piloting the new
version as soon as possible (hopefully by the end of March).

Accordingly, it is our decision that further pilot deployment of LiquidThreads
instances is placed on hold for the time being. LiquidThreads re-engineering
will hopefully be finished in two to three months, and at that point we will be
very pleased to roll out pilots to additional wikis.

Thanks for your understanding,
Andrew

[1] http://www.mediawiki.org/wiki/Extension:LiquidThreads/Q1_2011_re-engineering
Now can we please close this utterly ridiculous discussion? --Yair rand (talk) 12:35, 20 July 2011 (UTC)
The only thing that's ridiculous here is the rather extreme defensiveness that yourself and others have about these subjects. You want to shut down discussion about this for a while, fine. I'll just wait and start a newer topic in a few days. What's next, trying to get me blocked for daring to bring up LQT? Sheesh. Get a grip, man.
— V = IR (Talk • Contribs) 04:04, 23 July 2011 (UTC)

Suspend development of LiquidThreads

The Foundation is paying for this extension to be developed, so if it's never going to serve us then should we tell the Foundation to suspend development of LiquidThreads? Is the extension completely irredeemable?
— V = IR (Talk • Contribs) 17:29, 13 July 2011 (UTC)

LQT2 stopped being developed a while ago, I think. The English Wikipedia community has never seen LQT3, and the above discussion is no indication of whether ENWP will support it, and even if the community made it absolutely clear that the ENWP community would never go along with its introduction, the English Wikipedia is not all of Wikimedia. The WMF isn't going to halt everything because one random large community says "You know what, we don't think we'll find it useful". Sheesh. (Anyway, there's a good chance that enwp will have it enabled by the foundation, consensus or not.) --Yair rand (talk) 07:58, 14 July 2011 (UTC)
(Giving examples for a second: Despite the fact that the current version is horribly buggy, and nowhere near complete, The Czech, Portuguese, Hungarian, French, Swedish, Chinese, and Hindi Wikipedias, along with a dozen sister projects, all requested for early implementation of the unfinished version of LQT2. --Yair rand (talk) 08:11, 14 July 2011 (UTC))
Liquid Threads is crap. I've tried using it on Metamediawiki.org (to complain about the Feedback boxes), and it's crap. It's crap, it has been crap, and it will continue to be crap. Crrrrrrrrrrrrrrrrrrrrrrrrrrap. Festering putrid rancid maggot-infested crap. Don't implement it. DS (talk) 23:47, 19 July 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WikiLove feature vs "traditional" awards and barnstars

Maybe its just me, but why does WP:PUA not contain a single mention of the WikiLove feature? Also, is there actually some documentation regarding this feature here on EN:Wiki? Furthermore I am confused. Is the old system (manually giving barnstars and stuff) now officially obsolete with the introduction of the feature? Could someone perhaps write an essay or something explaining when to use the feature and when to use "the traditional method"? Toshio Yamaguchi (talk) 13:35, 21 July 2011 (UTC)

This is just my opinion, as a user of both systems, but there isn't an explanation of that because it's entirely according to your preferences. :) The old system is not obsolete. You can do it the old way; you can do it the new way. However you want to do it is just fine. (I use both because the barnstar I award most often in my volunteer work, for copyright cleanup, is not in the WikiLove feature. But I do love the feature for customized awards, which I enjoy giving.)
I'm not sure why it would be included in WP:PUA, specifically, as this is a collection of awards, but the documentation is linked at WP:WIKILOVE. There isn't any documentation on en Wiki that I know of, but it's on media wiki at WikiLove extension. :) --Maggie Dennis (WMF) (talk) 13:43, 21 July 2011 (UTC)

Proposed expansion on current protection

I apologize if this is in the wrong section. But here's an essay/proposal.

Vandalism on articles especially BLPs are still present. Pending changes (PC) to some extent has been used to try and reduce vandalism on high profile BLPs. For example, the article Justin Bieber still receives high levels of vandalism despite being semi-protected. PC level 2 was introduced to help some of the vandalism but was not very successful in stopping/reducing the amount of vandalism.

Autoconfirmation is very easy attain and it's supposed to be. Long-term sockpuppeteers have taken advantage of this and have easily broken through pages that have been protected as a result of sockpuppetry. For example in List of Bob's Burgers episodes, several socks were successful enough in getting through the protection. Garbagecanyeah (talk · contribs) is a prime example of socks taking advantage of this relative ease of attaining autoconfirmation. Time and time again, long-term sockpuppeteers have continued to abuse the ease of autoconfirmation. For example, we already have a special user who abuses this and gets through semi-protected pages very easily.

Though rarely used, full protection is used to help deal with the sockpuppetry and vandalism from autoconfirmed accounts. Due to pages being fully protected, only administrators may edit the page, drastically preventing any kind of improvements or changes that can be done those articles.

Long-term and trusted editors should not be blocked from editing due to vandalism and/or sockpuppetry. I believe that an intermediate protection is needed to help deal with situations where full protection would be used for sockpuppetry (this especially) and vandalism. Though PC may come to mind, PC does not physically prevent autoconfirmed accounts from editing a page and the intended edit is still made. To help with the concerns above, I am proposing the split of our current semi-protection capabilities:

Semi-protection 1 (SP1)

-Account has a minimum of 10 edits and is at least 4 days old
-Or account is confirmed

Semi-protection 2 (SP2)

-Are either account creators, administrator, autoreviewers, reviewers, and/or rollbacker
-Or a new userright if the community wishes.
Perhaps Veteran or Veteran Editor?
-And/or have at least X edits (for those who do not want to be associated with userrights)
Suggestion of 1,000 edits

Requirements for new userright if chosen

Suggestion of at least 1,000 edits
Suggestion of at least 3 months old
Suggestion of at least 500 mainspace edits

Usage

What do you guys think? Elockid (Talk) 03:32, 16 July 2011 (UTC)

No full protection won't get affected. Full protection doesn't address pages that are repeatedly and consistently targeted by socks and vandals though, even the ones that are semi-protected indefinitely since they are only used in short term durations. Elockid (Talk) 04:08, 16 July 2011 (UTC)

<talk> 15:21, 17 July 2011 (UTC)

@Eraserhead: PC is in limbo and it looks like it is going to stay that way. There's just no consensus to try and re-implement it. PC has been shown to be limited in preventing/reducing vandalism (assuming this since a lot of the supporters of PC believe that it prevents/reduces vandalism). PC has fared even worse with articles of high targets of vandalism/sockpuppetry. This is mostly for PC1. Can't really say anything for PC2 since this wasn't really tested.
@TheDJ: Though the encyclopedia is an open project, we have established protection levels for a reason. Yes, vandalism will be present, but the amount of vandalism can be reduced without having a detrimental effect to the project. I'm not requesting for a total block of vandalism. As vandals and socks get more sophisticated, it gets harder to prevent/reduce the amount of vandalism. The current protection capabilities are not adequate enough in my opinion to address the issues above. We've tried edit filters in socking cases and sometimes with vandalism unrelated to socking as a way to reduce these types of edits, but most have been found to be ineffective along with the current semi-protection levels. Also, many people in the encyclopedia share the idea that some sort of protection level is needed for BLPs. It can be considered a problem to others. Elockid (Talk) 22:06, 17 July 2011 (UTC)

The amount of edits can be discussed. But 100 seems to be fine. Elockid (Talk) 22:15, 17 July 2011 (UTC)
A well-known problem is folks who arrive Minerva-like, make a hundred innocuous edits (frequently in batches of ten or more in a period of minutes to a single article, or a big batch of punctuation changes etc. to reach the well-known magic number). Is there any way of sorting such folks out? Collect (talk) 22:33, 17 July 2011 (UTC)
I suppose an edit filter could be set up to track such activity... --Jayron32 05:14, 18 July 2011 (UTC)
I definitely agree that some kind of software attempt to detect bad-faith attempts to get enough edits would be a good idea. This applies whether or not the extra protection level is added - it would be useful for detecting socks going for auto protection. Wikipedia:Edit filter may be part of the solution... not sure. We could make the edit filter (or something) set a flag on an edit if it was deemed minor. This flag would not be visable to most users and would be distinct from the minor edit flag that can be set by the user. Lets call it autominor. A user would need to get 10 non-autominor edits to be autoconfirmed (or more for a higher level, if that's what we go for).
Yaris678 (talk) 11:32, 18 July 2011 (UTC)
I think a higher limit like 1000 edits and 3 months is better for an intermediate level of protection. Or even a bit higher. It needs to be something where a person would definitely need to plan it in advance and do a lot of work plus that number of edits means there is a good chance their other sockpuppets can be detected and removed so they have lost three months of work trying to work their way in. Overall I think this is a good idea and could substitute in general for the current use of the high level of protection where only admins can change an article. Dmcq (talk) 11:52, 18 July 2011 (UTC)
Support I like this idea a lot. We'd need to spend a bit more time, and obviously much wider, thrashing out the requirements (assuming the whole principle is agreed) as I think 1000 is too high (100 seems more reasonable to me but with a time requirement as well). Definitely it would need to go through RPP, and we'd have to make sure that we got our guidance clear on what should receive a level 2 protection, and how long.
From a software side, it would be very very helpful if we could specify what happens after protection expires, ie does it drop to level 1 or unprotected, so that we don't suddenly get sensitive/target articles being unprotected automatically.
While 100 might not completely eliminate the problem its highly unlikely that any move will be entirely successful. What it does do is give a significantly higher point of entry than 10 does, and one which would be much harder to pull off repeatedly to repeatedly damage articles. -- Eraserhead1 <talk> 22:02, 20 July 2011 (UTC)
I certainly don't think it should be presumptive in any way. Requests should be made at RPP, and admins patrolling there should make a decision on what they're seeing, as as now, just with another tool available if necessary. GedUK  12:12, 22 July 2011 (UTC)
IP bans almost never work for persistent individuals. Most ISPs are dynamic and it can only take 2 seconds for a sock/vandal to repeat what they were doing. If it was so simple as placing an IP ban as you say, we wouldn't have the amount of cases at SPI as we have now nor would we have a WP:Long-term abuse. Furthermore, due to the dynamic nature of ISPs, rangeblocking is almost not possible. For IP bans to actually work, massive collateral damage is needed and in more extreme cases, blocking half or an entire country is required. Most admins stray away from rangeblocking due to the possibility of massive collateral damage. We have tried to develop ways in the ways of edit filters to stop socks and vandals, and if you see the edit filter list, primarily the later filters, most of them are disabled because they are not doing their job. In general, blocks have little to no effect on persistent individuals evading their bans and/or blocks. The same can be said about our current semi-protection capabilities. See the example I gave above. What other means do we have then?
The proposal isn't meant for POV pushing. It's to deal with long-term abusers and places where high levels of vandalism is still present even if semi-protection is already present.
10 edits is fine for many of the simple vandalism problems. But, this isn't the reason for why I am proposing this. Like full protection where it used sparingly, my proposed usage is for what I said originally and in point 2. We'd probably have a policy to establish when to use it anyways. Elockid (Talk) 23:30, 26 July 2011 (UTC)
I can't see anytime regular semi-protection wouldn't work where this would be much better. All I can see is a policy that puts a pointless stigma on new users. I have yet to see a serious vandal who had more than 10 edits, even once on my time at wikipedia. Those few that do can easily be handled by page watchers. This is pointless and only serves to make wikipedia more insular and less an encyclopedia "anyone can edit." The conflict with the core mission of wikipedia is what's wrong here. i kan reed (talk) 13:55, 27 July 2011 (UTC)
Are you familiar with by User:Grawp by chance? How about the example I gave, List of Bob's Burgers episodes, where clearly semi-protection did not work and full protection lead to complaints? Elockid (Talk) 14:05, 27 July 2011 (UTC)
And this would stop this kind of motivated, technically proficient vandal how? There appears to be far more willingness for this kind of attack to select different articles instead. I don't see this fixing that problem, and unlike standard semi-protection this policy would make it easier to vandalize pages as quite a few fewer good faith editors would be able to revert vandalism. i kan reed (talk) 14:18, 27 July 2011 (UTC)
Long-term abusers like Grawp have a similar MO of creating multiple accounts/sleeper socks at any given time and make test-like edits in articles in a short amount of time. Usually, unnecessary punctuation, letter changing, formatting, etc. removals/additions or "playing" with their userspace are made. When the time is right, they make lots of edits in a couple of minutes using these sleeper accounts. For LTAs like Grawp, CUs cannot find the other accounts they made because they are either stale or were using multiple proxies leading to inconclusive results.
With an increased protection, making ten edits to get through semi-protected articles like the account Rubytuesdaysrocks (talk · contribs), (his edits to his userpage have been deleted under G5 but 10 nonsensical edits were made to their userpage between 22:06 to 22:07 UTC), isn't so simple and depending on the specifications, make it more time consuming/significantly harder for these users. In just 2 short minutes, the sockpuppeteer manage to gain autoconfirmed status without even trying. This is the big and recurrent problem I am addressing here. Autoconfirmation is just too easy for these users. I don't think autoconfirmation should be any more difficult to attain to address these problems. By having an advanced level of protection, long-term abusers actually have to try harder to get through their targets. It just won't take 5 minutes or less to abuse the system. The increased difficulty may deter them more.
As in List of Bob's burgers episode, we could have other editors other than just admins who can edit page. If full protection is used during these types of situations, the only editors who can edit the page are admins, making it much harder for good faith editors to remove unconstructive edits. Full protection when used due to vandalism/sockpuppetry limits the amount of edits from good faith editors more than a protection level where more than just admins can edit a page. Elockid (Talk) 14:58, 27 July 2011 (UTC)
Yes, and that makes it seem like all you're going to do is create an edit count arms race you can't win. As long as there exists a way to edit without being detected as a vandal, someone will be able to automate that process if they are technically proficient enough. Sitting on account for 6 months is not really any different than sitting on it for a week. 1000 fake, unremarkable edits can be generated as easily as 10. The only difference is that a legitimate 1000 edit count is a lot harder to come by. The proposed measure won't stop this behavior. i kan reed (talk) 15:06, 27 July 2011 (UTC)

How many people do you know are technically proficient enough to make that many edits? I don't know very many who can code. The statement, 1000 fake, unremarkable edits can be generated as easily as 10, is not necessarily true. Most people do not have the technical proficiency to make 1000 edits in a short period of time. Unapproved bot-like accounts making bot-like edits get blocked way before they reach a 1000. Secondly, plenty of people don't have the patience to do make that many unnecessary edits. If they do have the patience, it will take them a lot longer and a lot more effort if they do not have the technical proficiency to edit a page with increased protection. If something is made more difficult, there is a greater chance that the person will stop. Making 1000 edits takes a lot more time, effort, motivation and education (for technical proficiency) than users who make 10 edits, thus the italicized statement isn't necessarily true. Again, most people do not have the technical proficiency to make a massive amount of edits.

Many of the LTAs I've seen do not have this technical proficiency. Most of the LTAs socks get blocked before they reach 500 edits. Once in a blue moon, there are those that make it past 500 edits but there are not very many. For example, how many vandalbots have you encountered? Even as a user who primarily handles with vandalism and long-term abuse, I have yet to see vandalbots become a daily or weekly problem because many people don't have this kind of proficiency. This all goes back to what I said about unapproved bot-like accounts. Protection generally doesn't stop all vandalism. It only limits it. Like I said previously, I am not asking for a total stop to these edits. I am asking for better ways to limit these repeated edits. We do not have any tools that are adequate enough to even dent a sizable portion of our long-term abusers. Elockid (Talk) 18:21, 27 July 2011 (UTC)

Image placeholders

A long time ago in 2008 there was a discussion about image placeholders with the result being that there was a recommendation that image placeholders should not be used on article pages. Is there still a consensus that image placeholders should not be used? -- WOSlinker (talk) 18:36, 17 July 2011 (UTC)

Note this discussion seems to be related to Wikipedia:Bot owners' noticeboard#Image placeholders, so the real question is not only "should image placeholders be used?" but also "should a bot now go through and remove image placeholders from every article where they currently exist?". Anomie 19:48, 17 July 2011 (UTC)
Yes but let's solve each problem separately. -- Magioladitis (talk) 21:12, 17 July 2011 (UTC)
Looking at the discussion back in 2008 I agree with the arguments against the use of placeholders. In the following years there was also a demand of "less tags that state the obvious". One example is the deletion of "expand" tag because it's automatically implied that all pages need to be expanded. The same holds here. Wikipedia is not in 2008 anymore. It's obvious that if there is a page of a person with no photo, a photo is needed. No reason to state that with a big blank image. -- Magioladitis (talk) 21:12, 17 July 2011 (UTC)
In the case some page needs a photo more urgently than others, the wikiproject take care of it by adding |needs-photo=. Right now the use of these placeholder images is completely random. It's especially annoying when uses in stubs or when the infobox is empty consisting only from the person's name and the placeholder. It's interesting that that last discussion concluded that a wider use of placeholders should be avoided but we still have some editors that add generic infoboxes in pages adding placeholders with no discrimination probably because they just copy blank infoboxes from documentation. -- Magioladitis (talk) 08:59, 18 July 2011 (UTC)
If we are removing the placeholders then we should set the needs-photo flag on the talk page so that there is some indication that a photo is required. Keith D (talk) 19:02, 18 July 2011 (UTC)
If an article has no image, then it is pretty much implied that an image is required. Resolute 19:53, 18 July 2011 (UTC)
It is useful as it puts it in the appropriate image needed categories. Keith D (talk) 21:34, 18 July 2011 (UTC)
That presumes the categories themselves are useful. As with my other example below, you might as well put every non FA article into Category:Articles needing improvement to Featured Article status for all the use such categorization is. Resolute 02:57, 19 July 2011 (UTC)
I say to remove them all. They are as ridiculous as putting a line that says "Do you have more text to add? If so, place it here!" in the middle of every article. Resolute 19:52, 18 July 2011 (UTC)
This seems to be ideological fight between people who like to keep things simple and pin and standardise them, and people who like some freedom for creativity so sequential improvements can happen. No point in arguing with what are at base are psychological positions, and probably ultimately genetic dispositions. But this matter could be placed on a practical footing, so there are facts to consider instead. Can a script be written to compare, on a time basis, articles with placeholder images against those without, and see what differences there were in the numbers of images subsequently uploaded? --Epipelagic (talk) 04:36, 19 July 2011 (UTC)
It would be very good of we had something like this. My experience says that this placeholders helped a little or at all. I think we end up to the same discussion as with "Expand" tag that was deleted. There was no proof that pages with the expand tag improved faster than the others. We expect that a random editor will add random information to the a page based on their knowledge and not on tags unless the instructions given to the tag are very specific. Generic tags are useful for coordinated efforts and usually this is covered by Wikiprojects. -- Magioladitis (talk) 11:25, 21 July 2011 (UTC)
Well the bottom line is whether or not place holders get results. If we get a lot of useful images using placeholders that we wouldn't get otherwise, then we should use them. Otherwise we shouldn't. Unless we know the facts this debate is a waste of time. There is no reason why a competent programmer couldn't write a program to settle the issue. Alternatively, we could do it manually. Say, select 2000 BLPs at random without photos. Of those select 1000 at random and add placeholder images. Then check back after say 6 months, and see how many photos eventuated for the two groups. Without that information, this debate is not a real debate. In the end it just will go the way of the most bulldozing and opinionated participants, smothering the rest with empty burblings, the way most Wikipedia policy debates go. --Epipelagic (talk) 11:36, 21 July 2011 (UTC)
Instead of waiting 6 months we can easily do it by checking pages that still have/had image placeholders. -- Magioladitis (talk) 14:11, 21 July 2011 (UTC)
We could do it that way, but I doubt the samples would be random. Presumably there are selection biases when editors decide to add place holders, such as a bias toward higher profile articles (or the opposite). But a bot could be programmed to randomly select say 2000 articles that needed photos, perhaps on living people. It could then add placeholders to every second article, and keep a record of the articles without placeholders as the control group. It could then be run again say six months later to see how many images turned up in the two groups. That would be pretty bullet proof, and easy to program. A similar approach might also work with other issues, like the effectiveness of "expand" tags. Instead of researching issues where it is appropriate, Wikipedia tends to "debate" them. A lot of the activity on Wikipedia noticeboards is spent this way. The absence of relevant facts seems attractive to people who enjoy emoting and expressing strong opinions. Personally, I add placeholders to new articles I write about living scientists. My assumption is that at some stage, the scientists or their acquaintances will look at their page on Wikipedia, and see the placeholder. They are really the people I want to get the message to. It is less likely they will look at the discussion page and see a request there. But I'm just guessing. I don't know whether it is a good approach because the research is not there. --Epipelagic (talk) 05:03, 23 July 2011 (UTC)

I was very disappointed when I first found out that the community had decided against placeholders. I have access to OTRS and the photosubmissions queue pointed to by Wikipedia:Contact us/Photo submission. There was a backlog of requests that I handled when I first got access and many of them were from agents for subjects or the subjects themselves trying to submit photos that they had created as works for hire or by family members. Now that the backlog is gone, there are very few submissions sent in. It's important to think about the people we have articles on who would like to have their page display an image. A category or some obscure tag on a talk page they don't visit won't help. Yes, they can see that the page needs an image. But they simply have no idea how to provide one.

These placeholders aren't for editors who obviously know how to add images and would understandably be annoyed by them. They're useful for a subset of articles (BLPs) whose subjects rarely edit Wikipedia. Yes they are still extensively used and may not have gotten many images submitted, but that is because they are not used effectively. The placeholders told people to click on them and directed them to the local upload form. Many may very well have been marked as lacking permission unless an email was sent in, rather than just having them email us from the start with the photo and license and any details could be worked out over the same communication medium. The placeholders should point to Wikipedia:Contact us/Photo submission rather than the intimidating upload form. "Customer service representatives" like myself can make sure the proper copyright owner is providing the release, upload the file with the OTRS tag, and edit the article to include the image, eliminating frustration and barriers that prevent high quality images from being submitted and retained. – Adrignola talk 19:01, 23 July 2011 (UTC)

^ this. When I first joined OTRS and dealt with permissions queues, I handled several tickets where article subjects would send in a photo because they saw the placeholder on their article. At the very least it might be beneficial to allow placeholders on BLP articles and properly point them (as Adrignola said) to the photo submissions directions page. Killiondude (talk) 19:46, 23 July 2011 (UTC)
I've always been of the opinion that we should use the placeholders, myself. I think that it's a mistake not to, primarily for the reasons that Killiondude and Adrignola have outlined above.
— V = IR (Talk • Contribs) 22:17, 23 July 2011 (UTC)

Placeholders were designed to target new users and to that extent they did work since they effectively put the user onto rails in terms of the upload process. However wikipedia no longer allows image uploads from new users so if you wanted to restart the system you would have to rebuild it so the uploads took place through commons and I've never got round to doing that.©Geni 23:34, 27 July 2011 (UTC)

Bot for mirroring discussions across wikis

We currently don't have cross-wiki watchlists (T5525) or crosswiki transclusion (T6547, T11890). This inhibits communications across wikis (eg Commons/en, Meta/en, other language Wikipedias, etc). So I'm thinking, if we had a bot which mirrored pages from Wiki A to Wiki B, then editors who primarily haunt Wiki B would be able to get updates and messages, at least. For simplicity, I'm thinking the mirroring would be one way, so that editors at Wiki B would need to go to Wiki A to reply (I think trying to mirror in two directions would be too error-prone). Particularly obvious use cases would be editors mirroring their user talk pages from Wiki A (eg Commons) to Wiki B (eg en.wp) [albeit that particular use case is slightly superseded by Email notification]. I'm sure we can think of others. One particular use case would be mirroring templates - since smaller wikis often use copies of larger wikis' templates, and then don't benefit from updates [that might seem an unfamiliar problem to en.wp users, but it's quite real].

I was thinking there'd be two templates to tag pages with: ((crosswiki master)) for Wiki A and ((crosswiki slave)) for Wiki B, with the latter page protected. (The master template would tell the bot where to mirror to, and the slave template give an explanation that edits only occur on the master page, and link to that page.) Updates would be perhaps daily (ideally configurable per page in the template). There might also be a facility to mirror whole classes of pages (eg all those in a category). Now, I appreciate that this bot is a bit of a monster task... maybe cross-wiki transclusion would actually be easier to implement?? PS This idea was originally in a different section in a more specific form, and that's not proven helpful for discussing whether the basic principle is a good idea. Rd232 talk 14:20, 27 July 2011 (UTC)

Math rendering

Just an FYI for here: There's an ongoing RFC on the Wikitech-l list regarding changing how <math> renders. The thread can be seen at: Should we drop the rendering preferences for math?. There's also some discussion at Wikipedia talk:WikiProject Mathematics#RFC: Should MW developers drop the rendering preferences for math?, which notes that feedback is requested at mw:Requests for comment/Reduce math rendering preferences. Regards,
— V = IR (Talk • Contribs) 14:41, 27 July 2011 (UTC)

Raise the rangeblock limit (especially for IPv6)

After browsing the MediaWiki's developer wiki (mediawiki.org), I found out that the limit is a configurable setting in the configuration file (LocalSettings.php). As discussed earlier, it may be (but rarely) useful to block ranges larger than /16 in IPv4, especially to deal with LTA. But my main concern is with the IPv6 setting. In the future, organizations and end-users will receive /48's or larger typically, and we are not going to block 65536 /64 subnets (the current limit for IPv6) at once in order to block a single user. Therefore, I am making the following proposals:

  1. Allow rangeblocks of up to /12 in IPv4;
  2. Allow rangeblocks of up to /36 in IPv6;
  3. Require community consensus for rangeblocks larger than /16 in IPv4 and /48 in IPv6 at either ANI or a new noticeboard except for highly exceptional abuse incidents, and all such blocks must be discussed, even exceptional cases, with justification. If none is provided within 5 minutes of the start of the block, I think it's fair that a bot unblock immediately. The discussion must consider all collateral damage possible, and should require the same kind of % of support !votes as RfA and other !vote-driven processes.

The proposal may not be relevant now since Wikipedia is still not on IPv6, but, it must be discussed, and implementation of IPv6 will be in the future. However, I ask that the proposal be canceled if the sysadmins say it will require schema changes in the database.Jasper Deng (talk) 04:26, 11 July 2011 (UTC)

Note: I ask that anyone who !votes here read IPv6 address allocation to understand the need for a larger rangeblock limit in IPv6.

Please cast 3 separate !votes, one for each proposal.Jasper Deng (talk) 19:55, 11 July 2011 (UTC)

First proposal !votes

But how would the policy that requires a community consensus stop an admin from blocking a /12 in error? If they block more then they intended, a policy telling them not to wont help. Is there a way to require that before an admin blocks large then a /16 some type of notification must be acknowledged detailing the community consensus rule? Monty845 05:26, 11 July 2011 (UTC)
Looking at this, it may then be appropriate to limit the blockage to specific users, perhaps called "Large range-block clerks". It doesn't have to be a technical group, but something like the SPI clerks. The admin would have to cite a diff to do that. The edit filter, I believe, can be used to tag such blocks, and a bot can be used to undo those tagged.Jasper Deng (talk) 05:29, 11 July 2011 (UTC)

Second proposal !votes

Right, if an end user could be getting anywhere between a /64 and a /48, blocking a /48 in IPv6 could be the same as blocking a single IP in IPv4. Monty845 17:34, 11 July 2011 (UTC)
Exactly why I am asking for raising that limit (consider changing the vote). The reason I want /36 though, is because some organizations may get extremely large allocations. ISPs get /32s.Jasper Deng (talk) 17:43, 11 July 2011 (UTC)
It seems highly highly unlikely that any organisation will get a /36. -- Eraserhead1 <talk> 22:09, 11 July 2011 (UTC)
Actually, it is. The US DoD (Department of Defense) has 14 /22s (~/13). The reason why I chose /36, in any case, was because some ISPs may choose to very dynamically assign subnets from their entire block (or a slightly smaller one). The spirit of the proposal though is that a /64 subnet is a too-low maximum block length.Jasper Deng (talk) 02:30, 12 July 2011 (UTC)
You realise you only need more then 192 sites (with none extra large) to receive a /36 by current RIR policies right? [4] And any ISP including small ISPs who deal directly with the RIR will currently receive a /32 by default (see earlier ref and [5]) Nil Einne (talk) 12:58, 18 July 2011 (UTC)

Sub-proposal

/36 seems a little excessive. This subproposal is to change the limit to the more reasonable /48. This proposal is designed to replace the 2nd proposal.Jasper Deng (talk) 02:43, 12 July 2011 (UTC)

Third proposal !votes

Discussions should never be limited to admins, as remember, admins are not super users with extra authority, they are simply users whom have been entrusted with the extra bit. Regular users are able to do anything that an admin can unless it requires that extra bit, and a discussion certainly doesn't. Monty845 17:37, 11 July 2011 (UTC)
Limiting discussion to only users who know about rangeblocking is sensible to make sure those discussing are competent. It's perfectly possible to let other users comment separately on it.Jasper Deng (talk) 17:44, 11 July 2011 (UTC)
I disagree that having the admin bit is a good proxy for understanding of range blocks. I suspect there are many admins who do not, and many non-admins who do. Monty845 17:49, 11 July 2011 (UTC)
Which is why I am not only thinking about admins. I'm thinking a separate user group can be made.Jasper Deng (talk) 17:50, 11 July 2011 (UTC)

General discussion

Paradoxical support. I used to be against range-blocks by abusive bullyboy admins. Now I like them. Why? CAuse I think WP should go registration required anyhow. REally sick of IPs messing with decent articles. Makes me not want to write here, even. So...let's ban often and ban hard on IPs.TCO (reviews needed) 05:15, 12 July 2011 (UTC)

Except that banning IP's makes it harder to know who's edits to check for vandalism ;). -- Eraserhead1 <talk> 18:48, 12 July 2011 (UTC)
I know you are joking around. But to discuss. There has been a lot of research done on online behaviors and people take some identification with their online personas. Of course you may have sock sock-masters, but those types are probably already doing that. And it really is a bit of a hurdle for the person who just wants to put "lame" on a politician's page, to have to do the filling out the registration.TCO (reviews needed) 18:54, 12 July 2011 (UTC)
There is a Javascript-based gadget that can check the contribs of an IP's range.Jasper Deng (talk) 01:11, 13 July 2011 (UTC)
X! has a better one. GFOLEY FOUR!— 20:51, 26 July 2011 (UTC)

Isn't there also a technical reason why rangeblocks larger than /16 are allowed, i.e. server load issues? I would think that, in order to go through all those IPs on a /16 for instance would be quite a bit for the servers to handle. –MuZemike 06:02, 15 July 2011 (UTC)

The performance impact of the maximum rangeblock size is quite difficult to calculate, but it is certainly not linear in the size of the block. And considering how small a part of MW as a whole the relevant SQL query is, I'd say the performance impact of increasing the maximum rangeblock size is pretty trivial. (also)Happymelon 07:00, 15 July 2011 (UTC)
I would also believe that. There must always be a SQL query just to determine if the user is blocked when the Edit tab is clicked, regardless of user type.Jasper Deng (talk) 04:57, 16 July 2011 (UTC)

WQA rename

Proposal at Wikipedia_talk:Wikiquette_alerts#Refactor_proposal. Gerardw (talk) 10:31, 28 July 2011 (UTC)

User:PleaseStand/References segregator

I've just heard of User:PleaseStand/References segregator, and it's AWESOME. I propose making it a Gadget ASAP. (In fact, what it does after you click the green button is probably what the default MediaWiki behaviour should be... but that's another story.) Rd232 talk 21:57, 28 July 2011 (UTC)

is my understanding correct, that it separates the references during editing only, and the net result after a save is that both the wikitext and the document are exactly the same as if editing normally? If so, the only problem I see (beyond the limitations-- are not given there --that it does not handle nested references, section editing, and Internet Explorer) is that it might be difficult to get this right on very active articles where there are edit conflicts. DGG ( talk ) 22:21, 28 July 2011 (UTC)
That is correct. I think on such articles, it's likely there will either be an established style already or that it will be so chaotic that running any sort of tool to fix anything will be useless. I don't think those two cases are of particular import. --Izno (talk) 23:13, 28 July 2011 (UTC)
Normally it only separates references during editing. There is an option to use it to support conversion of an article to List Defined References (currently you need to add an extra line to your Javascript page to enable the conversion button), which is a useful option for large and high-activity articles, but requires consensus beforehand. Rd232 talk 23:31, 28 July 2011 (UTC)

Unblockself permission

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.
No consensus for this at the moment, and discussion has died out. r93233 has changed the terms of the debate (the unblockself permission is no longer needed to undo selfblocks), and r93206 dealt with a related security issue of viewdelete rights (cf T17641 comment 11). So if this discussion is revisited in future, the remaining issue is the core one of whether admins should be technically able to undo blocks of themselves by others (whilst policy forbids it, except in extreme and improbable situations where IAR might apply). The (now applicable) pros and cons of removing unblockself center on how the presence of the right affects the ability to handle the improbable scenario of a rogue admin account blocking all other admins. Rd232 talk 22:41, 30 July 2011 (UTC)

Since the deployment of MW1.17, blocking an admin prevents them from performing most admin tasks, including blocking and unblocking. Admins currently hold the 'unblockself' permission which (in conjunction with 'block') allows them to do as it says on the tin: unblock themselves. In light of the recent overhaul of security practices for admins and bureaucrats, it may be worth reviewing whether this (default) position is still right for enwiki. Thoughts? Happymelon 00:59, 16 July 2011 (UTC)

As I understand it an admin unblocking themselves would be reversed and sanctioned in some way (in theory). I dont know if this is in any way reality, but yes I think not allowing admins to unblock themselves is smart. They are after all not any better than the rest of us, they are our equals, not superior in any way possible.Camelbinky (talk) 01:53, 16 July 2011 (UTC)
Admins aren't supposed to unblock themselves anyway (unless they blocked themselves in the first place). My question would be, if the right is removed, how would that affect bureaucrats' (or others') ability to deal with a rogue admin account blocking lots of admins and bureaucrats? If a blocked bureaucrat can still unblock themselves and then desysop the rogue, I guess that's OK? And I suppose there's always (global) stewards, who a rogue couldn't block. PS on the issue of security "blocking an admin prevents them from performing most admin tasks, including blocking and unblocking" - but it doesn't suspend WP:Viewdelete rights, does it? I think it should. Rd232 talk 01:58, 16 July 2011 (UTC)
If we gave 'unblockself' to bureaucrats, then yes, that would be the case; and you are correct about the stewards. I agree that being blocked should suspend 'viewdeleted', although I don't think that's currently the case. Happymelon 16:56, 16 July 2011 (UTC)

In r93233 I have allowed admins to always be able to alter or remove blocks placed upon themselves by themselves, whether or not they have the 'unblockself' permission. Removing this permission therefore now only removes the ability of an admin to unblock themselves when blocked by another user. Happymelon 20:08, 26 July 2011 (UTC)

Alternate proposal

Closed in favour of better version of proposal. Rd232 talk 16:10, 19 July 2011 (UTC)
The following discussion has been closed. Please do not modify it.
  1. Remove the ability of admins to amend, reblock or unblock themselves unless they're the ones who blocked themselves.
  2. Remove all admin rights of admins while blocked (except for the ability to modify a self-imposed block). This may affect only WP:Viewdelete rights, which admins currently have while blocked.
  3. Throttle the ability of admins to block admins. An admin account could be limited to making 10 admin blocks per 24 hours; this ought to be a limit easily high enough to never be hit legitimately, but it sorts out the concerns of a hypothetical rogue or compromised account going nuts and blocking everyone.

Rd232 talk 13:14, 17 July 2011 (UTC)

  • I think this is going a little too far. Can't we just all trust our admins these days? Seriously, if we're so concerned about something happening, just shut RfA down--clearly the level of trust needed is below the amount of paranoia present. /ƒETCHCOMMS/ 13:37, 17 July 2011 (UTC)
    • Could people please PAY ATTENTION TO THE CONTEXT OF THIS PROPOSAL. It is not about not trusting admins, it is about not always trusting admin accounts, i.e. security. You've heard of admin accounts being hijacked, yes? Rd232 talk 16:15, 17 July 2011 (UTC)
      • But so rarely that this is seems to be entirely a waste of time. Are there any scenarios that have occurred where the second or third point would have mattered? You are trying to solve a problem that doesn't exist. Prodego talk 16:53, 17 July 2011 (UTC)
        • Earthquakes rarely happen. What a waste of time to plan for them happening! Rd232 talk 18:07, 17 July 2011 (UTC)
          • No one has ever died while waiting for a steward, to the best of my knowledge. Prodego talk 21:33, 17 July 2011 (UTC)
            • How is that relevant? Address the proposal actually made. For point 1, there is zero need for admins to reverse blocks of them by others - they're not allowed to anyway (and both point 3 and your steward remark cover the Doomsday scenario of a block-everybody rogue where IAR might be required; and in such a scenario, the rogue can be stopped more easily if they can't self-unblock). For point 2, suspending admin rights while blocked makes sense, and has security benefits, since in a questionable situation (possibly compromised account) an account may well be blocked but not desysoped. And as is well known, viewdeleted rights are among the most sensitive (cf WP:Viewdelete). Rogue and compromised admin accounts are very much a real problem; it's happened before and will again. The question is, do we want to be slightly better prepared, at zero cost in everyday activities and fairly low implementation cost, or not? If not, why not? "It's not really a problem" is just not good enough an answer. Rd232 talk 23:47, 17 July 2011 (UTC)
      • I've heard of course. Now you are proposing to make life much easier for a hijacker—block all active admins and crats and you can do very interesting things like vandalizing the main page. The poor and impotent blocked admins would be sitting nearby watching all this unable even to view deleted by this rogue account. Ruslik_Zero 17:01, 17 July 2011 (UTC)
        • Facepalm Facepalm Did you even see point 3? Also, (global) stewards are unaffected, and the proposal addresses admins, so 'crats could still unblock themselves regardless. Rd232 talk 18:07, 17 July 2011 (UTC)
  • Thanks much for the suggestion, but this is too complicated. Just remove the right entirely. If it's a self block, use ((unblock)). causa sui (talk) 16:53, 18 July 2011 (UTC)

Alternate proposal 2

  1. Install mw:Extension:EmergencyDeSysop (allows an admin to temporarily desysop another admin in an emergency, at the expense of also temporarily desysopping themselves). This takes care of the Doomsday "block everyone" rogue scenario which seems the only justification to allow admins to remove blocks of themselves by others. It also means in a crisis any admin can step up, without the need to wait for a bureaucrat or steward; this should decrease expected response time in a crisis.
  2. Remove the ability of admins to amend, reblock or unblock themselves unless they're the ones who blocked themselves.
  3. Remove all admin rights of admins while blocked (except for the ability to modify a self-imposed block, and the ability to EmergencyDeSysop). This may affect only WP:Viewdelete rights, which admins currently have while blocked.

Rd232 talk 16:06, 19 July 2011 (UTC)

  • The new, bigger danger, of a compromised admin blocking all other admins, created by this fix, raised by User:Cybercobra 04:17, 17 July 2011 (UTC) and User_talk:Chris G 04:54, 17 July 2011 (UTC), had better be thoroughly considered before doing anything. --SmokeyJoe (talk) 03:51, 23 July 2011 (UTC)
  • These proposals include a lot of worms. --SmokeyJoe (talk) 03:56, 23 July 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.