Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

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.

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:
  • Category:Disambiguation categories
  • Category:Wikipedia category redirects
  • Category:Wikipedia featured topics 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 ⁰⁰⁰¹ 03:08, 14 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 ⁰⁰⁰¹ 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)

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)

• 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 _words^deeds 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)

Enable LiquidThreads

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)
• 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 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 then 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)

• 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)

• 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)

• 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)

• 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)

• 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)
• Excercise in Futility given that the only version that could feasibly be applied to Wikipedia is not avaliable 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)
• Suppport 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:Wikipeida, 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)

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))

Require all new articles to contain at least one source

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

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

I hope that everyone sees this, and as such I am amending it to the first post I made. It seems that most of the opposition so far is based on a misunderstanding of this proposal. I am a planner and as such, I have a tendency to take things one step at a time to avoid opposition. This proposal is purely regarding the concept, and not the mechanics of how it would be accomplished, how long, which articles, etc. I don't want to see articles speedied immediately, nor do I want the system to prevent a page from being created when a reference isn't included. This is merely a proposal of deleting (in some manner) articles created after the enforcement date which lack a source after a certain period of time. The closest system currently in place would be BLPPROD.

I'd also like to take this opportunity to address the second most common reason for opposition, that we'd be biting newbies and making it harder to contribute. On the contrary; as it stands, these new, unsourced articles are generally nominated for deletion rather quickly, leaving the newbie diving head first into one of the most nasty processes we have here for new editors (second only to the Administrator Noticeboards IMO). This is by far and large more intimidating than the instruction that new articles (which already require signing up for an account) "contain at least one source, placed between <ref> and </ref> tags". There are many issues causing our present newbie/dwindling experienced editors situation, but this isn't one of them. It is the main contributor to our unsourced articles situation, however. - ʄɭoʏɗiaɲ ^τ _¢ 22:22, 11 July 2011 (UTC)

• Tentative Support subject to hearing the opposition arguments. I hope anyone opposing will give a real example of an existing article with sources which is fine as is. I understand, at one time, there was a notion that one editor would write a stub with no references and someone else would add references, and this was part of what made WP great. I also suggest that what was true in 2001 is not necessarily still true in 2011. I suppose it is technically possible to pass WP:N without adding a source - there may be extensive discussion in reliable sources, but the editor just chose not to include them. I wouldn't be in favor of permitting an article without sources to be CSD'd, but I would support giving 48 hours notice, and then CSD. I would support extension of sticky prod (deletion if no RS after ten days).--SPhilbrickT 00:05, 11 July 2011 (UTC)

Indeed, I wouldn't want to see them speedied immediately anyways. Perhaps stuck in a PROD like category, where if they don't have a reference after a week they are deleted. There are plenty of ins and outs of the mechanics that could be refined if the general concept floats well with the community. - ʄɭoʏɗiaɲ ^τ _¢ 00:23, 11 July 2011 (UTC)

If the community salutes this flag then it's likely to be as an extension of the current WP:BLPPROD "sticky PROD" system. --Ron Ritzman (talk) 00:28, 11 July 2011 (UTC)

I agree. Coincidentally, I've been writing to OP looking for clarification of a couple issues, and my sense is that extension of sticky prod to all articles would be the best solution. It would mitigate the concerns of almost all opposes.--SPhilbrickT 15:56, 11 July 2011 (UTC)

We currently have a BLPprod team that manages to salvage a very high proportion of the BLPprods worth salvaging. I rather fear that extending the sticky prod process to a large group of low risk articles would both swamp that team and end any pretence that this was prioritising high risk articles. Remember the original motivation for BLPprod was to improve our BLP process, though the effect has been to shift resources from other areas, some of which are higher risk in BLP terms. Prioritising a low risk area inevitably means deprioritising higher risk areas, and undermines the whole self organising ethos of the wiki. ϢereSpielChequers 19:44, 11 July 2011 (UTC)

• Support, conditionally, depending on what one means by "require" and how that's implemented. So far we've dealt with unsourced articles, and in particular unsourced BLPs, with after-the-fact deletion. I support, quite strongly, the need for some mechanism to ensure that we don't have unsourced BLPs, but I the way we've done it is about the most painful thing possible for the editors, particularly newer editors, who create these articles. They get themselves into an interface that lets them create new articles, but gives them absolutely no feedback at the time of article creation about what they've done wrong. Instead, we just hit them with templates and a handful of deletion processes and eventually delete the article. Compare this for a moment to a world where we have a line, below the article entry window, and above the edit summary, where we simply ask for the sources at article creation time--and don't honor the "submit" until something is in that field. In that case, we'd get decent sources at least half the time in cases where we get none today. Yes, we need to deal with incoming unsourced articles, but we need to do it in a way which encourages and assists editors, rather than confusing and frustrating them.--joe decker^{talk 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 decker^{talk 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. --JaGa^talk 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 usefull 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)
  • Thats 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 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 dont 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)
• 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)
• 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)

• 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 (eg 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?

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)

• 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 dont 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 dont like something being wrong and you dont 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 dont 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)

• 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 isnt 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)

• 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)
• 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. Silverseren^C 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)

