Wikipedia:Village pump (proposals)/Archive 38

Add links
Source: Wikipedia, the free encyclopedia.
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

Easier instructions for making articles

I have noticed over and over again that many n00bs have no idea how to create a new article, and most of the time end up creating it in userspace. We also get plenty of cases like this where the user has written out the article but doesn't know where to put it. As many times as I've instructed users on how to make articles, I've come to realize — I don't think we have a guide to making articles that clearly has a button with "create your article here" or somesuch. Usually I just end up giving them a red link to work with so they can turn it into their article. Do we have one that I've overlooked? Ten Pound Hammer and his otters • (Broken clamshells • Otter chirps • HELP) 14:53, 29 October 2008 (UTC)

Nope, we don't - that appears to be by design. The original idea was to encourage people to create articles on topics redlinked by other topics, so that new articles are never orphaned, and spurious unneeded articles are discouraged. In practice, these days, it's much more common for people to be interested in creating articles on topics of interest to them not linked by other articles. Should we encourage this, or is the current mechanism better? Dcoetzee 17:56, 29 October 2008 (UTC)
I definitely think that we should have a page that explicitly shows how to create a new page, so long as we make it clear that the user should check to see that a page on that subject doesn't already exist. Ten Pound Hammer and his otters • (Broken clamshells • Otter chirps • HELP) 23:50, 29 October 2008 (UTC)
Users asking at the help desk are usually directed to
Wikipedia:Your first article#How to create a page. PrimeHunter (talk
) 00:09, 30 October 2008 (UTC)
It never really took off, maybe because it's still to an extent at the drawing board stage, but I thought and still think that the Wikipedia:Article wizard was a great idea, and if it is completed and placed in the interface in a way that drives people to create articles using it, could be a great boon to Wikipedia.--Fuhghettaboutit (talk) 03:11, 30 October 2008 (UTC)
Yes, something like that would be very helpful. Ten Pound Hammer and his otters • (Broken clamshells • Otter chirps • HELP) 23:18, 2 November 2008 (UTC)

Deletions (afd)

Hi, the afd pages seem to be over 100 entries per day now. I was looking at a deletion discussion about the article on science (ology) of the effect of astro something on human culture. I can't remember the name and I have tried keywords I knew were in the discussion. I have gone over several archives and searched stuff like "ology afd" etc. Does the afd (or other lengthy active listing categories) require a specific and ambiguous search capability? And, does anyone recall this debate as I would like to find the article or the debate.... ~ R.T.G 15:25, 3 November 2008 (UTC)

Would that have been Wikipedia:Articles_for_deletion/Astrosociology_(2nd_nomination)?--Aspro (talk) 18:49, 3 November 2008 (UTC)
Wikipedia:Articles for deletion/List of sciences ending in -logy mentions astrology. PrimeHunter (talk) 02:11, 4 November 2008 (UTC)
Thanks, I actually found it after a while. I'm trying to undelete it but it's seeming unlikely. ~ R.T.G 02:23, 4 November 2008 (UTC)

Additional featured portal director

Please see Wikipedia_talk:Featured_portal_candidates#Additional_Featured_portal_director. Cirt (talk) 22:36, 3 November 2008 (UTC)

Proposed: That Jimbo should have the powers he currently has.

Recently, I've heard a couple of people speculate that Jimbo's role on English Wikipedia lacks consensus. I suspect this is false-- I think there is strong consensus for his role. But admittedly, we don't actually have a policy that specifies this.

So I'd call for eyes at: Wikipedia:Project Leader, where I've attempted to just spell out what his special role currently is.

In particular:

  1. Did I miss any of the powers Jimbo has?
  2. Jimbo's current role does have consensus, right? A few dozen voices of support before the arbcom election would be helpful in clarifying that yes, Jimbo should in fact have the appointment powers that he has. --Alecmconroy (talk) 06:23, 4 November 2008 (UTC)

New User Group - moveconfirmed

I've been noting the Grawp-type vandalism for the past few months. I have noted that often, Grawp will undo 10 random edits from Recent Changes and go immediately on a spree. Now often, undoing 10 edits in a row will not be noticed by RC patrollers until it is too late and Grawp has gotten his .5 milliseconds of fame. Unfortunately, Grawp's edits are preserved in the edit history for all eternity, so I figured that we might as well get a way to try to stop them before they happen.

I propose that we spin off the "Move pages (move)" right from autoconfirmed and make it into a new usergroup that the database automatically gives after a certain number of edits, as autoconfirmed is currently handled. However, if this is to be effective, moveconfirmed has to have a slightly higher barrier to it, so I propose that any user who has edited for more than 4 days and has more than 25 edits can move a non-full-move-protected page.

So...critiques? Comments? Concerns? NuclearWarfare contact meMy work 22:19, 30 October 2008 (UTC)

