Wikipedia:Village pump (proposals)/Archive 31

This seems like a good idea. It doesn't give the oversighters more power, just allows them to perform their function properly, i.e. removing things that even admins should not see, whereever they are. Kevin (talk) 01:33, 22 July 2008 (UTC)

This is absolutely a good idea and I fail to see how it gives more power. —Giggy 03:46, 22 July 2008 (UTC)

I admit I'm a bit wary of changing log entries (perhaps it can leave a note the entry was removed?), I otherwise have seen firsthand how these could be useful tools to have available. – Luna Santin (talk) 03:58, 22 July 2008 (UTC)

Hell No. In light of certain editors' use of oversight to cover up wrong-doing, logs must not be tampered with, period. I will not name names, but those who've been here for awhile know exactly who I mean. Good grief, what a terrible idea. --Dragon695 (talk) 04:34, 22 July 2008 (UTC)

• While that's a concerning issue, I believe the oversight log is not all that large. Therefore, oversighters will be able to monitor usage of the tool quite easily. Any abuse, should it happen, will be spotted quickly. Abuse, however unlikely, can still be overturned by system administrators; oversighted material is not irretrievably lost. PeterSymonds (talk) 10:24, 22 July 2008 (UTC)

Well Revision Delete will be quite useful to enwiki but I'm not sure how it will be used by those who will have this right i.e CU and oversighters, the bug filed on it hasn't really been given a second thought previously but introducing Revdel will actually need a full community support before it gets implemented, something similar to the [rollback] feature and the log problem was partly fixed but it still doesn't work well as Grawp has proven it, thus revdel is the only option for now...--Cometstyles 04:52, 22 July 2008 (UTC)

I've never been comfortable with the complete lack of accountability for oversight. Even a simple "two log entries have been removed from this user's logs" or "three deleted revisions of this page have been hidden" would be sufficient. As it stands, oversight has a strong resemblance to a memory hole. --Carnildo (talk) 08:31, 22 July 2008 (UTC)

Tend to agree with Carnildo. Would also like to explore the idea that oversighting logs be undertaken by a paid employee of the Foundation with such actions somehow audited. To pay for this position I would suggest allowing adverts on the search page, unless someone has a better idea. Obviously that suggestion will kill the idea, but at some point we are going to have to explore revenue options and the sourcing of paid labour for tasks with a high level of legal responsibility. Hiding T 10:59, 22 July 2008 (UTC)

That would be both unpopular and redundant as Brion Vibber is a paid employee who already has the ability to do this. — CharlotteWebb 19:12, 22 July 2008 (UTC)

All oversighters, like checkusers, are: identified to the Foundation, over 18, and fully accountable for their actions. There is no lack of accountability for oversight. If it's abused, it's removed. All oversighted edits are retrievable, and the log is short, so it can be easily monitored by others. There's not much need for paid positions, given that all credentials given to the foundation are scrutinised, and adverts on Wikipedia is not a good idea. With images such as child pornography, it can only be hoped that an admin doesn't stroll across one. With the proposed introduction of DeletedEdits to non-admins, this is even more of a danger. Furthermore, logs that contain libellous summaries or personal information will need to be removed, and with Wikipedia growing at the speed it is, that need will increase. PeterSymonds (talk) 11:37, 22 July 2008 (UTC)

As with Carnilido, there needs to be at least a little visibilty and transparency (ironically enough) in the oversights of logs. It could potentially be open to abuse but with the accountability measures, most of which are described by PeterSymonds above, this may not be as big a problem. Referring back to the first point, it would be a reasonably good idea but I shouldn't think most oversight members will be entirely content with oversighting logs due to the nature of such a measure. Rudget (logs) 13:28, 22 July 2008 (UTC)

No issues oversighting images, or deletion logs, or protection logs, or pagemove logs, but the high probability of abuse of, and low general risk of private info in them, makes me think block logs should not be oversighted. MBisanz ^talk 13:44, 22 July 2008 (UTC)

If an oversighter is abusing their rights, then an RfA should be started. Unless Dragon695 can provide evidence of the abuse, then they're using straw man arguments. Corvus cornix_talk 18:05, 22 July 2008 (UTC)

I believe you mean RFAR. Due to the oversight logs being non-public, material for the "/Evidence" page would be exceedingly difficult to obtain. God help the fool who requests arbitration against an unknown party effectively on the basis of hearsay. You can decide for yourself whether

Oversight's lack of oversight is an oversight. — CharlotteWebb

19:31, 22 July 2008 (UTC)

My complaint is that it is not possible for an ordinary user to know if an oversighter is abusing their rights, except (maybe) by comparing complete database dumps from different points in time. An oversighter could declare a user an "unperson", block them, oversight the block log, and oversight their edits, and there would be no way for an ordinary user to tell this from someone who's created an account but never used it. --Carnildo (talk) 19:51, 22 July 2008 (UTC)

This entire thread is a bit silly. The software has been written; it simply isn't enabled. At some point, it will be, regardless of whether or not Dragon695 or anyone else finds it objectionable. Corvus: You mean RfAr, not RfA, right? : - ) --MZMcBride (talk) 18:29, 22 July 2008 (UTC)

Uh, yeah, that.  :) Corvus cornix_talk 18:56, 22 July 2008 (UTC)

I propose that edit summaries be mandatory for all edits in the article namespace and template namespace. Ignoring any technical hurdles, how does the community feel about this? --- RockMFR 02:23, 19 July 2008 (UTC)

I doubt it's really all that useful. People who don't want to write summaries will start using meaningless ones, such as the letter a. Granted, there will probably be some increase in useful summaries too, but the downside is that you'll antagonize a bunch of people. --Trovatore (talk) 03:59, 19 July 2008 (UTC)

Edit summaries are for when an edit need explaining, which is not always.

Chillum

04:52, 19 July 2008 (UTC)

I often use a . to keep my summaries 100%, when I am editing something repeatedly, or mundanely (like a sandbox). I don't think it'd make much of a difference, and although summaries are nice, people shouldn't have to be forced to add them, as they don't really alter the quality of their work or the article. ~ JohnnyMrNinja 06:38, 19 July 2008 (UTC)

I do wonder if we can increase the amount of automatic summaries though, to make things a little easier. Such as "Added image", or "Removed section"/"Added section" ect. Just to help when viewing histories, as some of them for articles where many IPs edit can be very difficult as there is no indication whatsoever of what's been done. --

:.

08:31, 19 July 2008 (UTC)

I like Alex's idea better. It would be very nice if the software cam automatically put a summary like "its -> it's". Sometimes I'm too lazy to write such summaries, especially when I'm making the same kind of edits en masses. -- Taku (talk) 01:45, 20 July 2008 (UTC)

Taku, if you are making the same kinds of edits in masses, you might consider signing up for

AutoWikiBrowser, which facilitates such mass edits, and will fill in the edit summary automatically. − Twas Now ( talk • contribs • e-mail

) 22:57, 20 July 2008 (UTC)

The idea of more automatically-generated messages is a great one, but I don't know how that can be done with the Wiki software. Perhaps a browser plug-in or something? ~ JohnnyMrNinja 20:35, 23 July 2008 (UTC)

I find that firefox remembers the edit summaries I've typed. --Pwnage8 (talk) 23:19, 20 July 2008 (UTC)

I dont like the idea of forcing anyone to do anything, but perhaps I would agree that making the default value for Special:Preferences>editing>Prompt me when entering a blank edit summary>true could be helpful. for IP's who dont have pref's perhaps it could default to ask them as well. When I started editing I didn't know that the preference setting even existed, but once I learned about it I immediately set it to true.... Just a thought, hope it helps %%-SYKKO-%% (talk to me) 01:56, 22 July 2008 (UTC)

Setting it as default for everyone is a good idea. It will not force anyone to do anything, but will heavily suggest it. I found tnhis option annoying when I first started editing, but now I never see it (as I always do edit summaries). ~ JohnnyMrNinja 20:35, 23 July 2008 (UTC)

I don't think that feature works very well.

Chillum

20:38, 23 July 2008 (UTC)

Specifics? -- John Broughton (♫♫) 23:05, 23 July 2008 (UTC)

When I forget to enter an edit summary, it usually does not go off due to automatic edit summaries.

Chillum

23:53, 23 July 2008 (UTC)