• 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 dont 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 dont actually work on articles (which I think is terrible and THEY should be banned). There are 256,000 unsourced articles mainly because we dont 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 dont 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)

• 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)

Well, perhaps you'll help me understand how deleting articles without citations reduces the number of deletions. Here's what happens now:

1. Newbie creates an article on a notable subject, but does not type sources (into the first draft; most new articles are reviewed within minutes of the page creation).
2. The NPPer (perhaps) happens to notice that it's a notable subject and tags it as {{unref}}.
3. The article does not get deleted.

You propose to change this to:

1. Newbie creates an article on a notable subject, but does not type sources (into the first draft).
2. The NPPer completely ignores any considerations like notability and tags it for deletion as containing zero citations.
3. The article does get deleted.

This does not sound to me like a method of reducing deletions. WhatamIdoing (talk) 22:53, 11 July 2011 (UTC)

When you only look at sourceless articles, yes, more will be deleted. When you look at new articles in general, fewer will be deleted, as informing the user will become far more proactive.

1. User creates a sourceless article
2. NPP patroller tags with {{new-unref}}, and a small warning appears at the top of the page saying "Please add a source to this article indicating where the information was retrieved from. Articles without a source may be deleted after one week", and leaves a seond message on the users template which explains the simplest method of creating citations (a bare url within ref tags), and explains why we reference our content.
3. User learns and does, improving our encyclopedia, or user ignores and goes down the same road that all newbies go down at present.

That's how I see it, anyways. - ʄɭoʏɗiaɲ ^τ _¢ 23:58, 11 July 2011 (UTC)

That's a nice story, but I sincerely doubt that it will work that way. At present, 20% of our newbies are creating articles that survive the first few months. You propose to jeopardize some of those articles in return for the unsubstantiated hope that they will name "a source" (NB that you have not recommended "an WP:Independent source", which would tend to show notability) and then not be confused and offended when their source is declared insufficient.

BTW, the simplest method of creating a citation is to type the author's name, the title, and the publication date in plain text, underneath a section titled ==References==. WP:General references are simpler than WP:Inline citations and every bit as useful for showing notability. It's also preferable to teaching them how to exacerbate the WP:Linkrot problem that bare URLs pose. WhatamIdoing (talk) 00:26, 12 July 2011 (UTC)

Indeed. I believe that the first and most important point for a newly registered user is learning how to use our citation system. Sure unreferenced articles pose a larger workload, and take priority over link rot? I thought that's what we were here to do? Content creation can only go for so long without accumulating a never-ending backlog of cleanup work (which we already have). Newbies who do not learn how to reference what they write find out the hard way; its best that we point it, and only it, out to them from the very outset. - ʄɭoʏɗiaɲ ^τ _¢ 00:45, 12 July 2011 (UTC)

I do not think I misunderstood you at all. I simply look ahead at where this is leading and -to me- it doesn't look as positive as you describe it. Hoverfish Talk 22:59, 11 July 2011 (UTC)

Is this going anywhere?

I really dont 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 warrented 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. --JaGa^talk 17:30, 12 July 2011 (UTC)

Agreed. Worth a try. Rd232 ^talk 23:33, 12 July 2011 (UTC)

... we have an idea lab? Since when? — The Hand That Feeds You:^Bite 20:22, 12 July 2011 (UTC)

WP:VPI has existed since April 2010. Rd232 ^talk 23:33, 12 July 2011 (UTC)

Comment: 28 occurences of 'Suppport', 42 occurences 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 Template:Bug Template:Bug Template:Bug; 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 decker^{talk to me} 21:27, 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)

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 (eg 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 eg 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 (eg 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)

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 the glaring edit summary box and other disclaimers at the bottom of the edit window, and that's just for starters. From reading through this entire discussion again, I see three sets of suggestions that further examination could be focused on:

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

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

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

Summarising the argument

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

• 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)

Raise the rangeblock limit (especially for IPv6)

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

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

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

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

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

First proposal !votes

• 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? Monty₈₄₅ 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)

• 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. Monty₈₄₅ 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 then /36 I would support raising that limit to at least /36, and even /16. Monty₈₄₅ 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. Monty₈₄₅ 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)

• 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)

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 then /16 would require the community consensus Monty₈₄₅ 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. Monty₈₄₅ 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. Monty₈₄₅ 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)

• 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)

• 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)

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 ⁰⁰⁰¹ 03:14, 14 July 2011 (UTC)

Applying the speedy deletion button to unblock requests

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

I think that's a good idea. WhatamIdoing (talk) 00:18, 13 July 2011 (UTC)