This is a good modification to my suggestion a few sections above. I'd say 50 edits (really, how many brand new users need to move pages and can't find someone to do it?)--extending the limit ensures the gr*wp style 'innocuous' edits are more likely to be noticed, if they can even be bothered to make that many. Or maybe 25 if it can be set to mainspace- and unreverted only. [ roux ] [x] 22:24, 30 October 2008 (UTC)
Why will 25 edits make more of a difference than 10? It will be a little more work, but Grawp has shown that he doesn't mind 10 edits. 100 edits might make a difference, but that's going to be more harm than good. If the edits made were actually helpful, I might support this, but they're often just pointless edits to a userpage. There are
better options that will have less negative impact on legit new users. Mr.Z-man
22:30, 30 October 2008 (UTC)
The problem is that the move right is one that we want relatively new users to have. If we increase the threshold to 25, Grawp will simply undo 25 edits from recent changes and keep moving. When we consider a system to oppose vandalism, the highest priority must be given to the idea that the system should not be game-able. As it stands, we have a highly game-able system on the technical level, and a virtually ungame-able system on the human level: it's easy to get autoconfirmed, but hard to avoid being blocked on a Grawp-spree. As your proposal involves only a minimal increment to the difficulty of gaming the system at the technical level, I don't see the point of its implementation—especially as it increases the barriers for those who edit in good faith. The ideal system would block all bad-faith vandalism with no false positives, and let through all good-faith newbies who simply can't format wikitext the way we prefer: it would be ungame-able. If only we could build it… {{Nihiltres|talk|log}} 22:38, 30 October 2008 (UTC)
At what point does the administrator time spent fixing cut-and-paste pagemoves exceed the time spent fixing pagemove vandalism? Pagemove vandalism is easy: just hit the "rollback" and "delete" buttons a few times. Cut-and-paste moves are a good bit harder. --Carnildo (talk) 22:53, 30 October 2008 (UTC)

The

Abuse filter is coming, I promise! — Werdna • talk
00:01, 31 October 2008 (UTC)

[citation needed] --MZMcBride (talk) 00:04, 31 October 2008 (UTC)

This is an interesting proposal, although I would prefer that the move right requirements be 4 days plus approximately 20-25 unreverted, non-revert edits in the main namespace. I can't think of many examples where this would be a problem to legitimate editors, and would prevent Grawp from simple reverting edits. It might require a change to the software, however. -- Imperator3733 (talk) 14:38, 31 October 2008 (UTC)

If we had a user group intermediary to autoconfirmed and rollback, (for example 'surveyors' in the context of

flagged revisions), an effective and non-obtrusive method would be to delay page moves from autoconfirmed users pending verification by a user in this group. Cenarium Talk
18:33, 31 October 2008 (UTC)

I think what's required is for there to be a gap between making the 10 edits and getting autoconfirmed. If there is no gap then there is no time for anyone to determine if the edits were good or not (trying to automate that bit is asking for trouble). How about changing autoconfirmed (for both semi-protected edits and moves) to 4 days total since registering, 10 edits and 24 hours after the 10th edit? It would require some coding work, of course. --Tango (talk) 14:09, 3 November 2008 (UTC)

No more barriers to new users please. the skomorokh
15:34, 4 November 2008 (UTC)

Proposal for new wiki

I suggest that a new wiki is made-a wiki for all minor wiki's. This is because I saw StructulWiki. I think that there should be a wiki for all minor wiki's.--DJackD (talk) 08:42, 5 November 2008 (UTC)DJackD 06:41 p.m. 05/11/08 (GMT+10)

This is the place for making proposals about the English Wikipedia, not for proposing the creation of new wikis. Algebraist 11:44, 5 November 2008 (UTC)
Please see m:Proposals for new projects with instructions. Meta is the central place for Wikimedia projects; Wikipedia is just one of many hundred projects. Best, PeterSymonds (talk) 11:53, 5 November 2008 (UTC)

User:Apovolot/Expert peer review

See User:Apovolot/Expert peer review proposal. Apovolot (talk) 01:10, 6 November 2008 (UTC)

Link. [ roux ] [x] 01:23, 6 November 2008 (UTC)

A New Skin

I just thought of something. All Wikia wikis use a real new modern skin, known as Monaco. Maybe Wikipedia should upgrade into that. It has many new features, including fly-out menus, wider articles and much more.  

Talk to me!
03:24, 6 November 2008 (UTC)

Proposal: New article creation limits/autoconfirm change

I've had an idea for (somewhat) reducing the insane flow of BS vanity/attack/nonsense/nocontext pages. It's a two-pronged approach:

1) Raise the autoconfirm threshold to 10 days/100 edits. 2) Require page creation by non-autoconfirmed users to run through

WP:WIZARD
or one of its equivalents (there's a better one, but I've mislaid the link).

This has a bunch of benefits:

  • Immediately reduces Gr*wp-style get-ten-edits-then-poo-on-WP pagemove vandalism; I doubt that anyone involved with that--or /b/--is going to bother with 100 productive edits just to poo on things. Even if they do, it's a net benefit to the project;
  • Will help reduce the creation of insta-dumb pages by driveby people with too much time on their hands; 2-3 minutes to fill out a few fields is (I think) a sufficient barrier to entry for the casual doofi. The less-casual won't be dissuaded by anything short of an electric shock, so we're sort of SOL there;
  • Doesn't provide much more of a barrier to entry than a CAPTCHA for IPs;
  • Helps train new users in basics of MOS, formatting, etc.

Thoughts? [ roux ] [x] 05:37, 26 October 2008 (UTC)

I definitely oppose the idea of increasing the autoconfirm threshold. We just increased it from 4 days to 4 days/10 edits a few months ago. I remember there being some concern back then about new users being driven off by the edit requirement before they have the ability to create articles. Raising the requirement to 100 edits would, IMO, drive away too many potential users to be acceptable. I would, however, prefer that the threshold be 4 days/10 undeleted/unreverted edits. That minor change would not affect users making positive contributions to the encyclopedia, and would make it harder for vandals to gain the ability to move pages. This might require a change to the software, however.
As far as requiring new pages to be run through something like
WP:WIZARD, I think that also has the potential to drive new users away. I would suggest simply making a more noticeable link to MOS in the edit area (preferably with the ability to turn off that notice in preferences for the more experienced users). -- Imperator3733 (talk) 06:28, 26 October 2008 (UTC)