I've created a Twitter account to broadcast the mainpage FA of the day. Read more here on why, and how to participate. Steven Walling (talk) 01:21, 24 July 2008 (UTC)

I'd be interested in using a bot that could scan an article, check for duplicate links, then add an overlinking report to that article's talk page (if necessary). This would allow the maintainers of the page to cull unnecessary redundant links, while still allowing some human judgment in the process. Is anybody interested in putting a tool like this together? Perhaps it could become part of the PR process? Thank you.—RJH (talk) 21:42, 17 July 2008 (UTC)

I think it'd be a great idea, though perhaps instead of a bot it might be best as a toolserver script like the FAC tools. I imagine that it wouldn't be all that hard to do: one could generate a list of wikilinks on the page and then note duplicates and highlight ones in the same or adjacent sections by doing separate checks for each section and then the unions of the sets found for each section for each pair of adjacent sections. It could probably even be done in JavaScript. The main trick would be checking for redirects, though that would be made slightly easier by that redirects are already highlighted by class="mw-redirect", and so only those links would need to be checked. I could probably whip up a prototype in AppleScript easily, but that wouldn't be useful for most people. Unfortunate that I don't yet understand JavaScript well enough or this would probably be a breeze to create given that that language has enough such functionality to create things like popups. {{Nihiltres|talk|log}} 23:12, 17 July 2008 (UTC)

Please tread carefully... Double links are not discouraged in long articles, where one instance of an item might need explanation and is far from the previous instance. Also, in articles to sections of which lead redirects many links have to be repeated, as one will not read the previous sections. I do agree with the proposed process (reports which will be checked by humans), and, although too much automation might be responsible for massive deforestationlinking if handled badly, I have faith in the community. I reserve further judgement until I see more details.

Yes, well this is why I was just requesting a report, rather than a script to actually remove wikilinks. I recognize that some human judgement is important when determining what links to remove, and the report can explain that. On the other hand, it is a royal pain to try and spot duplicate links in a long article—something that can be done easily with software. (At this point it's very tempting just to write my own perl script that I can run on a downloaded copy of a page source.) Thanks.—RJH (talk) 15:33, 18 July 2008 (UTC)

My own little idea on link handling is, I hope, even more uncontroversial... (I hope I'm not digressing too blatantly; I find this a relevant subject.) "

London" displays London and links to London, England, which redirects to London. A useless complication, in other words; I've seen many of them, usually the result of moves. I wonder if that could be automatically converted to "London". Waltham, The Duke of

23:50, 17 July 2008 (UTC)

Please read Wikipedia:Tools/Navigation popups/About fixing redirects (basically, don't unless it's a double redirect) -- John Broughton (♫♫) 22:59, 23 July 2008 (UTC)

That is, don't fix these redirects unless you are editing the page for some other reason (like to add content). Redirects are handled efficiently by the server, and there is no reason to proactively fix them. — Carl (

CBM · talk

) 23:05, 23 July 2008 (UTC)

Oh, I've heard the story... And I agree that there are some kinds of changes that should not be made unless the edit can be actually useful. (I don't add content, but I do copy-edit; sometimes I meticulously check an article for any mistake which I could correct in order to remove spaces around em dashes. It's actually a prime motivator for thorough copy-editing. :-D) It's just that I find this kind of links profoundly silly.

Ah, well, I suppose there's manual editing for that—I'm glad I have pop-ups for checking links. Thank you for your input, gentlemen. Waltham, The Duke of 00:12, 26 July 2008 (UTC)

The sensible way to edit a large, oft frequented discussion page is by clicking on 'new section' or the 'edit' link next to the section of interest. Otherwise, one must search for the relevant section within the edit window and deal with the horror of edit-conflicts. Currently on pages like the Science Reference desk et al., the 'edit this page' link is bold and the 'new section' link is regular, leading to me accidentally being drawn to the bold link when I want the regular one. Indeed, I imagine few people ever need the 'edit this page' button on the reference desks. I suggest that the 'new section' link is made bold and the 'edit this page' link is made regular, so that people are drawn to what is probably the correct link out of the two. ----Seans Potato Business

It sounds sensible, but... Can this be done for a single page? Waltham, The Duke of

How about doing it for all talk pages and pages with __NEWSECTIONLINK__ on them? –

9

That might be a good idea. Pity that we seem to have failed to receive enough attention here. I had forgotten about this myself for almost a week... Stupid Pump. Waltham, The Duke of

This is a great idea, with no real downside. I do not know how long this topic has been here as nobody has timestamps... weird. ~ JohnnyMrNinja (I won't use one either)

It is weird, given that I distinctly remember adding a time-stamp. I suppose someone has removed them to prevent this thread from being archived. Waltham, The Duke of 19:52, 23 July 2008 (UTC)

If you want to target pages with __NEWSECTIONLINK__ on them, the MediaWiki software would have to be changed. I suggest

filing a bug report and requesting this as a feature. —Remember the dot ^(talk

) 06:48, 19 July 2008 (UTC)

A MediaWiki message (if it is what I think it is) would probably be the best solution; features useful for all shouldn't depend on individual scripts. Waltham, The Duke of 19:52, 23 July 2008 (UTC)

Making new section bold could be done with CSS - making edit non-bold dependent on the presence of new section cannot. --Random832 (contribs) 20:19, 23 July 2008 (UTC)

Okay, someone want to start a poll regarding bolding the "new section" tab (and unbolding the "edit this page"), on all talk pages, so we can see if there is consensus for this? -- John Broughton (♫♫) 23:03, 23 July 2008 (UTC)

All talk pages? Can't a bot do it? --Seans Potato Business 17:45, 25 July 2008 (UTC)

While noticing some of the recent page move vandalism today I decided to see what it was they did for their first 10 edits to get auto-confirm status (needed for page moves). This account only has two edits before it started using the page move feature, and their first edit was made on July 4th. I'm guessing the account existed before the auto confirm settings were changed, and got the flag when it existed for more than four days.

I propose, assuming it's possible, that all accounts that have not made any edits that were made before the auto-confirm settings change have their auto-confirm flag removed. Assuming this is possible likely means a dev would be needed to do it, but I thought I would post this proposal here to double check with the community before making the bug report. -- Ned Scott 02:58, 22 July 2008 (UTC)

The page was not moved. The edit summary was faked to look like a move. Being autoconfirmed is determined by the current rules, so many existing accounts lost their status when the rules were changed. PrimeHunter (talk) 03:32, 22 July 2008 (UTC)

You seem to be mistaken, Prime, because at least some of them were actual page moves. Unless there were 8 deleted contribs that I can't see, then this account does have auto-confirm status based on the old settings. -- Ned Scott 03:45, 22 July 2008 (UTC)

I was referring to the alleged move after two edits. The first real move was made after 7 visible and 3 deleted edits. PrimeHunter (talk) 03:54, 22 July 2008 (UTC)

Number 3 to 7 of the visible edits were

dummy edits with an edit summary imitating a move. There were 3 deleted edits on 4 July. PrimeHunter (talk

) 04:00, 22 July 2008 (UTC)

Aaah. -- Ned Scott 04:45, 22 July 2008 (UTC)

Endorse. Would also help a little with the haggar/grawp crap, if that's not what yer referring to in the first place.

Tan ǀ 39

03:33, 22 July 2008 (UTC)

Now I'm even more confused, as the logs show the account was created on July 4th, 2008. There must be deleted contribs that are involved. -- Ned Scott 03:48, 22 July 2008 (UTC)

Raiselived had three deleted contributions on July 3, 2 non-deleted comments on July 3, and 5 "fake move" edits on July 21, for a total of 10 before the first real move. --B (talk) 04:07, 22 July 2008 (UTC)

I see what you are saying about dates, though. The difference is timezones. The account was created July 3 at 21:42 Eastern. The deleted edits were at 22:21 and 22:22, and 22:25. All times are Eastern (UTC-5). --B (talk) 04:09, 22 July 2008 (UTC)

Actually, I think the reason for Ned Scott's confusion over the July 4 (UTC) creation was not related to time zones. Rather, it was because he originally guessed the account was created before the autoconfirmation requirement was raised on a much earlier date. PrimeHunter (talk) 04:15, 22 July 2008 (UTC)

Well, I guess that pretty much explains everything. -- Ned Scott 04:43, 22 July 2008 (UTC)

Actually, it wasn't faked, he did move the pages but the autoconfirm settings is 4 days 10 edits and though the account was created on July 4th, he really didn't start vandalising 4 days later because he has previously done this and was "blocked" by the admins over and over again, now what he does is atleast wait over 10 days and in this case, 18 days weirdly and the 10 edit requirement INCLUDES deleted edits, and this way he can easily fool anyone into thinking that he is a

Should autoconfirm be changed to not count deleted edits? -- Imperator3733 (talk) 15:01, 22 July 2008 (UTC)

I suggest not. Someone this clever can simply do edits to the sandbox or his/her user page. There are benefits to simplicity - it's easier to say "all edits", and it's easier if someone isn't going back and forth between autoconfirmed and not autoconfirmed, if/when edits are deleted. And yes, while the present system can confuse non-admin vandal fighters (who can't see deleted edits), it's better (I think) to work on informing vandal fighters (as needed) than to add yet another complication to our auto-confirmed process. -- John Broughton (♫♫) 15:15, 24 July 2008 (UTC)

I think "this is not a forum" is really not that convincing or relevant for most occasions. For example, one can easily hijack the rules but just going "blah blah personal opinion blah blah POV POV blah, and here's a source, and here's how to improve the article". i.e. it's not hard to make it seem like non-forum but really being at least 80% blogging. So, promoting blogging and tagging of 'this is not a blog' is more relevant. --Leladax (talk) 06:53, 25 July 2008 (UTC)

Umm ... what are you actually proposing be done? (And would you mind defining "promoting", as you're using the word; I'm having trouble making sense of it?) -- John Broughton (♫♫) 22:33, 25 July 2008 (UTC)

Often when I'm researching an article, I'll come across relevant reliable sources that I don't immediately need but might be useful in further expansions of the article. Similarly, there are times when articles are trimmed to remove sections per

Would it be reasonable to have a subpage (similar to a talk page) that's just a list of resources for future writers of the article?

You could include these in a section near the bottom called "Further reading". − Twas Now ( talk • contribs • e-mail ) 22:51, 20 July 2008 (UTC)

Often I'm running into cases where there are quite a few of them (PubMed journal searches, for example) and a long "further reading" section might be kind of cumbersome. I suppose it can always go on the talk page.

talk

) 23:55, 20 July 2008 (UTC)