Yes, especially with users blocked for username issues; I frequently come across malformed unblock requests for usernames (I'm not an admin, but I do a lot of UAA work, and I sometimes check on users who appear to have been editing in good faith), and this proposal seems like it would help. I can say that it's tremendously helped with contesting CSD tags (even though the rationales are frequently missing the point, at least users are getting their say), and hopefully it would have the same effect with unblock requests. The Blade of the Northern Lights (話して下さい) 03:43, 13 July 2011 (UTC)

I agree, this is a good idea. - Hydroxonium (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. Monty₈₄₅ 06:47, 14 July 2011 (UTC)

Attribution of images

This has been discussed before with a fairly even split in opinions thus would like to bring it up again. I am currently in discussion with ECGPedia regarding our use of their images. They may be willing licensing their content under a creative commons 3.0 license but have some concerns about proper attribution. Currently there is no attribution within the article for images. This is in contrast to ideas to which we reference where the idea is from in the reference section. We give the New England Journal of Medicine and Lancet a great deal of attribution. The issue with images is that the source is not always readily apparent and when it comes to medicine whether a picture was taken by a physician or a lay person affects the images reliability. Per WP:V either adding credits or a little blue link would improve things.

Also in my position with Wikimedia Canada I am working on collaborations with a number of other organizations. I am hoping to collect data regarding what effect their involvement with us has. If we show that ECGPedia's release of images under a more open license increases visits to their site than this will give us something with which to approach other organizations with whom we wish to partner. This is another reason I feel that we should fairly attribute those who donate images.--Doc James (talk · contribs · email) 03:40, 13 July 2011 (UTC)

Image attribution Proposal 1 (little blue link)

Typical ECG abnormalities in Brugada syndrome: ST elevation in V1-V3, without ischemia.

(The attribution text would display in the usual section below with reliable sources, e.g.:

Support

• Support as optional I think this would be an acceptable way to do it when there is a good reason to want extra attribution on an image. Monty₈₄₅ 17:03, 13 July 2011 (UTC)
  • Please see my comment in the other suggestions section - "optional" is not an option because of the language of the Creative Commons licenses. It's an all or nothing thing. --B (talk) 19:54, 13 July 2011 (UTC)
    • This is a legal opinion that we are not sure is true or not. I have asked Wikipedia's lawyer for clarification on this point.Doc James (talk · contribs · email) 20:26, 13 July 2011 (UTC)
      • As we are not a collection as defined by "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined below) for the purposes of this License." This equal application to all would not apply, Doc James (talk · contribs · email) 21:41, 13 July 2011 (UTC)
• Support; fits with our typical page layout and is unobtrusive. At the end of the day; this is a reasonable and small change that might make more institutions of this sort open to donating content. It does not undermine our ideals, it does not clutter up pages (well, apart from an extra small blue box...) and ultimately could bring is great benefit. (as a side point; I have gottne permissions for release under the promise I will try to add an in-article credit the author [with the caveat that it might not stick] and make zero apologies to you all for doing so. I got us a few awesome images in return for a reflist credit. :)) --Errant ^(chat!) 21:00, 15 July 2011 (UTC)
• Support; Will confirm that the caption indeed applies. And that we have attribution for the interpretation of the image. Doc James (talk · contribs · email) 16:22, 16 July 2011 (UTC)

Oppose

• There is no need to do this for attribution, as all attribution information is already one click away by simply clicking on the image. However, if the identification of the image itself or the caption text are supported by reliable sources (as may well be the case with File:BrugadaECGPedia.png used as the example here), I see no reason why a real reference couldn't be used. Anomie⚔ 19:30, 13 July 2011 (UTC)

This is sort of the manner in which I was planning on using it. Some of the images that I have been requesting come from published journal articles. --Doc James (talk · contribs · email) 20:12, 13 July 2011 (UTC)

I concur. --Cybercobra (talk) 20:42, 13 July 2011 (UTC)

• I think this is just going to be obnoxious more than anything else. And from a readability standpoint, it's confusing, since it's the same reference we use for factual citations. If the image caption has some controversial claim in it, that claim may be cited to a news article. Adding a second footnote to credit the image author is starting to hurt readability. Also, if you have to click on the footnote to see the attribution, you were already one click away from the image description page, so it doesn't really change anything other than clutter up articles (although, I guess it gives you built-in image attribution for printed versions of the article.) --B (talk) 19:45, 13 July 2011 (UTC)
• --Jayron32 19:50, 13 July 2011 (UTC)
• Oppose Ugly and not really beneficial to the project. Images are already credited if you click on them. Sven Manguard Wha? 21:45, 13 July 2011 (UTC)
• —[d'oh] 22:07, 15 July 2011 (UTC)
• Unjustified distinction between creators of text and creators of media (article writers don't get credit on the article page), unjustified distinction between institutional creators and other creators (institutional media donors get credit on the article page, but User:JoeBlow425 doesn't get credit), hard to implement reliably because we have to keep track of which donors impose extra requirements on attribution. Calliopejen1 (talk) 18:00, 17 July 2011 (UTC)

Neutral

• Gnangarra 10:21, 13 July 2011 (UTC)

Discussion

• An internal wikilink is what I presume this proposal is suggesting, that would mean that the donar would only get in article attribution if the donar is notable. internal link to our WP article isnt going to realy benefit the source. I can see disputes arising from this format specifically where images are available thru multiple locations do we credit Flickr for images sourced from Flickr users. Gnangarra 10:21, 13 July 2011 (UTC)
  • It is like a reference. When you click on it it brings you to the reference section where the credit info ( real name of author is mention ). This would be an optional idea if approved. Not requesting that we use it universally. Doc James (talk · contribs · email) 17:00, 13 July 2011 (UTC)
    • If you want to go this route, it's worth considering using the "group" feature for references. To do that you'd use: <ref group=Image>Joe Photographer - Joe's Photography business</ref> followed by {{Reflist|group=Image}} somewhere in one of the Footers sections (note that if the group name shows up in the brackets of those references, so you should keep it short. Also, if the group name contains any spaces you'll need to use quotations around it [for example: group="example name"])
      — V = IR (Talk • Contribs) 20:18, 13 July 2011 (UTC)

Image attribution Proposal 2 (credit link)

The Audubon Ballroom. (Credits)

Support

Oppose

• Redundant to both the image itself and the little "Enlarge" icon being linked to the same place. Anomie⚔ 19:26, 13 July 2011 (UTC)

We could replace the little enlarge icon with maybe credit? I had no idea what the little icon did for years. It is not intuitive. The EB gives you the caption and the credits when you put your mouse over the image. Doc James (talk · contribs · email) 19:41, 13 July 2011 (UTC)

• This doesn't really accomplish anything if all it does is take you to the same page that clicking on the image takes you to. --B (talk) 19:48, 13 July 2011 (UTC)
• --Jayron32 19:50, 13 July 2011 (UTC)
• Redundant to the image's description page, and gives unfair credit to image contributors vs. text contributors. Text contributors are currently noted only in the article history, not on the page itself. --Cybercobra (talk) 20:37, 13 July 2011 (UTC)
• Oppose Ugly and not really beneficial to the project. Images are already credited if you click on them. Sven Manguard Wha? 21:45, 13 July 2011 (UTC)
• —[d'oh] 22:07, 15 July 2011 (UTC)

Neutral

• Gnangarra 10:27, 13 July 2011 (UTC)

Discussion

• While a better approach as notability of the source isnt a presquesite for attribution. I'd be concerned over disruption to articles with image choice as EL do affect the source sites. Gnangarra 10:27, 13 July 2011 (UTC)

No sure what you mean? --Doc James (talk · contribs · email) 18:34, 13 July 2011 (UTC)

Image attribution Proposal 3 (credit in caption)

A hand affected by rheumatoid arthritis
James Heilman, M.D./Wikimedia Commons

Support

1. I much prefer this option with the restrictions that I outlined below - no user names, no company names, no links. We can't have this turn into an opportunity for free advertising. If the photo was uploaded by a pseudonymous Wikipedian, we can just say "See description page for attribution" or some such thing. --B (talk) 19:37, 13 July 2011 (UTC)

Oppose

• No need to spam photographers' (or other copyright holders') names across our articles. This information is appropriately kept with other metadata on the image description page. Anomie⚔ 19:44, 13 July 2011 (UTC)
• --Jayron32 19:50, 13 July 2011 (UTC)
• Protonk (talk) 20:15, 13 July 2011 (UTC)
• Redundant to the image's description page, and gives unfair credit to image contributors vs. text contributors. Text contributors are currently noted only in the article history, not on the page itself. --Cybercobra (talk) 20:39, 13 July 2011 (UTC)
• Strong Oppose I've seen this in actual implementation at the Assassin's Creed Wikia, it looks godawful. Images are already credited if you click on them. Sven Manguard Wha? 21:45, 13 July 2011 (UTC)
• —[d'oh] 22:07, 15 July 2011 (UTC)

Neutral

Discussion

Image attribution Proposal 4 (status quo)

Support

• As originator --Jayron32 19:49, 13 July 2011 (UTC)
• Basically, as I outlined below. — V = IR (Talk • Contribs) 20:02, 13 July 2011 (UTC)
• Protonk (talk) 20:11, 13 July 2011 (UTC)
• Fine as is. Sven Manguard Wha? 21:45, 13 July 2011 (UTC)
• No compelling reason to disrupt the entire project by changing things here. Anomie⚔ 10:48, 15 July 2011 (UTC)
• As per Jayron32 below, no one else gets there name featured on articles. Why should ECGPedia get special treatment? —[d'oh] 22:07, 15 July 2011 (UTC)

Oppose

Neutral

• I'm content with either #3 or #4. #1 and #2 are awful. --B (talk) 19:52, 13 July 2011 (UTC)

Discussion

• Nothing else at Wikipedia gets credit. If I take a photograph, why does that get my name prominently displayed on it, but if I write a paragraph of text I don't get to sign my name? Why? Because contribution to Wikipedia is not about generating glory for the writer. It is about spreading knowledge pure and simple. There are outlets to gain personal glory, and it's called "The rest of the world that isn't Wikipedia". If your purpose in taking a photograph is to become a better known photographer, or your purpose in writing text is to become a better known writer, Wikipedia is not for you. Wikipedia's image file pages, like Wikipedia's text history pages, are an adequate means of giving attribution for image sources and be fully compliant with our lisence. There is no need to give more prominent credit in the text to the originator of content. Yes, other parts of the world give more credit. We are not other parts of the world. We are Wikipedia. There is no reason to change how we do things just to increase the number of photographs we have access to. If you want more photographs, get a camera. --Jayron32 19:49, 13 July 2011 (UTC)

You have referenced the ideas in the text you have written to a reliable source so that the ideas do get attributed in the ref. Images like ideas should get referenced / attributed. The difficulty is how many of us have images of porphyria cutanea tarda lying around. I carry a camera every day and have still not got the opportunity to take a picture of it. I am suggesting this as a way to improve Wikipedia. As a way to convince others to release images they might not otherwise release. Doc James (talk · contribs · email) 19:54, 13 July 2011 (UTC)

It is a completely distinct and different issue. An image is not an idea. I am wholly the creator of the text I am writing, but I am referencing it to sources where the ideas come from. You are conflating two completely independent and distinct parts of Wikipedia articles, and there's no inherent need to make an analogy for what works in one case (inline cites for source texts) and apply it to another (images). They are different things, and require different standards. --Jayron32 20:24, 13 July 2011 (UTC)

I tend to agree, however... I can see the point that Doc James is making. I don't think we should dismiss his concerns out of hand (if for no other reason then the fact that many others seem to share his view).
— V = IR (Talk • Contribs) 20:39, 13 July 2011 (UTC)

• I'm okay with a citation when an image comes from a reliable source and we are relying upon or stressing the accuracy/authority thereof. I'm not okay with blanket attribution in all image captions. As Jayron argues, it would create an unfair divide among contributors based on the kind of content contributed. --Cybercobra (talk) 20:47, 13 July 2011 (UTC)

And that is what I am proposing. Per my above comment it appears to be allowed. I am not proposing we ref all images just those from reliable sources in which the reliability may be in doubt. Doc James (talk · contribs · email) 21:30, 13 July 2011 (UTC)

It does not seem to me that you are proposing to "ref" any images at all to proper reliable sources. It seems to me that you want to advertise the name of the person who took/owns the photo. "Dr H took this picture" is not a reliable WP:Published source for information about the contents of the photo. "Dr H took this picture" does not tell me whether the photo actually contains what some editor said it contains. It only tells me that he took the picture. WhatamIdoing (talk) 20:58, 15 July 2011 (UTC)

The first example is a reference to the source of the caption that verifies this interpretation of the ECG. The interpretation was made by a cardiologist in the Netherlands for this example. Even though the ref page does not make it that clear. But for images say from the WHO we should have a ref to the WHO supporting the interpretation per WP:V. If the image was from the WHO rather than Wikimedia Commons would that change matters? I agree Wikimedia Commons is not a reliable publisher. Doc James (talk · contribs · email) 16:25, 16 July 2011 (UTC)

Image attribution References

Image attribution Other suggestions?

• Question Is the intent to make a policy (enforced), a guideline (best practice), or just approve it as an optional practice? Monty₈₄₅ 05:59, 13 July 2011 (UTC)

Approve as an optional practice.--Doc James (talk · contribs · email) 16:57, 13 July 2011 (UTC)

That's possibly going to be problematic. The various Creative Commons licenses all have this language (or some form of it): "The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors." The "so what" of that is that attribution of one photo needs to be "at least as prominent" as the attribution for other photos. So if we start allowing some Creative Commons photos to be attributed, we have to attribute all of them. Of course, this flies in the face of my strong desire to keep user names out of image articles, but I think we can resolve that by saying "Image credit: see File:whatever.jpg" for users who have not provided an English name to attribute. But the bottom line is, if we start doing this, we have to do it everywhere. --B (talk) 17:25, 13 July 2011 (UTC)

I have emailed Wikipedia's legal counsel too see if this is an issue ( if we need to do it for all images if we do it for any images ). Will let you know what he says. I am not suggesting we put user names in the article text itself. I am suggesting on that we have "Image credit" or "[1]" as an option especially for images in which the source effects the reliability. Doc James (talk · contribs · email) 18:33, 13 July 2011 (UTC)

FYI, I have no idea what our current counsel will do/say, but when this question was asked of Mike Godwin, he basically said to leave him out of it. I guess/assume (based purely on my non-legal mind) that the Foundation doesn't want to get involved in these decisions, because if it gets involved, it becomes legally responsible. Right now, they get to claim that they are just a content hosting service no different from Youtube or Blogspot and that if a user violates a license, that's the user's problem, not the Foundation. So they have a vested interest in not giving an opinion here. --B (talk) 20:44, 13 July 2011 (UTC)

That's exactly what is going on, and I would be very surprised if the current legal counsel said anything different than Mr. Goodwin did, for the reasons that you've already outlined.
— V = IR (Talk • Contribs) 20:47, 13 July 2011 (UTC)

• Question threshold before an source is attributed, do we also attribute users in the article for images. Gnangarra 10:29, 13 July 2011 (UTC)

Photographer would at least need a real name. But this would be on a optional basis. Doc James (talk · contribs · email) 18:40, 13 July 2011 (UTC)

• I don't mind attribution for images with two IMPORTANT restrictions: (1) No internal or external links, website names, company names, in the attribution - otherwise, we're going to have massive numbers of commercial websites fighting over images just so they can have a free link to their website and (2) Real names only - no "photo by User:PointlesslyColorfulAndSillyUs3rname666". The attribution should be very simple - "Photo by Bob Johnson". --B (talk) 16:32, 13 July 2011 (UTC)

This sites give use attribution [8] and [9]. I am not suggesting we do it this prominently. Just a halfway point. One would still need to click on credits to bring it up. Also we would need a clause stating that we use images uploaded by our users directly preferably if equal quality images exist for the subject matter at hand. Images of rare medical disease are exceeding difficult to come by. We need to bend a bit ( not much but a bit ) if this can help us acquire them for the creative commons.Doc James (talk · contribs · email) 18:40, 13 July 2011 (UTC)

If "we need to bend a bit" means that we need to accept less than completely free images, then that's fine (to me, at least) but it means that commons is not an option. The entire purpose of commons is to be a completely free resource, so if potential contributors have any objection to completely giving up their rights to the image then they shouldn't be posting the files to commons. That doesn't mean that Wikipedia can't use the image(s), though (despite the hysterics of the anti-NFCC crowd). If there are license issues, then the contributors should upload the images directly to Wikipedia itself, not commons.
— V = IR (Talk • Contribs) 18:57, 13 July 2011 (UTC)

No people are still donating completely free images. It is just that we (Wikipedia in English) the major users of these images are going to give proper attribution (slightly more than the minimum required by law). The people I am in discussion with are completely aware that other may not do the same as us and are free to reuse their images. Doc James (talk · contribs · email) 19:28, 13 July 2011 (UTC)

Please see the Wikimedia Foundation's licensing policy. Projects are not permitted to accept "free content" licenses that are "less free" than the ones acceptable at Commons. Nor can we use under a claim of fair use content that would violate the "replaceable" rule. These are Wikimedia Foundation policies, not ones that the English Wikipedia has the power to change. --B (talk) 19:27, 13 July 2011 (UTC)

Right. I know that yourself and others have this interpretation, but... well, NFCC and all (more correctly: "Exemption Doctrine Policy (EDP)").
— V = IR (Talk • Contribs) 19:52, 13 July 2011 (UTC)

James, I very much like the attribution method used on those sites you linked - I would support something exactly like that here. --B (talk) 19:27, 13 July 2011 (UTC)

I would be fine with that aswell. Added it as an option in the discussion. Doc James (talk · contribs · email) 19:36, 13 July 2011 (UTC)

Image attribution further discussion

I don't really have a suggestion, but more of a basic question. Images (and other files) have their own dedicated pages, and it's always been my impression that we preferred all attribution to take place on that page (it's actually required for the most part, due to the NFCC bureaucratic stuff). Why do we want to, or need to, have attribution of images within the articles where the images are used?
— V = IR (Talk • Contribs) 18:51, 13 July 2011 (UTC)

What is NFCC? Doc James (talk · contribs · email) 18:58, 13 July 2011 (UTC)

Wikipedia:Non-free content criteria.
— V = IR (Talk • Contribs) 19:08, 13 July 2011 (UTC)

That's what this discussion is about - asking the question whether or not we want to change what we're currently doing. The main advantage I see in changing it is that it's the norm outside of Wikipedia and it's the expectation that serious photographers have. If you go to CNN.com and click on a random article, you will see any photos in that article captioned with something like "John Smith / Getty Images". Some professional photographers (or even a few of the more serious amateur ones) I have interacted with over the years have been rather ticked off that we don't provide inline citations. For example, see File talk:Cynomys ludovicianus -Paignton Zoo, Devon, England-8a.jpg for one such discussion. Now, I've also seen ones that want an inline citation linking to their website (for obvious self-promotional purposes - a link from Wikipedia is hundreds or thousands of dollars in free advertising) and we need to guard against that at all costs. --B (talk) 19:34, 13 July 2011 (UTC)

I think that I'm generally inclined to remain with the status quo, which essentially means "no inline attribution... but you can add it if you think it's important and others don't actively remove it". The reason being, essentially, due to the concerns over promotion that you brought up. Additionally though, the fact that you can click on our images and get to a dedicated page seems to supplant the need for inline citation (and indeed, allows for much more information to be given than normal). Most websites don't provide that click through capability. I hear you that because it's different, some contributors can be and are put off, but... I think that our position as a top 10 website allows us some leeway to say "this is how we do it, please learn our way". I'm willing to listen though, of course.
— V = IR (Talk • Contribs) 20:00, 13 July 2011 (UTC)

(edit conflict) I for one don't think we need to. As far as I understand the people who do think so, the motivation is generally along the lines of "Some person/organization might/will freely license a bunch of pictures, if we display their name alongside every use of their pictures in articles." This comes from the fact that few other major sites use our system of linking every image to an attribution page, instead printing the photographer credit in small print next to the image or at the end of the article in imitation of print media. Anomie⚔ 19:39, 13 July 2011 (UTC)

Per Anomie WRT the collaboration with ECGPedia will be referencing the interpretation of the cardiologist there who uploaded the image. Thus for this specific circumstance the text in the caption will need referencing.Doc James (talk · contribs · email) 20:19, 13 July 2011 (UTC)

If the interpretation is described in the text, it would be referenced like any other text in the body of the article. What we want to avoid is the small art photographers (who produce a useful product, it's true) spamming samples of their images into articles and insisting on highly visible attribution. It is free advertising for them and a headache for us. Rmhermen (talk) 22:09, 15 July 2011 (UTC)

Yes and what we want to promote is organizations like the World Health Organization, Health Canada and the Mayo clinic releasing their thousands of images of rare conditions for use to us. Images that it is unlike we will be able to ever take ourselves. We must not paint all images / sources the same. But with respect to images in medicine the entire interpretation of the patient is required before one can say what the image is. Therefore for the content I am interested in references are need to support the fact that say this image of dengue fever is indeed dengue fever with the ref being the Center for Disease Control who have back up the claim with serology rather than just someone who thinks they have dengue from flicker.(BTW I will not be referencing flicker) Doc James (talk · contribs · email) 16:19, 16 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)

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)

Unblockself permission

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 right - 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)

• 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)
• 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)

• 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)