I strongly disagree with such a high autoconfirm limit, but I strongly support some sort of limit, maybe even only three edits and no time requirement. But this is serious. I'm sick of ~60% of all new articles being made by users as their first and only edit, and ~90% of them being spam, attack, unsourced, non-notable, and/or OR. There needs to be a higher limit to create new articles, and it does not need to be as huge as that proposed, but there must be something. Reywas92Talk

15:39, 26 October 2008 (UTC)

Are you saying that you think the autoconfirm limit should be just 3 edits? If so, that would be lower than the current limit, which conflicts with your comment about wanting to raise the limit. In case you don't know already, users must be autoconfirmed (currently 4 days/10 edits) in order to create new pages, move pages, or edit semi-protected pages. -- Imperator3733 (talk) 17:29, 26 October 2008 (UTC)
No, the current autoconfirm should stay as it is. I didn't quite realize that the proposal was actually two completely different proposals. On 1) I oppose; the current autoconfirm for editing protected pages, etc. is fine. On 2) I also oppose because we already know by experience that a forced Wizard does not always work, though an optional one can. I support a second autoconfirm that only applies to article creation. It doesn't have to be long, but there must be more than allowing any registered user with zero idea how to do anything on WP to create articles that the rest of us must deal with. Reywas92Talk 18:02, 26 October 2008 (UTC)

I support the idea. 100 edits may be too much, but something like 20-50 edits is good. There should also be a mechanism to stop new users from making more than 10 edits to a page within half an hour. This would make it completely obvious whether it's a vandal account trying to attain the autoconfirmed requirements because they would switch pages. A new series of warning messages could be developed, and this could be a blockable offense. The result would be zero page move vandalism and better articles. --Pwnage8 (talk) 23:49, 26 October 2008 (UTC)

There was extensive discussion in May about raising the autoconfirm threshold. As a result, it was changed from 4 days/0 edits to 4 days/10 edits, with a majority of editors (but not enough for a rough consensus) in favor of 7 days/20 edits. So 10 days/100 edits is absolutely a non-starter; please drop that part of the proposal.
As for whether non-autoconfirmed editors should be able to create new pages in mainspace/articlespace, it would really be helpful to have some data. For example, of the x thousand new articles created on a given day, what percentage are created by non-autoconfirmed editors, and of those, what percentage are deleted or turned into redirects to previously existing articles, within (say) a week?
Finally, it's impossible to come up with any requirements that will absolutely prevent move vandalism, short of requiring admins to do all page moves (which we certainly don't want). The objective of increasing the autoconfirmed threshold was simply to make it more costly (in terms of time) for a vandal to get a new account to autoconfirmed status, and to make it more obvious (by looking at the edit pattern) that an account doing move vandalism had been created solely for that purpose. As many other editors have pointed out, making it harder for editors to qualify to do something does reduce vandalism, but the cost is that good editors aren't able to do useful things (for a while, at least), and may be sufficiently discouraged as to simply stop editing. In short, there is alway a cost-benefit tradeoff; the goal is to find that point where benefits most exceed costs. -- John Broughton (♫♫) 14:22, 27 October 2008 (UTC)
I am aware of the cost-benefit tradeoff. I support the idea of raising the autoconfirmed requirements because I think it would be a net benefit. Editors who are interested in contributing to this encyclopedia would stick around long enough to attain them, and vandal accounts would be outed through their editing pattern. If someone makes a new account for the sole purpose of making an article on themselves or their favourite non-notable band, then maybe discouragement is the way to go! --Pwnage8 (talk) 16:44, 27 October 2008 (UTC)

I support the x non-reverted edits rule and the wizard for one's first new page. It Is Me Here (talk) 14:25, 27 October 2008 (UTC)

Proposal 2 only - We could just try the latter. Goodness knows we could use some backlog reduction at Special:NewPages. Sometimes it seems that there are just a few of us there for a job that requires dozens. I estimate (blindly) that 3/4 pages is never patrolled. Even cutting that by 1/3 would be great. NuclearWarfare contact meMy work 02:52, 28 October 2008 (UTC)

God, no. Autoconfirm as it is already has near-draconian requirements; at this point, and any higher ones, it's just going to drive away legitimate users. As I said in the last autoconfirmation-raising debate, it is a trivial task to write a grammar bot in Perl/Ruby/Python and have it make minor corrections at rates high enough that these kinds of limits don't matter. All they do is hurt new editors who don't understand why they aren't "good enough" to meaningfully contribute (i.e, edit semi-protected articles, which is a growing subset of articles, and are also generally the ones drawing the most attention). Celarnor Talk to me 18:58, 1 November 2008 (UTC)

As the worst of the vandalism is page moves, would putting the move limit to a second auto-confirm longer & later make sense, most newbies don't move pages so this would not scare anyone off, especially if the move tab was hidden or linked to
main page. Wikipedia uses a rich vocabulary. Making it easier to look up unfamiliar terms that are not blue-linked would aid our readers. I would suggest adding Wiktionary to the toolbox. The navigation area might also be appropriate, but adding a line there would move the search box lower, and that might might be too much of a change in our overall look. To those who might question adding a link to Wiktionary and not to other sister projects, I would point out that we do link to other projects from articles where there is relevant content on the sister project, but Wiktionary is of potential use to a reader of any article. --agr (talk
) 20:23, 28 October 2008 (UTC)

