Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by TCO (talk | contribs) at 16:40, 12 July 2011 (→‎Proposal for Files for deletion: concern that we lose participation). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


Limit the Wikilove feature to specific user groups

I'm sure that this should be disallowed for non-autoconfirmed users, and only in an opt-in basis for non-admins, since Wikipedia isn't a social networking site.Jasper Deng (talk) 22:02, 30 June 2011 (UTC)[reply]

Oh, lighten up... Next thing you know we can't even say 'hello' anymore. — Edokter (talk) — 22:25, 30 June 2011 (UTC)[reply]
Actually I think Jasper's right, and it's only a matter of time before you see why. Malleus Fatuorum 22:28, 30 June 2011 (UTC)[reply]
We may not a be social network, but we are a community. I don't believe in blocking features for beginning editors, especially those that promote collaboration. — Edokter (talk) — 22:35, 30 June 2011 (UTC)[reply]
That's not what you'll be blocking Edoktor; have you looked at the "make your own" option? Malleus Fatuorum 22:48, 30 June 2011 (UTC)[reply]
Yes, I suspect we'll come to rue that one.--SPhilbrickT 01:49, 1 July 2011 (UTC)[reply]
That was a seriously Californian off-the-wall crazy idea. I quite like it though, better than all the gooey "love" stuff. Malleus Fatuorum 01:58, 1 July 2011 (UTC)[reply]
Obviously jealous of California MF? The 7th largest economy in the world. Almost all development and manufacturing of anything important in medical devices, telecommunications, social networking (though I might consider it a negative), Wikipedia (OK, another negative), automobile design, venture capital, computer devices, and gorgeous, intelligent women. In other words, without California, the US would be a backwards, Republican-run, anti-science, fascist religious state, pretty much laughed at by Californians. And we wouldn't let you have our excellent pot. OrangeMarlin Talk• Contributions 03:09, 1 July 2011 (UTC)[reply]
Why would anyone be jealous of California? A state that appears to have more lawyers per square mile than any other place on Earth? Malleus Fatuorum 03:14, 1 July 2011 (UTC)[reply]
Actually, it's 12th on the list of US states for active attorneys per square mile, being preceded (in order) by New Jersey, Massachusetts, Connecticut, New York, Rhode Island, Maryland, Delaware, Illinois, Pennsylvania and Florida. Additionally, the District of Columbia and Puerto Rico both have far more attorneys per square mile than California. WhatamIdoing (talk) 14:51, 2 July 2011 (UTC)[reply]
The reason I opened this thread was because of some recent trolling incidents with things related to Wikilove (like this IP). Besides, many non-autoconfirmed users don't know the meanings of barnstars, etc. Therefore, I think it's reasonable if non-autoconfirmed users can opt in to Wikilove by applying for Confirmed status. It's too risky to allow IPs to opt in.
"...can we all get along?" Bus stop (talk) 04:17, 1 July 2011 (UTC)[reply]
I'd like to point out that Orangemarlin is wrong about, well just about everything to do with California. Not only is Wikipedia NOT from California, worse- it's from Florida; the state of NY has developed more medical devices (in particular the Glens Falls, New York area) than California, the largest private sector construction project in the US is in Malta, New York eg-the newest most advanced chip fab in the US being developed by AMD; Sematech the international consortium of computer chip companies is in Albany, New York; and of course Wall Street, Madison Ave, and the news headquarters of all major networks is in the City of New York (which is twice the population of California's largest city, while being in a smaller geographic boundary). Tech Valley in Upstate NY is in a better healthier economic condition than Silicon Valley. Oh, yea and California has a bigger budget problem than just about any other state. Let California go its own way.Camelbinky (talk) 01:04, 6 July 2011 (UTC)[reply]

Opt out?

How about a way to opt out of receiving these unwanted advances? Apparently there's a way to opt out of the button to give these silly notices, but recipients has no such option. Short Brigade Harvester Boris (talk) 02:14, 1 July 2011 (UTC)[reply]

IMO the opt-out checkbox should block both sending and receiving -- it's highly unlikely that someone would opt out from sending but want to receive. For users who've disabled it, we could visibly disable the heart symbol to other users to make it clear what's going on.
I think it's inevitable that a small but vocal faction of users will dislike this feature, and this is a simple way to mitigate conflict about it.--Eloquence* 02:54, 1 July 2011 (UTC)[reply]
Well, if Wikipedia is anything like Facebook, then they will opt us in automatically, and make it impossible to figure out how to opt out!  :) OrangeMarlin Talk• Contributions 03:10, 1 July 2011 (UTC)[reply]
It is impossible to truly opt out. It is possible to make the button not appear to a user that has opted out; I can think of one fairly simple way that would work. But since anyone could manually type out any message they want I don't see a point in opting out of receiving the messages. Removing the button to send, on the other hand, could be useful and indeed I have done that for myself. Prodego talk 03:26, 1 July 2011 (UTC)[reply]
I think removing the button for opted-out users is good enough, since most of the Wikilove materials are hard to find for users who aren't familiar with what they are.Jasper Deng (talk) 04:09, 1 July 2011 (UTC)[reply]
It sounds like people also want an automated reply. I guess appropriate ones might be to
  • A rabbit icon 'I freeze like a rabbit when given wikilove'
  • A boiled rabbit icon 'I get obsessed when given wikilove, look out'
  • A rabbit pie 'We can share a meal and be friends'