Talk page, or you could comment it out in an appropriate section, like so:

<!-- Yadda yadda, here are some other useful resources: --> − Twas Now ( talk • contribs • e-mail ) 00:45, 21 July 2008 (UTC)

Also see the section above where there was some talk of holding these in a sub-talkpage (like Talk:Foo/LinkSuggest links), and having a "LinkSuggest" user-script to conveniently mediate access to them from the article proper. I'd have a crack at writing it if I only had the time. :-) For instance, the script might add a "suggested links" option to the toolbox which pops up a list of items and gives controls for adding or removing items yourself. --_{tiny plastic} Grey Knight ⊖ 07:57, 21 July 2008 (UTC)

There is absolutely nothing wrong with posting these on the talk page; most talkpage comments are far less substantive. I have recently begun creating sections titled "Resources relevant to the page" on talk pages. II | (t - c) 21:08, 21 July 2008 (UTC)

SDY, I think this is a great idea. Yeah, sure, theoretically this can be put on the talk page. Sure, there's absolutely nothing wrong with putting it on the talk page. But that doesn't happen. The presence of resource forks as a common or universal practice would encourage the posting and collection of resource lists, which would be of IMMENSE help in sourcing articles! There's no solid reason to oppose this idea that I can think of. Mr. IP (talk) 08:52, 26 July 2008 (UTC)

Wikipedia's page for creating an account or logging in has a link to the article "Password strength". I have the following questions:

• What is the set of all characters acceptable for use in a Wikipedia password? (Does it include:
  mathematical symbols? webdings? wingdings
  ?)
• What is the maximum allowable length for a Wikipedia password? (Does one
  Chinese character count as much as a Latin letter
  ?)
• Does Wikipedia truncate the password after a specific number of characters, and disregard the rest?
• Why are the answers to these questions not visible on the page for creating an account or logging in?

-- Wavelength (talk) 02:16, 22 July 2008 (UTC)

This doesn't really belong at the proposals village pump - more probably the

a/c

) 02:57, 22 July 2008 (UTC)

Probably it would go on one of MediaWiki:Signupend or MediaWiki:Fancycaptcha-createaccount. I checked the source a bit, I found that User:isValidPassword() checks only against a minimum size. The password field in the database is just an MD5 hash of the "actual" password, so the only real maximum is PHP's maximum string size, which I believe defaults to around 8 million characters. That would be a very secure password! --_{tiny plastic} Grey Knight ⊖ 11:21, 22 July 2008 (UTC)

The minimum size is in $wgMinimalPasswordLength, which on Wikipedia I think is set to 8. The check for the minimum uses strlen(), but I imagine Wikipedia is using a UTF8 string with mbstring.func_overload, which would mean that even "fancy" passwords with Chinese script only count each character as 1. --_{tiny plastic} Grey Knight ⊖ 11:39, 22 July 2008 (UTC)

For what it is worth, User:Slark has posted the following message (07:39, 20 March 2008) [2] at Talk:Password strength#Wikipedia password limits.

I just changed my Wikipedia password using KeePassX 0.2.2 (new version 0.3.1! with AutoType!) with maxed out password strength, which has the following options:

1000 characters length

Upper letters

Lower letters

Numbers

Special characters

White spaces

Minus

Underline

higher ANSI characters

KeePassX reports a password generated with these options as either 8000 bit or 12816 bit quality, either way Wikipedia happily accepted it. [end of message by Slark]

-- Wavelength (talk) 16:08, 22 July 2008 (UTC)

While MediaWiki indeed accepts such passwords, it's worth noting that they're

entropy per character. —Ilmari Karonen (talk

) 07:52, 23 July 2008 (UTC)

After reading this post decided to create a script to add a password strength meter on the new accounts form. It doesn't use a checklist like most meters instead opting for calculating the bit strength. I'm centralizing discussion at Common.js. — Dispenser 00:32, 27 July 2008 (UTC)

We've been suffering a lot of vandalism to templates lately (just check the threads on

There are two ways in which we could implement this:

1. MediaWiki has a configuration variable $wgNamespaceProtection which can be used to set a minimum protection level for all pages in a given namespace. By default, it's only used to prevent non-admins from editing the MediaWiki: namespace, but the Wikimedia sysadmins could use it to semiprotect the Template: namespace.
2. Wikipedia also has the Title Blacklist extension, which could be used to achieve a similar effect by adding the line "Template:.* <noedit|autoconfirmed>" to MediaWiki:Titleblacklist. This would be more of a hack, but it could be implemented by local admins without sysadmin assistance, and could also allow more fine-grained control. (In particular, I've proposed elsewhere to use this mechanism to protect subpages of Template:Convert.)

Obviously, this would prevent new and unregistered users from making legitimate changes to templates; however, most users with enough wiki experience to usefully edit templates should probably pass the autoconfirmation requirements anyway. Conversely, I'm aware that a determined vandal can easily register accounts in advance and rack up the required ten edits before vandalizing; but the semiprotection would still serve as a speed bump, and we can still keep fully protecting the highest-risk templates as we already do. Let the comments roll in. Also, feel free to notify any other relevant forums about this proposal. —Ilmari Karonen (talk) 03:08, 21 July 2008 (UTC)

TI have thought about this myself in the past few days. The main downside is the foundation principle of open editing, which I strongly advocate. I might be willing to compromise on that in this case, but I don't think the current autoconfirmed standards are rigorous enough that semiprotection would have much effect. I don't think full protection for all templates is a viable option, though. — Carl (

CBM · talk

) 03:20, 21 July 2008 (UTC)

I think the idea has merit and I support it but just something to think about though is that this would make vandalism harder to spot, right now the IP's are easy to spot editing but if the requirement were changed to autoconfirmed status then there would be no way to filter there contributions out from more established users. - Icewedge (talk) 03:46, 21 July 2008 (UTC)

There's been far too much limiting of the ability to edit going on lately; it all started with making it harder to get autoconfirmed, and its gotten way out of hand; we have principles, and they're more important than templates that can be watchlisted and reverted. Celarnor ^{Talk to me} 04:08, 21 July 2008 (UTC)

I mentioned this the other day as a facetious comment - while I do see why this would be considered, I don't think it's something we should implement. As mentioned, it limits constructive editing too much. Someone trying to make a useful edit to a template can't do so unless they're logged in. Locking out the entire Template: namespace also prevents additions or corrections to documentation of templates as well. We do have several tools already available to us to help with this - the preview screen now lists all templates used on a page; recent changes can be restricted to Template: edits only, as well as showing only anonymous users; high-risk templates can be protected as many already are. Several administrators, myself included, transclude various templates onto a user subpage with cascading protection (See

a/c

) 04:26, 21 July 2008 (UTC)

--- RockMFR 04:52, 21 July 2008 (UTC)

The original poster's proposal is a bad idea. Any vandal sophisticated enough to employ template vandalism is generally determined enough to create an account. I don't know how many useful anonymous edits are made to templates - not many, I expect, since anonymous edits are generally by unsophisticated users - but this still happens sometimes, due for example to "edit" links on transcluded infoboxes. Even this small number should not be ruled out for no purpose. Dcoetzee 05:51, 21 July 2008 (UTC)

User:Jaysweet had come up with an idea to help fight it on Wikipedia:Administrators' noticeboard/IncidentArchive450#Fog; basically it was a "View Recent Changes to pages transcluded on this page" tool (can AWB do that, or does someone want to have a crack at the toolserver?) with which users can easily find which template is the culprit of such an issue and revert it. Does that sound like it would be useful? --_{tiny plastic} Grey Knight ⊖ 10:12, 21 July 2008 (UTC)

It does actually. I also like the idea of templates being automatically protected when they are transcluded on a certain high number of pages. --

:.

12:10, 21 July 2008 (UTC)

Honestly, I'd bet all we need to do is tag the list of transcluded templates on the edit page that were most recently edited (say within the past 3 hours), similar to how protected templates are already tagged there as "(protected)". Usually, the most recently edited template is going to be the vandalized one. — Gavia immer (talk) 18:47, 21 July 2008 (UTC)

Is there anywhere we can list "suggestions for toolserver tools", or is this really a {{sofixit}} situation? :-) --_{tiny plastic} Grey Knight ⊖ 15:17, 21 July 2008 (UTC)