Oppose; as all the other links in the sidebar are, naturally, internal links. Every external link on the project is careful to indicate that it is indeed taking readers elsewhere, either with the external link icon or by explicit statement "on wiktionary", "at wikispecies", etc. There is no need to add such a confusing 'hole' through which readers can inadvertantly leave en.wiki. Anywhere a valuable link to wiktionary could be made, of course, there is nothing to stop you doing so,
within reason. Happy‑melon
20:33, 28 October 2008 (UTC)
Oppose, please, no clutter to non-reliable links. SandyGeorgia (Talk) 20:35, 28 October 2008 (UTC)
Most of our links are to Wikipedia, which is no more reliable than Wiktionary. Quite possibly less so; many of our Single Purpose Accounts would find nothing to do on Wiktionary. I don't see the force of this objection. Septentrionalis PMAnderson 22:10, 28 October 2008 (UTC)
The point of SandyGeorgia's comment is that it's considered a good general principle in web design that a reader should have some warning when they're leaving a site. If they're expecting an internal link and get an external link they can become disoriented. Dcoetzee 04:13, 29 October 2008 (UTC)
I would support the ability to add a template that adds an "other projects" sidebar link to Wiktionary where relevant, but outside of that, I don't think it would be as relevant as you think it would be. EVula // talk // ☯ // 20:41, 28 October 2008 (UTC)
No more sidebar clutter please. Incidentally, "unfamiliar terms" should be blue-linked; if to Wiktionary then with [[wikt:term]]. -- Fullstop (talk) 23:50, 28 October 2008 (UTC)
I have been editing on Wikipedia for 4 years and I have never seen a link to Wiktionary in an article. Can you point to a policy or guideline that says that? We routinely transwiki articles deemed to be no more than dictionary definitions to Wiktionary. When this is done, as far as I have seen, links to the transwikied page are deleted. --agr (talk) 19:31, 29 October 2008 (UTC)
There are many, though usually within the lead section. Search for wikt to find 700+ instances. (Though, I expected to find more than that. I find these useful, and think they should be officially encouraged)
However, I can't find any kind of guidance on when they should/not be used. Should probably be discussed (or any discussion linked to from)
Wikipedia talk:InterWikimedia links. -- Quiddity (talk
) 22:20, 6 November 2008 (UTC)
Thanks for finding those examples. That there are only 700+ instances in 2.6 million articles supports my point that such links are rare. And many of the examples are specialized uses such as links to foreign words, as in "
Hindu goddess of wealth and prosperity." But even if wikt links were expanded a thousandfold, we would still be in the position of trying to anticipate what will be unfamiliar to our readers. I would suggest that this is the wrong approach. Every word on Wikipedia would be linked to Wiktionary. A mechanism where the reader could highlight a word and then click a lint to find that word in Wiktionary would be best. What I am proposing, a sidebar link to Wiktionary, is less than ideal but simpler and could be implemented immediately.--agr (talk
) 00:06, 7 November 2008 (UTC)
There's also {{
Wi}} (about 500 uses), and a handful of templates with only a few uses. Mr.Z-man 01:41, 7 November 2008 (UTC)

bugzilla:708. — Werdna • talk

14:08, 29 October 2008 (UTC)

I support this too.
Interwiki links under “languages” are a precedent for sidebar links to other wikis. In fact, adding a “projects” box above languages, and having a format for including sidabar project links would reduce the hideous clutter of sisterlink boxes. Maybe adding a colon puts a link in the sidebar, e.g. [[:wikt:entry]]
A standard external link icon could clearly show that the link is external, as opposed to [[wikt:]] links, which do not. But this wouldn't really be necessary, anyway. —Michael Z. 2008-10-29 20:04 z
Couldn't this be done programmatically? If the article exists on a sister, a link is autogenerated. If not, not. Requires no behavioural changes to editors, just deletion of extant sisterproject boxes in See Also & EL sections, something that would be trivial with a bot. [ roux ] [x] 20:24, 29 October 2008 (UTC)
Maybe, but it would need some smarts, and probably shouldn't add entries without supervision. For example, Wiktionary entries follow normal capitalization rules, so we have wikt:banana but wikt:Ukraine. In some cases the link may have a different name, like Regina, Saskatchewan may link to wikt:Regina.
But anyway, adding a bot is a secondary consideration, which would follow anything we determine about sidebar links. —Michael Z. 2008-10-29 21:18 z
A similar system is used in Lithuanian Wikipedia. For example, lt:Europa has such links (the relevant box in sidebar is "kituose projektuose"). Templates like lt:Šablonas:Vikicitatos or lt:Šablonas:Vikižodynas are used to indicate the articles that should have such links. --Martynas Patasius (talk) 23:45, 31 October 2008 (UTC)

I don't think internal vs external vs sister site is the important issue. The question should be what is most useful to our readers. Do we have a way to tell how often the side bar links are used? If so, I would propose trying a Wiktionary link for 6 months and see how it does.--agr (talk) 14:02, 2 November 2008 (UTC)

Enable mw:Extension:Nuke

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.
Seems to be consensus (85% supporting) and this discussion has been open for over 1 month. The bug to have this enabled has already been filed (see bugzilla:15783). No need to continue discussing this. - Rjd0060 (talk) 03:23, 8 November 2008 (UTC)

Meta recently had a poll that passed that permits small wikis to enable the mw:Extension:Nuke. Due to its size, the English Wikipedia was not included in the poll and the decision has been left to us locally if we would like to enable such a feature.

In short, nuke permits administrators to delete all the recent pages created by a single user. This feature would be especially useful with grawp and spammers and would be

easier
on the servers than current deletion scripts used by admins to fight grawp (as well as more accurate). So I'd like to start a local poll on the question of enabling the nuke extension here.