Alternate proposal

1. Remove the ability of admins to amend, reblock or unblock themselves unless they're the ones who blocked themselves.
2. Remove all admin rights of admins while blocked (except for the ability to modify a self-imposed block). This may affect only WP:Viewdelete rights, which admins currently have while blocked.
3. Throttle the ability of admins to block admins. An admin account could be limited to making 10 admin blocks per 24 hours; this ought to be a limit easily high enough to never be hit legitimately, but it sorts out the concerns of a hypothetical rogue or compromised account going nuts and blocking everyone.

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

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

Block Reviewers user group

spun off from "Unblockself permission" thread above as it's not really an alternative solution to that issue. Rd232 ^talk 13:07, 17 July 2011 (UTC)

A common non-admin experienced user knows what's worth revoking talk page access over, and maybe perhaps even what's supposed to be worth an unblock. Therefore, as an alternate proposal, I propose a Block Reviewers user group that can modify blocks and unblock, but not have any other admin-related things. Thoughts?Jasper Deng (talk) 04:10, 16 July 2011 (UTC)

Completely agree! I do not like the current method of admins playing judge and jury and appellate court all in one. There is, unfortunately, one admin who seems quite aggressive on reviewing unblocks and upholding the block in probably 90% of all cases (way too high regardless of what admins may think, they are far from being that accurate in their blocks). I came across one egregious block review denied by him, brought it to AN/I and within a few hours had it lifted, and during that time I decided to check the user contributions to find more and found out of the last 10 block reviews all ten had been denied by that admin and at least three IMO should have merited lifting or at least further Community discussion. Given how active this admin is in seeking out block reviews in order to be the reviewer (and sorry, no AGF here) simply to purposefully deny and uphold the block; for this one reason I would like to see non-admins decide whether admin actions such as blocks should be upheld or not, they want to feel high and mighty like they are the "police" then we'll be the civilian police board to monitor their actions and hold them accountable. No cabal's self-monitoring their own actions.Camelbinky (talk) 04:49, 16 July 2011 (UTC)