Hey, that's a good idea. I wrote a user script to do just that. Anomie⚔ 01:34, 22 July 2008 (UTC)

I support this, but only if the default protection level is semi-protected, not fully protected, as there I'm sure there are a lot of non-Admins who edit templates in a constructive way (myself included). It Is Me Here (talk) 12:38, 21 July 2008 (UTC)

I strongly second

WP:CEX uses several templates created / modified by its members. -- Philcha (talk

) 13:14, 21 July 2008 (UTC)

Regarding Use the filter extension thing: Good: Temporarily stop the vandalism. Bad: Arms race., I disagree with the "Bad" analysis. Figuring out how to evade the settings in a filter extension would (a) be a lot of work and (b) would in no way give the vandal an advantage with regard to human beings spotting and fixing this sort of vandalism. A better analogy is to something like surveillance cameras or x-ray machines at airports - whether or not you think they're worth doing (primarily because of costs and false positives), they in no way lead to an "arms race". -- John Broughton (♫♫) 13:10, 21 July 2008 (UTC)

The extension isn't meant to deal with vandals like this; it is meant to employ filters to deal only with very specific, very easily identifiable forms of vandalism (i.e, the HAGGAR pagemoves); it is by no stretch intended to deal with the vandalism that is reverted by ClueBot and the like. Celarnor ^{Talk to me} 14:12, 21 July 2008 (UTC)

There are also lots of anonymous editors who edit constructively, too; are you better than they are because you have an account? Should we really block them from doing so because there are a few losers among the group? If you think that, then you really should be endorsing full-protection, since autoconfirmed users can be vandals too. You can even take it a bit further and say we shouldn't have templates at all, since you could work an account up past RFA to vandalize. Is it really a good idea to inhibit editing by default because of a few losers? Celarnor ^{Talk to me} 14:12, 21 July 2008 (UTC)

This is a wiki. Semi-protecting the entire Template: namespace is a bad idea that will do far more harm than good. Autoconfirmed limits are trivial to bypass and a great deal of legitimate page content is stored in the Template: namespace. --MZMcBride (talk) 14:27, 21 July 2008 (UTC)

Doing nothing at all would be worse than the current situation, which is summarised by the instructions here [3]. At present we revert, protect, purge and warn on a template-by-template basis, and we're slowly moving towards protection of most common transcluded templates in an inefficient, time-consuming and piecemeal way. There's a case for making it less convenient overall for the drive-by template vandal who wants to make a big mess with little effort.

I think semiprotecting the whole space is too draconian, but I like the idea of a "View recent changes to pages transcluded on this page" - dead useful if it could be made to work for Popups too. As for the "semiprotect when transcluded to >X pages" idea, I don't buy the argument that it's unworkable because you'll not get consensus on what X is. We appear to have consensus already on full protection for really important templates, and the judgement about whether to protect is made on the fly by individual admins. I'm sure a figure for X could be reached by discussion if the proposal was made. Finally, there's scope for a far better, step-by-step explanation at [4] as to how non-admins can detect and revert template vandalism: that's where users will go first for guidance, and it's a bit sparse. I found Hersfold's suggestions above particularly helpful for my own future reference. Maybe experienced template vandal-fighters could look at fleshing out the section a bit? Karenjc 18:11, 21 July 2008 (UTC)

We are going to have to do something about this. This vandal has worked out how to hit hundreds of high-profile pages at once and consequently the number of people who have been affected (and the number who have complained) is huge. I wrote a program to find out how many templates have more than 500 transclusions, and it returned over 2000. Semiprotecting templates with more than a certain number of transclusions looks like the best way to go. Hut 8.5 18:51, 21 July 2008 (UTC)

Mm-hm. Absolutely. I think we can all agree that a template that is transcluded on 500+ pages is certainly "high risk" and should at least be semi-protected. Of course templates that are transcluded less than that and are high risk are special cases and will likely receive enough attention to be protected without automatic intervention (like the AN templates for example). Some templates, however, get "forgotten" and overlooked and people can therefore miss some large scale vandalism. I don't know whether we should pursue some of the other ideas or not, but I do strongly think that this particular idea should be applied to the template namespace. --

:.

19:05, 21 July 2008 (UTC)

No. At least, not all templates. Protecting high-risk templates is within reason -- and established practice -- but not all of them preemptively. Any serial vandal knows how to register accounts to bypass semiprotection, meaning all this solution will do is exclude honest IP editors from contributing. I've been collaborating with an IP editor recently, who has made constructive edits to dozens of articles and related templates. One of the articles we've been working on was semiprotected in response to a conspiracy-theory vandal, and as a result all IPs are now locked out. I'd sooner just keep reverting the vandal than lose contributors.--Father Goose (talk) 19:13, 21 July 2008 (UTC)

We aren't talking about semi-protecting articles, though: this is about semi-protecting templates, which are quite a bit more arcane to (most) newbies. In any case, it's considerably quicker and easier to revert vandalism on an article than it is on a template. - Jredmond (talk) 20:40, 21 July 2008 (UTC)

I would like to register extremely strong opposition. As Dcoetzee says above, any vandal sophisticated enough to hit templates is sophisticated enough to ripen some accounts. All this does is shut off another area of the encyclopedia to IP editors. I have created templates in the past, and I shudder to think that soon I could never be able to do it again under my preferred mode of editing. IP editors should not be shut out of template space completely. Ever. I'm sorry, I understand the intentions here, but an extreme, total, and permanent crackdown on IP editors is going too far. This is just another step toward the total elimination of anonymous users.  Mr. IP, Defender of Open Editing  16:40, 27 July 2008 (UTC)

Good. The percentage of useful edits, compared to vandalism, of IP users is so low these days that anonymous users should be totally eliminated. Great idea for the startup of the project, but with intensely high worldwide visibility now - first hit or two on almost any google search - the concept is outdated and the protection of "the rights of anonymous users" is anachronistic at best. Anyone can register an account, and the positive effect that would have on the reduction of vandalism far, far outweighs any loss of constructive edits from IPs.

Tan ǀ 39

16:50, 27 July 2008 (UTC)

I'll go you one further, and suggest we eliminate all editors. They are such a nuisance! Administrators should not have to clean up after them.  Mr. IP, Defender of Open Editing  09:00, 28 July 2008 (UTC)