Support enabling

  1. Obviously. MBisanz talk 12:16, 25 September 2008 (UTC)
  2. This would be very advantageous for admins and developers alike; both reducing server lag and helping with the mass reversion of spammers and vandalbots. — ^.^ [
    needed
    ]     12:55, 25 September 2008 (UTC)
  3. Sounds like a good idea with no obvious negatives. -- Imperator3733 (talk) 16:35, 25 September 2008 (UTC)
  4. Looks good to me. Shereth 16:43, 25 September 2008 (UTC)
  5. I agree, this could be very helpful. Mr.Z-man 16:53, 25 September 2008 (UTC)
  6. Support, definitely. - Rjd0060 (talk) 17:07, 25 September 2008 (UTC)
  7. Support; nuke it from orbit, it's the only way to be sure. --—— Gadget850 (Ed) talk - 17:12, 25 September 2008 (UTC)
  8. Mwawhawhawhawhaw... er, I mean Support... :D Happy‑melon 17:23, 25 September 2008 (UTC)
  9. Giving nukes to 1500 random people on the internet? What could possibly go wrong? Support henrik•talk 18:00, 25 September 2008 (UTC)
  10. Support. --MZMcBride (talk) 18:41, 25 September 2008 (UTC)
  11. Though I'd be even happier if there was an un-nuke option as well. EVula // talk // ☯ // 21:41, 25 September 2008 (UTC)
    I'd like to amend my comment to say that I definitely think that a seven day limit would be a fantastic way of limiting inadvertent (or even malicious) abuse of the tool. EVula // talk // ☯ // 00:51, 30 September 2008 (UTC)
  12. Support. I've always wanted to have my own nuclear weapon. So long as I don't have to have the demon core on my desk as well.-gadfium 22:08, 25 September 2008 (UTC)
  13. Support, as long as I get to keep the
    football. Waltham, The Duke of
    03:23, 26 September 2008 (UTC)
  14. Support, per MBisanz (talk · contribs). Cirt (talk) 12:46, 26 September 2008 (UTC)
  15. Support Seems like a good enough idea. –Juliancolton Tropical Cyclone 12:52, 26 September 2008 (UTC)
  16. Support, this would be very helpful (and Grawp will die of radiation poisoning).
    m
     12:57, 26 September 2008 (UTC)
  17. Support with some upward limit on pages created. Protonk (talk) 18:57, 26 September 2008 (UTC)
  18. And when it supports uploads, it'd be great on imagevio uploaders as well. MER-C 13:21, 27 September 2008 (UTC)
  19. Support but I really think the software should be scripted to allow un-nuking with the same amount of work. It can't be that hard to code a reverse-option, all it has to do is undelete a list of articles which are hopefully logged to have been nuked. Or aren't they? I really think there ought to be a nuke log if they aren't. SoWhy 13:35, 27 September 2008 (UTC)
  20. Support as a valuable tool against vandalism and spam, but at the same time if this is a problem, why not just put a common-sense restriction on article creation for new accounts, something like 1 article per day for the account's first 30 days or 100 edits, whichever comes last. Andrew Lenahan - Starblind 18:27, 27 September 2008 (UTC)
  21. Support, provided that the tool is in fact limited to what is in the recentchanges table (as discussed below) - that is, is limited to new pages created by an editor in the past 30 days. With that limit, a rogue or compromised account isn't likely to be able to do much damage before being de-sysopped. -- John Broughton (♫♫) 00:44, 28 September 2008 (UTC)
  22. Support, with John Broughton's proviso to limit the period to 30 days. In practice, that could even be reduced to 7 days or even less, since a spate of spurious creations is likely to be noticed by someone relatively quickly. Horologium (talk) 01:11, 28 September 2008 (UTC)
  23. Support though a limit to 30 days would be good. Hut 8.5 11:03, 28 September 2008 (UTC)
  24. Support but I do like the idea of some sort of time limit (Broughton/Horologium) Scottydude review 13:10, 29 September 2008 (UTC)
  25. Support, provided that the nuke button is big and red ;P. Seriously, though, this is a good idea. I agree that a limit to 30 days would be a good idea. TalkIslander 10:17, 1 October 2008 (UTC)
  26. Support with limit. And yes, an un-nuke option would be handy there too. Garion96 (talk) 12:01, 1 October 2008 (UTC)
  27. support With the understanding that Nuke will be used only for the most blatant of vandalism and not in other situations. JoshuaZ (talk) 17:21, 5 October 2008 (UTC)
  28. — Werdna • talk 00:45, 11 October 2008 (UTC)
  29. Qualified support: I approve of the addition of this extension so long as a) it is only used on blatant vandalism (e.g. Grawp) and b) that there be a corresponding "un-nuke" feature available to all admins at time of installation (even if this feature has to be JavaScript added to Sysop.js). We already have the potential to do this with scripts, so adding it to the software is relatively trivial. My concerns are largely because of how it should be used rather than because it should not be used. {{Nihiltres|talk|log}} 07:10, 19 October 2008 (UTC)
  30. Support provided that there's a strict policy on its usage, as I'm sure there will be. ╟─Treasury§Tag►contribs─╢ 07:20, 19 October 2008 (UTC)
  31. Support - We give admins delete rights, this is just saving them the button-mashing. An "undo" ought to be available, obviously. Pseudomonas(talk) 10:06, 19 October 2008 (UTC)
  32. Support if there will be a strict "don't use unless you have to" policy. NuclearWarfare contact meMy work 00:53, 20 October 2008 (UTC)
  33. Support -- even if just to fight grawp and similar nasty things. Further justification: nuke as an "Admin" ability won't hurt anyone that doesn't already fear Admins. --Kuzetsa (talk) 22:56, 22 October 2008 (UTC)
  34. Yet another powerful tool to add to the administrative toolbox - all in all, one that could greatly benefit the site. But use cautiously, or else the nuke could leave radiation behind. ;)
    Talk
    ) 05:43, 25 October 2008 (UTC)
  35. Support Wizardman 20:30, 25 October 2008 (UTC)
  36. Support—Tony (talk) 02:58, 28 October 2008 (UTC)
  37. Support - simplifies the messy stuff. "Undo Nuke" would be a good safety measure, of course. --Ckatzchatspy 17:04, 28 October 2008 (UTC)
  38. Support - this is just a more efficient way of doing something currently done with scripts. Undo would be nice, but if abused it can be undone by a script (and the responsible admin punished). This is a rare situation, so this is okay. Dcoetzee 01:14, 30 October 2008 (UTC)
  39. Highly useful tool. –
    talk
    ) 18:10, 3 November 2008 (UTC)