Splitting admin tools into separate userright groups is a perennial non-starter proposal. Strange Passerby (talk • cont) 16:11, 16 July 2011 (UTC)

I would say editing blocks is one of the more serious things an admin can do. -- Eraserhead1 <talk> 16:59, 16 July 2011 (UTC)

"One of the more serious things an admin can do"? Really? Well, that might be true in a social media site... oh wait we're an encyclopedia. I thought the most serious thing any editor could do is to actually edit and add information to articles. I would say denying blocking requests is the least helpful thing someone can do when our goal is to "finish" this encyclopedia. Perhaps if more time was spent on research and creating articles and expanding stubs and adding references to articles with refneeded tags etc then the goal of the most comprehensive encyclopedia of knowledge in the world might be attainable. But nooooo, there are admins who would rather not do any editing at all and instead worry about enforcing civility and policies they see as "rules and laws". We'd be farther along without them.Camelbinky (talk) 04:31, 17 July 2011 (UTC)

Camelbiky, I'm just going to copypasta a comment in here that I made elsewhere, coz I'm a lazy get .... "Like every large community, Wikipedia needs a whole range of people with a whole range of interests and skills in order to function. Consider the medical profession - yes, we have family doctors / GP's, and very, very valuable they are, too. And, in the old, old days, we had 'wise men' and 'wise women' and such, who did most of the medical care for their community, and did it well. But today, for many reasons, we need people whose speciality is in orthopaedics, or cardiac, or ENT, or neurosurgery, or cancer, or - you name it! The community cannot - no community can - function well, let alone brilliantly, without specialists, and who are we to start judging when one specialist is 'more important' than another? It's a team effort. Everyone who contributes, in any way whatsoever, is a valuable member of that community. Let's make sure that we value everyone's contribution to the community, even if we don't personally have that particular area of interest and expertise ourselves. We need all sorts, really we do. Possible a better example: yes, we need people to build wonderful new roads - but if we're building wonderful new roads, we also need people who are happy to make sure the signposts are easy to read, people to create new maps, people to make sure that potholes are filled in, people who pick up the litter so road-users don't break their necks in it, people who make sure that bandits aren't lurking in ambush along the sides of our wonderful new roads, people who clear the road quickly when there's a crash ... we're all important." Pesky (talk …stalk!) 04:58, 17 July 2011 (UTC)