I'm sure the Wikipedia software could look for a list of automated responses associated with a user and pick out the appropriate one for edits about to make to a users page so these could be shown in the preview. Hmm if they change their edit correspondingly then a different message might come out - one could almost work in a whole Eliza type conversation here ;-) Dmcq (talk) 07:58, 1 July 2011 (UTC)[reply]

Jump List support

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

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

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

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

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

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)[reply]

<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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
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.

Proposals for closing projects/Closure of Old English Wikipedia

Per the new Meta:Closing projects policy, I have proposed Ang Wikipedia, the Old English Wikipedia, for deletion. My reasons are numerous, but the main issue is that information on a dead language makes sense, information in a dead language does not. Please voice any opinion at Meta:Proposals for closing projects/Closure of Old English Wikipedia. ▫ JohnnyMrNinja 06:10, 4 July 2011 (UTC)[reply]

why are you posting this here? Choyoołʼįįhí:Seb az86556 > haneʼ 09:29, 4 July 2011 (UTC)[reply]
Perhaps because both this project and that project's languages include the word "English" in them. Just a shot in the dark. Killiondude (talk) 06:37, 5 July 2011 (UTC)[reply]

So would you then wish to close down the Wikipedias in Latin, Sanskrit or Old Church Slavonic? I respect your view, but I disagree - I think it is of interest to keep these Wikipedias. ACEOREVIVED (talk) 14:30, 5 July 2011 (UTC)[reply]

"Wikipedia is not a junkyard", but to get to a different language you actually have to look for that language (i.e. it is not in the way), so there is no harm in keeping it and, contrary to what is said above, one it is actually useful in learning the language. Just because Mitsubishi, Toyota and other car companies have no qualms in butchering Latin (viz. plural of Prius), it does not mean dead languages are useless waste of a dozen megabytes out of terabytes. --Squidonius (talk) 18:54, 5 July 2011 (UTC)[reply]

Why do you not say "Anglo-Saxon Wikipedia" which is the name given to this Wikipedia at List of Wikipedias?ACEOREVIVED (talk) 19:54, 5 July 2011 (UTC)[reply]

For discussion about this proposal, follow the link above. Writing here will just ensure that nobody sees your comments. Jafeluv (talk) 20:12, 5 July 2011 (UTC)[reply]

Suggestion for a new adminbot - Deleting Unpopulated categories

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

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

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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

Revisiting the proposal to give bureaucrats the technical ability to remove the admin bit

Retitled from "Revisiting Wikipedia:Requests for adminship/Bureaucrat Unchecking"

Following the successful RFC at Wikipedia:Village pump (proposals)/suspend sysop rights of inactive admins, some editors (including myself) are wondering whether we should revisit the Wikipedia:Requests for adminship/Bureaucrat Unchecking proposal to give bureaucrats the technical ability to perform the removal of the tools for inactive admins as required by the aforementioned RFC. As such I wanted to ask here for input whether to start a new RFC on this proposal. Regards SoWhy 21:23, 4 July 2011 (UTC)[reply]