• Agree with Hut 8.5, semiprotect all templates with over 500 links. That'll at least slow the vandals down. NawlinWiki (talk) 19:15, 21 July 2008 (UTC)

• It's an idea - it doesn't prevent the vandalism, but it's a speedbump, and the template space is sufficiently esoteric that most people contributing are well-established editors, so we get less collateral damage this way than from sprotecting articles. Perhaps more usefully, someone could generate a list of all templates transcluded more than a hundred or so times, and let us start full-protecting them...
  talk
  | 20:25, 21 July 2008 (UTC)

I can make such a list, but posting it on-wiki is a bad idea as it gives the vandal a list of targets. Hut 8.5 20:57, 21 July 2008 (UTC)

• I like the general idea here. When it comes to editing templates, anybody can comment on the talk page, and any registered user can create a /Temp subpage with a mockup of their changes. My only major concern here is how effective semi-protection will be against throwaway autoconfirmed accounts. - Jredmond (talk) 20:40, 21 July 2008 (UTC)

• I personally think all good wikipedians should have account. Idea of semi-protecting templates which are present on more than 500+ pages seems fair and just. It will reduce some load of patrolling. Also good wikipedians who want to do constructive work would pass the basic test easily. This idea will prompt them to come up with an account. Vandals anyway are more interested in dirtying articles which has more visibility than templates which have auto set for hidden than show. --gppande «talk» 20:50, 21 July 2008 (UTC)

• I've seen little evidence to suggest that semi-protection will be a deterrent to anyone but legitimate editors. --MZMcBride (talk) 20:55, 21 July 2008 (UTC)

• Once we implement automatic semi-protection after the transclusion #500, how long will it be before people start adding more transclusions just to up the count and force protection? IMHO, a preview that allowed you to use the list to toggle which templates are shown would be a better approach to template vandalism, more in line with the "easy to break, easy to fix". -Steve Sanbeg (talk) 21:11, 21 July 2008 (UTC)

• Highly endorse. As one who believes that Wikipedia has moved past the "startup" where anyone can anonymously edit and into a realm where users should have accounts, and dealing with all the Grawp bullshit lately, this is a great idea.
  Tan ǀ 39
  01:35, 22 July 2008 (UTC)