There are ways and means to address such issues with individual users. I'm sure you're aware of them. Rd232 ^talk 23:18, 16 July 2011 (UTC)

• Oppose - Per Eraserhead. Sven Manguard Wha? 17:35, 16 July 2011 (UTC)
• We don't exactly have a backlog in CAT:UNBLOCK, do we? T. Canens (talk) 15:12, 17 July 2011 (UTC)
• Oppose per Eraserhead. If someone disagrees with the result of a block review they can request another one or, if they're not the blocked editor, they can discuss the issue with the admin and, if unsatisfied with the answer, raise the issue on AN or ANI. There really is no need for this new userright. Salvio ^{Let's talk about it!} 15:39, 17 July 2011 (UTC)
• Oppose per Timotheus Canens. When there is a backlog of blocked users so long that no one can deal with all the unblock requests, perhaps it would be time. Then again, if we ever get to that point, we may be past the Wikipocalypse... --Jayron32 01:02, 18 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 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 unsuccesful/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 existance, 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 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)

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)

Require Captcha for Special:EmailUser

With the recent incident with WikiAlpha, I think it's best, if possible, that this feature require CAPTCHA for non-autoconfirmed users.Jasper Deng (talk) 04:00, 18 July 2011 (UTC)

• Support - I'm surprised we've never had one. Also, WikiAlpha is currently being discussed at AN/I. I've linked to here as a "See Also" at the top of the thread. I wonder if going a step further and requiring capthca for registration might also be a good idea now, if not already present. CycloneGU (talk) 04:56, 18 July 2011 (UTC)
  • We've had a CAPTCHA for registration for as long as I can remember. MER-C 06:50, 18 July 2011 (UTC)
    • More precisely, we've had a CAPTCHA for registration since February 2007. Graham87 08:03, 18 July 2011 (UTC)