I for one would support this. Every other user right granting is reversible by the person who did it. In fact, everything admins/bureaucrats do is reversible and this is the only exception. It is only an accident that bureaucrats do not have this ability. AD 21:29, 4 July 2011 (UTC)[reply]
I have supported this proposal in the past and would support it again. Acalamari 21:31, 4 July 2011 (UTC)[reply]
Yes, of course crats should have this ability. → ROUX ₪ 21:35, 4 July 2011 (UTC)[reply]
Sounds good to me. -- Eraserhead1 <talk> 21:42, 4 July 2011 (UTC)[reply]
I supported this before, and still do. Since desysoppings are now going to start happening more frequently with the inactive admin removal process, it makes even more sense to have trusted local users do it instead of going to the stewards every time. We can assume bureaucrats to have knowledge about the policy and standard procedures, something of which many stewards may be unaware. Many Wikimedia projects have already added this right to the bureaucrat package: meta, simple.wikipedia, en.wikinews, hi.wikipedia, fi.wikipedia, etc. While bureaucrats weren't exactly selected for this task, I have no problem trusting them with an additional responsibility which is closely related with their current job. Jafeluv (talk) 23:38, 4 July 2011 (UTC)[reply]
  • Lest we get ahead of ourselves, rather than expressing support for the idea itself, perhaps we should discuss how an RfC would proceed. Past discussions have shown considerable support for the idea, but have foundered on claims that consensus was insufficiently strong, the question posed wasn't clear enough, and/or participation wasn't broad enough. Therefore, I would recommend the following specific steps: 1) Start a clear RfC on a distinct question. For example, "Should bureaucrats be given the technical ability to remove the admin bit?" No additional options (such as ability to remove the bureaucrat bit) or mention of other topics that have confounded past discussions (such as community de-adminship). 2) Advertise the RfC widely. Notices on the relevant Village Pump pages, T:CENT, WT:RFA, WP:BN, WP:AN, WT:ADMIN and other pages as appropriate. Ask for a mention in the Signpost. If possible, get a watchlist notice for it. 3) Hope for as clear a consensus as possible. --RL0919 (talk) 23:56, 4 July 2011 (UTC)[reply]
I would support this if it is limited to, and only, to procedural desysopping as per the new '12-month' resolution, To succeed, The RfC proposal should be as short and concise as possible, and should not only state what it is for, but also state clearly what it is not for - otherwise there will be a pile on of 'views from User:X' and alternative suggestions, and requests for additional tool-removal circumstances. The RfC should be widely advertised. Kudpung กุดผึ้ง (talk) 01:12, 5 July 2011 (UTC)[reply]
What about self-requests and Arbitration Committee remedies, both of which go to m:SRP at present? –xenotalk 01:41, 5 July 2011 (UTC)[reply]
@Kudpung: I think that's exactly the problem RL0919 mentioned. Imho, the RFC should only be about the technical ability to do so. We can discuss specific cases, such as procedural desysopping or the cases xeno mentions once there is a consensus that crats should have the ability. Like with any other userright, the question whether a group should have it (like the delete-flag for admins) is separate from the question in which circumstances they may use it (e.g. WP:DEL for the delete-flag). Regards SoWhy 07:33, 5 July 2011 (UTC)[reply]

Set up TWO RFCs. Seriously, it's the only way to stop the issue of policy polluting the discussion on the technical ability. Wikipedia:Requests for comment/Bureaucrat technical ability to remove sysop bit and Wikipedia:Requests for comment/policy on bureaucrat removal of adminship. For the latter, self-requests, temporary suspension under the new "inactive admin" approach, and arbcom remedies ought to be non-controversial - but regardless, the discussion has to be kept separate. Rd232 public talk 09:44, 5 July 2011 (UTC)[reply]