Oppose enabling

  1. Pending un-nuker or equivalent. We must have balance in the force. -- Ned Scott 03:28, 26 September 2008 (UTC)
  2. Far too open to accidental misuse (or even deliberate misuse, in the unthinkable event that we ever get an admin who is less than entirely scrupulous in his regard for policy). DuncanHill (talk) 23:05, 26 September 2008 (UTC)
    Why are we letting a hypothetical situation that has never happened (to the best of my knowledge) stop us from effectively undoing situations which are all too common? EVula // talk // ☯ // 00:41, 30 September 2008 (UTC)
    I hope that's sarcasm... --NE2 02:38, 6 October 2008 (UTC)
    Echo the above. Considering the huge problem that it will produce when misused (and it will get misused, just as every other tool does), I'd rather not have it granted at all. Celarnor Talk to me 10:34, 6 October 2008 (UTC)
  3. We make too many mistakes as it is. DGG (talk) 00:29, 30 September 2008 (UTC)
  4. "Pending un-nuker or equivalent" as stated above -- Philcha (talk) 09:01, 6 October 2008 (UTC)
  5. Too open to abuse, weak community oversight, difficult to undo, etc. Too many negatives, not enough benefit. Celarnor Talk to me 10:31, 6 October 2008 (UTC)
  6. Per Ned, there needs equally automated way to revert this. — CharlotteWebb 11:02, 6 October 2008 (UTC)
  7. Per DGG. Giggy (talk) 08:11, 14 October 2008 (UTC)
  8. Same as Ned and DGG. If an Admin went rouge or his account was compromised Nuke would make it possible for him to kill the popular pages, the main page, the sandbox, and all he wants in a couple of minutes, which would crash wiki and take a lot more time to restore than Grawp's moves. If it's possible to undo the nuke with a couple of clicks I will support.--Yamanbaiia(free hugs!) 11:01, 19 October 2008 (UTC)
    No it wouldn't. It can only delete pages created in the last 30 days. It can't delete anything that can't already be deleted. I think there's some misunderstanding about what this actually does... Mr.Z-man 02:11, 23 October 2008 (UTC)
    I didn't know that, mw:Extension:Nuke and this discussion is all I've seen about Nuke. I also didn't know that there already is a special script that allows admins to mass delete pages, which IMO makes of this an avoidable discussion. I don't oppose Nuke anymore.--Yamanbaiia(free hugs!) 20:55, 23 October 2008 (UTC)

Questions

Since we've just had several issues with admins recently, including socks, and an arbcomm case, I'd like to know how easy it would be to reverse this. So, would these also be undeletable as a group? - jc37 17:24, 25 September 2008 (UTC)

It would be added as a right to the admin group. Seeing as admins already have a large number of rights at Special:ListGroupRights and this feature can be duplicated by external software, there is really no more risk to an rogue admin with this tool than there is to an admin without it. Just that non-rogue admins will have an an easier time cleaning up with it. MBisanz talk 18:04, 25 September 2008 (UTC)
Let me clarify: If User:nuker (an admin) "nuked" three pages with the tool, is there an "un-nuke" version of the tool for undeleting all three simultaneously (the way they were deleted), or would they have to be undeleted one at a time?
This becomes even more "fun" when hundreds of pages are "nuked". - jc37 18:09, 25 September 2008 (UTC)
Currently, no, Mediawiki doesn't have an Un-Nuker, but many admins do have scripts that will do the same thing. So basically we'd be replacing Script-based Deletion and Script-based Undeletion with Software-based Deletion and Script-based Undeletion. MBisanz talk 18:16, 25 September 2008 (UTC)
Mk. Thank you for the clarification. While (presuming the trend continues) this is likely to pass, I think I'll stay neutral. Thanks again. - jc37 18:23, 25 September 2008 (UTC)
The successful detonation of a nuclear weapon above ground is invariably accompanied by a spectacular display of fireworks, which cannot be rewound (unless on video).[1]
I don't know why jc37 finds this disagreeable, but I consider the parallel with real-world nukes quite poetic. :-) Waltham, The Duke of 03:23, 26 September 2008 (UTC)
Well, since you asked : )
A key thing about the existing "tools" on the wikis is that there is something of a "balance". Any action can potentially be undone by another action of presumably equal effort.
Well, that "balance" has been gradually changing as new scripting tools and extensions and so on have been added. The speed at which someone can take an action is not necessarily the speed at which someone can undo the action any more.
And even Arbcomm has spoken out in several decisions regarding
fait accompli
(which is a fair amount of what such tools can potentially be). Imagine that someone is bold and moves every article of a certain topic to a name of their preference, even though those articles were a part of a larger topic, and follow a different convention, and consensus is that this should be reverted. Now unless one also has AWB (which should not be presumed), then undoing this could be quite a task. And this is just one example. I honestly have seen far more examples of "personal preference pushing" using tools than we really should see.
And so if we now allow admins to mass delete pages, but there isn't a counter for other admins to undo that action, well, I think you see my concern.
That said, I'm doing some
WP:AGF, and am attempting to hope for the best. And I do understand the value of admins having the ability. Hence staying neutral. - jc37
09:40, 26 September 2008 (UTC)