• Bad idea, agree with MZMcBride, this will only hurt good editors and looks like being used as another step against anonymous editors. Davewild (talk) 07:02, 22 July 2008 (UTC)
• I downright oppose any indiscriminate protection of pages in any namespace. Protection should be applied on a case-by-case basis, with the potential exception of pages which fulfil certain criteria of high risk of, and vulnerability to, vandalism. Thanks to the raise of the criteria for auto-confirmation, semi-protection is more meaningful than it used to be, and caution and good judgement should be involved in the use of such measures—without exceptions. Waltham, The Duke of 19:43, 23 July 2008 (UTC)
• I have a hard time believing that (a) newly registered users have any need to be mucking around with templates until they have a lot more experience than 10 or 20 edits (if they are "deterred" by semi-protection, that's arguably a benefit, not a problem), and (b) that there are many experienced editors who have been making useful changes to templates and yet haven't figured out the value of having a registered account (personalization, better anonymity, ability to track one's own edits, better reputation, etc.) Why don't we acknowledge that any template that impacts more than a couple of dozen pages is *high risk*, which means that most templates should be at least semi-protected, which means that we might as well semi-protect the namespace and be done with it.

The purpose of allowing "anyone to edit" is to avoid stifling viewpoints and encouraging contributions to articles. On the other hand, Wikipedia isn't (and never will be) "the encyclopedia whose software anyone can modify". We only let developers muck with the software - and no one considers that censorship, or a problem. Templates are code. In the risk-reward calculation, the risks of vandalism seem far greater than the benefits of contributions by novice and IP editors to templates. Or any "damage" to the concept of Wikipedia. -- John Broughton (♫♫) 23:20, 23 July 2008 (UTC)

That's an excellent point. Besides, most high risk templates are deemed unsuitible for even registered users to tamper with, hence why they are fully protected. I can't see how semi-protection would be unreasonable. The amount of actually beneficial template edits by IPs is so minimal, that the benefit's of deterring vandalism are indeed much greater. --

:.

14:20, 24 July 2008 (UTC)

John: With all due respect, you're utterly wrong and you are making statements without any support. Look at the Recent changes feed with logged-in users hidden showing only the Template: namespace (here). Anonymous editors make hundreds of edits to templates every day. And to say that only code is found in templates is simply rubbish. Take, for example, Template:Los Angeles Dodgers roster navbox. That template (and many, many, many others) contain legitimate page content. If we are to allow people to edit page text freely and anonymously, there is no reason to block editors from editing page content inside templates freely and anonymously. While I would certainly agree that the template that Template:Los Angeles Dodgers roster navbox uses (Template:Navbox) should be fully protected, semi- or fully protecting that template is absurd and anti-wiki. One of our guiding principles is the ability to allow anyone to edit, and we restrict such an ability for various reasons (large-scale damage, wasting server resources, content disputes, etc.). I've seen no compelling reason or evidence to flatly restrict the Template: namespace from anonymous users in this discussion. --MZMcBride (talk) 00:30, 25 July 2008 (UTC)

I agree; besides, many templates are little more than repeating text or tables. They don't have to be complex. They are easy to edit by anyone without (m)any glitches, and in case of a mistake they are easy to correct. I remind the honourable colleagues that, even though vandalism in a template can be seen simultaneously on many pages, that also increases the changes of someone spotting and correcting it, restoring the balance. And there is something else...

Templates are not restricted to the Template namespace. There are templates in the user and project namespaces, and although these are not transcluded in the mainspace, vandalism there can be equally or even more disrupting, depending on the case. These will be excepted by any blanket semi-protection on templates, creating double standards and precipitating unforeseeable changes in template-creation and -editing trends. What's wrong with the merits of case-by-case protection? Why flood the logs for what amounts, in many cases, to protecting templates transcluded in twenty pages? This cannon will kill far more flies than soldiers. Waltham, The Duke of 00:29, 26 July 2008 (UTC)

Without addressing the merits of your comment in any other respect, I'd just like to point out, as a minor technical correction, that neither of the suggested methods for (semi)protecting the template namespace would create any log entries. —Ilmari Karonen (talk) 01:27, 26 July 2008 (UTC)

Duly noted. For all it's worth, I meant it more as a poetic image than literally. :-) Waltham, The Duke of 23:06, 27 July 2008 (UTC)

Anomie's userscript solution

I just tried User:Anomie's User:Anomie/previewtemplatelastmod.js script, it seems to work pretty well; it modifies the "list of templates used here" list to show the most recent change instead of just the name of each one. --_{tiny plastic} Grey Knight ⊖ 06:58, 22 July 2008 (UTC)

Coincidentally, rev:37927 is now live, so that Special:RecentChangesLinked (listed in the toolbox on the left as "Related changes") now includes changes to transcluded templates. —Ilmari Karonen (talk) 01:30, 25 July 2008 (UTC)

About a year and a half ago, there was an effort (called Wikipedia:Userbox migration) to move templates which display user characteristics—commonly called userboxes and frequently appear on user pages—out of template: space into user: space. As a result, we now have perhaps thousands of userboxes (or userboxen) scattered all over the user: space, under various users' pages.

I have no idea if this has been proposed before, but would it make sense to move them into one easy-to-find place? I propose using user:

1. {{
   User:The Raven's Apprentice/Userboxes/User Firefox
   }}
2. {{
   User wikipedia:No personal attacks
   }}
3. {{User:Menasim/Userboxes/User Google}}
4. {{User:UBX/Scuba Diver}}
5. {{User time zone|UTC-8|(UTC-7 summer, UTC-8 winter)}}
6. {{
   User:Lucasbfr/Admin open to trout slapping
   }}

I notice that even in the highly regarded {{Babel}} usage, there are some user space boxes:

• {{Babel|:Feureau/UserBox/AmericanEnglish|:ZeroOne/Userboxes/php-3}}

In my six more-or-less-random examples, four are under various user's pages and two are in template space, though both the latter "pretend" like they are in user space. All very confusing. It looks like a significant fraction (20%?) of userboxes are under UBX (talk · contribs): a good start, and Mets501 (talk · contribs) put a nice directory there. But I'm not surprised it didn't catch on. UBX is ugly, and doesn't flow through the mind very well. (It does have good keyboard feel though.)

Should all the user boxes be migrated to be under

I think this is a great idea. − Twas Now ( talk • contribs • e-mail ) 05:22, 24 July 2008 (UTC)

I like the idea. Celarnor ^{Talk to me} 05:52, 24 July 2008 (UTC)

Anything that will remove the dozens of Template:User X style boxes is a good thing. MBisanz ^talk 06:23, 24 July 2008 (UTC)

Been proposed in the past but the anti userbox mob objected strongly.Geni 19:53, 24 July 2008 (UTC)

Why? Celarnor ^{Talk to me} 19:55, 24 July 2008 (UTC)

Because they were the anti userbox mob? I wouldn't worry. most have quit wikipedia or lost interest in the subject.Geni 22:57, 24 July 2008 (UTC)

Wikipedia:Userboxes#Which namespace? already recommends the account User:UBX for this. I had been under the impression that, these days, only "official" userbox templates that clearly facilitate collaboration, such as the Babel templates or {{User time zone}}, were permitted in Template: namespace, whereas random "personal" templates like "this user likes being whacked with sealife" should stay in User: space to make it clear that they're not part of Wikipedia (the project) proper. Apparently, however, that isn't quite the case: the guideline only says, in a vague way, that "userboxes in the Template and Project namespaces are expected to adhere more tightly with policies and guidelines". —Ilmari Karonen (talk) 01:26, 25 July 2008 (UTC)

The status of userboxes is under an uneasy truce at the moment. The less shifting around you do with them the better, I think.

talk

) 10:06, 27 July 2008 (UTC)

Just as an aside (and probably terribly naive) question: where did this "boxen" plural come from?--Kotniski (talk) 15:19, 27 July 2008 (UTC)

See wikt:boxen. Algebraist 16:31, 27 July 2008 (UTC)

That half answers it - but whence this habit among some otherwise apparently quite normal Wikipedians for using the specific term "userboxen" (which have nothing to do with the computers that boxen refers to according to Wiktionary)?--Kotniski (talk) 17:12, 27 July 2008 (UTC)

I worked for years on

Vax computers. How does one pluralize "Vax"? Vaxen! (If you like them; Vaxes, if indifferent.) —EncMstr (talk

) 21:31, 27 July 2008 (UTC)

So do we conclude that "userboxen" is used chiefly by computer geeks who think userboxes are a pretty neat idea?--Kotniski (talk) 22:57, 27 July 2008 (UTC)

Comment: Since

{{

talk

) 10:03, 27 July 2008 (UTC)

I didn't know that! It should be placed in Friendly though, along with Welcomeusername.

csdnew

10:07, 27 July 2008 (UTC)

That's a really good welcome template for that situation, Stifle. I shall have to remember it. ~ mazca ^{t | c} 10:09, 27 July 2008 (UTC)

It was pointed out to me that the recent discussion about subcategory placement within a category (alphabetically/at the beginning) is actually an open and really old bug. I have placed my vote there, and any still interested could do the same. ~ JohnnyMrNinja 08:30, 28 July 2008 (UTC)

When the rollback limit was initially created, it was when the flag was going to be given to all autoconfirmed users. As the permission has to be granted by admins manually now, and some degree of clue should be shown before a user receives it, I propose we remove the limit set on rollbackers - we've already shown that if there's misuse, we're effective at removing the permission. Ryan Postlethwaite 22:37, 14 July 2008 (UTC)

I've got no problem with this. Many users are having trouble keeping up with vandalism because of this limit. As Ryan said, we're doing fine with removing it when it is abused, so I don't think this should be a problem. - Rjd0060 (talk) 22:55, 14 July 2008 (UTC)

I may be wrong on this, but I think the limit was raised to 100 a few weeks ago. Even so, I would still support removing the limit entirely: it's not needed. People who abuse rollback get it removed, and those who use it correctly keep the right, but are hindered by the limit. Let's remove the limit. Acalamari 02:18, 15 July 2008 (UTC)

Never even knew there was a limit (is it documented somewhere?) But it sounds from the above that it would be beneficial to abolish it or at least raise it significantly.--Kotniski (talk) 09:07, 16 July 2008 (UTC)

Get rid of it - it's not helping anyone. Hut 8.5 18:55, 21 July 2008 (UTC)

I agree, admin judgment is sufficient. Can we move forward with this? Skomorokh 11:50, 22 July 2008 (UTC)

Opinion seems to be unanimous here so far. Any objections to taking it to the devs?--Kotniski (talk) 18:56, 26 July 2008 (UTC)

• I don't use the tool a ton, but if the limit serves no purpose, lose it. We have
  enough superfluous processes as it is. S. Dean Jameson
  20:36, 26 July 2008 (UTC)

The limit can't really be removed without actual development work on the software. But it can be raised to an arbitrarily high number. Currently, it's set to 10 / minute (I believe). Non-sysops can check their rate limits via the API (here). If people are regularly hitting the limit, there's no real reason not to raise it. --MZMcBride (talk) 02:12, 27 July 2008 (UTC)

So, how about asking it to be set to 60 a minute? A limit of one per second shouldn't get in anyone's way.--Kotniski (talk) 08:27, 27 July 2008 (UTC)

Assuming (based on the above discussion) that silence indicates consent, I've made a request at Bugzilla (Bug 14967).--Kotniski (talk) 08:55, 29 July 2008 (UTC)

I would like to request the addition of an "unwatch" button in the watchlist. I know this can be accessed by either opening the article or viewing the "manage watchlist" page, but in either case this requires an additional step.

I don't fully understand what you want and how this becomes more convenient. Also why use the prefix "un"... Couldn't we use "dewatch". --CyclePat (talk) 05:21, 27 July 2008 (UTC)

Unwatch is already in the interface. The point of this appears to be to be able to unwatch pages directly from the watchlist, without viewing the page you want to unwatch; this does make some sense, since the ordering on the edit watchlist view is very different from the ordering in the main view, so that it may be difficult to (for example) unwatch several recently modified pages quickly. Dcoetzee 08:56, 27 July 2008 (UTC)

Definitely support this idea. It may not seem a big deal to those of you with fast links, but on a slow link especially every extra step costs time.--Kotniski (talk) 09:14, 27 July 2008 (UTC)

Agree, very useful.

talk

) 10:03, 27 July 2008 (UTC)

Installing the user script user:js/watchlist works. However this really oughtta be a permanent feature in the software. It's listed as request 424 over at Bugzilla. Anyone willing to submit it as a patch?--Father Goose (talk) 10:17, 27 July 2008 (UTC)

enabling the

WP:navigation popups gadget already provides this capability when you hover over the page title on the watchlist {or anywhere else) DGG (talk

) 11:49, 27 July 2008 (UTC)

As you say, this appears everywhere, not just in the watchlist. As a result, it adds more bloat to pages and causes them to take more time to download. Also, not everyone likes the intrusive nature of popups.

talk

) 18:00, 27 July 2008 (UTC)

This is feature creep. --Pwnage8 (talk) 15:36, 28 July 2008 (UTC)

Does "this is feature creep" mean anything more than "this is a request for a new feature"? If so, could you provide at least some kind of argument?--Kotniski (talk) 16:42, 28 July 2008 (UTC)

Well, yes, it does mean more than that. Did you click the link? While I'm not sure I agree that it is feature creep, having to paraphrase because you are unable to understand the term is a waste of time...

Tan ǀ 39

16:45, 28 July 2008 (UTC)

I didn't mean I didn't understand the term, I just don't see how "this is feature creep" can stand as an argument on its own, without any attempt at justification. It's like writing "this is a bad idea" (with no "because..." after it).--Kotniski (talk) 16:52, 28 July 2008 (UTC)

Too many buttons. Lets just leave it as a javascript add-on

Chillum

16:45, 28 July 2008 (UTC)

It could be implemented as an option, removable via user preferences, for those who think it's too much clutter.--Kotniski (talk) 16:54, 28 July 2008 (UTC)

Sorry if I was snappy above. Too much of

Tan ǀ 39

16:55, 28 July 2008 (UTC)

This is a very good idea and I don't see anything that would prevent this from happening. -- Imperator3733 (talk) 16:48, 29 July 2008 (UTC)

Couple of questions.

What do you do if your article gets canceled, and/or the title gets redirected ?