True but I'm unsure as to how to have them open at the same time, since the second RFC requires the first to be successful to make any sense. And if we cannot have them open at the same time, how can we stop people from polluting the first RFC with discussions that should be held in the second one? One idea would be to ask one or more respected neutral editor(s), possibly from ArbCom, to moderate the RFC and remove all discussion that's outside the RFC's scope but I'm unsure whether all editors will accept such moderation... Regards SoWhy 10:34, 5 July 2011 (UTC)[reply]
We can perfectly well have the second open at the same time as the first, it's by far the simplest solution. All the second RFC needs to do is say at the top something like This RFC is about the policy which will be required if Wikipedia:Requests for comment/Bureaucrat technical ability to remove sysop bit succeeds. And the first will say This RFC is purely about giving bureaucrats the technical ability to remove the sysop bit. Use of this ability would be governed by whatever policy the community determines. A potential policy is under discussion at Wikipedia:Requests for comment/policy on bureaucrat removal of adminship. The technical ability, if activated, may not be used unless or until a specific policy has been approved by the community. That way, moderation by any editor should be acceptable, since there's a good place to move any misplaced comments to (but the existence of that place should anyway minimise the problem). Rd232 public talk 12:06, 5 July 2011 (UTC)[reply]
Indeed, recently parallel discussions were running simultaneously on adding the technical ability for CU/OS to function without administrative rights concurrent with the more general policy discussion on whether adminship should be a prerequisite for those roles. –xenotalk 12:23, 5 July 2011 (UTC)[reply]
Good points, I'm convinced. As such, I started two RFCs at:
As I am not experienced in creating RFCs, I would invite everyone here to help expanding those pages with proposals and structure, so we can start those RFCs soon. Regards SoWhy 13:43, 5 July 2011 (UTC)[reply]
I added some background and structural tweaking to the technical one. I think that will be the easier of the two since it is a pretty simple yes/no situation. The policy one may be a bit more complicated, since potentially people might have different opinions on bureaucrats acting in different cases (self-requests vs. ArbCom rulings vs. inactives). We may want different sections to discuss each to make consensus easier to determine in case it differs from one situation to another. --RL0919 (talk) 21:16, 5 July 2011 (UTC)[reply]
I created a separate section for each situation where a removal might be required, so that people can support one situation while opposing others. Then, when the RFC is closed, all situations with consensus in their favor can be added to the policy. Regards SoWhy 21:25, 5 July 2011 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]

Align indents and lists

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

Outdated example, see below

Elected members

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


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

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

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

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

Test

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

Proposed partial solution to NFCC enforcement

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

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:

  • War = White

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

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)[reply]
What do you mean by "War"? --SPhilbrickT 12:50, 7 July 2011 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • Cute, but no Nice idea, one I would have supported in my earlier, naive days. It simply would not work. There could be hideous clashes of colours in reality, possible confusion of colours in continental competitions, and as above, the Anglo-centric assumption of colour codes would make consequential arguments a nightmare to resolve. doktorb wordsdeeds 11:53, 11 July 2011 (UTC)[reply]
  • 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)[reply]

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

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)[reply]

  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
      • 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)[reply]
  • 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)[reply]
    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)[reply]
    You're completely misreading that policy. --Yair rand (talk) 12:54, 7 July 2011 (UTC)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    The WMF has a web forum? Where at?
    — V = IR (Talk • Contribs) 10:43, 8 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Exceptionally strong oppose per Fetchcomms. WikiPuppies! (bark) 22:43, 8 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
The username signature can be edited, actually. II | (t - c) 17:53, 9 July 2011 (UTC)[reply]
  • Well in that case, I support for the above reason. Danger (talk) 02:49, 10 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]

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)[reply]

  • 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)}}[reply]