I'm inclined to share Jc37's concerns. Also, what is the definition of "recent edits" here? And does it only delete pages that have only one contributor or will it also delete pages that others have edited? What, for example, would happen if a rogue admin attempted to nuke in short order the articles created by Rambot and other editors with large numbers of contributions? The available documentation is not very clear about such things. older ≠ wiser 14:30, 26 September 2008 (UTC)

If this proposal is adopted, it should only be given to admins who pass RfA after its introduction, as RfA's prior to that will not have examined the candidate's perceived trustworthiness with such a powerful tool. Also, how about watchlisting this? It is a proposal for a massive change to admins' tools. DuncanHill (talk) 23:17, 26 September 2008 (UTC)
No it isn't, its not giving them the ability to do anything that they can't already do. Right now they'd have to go to Special:Newpages, filter it to show articles by the user in question and delete those pages. Mr.Z-man 15:38, 27 September 2008 (UTC)
Recent edits means everything that's in the recent changes (database) table. Entries in the table are set to expire after 30 days. MER-C 13:46, 27 September 2008 (UTC)
Is that documented somewhere? There is only the barest mention of "recent edits" at mw:Extension:Nuke. I'd be less concerned over implementing this if the scope is limited to only the past 30 days. older ≠ wiser 22:49, 27 September 2008 (UTC)
No, not really. If you can understand (at least vaguely) PHP, in getNewPages(String username) (view source) - which returns the list of pages to be nuked - it does a query against the recentchanges table. The lifetime of table entries is governed by $wgRCMaxAge, which is set to 30 * 86400 seconds = 30 days. MER-C 06:55, 28 September 2008 (UTC)
Thanks. Any clarification about my other main concern -- does this nuke only pages where there was one editor, or does it not check whether there were other editors? older ≠ wiser 16:53, 28 September 2008 (UTC)
I don't know. Sorry. MER-C 09:59, 29 September 2008 (UTC)
I am not a code-person, but it is enabled at Commons, so maybe a an admin from there can explain that question. MBisanz talk 17:07, 29 September 2008 (UTC)
I think if the developers can create a rollback feature for nuke, then that would be great. An admin can view the "nuke" log, and click on the rollback button, much like rollbackers rollbacking a page from the page's history page because of vandalism, it would work and look the same way. It would be a great idea to the developers. Techman224Talk 02:57, 11 October 2008 (UTC)
See bug 15942. MER-C 02:47, 12 October 2008 (UTC)

Hm. Looks like this is going to be enabled. Now, what's the name of that bot that created 20,000 pages again? *requests adminship* -- Gurch (talk) 21:02, 30 September 2008 (UTC)

If you think that would work, you don't understand how Nuke works. — Werdna • talk 22:49, 20 October 2008 (UTC)

Alternate proposal

Since we are (rightly) worried that no easy way to "undo" this mess exists and we have had admin issues in the past. Let's instead give the nuke rights to 'crats. They are, right now, the vice presidents of the wikipedia world (presiding over the senate and going to state funerals). This gives us an easy way to have the functionality but restrict it to a very trusted group of people. Protonk (talk) 18:19, 26 September 2008 (UTC)

But this would be a fundamental change in the nature of what a 'crat does. The basic maintenance of the 'pedia, in the form of deletions/protections/etc is the domain and duty of administrators, and tools to that effect should pertain to them. If we do not trust administrators as a whole with a tool that pertains to administrative actions, then we should just not have the tool to begin with, rather than delegating admin duties upward. Shereth 18:29, 26 September 2008 (UTC)
That's fair. Protonk (talk) 18:56, 26 September 2008 (UTC)
As a bureaucrat, I don't think the nuke tool should be put solely in our hands (obviously we would have it as admins); our job is to ascertain community consensus, and our duties tend to involve user right modifications (promoting admins and other 'crats, bot flags), with renaming being outside of that. Nuking vandals is totally outside what we were chosen for, and limiting its scope to a dozen or so editors would severely limit its abilities (in a bad way). EVula // talk // ☯ // 18:14, 30 September 2008 (UTC)
18:46, 4 October 2008 (UTC)

Give it to Oversighters? There's usually one or two online at any given time and they're responsible, easy-to-reach and concerned with protecting the site from user-based abuse. ╟─Treasury§Tag►contribs─╢ 17:30, 5 October 2008 (UTC)

That's a much, much better idea. I don't like the idea of well over a thousand people retroactively having a new ability this strong granted to them. Celarnor Talk to me 10:33, 6 October 2008 (UTC)

If it's not too late for an idea, might I suggest implementing a new access level (perhaps called the "nuclear club") that has access to the nuke. Admins could be promoted to nuke status by bureaucrats based on input from both the admins and the community at large. Horselover Frost (talk) 08:40, 11 October 2008 (UTC)

Wikipedia doesn't need more bureaucracy and levels. I do agree with giving this feature to Oversighters for the reasons given by User:TreasuryTag.--Yamanbaiia(free hugs!) 11:05, 19 October 2008 (UTC)
I would similarly support a nuke version that was restricted to "trusted" persons, but absolutely no variant of the nuke system that would be usable by anyone. --Kuzetsa (talk) 23:00, 22 October 2008 (UTC)
Admins already have access to a variant of Special:MassDelete through a script. Nuke is really no more dangerous than that. Enabling it for all admins shouldn't bring any extra problems. PeterSymonds (talk) 23:05, 22 October 2008 (UTC)

Bureaucrats aren't necessarily trustworthy - I don't, for example, see why someone like

