Wikipedia:Village pump (proposals)/Archive 75
Village pump (proposals) archive
This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214
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:
- I would be correctly described as a fangirl, not a fanboy.
- 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)
- Two points:
- 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):
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 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 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:
- Technical Writing
- 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)
- 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)
- Support the idea. CSS specifics can be worked out by the gurus. — HELLKNOWZ ▎TALK 20:28, 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)
- 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):
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)
- Oppose unless there is evidence this is a widespread problem and victims want it stopped. Otherwise it looks like a solution looking for a problem. Email has lots of valid uses for new editors. PrimeHunter (talk) 00:18, 4 July 2011 (UTC)
- Oppose. We have better means of stopping this type of behavior. Unless you can confirm that this is a major problem, your proposal does more harm than good. עוד מישהו Od Mishehu 06:05, 5 July 2011 (UTC)
- Oppose. If users are being harassed by unsolicited mail they will, and do, let us know soon enough. Mail use will then be withdrawn. --Kudpung กุดผึ้ง (talk) 06:22, 5 July 2011 (UTC)
- Oppose. This will do more harm than good. Killing the ability for new users to reach out in a private manner to individuals is too high a price to pay for a theoretical harassment attack.--Jorm (WMF) (talk) 06:25, 5 July 2011 (UTC)
- Note: - this comment is actually my opinion as an employee of the Foundation given that this policy would overlap my work with editor retention. Such an action (restricting EmailUser) could adversely affect editor retention.
- Oppose - this seems like a solution looking for a problem. I wouldn't worry about this until we're confronted by it. In my capacity as an administrator and volunteer, not as an employee action. - Philippe 21:08, 5 July 2011 (UTC)
- Oppose, in my experience abusive emails are more likely to be sent by admins than anyone else. DuncanHill (talk) 21:15, 5 July 2011 (UTC)
- Oppose, because if the feature is used wrongly, the user can be blocked, including blocking the use of emails (
blockemail). If it has to do with users from a certain IP, the IP can be blocked by a CheckUser who has verified it, of if from a similar IP range, a rangeblock. Hazard-SJ ± 19:03, 6 July 2011 (UTC)
- In addition, a user being targeted can disable email-from-other-users until the harasser is dealt with. Bottom line: we're not helpless against the scenario, and if becomes a real problem, the issue can be revisited. Rd232 public talk 23:31, 8 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:
- France = Blue
- Italy = Azure blue
- Spain = Dark red
- Switzerland = Red
- Netherlands = Orange
- Germany = Gold
- Denmark = Burgundy
- Luxembourg = Deep sky blue
- Kazakhstan = Light blue
- Ireland = Green
- United States = Dark blue
- Russia = Dodger blue
- United Kingdom = British racing green
- Hungary = Forest green
- Ukraine = Navy Blue
- Poland = Crimson
- Sweden = Yellow
- War = White
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)
- What do you mean by "War"? --SPhilbrickT 12:50, 7 July 2011 (UTC)
- Oppose This isn't going to end well. Dozens of coutries use similar colors in their flags. Think of all the Commonwealth nations and their usage of dark blue. Mongolia, Japan, the United States, and China all use dark red. A ton of nations use at least one of dark green, white, and yellow. There is no way to avoid overlap, and if we do a one color to one country system, it's going to be English/Anglo centric, cause a ton of disputes, and just cause mess after mess. As a coutnerproposal, I would offer that in cases such as that diagram, that every effort be made to try and use one of the flag colors for each nation (not predetermined), but that contrast be taken into account. If someone gets stuck with pink to make it all work, someone gets stuck with pink. It beats nationalistic color jockeying. Sven Manguard Wha? 05:17, 11 July 2011 (UTC)
- Cute, but no Nice idea, one I would have supported in my earlier, naive days. It simply would not work. There could be hideous clashes of colours in reality, possible confusion of colours in continental competitions, and as above, the Anglo-centric assumption of colour codes would make consequential arguments a nightmare to resolve. doktorb wordsdeeds 11:53, 11 July 2011 (UTC)
- No. We need less emphasis on nationalism, not more.
- Also, colour choices will inevitably have an arbitrary element because so many countries have, in reality, adopted multiple and/or overlapping "national" colours.
- Sometimes the colour choice may have to be context dependent (differing between sports, for example) unless we are to impose a universal colour for each country regardless of the nuances of actual usage.
- Also, there will be all the usual problems we associate with flags &c - especially that of dual, ambiguous, or changeable nationality - because many people don't fit into pigeonholes as neatly as the OP supposes. Since the chosen examples are in cycling, what colour should be assigned to Nicholas Roche? In practice, he would get green in some articles, blue in others, occasionally somebody would create a new hue of turquoise for him, and in a couple of remaining articles he would get rather fetching blue and green stripes. All of which would be subject to the occasional edit war. Ditto for Heinrich Haussler, Max Sciandri, &c.
- Similarly, where the actual nationality (ie. passport) of the subject is not known, wikipedians would feel compelled to make a best guess in order to fill an uncoloured gap. I've already seen that on a lot of sports articles - we can't possibly have evidence of the nationality of ten thousand marginal-notability athletes, but somebody's gone around adding little flags on the assumption that if (for instance) they play for an English team and have an English-looking name, they must get a little St George flag (even though "english" isn't really a nationality) in order to complete a table. bobrayner (talk) 14:03, 11 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!
- OpposeNo one could distinguish all those slightly different tints and shades on a computer monitor. Seven different blues? Why does one country get the basic color? Who is to say that Switzerland is more "red" than China? Who are you to determine the color which stands for a given country, anyway? Edison (talk) 16:32, 13 July 2011 (UTC)
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)
- 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)
- 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, 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)
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 (T•C•V) 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)
- I agree, this is a good idea. - Hydroxonium (T•C•V) 05:45, 14 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)
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!
- all article information in the article needs to be sourced, you can find these at the end of the article. If you have question its best to ask on the article talk page as the people who edit the article can best answer such questions. Gnangarra 10:32, 13 July 2011 (UTC)
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:
- Have been tagged for 4 days
- Are not in any of the following categories:
- Is not listed on Wikipedia:Categories for discussion
- Does not have {{Empty category}} on the page
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)
- Oppose Not for the vandalism, but because I really don't trust bots not to be gamed, and because there are plenty of categories that should be empty most of the time. There are a number of backlogs at WP:GBD that spend most of their time hidden from the list because they are empty, but occasionally fill up, get dealt with, and go back to being empty. Deleting the category during downtime would screw stuff up, and the bot would have no idea that it wasn't supposed to be messing with stuff there. I would support a bot that a) generated a list of unpopulated categories (so that admins could look through them) and b) had an exclusion list (so that once the bot listed them, we could add maintenance categories and other not to be deleted categories to that list so they would not keep showing up in future lists.) However a deletion happy bot dealing with categories is a bad idea. Sven Manguard Wha? 05:23, 11 July 2011 (UTC)
- Such categories should be tagged with a {{Empty category}}, which alerts human admins not to delete them, and the proposed bot is supposed to leave those categories alone. עוד מישהו Od Mishehu 07:20, 11 July 2011 (UTC)
- The likelihood of even half of the categories that should be tagged with that actually being tagged with that seems low to me. My oppose stands. Sven Manguard Wha? 21:50, 13 July 2011 (UTC)
- My first thought when seeing this was what Sven expressed here. There's a reason that there isn't a bot that does this already. Tell ya what though, if you want to develop a bot dealing with categories here's an idea for ya: create a bot with a web interface which will move all articles in a given category into a different (new or existing) category. That would be useful.
— V = IR (Talk • Contribs) 02:24, 14 July 2011 (UTC)- I was about to say that there are a bunch of bots that move pages, in fact, I used to run AMbot to do this for CFD closes. When I checked WP:CFDW however, I saw that Cydebot was the only one listed as still active. If Cydebot isn't able to keep up, or isn't what you are looking for, drop me a line to discuss. --After Midnight 0001 03:08, 14 July 2011 (UTC)
- My first thought when seeing this was what Sven expressed here. There's a reason that there isn't a bot that does this already. Tell ya what though, if you want to develop a bot dealing with categories here's an idea for ya: create a bot with a web interface which will move all articles in a given category into a different (new or existing) category. That would be useful.
- The likelihood of even half of the categories that should be tagged with that actually being tagged with that seems low to me. My oppose stands. Sven Manguard Wha? 21:50, 13 July 2011 (UTC)
- Such categories should be tagged with a {{Empty category}}, which alerts human admins not to delete them, and the proposed bot is supposed to leave those categories alone. עוד מישהו Od Mishehu 07:20, 11 July 2011 (UTC)
- Oppose - too many admins currently. Killiondude (talk) 21:52, 13 July 2011 (UTC)
- Oppose - There are not that many categories that stack up in the C1 area that a bot is really needed to assist here. I personally do much, if not most, of the C1 deleting, and I am easily able to keep up with the task. When I am away for some time, I notice another admin always keeps things from piling up. Also, a human admin is able to check the talk page for objections placed by a concerned user who does not know to use {{Empty category}} or who is alerting the admin that the category was emptied out of process. --After Midnight 0001 02:58, 14 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
- The number of patrollers varies from time to time. This leads to multiple editors 'racing' to revert vandalism/ duplicated effort for looking at changes OR long periods where none of the IP/ newbie contribs are reviewed.
- when an editor does not revert a change, it may be because a) its good b)it needs closer looking into by someone else
- vandalism comes in bursts: an editor who made one bad edit is likely to strike again.
Proposal
- add a feature so that when a change is viewed, an editor can tag the change as one of(for e.g.):[good|not sure|reverted]
- users get tagged if they have a tagged edits.
- When the RC list is viewed, the tags will be visible near each change. (for e.g.): <change tag>/<usertag>
- (diff | hist) . . article1; 11:19 . . (+1) . . RepeatTroublemaker (talk) (new attack) ?/!
- (diff | hist) . . article1; 11:18 . . (+1) . . NewWikiGnome (talk) (new useful) ?/:)
- (diff | hist) . . article1; 11:17 . . (+1) . . RepeatTroublemaker (talk) (reverted attack) X/!
- (diff | hist) . . article1; 11:16 . . (+1) . . NewWikiGnome (talk) (reviewed useful) :)/:)
- editors who can tag changes must be autoconfirmed/ slightly more edits(say 20-30) OR can be elevated by other RC patrolers.
Why I think it will be useful
- Will streamline RC patrol and prevent duplicated effort.
- more thorough patrols: pay special attention to older unpatrolled changes, changes tagged not sure and changes by users tagged to be problematic.
- if (i'm guessing!) WP servers maintain a list of recent changes as a database for 2 days, It wont be too much of a strain to add an extra column or two per entry.
- It won't add to any backlog of changes to review(unlike flagged revisions). The backlog already exists. This just clearly marks those changes that need patrolling and maybe will help clear it out faster.
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)
- This is essentially flagged revisions on all articles which works well on DE wiki and elsewhere. It would make things a bit easier for hugglers providing Huggle was configured to ignore edits that had been "approved" in this way, but the main impact would be on watchlisters who would see just how rare it is for an edit to be unchecked after 24 hours. Currently there is huge wastage in our vandalfighting and recent changes patrol methods because we don't record that someone has seen an edit and decided it wasn't vandalism, so we don't know which edits are unchecked or which have been checked twenty times (I've taken Beaver and certain other vandal magnets off my watchlist because I worked out how many people must be watchlisting Beaver to get the current speed of reversion) . Sadly experience of the pending changes debate is that a blocking minority of the community doesn't want this sort of system, and I don't see that changing as long as we have enough hugglers to make the current system work. Our vandalfighters are dwindling in number and if this continues we will eventually have to implement a system that enables their time to be used more efficiently, but I fear we won't get consensus to do this as long as we have enough volunteers to operates a set of vandal fighting tools that wastes an awful lot of volunteer time checking edits that many others have checked. ϢereSpielChequers 07:53, 12 July 2011 (UTC)
- I agree with WereSpielChequers. Flagged Revs would make this recent change patroller very happy. When I'm Huggling, I'm trying my hardest but it'd be nice if we could have less duplicated effort. —Tom Morris (talk) 12:23, 14 July 2011 (UTC)
- With regard to the objections raised by Cntras and Qqwyrxian,:
- My estimates for the IP and newbie contribs are around 20/min and 6/min respecively. That is around 30 edits/min that are "high risk".
- Even with low review rates (i do around 5/min at max speed) clashes do occur.
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)
TentativeSupport 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, butI 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)
- 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)
- 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)
- 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)
- 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 reference. Unscintillating (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)
- Very, very, very, very Support Wikipedia is beginning to become a rummage sale with a few hidden gems. There are some great articles, but lots of junk. Time to clean up the junk before adding more unsourced and low quality junk to the rummage sale. Did I say very strong support? History2007 (talk) 00:49, 15 July 2011 (UTC)
- Support - Verifiability is a core principle; no sources = no verifiability. If this discourages the creation of articles which would otherwise die a horrible death at the front gate or at AfD, no matter. There absolutely needs to be a significant program to attract and train new content creators, but putting up this most minimal of barriers would not hinder that objective in any way. Rather, it would help teach newcomers what is actually expected at Wikipedia in practice: that articles be verifiable and contain information published in independent and substantial sources. Carrite (talk) 03:40, 11 July 2011 (UTC)
- Reluctant Oppose We need to constantly move our standards forward, and this is a step in the right direction - except using a speedy in this case strikes me as too bitey. I'd prefer a PROD - specifically, something in the image of WP:BLPPROD. --JaGatalk 04:34, 11 July 2011 (UTC)
- This is just floating the initial concept. I think a prod like setup is more appropriate as well; I was just shooting the idea out of my head to see what the community thought of new articles requiring one source, and less on the mechanics of how that is enforced. - ʄɭoʏɗiaɲ τ ¢ 10:50, 11 July 2011 (UTC)
- Support Encouraging new articles to be higher quality from the start is what we should be doing. --Jayron32 04:36, 11 July 2011 (UTC)
- Comment I have mixed feelings about this. We already have several templates that address sourcing issues, and if the NPPers are doing their job, it should suffice. BLPPROD works for BLPs but also has its imperfections due the fact that no criteria were laid down as to what constitutes an appropriate reliable source. At present, any link on the page that concerns the subject, however vague, dismisses the use of the BLPPROD. A software script would not be able to assess the quality of sources. A possible solution would be for Twinkle to place a message on the creator's tp when a 'noref' 'refimprove', or 'primary sources' tag is added, such as: Welcome to Wikipedia and thank you for your contribution. The article you created at [[xxx]] has been tagged as requiring sources. To avoid possible deletion, please consider returning to the article and addressing the issues. Thanks, and happy editing! ~~~~ This is a custom message which I have used hundreds of times. Kudpung กุดผึ้ง (talk) 04:50, 11 July 2011 (UTC)
- Strong Support I'm a hardliner on this. I would, were the rules up to me, immediately delete all 300,000 unsourced articles, regardless of their content, so long as those articles were not left without sources by an act of vandalism. At WP:AFC articles are not created unless there are multiple reliable sources, period. That's what needs to happen with every single article. I would support this proposal, in whatever form it comes out, so long as it moves us closer to the standards AFC applies. Sven Manguard Wha? 05:04, 11 July 2011 (UTC)
- Strongest possible oppose especially for bots and edit filter purposes. If the content makes sense, and we've got no reason to suspect it's a hoax, misleading, etc..., tagging with {{unreferenced}} is completely sufficient. Knee-jerk reactions do not improve the encyclopedia, and will drive away newcomers, and will deprive of content we could build upon. Headbomb {talk / contribs / physics / books} 05:13, 11 July 2011 (UTC)
- Question: Would this be accomplished by the edit filter, having a notice given to the editor that the article requires a source before it can be saved, or by just deleting the article? If the latter, I oppose this change. --Yair rand (talk) 05:18, 11 July 2011 (UTC)
- None of the above. The discussion is merely regarding the concept. How it would be achieved would be a second discussion, but the best idea I've read so far is using BLPPROD as a model. - ʄɭoʏɗiaɲ τ ¢ 22:43, 11 July 2011 (UTC)
- Oppose The amount of very useful and now well well sourced articles we would not have if this had be applied in the past shows that the net-benefit of such a rule is negative Agathoclea (talk) 06:59, 11 July 2011 (UTC)
- That's the thing, what Wikipedia has been over the past 10 years is not what it will be forever. We are gradually shifting from quantity towards quality with new articles, and making Wikipedia a far more reputable resource in the process. - ʄɭoʏɗiaɲ τ ¢ 22:43, 11 July 2011 (UTC)
- Oppose. Is this proposal among those that are usually called "an uncommonly silly"? Just to delete a perfectly valid article only because it does not satisfies a bureaucratic requirement? If people have so much free time that they can come here and propose this, they would be better to simply find a source themselves. Ruslik_Zero 07:24, 11 July 2011 (UTC)
- "bureaucratic" requirement? No, it's at the core of what Wikipedia needs to be, a reliable encyclopedia. Look at WP:42 please. Also, for the sake of discussion, there are currently 255,931 unreferenced articles, of which 3,041 are BLPs. This isn't some petty problem, its 7% of the entirety of Wikipedia. Sven Manguard Wha? 07:47, 11 July 2011 (UTC)
- Support, this should be a minimum standard. — Cirt (talk) 07:31, 11 July 2011 (UTC)
- Support": I don't think have just one source would be to onerous and would get rid of a lot of the rubbish that is added. I think it would also be a very good PR move towards making the project more credible. Giacomo Returned 07:36, 11 July 2011 (UTC)
- Oppose, babies, bathwater, etc. And what Ruslik said.--Kotniski (talk) 07:51, 11 July 2011 (UTC)
- No, but. On the one hand if this was simply done by making unsourced a deletion criteria it would be a bad PR move, undermine the strategy of Openness and risk being a further step in moving from a policy of wp:verifiable to a policy of verified. We already have templates such as {{fact}} for statements sufficiently contentious that they need to be sourced, and a BLP policy that encourages us to simply remove unsourced contentious content about living people. I think there is a real risk that requiring a source for all new articles would be a further step towards requiring a source for all new edits or all new facts, and that those who would support such a policy change would see this as making "revert unsourced" a legitimate edit. One of the problems of our article creation process is its asynchronous nature, with some patrollers and even admins working to an unwritten and much stricter policy than the consensus based one that some article creators follow. I'd be happy with a screen prompt in the article creation process that said, "You don't seem to have a source in this new article, please tell us where you got this information from [______]" ideally with sufficient code behind to politely reject facebook, Linkedin etc. if they are offered as a source. Such a prompt would be a good step towards a newpage patrol system that was asynchronous the other way, with newpage patrol being more about correcting categories and fixing newbie errors and generally helping article creators navigate an article creation process that was stricter than the article creation policy. ϢereSpielChequers 08:43, 11 July 2011 (UTC)
- Oppose. Its another case of WP:CREEP.This would make it even harder for new users to create articles. It's also impossible to automate (unless we have a bot that is able to parse and understand full human language), as you cannot expect a new user to use any of our myriad of citation systems. "See front page of New York Times from February 3rd, 2010" is not a good reference, but it meets WP:V. So may a bare URL (but it may also be spam). Also consider a not atypical use case: A user writes an article, saves it (to be on the safe side), then uses the interface to do the tedious task of inserting references. Would this still work? How? --Stephan Schulz (talk) 08:58, 11 July 2011 (UTC)
- Oppose. I don't believe we are "well beyond the initial hurdle of content creation", we're still in the early stages of writing an encyclopedia, with many subject areas still lacking in content. Realistically, most articles will require at least one source if they're going to stay here for long, but many perfectly good articles started life as brief additions by new editors with no sources added. How many perfectly reasonable articles on towns and villages, species, etc. are unsourced and would get deleted if this were to be implemented? We need to keep new editors coming to the project and this proposal would make it harder for people to get started. We have enough in place to cope with unsourced articles as it is.--Michig (talk) 09:01, 11 July 2011 (UTC)
- Oppose we don't need anymore deletion reasons we already have WP:CSD#A7 or {{prod}} on notability, both at least give the creators a chance to address the concerns. Editors do write stub articles as part of a larger article then return to add a sourcing especially during GA and FA processes. Gnangarra 11:04, 11 July 2011 (UTC)
- This could be akin to PROD, where users would be given at least a week to construct their article. - ʄɭoʏɗiaɲ τ ¢ 22:43, 11 July 2011 (UTC)
- exactly Gnangarra 10:09, 13 July 2011 (UTC)
- This could be akin to PROD, where users would be given at least a week to construct their article. - ʄɭoʏɗiaɲ τ ¢ 22:43, 11 July 2011 (UTC)
- Support. WP:V has to be at the heart of wikipedia, and we desperately need higher quality among articles - new ones in particular. I appreciate the concern about scaring off some new editors, but creating a completely new article is not the sole (or even the most common) starting point for an editor, and we want better new editors, rather than keeping standards low to attract more people prone to creating unsourced content. I would very much support any move to make it easier for editors to add sources, but this proposal shouldn't have to wait for that to be implemented. Apart from the editors, I think the concern about getting new articles created isn't a big issue either - for a newbie to add a source is not impossible (though it could be made more intuitive) and we have plenty of talented article creators already - if there were some huge backlog of missing articles which "should have been" created but had not been due to some basic sourcing standards, then there's a bigger problem at hand. bobrayner (talk) 11:27, 11 July 2011 (UTC)
- Strong oppose because I don't trust Wikipedians with this tool. WP:Editorial judgment is still a redlink, and I'm afraid the evidence is that too many users don't have it. They'll habitually tag material for deletion, or send material to AfD, without looking for sources themselves or in any way try to help write content. So a new user, trying to contribute to the encyclopaedia, will often find that their efforts are met with high-speed templated deletion messages (often within seconds of creation) that are seemingly designed to get rid of them and their contributions as fast as possible; and there's already a labyrinthine mass of confusing rules to comply with. In short, Wikipedia is already a massively hostile and offputting place for a new person who wants to write content, and I'm unalterably opposed to any further steps along this path.—S Marshall T/C 12:49, 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)
- Oppose This proposal would completely undo the verifiability policy which states that facts must be verifiable, not verified. It is certainly not difficult to have an inappropriate article deleted now, and this would merely promote the idea of deleting articles without bothering to read them or do any research on a topic. That is unacceptable behavior. If you can't be bothered to do a web search on an article's topic, you should probably find an area other than NPP or deletion tagging in which to work. The bar on new page creation is already high enough, and BITE is violated often enough, that there is no need to make things even worse for new editors, editors creating their first new page, or those seeking to contribute knowledge to the project. Jim Miller See me | Touch me 13:04, 11 July 2011 (UTC)
- One per article is a low bar, and definitely doesn't shread WP:V with regards to the rest of the article. - ʄɭoʏɗiaɲ τ ¢ 23:02, 11 July 2011 (UTC)
- This proposal makes some sense but I have to oppose at this time per the arguments of S Marshal and per there is no deadline. Yes we do it for BLPs but that's because they do have a "deadline" (it's "yesterday") and I might support this for other high risk articles such as bands and companies but if a new user creates one stub about an 18th century British politician we shouldn't bite him because it doesn't have sources yet. --Ron Ritzman (talk) 13:26, 11 July 2011 (UTC)
- I could also apply deadline to say an article needn't be created in the first place until an editor can sit down and take 30 seconds to paste one in. I don't think we should bite either. We should instruct them that
hoardes of angry hyenasour friendly editors will descend upon their article if they don't provide some evidence of what they are typing. - ʄɭoʏɗiaɲ τ ¢ 23:02, 11 July 2011 (UTC)
- I could also apply deadline to say an article needn't be created in the first place until an editor can sit down and take 30 seconds to paste one in. I don't think we should bite either. We should instruct them that
- Support (super strong) Yes of course. This is a great idea. Otherwise we have WP:OR Doc James (talk · contribs · email) 13:28, 11 July 2011 (UTC)
- Not really - as long as sources exist somewhere, it isn't OR. Nor, for that matter, is the fact that one or more sources are cited any guarantee that the article doesn't contain OR.--Kotniski (talk) 13:50, 11 July 2011 (UTC)
- It makes it more reliable though... And unless you provide a source, text can be deleted without prejudice; we have a disclaimer to that effect below the edit window. - ʄɭoʏɗiaɲ τ ¢ 23:02, 11 July 2011 (UTC)
- I am unhappy with giving the impression that people can just write what they think is true ( original research ) and then just leave it up to others to find the evidence for what they have stated. Yes no ref means OR. --Doc James (talk · contribs · email) 03:47, 13 July 2011 (UTC)
- It makes it more reliable though... And unless you provide a source, text can be deleted without prejudice; we have a disclaimer to that effect below the edit window. - ʄɭoʏɗiaɲ τ ¢ 23:02, 11 July 2011 (UTC)
- Not really - as long as sources exist somewhere, it isn't OR. Nor, for that matter, is the fact that one or more sources are cited any guarantee that the article doesn't contain OR.--Kotniski (talk) 13:50, 11 July 2011 (UTC)
- What would happen to ITN/ongoing events, summary overviews and similar? Also 'Village Pump and other WP policy pages have no references - so should be deleted' :)
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)
- Project pages are not articles, only articles are articles. If its ITN or an "ongoing event", then finding ONE source before creating the article should be easy! Those articles without references are unverifiable and just a bunch of heresay without anything to back it up. We're an encyclopedia, so we don't create new information. - ʄɭoʏɗiaɲ τ ¢ 23:02, 11 July 2011 (UTC)
- Oppose This will scare off new editors, and the unref'd tag does its job. Lugnuts (talk) 18:19, 11 July 2011 (UTC)
- Strong oppose per Agathoclea. Many notable articles begin as stubs which are poorly sourced. Is practically how wikipedia has got where it has today. Under such a rule masses of high potential articles would be deleted blindly all because of a needed sourced. If we seriously want to dramatically improve article quality we would prevent the creation of any new article and give an incentive for editors to source the 255,000 unreferenced articles and have a humungous cleanout. By far the biggest problem on wikipedia is the subject matter and way that many of the articles are written which is why in the present state having them will never be regarded as a credible source. If we got rid of all of the unencyclopedic shite and cruft and stuck to traditional topics or semi-traditional topics and ensured they all had a decent level of sources then we could permit new content to be added only if sourced, or at least placed at a side until they can be verified and kept. So I am not buying that this would actually improve quality. Far more drastic measures are needed if we are to be serious about quality and having more credibility as an academic website. ♦ Dr. Blofeld 18:39, 11 July 2011 (UTC)
- Support. I don't see what's so hard to swallow about this, and I suggest that anyone who does ought to spend a few minutes looking at NPP. Nobody's asking for perfectly crafted citations, just an indication of where the information has come from. Malleus Fatuorum 19:06, 11 July 2011 (UTC)
- Oppose It would be absolutely great to have every new stub have a source that we could easily check to make sure what we are dealing with; for myself this is a must when I create stubs. However, I am opposed to a rule for killing stubs without citations. We should leave it to tagging and checking against hoaxes etc. and going about each case (or series of cases) individually. I know this means more work, because I often have to look for hours for missing sources. Even so, I oppose. Hoverfish Talk 19:13, 11 July 2011 (UTC)
- Oppose per chaos5023. 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). Since there is no such functionality yet, deleting an article just because it's unsourced is needlessly too generalized a criteria for speedy (an AfD is another matter). A very very broad brush for painting a red target for the deletionist tool-using button pushers. To put it bluntly, it's lazy. Not all new articles are created as stubs (as the original proposal implies), and it's well-known that new users generally have a lot of trouble grasping the coding behind referencing. Speedily deleting a full article someone obviously spent a great deal of time on, about a subject that later turns out to actually be notable, will be extremely discouraging for potential new editors. Focus more on getting these points across to new users rather than simply slapping them around for breaking rules they don't even know existed.-- Obsidi♠n Soul 19:17, 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?
- 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)
- 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)
- We should not encourage nominators to simply stop at looking for the
- Strongly oppose, as this would scare off newbies, who would have no idea how to do that. They should be allowed to create articles, which will later be improved with sources. StuRat (talk) 19:20, 11 July 2011 (UTC)
- Strongly oppose, once again this is a project that relies on newbies and is too large in "rules" already to continue to attract new editors if it is required that someone read every !rule prior to editing. Yes, a source should be required in a new article, but some times even the future best editors come to Wikipedia not knowing how to format a reference on Wikipedia or just come to do one little thing, get addicted and become the next well-respected admin. If this proposal goes through then we are well on the slippery slope to having to simply remove from the multiple policies that state "we are a work in progress and your contributions need not be perfect" and change that to "read all our strict laws and do a perfect job at creating an article or it will be speedily deleted without discussion regardless of notability." Which brings me to my next point- deletion should be based solely on notability and not on quality, too many editors seem to forget that. (BLP issues are an obvious exception, please don't bring that red-herring into this). If an article lacks a source, you know what you can do? ADD A FREAKIN' SOURCE OR SIT ON YOUR HANDS AND GO ELSEWHERE! "I don't like something that is wrong, I'll delete it. I wont try to fix it. That would require work on my part. So I'll delete it. And policy should be that EVERYONE ELSE has to do work and be bothered so I'm not bothered with real work."Camelbinky (talk) 20:02, 11 July 2011 (UTC)
- I don't think that expecting people to source content they add to Wikipedia constitutes "expecting EVERYONE ELSE to do the work" – and WP:BURDEN seems to agree. In fact, adding unsourced content to Wikipedia involves creating needless work for others. ╟─TreasuryTag►District Collector─╢ 20:17, 11 July 2011 (UTC)
- Whenever I see someone quote WP:BURDEN all I see is "I want someone else to be perfect so if I see something wrong I can just delete it and not fix it" because that's what it means and it is the WORST of all the policies/guidelines that exist. If you see something wrong, fix it. Gee, is that really that hard to do?! If you don't like something being wrong and you don't want to fix it, then ignore it, it doesnt hurt YOU. If your response is that you want a reliable serious endeavour to create a complete encyclopedia then... it is not NEEDLESS work for you to put in sources when someone new does not know how. Example- the first time I created an article from scratch I didnt know how to do the wiki-markup to put in inline-citations, so I put on the talk page what my sources were. Someone contacted me over time during my other editing of existing articles and politely taught me what I needed to know. I then started my second article from scratch and took it on up to GA status. I do believe at least 2 or 3 articles that I am the main contributor on have made it to GA status and I have created from scratch over 30 articles. None of that would exist if my first attempt had been speedily deleted due to unsourced material issues, since I would have been too discouraged to continue I'm sure.Camelbinky (talk) 20:42, 11 July 2011 (UTC)
- Whenever I see someone quote WP:BURDEN all I see is "I want someone else to be perfect so if I see something wrong I can just delete it and not fix it" – if you disagree with the notion that editors should take some responsibility for their actions on Wikipedia, then that seems rather unfortunate. It is the WORST of all the policies/guidelines that exist – ditto. It is not NEEDLESS work for you to put in sources when someone new does not know how – if this proposal were properly implemented, there is no reason why a new editor should "not know how" to copy-paste a URL into their article. In fact, most people know how to do this anyway. ╟─TreasuryTag►Syndic General─╢ 21:34, 11 July 2011 (UTC)
- I think you're conflating (proper) use of wikimarkup with providing a source for one's contributions. Killiondude (talk) 20:47, 11 July 2011 (UTC)
- Am I though? What stops, if this proposal goes through, for a year from now we have editors going around "this article is crappy, yea it has a source but it isnt properly formatted, so we should delete it because per WP:BURDEN the editor has to fix it, and we've had it tagged for 6 months and no one is watching or doing anything". This is just one more proposal to game BURDEN to allow the deletion of anything that does not fit someone's high expectations because they don't want to do the work to make articles reach what they think an article should look like. Deletion is based on notability. End of story. This talk of speedy deletion is an end-run around having to go through a discussion (more work!) where others will come along and say "no, its notable" and there will be talk about it and in the end maybe a source or two will actually be placed IN the article but maybe not and the article is not improved and the nominator is pissed because the article is still crappy but it cant be deleted now. Speedy deletion for this is uncalled, and we need to make a stand that policy still stands that quality is not an issue for discussion at AfD.Camelbinky (talk) 21:16, 11 July 2011 (UTC)
- What stops, if this proposal goes through, for a year from now we have editors going around "this article is crappy, yea it has a source but it isnt properly formatted, so we should delete it because per WP:BURDEN the editor has to fix it, and we've had it tagged for 6 months and no one is watching or doing anything". Slippery slope arguments are pretty poor at the best of times, and this one seems to be especially weak, if I may say so. ╟─TreasuryTag►Syndic General─╢ 21:34, 11 July 2011 (UTC)
- Am I though? What stops, if this proposal goes through, for a year from now we have editors going around "this article is crappy, yea it has a source but it isnt properly formatted, so we should delete it because per WP:BURDEN the editor has to fix it, and we've had it tagged for 6 months and no one is watching or doing anything". This is just one more proposal to game BURDEN to allow the deletion of anything that does not fit someone's high expectations because they don't want to do the work to make articles reach what they think an article should look like. Deletion is based on notability. End of story. This talk of speedy deletion is an end-run around having to go through a discussion (more work!) where others will come along and say "no, its notable" and there will be talk about it and in the end maybe a source or two will actually be placed IN the article but maybe not and the article is not improved and the nominator is pissed because the article is still crappy but it cant be deleted now. Speedy deletion for this is uncalled, and we need to make a stand that policy still stands that quality is not an issue for discussion at AfD.Camelbinky (talk) 21:16, 11 July 2011 (UTC)
- Whenever I see someone quote WP:BURDEN all I see is "I want someone else to be perfect so if I see something wrong I can just delete it and not fix it" because that's what it means and it is the WORST of all the policies/guidelines that exist. If you see something wrong, fix it. Gee, is that really that hard to do?! If you don't like something being wrong and you don't want to fix it, then ignore it, it doesnt hurt YOU. If your response is that you want a reliable serious endeavour to create a complete encyclopedia then... it is not NEEDLESS work for you to put in sources when someone new does not know how. Example- the first time I created an article from scratch I didnt know how to do the wiki-markup to put in inline-citations, so I put on the talk page what my sources were. Someone contacted me over time during my other editing of existing articles and politely taught me what I needed to know. I then started my second article from scratch and took it on up to GA status. I do believe at least 2 or 3 articles that I am the main contributor on have made it to GA status and I have created from scratch over 30 articles. None of that would exist if my first attempt had been speedily deleted due to unsourced material issues, since I would have been too discouraged to continue I'm sure.Camelbinky (talk) 20:42, 11 July 2011 (UTC)
- I don't think that expecting people to source content they add to Wikipedia constitutes "expecting EVERYONE ELSE to do the work" – and WP:BURDEN seems to agree. In fact, adding unsourced content to Wikipedia involves creating needless work for others. ╟─TreasuryTag►District Collector─╢ 20:17, 11 July 2011 (UTC)
- Oppose The bar against entry for new editors is already high enough. --causa sui (talk) 20:23, 11 July 2011 (UTC)
- Oppose - I can see the wikilawyering over the something like 2013 NFL Draft. We're obviously going to have the article. It's obviously a notable topic. But when the article outline is created, it seems like deleting it because there are no sources would just be obnoxious. I'd support a less all-encompassing version of this rule that excludes sub-articles or some such thing. Obviously, there should be sources eventually, but a prohibition on creating the stub outline seems like overkill. --B (talk) 20:37, 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)
- Comment I'm not sure about this, but there should be a period of grace of say an hour from first creation, otherwise bots will tag most new articles for deletion, which would be very irritating. Johnbod (talk) 20:39, 11 July 2011 (UTC)
- Support, if some grace period is provided for. We do not want to attract new editors who do not want to bother to source their content. Wikipedia's principal challenge at this point in its development is quality, not quantity. Sandstein 21:13, 11 July 2011 (UTC)
- Really? Quality over quantity? Hmmm, that's an argument I've seen thrown around for the last three or four years... I guess every article created since then, and every one created from here on out, you will support for deletion because obviously the article isn't need, we are pretty much complete according your theory. I find that a weak argument. Guess I should stop creating new articles and just work on improving existing articles. And anyone else working on creating new articles is wasting their time as well.Camelbinky (talk) 21:24, 11 July 2011 (UTC)
- That's a straw man; I've been arguing for quality over quantity for a while now, and I've created one article (and I'm just about ready to move the other one into articlespace). It's not that creating articles is A Bad Thing, it's that we have to spend more time focusing on the ones that already exist. Compounding this problem is the fact that these unreferenced articles tend to be in groups; there are a huge number of unreferenced articles on India and Pakistan-related articles and higher-level science articles, for instance. We have to stop pretending that this isn't a major problem if we want to be taken seriously. The Blade of the Northern Lights (話して下さい) 18:41, 14 July 2011 (UTC)
- Does consensus exist that we want to be taken seriously? It sounds like more trouble than it's worth. —chaos5023 (talk) 18:45, 14 July 2011 (UTC)
- If Wikipedia's goal is to be a repository for "the sum of human knowledge", I'd think that being taken seriously is implied. If you don't think it is, you should perhaps Jimbo himself if his goal is to make this a serious project. And for what it's worth, we are being taken more seriously than we once were, so even if there's no consensus it's still happening, and we can't really fight that. The Blade of the Northern Lights (話して下さい) 18:48, 14 July 2011 (UTC)
- "Sum of human knowledge": even Jimbo knows that, while that was a lovely turn of phrase, it's marketing copy that's flatly contradicted by WP:NOT. But, uh, if we're being taken seriously whether we like it or not, how is that compatible with scare language about how we need to do X in order to be taken seriously? If we literally cannot stop it from happening, sounds like we can relax as far as making it happen goes. —chaos5023 (talk) 19:02, 14 July 2011 (UTC)
- I know it's not supposed to be taken literally (god forbid Wikipedia ever go down that road), but I think that we should work with our publicity, not against it. I think this would be a good way to do so; others do not. Reasonable people can disagree. The Blade of the Northern Lights (話して下さい) 19:19, 14 July 2011 (UTC)
- We're taken seriously? Really? Has anyone told Stephen Colbert, Jon Stewart, the creator's of South Park, Conan O'Brien, Jay Leno, or Daniel Tosh? I love this project and working on it, and yes, I think 90% of the information here is correct, but we have to face the facts–no matter how "mainstream" we get in being where people find information (due to being so high on any Google search and for that reason ONLY) we are not ever going to be able to get over the stigmatism that we have been branded with. And I fail to see how this proposal of eliminating information through deletion in disregard for our policies on why to delete something in any way addresses the problem of not "being taken seriously".Camelbinky (talk) 20:26, 14 July 2011 (UTC)
- It's all about which half of the glass you look at; a lot of doctors seem to think that we're a great medical resource (it's in one of the editions of the signpost). I do think that removing unsourced information would be a good way to communicate to the public that we care about veracity as much as we say, but I also understand your view. Perhaps I've been jaded by my year and change on NPP. The Blade of the Northern Lights (話して下さい) 01:48, 15 July 2011 (UTC)
- We're taken seriously? Really? Has anyone told Stephen Colbert, Jon Stewart, the creator's of South Park, Conan O'Brien, Jay Leno, or Daniel Tosh? I love this project and working on it, and yes, I think 90% of the information here is correct, but we have to face the facts–no matter how "mainstream" we get in being where people find information (due to being so high on any Google search and for that reason ONLY) we are not ever going to be able to get over the stigmatism that we have been branded with. And I fail to see how this proposal of eliminating information through deletion in disregard for our policies on why to delete something in any way addresses the problem of not "being taken seriously".Camelbinky (talk) 20:26, 14 July 2011 (UTC)
- I know it's not supposed to be taken literally (god forbid Wikipedia ever go down that road), but I think that we should work with our publicity, not against it. I think this would be a good way to do so; others do not. Reasonable people can disagree. The Blade of the Northern Lights (話して下さい) 19:19, 14 July 2011 (UTC)
- "Sum of human knowledge": even Jimbo knows that, while that was a lovely turn of phrase, it's marketing copy that's flatly contradicted by WP:NOT. But, uh, if we're being taken seriously whether we like it or not, how is that compatible with scare language about how we need to do X in order to be taken seriously? If we literally cannot stop it from happening, sounds like we can relax as far as making it happen goes. —chaos5023 (talk) 19:02, 14 July 2011 (UTC)
- If Wikipedia's goal is to be a repository for "the sum of human knowledge", I'd think that being taken seriously is implied. If you don't think it is, you should perhaps Jimbo himself if his goal is to make this a serious project. And for what it's worth, we are being taken more seriously than we once were, so even if there's no consensus it's still happening, and we can't really fight that. The Blade of the Northern Lights (話して下さい) 18:48, 14 July 2011 (UTC)
- Does consensus exist that we want to be taken seriously? It sounds like more trouble than it's worth. —chaos5023 (talk) 18:45, 14 July 2011 (UTC)
- That's a straw man; I've been arguing for quality over quantity for a while now, and I've created one article (and I'm just about ready to move the other one into articlespace). It's not that creating articles is A Bad Thing, it's that we have to spend more time focusing on the ones that already exist. Compounding this problem is the fact that these unreferenced articles tend to be in groups; there are a huge number of unreferenced articles on India and Pakistan-related articles and higher-level science articles, for instance. We have to stop pretending that this isn't a major problem if we want to be taken seriously. The Blade of the Northern Lights (話して下さい) 18:41, 14 July 2011 (UTC)
- Really? Quality over quantity? Hmmm, that's an argument I've seen thrown around for the last three or four years... I guess every article created since then, and every one created from here on out, you will support for deletion because obviously the article isn't need, we are pretty much complete according your theory. I find that a weak argument. Guess I should stop creating new articles and just work on improving existing articles. And anyone else working on creating new articles is wasting their time as well.Camelbinky (talk) 21:24, 11 July 2011 (UTC)
- Strong support – any good-faith contributor uses sources when creating an article. How difficult can it be for them to copy-paste the URL or ISBN or whatever at the same time? Much easier and more helpful for them to do it than for other people to have to pick up the pieces. ╟─TreasuryTag►Syndic General─╢ 21:34, 11 July 2011 (UTC)
- Oppose Even creating legitimate articles as an experienced user is a pain (It is a race against time if not pre-prepared). As said above, adding references is nowhere near straightforward even with "cite doi", "cite pmid" etc. —there is no "cite isbn" though—! --Squidonius (talk) 21:05, 11 July 2011 (UTC)
- What about simply <ref> and </ref>. The ref doesn't have to be properly formatted, just there. - ʄɭoʏɗiaɲ τ ¢ 23:02, 11 July 2011 (UTC)
- Undecided but leaning oppose -I do worry about editor retention and difficulties of use for new editors. I have seen editors interpreting articles as unreferenced when new editors have left references at bottom of an article but not in inline format. I think the need for new editor retention currently outweighs the need for referencing from the outset, but I do think this is a proposal worth looking at as editor patterns change over the coming years. Casliber (talk · contribs) 21:36, 11 July 2011 (UTC)
- Comment, I several opposition statements related to the notion that the software would reject article creation, rather than humans tagging articles. I see several others opposed to a CSD concept, but Floydian clarified this should be a PROD or sticky prod approach. While a raw count shows a substantial number of opposes, the count looks very different if one identifies those talking about a sticky prod approach. Granted several are specific opposes to that concept, but the count looks very different.--SPhilbrickT 21:38, 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)
- *Strongly oppose, per StuRat's "this would scare off newbies, who would have no idea how to do that." If WP provided a "welcome" message that was useful, i.e. policies briefly and clearly explained (2-3 sentences each about WP:V, WP:NOR and WP:NPOV) and basic tools explained thoroughly (Edit Box, and use of browser's Back button; citation tools and {{reflist}}; watchlist so they can see what's happening to "their" articles), then there might be a case for being more stringent. --Philcha (talk) 21:51, 11 July 2011 (UTC)
- Oppose What matters is whether suitable sources have been WP:Published, not whether someone has figured out how to type up the names of the sources in the article. Deleting good, valuable, verifiABLE material on a notable, encyclopedic subject merely because the author didn't type up the name of the source is destructive and bureaucratic. The correct response to an unref'd article is to add the references, not to tag it for deletion. (And I can't tell you how many {{unref}}-tagged articles I've seen that actually do contain proper citations.) WhatamIdoing (talk) 22:48, 11 July 2011 (UTC)
- Oppose It's not sources which are the problem - Wikipedia is an encyclopedia not a search-engine. What matters more is that our own text should be accurate and well-written. As examples, consider a couple of articles created by the nominator of this proposal: Mod (video gaming) and Transcendental homelessness. The first case has several sources but they don't really support the topic. That article is poor quality and has been that way for 7 years now. The second article is even worse as it was written without much understanding of the topic. It ostensibly contains a source but the direct quotation which appears in the article is misattributed - when you read the source you find that "the urge to be at home everywhere" was in fact said by Novalis, not Lukacs. Warden (talk) 23:23, 11 July 2011 (UTC)
- In response to the first though, wikipedia is an encyclopedia, and so it should contain references. Our own text can only be verified as accurate if sources accompany it. The first article of mine you pointed out I wrote 7 years ago, when I was admittedly a terrible editor. Besides, times they are a changin', and what was acceptable in 2003 is not so much in 2011. When I wrote it, none of those sources were there, nor any discussion on the concept of modding a game. As for the second, it was a very difficult requested article which I randomly decided to take on. I bet you'd have had a much more difficult time finding out what you just did, and verifying what I wrote, had I not taken 15 seconds to include the source of the information I was adding. - ʄɭoʏɗiaɲ τ ¢ 23:44, 11 July 2011 (UTC)
- "wikipedia is an encyclopedia, and so it should contain references" Most encyclopedias don't contain references, so this is a non sequitur. We choose to name sources, but that's because of our preferences and our anyone-can-edit notion, not because we're an encyclopedia. WhatamIdoing (talk) 00:21, 12 July 2011 (UTC)
- Most print encyclopedia have articles written by paid writers, who are often identified, and who are experts in the field of the article. And many do include references, unless they are a "child's encyclopedia" or one given away a volume a week at the grocery store. Wikipedia is written by a mixture of dedicated experts, random volunteers with varying ability, good or bad intentions and knowledge, and anonymous POV pushers, loons and vandals. Edison (talk) 16:44, 13 July 2011 (UTC)
- I understand and agree with the reasons why we provide citations. That I like citations doesn't change the fact that "includes a list of references" is not a defining feature of an encyclopedia. A citation-free encyclopedia is still an encyclopedia. WhatamIdoing (talk) 20:46, 15 July 2011 (UTC)
- Most print encyclopedia have articles written by paid writers, who are often identified, and who are experts in the field of the article. And many do include references, unless they are a "child's encyclopedia" or one given away a volume a week at the grocery store. Wikipedia is written by a mixture of dedicated experts, random volunteers with varying ability, good or bad intentions and knowledge, and anonymous POV pushers, loons and vandals. Edison (talk) 16:44, 13 July 2011 (UTC)
- "wikipedia is an encyclopedia, and so it should contain references" Most encyclopedias don't contain references, so this is a non sequitur. We choose to name sources, but that's because of our preferences and our anyone-can-edit notion, not because we're an encyclopedia. WhatamIdoing (talk) 00:21, 12 July 2011 (UTC)
- In response to the first though, wikipedia is an encyclopedia, and so it should contain references. Our own text can only be verified as accurate if sources accompany it. The first article of mine you pointed out I wrote 7 years ago, when I was admittedly a terrible editor. Besides, times they are a changin', and what was acceptable in 2003 is not so much in 2011. When I wrote it, none of those sources were there, nor any discussion on the concept of modding a game. As for the second, it was a very difficult requested article which I randomly decided to take on. I bet you'd have had a much more difficult time finding out what you just did, and verifying what I wrote, had I not taken 15 seconds to include the source of the information I was adding. - ʄɭoʏɗiaɲ τ ¢ 23:44, 11 July 2011 (UTC)
- Oppose - a lot of Motor Racing reports start off well before 1 week of the race, without any references. This sort of proposal is just going to hinder. Ronhjones (Talk) 23:57, 11 July 2011 (UTC)
- Just going to hinder what? What the fuck are you on? Malleus Fatuorum 00:03, 12 July 2011 (UTC)
- Oppose This is not fixing a problem. Actually, I don't think it is even addressing something that is a problem. We get a significant number of new articles made that are on notable subject and they don't have references. We already have processes set up on how to improve those articles. And, on the other hand, we get a number of articles about garage bands and non-notable companies that do have references, it's just that they are referenced to the band's website or press releases. This proposal is not fixing a problem. Instead, I think it would lead to losing even more notable topics while not sufficiently diminishing the issue of non-notable articles that are being created. SilverserenC 00:20, 12 July 2011 (UTC)
- Moral support I don't think anyone here believes that our articles should go without references. As the encyclopedia anyone can edit, we are also the encyclopedia where anyone can make stuff up. Because of this, articles are only as strong as their references. However, I'm not very optimistic about the logistics of prohibiting uncited articles from being created. There are many ways to cite articles that might go unnoticed by casual editors. Unusual referencing formats such as embedded external links and plain text citations may go unnoticed by editors just looking for ref tags and a reflist. And forcing newbies to learn complex wikisyntax for references isn't the most welcoming gesture. This all being said, I would like to see Wikipedia move in this direction, but I don't know if we have the workforce required to properly police a PROD idea for unreferenced articles, and I surely wouldn't approve of any speedy criteria for unreferenced articles. ThemFromSpace 00:38, 12 July 2011 (UTC)
- Support. The extremist, open-source Randian Wikipediots are not considering what actually gets accomplished. They would rather lose the 99 sheep to save the 1. Fuck it. Let's break eggs and make omelletes. (And I say this having started out as one of the "let us build the house crew".)TCO (reviews needed) 03:00, 12 July 2011 (UTC)
- Strong Oppose WP:V does not mean you get to shoot on sight. Not having references initially or even for some time does not mean that it is not possible that an article soon meets our requirements for notability and verifiability. It simply means you need to go looking. Lots of people -- newbies and experienced editors alike -- who are on their way to crafting enormously good articles might start by writing something less than perfect, and that's just fine. Steven Walling 03:52, 12 July 2011 (UTC)
- Strong Oppose Not only would this bite the newbies and swallow them whole, it will invite massive amounts of false, fake, or unspecific sources that will be there for years. We already have enough crappily sourced articles, we don't need to be fanning the flames with our own policies. BETA 07:42, 12 July 2011 (UTC)
- So you're saying that by requesting that people source the information they write, we invite them to contribute fake, false, and unspecified sources? Maybe 1 of every 50, hardly a loss on a verifiable (by using the sources, not just that there is verification somewhere in the world) encyclopedia. - ʄɭoʏɗiaɲ τ ¢ 10:55, 12 July 2011 (UTC)
- Massive Oppose I'm just going to get down to the point - I have created hundreds of articles based on villages and hamlets in which they do not even have a pub or a phone box. Even though they are small, they do not even need sources because the OS Grid Reference that comes standard in the infobox and map of the village is a reference! I doubt that any of the articles that I had started would ever grow to a Start Class, so citations are no big deal for a paragraph long stub. Jaguar (talk) 09:05, 12 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)
- 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)
- Comment Oooooh, this is an interesting proposal. We want so many things from Wikipedia, but what we mainly want - the core of the project - is to present the sum of worthwhile human knowledge to everyone in a reliable and readable form. We had a huge problem with the "reliable" part for many years - and not just because of vandals messing around, nor even because of well meaning but poorly informed individuals reading an article and then adding some material they had vaguely heard somewhere once, but also because those at the very heart of the project were happily creating articles from a book or two they were reading, without putting in inline citations, and simply making honest mistakes which then couldn't be easily checked by other Wikipedians, but when someone knowledgeable on the subject read the article they would note the mistakes. We have to continue moving forward with our aggressive stance on ensuring that articles are not just theoretically verifiable, but are actually easy to check for all readers. Well meaning and experienced editors make mistakes. Articles get edited and material gets moved around. The ability to check the truth and accuracy of important statements is vital. I have seen simple mistakes on Wikipedia mirrored across the internet and then get enshrined in reliable newspapers and books. That's shocking. We have to get real about our responsibility and be rigorous in assisting editors and reader to verify the facts. References are not an aesthetic addition to articles, they are the articles. No article should be written without consulting a reliable source - and the source should be right there with the editor at the time of writing to make sure that there are no mistakes. If substantive material is added to an article at any point from creation onwards, the source(s) from which the material comes should be mentioned. That's basic. If someone is unable or unwilling to do that we should be encouraging them to stop editing articles and get involved in something else.
- 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)
- Support for those of you who haven't done NPP, you should look at the last 100 or so articles created on India and Pakistan-related topics; they're frequently in horrifically mangled English, full of puffery, and completely unreferenced (do a search for "is a beautiful village" or "is a beautiful town"; almost all of the hits are from Indian/Pakistani villages). There's no reason we should have articles like Kanju floating around in the state it's currently in (I don't give a fuck if it is a village and deemed "inherently notable", it's such a mess now that reworking it will require more effort than simply zapping it and restarting). I don't think we have to worry about WP:BITE as much as people seem to think, because many of these articles are written by people with no intention of helping the encyclopedia. And finally, it makes it much more difficult to detect vandalism; for an example see the edit history of Notak Bhakkar. It's a problem; I honestly think that more people will be willing to come here if they hear about Wikipedia's reputation for being a reliable encyclopedia than there will be if we start looking for new users at the expense of reliability. This is a good step in that direction. The Blade of the Northern Lights (話して下さい) 03:34, 13 July 2011 (UTC)
- And to those complaining about this being a lack of motivation on editors' parts; I'd point out that we're here as volunteers. Furthermore, if we remove content from articles for being unsourced, it seems perfectly logical that we should be able to delete pages that aren't sourced and don't have anything that would pass RS. It's not laziness, it's an attempt to build a reliable encyclopedia. If it means we can remove some incomprehensible puffery so someone can come along and start from scratch (see the links I provided above), it's an improvement over this need to try and preserve every bit of content even though we can't verify it's truthfulness. The Blade of the Northern Lights (話して下さい) 04:18, 13 July 2011 (UTC)
Require all new articles to contain at least one source: Do something
- Strong oppose Unsourced content can be sourced. If you're too lazy to do it yourself, then don't make a new rule as a result of laziness. Do something. /ƒETCHCOMMS/ 04:05, 13 July 2011 (UTC)
- When there are 256,000 unsourced articles, it isn't laziness, it's total disregard on the projects part to continue to allow this number to grow. By limiting that, the existing unsourced articles can then be more heavily focused upon. - ʄɭoʏɗiaɲ τ ¢ 10:44, 14 July 2011 (UTC)
- Right, but the solution to the ~260,000 unsourced articles isn't to get rid of the articles, it's to source them (with the caveat that some of them may actually need to be deleted... maybe not need, but we'd be better off deleting them. That would more likely be due to notability concerns though, not a lack of references). It's a question of perspective, I guess.
— V = IR (Talk • Contribs) 17:48, 14 July 2011 (UTC)- Floydian, I understand your frustration with new articles being created without any sources, but you seem to be implying that if we can only stop new articles with no sources from being created suddenly we can all start adding sources to the current number of unsourced articles. Well, you cant force editors to work on something they don't want to work on, it is not like there are plenty of editors out there that suddenly their time will now be freed due to your proposal and what they will now do is spend time adding sources to other articles. I wish I could make a policy change that caused people to stop tagging and ONLY go around editing and adding information to articles, but I cant. Your proposal assumes everyone is here to actually add information and sources to articles. They arent. You have admins who spend almost 90% of their time simply resolving disputes and blocking people who are "disruptive" and don't actually work on articles (which I think is terrible and THEY should be banned). There are 256,000 unsourced articles mainly because we don't have any editors who care about those subjects to actually work on them, and we cant force anyone to improve them either. We can only expand our stubs if we get new editors who have varied interests and want to work on different subjects. Your proposal will end up driving away new editors who have lower learning curves or who give up easier because of discourgement. The next future great editor who makes his/her lasting mark on Wikipedia may not (and probably doesnt) have high self-esteem and needs encouragement, not a speedily delete of their perfectly fine first article based on not having a source. Again, since you don't listen–deletion is because of notability, not quality. Your proposal is about quality. You cant have a policy change that is in conflict with other policy. Your proposal, even if gets a majority here, cant be used for deleting an article.Camelbinky (talk) 18:43, 14 July 2011 (UTC)
- Although... here's a thought. The "BLP problem" has been solved (supposedly), and scottmac and others are still around. Maybe we should talk someone into mass-prodding and/or deleting all unreferenced articles. That seems to get people to work on the articles, at least (eventually, anyway).
— V = IR (Talk • Contribs) 22:51, 14 July 2011 (UTC)- Many would be up-in-arms over a proposal like that. It is true that articles are polished rapidly when threatened, and that premise is a good encouragement to progress: That crap will be deleted if you don't improve it! The intention here is not deletion at all, but the improvement of articles. This simply puts a deadline on it, instead of there being no deadline. No deadline is fine for finishing the encyclopedia, but we've barely begun to start it! Maybe there are alternative to deletion, such as saying that if you don't add a source it will be moved into your userspace for you to continue your work, in a completely non-derogatory fashion of finishing your thought before you submit it. - ʄɭoʏɗiaɲ τ ¢ 23:17, 14 July 2011 (UTC)
- The only problem is that I have a real problem with taking such an approach. I was one of many who were "up in arms" the last time, and I think it was justified then and would be more justified now (especially since arbcom said something like "next time we're not going to be nice about this" when they gave the editors in question a free pass for being disruptive). I still think that a couple of people should have been kicked off the project for that little stunt, but... C'est la vie. Water under the bridge. etc... All of that being said, there may be merit in the "move them out of article space" idea. I'm not a fan of moving them to userspace though, because... articles seem to get lost that way, in a manner of speaking, you know? The "article incubation" idea has been kicking around for years, and is utilized to various degrees. What about extending and generalizing that, and coming up with a process to move unreferenced and "unready" (not speedyable articles, but maybe prodable articles as long as they don't have serious issues) to either somewhere in Wikipedia space or (better yet) to a namespace designed for it ("Incubator" is an obvious name).
— V = IR (Talk • Contribs) 00:12, 15 July 2011 (UTC)
- The only problem is that I have a real problem with taking such an approach. I was one of many who were "up in arms" the last time, and I think it was justified then and would be more justified now (especially since arbcom said something like "next time we're not going to be nice about this" when they gave the editors in question a free pass for being disruptive). I still think that a couple of people should have been kicked off the project for that little stunt, but... C'est la vie. Water under the bridge. etc... All of that being said, there may be merit in the "move them out of article space" idea. I'm not a fan of moving them to userspace though, because... articles seem to get lost that way, in a manner of speaking, you know? The "article incubation" idea has been kicking around for years, and is utilized to various degrees. What about extending and generalizing that, and coming up with a process to move unreferenced and "unready" (not speedyable articles, but maybe prodable articles as long as they don't have serious issues) to either somewhere in Wikipedia space or (better yet) to a namespace designed for it ("Incubator" is an obvious name).
- Many would be up-in-arms over a proposal like that. It is true that articles are polished rapidly when threatened, and that premise is a good encouragement to progress: That crap will be deleted if you don't improve it! The intention here is not deletion at all, but the improvement of articles. This simply puts a deadline on it, instead of there being no deadline. No deadline is fine for finishing the encyclopedia, but we've barely begun to start it! Maybe there are alternative to deletion, such as saying that if you don't add a source it will be moved into your userspace for you to continue your work, in a completely non-derogatory fashion of finishing your thought before you submit it. - ʄɭoʏɗiaɲ τ ¢ 23:17, 14 July 2011 (UTC)
- Although... here's a thought. The "BLP problem" has been solved (supposedly), and scottmac and others are still around. Maybe we should talk someone into mass-prodding and/or deleting all unreferenced articles. That seems to get people to work on the articles, at least (eventually, anyway).
- Floydian, I understand your frustration with new articles being created without any sources, but you seem to be implying that if we can only stop new articles with no sources from being created suddenly we can all start adding sources to the current number of unsourced articles. Well, you cant force editors to work on something they don't want to work on, it is not like there are plenty of editors out there that suddenly their time will now be freed due to your proposal and what they will now do is spend time adding sources to other articles. I wish I could make a policy change that caused people to stop tagging and ONLY go around editing and adding information to articles, but I cant. Your proposal assumes everyone is here to actually add information and sources to articles. They arent. You have admins who spend almost 90% of their time simply resolving disputes and blocking people who are "disruptive" and don't actually work on articles (which I think is terrible and THEY should be banned). There are 256,000 unsourced articles mainly because we don't have any editors who care about those subjects to actually work on them, and we cant force anyone to improve them either. We can only expand our stubs if we get new editors who have varied interests and want to work on different subjects. Your proposal will end up driving away new editors who have lower learning curves or who give up easier because of discourgement. The next future great editor who makes his/her lasting mark on Wikipedia may not (and probably doesnt) have high self-esteem and needs encouragement, not a speedily delete of their perfectly fine first article based on not having a source. Again, since you don't listen–deletion is because of notability, not quality. Your proposal is about quality. You cant have a policy change that is in conflict with other policy. Your proposal, even if gets a majority here, cant be used for deleting an article.Camelbinky (talk) 18:43, 14 July 2011 (UTC)
- Right, but the solution to the ~260,000 unsourced articles isn't to get rid of the articles, it's to source them (with the caveat that some of them may actually need to be deleted... maybe not need, but we'd be better off deleting them. That would more likely be due to notability concerns though, not a lack of references). It's a question of perspective, I guess.
- When there are 256,000 unsourced articles, it isn't laziness, it's total disregard on the projects part to continue to allow this number to grow. By limiting that, the existing unsourced articles can then be more heavily focused upon. - ʄɭoʏɗiaɲ τ ¢ 10:44, 14 July 2011 (UTC)
- Support - Would be a welcome improvement to keep off some of the endless rubbish article created everyday. The clarity would help newbies also. Regards, SunCreator (talk) 15:53, 17 July 2011 (UTC)
I think many users are misinterpreting the proposal
- BIG COMMENT FROM PROPOSER 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)
- 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)
- 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)
- 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)
- Well, perhaps you'll help me understand how deleting articles without citations reduces the number of deletions. Here's what happens now:
- 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).
- The NPPer (perhaps) happens to notice that it's a notable subject and tags it as {{unref}}.
- The article does not get deleted.
- You propose to change this to:
- Newbie creates an article on a notable subject, but does not type sources (into the first draft).
- The NPPer completely ignores any considerations like notability and tags it for deletion as containing zero citations.
- 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.
- User creates a sourceless article
- 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.
- 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)
- 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.
- 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)
- Well, perhaps you'll help me understand how deleting articles without citations reduces the number of deletions. Here's what happens now:
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. ╟─TreasuryTag►pikuach 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)
- 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)
- 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. ╟─TreasuryTag►pikuach nefesh─╢ 08:12, 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)
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. ╟─TreasuryTag►senator─╢ 09:47, 12 July 2011 (UTC)
- I'd rather see people explain their opposition now, so that I can come back in a few weeks with a more well-laid out plan. As it stands, 90% of those 42 opposes are based on newbie biting, which is an issue that can be solved with some thought. If you feel this discussion is unproductive, go do something productive! - ʄɭoʏɗiaɲ τ ¢ 10:49, 12 July 2011 (UTC)
- "brainstorming" is a good point and should be encouraged. The idea might have been better introduced at WP:VPI first. Rd232 public talk 11:45, 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)
- 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)
- Support - I support the atleast one source suggestion. I think it would increase the likelyhood of a notable article.--BabbaQ (talk) 11:51, 12 July 2011 (UTC)
- Support the principle; more discussion, of course, will be needed about the implementation.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); July 12, 2011; 14:57 (UTC)
- Oppose this attempt to further retard wikipedia's slowing growth. Protonk (talk) 22:09, 12 July 2011 (UTC)
- Perhaps you could pause to reflect on just how badly you phrased that. Rd232 talk 23:35, 12 July 2011 (UTC)
- What, specifically, should I reflect upon? Protonk (talk) 00:28, 13 July 2011 (UTC)
- "this attempt to further retard wikipedia's slowing growth" is literally an accusation of bad faith at the proposer, which surely you didn't mean. Rd232 talk 00:41, 13 July 2011 (UTC)
- That's a unique interpretation. I don't allege bad faith at all. I'm sure that the proposers have the best interests of wikipedia in mind but requiring one reference for all new articles is literally slowing the growth of articles and editors. Protonk (talk) 01:00, 13 July 2011 (UTC)
- Is English your first language? Because "attempt to further retard wikipedia's slowing growth" is certainly badly phrased. You meant something like "this would further retard Wikipedia's slowing growth". "attempt" implies that this retardation is the proposer's goal. Rd232 talk 10:36, 13 July 2011 (UTC)
- Are you being testy for a reason? In my opinion the function and purpose of this proposal are one and the same: to slow the growth of wikipedia. Scanning the support votes many of the claims made there are also linked to managing NPP, asserting that we shift from quantity to quality and dealing with an influx of perceived low quality articles. All of those things hinge directly on the reduction of growth--not incidentally. I chose my words precisely. I'm sorry you feel that bold claims about this dangerous and foolhardy proposal are signs of clumsiness or incivility. But that's your problem, not mine. 184.59.29.41 (talk) 16:59, 13 July 2011 (UTC)
- I'm not being testy at all. I'm disappointed by your responses, but at least your final reply clarifies a bit what you meant (though it still doesn't justify your original misleading phrasing; it's like saying "this is an attempt to chop off my arm" whilst omitting that the proposed chopping is to save your life, because the doctor reckons it's gangrenous.). Rd232 talk 23:40, 13 July 2011 (UTC)
- And again you misread me. Let me spell this out. As I can see it, the apparent motivation behind this proposal and all its perennial forebears is not amputation to save the patient but distrust and displeasure at what growing the editor community represents. A seemingly charitable read might be that editors supporting this proposal hope to gain only the good new editors and only the good new articles, but the naivete in that statement strikes me as a much graver charge to level. Insularity, of a sort, seems more likely as one potential motivation. See the remarks above and below coming from the (honest and good faith) concerns of NPPers--they all have a hard slog tagging and deleting hundreds of crappy new pages again and they want a reprieve. I don't begrudge them that desire, but I'm not going to mince words about what I feel it represents. Likewise the comments about changing circumstances. Again and again we hear comments to the effect of "this isn't 2001 anymore" or "we want to pivot away from quantity to quality". All of these appeals to changing circumstances (true or not) are grounded in a desire for lower growth of edit�����u�]GET http://twitter.com/statuses/user_tie good faith beliefs that reduced growth will not damage wikipedia. I disagree. Protonk (talk) 02:51, 14 July 2011 (UTC)
- Entering facepalm territory... nobody's objective is to reduce growth. The objective is to improve quality, and it may be that reduced quantity is a price worth paying, but that's quite different (and there are also definitional issues - is a reduction in should-be-deleted spam articles a reduction in quantity?). It's like saying "X's objective is to spend $10" when in fact X's objective is to have lunch. You may well disagree that the lunch is worth $10, but not mix up cost and benefit. PS "the apparent motivation behind this proposal and all its perennial forebears is not amputation to save the patient but distrust and displeasure at what growing the editor community represents." ... quite amazing. Been a while since I've seen such a completely ludicrous statement made with a straight face by an established editor. Rd232 talk 23:52, 14 July 2011 (UTC)
- Facepalm all you want. This proposal doesn't have consensus and won't in the foreseeable future. Protonk (talk) 03:18, 15 July 2011 (UTC)
- Not the issue - I'm not sure it's a good idea either, at least if done in the way most opposers think it would be. Rd232 talk 22:21, 15 July 2011 (UTC)
- Facepalm all you want. This proposal doesn't have consensus and won't in the foreseeable future. Protonk (talk) 03:18, 15 July 2011 (UTC)
- Entering facepalm territory... nobody's objective is to reduce growth. The objective is to improve quality, and it may be that reduced quantity is a price worth paying, but that's quite different (and there are also definitional issues - is a reduction in should-be-deleted spam articles a reduction in quantity?). It's like saying "X's objective is to spend $10" when in fact X's objective is to have lunch. You may well disagree that the lunch is worth $10, but not mix up cost and benefit. PS "the apparent motivation behind this proposal and all its perennial forebears is not amputation to save the patient but distrust and displeasure at what growing the editor community represents." ... quite amazing. Been a while since I've seen such a completely ludicrous statement made with a straight face by an established editor. Rd232 talk 23:52, 14 July 2011 (UTC)
- And again you misread me. Let me spell this out. As I can see it, the apparent motivation behind this proposal and all its perennial forebears is not amputation to save the patient but distrust and displeasure at what growing the editor community represents. A seemingly charitable read might be that editors supporting this proposal hope to gain only the good new editors and only the good new articles, but the naivete in that statement strikes me as a much graver charge to level. Insularity, of a sort, seems more likely as one potential motivation. See the remarks above and below coming from the (honest and good faith) concerns of NPPers--they all have a hard slog tagging and deleting hundreds of crappy new pages again and they want a reprieve. I don't begrudge them that desire, but I'm not going to mince words about what I feel it represents. Likewise the comments about changing circumstances. Again and again we hear comments to the effect of "this isn't 2001 anymore" or "we want to pivot away from quantity to quality". All of these appeals to changing circumstances (true or not) are grounded in a desire for lower growth of edit�����u�]GET http://twitter.com/statuses/user_tie good faith beliefs that reduced growth will not damage wikipedia. I disagree. Protonk (talk) 02:51, 14 July 2011 (UTC)
- I'm not being testy at all. I'm disappointed by your responses, but at least your final reply clarifies a bit what you meant (though it still doesn't justify your original misleading phrasing; it's like saying "this is an attempt to chop off my arm" whilst omitting that the proposed chopping is to save your life, because the doctor reckons it's gangrenous.). Rd232 talk 23:40, 13 July 2011 (UTC)
- Are you being testy for a reason? In my opinion the function and purpose of this proposal are one and the same: to slow the growth of wikipedia. Scanning the support votes many of the claims made there are also linked to managing NPP, asserting that we shift from quantity to quality and dealing with an influx of perceived low quality articles. All of those things hinge directly on the reduction of growth--not incidentally. I chose my words precisely. I'm sorry you feel that bold claims about this dangerous and foolhardy proposal are signs of clumsiness or incivility. But that's your problem, not mine. 184.59.29.41 (talk) 16:59, 13 July 2011 (UTC)
- Is English your first language? Because "attempt to further retard wikipedia's slowing growth" is certainly badly phrased. You meant something like "this would further retard Wikipedia's slowing growth". "attempt" implies that this retardation is the proposer's goal. Rd232 talk 10:36, 13 July 2011 (UTC)
- That's a unique interpretation. I don't allege bad faith at all. I'm sure that the proposers have the best interests of wikipedia in mind but requiring one reference for all new articles is literally slowing the growth of articles and editors. Protonk (talk) 01:00, 13 July 2011 (UTC)
- "this attempt to further retard wikipedia's slowing growth" is literally an accusation of bad faith at the proposer, which surely you didn't mean. Rd232 talk 00:41, 13 July 2011 (UTC)
- What, specifically, should I reflect upon? Protonk (talk) 00:28, 13 July 2011 (UTC)
- Perhaps you could pause to reflect on just how badly you phrased that. Rd232 talk 23:35, 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)
- Oppose, discourages new-user participation. - Jmabel | Talk 03:53, 13 July 2011 (UTC)
- Support It's the encyclopedia anybody is free to edit, not create. Typically (as a NPPer) I'll look at an article and read through it looking for notability claims and issues that I typically see. If it's unreferenced, I'll tag it as such, notify the author and any major contributor to the page, and move on. I'll come back to the page after a significant amount of time (a few weeks or more) and if I still see the same issues, I'll PROD it explaining the lack of sourcing and it's problems. To have any random editor or IP address come in and remove the PROD makes it a exercise in Bureaucracy to move this deletion on for unsourced reasons. I tend to let it lie quietly and non-speddily if it's obviously not garbage. Hasteur (talk) 17:47, 13 July 2011 (UTC)
- Strong Support for the sticky PROD idea. IMO, this version of the proposal strikes a good balance between preventing the addition of unsourced articles, and not discouraging new users. I also agree strongly with SPhilbrick that what was a good idea in 2001 is not necessarily a good idea now. RadManCF ☢ open frequency 19:50, 13 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)
- Support WP:V is a basic requirement for an encyclopedia article. Requiring "a reference" is not enough to show that something belongs in an encyclopedia, since the ref might not be "reliable" or "independent" and it might not have significant coverage, or it might be an offline source the article creator made up on the spot, but it is a start. I took a look at recently created new pages, and saw that most have one or more references. The creator of The Blue and The White House, for instance, likely could have added a reference if the interface requested it, since he seemed to be citing facts that would not be just things he remembered about the subject, and since he seemed to be familiar with Wikipedia mechanics such as Wikilinking and categorization. If I try to jump in and reference it, I would immediately be faced with looking for references in a language other than English, with many false results from the commonness of the keywords ("blue house" "white house"). A separate problem is editors who, to be at the top of the "most articles created list" find long lists of things found on some website and create hundreds of unreferenced stubs. They would have to stop their rapid article creation long enough to at least include the website where they got the information. Often newbies copy some website and paste the content to create an article. If they cited the source website, the copyvio would be evident, and perhaps the interface could decline the entry rather than deletinglater while slapping the copyvio template which looks like a public accusation of criminality.(Edited to add- Note: the creator later added a ref, and I noted 103 more hits from Google Book Search on the discussion page). Edison (talk)
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)
- 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.
- 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)
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:
- 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.
- 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.
- 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)
- There is a strong case for most articles to have a reference (or a link to another page where such sources can be found - as with the Pal Maleter article above - where 'see Hungary 1956' will provide sufficient references).
- We do not wish to frighten the newbies/occasional users: possibly a 'polite mention' on their talk page might suffice.
- There may be reasons for why references are not provided immediately - the author wishes to put #something# on WP and add details later etc.
- A requirement for #all# articles to have references immediately is likely to lead to WP-ians/newbies to either put in 'anything vaguely connected' (the Pal Maleter pine) - my comment above about allowing a certain grace period depending upon the nature and size of the article.
Anyone wish to summarise the rest of the discussions - and what would be practical proposals for dealing with the issue?
- Should we concentrate on dealing with 'short unreferenced articles' and 'creators of many unreferenced articles' - rather than 'occasional creators of such'? Jackiespeel (talk) 14:07, 14 July 2011 (UTC)
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 (T•C•V) 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)
- I genuinely don't see the advantage of Liquid Threads. I don't see how the current system is in any way broken or deficient. ╟─TreasuryTag►senator─╢ 11:22, 7 July 2011 (UTC)
- Well, we have: edit conflicts; messy archiving (and resulting broken links); need for each thread to happen at just one talk page; need to watchlist a whole talk page to follow just one thread. If LiquidThreads can solve these issues, I'm in favour. --Kotniski (talk) 12:09, 7 July 2011 (UTC)
- You also get the additional drawback of talk page spam and other undesirable posts requiring administrator attention to be properly removed (in the current system, they can be removed by anyone). MER-C 12:17, 7 July 2011 (UTC)
- The only real problem with edit conflicts is that they are not handled properly. It can't be so hard to make the automatic resolution of edit conflicts work much more often, and to ensure that when you only edited a section and got an edit conflict there, you only need to resolve the edit conflict in that section. The current system for manual resolution is completely useless on large pages and loads so slowly that even the back button responds way too late. All of this is fixed easily, and Liquid Threads has nothing to do with the solution. Hans Adler 22:38, 7 July 2011 (UTC)
- Well, we have: edit conflicts; messy archiving (and resulting broken links); need for each thread to happen at just one talk page; need to watchlist a whole talk page to follow just one thread. If LiquidThreads can solve these issues, I'm in favour. --Kotniski (talk) 12:09, 7 July 2011 (UTC)
- LQT is not ready for deployment on en.wp. mw:LiquidThreads 3.0/Phase 1 claims that it will be deployed around August, but knowing the foundation that's not going to happen (delayed in favor of... I'll let it speak for itself). It's looking like it's going to be forced upon us too. I've seen what they've been cooking up and it's not good -- it looks like a forum, feels like a forum and effectively functions like a forum... yet somehow it's not supposed to be a forum. (For the record, this is a strong oppose). MER-C 12:17, 7 July 2011 (UTC)
- LQT 2.0 is ready to rock, and is in widespread use already on several fairly high traffic Wikimedia sites. Besides, it'll take until August for this proposal to get anywhere anyway, based on the anti-change track record here. I think that it would be helpful to at least enable it in some places on en.wikipedia now, if only to allow people to get used to it. I'm aware that there is a somewhat significant (and vocal) minority of editors here who are opposed to anything "facebook like" being added, but... I don't know what to say to you guys exactly, except maybe "loosen up a little"? The addition of WikiLove hasn't caused any problems, after all. Don't be skeered. :)
— V = IR (Talk • Contribs) 12:31, 7 July 2011 (UTC) - You're completely misreading that policy. --Yair rand (talk) 12:54, 7 July 2011 (UTC)
- My point is that LQT deployment eliminates the important semantic difference between a WP talk page and a forum. It is plausible that a new user, on seeing a LQT enabled talk page and not being familiar the relevant policy will apply the duck test and treat it like a forum. MER-C 13:14, 7 July 2011 (UTC)
- LQT 2.0 is ready to rock, and is in widespread use already on several fairly high traffic Wikimedia sites. Besides, it'll take until August for this proposal to get anywhere anyway, based on the anti-change track record here. I think that it would be helpful to at least enable it in some places on en.wikipedia now, if only to allow people to get used to it. I'm aware that there is a somewhat significant (and vocal) minority of editors here who are opposed to anything "facebook like" being added, but... I don't know what to say to you guys exactly, except maybe "loosen up a little"? The addition of WikiLove hasn't caused any problems, after all. Don't be skeered. :)
- LQT is like the Duke Nukem Forever of wiki software. I'm in favor of some better system for discussion pages than the current ordinary wiki pages, just not necessarily LiquidThreads. It's been in development hell for as long as I can remember, and that's because (IMO) it was an attempt to reinvent the wheel based on a singular vision. It's a bulky and bloated mess of dynamic animations that don't seem appropriate or efficient for our purposes. I'd rather use existing proven forum software or at least something that's been systematically developed based on actual research and a solid plan, rather than the product of some hobbyist programmer's singular vision. Equazcion (talk) 12:52, 7 Jul 2011 (UTC)
- (hiya Equazcion, long time no see!
) I tend to agree with the idea that LQT isn't that great, but... unless and until something better comes along, I don't see any reason not to use LQT. It's not great, but it's certainly better than what we've got now (in my opinion). It is deployed on several Wikimedia sites already, as well. Also, not that Andrew Garrett, LQT's developer, is actually working for the WMF on a contract, specifically to develop LiquidThreads, so it's actually not "the product of some hobbyist programmer's singular vision." any longer (although that's certainly how it started).
— V = IR (Talk • Contribs) 13:08, 7 July 2011 (UTC)- Werdna/Andrew is who I was referring to. He's been developing it for as long as I can remember; I wasn't aware that someone else had started it before him, and his development of LQT always struck me as that "singular vision" I referred to -- one old Wikipedian making choices according to his particular vision of what Wikipedia discussion pages should be, instead of a more committee research and planning effort. This was a bad idea back then, and now after the years of muddling through I believe it's still a bad idea. Current wiki pages provide a sleeker discussion system regardless of their problems. Equazcion (talk) 16:03, 7 Jul 2011 (UTC)
- PS. I might be in favor of releasing LQT on large pages where a lot of real-time conversation happens (like ANI), and watchlisting individual discussions and eliminating edit conflicts are in dire need. Even there I would rather it be considered a temporary fix though. LQT is a move toward the more complicated and we should be thinking simpler instead. Watchlisting individual discussions and eliminating edit conflicts could be probably be resolved without the full-fledged, animated forum system. Equazcion (talk) 16:43, 7 Jul 2011 (UTC)
- Well, he has fairly consistently requested (even begged) for feedback, and has received some (although hardly enough, in my mind), which is actually a part of the reason for this proposal to enable it here and use it in a few limited places. I can't imagine it being "turned on" prior to LQT 3.0 being released anyway, which supposedly addresses a bunch of the concerns with usability that yourself others below are bringing up, so it seems like the time to get a feel for just how much resistance there is.
— V = IR (Talk • Contribs) 22:42, 7 July 2011 (UTC)- I know, he's requested feedback and gotten it, from myself and others. One consistent remark is LQT's general bulkiness, but he doesn't seem to agree that this is an issue; one example of the problem of how this is being approached. As much as he might be open to feedback, he's still one guy deciding on its direction. Equazcion (talk) 16:25, 8 Jul 2011 (UTC)
- Well, he has fairly consistently requested (even begged) for feedback, and has received some (although hardly enough, in my mind), which is actually a part of the reason for this proposal to enable it here and use it in a few limited places. I can't imagine it being "turned on" prior to LQT 3.0 being released anyway, which supposedly addresses a bunch of the concerns with usability that yourself others below are bringing up, so it seems like the time to get a feel for just how much resistance there is.
- (hiya Equazcion, long time no see!
- New LQT deployments are on hold. A number of other projects have requested LiquidThreads and had their requests marked as "RESOLVED LATER". --Yair rand (talk) 12:54, 7 July 2011 (UTC)
- Well, that's interesting. However, I don't see that as a show-stopper, primarily because of what I said above. I have absolutely zero expectation of this going anywhere today, tomorrow, next week, or even next month, due to the predisposition of users here to oppose any changes... although, by this time next month I expect to at least have a good idea of how much resistance there really is, here.
— V = IR (Talk • Contribs) 13:11, 7 July 2011 (UTC)- It seems quixotic, even self-destructive, to me to measure the resistance to a product that isn't what would actually be implemented and has numerous serious issues that the implemented product would not have. —chaos5023 (talk) 23:09, 7 July 2011 (UTC)
- Well, that's interesting. However, I don't see that as a show-stopper, primarily because of what I said above. I have absolutely zero expectation of this going anywhere today, tomorrow, next week, or even next month, due to the predisposition of users here to oppose any changes... although, by this time next month I expect to at least have a good idea of how much resistance there really is, here.
- I used to be in favour of LQT. Having actually used it over on Meta (I'm pretty certain it was Meta), I can only oppose in the strongest terms. It is confusing to navigate, hard to find what you want, and annoying to edit. → ROUX ₪ 14:08, 7 July 2011 (UTC)
- LQT isn't enabled on meta, you're probably confusing it with strategywiki. Since LQT is undergoing a huge redesign, and the finished version probably won't look anything like the current version, I don't really see why this is being discussed now. --Yair rand (talk) 14:21, 7 July 2011 (UTC)
- My bad, you're probably right. Either way my commentary stands. Essentially I am very much not in favour of oldschool Usenet-style mystery-meat navigation; I much prefer to be able to read whatever's going on without having to click interminably to get to what I want to see. → ROUX ₪ 14:28, 7 July 2011 (UTC)
- humm... maybe it would be a good idea to pull this until sometime after August, after all. I'll ping Werdna about it.
— V = IR (Talk • Contribs) 14:24, 7 July 2011 (UTC)
- LQT isn't enabled on meta, you're probably confusing it with strategywiki. Since LQT is undergoing a huge redesign, and the finished version probably won't look anything like the current version, I don't really see why this is being discussed now. --Yair rand (talk) 14:21, 7 July 2011 (UTC)
- I took a look on mediawiki and saw the screenshot of that thing, and I have to strongly oppose. This is an encyclopedia anyway, not a web forum, and that design will greatly encourage the use of talk pages as a general forum for the discussion of subjects. Reaper Eternal (talk) 15:41, 7 July 2011 (UTC)
- Oppose per Roux. I've used it elsewhere, too (can't remember where) and simply hated it. --Anthonyhcole (talk) 16:09, 7 July 2011 (UTC)
- Strong oppose Again? I have used LQT before, and while it is nice in some applications (such as the "comments" namespace for Wikinews), it only clutters talk pages by making them even larger with the extra buttons/formatting, and is frankly too complicated. What on earth is wrong with editing a simple page? I like my talk pages simple, tyvm. If anyone wants threaded conversations without LQT, see User:Fetchcomms/vector.css (stolen from fr.wp). Much cleaner and simpler, imo. /ƒETCHCOMMS/ 16:45, 7 July 2011 (UTC)
- I met the liquid threads developer and he is a great guy. However I don't know enough about it yet to know if it is ready for mass use. Graeme Bartlett (talk) 22:18, 7 July 2011 (UTC)
- Strongly oppose. I was exposed to Liquid Threads on the strategy wiki, and while it has some advantages, it has just as many disadvantages. The most important of these is a complete loss of the sense of location. I became totally disoriented on strategy wiki. Introduce this here, and if, after a couple of weeks, I don't regain my orientation I will find better uses for my time than editing Wikipedia. I am sure there is a huge contingent of other editors who will react similarly. It's not at all clear that the additional editors attracted by Liquid Threats, if any, will make up for this loss. Hans Adler 22:31, 7 July 2011 (UTC)
- Oppose There are many places on Wikipedia where people like to push a point of view, and it is essential that other editors can refactor, {{hat}}, or delete inappropriate or unduly repeated messages. It is not feasible to get an admin involved in every piece of nonsense (as I understand it, posts in LQT are private and cannot be edited except by the poster or an admin; also if an admin does delete a post, a funky place holder is shown where the post used to be, so talk pages will accumulate pointless crud). A more important reason to oppose LQT is the complete violation of WP:NOTFORUM that would follow—imagine using forum software to tell a spammer or POV pusher that "this is not a forum", and that if they post just one more reason why evolution is wrong or some living person is evil you will take half an hour to find an admin who might delete their posts. Johnuniq (talk) 23:29, 7 July 2011 (UTC)
Question:Oppose - Is there is a way to (A) disable the requirement for admins to remove content and (B) enable the creation of full-width drafts of articles within discussion pages? ~ Mesoderm (talk) 00:29, 8 July 2011 (UTC)- Each discussion is a separate page (example: strategy:Thread:Talk:Main Page/en/A new set of featured proposals is needed) so the answer to your first question is no. MER-C 02:49, 8 July 2011 (UTC)
- If that is the case, then I would have to say no. My primary concerns other than (a) and (b) are that it is aesthetically unpleasant and feels cluttered, but I wasn't going to vote if that was my only issue with it. However, forcing admins to deal with removing posts is a terrible idea, and will dramatically reduce our ability to maintain our standards for talk page content. ~ Mesoderm (talk) 03:13, 9 July 2011 (UTC)
- Each discussion is a separate page (example: strategy:Thread:Talk:Main Page/en/A new set of featured proposals is needed) so the answer to your first question is no. MER-C 02:49, 8 July 2011 (UTC)
- I don't like what I've seen of LiquidThreads either. It feels like bolting a forum interface onto Wikipedia. The only way I'd accept it is if it was deployed in parallel, so it is possible to see how many people prefer using the current talk pages, and how many prefer using the current system. Carcharoth (talk) 01:00, 8 July 2011 (UTC)
- Even if it were deployed Foundation Style(TM) I can see quite a few established editors redirecting their talk pages to explicitly avoid LQT. MER-C 02:49, 8 July 2011 (UTC)
- Support - When it comes to major technical changes, we have to assume that it will take at least half a year from time we get consensus for it to be installed. I don't support the current version of LQT, but I'll probably support what it'll look like next January. Mr.Z-man 01:44, 8 July 2011 (UTC)
- Oppose the entire question. This is a nonsensical exercise; we're effectively being asked to disregard the actual existing software and respond to the suitability of imaginary software that does not exist and cannot be tested or evaluated. This is goofy. There's a six-month lead time on forming consensus for a change of this magnitude, so you want to get started early? Tough. Consensus cannot even start forming until it has something that exists to form around. The only thing more nonsensical than opposing adoption under these circumstances is supporting it. —chaos5023 (talk) 01:50, 8 July 2011 (UTC)
- Oppose - think this is a solution looking for a problem. Edit conflicts happens everywhere, not only on talk pages, but on even busier pages such heavily edited mainspace. As an editor, I have, I believe, a very busy talk page; nevertheless, I do not get that many edit conflicts. On internet forums where I am active,including the WMF, I find those that have liquid threads are most confusing, and see no advantage in them. Kudpung กุดผึ้ง (talk) 04:47, 8 July 2011 (UTC)
- The WMF has a web forum? Where at?
— V = IR (Talk • Contribs) 10:43, 8 July 2011 (UTC)
- The WMF has a web forum? Where at?
- Oppose Having used liquid threads on other wikis, I've found no real advantage, and, like Hans Adler, a complete sense of disorientation in the system. Classic case of what we have isn't broke, so can we please not fix it? Courcelles 05:30, 8 July 2011 (UTC)
- Oppose Similar concerns as others. Plus, I've always thought of discussion pages as workspaces that have been unique to Wikipedia's culture. Pushing them to become forums is, at least to me, forcing people to work a certain—different—way, and you're possibly going to lose a lot of editors accustomed to the current format if you force a new system upon them. Exactly what magnitude of clear, demonstrable gain is there? Has there been any positive statistical significance in user feedback before versus after implementation of liquidthreads, or are we just assuming a rose-tinted world where everything will just magically get "better?" just 'cuz? --slakr\ talk / 06:59, 8 July 2011 (UTC)
- Exercise in Futility given that the only version that could feasibly be applied to Wikipedia is not available yet. LiquidThreads does have its place though. It has been said that a full consultation process will occur when the day comes, where we'll be able to have it tweaked to suit our needs. That day is not today. --Dorsal Axe 15:02, 8 July 2011 (UTC)
- We have been using it on Swedish Wikisource for some time. Unfortunately, I can not recommend it today. When a bug arise, it takes to long time to handle for bugzilla. -- Lavallen (talk) 15:21, 8 July 2011 (UTC)
- Moral Support (actual oppose) - discussions on enwiki are a broken incomprensible miasma of words - I appreciate the sentiment of this proposal, but sadly liquid threads in its current state is no better than what we have now. Sadly, unless the wikimedia foundation and the developers of mediawiki make user experience their highest priority will we see a solution to this problem - and I don't think that is likely. Edit- this edit was me not logged in (but the prior edit from that IP was not me) Ajbpearce (talk) 21:19, 8 July 2011 (UTC)
- I took a dislike to Liquid Threads when I tried it a while back, and I'm not sure that's ever going to change, unless it can somehow be set up as a front-end to wikitext (so that it's an optional interface for those as wants, and the wikitext is there as an option if someone wants to use it)... but I have doubts that that's even possible, never mind likely to happen. Rd232 public talk 22:38, 8 July 2011 (UTC)
- Exceptionally strong oppose per Fetchcomms. WikiPuppies! (bark) 22:43, 8 July 2011 (UTC)
- Very strong oppose. LiquidDreads (LiquidThreads) will spread replies down the page as 10x times longer (in IE or Firefox), but seems like 20x times more verbose as a presentation format. When I tried to tack very short replies inside a message node, then several users "refactored" the talk-page to expand my short replies into yet more separate verbose nodes, and thus further complicated, the base complexity, by annotated replies that my replies had been refactored, annotated and moved. It seems to foster "creeping messagism" where the multi-multi-message format is more important than the jist of the messages. Hence, Liquid Threads are a type of "form over substance" which insists on an extensive, drawn-out format, as if all messages must be formatted into Thread-speak to be allowed on the page. Imagine trying to tag, or redact, a prior message with "[citation needed]" or "[insult removed -Wikid77]" or similar, when replies inside nodes are often "forbidden". Liquid Threads is more verbose, more complex, and just too slow, compared to simple talk-page format. Sorry for the WP:Sarcasm as "LiquidDreads" but I have felt that way a long time. -Wikid77 (talk) 00:00, revised 00:06, 9 July 2011 (UTC)
- On one hand, in dealing with new users I think having threaded talk pages would be helpful for transitioning between Wikipedia and the rest of the web, where threaded comment schemes are common and chronological comment schemes are common, but the odd mix that we have is uncommon.
On the other hand, creating a system where only admins can delete even libelous or obscene comments would be, without hyperbole, a disaster. Given our decreasing number of admins and the unpleasantness of such a task, I can't see reason not to oppose this proposal. (If I have misunderstood how this works, please feel free to correct me, but do ping me, since I probably won't watch this conversation.)Danger (talk) 03:03, 9 July 2011 (UTC)- In the current deployed version, threads are editable by anyone. MER-C 10:36, 9 July 2011 (UTC)
- Yes, any libelous or obscene comments can be edited, as a separate edit, before an edit to reply, but I had forgotten about the drawback that obscene usernames cannot be removed, except by contacting an admin. Any posted username in LiquidThreads is "permanent" such as a message posted by a "User:President_xx_pimps his_wife" (which in normal talk-pages, that username could be easily removed by any editor).-Wikid77 15:03, 9 July 2011 (UTC)
- The username signature can be edited, actually. II | (t - c) 17:53, 9 July 2011 (UTC)
- Well in that case, I support for the above reason. Danger (talk) 02:49, 10 July 2011 (UTC)
- Support a basic liquid threads deployment so that new users can take part in discussions in a format that they may be used to. One of my main pet peeves is editors who make controversial edits but ignore warnings on their talk pages and never discuss anything. However, I suspect that for some of them it's easier to edit articles then talk pages. Imagine someone unfamiliar with wikipedia trying to follow up to a talk page thread (perhaps a deeply nested post) but instead of the post and a simple empty edit box to write their reply they get a whole bunch of wikitext and once they figure it out and hit save they get a message about something called an "edit conflict" and 2 pages of wikitext. How may of them just give up and keep doing what they are doing in article space until they're blocked? However, per all those above concerned with NOTFORUM and NOTMYSPACE, we don't need the "avatars", "mood bars", and "dashboards", K.I.S.S. --Ron Ritzman (talk) 16:14, 9 July 2011 (UTC)
- Support While I haven't tested LiquidThreads much, Wikipedia discussions are an enormous mess. LiquidThreads are organized, can be more easily integrated into the database/watched individually, and are pretty easy to edit. See this page for an example to play around with. II | (t - c) 17:53, 9 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)
- Consensus is oppose the introduction of LiquidThreads in en:Wikipedia, at least in the current form known. Ronhjones (Talk) 19:45, 10 July 2011 (UTC)}}
- I'd actually like to see a limited roll out of LQT now because of what happened with User:Danger's comment above. There is a lot of confusion about what can be done with LQT; how it behaves, and what user's and admins are allowed to do. We're all saying "do it" or "no way", but we're making those comments based on (very) incomplete information, since seemingly none of us are familiar with the system. I'd like something for the reasons that User:ImperfectlyInformed expressed below: Wikipedia's talk page system is messy. I recognize that the lack of structure on MediaWiki talk pages is often seen as advantageous, and it certainly does have it's benefits in some cases, but good discussion benefits quite a bit from some structure. LiquidThreads is being designed with the current system in mind at least, so it's not as though it'll be bolting on something completely foreign to the system.
As for the NOTFORUM arguments, I find those to be completely unconvincing. That "Wikipedia is not a forum" has nothing to do with the software itself, or the method in which talk pages work. "Wikipedia is not a forum" is about what people can and should be talking about on Wikipedia. The manner is which people are communicating is irrelevant to what they are talking about. Nothing about enabling LiquidThreads on Wikipedia can or will affect what types of discussions talk place onsite, it will only change the interface that those discussions take place on.
The most serious barriers to deployment that I see are 1) that the software isn't ready in some fundamental manner, and 2) that the interface itself is confusing (expressed well by User:Hans Adler, who described the largest problem as "a complete loss of the sense of location."). I'd just like to point out that the software is still under development, which pretty much covers both points for me. It's not as though traditional talk pages (such as this one) would completely go away if LiquidThreads were installed here, either. So... go ahead and keep "opposing" or "supporting" if you guys would like, but I think it would be useful to further address the question rationally, here. If there actually is a supermajority of editors who, as User:Hans Adler said above, will likely quit editing Wikipedia when LQT is rolled out here, then we really need to know that. The Foundation is paying for this software to be developed, so if it's never going to serve us then we should tell them to... change direction.
— V = IR (Talk • Contribs) 17:20, 13 July 2011 (UTC) - Support The software used to thread talk page discussions is nearly 12 years old. And it shows. We have to manually thread comments, we have competing methods of threading ("*" vs ":" vs "#" and various combinations of the three), we have edit conflicts which require work to undo, we have a half dozen other smaller technical problems. All of these present barriers to entry and friction for discussion. We need to switch to something more modern and I honestly don't care whether it is liquid threads or some other software. Protonk (talk) 19:46, 13 July 2011 (UTC)
- Oppose I don't see what benefits LQT has compared to the current system. Especially I still feel we would lose part of the great edibility the current system provides when introducing LQT. Toshio Yamaguchi (talk) 06:58, 14 July 2011 (UTC)
- Support. It's time. I've been pushing for it to be enabled for years now. It's efficient and easy to use. The features and benefits it provides will vastly improve discussion on Wikipedia. Though it does take some getting used to, and that's what usually puts off a lot people. -- Ϫ 10:07, 16 July 2011 (UTC)
- Hold until 3.0 – I think it would be beneficial for us to have talk pages more forum-like, as with just about the rest of all other discussions on the Internet. This is one thing in which I think we have been lagging behind in for quite some time, now. However, I am aware of the bugginess of the current version and the benefits that 3.0 is advertising about. Another reason I am not support-ing at this time is that I don't readily like the "separate discussion, separate page" thing, but I don't know if there is a better way to not have that and still keep everything else. –MuZemike 21:19, 19 July 2011 (UTC)
- Okay, this is getting ridiculous. "Hold until 3.0" is in fact the only option. Just to try and help people understand the situation, I'm copying a comment from Andrew Garret here:
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)
- 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.
- Now can we please close this utterly ridiculous discussion? --Yair rand (talk) 12:35, 20 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)
- Can only be edited by autoconfirmed/confirmed users:
- -Account has a minimum of 10 edits and is at least 4 days old
- -Or account is confirmed
- Note: This is currently what's in use for semi-protection
Semi-protection 2 (SP2)
- Can only be edited by users who
- -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
- Have at least X edits
- Suggestion of at least 1,000 edits
- Be at least X months old
- Suggestion of at least 3 months old
- Optional: have at least X mainspace edits
- Suggestion of at least 500 mainspace edits
Usage
- On pages where SP1 has found to be unsuccessful/less than what was expected.
What do you guys think? Elockid (Talk) 03:32, 16 July 2011 (UTC)
- Would this at all affect full protection? Also, right now I'm going to Oppose this right now because I predict that if the L2 semi-protection comes into existence, the L1 will just get used less and less, unnecessarily setting the bar for editing higher. If a few articles get attacked by socks, full protect them. No need to make it rough for the rest of the articles out there, Sven Manguard Wha? 03:52, 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)
- A software feature would be nice. Currently this is possible through some edit filter hackery, but it's quite inefficient. Another problem with temporary full-protections on indefinitely semi'd articles is that the temporary full protection overwrites the semi, so that when the full protection expires the article is left unprotected. T. Canens (talk) 15:15, 17 July 2011 (UTC)
- Pending changes sounds like the best solution to this problem. -- Eraserhead1
<talk> 15:21, 17 July 2011 (UTC)
- I agree that some kind of protection between semi and full would be useful. Yes, there is the theoretical risk that you end up with loads of pages at that level which would have otherwise been semi-ed, but it should be easy to stop that with a decent protection policy. You could do it with a combination of semi and PCPL2, but PC is in limbo at the moment... and requiring a bit more experience seems like a simpler solution. 1,000 edits and 3 months seems to be about the right level. Of course, if we did agree on something like this, someone would have to talk to the devs and get it implemented. Yaris678 (talk) 18:55, 17 July 2011 (UTC)
- Comment "Vandalism on articles especially BLPs are still present." this is not a problem, this is the essence of the open editing model that is Wikipedia. Articles will always have vandalism, no matter how 'closed' you make them. —TheDJ (talk • contribs) 20:06, 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)
- If the edit limit was 100 and all requests have to be through WP:RfPP so it can be looked at by an independent third party or via an WP:ORTS ticket I think I could support this. The effort to get accounts up to 100 good edits before making your socky edit is a pretty steep hill to climb and 10x higher than standard semi-protection, additionally 100 edits isn't that many that you are going to completely shut out potential legitimate contributors. -- Eraserhead1 <talk> 22:11, 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 suppose an edit filter could be set up to track such activity... --Jayron32 05:14, 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)
- Oppose I see a bit of (self congratulatory) discussion above, which is primarily what I'm responding to here. Any use of "preemptive" protection, semi-, pending changes, or otherwise, is unwanted (as is amply demonstrated by the results of the pending changed trial).
— V = IR (Talk • Contribs) 22:13, 20 July 2011 (UTC)- By pre-emptive, I assume you mean applied because there is expected to be a lot of vandalism, rather than there has been. That does not have to be the case with this 3/4 protection idea, any more than it would be with full protection. Yaris678 (talk) 11:24, 21 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)
- Oppose Creates a stigma against new users. The vast majority of new vandalism only accounts will typically be blocked before they become autoconfirmed. The new threshold only serves to artificially limit the set of good faith editors who can edit an article. Falls the fallacy that more active editors are better editors. Bad idea. i kan reed (talk) 14:35, 22 July 2011 (UTC)
- This isn't principally for dealing with new vandals. It is for dealing with persistent vandals and people with an agenda who have been banned who put a real and continuing effort into corrupting Wikipedia using a multitude of sockpuppets. Dmcq (talk) 20:31, 24 July 2011 (UTC)
- Double my opposition then There are means of dealing with persistant individuals evading bans, relating to IP bans. If POV pushing is occuring, a true lock is needed to help settle the issue rather than continue with a "elite only consensus". This is a bad idea, and only encourages users to get high edit counts for no reason. 10 edits for autoconfirmed is enough to establish a pattern of good faith editting. More than that promotes elitism on a meaningless number. i kan reed (talk) 19:53, 25 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)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- It is useful as it puts it in the appropriate image needed categories. Keith D (talk) 21:34, 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)
- 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)
- In the case some page needs a photo more urgently than others, the wikiproject take care of it by adding
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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.
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:
- Allow rangeblocks of up to /12 in IPv4;
- Allow rangeblocks of up to /36 in IPv6;
- 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
- Oppose From what I've seen on various boards and on the SPI freenode channel, the philosophy for blocking IP ranges is 'less not more'. I suspect that another reason that the threshold is there is that many admins don't really know rangeblocks terribally well, and without this threshold in place, could with the best of intentions block tens or hundreds of thousands of IP addresses. I would consider changing my vote if I see support from people whom I trust know more about rangeblocks than I do. Sven Manguard Wha? 05:09, 11 July 2011 (UTC)
- This is why I'm proposing that communal consensus is achieved before large blocks occur. Also, please read the article on IPv6 address to understand why I am requesting the rangeblock limit be raised for IPv6 especially.Jasper Deng (talk) 05:11, 11 July 2011 (UTC)
- 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)
- 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)
- I oppose raising the maximum range block size for IP4 - I once saw a discussion where a /14 block was a possible outcome, and that can be handled easily as 4 /16 range blocks. That only happened once that I know of; and allowing such blocks would be likely to make them much more common (and make /10 blocks similarly easy). עוד מישהו Od Mishehu 07:16, 11 July 2011 (UTC)
- Oppose bocking of anyone is done through a process that includes warnings, by the time a block occurs a number of editors have already been involved. The basic purpose of blocking an editor is to prevent further damage/disruption by requiring an an/i discussion as well will only serve to facilitate further disruption beyond where a block is the appropriate action. An after event range block discussion as to how wide the block should be is a different story, if its unintentionally affected too many editors then there will a blip of unblock requests which will also alert others to the issue, personally I'd rathe rbe caught up in an IP range block then to see the facilitation of further disruption/abuse of other editors. Gnangarra 10:49, 11 July 2011 (UTC)
- Oppose I still don't like the idea of going beyond /16, while a community consensus requirement, with some mechanism to stop blocks from going in without the consenus is a good compromise, I still am not convinced of the need. If if the abuse is really so bad as to justify a /12 block, it should also justify the time spent blocking the necessary /16s. Monty845 16:54, 11 July 2011 (UTC)
- Oppose - completely unnecessary and massively punitive on innocent editors. As a checkuser, I can attest that there's very seldom need for a rangeblock of this extent, and the collateral damage would be unacceptable - Alison ❤ 19:42, 11 July 2011 (UTC)
- Oppose introducing a range block above a /16 for IPv4, a /12 is 1/4096th of the IPv4 space :eek:. It seems reasonable to allow a reasonable range to be IPv6 blocked - I think a /48 sounds fine - a /48 gives the user 65536 LAN's - of which each one can have 18,446,744,073,709,551,616 IP addresses - there is no reason to give even a company like IBM or Apple more than a /48. -- Eraserhead1 <talk> 22:03, 11 July 2011 (UTC)
- Oppose the effect of one vandalous user in this size is going to be extremely diluted with a very big chance of collateral damage. If required 16 range block can be imposed, as any block this big is very serious. Graeme Bartlett (talk) 10:09, 12 July 2011 (UTC)
- Oppose - the ISPs that are really truly /12 or higher are basically not blockable under our policies/editor expectations. Though in the past there has been multiple abuse coming from these ISPs, sometimes at the same time, having even a /16 block on these ISPs can cause some major collateral damage. Smaller ranges won't be a problem for less troublesome ISPs. Having the ease to block larger ranges increases the possibility of accidentally blocking whole countries/large sections of countries. We already have the technical ability to block larger ranges. It's not super necessary. Elockid (Talk) 03:17, 16 July 2011 (UTC)
Second proposal !votes
- Support Shouldn't IPv6 blocks be available in the same size (as a proportion of total addresses) as IPv4? If IPv6 can only be blocked in increments smaller than /36 I would support raising that limit to at least /36, and even /16. Monty845 16:49, 11 July 2011 (UTC)
- Oppose Rangeblocks have nothing to do with proportions, it's a way of stopping vandals with access to a dynamic IP address setup from vandalizing. Just because the cake is bigger does not necessarily mean that the vandal is going to have access to more of the cake. Sven Manguard Wha? 17:27, 11 July 2011 (UTC)
- Actually, the allocation policies do warrant a larger rangeblock in IPv6. Please read IPv6 address allocation. IPv6 addresses are even more dynamic and spread-out than IPv4.Jasper Deng (talk) 17:28, 11 July 2011 (UTC)
- 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)
- It seems highly highly unlikely that any organisation will get a /36. -- Eraserhead1 <talk> 22:09, 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)
- 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)
- Support The technical ability should be there, and any controversial blocks can always be debated. I remember reading that Wikipedia could be totally locked down for updates, but I don't know how to do that! (0:0/0) Graeme Bartlett (talk) 10:06, 12 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)
- Support this, while I take your point about the US department of defense if anyone was going to get a crazy allocation it would be them. -- Eraserhead1 <talk> 18:44, 12 July 2011 (UTC)
- Support if the current limit is /64 that seems a little silly, perhaps reflective of the fact we don't support IPv6 yet. I'm a home user and I have an /48 subnet which is what some tunnel providers are handing out when a subnet is requested by an end user (altho some are moving to /56). [6] [7]. Note that as I understand it, if you are using a tunnel broker the default setup would usually require a subnet (or some would say two subnets) since there would be something like ABCD:EFGH:IJKL::1 for the remote tunnel end point (the server you're connected to), ABCD:EFGH:IJKL::2 for the local tunnel end point (your router) which make up one subnet and then you'd need at minimum another /64 subnet for the computers on your LAN. Nil Einne (talk) 12:41, 18 July 2011 (UTC)
- Support if end users will typically get /48 to /64 sized blocks, then a /48 seems reasonable for a range block. I was listening to a podcast the other day and the guy got a /48 IPv6 block from Cogent for his T1, so I guess that's in line with what the IPv6 address article says. Mojoworker (talk) 19:30, 19 July 2011 (UTC)
- Support – I think /48 is reasonable, but it ultimately depends on how IPv6 addresses are going to be allocated; from reading the last few articles regarding IPv6 (one of them has been linked above), /48 shouldn't be too bad. –MuZemike 19:10, 28 July 2011 (UTC)
Third proposal !votes
- Support While I disagree with going beyond /16 blocks, if that portion of the proposal does gain support, then I think the community consensus requirement is a good idea. Per my other opinion on IPv6 above, I would set the IPv6 rule to be the same as the IPv4, so more than /16 would require the community consensus Monty845 16:52, 11 July 2011 (UTC)
- Oppose Asking for community input on the proper application of rangeblocks is like asking for community input on the proper procedure during a surgery. The vast majority of users have no idea how rangeblocks work, at least beyond a conceptual level, and my experience has shown that for many contributors at consensus style discussions ignorance on a subject is not at all a barrier to participation. I'd love for large rangeblocks to get second opinion from people that normally do rangeblocks. I wouldn't like at all to see the community as a whole get involved. Sven Manguard Wha? 17:23, 11 July 2011 (UTC)
- The consensus discussion can be restricted to admins only, or only for certain users.Jasper Deng (talk) 17:24, 11 July 2011 (UTC)
- 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)
- 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)
- 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)
- 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)
- We can talk about any particular blocks or required blocks on WP:ANI. Any members of the community can participate in that. I don't think that there is any difference in from current practiced here. Graeme Bartlett (talk) 10:15, 12 July 2011 (UTC)
- Support per discussion below.TCO (reviews needed) 14:07, 12 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)
- 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)
- 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)
- Comment: A short-term /16 range block may be reasonable for an administrator to apply. However, longterm range blocks or range blocks of adjacent /16s should be reviewed with a checkuser prior to applying, because it has a direct impact on the accessibility of the project. Sometimes accounts presumed to be the same sockmaster are actually unrelated. First off, the greater proportion of IP edits are additions to the project and are not vandalism. Secondly, it prevents new editors from joining the project. Finally, it is unreasonable to prevent large numbers of editors and potential editors from contributing to the project over an extended period because of a single abusive editor/vandal. Bringing checkusers into the discussion can help administrators and other editors determine the best course of action for editors who are problematic over a large IP range. Risker (talk) 21:10, 13 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)Happy‑melon 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? Happy‑melon 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. Happy‑melon 16:56, 16 July 2011 (UTC)
Remove rightEdit: See Below - It takes about seven seconds to hop on the IRC and find a(n) admin(s). If the block was self imposed (either purposefully or accidentally) and everything is above board, chances are high that it will only take a minute or two to secure an unblock from said admin(s). Therefore this is unneeded. Sven Manguard Wha? 04:05, 16 July 2011 (UTC)- Not all (and in fact minority) of administrators use IRC. Ruslik_Zero 11:42, 16 July 2011 (UTC)
- Yes, but there are always a few there, and they're usually quite helpful. Non-regular users can click on the links at the Wikipedia IRC guidelines page to open up a browser based IRC connection where they can ask. Sven Manguard Wha? 17:35, 16 July 2011 (UTC)
- Last time I blocked myself by mistake I was unable to unblock myself. I had to email around until I found someone to help me out :-) Do not have access to IRC most of the time. And in fact never used it. Doc James (talk · contribs · email) 18:45, 16 July 2011 (UTC)
- I appreciate that it isn't common, however all it takes to get to the IRC is to click the green "connect" at this link. If you only block yourself once in your entire career, well this isn't too much to ask, at least in my opinion. Sven Manguard Wha? 19:29, 16 July 2011 (UTC)
- Yes at which point I get a pleasant message that content on this website is block by the sys admin.--Doc James (talk · contribs · email) 02:44, 17 July 2011 (UTC)
- If directly accessing IRC is not a viable solution for you, placing {{unblock}} or {{adminhelp}} on your talkpage, or emailing unblock-en-l@lists.wikimedia.org should provide a swift and easy means of attracting admin attention. Skomorokh 12:34, 17 July 2011 (UTC)
- Yes at which point I get a pleasant message that content on this website is block by the sys admin.--Doc James (talk · contribs · email) 02:44, 17 July 2011 (UTC)
- I appreciate that it isn't common, however all it takes to get to the IRC is to click the green "connect" at this link. If you only block yourself once in your entire career, well this isn't too much to ask, at least in my opinion. Sven Manguard Wha? 19:29, 16 July 2011 (UTC)
- Last time I blocked myself by mistake I was unable to unblock myself. I had to email around until I found someone to help me out :-) Do not have access to IRC most of the time. And in fact never used it. Doc James (talk · contribs · email) 18:45, 16 July 2011 (UTC)
- Yes, but there are always a few there, and they're usually quite helpful. Non-regular users can click on the links at the Wikipedia IRC guidelines page to open up a browser based IRC connection where they can ask. Sven Manguard Wha? 17:35, 16 July 2011 (UTC)
- Not all (and in fact minority) of administrators use IRC. Ruslik_Zero 11:42, 16 July 2011 (UTC)
- I really think this is a solution looking for a problem. The vast majority of self unblocks are made by admins who mistakenly block themselves, which is fairly easy to do. Since we have no systematic problem of admins unblocking themselves when they shouldn't be, why complicate matters by requiring use of the {{unblock}} template, or IRC, when the admin can simply unblock themselves instead? I've had an admin unblock themselves in order to block me in response to a block, and that was dealt with quite promptly. But I'd much rather have to call in help in that very rare situation than every time someone mistakenly blocks themselves. After all Sven, if every admin blocks themselves once in their career, that is 1500 unblock requests. Compare to the dozen or so admins who have abused unblockself. Prodego talk 19:57, 16 July 2011 (UTC)
- You've missed the point entirely: this thread began with a post including the key remark In light of the recent overhaul of security practices. The reason the status quo has persisted so long is for the reasons you give, which are fine as far as they go. But they have no relevance to the security issue of removing the ability to self-unblock. Rd232 talk 23:21, 16 July 2011 (UTC)
- I suppose what I am saying is that it isn't a security issue, or any other type of issue. In fact, it doesn't seem related to site security at all. Or is there something I am missing? Prodego talk 02:04, 17 July 2011 (UTC)
- It would be relatively simple to tweak the code so that removing self-blocks did not need the 'unblockself' permission. Would that be productive? Happy‑melon 05:15, 17 July 2011 (UTC)
- So, let's create 'unblockselffromstupidselfblock' permission. Ruslik_Zero 16:52, 17 July 2011 (UTC)
- To which I say "Why?". The current situation hasn't caused problems, avoids the issue Chris mentions below without any kludgy 'admin only' rate limits, and doesn't require any developer work. Creating a complicated system that we don't need and never have needed seems somewhat silly. Let's stick to solving problems that exist. Prodego talk 16:59, 17 July 2011 (UTC)
- So, let's create 'unblockselffromstupidselfblock' permission. Ruslik_Zero 16:52, 17 July 2011 (UTC)
- It would be relatively simple to tweak the code so that removing self-blocks did not need the 'unblockself' permission. Would that be productive? Happy‑melon 05:15, 17 July 2011 (UTC)
- I suppose what I am saying is that it isn't a security issue, or any other type of issue. In fact, it doesn't seem related to site security at all. Or is there something I am missing? Prodego talk 02:04, 17 July 2011 (UTC)
- You've missed the point entirely: this thread began with a post including the key remark In light of the recent overhaul of security practices. The reason the status quo has persisted so long is for the reasons you give, which are fine as far as they go. But they have no relevance to the security issue of removing the ability to self-unblock. Rd232 talk 23:21, 16 July 2011 (UTC)
- Neutral - On the one hand, my original reasoning still convinces me, on the other hand, ƒetchcomms makes an excellent point below. Sven Manguard Wha? 19:38, 19 July 2011 (UTC)
- Keep right Keep things simple. Doc James (talk · contribs · email) 02:45, 17 July 2011 (UTC)
- Retain per Prodego. If an admin goes rogue, (temporary) desysopping is the correct action. Also, imagine a rogue admin mass-blocking legit admins who would be unable to unblock themselves. If there is a problem with admins, it is escalated to the Bureaucrats, this being their purpose. --Cybercobra (talk) 04:17, 17 July 2011 (UTC)
- Keep right, I would argue that this decreases site security. Admin account is compromised, writes a script that blocks all active admins (in order of their last edits), they can no longer unblock themselves, we now have no admins until a steward comes around. --Chris 04:54, 17 July 2011 (UTC)
- (a) if the Doomsday block-everyone rogue scenario is the problem to be solved, this is not the solution to that problem. By contrast, point 3 in my alternate proposal is a solution to that problem. In essence, you're suggesting that we shouldn't fix a bug because we're relying on the existence of the bug to do something. That's bad design. (b) in that scenario, you're overlooking bureaucrats, who should still be able to unblock themselves. This proposal is only about admins. Rd232 talk 11:31, 18 July 2011 (UTC)
- Actually, I wasn't addressing your solution at all (I will admit your does seem mildly saner, but is not a proper solution to the security problem; if we are going down that path, we might as well just install mw:Extension:EmergencyDeSysop which provides an easy solution to the problem). (b.) I highly doubt the chances of a bureaucrat being around to solve the problem (it would be faster for a steward to arrive). Also, what happens if a bureaucrat's account is compromised? --Chris 09:46, 19 July 2011 (UTC)
- Hm, I didn't know mw:Extension:EmergencyDeSysop existed (it's a thought I had myself a while back). I've adopted that instead in an alternate proposal below. Rd232 talk 16:10, 19 July 2011 (UTC)
- Actually, I wasn't addressing your solution at all (I will admit your does seem mildly saner, but is not a proper solution to the security problem; if we are going down that path, we might as well just install mw:Extension:EmergencyDeSysop which provides an easy solution to the problem). (b.) I highly doubt the chances of a bureaucrat being around to solve the problem (it would be faster for a steward to arrive). Also, what happens if a bureaucrat's account is compromised? --Chris 09:46, 19 July 2011 (UTC)
- (a) if the Doomsday block-everyone rogue scenario is the problem to be solved, this is not the solution to that problem. By contrast, point 3 in my alternate proposal is a solution to that problem. In essence, you're suggesting that we shouldn't fix a bug because we're relying on the existence of the bug to do something. That's bad design. (b) in that scenario, you're overlooking bureaucrats, who should still be able to unblock themselves. This proposal is only about admins. Rd232 talk 11:31, 18 July 2011 (UTC)
- Unblocking oneself is strongly discouraged by the current blocking policy. Whether you're in favour or against the right, it must be granted that keeping a right that only allows you to do something that is strongly discouraged by policy is an exceedingly strange decision. Skomorokh 12:34, 17 July 2011 (UTC)
- Obvious keep Very very very rarely does an admin unblock themselves from a legit block without getting immediately desysopped. But more frequently, admins block themselves--for practice or experimenting, for enforcing breaks, by accident, etc. This is a solution looking for a problem. /ƒETCHCOMMS/ 13:37, 17 July 2011 (UTC)
- Either remove it and allow for self-blocks to be removed regardless of the permission, or keep it. I don't really care either way. T. Canens (talk) 15:16, 17 July 2011 (UTC)
- Keep permission Prodego hits the nail right on the head. Salvio Let's talk about it! 15:34, 17 July 2011 (UTC)
- Remove right per Skomorokh. If you want to block yourself, set the block to expire in a few minutes or wait for someone else to find your unblock template. Or you can create an acknowledged alternate account (many of us admins have them already, if for no other reason than password security) and block it. Let's look at the Robdurbar case for examples — yes, Robdurbar blocked several admins, and they were right to unblock themselves, but the situation would have ended far faster if Robdurbar hadn't kept unblocking himself every time that he was blocked. If the right be removed, and if such a situation ever happen again, it will stop as soon as someone blocks the rogue, and that person can then check the rogue's log and unblock everyone who shouldn't have been blocked in the first place. Nyttend (talk) 17:43, 17 July 2011 (UTC)
- Please see my counter point about how this creates a worse situation. --Chris 03:31, 18 July 2011 (UTC)
- Comment Sometimes solutions create other problems. Doesn't mean, though, that the solution shouldn't be considered. The concern here is about a security violation of an admin account, and limiting that concern by having a block on a potential rogue admin become fixed. The usual process, as far as I'm aware, for such a situation is an emergency desysop via Wikipedia:Arbitration_Committee/Procedures#Removal_of_permissions. I feel that emergency desysop is still the best route to follow, and if it is felt that the process outlined at Wikipedia:Arbitration_Committee/Procedures#Removal_of_permissions is potentially too slow or cumbersome, then perhaps a discussion on how to speed that up might be appropriate. SilkTork ✔Tea time 11:52, 18 July 2011 (UTC)
- Remove right If we had done this first, all this hulabaloo about giving bureaucrats the right to desysop admins could have been made unnecessary. Removing this right means a compromised admin accounts or vandal use of sysop tools can be handled by any sysop instead of a small handful of highly trusted users. If an admin accidentally self-blocks, we have {{unblock}} for that, where there is practically never a backlog. Regards, causa sui (talk) 16:53, 18 July 2011 (UTC)
- Remove right per previous arguments. Someone (voting to keep) above said 'keep it simple' and I agree. We can simplify the software by removing the right altogether. Admins should not unblock themselves. If they want to test blocks, use a short block or the unblock template. If they want a wiki-break, just walk away - blocking your own account to enforce a break is meaningless if you retain the ability to unblock yourself at will. Agree with all of Rd232's arguments, there are no compelling reasons to keep this right, and several to remove it. TechnoSymbiosis (talk) 04:33, 19 July 2011 (UTC)
- Remove right from admins per the above arguments. The fact that the current situation is adequate is a poor argument for not making it better (more logical, more streamlined). I'd support adding this right to the bureaucrat bundle though as a limitation on rogue abuse, but it isn't crucial. Eluchil404 (talk) 06:57, 19 July 2011 (UTC)
- Keep right. Let's consider this practically. If the reason for removing this right is to improve security (i.e. preventing a compromised admin account from doing damage), consider that a person who gains control of an admin account could simply script-block all the current admins and bureaucrats, and none of them could unblock themselves to intervene, so the account could continue to go on a rampage restoring, deleting and moving pages around unhindered until a steward could be found to emergency-desysop them. This is not a step in the right direction, IMO. 28bytes (talk) 13:39, 19 July 2011 (UTC)
- Erm, you're stating that argument as if it's novel; it isn't, and has already been responded to. See also Alternate Proposal 2 below. Rd232 talk 16:10, 19 July 2011 (UTC)
- No, I read your alternate proposal. But this proposal doesn't include the throttling, and is still in danger of reaching consensus, so it needs to be opposed. 28bytes (talk) 17:00, 19 July 2011 (UTC)
- OK, fair enough, but then we're in that special limbo that always makes me think this proposal should have gone to WP:VPI first. If these kinks had been sorted out first, we'd probably be on the way to consensus for something sensible. As it is, we're kinda stuck, because the Doomsday scenario seems to some to preclude saying yes to the current proposal, but others who are saying yes would surely support some measure or other to preclude the Doomsday scenario. How do we stop this CENT-listed train? Rd232 talk 20:15, 19 July 2011 (UTC)
- No, I read your alternate proposal. But this proposal doesn't include the throttling, and is still in danger of reaching consensus, so it needs to be opposed. 28bytes (talk) 17:00, 19 July 2011 (UTC)
- 28bytes, your argument appears to neglect the inverse. You say a rogue admin could use a script to automatically block other admins and then wreak havoc until a steward intervenes. What is to prevent them right now from using a script that repeatedly unblocks themselves (since they have that power), repeatedly blocking other admins (requiring them to manually unblock themselves, disrupting their ability to intervene) and similarly wreak havoc until a steward intervenes to desysop them? At least if the admin is not able to unblock themselves, there's a chance an unblocked admin may be able to intervene early to prevent disruption, and leaves steward intervention as a last resort. The current situation, as you propose we keep, offers no remedy whatsoever until a steward intervenes to remove the bit. TechnoSymbiosis (talk) 01:32, 20 July 2011 (UTC)
- Exactly - either way can be abused. As it currently is sysops can also undo mistaken blocks of themselves. So that makes the current situation better. Prodego talk 01:55, 20 July 2011 (UTC)
- Why can't they use {{unblock}} like everyone else? If they have indeed accidentally blocked themselves, they should be unblocked in short order. Why do they need a special power to unblock themselves when we have existing remedies for unblocking? TechnoSymbiosis (talk) 02:28, 20 July 2011 (UTC)
- Exactly - either way can be abused. As it currently is sysops can also undo mistaken blocks of themselves. So that makes the current situation better. Prodego talk 01:55, 20 July 2011 (UTC)
- Erm, you're stating that argument as if it's novel; it isn't, and has already been responded to. See also Alternate Proposal 2 below. Rd232 talk 16:10, 19 July 2011 (UTC)
- Keep userright - My reasoning is this: We should be able to trust our admins to not unblock themselves from a legitimate block. If, however, we have an admin willing to so flagrantly ignore policy, then yeah, let him/her unblock him/herself so we know who s/he is and let ArbCom desysop him/her. Additionally, if admins accidentally block themselves, they should be able to unblock themselves. In the extremely rare event of a rogue sysop account, chances are that s/he would just look at the block/delete/protect logs and script-block all the admins who are currently active. As there appear to be less than 30 active admins at a time, this could easily be accomplished in 3 seconds or less using API.php. Then the rogue admin could do whatever s/he wanted until a 'crat or steward desysopped him/her. Reaper Eternal (talk) 16:58, 19 July 2011 (UTC)
- I've read this discussion and agree with the points Pedro and Cybercobra made. This is a solution looking for a problem. Rogue admins who unblock themselves can be desysopped by a steward temporarily. Removing unblockself could create more damage than good. Steven Zhang The clock is ticking.... 21:29, 19 July 2011 (UTC)
- Keep permission -- anyone who abuses it will shortly no longer be able to abuse it. No evidence of rampant misuse. --SarekOfVulcan (talk) 17:24, 20 July 2011 (UTC)
- Keep permission per Reaper Eternal; it is a litmus test of a sysop's legitimacy. No reason why admins in good standing should need to have the right removed. LessHeard vanU (talk) 20:38, 20 July 2011 (UTC)
- Remove permission - no admin worth his salt would ever use it therefore it is not needed. Setting admins up to fail by giving them a tool they should never use seems a bit like planting a nice fruit tree in a garden and telling the inhabitants not to eat of it. Not a nice trick to play. DuncanHill (talk) 20:46, 20 July 2011 (UTC)
- Please bear with me. First, I want to say that I do sort of agree with Prodego and Fetchcomms that this is a solution looking for a problem, basically. I'm not an admin, so maybe I can't judge this, but I actually think that it would be rather rare for an admin to block themselves accidentally. Please do correct me with endless log entries as necessary. As for testing, this can easily be done at the Test Wikipedia, for example. As for enforcing wikibreaks, that's a pretty ridiculous block reason anyways. To arrive at my point, if admins blocking themselves accidentally is a major issue, we could have something like a unblockselffromself and whatnot, to allow admins to unblock themselves, only if the block in question was placed by themselves. Before somebody rejects this just because it's not implemented, I would like to say that I have some experience with MediaWiki development and it would probably not be very hard to implement such a thing. I shall work on a patch for this myself. — Waterfox ~talk~ 21:06, 23 July 2011 (UTC)
- Oppose removing the right, if an admin should get blocked, it should be temporary de-sysop and then block. But when blocking is required for testing, block yourself and then unblock when done. Just like, if a sysop blocks another sysop for a good reason, the blocked sysop should assume good faith and not unblock self. ~~EBE123~~ talkContribs 13:08, 23 July 2011 (UTC)
- OMGchange! Stop it! Stop it! Stop it!. Seriously, the amount of resistance around here to any kind of change, no matter how non-consequential, is just mind-boggling and sad. Admins used to be able to continue doing all admin actions even while blocked (There was that one case of a blocked admin who continued to use rollback to revert vandalism), including unblocking anyone (including themselves). Now blocked admins cannot do admin actions any more when blocked. That makes sense. The fact that they can still unblock themselves is just a remnant of all this, and the arguments to keep things that way are not convincing, to say the least: "What if an admin automatically and instantly blocks everyone?" Well, what if an admin automatically and instantly unblocks himself? "It's a test. Admins should not unblock themselves and if they do, de-sysop them." If they should't do it, don't let them do it. We could just as well create a "block everyone" button that would de-sysop anyone who pushes it. That's just.. silly. "It's needed for testing." No, it's not. Any kind of testing can be done without blocking yourself. This is such a minor change, would it really hurt so much to have it implemented? --Conti|✉ 03:03, 25 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. Happy‑melon 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. |
Rd232 talk 13:14, 17 July 2011 (UTC)
|
Alternate proposal 2
- 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.
- Remove the ability of admins to amend, reblock or unblock themselves unless they're the ones who blocked themselves.
- 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)
- I'd prefer to see the EmergencyDeSysop extension debated separately. I think it alone is a better solution than bundling all three changes. 28bytes (talk) 17:06, 19 July 2011 (UTC)
- Well for me they're complementary; making sense as a bundle; and people can say "support x but not y" etc. Rd232 talk 17:38, 19 July 2011 (UTC)
- Support this too. I don't see why not. It would be years before anyone had cause to use it, it would be very good to have it when needed, and the potential for abuse is quite low. --causa sui (talk) 21:39, 19 July 2011 (UTC)
- Comment Have there been issues with people inappropriately unblocking themselves that have not been managed with current guidelines?Doc James (talk · contribs · email) 21:41, 19 July 2011 (UTC)
- Probably, but that's not the point. The point is there no good reason to be able to do this, and in security terms it's not good. Rd232 talk 23:34, 19 July 2011 (UTC)
- Oppose - Countdown until abused ... 5 ... 4 ... 3 ... 2 ... . I can see this being used on the flimsiest of pretexts leading to pointless drama. Besides, this feature virtually guarantees that rogue admins wanting to go out in a blaze of glory will take someone with them (I guess they have to do something now that you can't delete the main page any more). --B (talk) 23:11, 19 July 2011 (UTC)
- A rogue admin / compromised account desysopping one admin at the cost of desysopping themselves does not exactly sound like a "blaze of glory" to me... And an inappropriate desysopping under mw:Extension:EmergencyDeSysop is necessarily limited to one case, and not difficult to fix. As for "pointless drama" - that would be covered by policy; EmergencyDeSysop is precisely emergency desysop and it's an action that can be regulated by policy in the usual way, and would surely be far more circumscribed than blocking policy. Rd232 talk 23:34, 19 July 2011 (UTC)
- What about a wheel war? I block a user. The user is unblocked. I reblock them. The user is unblocked. I reblock them again. Is there an "emergency" here justifying the non-crat/non-steward desysopping? What if I reblocked three times? What if it was only once? What if I blocked a user who complained about it? I'm sorry, but there's too much room for scope creep here and having the feature leaves it open to the line getting moved further and further in the permissive direction. I'd rather keep the desysopping capability in the hands of only a very small number of people who are personally known and accountable to the Foundation - not to anonymous admins. --B (talk) 00:12, 20 July 2011 (UTC)
- Funny how we generally trust admins to follow policy, and the community to sort out problems with exceptions to that. Why would this not apply to policy on EmergencyDeSysop? Also, unlike any other policy deviation I can think of, misuse of EmergencyDeSysop is self-limiting (you can only do it once, and won't get your own sysop bit back if the use wasn't covered by the policy). Rd232 talk 09:28, 20 July 2011 (UTC)
- What about a wheel war? I block a user. The user is unblocked. I reblock them. The user is unblocked. I reblock them again. Is there an "emergency" here justifying the non-crat/non-steward desysopping? What if I reblocked three times? What if it was only once? What if I blocked a user who complained about it? I'm sorry, but there's too much room for scope creep here and having the feature leaves it open to the line getting moved further and further in the permissive direction. I'd rather keep the desysopping capability in the hands of only a very small number of people who are personally known and accountable to the Foundation - not to anonymous admins. --B (talk) 00:12, 20 July 2011 (UTC)
- A rogue admin / compromised account desysopping one admin at the cost of desysopping themselves does not exactly sound like a "blaze of glory" to me... And an inappropriate desysopping under mw:Extension:EmergencyDeSysop is necessarily limited to one case, and not difficult to fix. As for "pointless drama" - that would be covered by policy; EmergencyDeSysop is precisely emergency desysop and it's an action that can be regulated by policy in the usual way, and would surely be far more circumscribed than blocking policy. Rd232 talk 23:34, 19 July 2011 (UTC)
- Oppose there is a reason that extension has never been used - because letting admins desysop each other is a horrible idea. Prodego talk 01:11, 20 July 2011 (UTC)
- Why? (And why have you phrased it in a way that lets the Emergency in EmergencyDeSysop slip away?) Rd232 talk 09:28, 20 July 2011 (UTC)
- I don't think you've understood the proposal. Presumably (Rd232, correct me if I'm wrong), an admin who abuses this (and there will be very few) will not be getting their sysop bit back, whereas the person they desysoped will. --causa sui (talk) 16:49, 20 July 2011 (UTC)
- Support all points as reasonable. Set clear bright line rules on when the emergency desysop can be used. Consequences for misuse are clear - you don't get your bit back. If we trust admins to be able to appropriately block users who cannot unblock themselves, I don't see why we can't also trust admins to be able to appropriately desysop admins who cannot resysop themselves. There are remedies for blocked users in the event a block is misused, and there should be equivalent remedies for desysopped admins in the event an emergency desysop is used. Adminship is a job, not a privilege, it shouldn't come with special protections. TechnoSymbiosis (talk) 01:22, 20 July 2011 (UTC)
- Support—seems like a very smart solution. Anyone who abuses it, in doing so, guarantees that they won't be able to abuse it again. ╟─TreasuryTag►Odelsting─╢ 16:53, 20 July 2011 (UTC)
- Cautions Support - If the emergency desysoper was correct in his action, xe'll get xis mop back easy and quick. If the desysoped admin was wrongly victimized, xe'll xis mop back easy and quick. As long as getting the mop back, if the person who loses the mop has done no wrong, then this isn't troublesome. Sven Manguard Wha? 18:07, 20 July 2011 (UTC)
- Oppose - After that fiasco where ScottMacDonald went rogue, blocked me, and got implicit Arbcom support for his actions, I'm tempted to say that admins shouldn't even be able to block each other.—Kww(talk) 18:25, 20 July 2011 (UTC)
- Oppose Agree with Kww admins should not be able to block each other. More discussion is usually required for these decision. If only to keep drama to a minimum. Doc James (talk · contribs · email) 21:15, 20 July 2011 (UTC)
- Removing unblockself seems sensible as a security measure considering the risk of consequences from a compromised admin account. However, if it was themself who did the block, they should be able to undo it. --SmokeyJoe (talk) 03:42, 23 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)
- Oppose, Bureaucrats would be better at that. ~~EBE123~~ talkContribs 12:33, 24 July 2011 (UTC)
- Oppose. The current system works. Why do we need these changes? Seems like a solution looking for a problem. Also, if an admin became compromised or went rogue, it would give him more power to disrupt Wikipedia, while taking power away from other admins. For example, an admin goes postal and blocks everyone they see. Under the current system, any of the wrongfully blocked admins can just unblock themselves and indef the rogue one, who will be desysopped reasonably quickly, even if they unblock themselves a couple of times. If we accepted the above package, the admins who were wrongfully blocked would be able to desysop the rogue admin, but they wouldn't be able to unblock themselves or block the disruptive one, who could still go on disrupting WP. They'd have to wait for an admin who isn't blocked to figure out what's going on, block the disruptive user, and unblock everyone who was wrongfully blocked. It would be a mess compared to what would happen now. Swarm 20:08, 23 July 2011 (UTC)
- Oppose. I just don't see it happening - I doubt sacrificing your bit to remove someone else's is something which will actually work in practice. — Waterfox ~talk~ 21:01, 23 July 2011 (UTC)
- Oppose. mabdul 17:35, 24 July 2011 (UTC)
- Support mostly This is not something that will be used frequently, but it's the best solution I've seen to a problem that really does exist. I've thought it a good idea ever since it was made in the immediate wake of the Robdurbar case. Moreover, the original proposal suggested that Arbcom immediately be notified: there will always be someone who should have been desysopped when this right is used: either the one using the right is abusing and should give it up, in which case the victim will have rights restored (unless both are doing the wrong thing, in which case this will be an even better outcome for the encyclopedia), or they're doing the right thing and will thus remove a problematic admin, and their own rights will be restored. However, I don't see why we would support removing the ability to view deleted revisions from a blocked admin — viewing deleted revisions is passive, and nobody notices unless they're working with the servers themselves, unless the blocked admin does something with those revisions. The vast majority of good blocks of admins are totally unrelated to abuses of this right, and abuses of this sort are what really needs to go to Arbcom. Finally, regarding self-imposed blocks: if that's technically possible, I have nothing against that, since as far as I know, there's nothing wrong with removing your own block of yourself. Nyttend (talk) 17:58, 25 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.