Two RfCs for allowing bureaucrats to remove the admin bit

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

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)[reply]

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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • Support, conditionally, depending on what one means by "require" and how that's implemented. So far we've dealt with unsourced articles, and in particular unsourced BLPs, with after-the-fact deletion. I support, quite strongly, the need for some mechanism to ensure that we don't have unsourced BLPs, but I the way we've done it is about the most painful thing possible for the editors, particularly newer editors, who create these articles. They get themselves into an interface that lets them create new articles, but gives them absolutely no feedback at the time of article creation about what they've done wrong. Instead, we just hit them with templates and a handful of deletion processes and eventually delete the article. Compare this for a moment to a world where we have a line, below the article entry window, and above the edit summary, where we simply ask for the sources at article creation time--and don't honor the "submit" until something is in that field. In that case, we'd get decent sources at least half the time in cases where we get none today. Yes, we need to deal with incoming unsourced articles, but we need to do it in a way which encourages and assists editors, rather than confusing and frustrating them.--joe deckertalk to me 00:35, 11 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • Comment  Can we get some feedback from the developers on this?  Unscintillating (talk) 02:14, 11 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Reluctant Oppose We need to constantly move our standards forward, and this is a step in the right direction - except using a speedy in this case strikes me as too bitey. I'd prefer a PROD - specifically, something in the image of WP:BLPPROD. --JaGatalk 04:34, 11 July 2011 (UTC)[reply]
    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)[reply]
  • Support Encouraging new articles to be higher quality from the start is what we should be doing. --Jayron32 04:36, 11 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • "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)[reply]
  • Support, this should be a minimum standard. — Cirt (talk) 07:31, 11 July 2011 (UTC)[reply]
  • 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)[reply]
  • Oppose, babies, bathwater, etc. And what Ruslik said.--Kotniski (talk) 07:51, 11 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • Support Yes of course. This is a great idea. Otherwise we have WP:OR Doc James (talk · contribs · email) 13:28, 11 July 2011 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]

    • 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)[reply]
  • Oppose This will scare off new editors, and the unref'd tag does its job. Lugnuts (talk) 18:19, 11 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • Oppose The bar against entry for new editors is already high enough. --causa sui (talk) 20:23, 11 July 2011 (UTC)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • *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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • "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)[reply]
  • 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)[reply]
    • Just going to hinder what? What the fuck are you on? Malleus Fatuorum 00:03, 12 July 2011 (UTC)[reply]
  • Oppose This is not fixing a problem. Actually, I don't think it is even addressing something that is a problem. We get a significant number of new articles made that are on notable subject and they don't have references. We already have processes set up on how to improve those articles. And, on the other hand, we get a number of articles about garage bands and non-notable companies that do have references, it's just that they are referenced to the band's website or press releases. This proposal is not fixing a problem. Instead, I think it would lead to losing even more notable topics while not sufficiently diminishing the issue of non-notable articles that are being created. SilverserenC 00:20, 12 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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

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)[reply]
  • 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)[reply]
    • "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)[reply]

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)[reply]

  • 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)[reply]
  • 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)

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)[reply]

"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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
    • 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)[reply]
But how would the policy that requires a community consensus stop an admin from blocking a /12 in error? If they block more then they intended, a policy telling them not to wont help. Is there a way to require that before an admin blocks large then a /16 some type of notification must be acknowledged detailing the community consensus rule? Monty845 05:26, 11 July 2011 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose I still don't like the idea of going beyond /16, while a community consensus requirement, with some mechanism to stop blocks from going in without the consenus is a good compromise, I still am not convinced of the need. If if the abuse is really so bad as to justify a /12 block, it should also justify the time spent blocking the necessary /16s. Monty845 16:54, 11 July 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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. Monty845 16:49, 11 July 2011 (UTC)[reply]
  • 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)[reply]
Right, if an end user could be getting anywhere between a /64 and a /48, blocking a /48 in IPv6 could be the same as blocking a single IP in IPv4. Monty845 17:34, 11 July 2011 (UTC)[reply]
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)[reply]
It seems highly highly unlikely that any organisation will get a /36. -- Eraserhead1 <talk> 22:09, 11 July 2011 (UTC)[reply]
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)[reply]
  • 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)[reply]

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)[reply]

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 Monty845 16:52, 11 July 2011 (UTC)[reply]
  • 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)[reply]
    • The consensus discussion can be restricted to admins only, or only for certain users.Jasper Deng (talk) 17:24, 11 July 2011 (UTC)[reply]
Discussions should never be limited to admins, as remember, admins are not super users with extra authority, they are simply users whom have been entrusted with the extra bit. Regular users are able to do anything that an admin can unless it requires that extra bit, and a discussion certainly doesn't. Monty845 17:37, 11 July 2011 (UTC)[reply]
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)[reply]
I disagree that having the admin bit is a good proxy for understanding of range blocks. I suspect there are many admins who do not, and many non-admins who do. Monty845 17:49, 11 July 2011 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • Support per discussion below.TCO (reviews needed) 14:07, 12 July 2011 (UTC)[reply]

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)[reply]

Proposal for Files for deletion

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)[reply]

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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=439110830"