talk
) 18:15, 3 November 2008 (UTC)

Giving it to oversighters makes sense to me as does giving to to 'crats, having as a general adding power it would need an additional restriction such as no page with edits by more than 5(?) loged in users, or maxing out at 100 articles, would stop mass deletions buy rogue admins --Nate1481 15:15, 6 November 2008 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WP:Write for dummies

The original goal of Wikipedia, I believe, was to have an article on everything people would want to know about. With the English project going on 3 million articles, I think that goal has more or less been accomplished. Our attention should now turn to making the encyclopedia useful.

Far too many articles, even those on elementary topics, are largely or completely incomprehensible to general readers. Some articles, instead of having the complicated stuff at the bottom (or in more-specific articles), have high-level gobbledegook sprinkled from top down. Some use wikilinks as an excuse not to define important terms, forcing readers to go on a wild goose chase across Wikipedia in a vain attempt understand the first article. Some incorporate complex mathematical formulas that are gibberish to 99% of people.

There used to be a wikiproject called General Audience, but it's inactive. I think the problem was just too enormous for a single wikiproject to solve.

I think what we need to do is push people to incorporate comprehensibility into every Wikipedia article. (That is not to say that every article must be comprehensible by a general audience; rather, every article should be understood by those likely to read it.)

I think one way to do this would be to require what I call a "dummies test" before any article can become a

peer review. Instead of soliciting opinions from experts on the topic, a dummies test calls for the judgement of potential readers who are *not* well-versed in the topic. For example, a dummies test for Baseball
would call for people who don't know the rules of baseball to see if they can understand the article. For some complex topics, the dummies might be undergraduate students in the same field rather than just anyone, but in all cases, the dummies should be people not familiar with the topic.

Dummies would provide feedback from the point of view of likely readers. After all, people usually turn to encyclopedias when the don't know something. If the dummies cannot understand the article, it doesn't become a good article.

It should be apparent that by "dummy," I don't mean a literally stupid person but rather a "dummy" in the spirit of the "... for Dummies" books, which explain topics from the very basics up, just like Wikipedia should.

Some other things we can do include allowing the "too technical" tag to be placed on the article itself rather than the talk page and improving the

Wikipedia:Make technical articles accessible
page. I would also like to resurrect the General Audience project with the priority of making every article whose topic is basic enough to be included in World Book comprehensible to the average person.

Personally, I think "Wikipedia articles are aimed at and should be written for people who aren't already familiar with the topic" should be considered an important part of the

Wikipedia pillar "Wikipedia is an encyclopedia." "Write for dummies," therefore, should be an important policy and not simply a style guideline. -- Mwalcoff (talk
) 01:19, 3 November 2008 (UTC)

I certainly don't think something so subjective should ever become policy. That is a stylistic issue, and is appropriately dealt with as a stylistic guideline (and it already is, at
pillar of Wikipedia along the lines that Wikipedia is intended to provide information to people who aren't already familiar with a topic. You'd think this would be obvious, but apparently it needs to be spelled out.
I'm wary of the concept of "introduction" articles, although I think they're well-intended. In my opinion, the main article genetics should be the "introduction" article, with more-complex information included in subsidiary articles. -- Mwalcoff (talk) 13:48, 3 November 2008 (UTC)
I actually agree with the editor at the article on e. If something is incomprehensible to you, then you should probably read up on the prerequisites so you can fully understand it. Dumbing it down would be a disservice to our readers; If we do as you like, then the article on e would become either ridiculously huge as it tries to cater to every level of reader, or become something as completely useless as "e is a mathematical constant roughly equivalent to 2.71". For e to really mean anything to you, you have to understand how it was arrived at and what it really means (which means you need to understand limits). Celarnor Talk to me 17:23, 3 November 2008 (UTC)
I can see what the editor is saying about e article. Perhaps we should have some sort of page header like

{{User:Gnevin/sandbox1|read=Limits and Pi

}}

Gnevin (talk) 21:48, 3 November 2008 (UTC)
I like that, but I think it could be a bit smaller. 21:26, 3 November 2008 (UTC)


To reply to your other point(s), I don't agree that Wikipedia should be the first place to go to get basic information. If you want everything simplified, there's another project with that in mind; it's called Simple Wikipedia.
I think you're a little disoriented about the way in which Wikipedia is organized; we do provide information to people who aren't familiar with a topic. You can easily learn what
tangent line, limit, function, etc. There's no need to extend definitions given in other articles all over the project like that just for the sake of it.
The alternative solution, is of course, to present information in a way that someone doesn't need to know about the requisite information. Of course, then we lose accuracy, precision and conciness; describing things in technical terms is the best way to achieve those things. If valuing accuracy, precision and conciseness (e.g, describing derivatives for what they are, "the slope of a tangent line at a single point" vs "the value of the change in the y axis divided by the change in the x axis a line drawn against another line in such a way that it only touches one part of the line") requires that we try to point readers to the material that they need to understand first, then fine. I don't have a problem with that; that's how people learn anyway.
Ultimately, I think this kind of things comes down to whether you want to cater to a reader who wants to understand something, or a reader who wants a quick summary of things; as a member of the former group, I hate to see articles dumbed down to the point where its next to useless with the point of making it accessible to someone who just wants a quick definition.
I think the "introduction to x" articles are a good compromise; they don't cause the damage associated with dumbing down to the main article, and they provide a place where requisite material can be summarized and simplified for someone who is only interested in a quick definition or summary and isn't really interested in the material. And it makes sense; if you just want an introduction to genetics, and aren't looking to really understand it, that would be the place to go. The answer certainly isn't dumbing down the main article on genetics to that level. Celarnor Talk to me