Also, on the question of references, what is the benefit of having references to written material that is not accessible to most people (i.e. is proprietary). Than how do people check on the veracity of the source ? I am going to advocate that people prioritize sources that can be accessed on the Web, or at least are public domain, (and not pay for content, therefore not accessible on the Web in most cases.)

Menlaus2 —Preceding unsigned comment added by Menelaus2 (talk • contribs) 20:56, 27 July 2008 (UTC)

The answer to the first question is it depends on the circumstances: a deletion via AfD is very different than a redirect; a redirect by an experienced editor who provides a good edit summary is very different than a redirect put in place by an inexperienced editor without an edit summary; and whether the matter is worth fighting about depends a lot of how much discussion there has been. Take a look at

WP:EIW#Postmortem

.

The benefit of references to sources that aren't online is that (1) much of the information in the world is not online, or accessible publicly online, and (2) if Wikipedia didn't use this information, it would be crippling to many articles. Wikipedia isn't just about recent events and cultural matters. Online sources available to all are to be preferred if of at least equal quality to restricted or off-line sources, of course, but often that's just not an option. As to checking on off-line or restricted sources cited by an editor, it depends if the editor is (a) posting controversial or questionable information; and (b) lacks credibility (from prior editing) at Wikipedia. If both conditions are true, it's highly likely that another editor will track down the sources (something not available to any other editor isn't, by definition, a

reliable source) to verify them. -- John Broughton (♫♫)

19:57, 27 July 2008 (UTC)

Hi, Menlaus2,

• If an article you created got deleted by an administrator, a warning notice was probably placed on the article before this happened. The notice would have stated why it was thought the article should be deleted, and contained a link to a subpage of "
  watching
  the article, and so missed the notice?
• If an article gets moved to another article name or turned into a redirect and you don't agree with what has been done, you should post a message on the talk page of the new article and explain your objections so that the matter can be discussed. You may also want to contact the editor who made the change through his or her talk page and mention that you've started a discussion on the matter on the article's talk page.
• For articles to be properly referenced, it is often necessary to cite not just material that is available freely online but also subscription-only material and print resources. In fact, most good articles and featured articles cite a large number of such references. This is to ensure that the best resources have been consulted; not everything that is important is available on the Internet! If you are particularly interested in the subject-matter of a certain article and wish to verify some references, you may have to visit a library to look them up. Alternatively, you may try contacting regular editors of the article and ask if they can e-mail you copies of the references.

By the way, do sign and date your messages by typing four tildes (~~~~) after them. — Cheers, JackLee ^–talk– 20:04, 27 July 2008 (UTC)

No trace of a discussion in the subpage "Wikipedia:Articles for deletion".

Also, my very specific concern is proprietary information. I do like the idea that references should amplify the ability of a reader to examine the subject more thoroughly. But, from that perspective, then information resources should be those that do not require a trip to a major academic center to get an article. Menelaus2 22:11, 27 July 2008 (UTC)

Let me try again: When you say information resources should be those that do not require a trip to a major academic center to get an article, you're wrong if by "should be" you mean "should only be". You're correct if by "should" you mean "should, preferably, be". Wikipedia does not now exclude important information simply because it is not easily available. If you really mean the first of these two, then you should be posting at the talk page of the policy

WP:V

, because what you're proposing is a major, major change in the way Wikipedia works.

And as for the deletion (or redirect) of an article, it would really, really help if you would mention a specific article that you're concerned about. -- John Broughton (♫♫) 01:17, 28 July 2008 (UTC)

I agree - paid-access-only academic journals are a curse, but we can't ignore the information contained in them. At least the abstracts are all freely available, and an increasing number of authors are putting their own papers on their websites (making it at least worth web-searching for any individual paper to see if an online copy exists) Pseudomonas_(talk) 08:27, 28 July 2008 (UTC)

There's even progress towards real Open access. All articles based on work sponsored by the NIH in the US, and by RCUK in Great Britain, and by several agencies elsewhere, is now required to be available to the public in some form 6 months after publication--either the final published version, or the authors final accepted manuscript. This basically applies to materials published from mid 08 onwards, but will help our authors in a great many subjects, especially in biomedicine. (The concept is the 6 months will not hurt publishers excessively, as researchers in a university will need the material immediately. For general information on this, the best source is the new Open Access Directory wiki. (COI--I'm one of the editorial group there) DGG (talk) 22:18, 28 July 2008 (UTC)

I think that Menlaus is talking about edits he/she made to

That would be where he/she changed a redirect into an article, if one wants to characterize

consensus that there in fact should be separate articles." -- John Broughton (♫♫)

17:11, 29 July 2008 (UTC)

The link can be accessed by clicking on either one of the links in the default signature, then looking for "user contributions" in the sidebar. Happy‑melon 21:38, 27 July 2008 (UTC)

While I can't say with 100% certainty about how things have been done in the past, the history tab for MediaWiki:Signature seems to show no evidence that a link for user contributions was ever part of the default signature of registered editors. -- John Broughton (♫♫) 01:21, 28 July 2008 (UTC)

The link is in the toolbox on users' talk pages. Prodego ^talk 01:22, 28 July 2008 (UTC)

My memory must be playing tricks on me, because I'm pretty sure it was there. And, the user toolbox link you provided is a good bit easier.

talk

) 23:40, 28 July 2008 (UTC)

Actually, MediaWiki:Signature is fairly new (< 1 year). It was added so that we could add the talk link to the default signature. Before that MediaWiki page was introduced, I believe the signature was just a link to the userpage. Signatures for anons always link to contibs though. Mr.Z-man 23:57, 28 July 2008 (UTC)

Pretty much. A lot of people have added links to contribs but some of us think links to talk pages are excessive.Geni 15:46, 29 July 2008 (UTC)

I would like to request that start and end cutoff date fields be added to articles' History pages. It's currently a very tedious task to locate old diffs for frequently edited pages (such as Talk pages). I know you can enter the dates in your browser's address bar, but this requires the additional step of clicking the "older 100" link first. Also, in my browser (Avant+IE7) the address bar resets itself when the browser looses focus, so this can cause problems when copying/pasting from a text editor.

I've been working on a proposal at

An example of the proposal in action, using sub-articles, can be found at

As shown here, Wikipedia software doesn't permit subpages in article space - which seems to be what you propose. So you're going to have to demonstrate that consensus exists to change that. -- John Broughton (♫♫) 00:47, 17 July 2008 (UTC)

I'm proposing doing it via templates, actually. But the reason for disabling subpages in article space, so far as I can tell, isn't a consensus-based one, but a technical one - nobody was using article space subpages, and they caused problems with articles like

talk

) 01:08, 17 July 2008 (UTC)

The cricket people tried something simular a few years back. It wasn't popular. We've always found a series of stand alone articles to work better than messing around with templates.Geni 12:13, 17 July 2008 (UTC)

I can't say I would have thought Cricket to be a subject area this was a natural fit for, though I'd be interested in seeing their efforts. But have a look at the three specific examples I offer- I think, for instance, that

talk

) 15:28, 17 July 2008 (UTC)

In fact getting rid of subpages was part of the software upbgrade -not just an unused feature. The earliest software had no distinct namespaces and, for example, all talk pages were made be adding a /Talk link at the bottom of the article. The discussion at

Wikipedia talk:Subpages/Archive gives some explanation for why it was disallowed for articles titles. Rmhermen (talk

) 17:21, 17 July 2008 (UTC)

To get back to Phil's point, as this is coming from discussion of notability (particularly in areas of fiction), it has been suggested that adding something to the topic of the page (whether it's a dir-style sub-article approach, or a template to describe the branching nature) would be useful to help immediately identify articles that are meant to be considered as part of the coverage of a large topic. Part of this is raised by the question of supporting articles having to demonstrate their own notability or not, which is a question for that page, but if you consider it for a larger topic, such as say World War II where there are many notable subpages, does it make sense to have such indication present at the very top of the page to help users navigate larger topics? --MASEM 17:40, 17 July 2008 (UTC)

And I think there the answer is yes, at least in some cases. Obviously

talk

) 21:36, 17 July 2008 (UTC)

I guess I have become too much of a fan of