• Support. The case for this is obvious enough to tempt me to file in Bugzilla right now. MER-C 06:50, 18 July 2011 (UTC)
• Support although I wouldn't terribly mind if it were required of all users in order to send emails. If you want/have to send email en-masse, and you don't already have enough of an on-wiki relationship with the recipients to already have their emails, then you probably shouldn't be sending those emails in the first place. This will make it harder, or at least more tedious, for both pollsters and vandals (which is what I consider the WikiAlpha people to be) to use the email function on a widespread basis, and I think that's a good thing. Also, since autoconfirmed is a deliberately low standard, it dosen't take much for a spammer to build up an account to get around the Captcha requirement. Sven Manguard Wha? 07:06, 18 July 2011 (UTC)
  • Related note: Do we use ReCaptcha for our captchas? I happen to think that the ReCaptcha mission is worth supporting. First few paragraphs of this article, in case you didn't know. Sven Manguard Wha? 07:06, 18 July 2011 (UTC)
    • No. Last I heard the WMF is opposed to anything which uses servers outside their control for privacy, reliability and possibly other reasons. Personally I think a more important goal as per Graham's comments below is we need some sort of audio captcha for blind users. Of course this could be handled via ReCAPTCHA but any method is fine provided we actually have something. Edit: See the replies here [10], the biggest concern is it's not open source. I should mention on a personal note I've never been that impressed with ReCAPTCHA. It's sort of like some of the distributed computing efforts, at least in the earlier years. Sounds like your contributing something noble but sometimes it seemed like your doing work for semi-commercial efforts for free (or at least it wasn't always clear what would happen to the results and whether anything may be patented partially arising from volunteer efforts). Nil Einne (talk) 10:54, 18 July 2011 (UTC)

• Cautious support, but I'm not sure how much good it would do, as WikiAlpha's email bots could just make ten edits and wait four days until they started their email spree. However I oppose requiring a CAPTCHA for all emails, as it would make things more difficult for blind Wikipedia users like myself. I wouldn't be personally affected, as I am an admin, but I've never gotten the audio CAPTCHA to work for instance. Graham87 08:03, 18 July 2011 (UTC)

• Limited support per Graham not sure how well it will work. Opposed to all e-mails until and unless audio CAPTCHAs or some other solution is found for blind users and anyone else who can't use our current CAPTCHAs Nil Einne (talk) 10:54, 18 July 2011 (UTC)
  • Would you support a throttle (e.g 1 in 24 hours) after which you can't send any more without a captcha? That would reduce the risk of bot spam, while allow blind users to send some emails. עוד מישהו Od Mishehu 13:01, 18 July 2011 (UTC)
• Comment - the possibility of socking so that captcha is not required is an interesting one. There are parallels with the #Proposed expansion on current protection. In both cases the answer may be some higher bar (more edits and time than is required to get autoconfirmed) and some software that detects attempts to do a mass of "under the radar" edits, such as minor punctuation changes. Yaris678 (talk) 11:21, 18 July 2011 (UTC)
• Support under the condition that we allow infrequent emails (maybe 1 per 24 hours?) to be sent without a captcha - this should help with the accessability issues, while remove the reason for using a bot to send the emails (a bot would make it easy to send hundreds of emails in a single sitting; sending 1 a day is hardly a job for a bot). עוד מישהו Od Mishehu 12:03, 18 July 2011 (UTC)
• Support. Ironholds (talk) 14:07, 18 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)

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)