But wouldn't Eisenhower obviously be a subpage of U.S. presidents? Who would make these decisions and how often and (pessimist,me) how would they be done consistently? Article series boxes are still used in some article (including some where I have added them.) In fact, I believe they used to be used in the World War II article which is currently hiding most of its links in collapsible boxes at the very bottom of the page where I doubt they are ever noticed. Rmhermen (talk) 14:29, 18 July 2008 (UTC)

No. One thing you'll see, if you look at the proposal, is that I pretty clearly and carefully tried to cut off this problem by noting that branching should not be used where an article could plausibly have multiple parents. So Eisenhower shouldn't branch off of WWII or US Presidents because he could branch off of both. But I see the general objection, and have tried to head it off. The main thing is that I don't see this as something that should be done everywhere - it's a specific tool that's good for a specific type of article - namely one that has generated a large number of pages that are de facto subpages already. The proposal is not to start dismembering articles into subpages, but to start organizing the subpages we clearly already have but aren't organizing sensibly.

talk

) 14:51, 18 July 2008 (UTC)

There is nothing that cannot be argued to have multiple parents.Geni 21:46, 18 July 2008 (UTC)

There is, however, probably a much more limited set of things that people would actually come to a consensus that it had multiple parents. I think people would have a much easier time nesting Kant's works under

talk

) 22:13, 18 July 2008 (UTC)

Kant is mearly an author. His works come under 18th century philosophy no? Early life of George W. Bush belongs under formative years of US presidents. Your biased tendency to tie things to individuals is showing. I guess you would make Rolle canal a sub article of James Green (engineer).Geni 22:30, 18 July 2008 (UTC)

Geni, are you even being serious here? Read the proposal - neither of the suggestions you're making here - early life under

talk

) 22:39, 18 July 2008 (UTC)

So how would you suggest we break down a Formative years of US Presidents article other than by person?Geni 22:50, 18 July 2008 (UTC)

I'm struggling to imagine how and why we would even have an article on that - but I would imagine if we had one it would be organized thematically so that points about the overall topic became clear and so that it wasn't just a list of biographies. If we're actually going to have an article on formative years of US Presidents it is, presumably, going to be primarily about what trends and similarities can be found among these formative years.

talk

) 23:07, 18 July 2008 (UTC)

Why? You could equaly put it together through a series of short bios and saveing the comparisions to the end. The category system appears to be scale free which suggests that attempts to enforce a parent child relationship on articls are fundimnetaly flawed.Geni 23:43, 18 July 2008 (UTC)

Geni, you're objecting to an organizational scheme because of how an article that doesn't exist might be organized, despite the fact that it would be a completely idiotic way to organize this hypothetical article, which, I hasten to repeat, doesn't exist. I'm not sure how to possibly satisfy your objection, since it doesn't seem based on anything resembling the on-the-ground reality.

talk

) 00:38, 19 July 2008 (UTC)

This is what categories do, surely? ninety:one 22:03, 18 July 2008 (UTC)

Categories or appropriate navboxes can do this, yes. The problem is is that you have to scroll down to the bottom of the page to discover that. In the same line, a well-written lead should clearly state within a sentence or two that the article should be considered a child of a larger article, but not all leads are well written. --MASEM 22:09, 18 July 2008 (UTC)

So use a skin with them at the top.Geni 22:50, 18 July 2008 (UTC)

The category system provides no sense of relationship between elements of a topic. It doesn't matter if it's at the top or bottom, because it's completely inadequate to the task at hand.

talk

) 00:38, 19 July 2008 (UTC)

Fe articles fall within one topic area.Geni 00:48, 19 July 2008 (UTC)

No. But some articles are clearly sub-topics of a parent article. Nobody is seriously going to suggest that

talk

) 00:54, 19 July 2008 (UTC)

Categories seem to me a good tool for tracing a thread across multiple articles. But they don't really organize articles in relation to one another.

talk

) 22:13, 18 July 2008 (UTC)

because as we have learned articles do not relate to each other the way you suggest they should.Geni 22:50, 18 July 2008 (UTC)

Baloney.

talk

) 00:38, 19 July 2008 (UTC)

Well if it is already possible to write that way then no need for a change is there? And you do lose coherence for your method. Suppose I mention GWB's childhood in a third article. Now do a link to your sub article which is going to have context issues or to a main article that only has a summery?Geni 00:48, 19 July 2008 (UTC)

Except that writing that way is an ugly hack right now that causes problems with guidelines like

talk

) 00:54, 19 July 2008 (UTC)

So to get the content I want to link to to make sense I have to link via a seperate article?Geni 02:02, 19 July 2008 (UTC)

Is... that... different from now?

talk

) 03:13, 19 July 2008 (UTC)

There are some article that do relate this way. The problem is deciding which ones they are - and agreeing on it. WP:Series already does something like this, I think. Rmhermen (talk) 23:33, 18 July 2008 (UTC)

I strongly agree with this movement. When you're dealing with a single concept, but the information becomes too vast to put on one page, it is much better to have a formal structure wherein the branched pages are necessarily a part of the overarching concept. Caveat: the implementation of this needs to be simple, elegant, and automatic. II | (t - c) 00:10, 19 July 2008 (UTC)

I can see two good ways to do it - either use the existing subpage architecture, or use article names similar to subpages but process the names via templates instead of in Mediawiki - thus allowing OS/2 to not automatically be processed as the sub-article "2" of the article "OS". Either way, the heavy lifting should be done in the article title and some template code.

talk

) 00:40, 19 July 2008 (UTC).

• Phil, I like the concept that we somehow protect the encyclopedic inclusion of sub-topics, where the parent article becomes unwieldy, but the sub-topic does not meet the GNC individually. But I don't see the need for special templates and software. Why can't we just place a tag on the top of the talk page similar to what projects place, explaining the nature of the article as a sub-page and the rational. We are trying to avoid the deletion of subpages, while not making a loophole for abuse. We do this with articles that survive AfD, providing a link to the previous AfD discussion as rational for continued inclusion. Can we preempt AfD by linking our tag to an RfC (in an AfD format) where consensus for inclusion is demonstrated upfront? --Kevin Murray (talk) 23:49, 25 July 2008 (UTC)
  • If there is, as you suggest, consensus to keep such subpages, why would it matter if they go to AfD? Consensus would then be to keep them. If they're getting deleted at AfD, well then, there is not consensus to leave them around, tag or no tag, subarticle or no subarticle. Seraphimblade ^{Talk to me} 08:10, 26 July 2008 (UTC)
    • Because I don't think that AfD works well. If a decent article ends up on AfD it faces prejudice immediately (e.g., guilty until proven innocent) and gets automatic opposition from deletion-zealots, "drive-by" participants, and ignorant newbies trying to be the worlds greenest admin. Though I have seen many article improve through AfD, it all depends on who is there that day and how much energy they have to "mentor" an article or author. I can typically save about two articles a day if I have the energy to do the research and rewrite. I see that attempts to "legislate" "objective" inclusion criteria as flawed -- we just need better processes to apply logical but subjective guidelines to inclusion selection. --Kevin Murray (talk) 15:02, 26 July 2008 (UTC)
      • I suppose I tend to disagree there. I agree that AfD doesn't work well, but probably not in the sense you say it—I see far too much unimprovable garbage retained and too little emphasis on quality control. I see no problem with an objective standard for inclusion, that standard being "Have independent, reliable sources chosen to give significant coverage to this subject or not?" Whichever the answer is, we follow their lead. If they've given significant independent coverage to it, and it otherwise meets our inclusion policies, we write an article. If they've covered it briefly in the context of a parent topic, we cover it briefly in the context of that parent topic. If they've declined to cover it at all, we decline to cover it at all. We
        do not second guess sources in any other area of our writing, why should we do so when deciding what to include and how to include it? Seraphimblade ^{Talk to me}
        20:11, 27 July 2008 (UTC)
• Phil's initiative sounds good. Please note a couple of current AFD nominations which seem relevant:

• List of Mad Magazine issues
• List of Mad's movie spoofs

These are obviously good appendices to our coverage of Mad magazine and we need a better formal structure for such to avoid wasting time at AFD, where it seems likely that both will be kept. Colonel Warden (talk) 11:55, 28 July 2008 (UTC)

• While browsing the village pump, I noticed that I had written up some thoughts in the same direction a while ago - see User:B. Wolterding/New subarticle concept. Maybe good as food for thought, plus links to previous use of subpages in article space, etc. --B. Wolterding (talk) 17:42, 30 July 2008 (UTC)