Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

New ideas and proposals are discussed here. Before submitting:

• Check if your proposal is already taken care of at Perennial proposals.
• Proposed software changes should be filed at Bugzilla. Editors here can help you with this.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed new wikis belong at m:Proposals for new projects.

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

Watched counter

The proposal in this box is shelved/withdrawn until the proposal in the next sub-section is resolved. (May be worth reading for background on that proposal, though)
The following discussion has been closed. Please do not modify it.
Wikipedia:PEREN#Create_a_counter_of_people_watching_a_page There are more good editors than vandals. Even if making the counter visible and the 'unwatched pages' page public resulted in massive abuse, editors would quickly remedy the problem by adding unwatched pages to their watchlist. Can an admin tell us how many pages there are on the unwatched list? Reasons for doing this, or why the 'vandalism' objection is invalid: Good editors would overwhelm vandals. Displaying "<5" for 0-4 would make this useless for vandals.[1] If there are still vandal concerns, an adminbot could be set up to ask recently-active editors to "adopt" articles. This would allow editors to find pages that needed "adoption". This would relieve the admins who are taking care of the unwatched list. What other reasons were given against this proposal? It might help if the PEREN page linked to the discussions. Without knowing what was said, the reasoning sounds like "the vandals would make this impossible", which is often a poor objection. –MT 03:50, 19 April 2009 (UTC) The list of unwatched pages is limited to 1000 entries, sorted alphabetically. It is rare that it extends beyond the letter A. Every time it is refreshed, there are a number of editors who dutifully watch hundreds of pages from it, yet every time it is refreshed with a new list. It really is like emptying the Atlantic with a teacup. I think the problem is hugely more widespread than you anticipate. Happy‑melon 09:36, 19 April 2009 (UTC) Not that they don't need watching, but how many of the first 1000 are redirects? Mark Hurd (talk) 11:26, 19 April 2009 (UTC) Given that points 1 and 2 would address the vandal problem, doesn't what you're saying just give us all the more reason to support this proposal based on points 4 and 5? –MT 13:51, 19 April 2009 (UTC) Another possibly 'simple' short-term solution is to provide another special page that lists unwatched pages by order of most recent edit and that can also still be limited to the first 1000. If that overlaps between runs, we'd be clearing the backlog from the more 'important' first. Otherwise we're no worse off. Mark Hurd (talk) 00:12, 20 April 2009 (UTC) Great idea. This would not only eliminate vandalism worries, but would also be extremely useful. This feature is a frequent request, is useful and informative, and aside from vandalism I don't think there are objections. We have the following options: Modify wgAllowPageInfo to display "<5 watchers" Change the list to order by last-edited rather than alphabetical, reduce displayed entries to 100, allow all to see it Change the list to order by least watched, then last-edited, reduce to 100, rename it to "least watched articles", allow all. I would support going directly to 3, but we can do a more gradual roll-out by implementing 1 and 3 (I think these are trivial changes, but perhaps a dev could comment) and then removing 1 when the list starts to shrink. Were there any lurking objections? –MT 00:53, 20 April 2009 (UTC) In the flagged protection and patrolled revisions trial implementation, special:Unreviewedpages, which lists pages that have never been patrolled, will indicate the number of active users watching the page. It's only accessible to reviewers. Cenarium (talk) 01:00, 20 April 2009 (UTC) This seems like its a lot more trouble than its worth. If you really want to help with vandalism, just get rollback and download huggle. I disagree that "Good editors would overwhelm vandals." really deals with the vandalism problem. This sounds like how wars used be fought, where each army would just stand in a line and shoot at the other one, and the bigger one would usually win. It worked, but not particularly well. Saying that fewer than 5 people watch a page still makes it nicer target for vandals, it just doesn't narrow it down quite as much. Since the people watching it might have left the project ages ago, it could still have 3-5 watchers but effectively be 0. Mr.Z-man 01:02, 20 April 2009 (UTC) Countervandalism activity is more than just RC patrol. Somebody needs to watchlist articles to catch the vandalism that the RC patrollers miss -- the majority of my vandalism reverts take place hours to days after the fact. --Carnildo (talk) 01:19, 20 April 2009 (UTC) I wouldn't like vandalism patrol, but I would like to make things much easier for editors and much more demoralizing for vandals. Your objection seems against the weakest part of the proposal. The implementation of #3 is a trivial change to an SQL "ORDER BY". The strongest part is editors being able to adopt unwatched pages. This is strengthened by the possibility of a "least watched last edited" page. Vandalism already targets unwatched pages (just click random and mess up an obscure article), this proposal would allow editors to target this already-vulnerable class of pages. –MT 08:07, 20 April 2009 (UTC) When your database contains several million rows, changes are rarely "trivial." The code for Unwatchedpages doesn't count the number of people watching the page at all right now nor does it use an explicit order, so you would need to add the "ORDER BY" and would also need a "GROUP BY." The other issue is that the list is only updated once every week or so. Given that we get about 11,000 edits per hour on around 6000 distinct pages, "most recently edited" might as well be random as it would be out of date within a few minutes. Based on a quick and dirty estimate using the number of pages in the list right now and how far it gets alphabetically, I would estimate that there's easily 60,000 unwatched pages. At 100 at a time, with updates once a week, it'll take 11 years just to work through all the pages with 0 people watching them, ignoring all the ones that are added in that time. Mr.Z-man 18:41, 21 April 2009 (UTC) I didn't and don't endorse a broken version of a recently-edited page. Given that wgAllowPageInfo doesn't use a field in the page table, I agree that it isn't trivial. It would require adding a field and index to the page table (cf. page_random, page_len, page_touched) that kept track of watchers. What sort of disruption would the addition of this field cause? Consider where unnoticed vandalism mostly occurs. The proposal would put into view these pages (which are highly vulnerable, seldom altered, and recently altered). This would allow editors to have a central place to patrol for vandalism (see Wikipedia_talk:Special:UnwatchedPages#Purpose. It would also allow editors to find pages to watch. There's a great reason Jimbo requested the unwatched pages, and given that that method is too overwhelming, there remains a great reason to implement recent least-watched pages. –MT 23:39, 21 April 2009 (UTC) Adding new tables to the database is relatively simple. Altering existing ones is generally avoided. I believe it requires stopping replication on, altering, then re-enabling each slave server one by one, then switching the master to update that. After updating all the databases, a script would have to be run to populate the new field. The page table on enwiki currently has 16,575,280 rows, and grows constantly. I've no idea how big the watchlist table is. If this is done, it might make such a special page possible (and able to be updated dynamically). The index would also probably have to be on page_latest as well if you want to be able to sort by most recently edited. Mr.Z-man 00:08, 22 April 2009 (UTC) Not forgetting, of course, that while the database master is being updated, the whole wiki goes read-only (unless they do something wierd like setting one of the slaves to be a temporary master, which could work I guess). This is the schema update script, yes? Happy‑melon 17:05, 24 April 2009 (UTC) \ Ah, pages isn't indexed by date. How does recent changes work then? (schema, large image). Perhaps it would be more appropriate to add this sort of field there. This would also involve adding a field, but might be less dramatic. The field would list the number of people watching the page at the time the edit was made, and could be used to generate our desired list. –MT 02:40, 22 April 2009 (UTC) Since RecentChanges would otherwise need to read from about five different tables every time it was requested, it actually stores all its data in its own separate table. Every new elegible edit or action puts a copy of its log into the recentchanges table as well as whichever permanent table it uses, and ever hundredth edit calls a function to clean out rows from the table that are older than the limit (currently 30 days). Happy‑melon 17:08, 24 April 2009 (UTC) Perhaps I should amend the proposal.–MT 19:38, 25 April 2009 (UTC)

A recent changes page for unwatched articles

Vandalism is a problem on all pages, but it is a much larger problem on pages that, on average, have fewer or zero people watching them. One solution to this problem is Wikipedia_talk:Special:UnwatchedPages, which was requested by Jimbo, is accessible only to admins, is updated infrequently, and is therefore very difficult to 'clean out'. Another solution, advocated here, is to modify the recent-changes table in MediaWiki to grab the watcher-count from the watchlist table. We would then be able to create a "recent changes in unwatched articles" page. This page would let editors catch vandalism that would usually have gone unnoticed for long periods of time. It would also encourage editors to expand their watch-lists, and urge editors to contribute to fringe/stub articles that are seeing some recent activity. It would also allow us to finally address one of the WP:PERENs. To get this proposal off the ground, we would need:

1. Interest from editors. Other potential benefits. Perhaps a straw-poll.
2. Critical comments, including reasons why this might not be as useful as stated.
3. Solid estimates of cost - can this be done without locking the site? How long would it be read-only for?
4. Input from a developer. Should one be contacted to check feasibility?

Comments addressing any of these four points are especially welcome. –M^T 19:38, 25 April 2009 (UTC)

Now this is an interesting, and probably feasible, idea. Technically, it could probably be done without a schema-change, and it could be useful to do so; the code in FlaggedRevs, for instance, uses the fact that it has to do a database lookup to be more clever in what it shows: it only 'counts' users who have logged in in the past 60 days, for instance, which is pretty neat. If the servers can take the strain, having that feature available on Recent Changes would be very useful, and avoids the issue of pages apparently being watched because they're on the watchlists of users who last logged in three years ago. Performance-wise, having a rc_watched column in the recentchanges table would massively reduce database load when viewing RecentChanges. Or we could define a few more types in the rc_type field (only ~3 actions defined out of a possible 16 million!), and avoid an explicit schema change, but the devs might find that a bit hackish (I remember there being hiccups over the RevDeleted bitfields). On the other hand, that field then has to be populated on every action.

Procedurally, it sounds like a godsend. Unwatched articles are only dangerous if they're edited; unwatched but untouched articles are no harm to anyone. Happy‑melon 14:39, 27 April 2009 (UTC)

I think 7 days would be the best last-login time, unless someone can give a better figure. Given the rate of revisions vs the rate of access, and the many other fields in recent changes, I don't think that this would do too much damage to performance. And the benefits, as you say, are a godsend. Should we get dev feedback, or try to get a few more comments? –M^T 02:36, 28 April 2009 (UTC)

I guess it should be the latter... –M^T 04:28, 5 May 2009 (UTC)

How might the column increase performance?   M  20:37, 13 May 2009 (UTC)

I have to agree that this is an interesting proposal. During my vandalism patrols i cross infrequently visited articles every now and then which blatant vandalism on them for periods up to (And in some cases over!) a year. While I encounter them irregularly it won't automatically mean there are not a lot of pages vandalised this way - they simply don't show up on anti-vandalism tools often. I also see possibilities for using this page for new page patrol as pages listed might very well be missed non notable or vandalism pages that slipped into forgetfullness.

On a more critical note: How would these articles be patrolled? I can imagine that this category will end up having at least 100.000 articles in them. Even if they are only infrequently edited it will still mean a lot of edits in a day - and how will double / triple / n* checks of the same page be prevented? Likewise, not every actively edited article has to be on a watchlist. Also, some active editors have massive watchlist from new page patrols (I had to remove 600 entries from three weeks patrolling). How can we prevent pages from going unnoticed due to unclean watchlists? Might it be better to filter on pages that have not been edited in say, two months? Excirial ^{(Contact me,Contribs)} 19:51, 15 May 2009 (UTC)

Another way to look at it is as filtering out all 'watched' pages from recent changes - if someone's watching, you don't need to. So right away we're preventing many multi-checks. Overflowing watchlists are a problem, but this new page will catch further edits to infrequently-edited articles. So if you can't track every page on your watchlist, then you shouldn't, and now you wouldn't have to. The other problems you bring up - inevitable double checks, thousands of edits per day - are ones we already face. This proposal can't solve them, but it does reduce them.   M  22:13, 15 May 2009 (UTC)

You could just use variables, like

"Recent Changes on Village pump (proposals): Greg Tyler, on 09/7/2009"

But it would be a good idea for rollback

Would there be some way of combining it with the recent "whitelist" list of autreviewers? That is, for there to be a list of recent changes to unwatched pages excluding those pages where the last change is by an autoreviewer? That way it would be easy to look for vandalism without checking pages where someone else has already reverted vandalism. That might well solve some of Excirial's concerns about multiple checks of the same recent edit. Grutness...wha? 02:09, 23 June 2009 (UTC)

The list would essentially be a filtered version of the current recent-changes list, so if this idea is possible there, then it is possible with this list. I don't think that this should be handled by the server itself, though I do think that it should expose the autoreviewer or admin status of the last editor, so that scripts could use that information to do what you describe.    M   21:57, 2 July 2009 (UTC)

Would it be a good idea to move this proposal into its own page, and if so, where should it be located?    M   22:10, 6 September 2009 (UTC)

Recent unwatched changes straw poll

The proposal is to create a recent changes page for unwatched articles to prevent vandalism by modifying the recent-changes table in MediaWiki. (I'd really prefer not to see this one archived, since it would open up several useful features. It would permit Watched counters. A now-ignored bugfix in the watchlist code and the addition of a 'checked' watchlist row would then let you patrol your own watchlist. Adding a public-watchlist preference would then give us a passive form of Flagged revisions.) Though this is a software feature request, support from editors would help.

• Support. –M^T 04:28, 5 May 2009 (UTC)
• Support. -- John Broughton (♫♫) 18:24, 9 May 2009 (UTC)
• Support sounds good to me. It does provide a route for vandals to find unwatched articles, but I think the benefits outweigh that. Rd232 ^talk 18:34, 9 May 2009 (UTC)
  • While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. –M^T 19:46, 10 May 2009 (UTC)
• Support. Mark Hurd (talk) 15:05, 10 May 2009 (UTC)
• Comment - Just file a bug. If its a good idea and technically feasible, someone will do it. The existence of a straw poll will likely have no effect. Mr.Z-man 15:26, 10 May 2009 (UTC)
  • Isn't a bug with a supportive straw poll more likely to be implemented soon than the same bug without? Rd232 ^talk 19:35, 10 May 2009 (UTC)
  • When people voice their support for a proposal, others become more inclined to try to see it implemented. This may include filing a bug report, searching documentation, speaking with devs directly, changing the relevant code, and submitting a patch. "Well, someone else will get to it eventually" is not the approach that we should take at this page. Even if the devs were entirely blind to community requests, your support would nevertheless encourage other editors (like me) to try to see this implemented. –M^T 19:46, 10 May 2009 (UTC)
    • With this specific proposal, it may, but only because the schema change would need approval from Brion. With the amount of work required to do this, I doubt a little straw poll is going to have a significant effect on any developer's motivation. Mr.Z-man 18:58, 13 May 2009 (UTC)
      • Then let's hope that it grows to become a much bigger straw poll :) as this might demonstrate a need for better tracking of unwatched pages   M  20:29, 13 May 2009 (UTC)
• Support - I really like this idea. I know from personal experience that non-obvious vandalism on poorly watched pages can go undetected... I have a couple such pages on my watch list & when I took a month off, I cam back to find some vandalism on one of them that had been sitting for 2+ weeks. --ThaddeusB (talk) 18:34, 13 May 2009 (UTC)
• Support - Great idea. Kevin Baas^talk 20:34, 13 May 2009 (UTC)
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\^C 20:38, 13 May 2009 (UTC)
• Bug 18790 has been created. Suggesting improvements (or establishing that there is a clear need for this) here is what will help with implementation, though voting at bugzilla in addition to here should help make it more noticed. At bugzilla, only 55 wp enhancements have 10+ votes, 19 have 20+, and 8 have 30+, out of over 1300. Registration is easy, and the vote link is at the bottom-right of the bug page, under 'related actions'. (Please use this feature to vote instead of leaving a comment at bugzilla, as comments are relayed to mailinglists).   M  22:31, 13 May 2009 (UTC)
• Support - Makes a lot of sense and fills a great need. J04n(talk page) 09:58, 22 May 2009 (UTC)
• Support - If this can be done without overloading the system, then by all means please do. (Every little bit helps in targeting vandalism.) --Ckatz^chat_spy 17:18, 26 May 2009 (UTC)
• Support per above proposal --unsigned by Assasin Joe
• Support per all the other comments that I read. This would be very useful to find vandalism in more hidden pages. –Drilnoth (T • C • L) 17:02, 27 May 2009 (UTC) See my comment below. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Support per my original comment. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)
• Support – Wow, this is a really good idea. As long as it can be configured in software, I think it would be very useful. American Eagle (talk) 06:36, 31 May 2009 (UTC)
• Support If implementable, it's an ingenious solution to the problem of vandalism to unwatched pages. --Cybercobra (talk) 08:52, 31 May 2009 (UTC)
• Support only for admin, oppose otherwise - It would be simple enough for a vandal to watch a page, and then it would fall off of everyone's radar. That would turn a good thing into a very bad one. ▫ JohnnyMrNinja 06:57, 5 June 2009 (UTC)
  • Restricting the page to admins is one solution, but I don't think that there's a problem. We would count only autoconfirmed watchers active in the past 7 (or 60) days, and the implementation would also give us recent-changes for pages with 1 watcher, or under 5 watchers, and so on. The sort of coordinated vandalism to 'get around' this is rather visible and is more difficult to deal with if we keep the pages admin-only.    M   01:14, 6 June 2009 (UTC)
    • Isn't that going to be a gigantic strain on the servers? Right now, our watchlists are the biggest strain (right?), so wouldn't a watchlist that watches thousands of pages that are selected from every page on EN based on a series of checks on each page and every user that watches any pages at all... Wouldn't that slow our WP down to the barest crawl? Even if the list of articles matching the criteria were only updated every other day or so, a watchlist that big is a massive beast. Of course you could limit the number of pages that show up, but it would still check the entire list for the 100 most recent changes (right?). I'm certainly no expert on how Mediawiki works, so maybe I'm wrong. Limiting it to admins is a better solution, I would think, if even that is feasible. If it's between having an even-more unstable connection to WM projects or having the fact that Franklin Township, Wright County, Minnesota is referred to as a "gaylord" for two weeks, I'm okay with the latter. But, again, maybe I'm mistaken about the strain. ▫ JohnnyMrNinja 09:12, 10 June 2009 (UTC)
      • No - actually, it might speed things up. The proposal is not to put every unwatched page onto a global watchlist, but to record the watcher count in the recent changes table. This is extremely fast compared to a global watchlis, and is fast in general (see Bug 18790). If the page causes people to reduce their overburdened watchlists (which it should), it may actually increase performance.    M   00:27, 11 June 2009 (UTC)
        • If that's the case then it could be workable, and it is a good idea. With the inclusion requirements you've specified, the list would actually pick up far more pages than the regular unwatched pages list. But I must stress that launching it for everybody is a bad idea, because if something goes wrong and it is deactivated, we will have provided a complete list of un-and-hardly-watched pages, and then removed our ability to protect them. I am not a fan of segregating access normally, but I still feel that it should only be accessed by admin (maybe rollbackers?) until such time that it shown to not contain bugs and we decide we're going to keep it permanently. The only thing you need to be Autoconfirmed is to not have been blocked yet. ▫ JohnnyMrNinja 02:25, 11 June 2009 (UTC)
          • Right, it wouldn't be the same, though this means it would pick up more unwatched pages and not false positives. It wouldn't be a complete list, since it would only record edits made in that short period of time (no doubt those articles would be gobbled up into watchlists by our editors). I do think that these points deserve attention, but it might be early to decide how we want to deploy the feature.    M   18:29, 16 June 2009 (UTC)
            • A few comments. This almost certainly won't speed anything up. Watchlists are not the biggest strain and the slow part of watchlist generation is generating the HTML, not the 1 database query to get the list. You're calculating something that's not currently calculated and not removing anything else. You say in one comment that people would "reduce their overburdened watchlists" then in another that pages would be "gobbled up into watchlists by our editors." That can only affect performance in one way. The question is just will the extra calculation on every edit be fast enough to be usable. Blocking a user does not remove the autconfirm right. A blocked, autoconfirmed user could still do anything that requires autoconfirmed, as long as it doesn't also require editing rights. Even if they're blocked before becoming autoconfirmed, their account doesn't stop aging, and most blocked users can still edit their talk page; so they could even become autoconfirmed while blocked. Mr.Z-man 20:36, 16 June 2009 (UTC)
              • A reduction in the size of watchlists and perhaps the need to check them might reduce some of the burden. It's not important whether it will or not, just that it definitely won't bog down the server. In the long term, this will allow editors to reduce their watchlists. In the short term, editors will tend to add these articles to their lists until they see that it's unnecessary. If something went wrong, which is entirely unlikely, we'd have no problems watching the small list of recent unwatched articles. Dedicated vandals will always get through to some extent, but checking for autoconfirmed is something cheap, relatively accurate, and effective for the majority of cases.    M   00:23, 22 June 2009 (UTC)
                • Restricting it to autoconfirmed would be trivially simple to bypass. Vandals wouldn't even need to create new sleeper accounts to see the list, they could just use existing, blocked ones. If you're not concerned with dedicated vandals, then it shouldn't be restricted at all, as only dedicated vandals would likely even take the time to check such a list. Mr.Z-man 03:28, 22 June 2009 (UTC)
                  • Misunderstanding, I think. It's safe to let everyone see it; I think the concern was a vandal registering 5 accounts, watchlisting many articles, and then vandalizing them. Autoconfirmed would be for whether the editors are counted as watchers, which makes this strategy not worth the effort.    M   08:11, 26 June 2009 (UTC)
• Support the unwatched list it too big to do anything useful with by admins. Perhaps proven vandal fighters would get blocks of these unwatched pages to add to their watchlists. Talk to me if you are interested in this idea. The article names could be emailed to those who want to change them to watched articles. Graeme Bartlett (talk) 02:16, 6 June 2009 (UTC)
• Support Sounds like a good idea. Dream Focus 09:35, 6 June 2009 (UTC)
• Support Graeme two posts up says it well. Casliber (talk · contribs) 05:29, 25 June 2009 (UTC)
• Yep, definitely a good idea. –Juliancolton | ^Talk 22:07, 2 July 2009 (UTC)
• Support Very useful idea. It will increase the efficiency of the list. In my opinion, I would not mind if I had a list of pages to watch on top of my current list. It is all going for the same cause in the end anyways. -- Dspradau → talk  14:45, 6 July 2009 (UTC)
• Support, a very good idea. 'Nuff said. Jamie^☆S93 21:41, 9 July 2009 (UTC)
• Support, with considerations. It should only go ahead if it is known with certainty to not cause added strain to the servers, as well, I think one of the suggestions above should be seconded: make it admin only for a test period, before opening it up for everyone to use, just as a precaution. (I know, I'm hardly here, but, at least I'm hardly here over a long period of time *grin*, which should let me have some say). kaVri 19:28, 12 July 2009 (UTC)
• Support - This feature would increase average article quality on Wikipedia by combating vandalism on unwatched pages. One could see it as a complement to Flagged Revisions. EconomistBR 20:56, 15 July 2009 (UTC)
  • I've heard stories about something called "flagged revisions", but I think those are just ghost tales that old editors tell each other around the campfire. They'll be implemented soon is the punchline to all the jokes. There was something about them appearing when Brion Vibber got back from his honeymoon, but he seems to be back now... Delicious carbuncle (talk) 21:54, 15 July 2009 (UTC)
  • Though I don't think that flagged revisions are as useful as they seem (I'd prefer a per-person way of tracking articles and not revisions, which is somewhat easy to implement using the watchlist), I agree that the two would work well together. Similarly, if we turned on the 'how many people are watching this page' feature, those interested in watching the unwatched pages would be able to tell if they are already watched.    M   21:05, 20 July 2009 (UTC)
• Oppose, this will just make things worse, giving the vandals a potential hit list they can use. ViperSnake151  Talk  13:33, 24 July 2009 (UTC)
  • You might be misunderstanding the proposal. While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. It's safe to leave cheese out when there's a lethal spring-loaded bar attached - which is exactly what this list is.    M   17:44, 31 July 2009 (UTC)
• Support – definitely. This is a good way to revert vandalism. —MC10|Sign here! 02:34, 25 July 2009 (UTC)
• Nuclear support. This is a brilliant idea. In the past I've randomly picked some unwatched pages to put on my watchlist, but they were never edited that I saw, and I removed them as a futile addition. One caveat, though. Are we only looking at pages that show up on zero watchlists, or will this include, for example, pages only watched by people who are long gone? Come to think of it, where we have permablocked vandals and the like, can we strip them of their watchlists and prevent them from watching articles (given that they would only have nefarious reasons to be watching anything)? Cheers! bd2412 T 19:28, 31 July 2009 (UTC)
  • It marks the recent-changes entry with how many recently-active & autoconfirmed editors were watching at the time of the edit. This ignores long-gone editors, and the 'watch pages to hide them' vandal tactic is painfully time-consuming (so watchlist-stripping is not needed). Yes, we would be able to filter recent-changes to pages with 0, <5, or >500 watchers.    M   19:52, 31 July 2009 (UTC)
• Support Ben MacDui 15:42, 1 August 2009 (UTC)
• Support Far better to match the system to the content, not vice versa: there have been calls to raise the BLP notability bar to cut down on content needing to be watched. Esowteric+Talk
• Support - great idea. --[midnight comet] [talk] 18:24, 3 August 2009 (UTC)
• Support - makes life easier. Kayau Wuthering Heights VANITY FAIR paradise lost 08:17, 4 August 2009 (UTC)
• Support-It seems like a great idea. However, there must be hundreds of thousands of unwatched articles. Perhaps we should start off with admin's first. In addition, there really should be a limit as to how many a person could see.(I see no reason to have a public list of 150,000+ unwatched articles as this invites vandalism).Smallman12q (talk) 19:28, 4 August 2009 (UTC)
  • The list pretty much only displays recently-edited unwatched pages, rather than all unwatched pages. It would slowly grow until pages started falling off the end. You're probably right about the title - we shouldn't have a page called 'here are our unwatched pages' (which isn't true anyway, since we'd watch them using this list). It should probably be just another option in the recent changes list.    M   02:05, 5 August 2009 (UTC)
• Support. What a great idea. To the editor who said it should only be admins, I can understand, but suspect that more help will be needed than just sysops. What about making it availible to those who have had rollback without incident for six months or a year? Unschool 02:17, 10 August 2009 (UTC)
• Support Couldn't hurt anything, and might wind up being useful. causa sui× 04:43, 13 August 2009 (UTC)
• Support I can't see it doing any harm to try this, at the very least. Sophus Bie ^(talk) 03:13, 14 August 2009 (UTC)
• Neutral. Would certainly be useful but... vandals can watch pages to. A vandal who is smart enough to use that list to find pages which aren't watched would probably be smart enough to watch the page after vandalising it. :/ I know, WP:BEANS, but I think that it needs to be mentioned. One option would be to limit it to a trusted group like rollbackers. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Switched back to support, above. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)
• Support. I do not quite understand this technical jargon (please do not waste time trying to explain to me), but if the only way the server load can be tested, is to be implemented, I support. All critics seem to have been silenced by M's rebuttals. Lumenos (talk) 04:44, 15 August 2009 (UTC)
• Support. Sounds like a good idea. I just hope it doesn't backfire because of unforeseen circumstances. Maybe it should be tested first in a trial run for admins only. -- œ^™ 20:18, 15 August 2009 (UTC)
  • I like the idea of testing in a safe way first, before making it live for all. That unfortunately might mean restricting it to admins, unless someone has a better idea. (One possibility would be to force the list to be definitely small enough to process, eg show only the first 100 unwatched-change pages per day. Or show those 100, but only create a new batch when all those 100 have been watched...) Rd232 ^talk 08:45, 7 September 2009 (UTC)
• Comment This seems to have broad support, and a bug was filed. Should the poll be closed? --Cybercobra (talk) 03:45, 18 August 2009 (UTC)
  • 34 support, 1 Oppose as of your comment, so the support is strong, yes :) It's still not clear though if this is something the community sees as not just a good idea, but something that's really needed (per my 13 May comment above). Many editors are also giving a lot of informative feedback (eg the 'rollbackers only' points) and ideas, without this generating 'drama'. I think it will die down soon enough anyway...    M   02:21, 19 August 2009 (UTC)
• String support provided access to it is limited to trusted users (perhaps admins and rollbackers?). עוד מישהו Od Mishehu 08:38, 18 August 2009 (UTC)
• Support Brilliant idea ! Mr.TrustWorthy----Talk to Me! 17:19, 18 August 2009 (UTC)
• Support GeometryGirl (talk) 11:01, 19 August 2009 (UTC)
• Support ----occono (talk) 17:06, 23 August 2009 (UTC)
• Yep, would be good. I suggest that only rollbackers and sysops be able to see it. Pmlineditor  Talk 12:10, 30 August 2009 (UTC)
• opppose Until we know exactly how many unwatched articles/pages there are. If there are more than 10,000, I can't imagine a watchlist which would do much good unattached to some external tool. Protonk (talk) 08:27, 7 September 2009 (UTC)
  • My feeling is that the number is far north of 10,000 Protonk (talk) 08:34, 7 September 2009 (UTC)
• Neutral To be honest, I just don't care much about the underlying issue here. It certainly wouldn't bother me if this were implemented, but since I would be unlikely to ever use it I can't support it.
  — V = I * R (talk to Ω) 08:52, 7 September 2009 (UTC)

Proposal: Have a bot autodelete any stub article of less than 250bytes if not edited in X months

Per WP:REDLINK and WP:STUB, I think there should be a balance between creating an article of one or two sentences and allowing an unimproved micro stub to exist indefinitely. My view is that a redlink is as much or more an incentive to research and create an article as is a stub to expand, but that a minimal stub detracts from the impression of the encyclopedia as a serious enterprise. As I am aware that many editors do create a very short stub as a type of placeholder and then they (or a project) begin expanding them I would think there should be a generous allowance to permit them - or others - to work upon them to bring them up to article status.
Per WP:Stub Wikipedia is not a directory and it would be difficult to argue that a one or two sentence page would not fall into that definition - except perhaps place names; "X" is a small village in Y province/state of country Z", and discussion might suggest particular stub types that might be exempt from the cull. Also suggestions regarding time frames may be beneficial, especially with input from those who can provide analysis on the likelihood of expansion on stubs over time from creation.
I look forward to comments. LessHeard vanU (talk) 14:01, 21 August 2009 (UTC)

I'd oppose your proposed exemption: to my mind, a bot that went through and automatically deleted orphan stubs should be specifically targeted at the efforts to convert Wikipedia into an atlas. A bot-created stub about a remote yak-herding village that has only been edited by bots since its creation is a perfect target for deletion. If someone wanted to write a more customized bot that automatically created "list of settlements in so-an-so" based on the geographic coordinates in those stubs, I wouldn't object to that as an alternative to outright deletion.—Kww(talk) 14:06, 21 August 2009 (UTC)

This has the same problem as people using bots (scripts) to create stubs - no human oversight as to what is happening. 250 bytes, while it may sound reasonable, is an arbitrary cutoff - and unfortunately any cutoff would be rather arbitrary. There is no way to ensure that the content being deleted should be deleted. The idea of removing data to encourage the addition of data strikes me as being somewhat backward. While I can safely say that I would (probably) support the deletion of most individual sub-stub articles of this size, I am uncomfortable with turning a bot loose to do the work on its own. Shereth 14:08, 21 August 2009 (UTC)

We should not be deleting articles until a person has at least looked at it. An article being short and not edited often is not criteria for deletion. Chillum 14:09, 21 August 2009 (UTC)

Add in a view counter parameter? I am suggesting 250byte (but am open to variance based on experience) as a really small size which unlikely be more than a directory type stub, but if it is being viewed regularly then there is evidence of worth. In a general response to comments so far, deletion is not judgement or permanent; if something that should be there gets removed then it will be recreated and hopefully for the better. LessHeard vanU (talk) 14:28, 21 August 2009 (UTC)

I suppose you could tack on numerous "parameters" for the bot to go on. Has it had more than 1 non-minor edit? Does it have X number of views? No edits since X? Only edited by bots? Only X bytes long? Inbound links? A lot of these would help ease my concerns, but the major stumbling block to me is that it's all run by bot. I am extremely hesitant about bots being involved in the creation or deletion of articles, for ultimately the inclusion criteria can only be judged by a human, not a machine. Now, I could see a bot placing them in a CSD-like "stubs eligible for deletion" category that could be reviewed by actual humans who could make the final call on whether it should be deleted, but then we're creating an awful lot of work ... Shereth 14:35, 21 August 2009 (UTC)

Add in a two-week notification to the creator of the article before the deletion, and that seems to be good (Make sure this is well-advertized with an opt-out - I don't thikn some bot operations want to see 1000s of the same messages). --MASEM (t) 14:10, 21 August 2009 (UTC)

I would oppose this, per Shereth. Arbitrary cutoffs are bad. For example:

[[File:JohnSmith.jpg|thumb|John Smith]] '''John Smith''' was a sixteenth century English author. While he wrote several collections of poetry, including [[Collection1]], he's most famous for his plays, mainly [[His famous comedy]]. {{author-stub}}

is only 247 bytes, yet it includes an image, links to other relevant articles, and contains key background information. However, one could write an article that consists of nothing but a well-filled infobox and a stub tag, and have it be well more than 250 bytes. If an article goes several months with no edits, I think its rather unlikely that a well-researched full article is on the horizon, and the only thing that's preventing it is the stub. My guess is that we would just end up with a redlink for another several months or years, and rather than providing what little information we can, we provide none. Mr.Z-man 14:33, 21 August 2009 (UTC)

• Perhaps someone could do some data-gen to give us some examples of the articles that would be caught by LHvU's proposed net? –xeno^talk 14:36, 21 August 2009 (UTC)

• I would oppose this. Being short and stable is not any kind of criteria for deletion. DuncanHill (talk) 14:48, 21 August 2009 (UTC)

• Why not have the bot just prod all the articles, rather than delete? Of course, this would create a tremendous backlog of prods if done all at once, so perhaps this could be run at a limited rate, or something like that. Cool3 (talk) 14:57, 21 August 2009 (UTC)

I had thought of that, too, and was worried about the backlog - I hadn't considered throttling the reporting bot. Shereth 15:01, 21 August 2009 (UTC)

• Oppose. we are not on a timetable to finish the encyclopedia. If stubs are notable, they can linger as long as it requires for an interested editor to come along and improve the article. With the current "completness" of the encyclopedia, it will require longer and longer for stubs to develop, but that is no reason to delete them. See also Duncan Hill's comment. —TheDJ (talk • contribs) 15:04, 21 August 2009 (UTC)

  I would support such a bot adding articles to a category for human review. Chillum 15:07, 21 August 2009 (UTC)

• The main question is, is there consensus to delete any kind of substub even if the topic passes WP:N & friends? If so, of which kind? I for one wouldn't mind seeing all "Foo is a Bar" type substubs gone, in particular if we already have a "List of Bars" article.
  My biggest problem with stubs is when they are so short that they have to be considered wrong, which can usually only happen with (quasi-)bot-created stubs (e.g. Philipp von Bismarck, Otto Fürst von Bismarck (CDU), Karl-Heinz Daehre, Mario Czaja, Karl Eduard Claussen, Christine Clauß, Paul de Chapeaurouge, Rudolf Böhmler, which all omit the most defining points of those people). With the current proposal at WP:VPP that should hopefully happen less frequently for any newly created stubs. Question remains how to identify all the existing substubs that fall into that category, be it for improvement or deletion. By default I'd think that they will always need human eyes on them, but as xeno said, a examplary selection of substubs generated by whatever filters would be enlightening.Amalthea 15:36, 21 August 2009 (UTC)
• Yes, size isn't a deletion criterion. The best treatment of a permanently short article might be to merge it, move it to wiktionary. etc., but these are operations for a human. No harm though in having bots generate lists of articles based on any criteria people find useful (but of course there's no need to add tags or categories to the actual articles - that just floods the changes lists unnecessarily).--Kotniski (talk) 16:04, 21 August 2009 (UTC)
• I also disagree with this proposal, it would have the potential to catch articles such as this one where there was content but only in a template thus making the article shorter than it actually was by byte size. I am aware this would be ok due to the article being edited within a reasonable time scale but I fear other similar articles could be caught. More basically I disagree with the premise as very short articles can be expanded by anyone, while new articles can only be created by registered users. If the articles have enough context to avoid meeting the speedy criteria and have potential to be expanded they should not be deleted or merged out of existence. Some verified information is better than no information. Davewild (talk) 18:53, 21 August 2009 (UTC)
  • Well, I don't find the last part true. Take Paul de Chapeaurouge, for example, which I mentioned before: The only verifiable (not verified!) information we have on him is that he was "a representative of the CDU" – which is basically a footnote in his biography, he joined them when he was 70, and all the time he was a founding member of a different party. Substubs like this, generated from a list, often leave out the important parts, but make it appear as if they presented the high points. Having no article would be preferable here, since the only verifiable information we have would have turned up in a search anyway, by way of the list. Amalthea 19:41, 21 August 2009 (UTC)
    • Having the article in the case you have raised does have a good purpose as it provides an easy link to the German wikipedia article which can be used for expansion of the article, which is more likely to happen now that link is there than from a list. Pointing the reader, as well as potential editors of the article, towards such a more substantial article in another language is not a bad thing. It also would not be even close to coming under this proposal anyway as it has over 500 bytes so I question whether this proposal would even achieve the aim that it's proponents would want. Davewild (talk) 19:57, 21 August 2009 (UTC)
      • The criteria are in a state of flux, of course. :)
        I'm not sure our typical reader will even notice the interwiki link and, again, this substub conveys an incorrect picture of that person. If a reader goes away with the impression that the most notable feature of him was what's in the article then we have done him a disservice. And of course, there's for example Sabine Christiansen where I'm pretty sure the interwiki link is complete bogus as well. Amalthea 20:22, 21 August 2009 (UTC)
• Oppose The age of the stub article is not relevant. It could develop into something better one day. And even a stub for a Wikipedia valid topic, is better than nothing at all. Dream Focus 19:48, 21 August 2009 (UTC)
  • Well, I would refer you to the (random!) example I've just presented directly above. Amalthea 19:52, 21 August 2009 (UTC)
    • Which would not even come under this proposal anyway as I point out above. Davewild (talk) 19:59, 21 August 2009 (UTC)
• Oppose for the reasons already mentioned.--Cube lurker (talk) 20:01, 21 August 2009 (UTC)
• Oppose as nobody is more encouraged by a red link. On the contrary, starting an article from absolute scratch is a more daunting task for the unprofessional editor then making edits to an article that has already passed the deletionists of wikipedia (New page patrol). Further to this, there is nothing gained from deleting these articles. There is only loss of information. Just because someone has it subjectively in their mind that this information is irrelevant, does not mean that it is irrelevant. - ʄɭoʏɗiaɲ ^τ _¢ 15:10, 22 August 2009 (UTC)
• Oppose Having a stub is better than nothing at all, and having half of the picture is better than having no idea at all who a person is. If information/pictures/interwiki links are incorrect, that has nothing to do with the article being a stub. Anything incorrect should be fixed. hmwitht 14:37, 23 August 2009 (UTC)
• Oppose Look at any paper encyclopedia and you will find lots of articles shorter than 250 characters. Stubs are fine. Sometimes I just want to know what something is. I also question the premise that redlinks are more likely to be expanded. Stubs allow IP users to expand. --Apoc2400 (talk) 15:41, 26 August 2009 (UTC)
  • Accius is a good example. It is 300 bytes, but that is due to lots of markup. John Vandenberg ^(chat) 12:57, 1 September 2009 (UTC)

Have the bot list such stubs for review and possible prodding/deletion/merger, etc

Well, it appears that there is a large sentiment for "something is better than nothing" - even if it triggers WP:NOTDIR, so perhaps it would be best that any initial run bot would simply list these stubs and a taskforce could go through and remove the real junk (once tagged by the bot it would whitelist any stub not deleted). Any subsequent bot runs could PROD an article under the criteria, and again allow flesh and blood operators make the decision. I would comment that this is not attempting to "finish up the encyclopedia" but to remove content that is no longer up to standard - much like some old FA's lose the status - and improve the overall quality of the project. I would, of course, sign up for such a review body in the first instance. LessHeard vanU (talk) 20:11, 21 August 2009 (UTC)

^^^ The first part of this is a "just do it" solution, no one can stop someone from compiling such a list. I would suggest the eminently helpful MZMcBride, he's great with this kind of thing. Maybe ask at WT:DBR. –xeno^talk 20:14, 21 August 2009 (UTC)

This seems to be an eminently good idea. Something vaguely similar was recently done with bilateral relations articles (a group of people went through a list of them all trying to weed out the junk) with what seemed to be fairly good results to most folks. Perhaps forming some sort of project/group/taskforce/etc. to help carry out the process wouldn't be a bad idea, and of course as it could become a standing group of sorts as new articles would enter the list over time. Cool3 (talk) 20:29, 21 August 2009 (UTC)

We already marks stubs for reviewing, via the {{stub}} templates that we put on them. The issue is not lack of marking, it's lack of volunteer time to review tens of thousands of articles. — Carl (CBM · talk) 20:32, 21 August 2009 (UTC)

This tool may help with this effort. -- œ^™ 04:28, 22 August 2009 (UTC)

• I have (had) generated a list of articles of below 250byte that has not been edited in 12 months, tools:~mzmcbride/lessheard.txt - there are 1500+ of them. A brief review indicates that some like "List of" are likely useful - but the number that uses an underscore ("_") in the title indicates that it is unlikely to be found as a search item: there may even be another better titled article on the subject. There are obvious candidates for a BLP review, too. Oh, well, I have my bot list, and something for me to do that doesn't involve being droll at the drama boards... Anyone wanting to take a punt at reviewing/prodding/deleting/redirecting/merging is welcome. If there are more than a couple we might even have to organise a small project. LessHeard vanU (talk) 16:45, 22 August 2009 (UTC)
  • An underscore and a space are equivalent: Life_Will_Be_the_Death_of_Me = Life Will Be the Death of Me. Amalthea 17:10, 22 August 2009 (UTC)

**I am happy to try and expand some of these articles. It would be a good idea to move the list onto wikipedia, where notes can be placed against entries where action is taken or which are quite appropriate to be kept short such as the disambiguation pages on the list. Davewild (talk) 18:01, 22 August 2009 (UTC)

• • • I see the list is on wiki already at User:LessHeard vanU/Mini stubs. Davewild (talk) 18:23, 22 August 2009 (UTC)
      • I am being ruthless, so if anyone sees a redlink and think they can find sufficient info to turn it into either a small article or a good stub (and don't have sysop flags) let me know and I will undelete. LessHeard vanU (talk) 19:26, 22 August 2009 (UTC)
        • Why are completely going against consensus? How about you don't delete them unless they fail afd? Prodding is pointless here as very few people likely have the stub watchlisted. Also, titles with an underscore are titles with spaces, so yes they are easily found in a search. I find it disturbing that you don't know that but are going around deciding which articles aren't fit for the encyclopedia. - ʄɭoʏɗiaɲ ^τ _¢ 15:33, 23 August 2009 (UTC)

A glance shows that LessHeard is already carrying out some rather poor speedy deletions from this list. The high failure rate at low volume is a good indicator that introducing a bot to increase the volume is a bad idea. Christopher Parham (talk) 15:30, 26 August 2009 (UTC)

deletes are here at the moment. Rich Farmbrough, 04:13, 30 August 2009 (UTC).

Date parameter

I did include a date parameter in {{Asbox}} at one point, in case it was ever thought useful to explore how long things remained as stubs, and perhaps triage them. It was taken out as scope creep. However if it would result in less stubs, in a good way, it can be put back in. Rich Farmbrough, 04:03, 30 August 2009 (UTC).

A better verb for "search on Wikipedia"

Every day I say or hear "Donno, check it up on wikipedia" or "even google it on wikipedia". A better verb needs to be coined as to wikipedia sounds silly. If it does, what is it? just an odd thought, but this could go a long way, so I am posting. --Squidonius (talk) 11:31, 24 August 2009 (UTC)

I sometimes use 'ask wikipedia', as in "I don't know, you could ask wikipedia". Personally I'm not a fan of awkward neologisms like 'google it' so if you do coin a new verb, I for one won't be in a hurry to adopt it. Mike1024 (t/c) 12:29, 24 August 2009 (UTC)

"Wikoogle"! Dendodge _T\^C 12:50, 24 August 2009 (UTC)

(ec) Just say "check Wikipedia" or some other variation. Using "Google" as a verb evolved from the near-ubiquity of the engine and its unique, short name (two syllables, not five like Wikipedia). If they had tried from the start to make "Google" a verb, it wouldn't have worked - these things need to happen naturally. It's usage as a verb is actually bad for the company, as the more common the term becomes in the daily lexicon, the more diluted their Trademark becomes, which could easily cause it to lose that status. All that being said, I do know plenty of people who say "Wiki it," which, while technically incorrect, tends to work out the way you want it to nicely. ~ Amory (user • talk • contribs) 12:54, 24 August 2009 (UTC)

I don't think it's that difficult to say "Look it up on Wikipedia", like you would say for any website. I don't think we need to just say "Wikipedia it", but go for it, if people know what you're talking about. hmwitht 15:00, 24 August 2009 (UTC)

"Wikipedia it" is a problem because it could mean more than one thing. Does that mean "read an article" or "re-write the article" or "spend the rest of the week trying to determine consensus on a single sentence"? WhatamIdoing (talk) 19:12, 24 August 2009 (UTC)

Woogle it. Wikit. Wikifact check. Wing it (from Bing it). Ahhhh, all of these suck. Maybe we would need to create a "wikisearch bar" so we could spread the the phrase wikisearch with some grounding in reality. (By "we", I mean "all of us except me and Mike1024". The brows of people who make up neologisms are decidedly higher than those of the people who use them.) Andrew Gradman ^talk/_WP:Hornbook 05:53, 25 August 2009 (UTC)

Perhaps there could be a new verb coined here - after, Google has become such a popular search engine that people now talk of "googling the web" rather than "surfing the Web". Perhaps we could talk about Wikipeding for a term? I would be against, however, saying "wikifying it" because there are a lot of other Wiki websites (such as Wikinews}other than Wikipedia.

ACEOREVIVED (talk) 06:23, 26 August 2009 (UTC)

For the term to have a chance of catching on, we'd have to associate it with our search toolbar -- e.g. as a substitute for the word "Go" in the search button. But when I imagine any of our current ideas being put in that position,

• Wiki it!
• Wikit!
• Wikisearch it!
• Wikipede it!
• WP it!
• Wikify it!
• Wikoogle it!
• Woogle it!
• Wing it!
• Waltavista it!
• Wahoo it!

I lose my appetite. Sorry Jimbo. Andrew Gradman ^talk/_WP:Hornbook 06:59, 26 August 2009 (UTC)

"Wik". Noisalt (talk) 11:33, 26 August 2009 (UTC)

No need to name it after a long-time banned user. It's like saying "Grawp it!", which, come to think of it, would sound good except for the, um, interesting connotations. :-) Graham87 16:11, 26 August 2009 (UTC)

I like "wiki it". - Peregrine Fisher (talk) (contribs) 16:16, 26 August 2009 (UTC)

I appreciate your liking of this term, but I stick with what I said above - I am a little unsure of "wiki it" myself, as there are other Wiki websites besides Wikipedia. How about Wikipede it, as AGradman suggested above? ACEOREVIVED (talk) 19:54, 26 August 2009 (UTC)

People, this whole discussion is out of place on this page, and pretty much useless anyway. We don't really get to pick. If a word arises, it will be by the usual, natural course of linguistic evolution -- someone says it and it catches on. Trying to direct that process is unlikely to be effective; it's more likely to just annoy people. --Trovatore (talk) 20:05, 26 August 2009 (UTC)

The task is to find an abbreviation of Wikipedia (5 syllables) that fits in "___ it" and is short verbally (not just in writing). Then we start using it. "Wiki it" slurs into weekeet. "Doubleyou-pee it" doesn't quite work. Check TFE? WiP? WP, pronounced as 'wip'? Whip it. Ha ha. From now on, in my head, I'll be pronouncing WP as Wip, and referring to Wikipedia as WiP. Join me! and soon we too may have an awesome nounverb.    M  

While I would never personally use any such verb, I never use "google it" either as I prefer ask.com, I would like to state I hope this thread continues and more chime in. Its fun, its interesting, it is what the Village Pump is about. Collaborate and do not let editors like Trevatore discourage or bully you into not posting and continuing. Wet-blankets abound and they need to be ignored, because if he or anyone else doesnt like this thread then they dont have to read it, we do not censor on wikipedia. Be merry and continue please. You are the heart of Wikipedia and jovial exchanges on here are a great distraction from the depressing arguments and petty bickering often found here. Collaboration should be encouraged, not stiffled. This is the perfect forum for this discussion, dont leave, I'll defend you to my last key-stroke.Camelbinky (talk) 01:29, 30 August 2009 (UTC)

Wikipate! Grandmasterka 03:26, 30 August 2009 (UTC)

In the same light that editors should never need to create articles about themselves if they think they're notable (as eventually someone will write an article about them anyway), I think trying to create a phrase for people to use is a fool's game. If society's consensus is that they enjoy saying "Wik it" or "Wing it", then that can be adopted as a neologism. Otherwise, I think we should just wait. Pushing for it almost seems like we're desperate to be "hip" and "in tune with society". Let's face it, we're on our own wavelength and not in tune with anything else. (That said, I heard that Wikipedia's natural frequency is similar to Middle C...) Greg Tyler ^{(t • c)} 21:58, 1 September 2009 (UTC)

I just noticed that Trovatore made the same point above and would like to clarify that the second half of my post is totally irrelevant, unfounded and spurious nonsense. Greg Tyler ^{(t • c)} 22:00, 1 September 2009 (UTC)

a general Conversation page?

Now I know that wikipedia isn't the place for "chatting", BUT I think a page just for talking and for getting to know all the editors, and other members, would be nice to have. As of now, everybody is sepperated. I also know that there is irc, but not everyone can use irc.Accdude92 (talk) (sign) 14:19, 25 August 2009 (UTC)

Wikipedia is not a social-networking site. We're here to build an encyclopedia. However, collaboration is encouraged. Try contacting an editor on his/her talk page. hmwitht 17:30, 25 August 2009 (UTC)

• mw:LiquidThreads should help, when and if it's ever deployed (see Andrew Garrett's blog for details on development). The kludginess of the current talk page system is what drives the long standing institutionalized anti-social behavior that Wikipedia presently espouses (as displayed in the reply above). I know exactly what you're saying, and personally agree with the sentiments, but until the technical restrictions are handled nothing is going to significantly change.
  — Ω (talk) 18:34, 25 August 2009 (UTC)
• For kicks, you could always try and have conversations with people in the WP:SANDBOX. Whilst WP isn't social networking, or a forum, I do sometimes feel that minor less-streamlined talk would help the atmosphere greatly. Generally when I try and do something humorous people just flip me off on here, which is a shame. It would certainly be cool to remedy that and let people have breathing space. I can handle being shot back at, but I'm sure it turns decent new editors away. Greg Tyler ^{(t • c)} 20:58, 25 August 2009 (UTC)

I agree we need a general "chat room", but maybe keep it for finding editors who have similar interests and collaborating with people instead of making it just another AOL/Yahoo!/Myspace/Facebook thing where people are. It would be nice to have a general conversation forum where you could say "Hey, this is what I've been working on, anyone out there have similar interests?" because often people are working on articles within a similar topic and never know about each other and may have insight and info the other may have been looking for. Also a great place for potential wikiprojects to be formed since suddenly a large group of people realize they have a large collection of articles they want to colloborate and organize better. If anti-social people like the one that replied up above dont want to get to know others then that is their choice, but they can not force their personal beliefs on the rest of Wikipedia.Camelbinky (talk) 22:21, 25 August 2009 (UTC)

Wouldn't it cause mass edit conflicts? Warrior4321 22:26, 25 August 2009 (UTC)

Only if it was designed poorly. If you're really concerned, you could bring your concerns up with Werdna (talk · contribs), since he's currently leading the development of LiquidThreads.22:41, 25 August 2009 (UTC)

IRC is the best way to socially interact (generally, on the Internet as well, in my opinion). I'm not sure why someone wouldn't be able to use IRC - it's easy enough to learn with some tutorial or you can always just use an applet if you have connection problems. -- Mentifisto 15:17, 26 August 2009 (UTC)

I agree with the sentiments about IRC, but even an official Wikipedia IRC channel isn't really on Wikipedia. Most people just won't bother to use something "offsite", for various reasons.
— V = I * R (talk to Ω) 03:50, 30 August 2009 (UTC)

True, IRC has to be offsite, but Wikipedia supports it and has a whole host of channels to talk on. Webchat.freenode.net makes it easily accessible, too. If you want to chat about Wikipedia, I would support IRC as the place to go. Besides, holding it on site would mean the servers had to hold masses and masses of pointless, spammy conversations. That seems like a waste when there's such valuable information held there too. Greg Tyler ^{(t • c)} 16:34, 31 August 2009 (UTC)

The other issue with IRC though is that it's chat. Personally, I just don't like chat... as for server load questions, that's really not something to be concerned with.
— V = I * R (talk to Ω) 13:37, 1 September 2009 (UTC)

Talknotice

Sometimes, we have important community announcements, but there is no optimal way to advertize them. We can use the watchlist notice, but IPs can't see it, and logged-in users don't always frequently check their watchlist, so it's not that efficient. There's also the sitenotice, which makes the message visible to all users on all pages. But some announcements are not intended for all readers or are not important enough to be put on the sitenotice, so we could use a talknotice working like the sitenotice and displayed only on talk pages, also dismissible. If we agree that such a thing is desirable, it'll be requested to the developers. Cenarium (talk) 00:26, 26 August 2009 (UTC)

I second this proposal; the decision of what to do at the end of the coming flagged revisions trial (as Cenarium notes elsewhere) is one such announcement where watchlists don't reach enough users but sitenotice reaches too many.--ragesoss (talk) 19:27, 30 August 2009 (UTC)

Sounds good to me. - Peregrine Fisher (talk) (contribs) 21:24, 31 August 2009 (UTC)

Could we just put namespace checking code into the sitenotice? Something like {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|...}} should do? — Dispenser 21:38, 31 August 2009 (UTC)

I tried on testwiki and the sitenotice couldn't handle it, if you put checking code in, it will be displayed on pages as parsed on the page Mediawiki:Sitenotice itself. I think it's for performance reasons. Cenarium (talk) 22:51, 31 August 2009 (UTC)

If we needed it right now we could use CSS or JS to hide on articles. — Dispenser 07:07, 1 September 2009 (UTC)

I filled Template:Bug requesting this. Cenarium (talk) 00:22, 1 September 2009 (UTC)

I love this idea. I think it might work better if the notice was displayed in all the secondary namespaces, and perhaps while editing. That way, anyone who isn't just a casual reader will see it. — Jake Wartenberg 04:14, 1 September 2009 (UTC)

Table of contents

Check out Maglev (transport). Its table of contents is floated over to the right, next the the main text, instead of above the rest of the text. I'm sure I'm not the only one who has been annoyed by having to scroll and scroll and scroll and scroll to get past the TOC. Maybe using the method found in "Maglev (transport)" in all articles, or at least all long ones, would make Wikipedia more usable overall. All it would require would be a TOCright or TOCleft in double curly brackets where the table of contents is.--(User:Star Trek enthusiast) (talk) 23:21, 27 August 2009 (UTC)

If you want to get to the bottom of the toc, just click the first "item" on the table of contents. It will take straight to the bottom of the toc, no scrolling required Warrior4321 00:35, 28 August 2009 (UTC)

It won't work in every article, since many articles include either an Infobox or a picture on the upper right of the article (where the TOC appears in the Maglev article). Any individual articles can be changed to display the table of contents on the right hand side by placing the {{TOCright}} template on the page.
— V = I * R (talk) 04:25, 28 August 2009 (UTC)

It's a lousy system for smaller screens. the (edit) link for section one is left hanging at the top of the TOC while section one actually starts underneath the TOC. NotAnIP83:149:66:11 (talk) 10:00, 31 August 2009 (UTC)

Table on the recent changes page

The content on the Recent changes page is very badly arranged. Could tha data be sorted in the table? --Janezdrilc (talk) 14:42, 28 August 2009 (UTC)

How would you prefer to see it? Who then was a gentleman? (talk) 19:27, 28 August 2009 (UTC)

The table could have about 6 columns: Column1 labels N or m, Column2 Title, then hour, counter of bytes, author and finally notes. --Janezdrilc (talk) 22:28, 30 August 2009 (UTC)

I don't understand. There are 7 columns already. Are you asking for more info, or less? Who then was a gentleman? (talk) 21:03, 31 August 2009 (UTC)

The OP may be interested in "Enhanced recent changes", which can be toggled in the "Recent changes" tab of Special:Preferences. Dendodge _T\^C 21:05, 31 August 2009 (UTC)

I meant a table with grid like this (for now there is just bulleted list):

(diff) (hist)	m	Hyderabadi haleem‎	01:58	(+3)	Sarabseth (talk | contribs)	→Preparation: grammar
(diff) (hist)	N	User:Darrenhusted/sandbox22‎	01:58	(-25)	Hooliganb (talk | contribs)	→Karl
(diff) (hist)		Wikipedia:WikiProject Macau/Popular pages‎	01:58	(+57)	Baxtersmalls (talk | contribs)	Popularity stats for WikiProject Macau
(diff) (hist)		Dexilla‎	01:58	(+456)	Mr.Z-bot (talk | contribs)	→Links: moved to subcategory, Replaced: Category:Tachinidae → Tachinidae-stub,, Removed: fly-stub, using AWB

I wonder whether you meant that you would like to see the Wikipedia "Recent Changes" feature become better categorised. At present, I agree that if you click on "Recent Changes", the only order seems to be the purely temporal order of the last x number of changes (which some Wikipedians might think is fair enough - after all, this is the name of this feature). However, perhaps there could be a way to categorise this feature, so people can find what they may wish to see in this feature more easily. ACEOREVIVED (talk) 20:02, 2 September 2009 (UTC)

Article wizard 2.0

Right, this has been on my back burner for a long time, and I've finally done it: based on the article for creation wizard, I've created Wikipedia:Article wizard2.0, (superceding the less helpful and less pretty and underused WP:Article wizard) as a generic wizard for registered users to create articles, including a simple template at the end. Comments please on the idea and execution; and on how we can promote it when it's ready. I've previously considered things like the MediaWiki page that produces the Search Results page (I forget the name now), that kind of thing. NB The one thing that the old Article wizard does that may be worth taking is emphasising the need to search for alternate spelling etc (see Wikipedia:Article wizard/other). But I'm tired and hungry now... Rd232 ^talk 14:13, 30 August 2009 (UTC)

I like it. I've posted feedback at Wikipedia talk:Article wizard2.0. hmwitht 14:34, 30 August 2009 (UTC)

It's an excellent start. I have a few comments, but have to gather my thoughts. Will respond in more retail at the talk page.--SPhilbrickT 17:53, 30 August 2009 (UTC)

Did not work at all, aborted without retry... and did not even say "thank you for your time, come next week...". Yes, I was honest, I really thought it's not ready for FA yet and will need some more work because the book says it's never too late and be bold and ... oh well. Seriously, I doubt that the user who do need help will actually go through all these hurdles. It's like a bank's call center computer that will drain your phone battery before even getting closer to whatever you needed... No, they'd better learn the rules the good old way. NVO (talk) 19:50, 30 August 2009 (UTC)

And the award for the least constructive comments on this topic so far goes to.... Seriously, a really good wizard of some sort would be a great asset. How about helping to create one? Or roll your own if you think this one is that bad a starting point. Rd232 ^talk 22:46, 30 August 2009 (UTC)

Wikipedia:Article_wizard2.0/subpage is broken (this is used in construction of a userspace proto-article)(instead of showing the name of the viewer, it shows the name of the last person to edit the page). Recommend replacing {{REVISIONUSER}} with Special:Mypage. --Thinboy00 @276, i.e. 05:37, 31 August 2009 (UTC)

done, thanks. Rd232 ^talk 18:57, 1 September 2009 (UTC)

An overview of Outstanding issues is now available at Wikipedia talk:Article wizard2.0#Outstanding issues. Thanks. Rd232 ^talk 18:57, 1 September 2009 (UTC)

Thank you for your work, I had thought about something like that and it could help some new users. Cenarium (talk) 17:11, 2 September 2009 (UTC)

Making our editing interface more clear and helpful

Hello all! You're probably aware that Wikipedia is reviewing its editing interface at the moment, the purpose being to make it easier to use. A lot of time and money is being spent, and this is all obviously a great idea. However, while the developers are still at work, I feel a massive improvement could be made relatively easily. The text that surrounds the edit box is confusing, unsightly, and not at all helpful. It is fragmented, and is clearly a product of years of tinkering by many different people. I feel we should take a step back and organise this important text in a much more presentable and informative way. Below are two images of the interface; before, and after my proposal.

The current editing interface, as seen by an anonymous user

Current proposal: two boxs – editing instructions for anons and newbies only at the top, warnings for all users at the bottom (incorporating the legally required text). Note also the text between the edit box and summary box.

Initial proposal: consolidate all the advice and warnings into a simple notice at the top.

As you can see, my proposal is simpler, clearer and prettier than the current situation. I'd also like that a similar one be created, identical except for the removal of the third 'create account' line, for users who are logged in. I'd also hope that its display could be turned off in user preferences. Anxietycello (talk) 15:48, 30 August 2009 (UTC)

Users with modest screen sizes will have to scroll a whole screen down to get to edit window. Why? NVO (talk) 19:32, 30 August 2009 (UTC)

It could be turned off by experienced users, so wouldn't affect you. It is mainly aimed at new and unregistered users. Anxietycello (talk) 21:12, 30 August 2009 (UTC)

First-time users will simply not find the edit window if it's in the bottom third of the screen or, worse, below the screen. They'd walk away. Usability basics. Of all the things that must be on the screen you've left out the most important. Edit window. NVO (talk) 18:19, 31 August 2009 (UTC)

That's highly speculative opinon, not usability basics. In my highly speculative opinion, I'd expect anon users to be more welcomed by the sentence "welcome to the eiting interface" than what they're currently faced with; the "you are not logged in" warning. See the second draft image below, in which the box takes up less vertical space. Anxietycello (talk) 19:53, 31 August 2009 (UTC)

Which is more than you can do with the current text, which takes up the same amount of room. Anxietycello (talk) 23:33, 30 August 2009 (UTC)

But you can easily hide it with the current setup. Also, you're missing the required text regarding the CC-BY-SA and GFDL. Anomie⚔ 00:54, 31 August 2009 (UTC)

Perhaps that highly technical text could be left as it is, but just after the save button (so that the edit here/summarise here text can be used). Anxietycello (talk) 12:52, 31 August 2009 (UTC)

I like this proposal, and you're absolutely right about the hodgepodge of the current interface. It needs developing but it's a good start. Obviously it would need to easily be disabled (and should mention in no uncertain terms that sources are required). —Noisalt (talk) 01:05, 31 August 2009 (UTC)

Perhaps there could be a [hide]/[show] symbol next to it, and an option to hide it outright in user preferences? I wouldn't say that Anomie's idea of 'easily' is the same as mine. Anxietycello (talk) 12:52, 31 August 2009 (UTC)

I can see how its clearer, by putting everything in once place. But I'm not sure its more helpful. This seems like cleaning your bedroom by putting everything on one shelf in the closet. Yes, the room is less cluttered, and you know where everything is, but that doesn't mean its a more usable system. Mr.Z-man 02:02, 31 August 2009 (UTC)

The main USP of my idea is that it has instructions on how to edit, for those within that market that we've so far been totally shunning. Anxietycello (talk) 12:52, 31 August 2009 (UTC)

But, it doesn't, really. It just takes what's already there, gets rid of a bunch of it, and puts the rest all in one place. Mr.Z-man 13:49, 31 August 2009 (UTC)

Just visually, there's too much whitespace on the page anyway. — V = I * R (talk to Ω) 14:03, 31 August 2009 (UTC)

Was that supposed to be a reply to me? Removing whitespace does not add instructions on how to edit. The proposed design does not have anything that the current interface doesn't, and I believe its missing things that the current interface has. Mr.Z-man 18:35, 31 August 2009 (UTC)

But it does! It has simple editing instructions - see the fourth, fifth and sixth bullet points on the top box. I have submitted a second draft, take a look at that, and I'm sure you'll be more satisfied. My proposal uses simple language in clear explainations. This may all seem moot to you, the experienced user, but I really feel for what those average joe types said in the video (File:Wiki feel stupid v2.ogv). Please take the time to read the recent Usability and Experience Study. My proposal is now this; the top box will display only to IP users (maybe also newly registered ones), and the bottom box will be perminantly visable to all. It's not just "thrown onto one shelf", it is a clear, coherant organisation of several highly important – fundamental, even – messages that must be taught to new users. Anxietycello (talk) 19:33, 31 August 2009 (UTC)

I agree that we need better instructions, but "Type in the big honking box full of text" is pretty much "Using a Computer 101". Anything that involves typing more than a few words typically involves typing in a textbox and almost every form everywhere on the internet has buttons. If anything, "Show changes" is the one that needs explanation. The problem is the complicated nature of wikitext, not people not being able to find the editbox or the "Save" button. Have you actually watched the video you keep linking to? Mr.Z-man 21:38, 31 August 2009 (UTC)

Yes I have, and the thought I went away with were that people were baffled by the information overload on reaching the edit page. Ok, I can see that the instruction box preceding the edit box isn't filling everyone with enthusiasm. Would you support the text shuffle following the edit box? Being more organised, perhaps it will be easier for people to understand the basic rules, etc.? Anxietycello (talk) 23:03, 31 August 2009 (UTC)

You should take this to the Usability initiative, since this is exactly what their working on right now... — V = I * R (talk to Ω)

Drawn up a new draft, adding the suggestions given. Header moved to the sides to shrink the box and remove whitespace. The code I used to make the text and boxes can be found at User:Anxietycello/Interface. Anxietycello (talk) 14:15, 31 August 2009 (UTC)

If you were reducing the amount of text, then I would support it. But you're not, so I don't. I would get rid of the "Welcome to the editing interface!" to start. Maybe if that was displayed only the first time, it might be OK (probably not), but it would become annoying fast. Having to dismiss it would also be annoying. Anyways, I would liek to see the six sentences reduced to about two. - Peregrine Fisher (talk) (contribs) 21:32, 31 August 2009 (UTC)

The top box would be displayed to anonymous users and newly registered accounts only. You would never see the top part, except when not signed in. Anxietycello (talk) 22:16, 31 August 2009 (UTC)

Well, then how about a shorter bottom box? - Peregrine Fisher (talk) (contribs) 22:24, 31 August 2009 (UTC)

Afraid not; the last four bullets are required by law in order for the website to operate, and the first two bullets are our own rules, which are fundamental to the operation of our encyclopedia. These things need to be said. Anyhow, as it stands, my box takes up less room (about 20% less) than the current situation and still says all the same things. Anxietycello (talk) 23:03, 31 August 2009 (UTC)

What's with the side boxes saying "Welcome"? Get rid of those. —Noisalt (talk) 00:21, 1 September 2009 (UTC)

Trimmed down alterations

A rearrangement of the text that follows the edit box. My proposed version (right) contains all the text of the current version (left), but presents it in a more logical and clear fashion. It also includes a request that all work submitted be neutral, verifiable and encylopedic - the core of our complex rulebook. Note how it also takes up less room.

Ok, I can see that the idea for the box I started with is not being happily accepted, for both aesthetic and practical reasons. Perhaps a simpler reform would be better recieved? Forget the top box for now, and lets focus on the mess of text below the edit box. As I said before, it is fragmented, and is clearly a product of years of tinkering by many different people. It is also a highly important peice of information, one that people should be able to easily read and understand. I therefore propose the above re-organisation. Any thoughts? Anxietycello (talk) 00:56, 1 September 2009 (UTC)

I can only support less text, but others may like more, I don't know. - Peregrine Fisher (talk) (contribs) 01:00, 1 September 2009 (UTC)

It takes up less vertical room than the current situation, and is only 168 words vs the current 183. While I do agree that it should be as short as possible, I also feel that all the text in my proposal is necessary. Is it so hard to scroll past? Surely you wouldn't need to very often? Anxietycello (talk) 01:23, 1 September 2009 (UTC)

I see what's going on. I didn't even see the "If you do not want your writing edited" stuff in the original because it's in a small font. I think I like the placement, but I'm not liking how it seems so much longer, even though it's shorter. - Peregrine Fisher (talk) (contribs) 01:30, 1 September 2009 (UTC)

See, yeah, it is as if having some text <small> and some text <big>, some bold and some bulleted makes things less visible, somehow more easy to gloss over. It's all important! Is that what you mean by it seeming longer now? Actually not so easy to ignore? Anxietycello (talk) 01:42, 1 September 2009 (UTC)

Well, I'm not convinced that it's all important, but yes, that is what I mean. - Peregrine Fisher (talk) (contribs) 02:21, 1 September 2009 (UTC)

Also, after 20000 edits, today is the first time I've ever bothered to read any of that. It's kinda like the ads on the side of a google search. I don't even see it. Can we just link to an explanatory page? - Peregrine Fisher (talk) (contribs) 02:27, 1 September 2009 (UTC)

Unfortunately, no, we can't. It has to be on that page as specified by the organisation that issues wikipedia with its licencing rights. See anomie's post above. 212.183.134.64 (talk) 02:38, 1 September 2009 (UTC)

That's not true. Lots of sites have a "Terms of Use" link, with all the info on a dedicated page. - Peregrine Fisher (talk) (contribs) 03:12, 1 September 2009 (UTC)

Lots of sites copywrite their text and operate for profit. We run under a very specifically free licence that has very specific rules. See here Anxietycello (talk) 14:48, 1 September 2009 (UTC)

I'm honestly not trying to be a stick in the mud here, but I'm really wondering why this discussion is occurring here rather then on the Usability study page. This is exactly what they are tasked with studying and improving, and they have the money, resources, time, and backing of the WMF to actually implement changes. Their also smack dab in the middle of evaluating exactly what this is attempting to address, so your suggestions and comments would be much more likely to have an impact there regardless.
— V = I * R (talk to Ω) 06:02, 1 September 2009 (UTC)

Ok, I've posted to Wikipedia Usability initiative here. -- Anxietycello (talk) 17:45, 2 September 2009 (UTC)

Hmm. Hadn't seen that meta page. It looks like we could trim it, but I'm not going to follow this discussion between wikis. Good luck. - Peregrine Fisher (talk) (contribs) 17:50, 2 September 2009 (UTC)

Strong support, the current state is really a cluttered mess. The symbol box should be right under the submit box (BTW, wikEd aleady rearranges the page in that way). The proposed text should actually be tweaked to be more concise and easier to read. Cacycle (talk) 21:20, 4 September 2009 (UTC)

Wikipedia should keep peace on the earth...

Hello!

Sorry for my limited knowledge of English, but I think that the images like these:

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:Anti_Armenia.png

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_France.svg

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_Israel.svg

should not be in Wikipedia nor Users pages of Wikipedians.

Wikipedia should be a place for knowledge not for rasistic expressions of some users.

Skrabbit (talk) 16:45, 31 August 2009 (UTC)

Those images are on azwikipedia, and there's nothing we can do about them here. Sorry. Majorly talk 16:47, 31 August 2009 (UTC)

For what it's worth, they're actually all hosted on Commons. You could take the matter up there at Commons:Commons:Deletion requests or similar, though I can't say I'm up on Commons policies. Cool3 (talk) 17:12, 31 August 2009 (UTC)

I will happily tag those images on both with whatever their equivalent of {{db-attack}} is. Those images can't be used for anything positive I imagine. - ʄɭoʏɗiaɲ ^τ _¢ 17:14, 31 August 2009 (UTC)

Except the first image. Majorly talk 17:15, 31 August 2009 (UTC)

Thing is, not everything in life is positive, especially in an encyclopedia about everything. Majorly talk 17:15, 31 August 2009 (UTC)

Yes, but there's a difference between showing something negative that happened or that exists, and promoting hate. The anti-Israel flag is quite clearly being used in a negative way by the userpages it is on. - ʄɭoʏɗiaɲ ^τ _¢ 17:42, 31 August 2009 (UTC)

In fact, all three seem to be used on userpages, although I can't tell you much more than that... ~ Amory (user • talk • contribs) 20:02, 31 August 2009 (UTC)

(od) Somewhat relevant to this thread: commons:Commons:Deletion_requests/Image:Anti_Poland.png which also discusses commons:Category:Anti_logos and its >220 member files. I don't know what to make of the discussion, but in any case there isn't anything to be done within the scope of this project. BTW, someone attempted to speedy the no-France image and the speedy tag was quickly removed by the author. Sswonk (talk) 21:35, 31 August 2009 (UTC)

I have nominated the Israel one. It is clearly part of a political agenda, as can be gathered from the pages it resides upon. Unlike the anti-france or anti-japan images, it regards a current and ongoing confrontation, and not a simple dislike towards the policies of a government. - ʄɭoʏɗiaɲ ^τ _¢ 19:16, 1 September 2009 (UTC)

Coloring Wikipedia text is a BAD idea

I read this article a couple of minutes ago:

http://www.wired.com/wiredscience/2009/08/wikitrust/

Please, please don't implement this. Not only would this make reading articles difficult with this turned on, but I can only see this causing a lot of issues with 'truthiness'. Editors with get into discussions and, rather than coming to a consensus, they will simply let the edit color speak for itself.

I understand Wikimedia Foundation's interest in making Wikipedia seem more accurate to the eye of the general and scientific communities, (Despite Wikipedia already being the most expansive and accurate general source in existence. ) but rainbow coloring pages doesn't seem like the way to do this. It's distracting, may actual reduce accuracy, and makes the page seem disjointed. Instead, let's extend the extension which shows page rankings under the page title and color codes page titles respectively to where it's used by default, as well as a link to a 'research safe' version of the article. (A recent history of the page with an equal or greater ranking.)

This method would not only ensure accuracy, but would also provide a standard, static-style encyclopedia which could be used reliably in a professional or academic context. 8bit (talk) 05:41, 1 September 2009 (UTC)

What's actually occurring is covered at Wikitrust. It appears to be a Gadget, not anything forced on every user by the base software.
— V = I * R (talk to Ω) 05:48, 1 September 2009 (UTC)

Even as a gadget, I'm still kind of against it, as it seems like something which would lead to truthiness, but either way, what of my alternate proposal as a default setup? Here's an image of approximately what I'm picturing:

8bit (talk) 06:04, 1 September 2009 (UTC)

I do wish we'd show regular readers our assessments. It's a valuable piece of info when trying to figure out how much to trust an article. - Peregrine Fisher (talk) (contribs) 06:09, 1 September 2009 (UTC)

@Peregrine Fisher: See s:Wikisource:Text quality. A system like this might work here, but on the other hand, I think we should strive to keep readership and editorial stuff separate whenever possible. Meh, just a thought... –Juliancolton | ^Talk 01:50, 5 September 2009 (UTC)

There's been a relatively extensive discussion on the wikien-l mailing list, feel free to read it as well if you like. This thing is gonna take a while to get here, if at all, and it's not going to be exactly as the sensationalist article writer makes it sound. The main aspect is how extensive a section of text has been edited, and the ability to link to the diff where it was added, something that is really cool. ~ Amory (user • talk • contribs) 12:31, 1 September 2009 (UTC)

Thanks, Amory. In this case, this does sound pretty cool as an editing tool, so long as it doesn't, say, give older users or users with more edits higher color priority or something, as that article seemed to imply. 8bit (talk) 18:09, 1 September 2009 (UTC)

8-bit, the colors don't appear by default and are accessible in a tab for those who want to use the tool (try with [2]). I think it's an innovative idea, but I'd like to see a demo on this Wikipedia. Eklipse (talk) 20:16, 1 September 2009 (UTC)

The one problem I see is that some good editors could acquire an "unstable" rating merely by getting involved in edit wars over style, or because they're commendably trying to clean up and neutralize an oft-vandalized page like Barack Obama or Sarah Palin, while mediocre editors can appear sounder than they are merely by the accident of doing most of their work on poor but uncontroversial pages where style and format don't come up as issues. —— Shakescene (talk) 20:43, 1 September 2009 (UTC)

I could swear I remember this idea being suggested years ago by some random user...He should sue! :) ----occono (talk) 00:31, 4 September 2009 (UTC)

Proposal to transform the Audit Subcommittee into an independent committee and grant new responsibilities

Please see here for details on this proposal and preliminary discussion. It's proposed to transform the Audit Subcommittee into an entity independent of the Arbitration Committee and grant several additional responsibilities regarding the overseeing of the checkuser and oversight permissions. Cenarium (talk) 22:40, 1 September 2009 (UTC)

The question of the independence has been reported for later consideration, and there is now a proposal to add new responsibilities to the Audit Subcommittee and regularly organize CU/OS elections, also added to CENT. Cenarium (talk) 03:45, 3 September 2009 (UTC)

Search box at the bottom of the page

Is there any way a Search box could be added to the bottom of every page? If one gets to the bottom of a page and is using Firefox, you have to grab the scroll bar and scroll all the way to the top of the page to get to the Search box. This isn't a problem in IE, which allows you to right click on the scroll bar and request to go to the top of the page, but you can't do that with Firefox. Or, maybe even just a link that says "Go to the top of the page". Who then was a gentleman? (talk) 20:57, 2 September 2009 (UTC)

Your keyboard doesn't have home or end buttons ? —TheDJ (talk • contribs) 21:11, 2 September 2009 (UTC)

See also Wikipedia:Keyboard shortcuts. Alt-Shift-f goes straight to the searchbox in Firefox on Windows or Linux. PrimeHunter (talk) 21:16, 2 September 2009 (UTC)

I never knew those would do that. Thanks. Who then was a gentleman? (talk) 21:19, 2 September 2009 (UTC)

On my Mac, I can also usually just hit Tab to force focus directly on the search field (though it'll get thrown off by other form elements, such as the options on the Watchlist or Contribs pages). EVula // talk // ☯ // 22:08, 2 September 2009 (UTC)

Unsourced tables

Is there a template for marking a table/chart/graph as unsourced (for example, something you can put underneath the image or the {{bar box}} that would say something along the lines of "the sources of this table/chart/graph are unclear"? I couldn't find any. And, if there isn't, does anyone think adding one would be useful? I could create one fairly easily. rʨanaɢ ^talk/_contribs 21:02, 2 September 2009 (UTC)

What's wrong with using the standard {{citation needed}}? hmwitht 21:20, 2 September 2009 (UTC)

I was thinking for marking a whole table, or an image, rather than specific facts within it. (The one that got me thinking about this was the bar chart at South Korea#Religion.) rʨanaɢ ^talk/_contribs 05:20, 3 September 2009 (UTC)

Well, I figured that you could either add it at the end of the table or after the sentence describing what's inside the table right above it. hmwitht 13:43, 3 September 2009 (UTC)

PovWatch

I'd like to propose turning on an extension called PovWatch. It allows users to push problematic pages on to the watchlists of other subscribing users. Often I see reports on ANI asking users to watchlist a certain page that is having problems, so I feel that this could really help in certain circumstances, specifically those in which there BLP issues. This functionality is completely optional - you won't be affected by it at all unless you choose to subscribe. — Jake Wartenberg 02:13, 3 September 2009 (UTC)

• Support as nominator. — Jake Wartenberg 02:13, 3 September 2009 (UTC)
• Support the idea, assuming the release is stable (which it seems to be). Should be a nice addition to what we've got at the moment like Wikipedia:Neutral point of view/Noticeboard. Ironholds (talk) 02:20, 3 September 2009 (UTC)
• Support what seems to be an excellent idea. Individual opt-in + Useful functionality = Good idea. NW (Talk) 02:30, 3 September 2009 (UTC)
• Support per those above. This should prove helpful to our efforts. Lara 03:13, 3 September 2009 (UTC)
• Support This can be easily done by simply getting people to add articles to a listing page, and watching recent changes. No need for any setup. YellowMonkey (bananabucket) 03:17, 3 September 2009 (UTC)

  The problem with using related changes is that most people check their watchlists quite often, and would not check a second page as often, if ever. — Jake Wartenberg 04:04, 3 September 2009 (UTC)

  I do. See the links on my own user page. As a matter of fact, I hardly ever use my own watchlist any more.
  — V = I * R (talk to Ω) 04:59, 3 September 2009 (UTC)

• Support Seems like an useful tool for those who are willing to use it. Does it highlight the pages "pushed" there by others though? Otherwise, we should first get such a feature added as many active users (and especially admins) usually have thousands of pages watchlisted and will not notice a new page if it's not highlighted in any way. Regards SoWhy 07:38, 3 September 2009 (UTC)
• 'Support: I wouldn't use it (I'm just not that sort of person) but I know others who would, and find it very useful indeed. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 11:11, 3 September 2009 (UTC)

Query. Based on the linked pages, I'm still not entirely clear about how this works, or how fine-grained the control is. Could someone post (or link to) a more detailed description of this extension? Specific questions I have include:

• Who will have access to this extension? Will editors with povwatch_user flags set receive the updates to their watchlists, while editors with povwatch_admin set be able to add pages? Who sets/removes povwatch_admin and povwatch_user flags? Will there be a way to exclude users or groups? Who will be able to see what pages are in the log? (Not to open a can of BEANS here, but I can see this as a delightful toy for a troll: "Hey, wanna make a nasty/libellous/obscene/privacy-violating/obnoxious message appear on every admin's watchlist? Just edit any of the pages added to povwatch...".)
• I get the impression that there's a single category of pages, and you either get all of them or none of them while you're subscribed; is that correct? Is this going to be a useful feature if it pushes to watchlists every controversial BLP, vandalism target, POV-pushing dispute, long-term fringe/pseudoscience battle, etc.
• Is the purpose of this features supposed to be used 'narrowly' — that is, just for BLPs? If so, do the proposers envision ultimately watchlisting essentially every BLP raised on a noticeboard, or will there be further screening? Will the usefulness of this tool be diluted rapidly once a few high-traffic BLPs make it on to everyone's watchlists? (Once Barack Obama and a few other high-profile names get watched, all the other, minor, third-tier BLPs will get lost in the noise of crowded watchlists. I'm concerned that even though those pages will be watchlisted, they won't actually be watched.)

I may come up with more later, but I'm not convinced at the moment that some of these problems won't cause more harm than good. TenOfAllTrades(talk) 13:35, 3 September 2009 (UTC)

• Support The example images have sysops putting pages on there, which seems like a good place to start, especially as any page that should be put on PovWatch is at the very least likely have some prior admin involvement or discussion. Any user dumb enough to vandalize on any of those pages will get to watch as they are simultaneously warned and blocked by 200 users and 20 sysops. These would quickly become some of the most-watched pages. I presume it would be used rather narrowly and for limited times - otherwise it would just become pointless. Suddenly everyone finds there is a dispute on a page, and in doing so they work it out, thus leading to the page being removed from the PovWatch list. It would kind of be a neat use of a new notification system. ~ Amory (user • talk • contribs) 14:30, 3 September 2009 (UTC)

Correct me if I am mistaken, but as I understand it there is no way to automatically unwatch pages that were added via the povwatch extension. Each subscriber has to manually remove pages from his watchlist, or it stays forever...? TenOfAllTrades(talk) 14:42, 3 September 2009 (UTC)

Oh, hmm. The way I interpreted it (based on this image) was that it was an all or nothing thing. You manually subscribe or unsubscribe to PovWatch, which puts or removes all those pages on/from your watchlist. You never watch the individual pages, just PovWatch. Kind of like a transclusion. ~ Amory (user • talk • contribs) 14:56, 3 September 2009 (UTC)

That's why we really need someone who knows how the extension works to offer a more detailed explanation before (and if) this goes live. SoWhy's point is also a good one. Through some pretty vigorous trimming, I have about fifteen hundred pages on my watchlist, and I know admins who have several thousand or more. If someone makes an edit without an edit summary (or with an innocuous one) and it pops up on my watchlist, it's not going to ring any warning bells in my mind unless I know that the article is on my watchlist for some important reason. TenOfAllTrades(talk) 15:10, 3 September 2009 (UTC)

I've installed this extension on a test wiki, and I can tell you that there is no way to remove a title once it has been pushed out. I think both the ability to do that and highlight pages watchlisted via the extension on user's watchlists would be huge improvements to the extension. That said, I feel it has plenty of potential as it is, and don't see the lack of these functionalities as major problems. — Jake Wartenberg 01:42, 5 September 2009 (UTC)

• Support, good idea. –Juliancolton | ^Talk 01:45, 5 September 2009 (UTC)
• Support I don't see a downside, this is a good idea. Chillum 02:59, 5 September 2009 (UTC)
• Support Great idea. Warrior4321 03:58, 5 September 2009 (UTC)
• Support - Nice idea. AdjustShift (talk) 15:22, 5 September 2009 (UTC)
• Support - good idea. I hate it when discussions go stale because the ones involved aren't watching it...--Unionhawk ^{Talk E-mail} 18:17, 5 September 2009 (UTC)
• Support. Yes, a useful improvement. Two thoughts: might it be possible to customize this, so that subscribers could select subject areas of POV pages to be selectively added to their watch lists, like the subject areas for RfCs? (In other words, could one ask to have POV issues about politics, or about math/science, selectively displayed on one's watchlist?) And, for that matter, could one have individual RfCs displayed directly on watchlists too (as opposed to watchlisting RfC lists in particular topics)? --Tryptofish (talk) 18:45, 6 September 2009 (UTC)

Bugzilla request filed. — Jake Wartenberg 22:37, 6 September 2009 (UTC)

• Rename since this will probably be used for things other than watching for non-NPOV editing. Remember how the abuse filter was renamed "edit filter"? --NE2 03:00, 7 September 2009 (UTC)
• Support I really like this idea. Ideally it can be expanded to other sorts of tags, such as COI and other warnings of high importance. Basket of Puppies 03:28, 7 September 2009 (UTC)
• Oppose Comment If I was a nasty, underhanded type of person, I would use this to destroy the watchlists of people I didn't like by trebling or quadrupling their size, filling them with entries (chosen specially to be objectionable to the victims concerned) which my enemies would then have to delete manually. Now forgive me for being a little paranoid but since there are many people out there who actually are nasty and underhanded, I can't support this unless I have an "opt-out" option on my own watchlist to prevent the less pleasant denizens of the Internet messing with it. I am pretty sure that Grawp would love this extension. -- Derek Ross | Talk 04:26, 7 September 2009 (UTC)

• This extension is opt-in only. Its interface will only be accessible to trusted users. — Jake Wartenberg 14:39, 7 September 2009 (UTC)

Can this thing be in it's own category like another namespace so they can bee seen apart? YellowMonkey (bananabucket) 05:30, 7 September 2009 (UTC)

I am not sure I understand your question. The extension's functionality will be located at Special:PovWatch. — Jake Wartenberg 14:39, 7 September 2009 (UTC)

Opt-in ? I like the sound of that. Okay then, I withdraw my opposition. However I would still note that underhanded people have in the past gained trusted status. So I would still prefer to have "opt-out" which I can apply to my own watchlist. -- Derek Ross | Talk 22:02, 7 September 2009 (UTC)

• Support It sounds like a helpful option. hmwitht 04:59, 7 September 2009 (UTC)
• Eh I guess I don't see the benefit. I watchlist things because I'm waiting for a change (where I remove the page from my watchlist later), I care about the page content, or I created it (or somehow have it watched automatically). Between those three causes I think I have about 1100 pages watched (with the plurality being user pages). Among the three causes I care the least about articles which become watched through some automated process. Obviously my assertion about the extension isn't enough to stop installation. I can just as easily not participate in the extension after it is installed. but I guess I'm just really fuzzy on the proposed benefit. Protonk (talk) 07:16, 7 September 2009 (UTC)

  That sums up my own POV perfectly (pun completely intentional!)
  — V = I * R (talk to Ω) 14:21, 7 September 2009 (UTC)

Pure vandalism edits

I was just thinking that it would be nice to be able to mark pure vandalism edits as such, in a pages edit history. The benefit to that could be the ability to hide such edits if the viewer desires to do so (in the same manner as minor edits and bot edits can be "hidden").
— V = I * R (talk to Ω) 07:31, 3 September 2009 (UTC)

Well, who would mark the edits as vandalism? Sysops are too few, but if everyone could do it it'd be abused. Maybe based off of the rollback ability? It seems like the kind of thing that could easily be misused. ~ Amory (user • talk • contribs) 13:57, 3 September 2009 (UTC)

Maybe a flag this edit button on the edit page that allows admins to take a look at it.Accdude92 (talk) (sign) 14:03, 3 September 2009 (UTC)

(edit conflict) That's just more work for the admins, and not worth it. Also, if it were just based on around rollback, you'd miss shady uses of it. hmwitht 14:05, 3 September 2009 (UTC)

Maybe a new group of people that only have registered user power, and the power to deal with vandals.Accdude92 (talk) (sign) 14:10, 3 September 2009 (UTC)

huh... I've seen this thought process expressed before here. I'm not really sure how this could be abused, anymore then the "minor edit" flag could be and is abused. Everyone always seems to want new features limited to some select group or another as well, which I don't understand either. Ah well.
— V = I * R (talk to Ω) 14:13, 3 September 2009 (UTC)

The minor edit argument is, for lack of a better word, minor. In this case, however, I can easily foresee t3h ePIC LULZ that would be achieved by marking edits as vandalism, especially those reverting vandalism. ~ Amory (user • talk • contribs) 17:24, 3 September 2009 (UTC)

I honestly don't see why... maybe I'm just not explaining what I envision correctly? All it would do is exactly what the minor flag does now, which is basically nothing. Whether or not a particular edit, or even a whole series of edits, is marked isn't actually going to have any real impact aside from possibly making the use of that flag pointless.

While we're on the subject though, It would also be nice to be able to edit the minor flag. I know that I've either forgotten to click it or accidentally clicked it several times, and I know that some people will either always or never use it, so being able to edit them ought to increase their utility in most instances. Being able to edit my own edit summaries would sure be nice, as well.
— V = I * R (talk to Ω) 17:34, 3 September 2009 (UTC)

The difference is that people can only mark their own edits as minor. Unless we expect that vandals to mark their own edits as vandalism, this would mean that people could mark other people's edits as vandalism. Mr.Z-man 17:38, 3 September 2009 (UTC)

In which case it would be entirely unnecessary makework and inconsistently applied. –xeno^talk 17:40, 3 September 2009 (UTC)

There's an easy "fix" (in quotes because I don't see the above as an issue, but I recognize that many do) to that issue: Tie the use of the "vandalism flag" to the undo feature. Since pure vandalism edits are almost always undone, this seems to me to be an obvious choice.
— V = I * R (talk to Ω) 17:59, 3 September 2009 (UTC)

What we should do is give everyone the ability to roll back (well, all autoconfirmed users, or everyone who asks for it - and strongly encourage people to ask for it - but take it away from the minority who abuse it). Then we could make rollback the standard recommended way of dealing with vandalism, and record rolled-back edits as vandalism edits. This could be used for all sorts of purposes - filtering watchlists and edit histories as suggested here, and automated tracking/warning/blocking of vandals (though obviously no automatic blocks just because a lot of your edits got rolled back). Obviously you'll get occasional misuse, as you do with every WP feature, but that shouldn't be a reason not to do it when it could provide such benefits.--Kotniski (talk) 17:48, 3 September 2009 (UTC)

Is there a problem that this solution purports to solve? –xeno^talk 17:55, 3 September 2009 (UTC)

Yea, I guess. I'm not real clear on exactly what rollback is (an easy multiple undo, is the best sense of it that I have). My only real worry there is that it's not as transparent. Everyone can see reverts in thee history, and I think that is the way it should be. I just want a way to hide them in the history when their in the way, is all.
— V = I * R (talk to Ω) 17:59, 3 September 2009 (UTC)

Kotniski's suggestion wouldn't work. Native rollback is used for many other things other than vandalism (bots gone wrong for example, and some people use various edit-summary-changing scripts to use rollback in place of undo). I think that it's too complicated to do what you want to do. Even if it were tied to a rollback, then shouldn't the rolling back edit be hideable as well? –xeno^talk 18:06, 3 September 2009 (UTC)

(edit conflict) Yea, I think so. To be clear, all I want, and all I think is ever needed, is a dumb flag. Even if anyone could edit the flags of anyone else's posts, it wouldn't really be harmful. It may make using the flag on the edit history of that page somewhat pointless, but that's not really a big deal. That's also the reason why I honestly don't see is as an abuse issue. There's just no exposure provided by it, which is what vandals and trolls always really want.
— V = I * R (talk to Ω) 18:18, 3 September 2009 (UTC)

(1) Rollbacks are just as visible in the history as undos. (2) If there were an option to hide rolled-back edits, then presumably it would include hiding the rolling-back edits (this is obviously something for the developers to think about rather than us). (3) Obviously the software could detect whether the rolled-back edit was made by a bot, and adjust accordingly. (4) If someone changes the edit summary, the software could easily detect that. (5) It's not complicated - it would make things much simpler (well, it would give developers a means of making things much simpler for editors - vandals could be warned/reported automatically, so we wouldn't have to worry about that any more). (6) A few trifling concerns is no reason to say right from the outset "this suggestion wouldn't work".--Kotniski (talk) 18:15, 3 September 2009 (UTC)

eeech... "vandals could be warned/reported automatically" now I think we're getting in to real potential abuse area. I could just imagine some schmuck tagging 100 people and causing an uproar before being blocked.
— V = I * R (talk to Ω) 18:21, 3 September 2009 (UTC)

This introduces many layers of complicated interactions, with only very minor benefits. –xeno^talk 18:23, 3 September 2009 (UTC)

I think the potential benefits far outweigh the alleged complexity (it's not complexity anyway, it's - shock, horror - "something we're not used to"). And the "uproar" in the case described would be minor - let him do that, it's better than having him vandalize 50 articles (and we're talking autoconfirmed accounts here, not random IPs, so it's not going to happen every day).--Kotniski (talk) 12:55, 4 September 2009 (UTC)

I was talking about the complexity of changes we would be asking the Mediawiki developers to make. –xeno^talk 14:39, 5 September 2009 (UTC)

I have to admit that this thought crossed my mind as well. That's actually one of the benefits that I see to what I'm actually proposing here though, in that implementing the flag idea should be fairly straightforward. It's essentially just a copy of the existing functionality for minor flags, along with the addition of a bit field in the database table. It's entirely possible that there's some underlying problem with doing that, and I would be perfectly willing to accept it if that turns out to be the case, but somehow I doubt it. The rollback thing, on the other hand... that's a whole different ball of wax.
— V = I * R (talk to Ω) 15:05, 5 September 2009 (UTC)

It's not really, though, is it, it's just implementing your suggestion using existing functionality (the rollback button could be the vandalism flag). The only problem is overcoming the WP superstition that rollback is an important privilege that needs to be guarded. Anyway, I'll vote for your bug report.--Kotniski (talk) 16:28, 5 September 2009 (UTC)

Doesn't the rollback tool already use tags to mark some rollbacks as "vandalism"? Personally, I think that access to the rollback and admin tools ought to be fairly automatic, but that's a whole other issue. My main thinking in bringing this up was just to add a relatively simple, and non-controversial, means of marking and "hiding" those edits ("Hiding" as in the ability to mask them out just like minor edits or bot edits can be currently). I can see where you're going, and I don't really disagree, but I just don't see that type of proposal going anywhere "politically". I think that this at least has a chance, and could even prove to be statistically useful down the road.
— V = I * R (talk to Ω) 16:56, 5 September 2009 (UTC)

Enhancement request filled

Anyway yea, the proposal is to just add a simple flag, exactly like the minor flag, which we could add to posts. The simple implementation is to make it's use available when using the undo feature (to mark the edit being undone). The more involved implementation would be to ask to have the tick box on the edit page (I'm not sure what the correct name for this would be, but the version that you see when you click on the date link of an edit from the page history). That page could actually include check boxes for both, "minor" and "vandalism", and if it's your own edit, it could allow you to edit the summary as well.
— V = I * R (talk to Ω) 18:33, 3 September 2009 (UTC)

Yes, independently of the above more far-reaching idea based on popularizing rollback, I think this is a good idea. --Kotniski (talk) 12:55, 4 September 2009 (UTC)

Bug#: 20510 filed for the "vandalism flag", specifically. Maybe it'll get somewhere, maybe not... It's a small thing, but I think it would be nice.
— V = I * R (talk to Ω) 05:25, 5 September 2009 (UTC)

another possible complication

I've seen "RVV" or "vandalism" in many edit summaries, when in fact that what was not what the reverted entry was. Sometimes it's pure disagreement or difference of opinion; sometimes the reverted editor was going by a different unit or spelling convention; and sometimes that editor had a different source of facts (sometimes more recent, sometimes older, sometimes just different). Often what seems obvious to the average reader (and thus the most recent editor-but-one) has been shown over extended discussion on a Talk Page to be inaccurate or imprecise, but that doesn't mean that the reverted edit wasn't made in good faith. The reversion might well be justified, but what was reverted wasn't necessarily vandalism. —— Shakescene (talk) 20:03, 3 September 2009 (UTC)

True, and I've seen the same issues myself. I simply don't see how that is a significant problem which this proposal needs to address. I see people "misuse" the minor edit flag constantly as well, but that's not a reason (to me, at least) to remove it.
— V = I * R (talk to Ω) 03:23, 4 September 2009 (UTC)

Quite. We mustn't throw out every suggestion for new functionality just because someone sometime might abuse or misuse it.--Kotniski (talk) 12:55, 4 September 2009 (UTC)

It might be a good idea to implement a "vandalism reversion" flag, akin to the "minor edit" flag. Then again, the risk of abuse (which would inevitably lead to bad faith assumptions and large disputes) is concerning... –Juliancolton | ^Talk 01:44, 5 September 2009 (UTC)

That's a very fine and interesting point. Maybe if there were a V flag, editors would stop lazily or carelessly using "RVV" as an-all-purpose abbreviation for "revert" and just hit the "vandalism" flag when it really seems to be vandalism. On the other hand, it's equally easy to see how a simple check-box might aggravate the problem. —— Shakescene (talk) 04:04, 7 September 2009 (UTC)

Editable history

We talked about this a little bit, above. There should be a method to edit the minor flag and at least your own edit summaries. The easiest way that I can think of to implement that would be to add them as editable fields to the old revision view of a page. That page is missing the edit summary anyway, so this is technically two enhancements. Bug 20511
— V = I * R (talk to Ω) 05:31, 5 September 2009 (UTC)

Something like that has already been proposed (Wikipedia:Village pump (proposals)/Archive 30#Being able to edit your edit summaries, Wikipedia:Village pump_(technical)/Archive 44#Edit summary grace period?, bugzilla:13937). In short, something like that would be somewhat useful in some rather rare cases and very confusing in some other rare cases (for example, when someone has already seen the previous edit summary). Thus some precautions would be necessary... On the other hand, a script or a gadget that would allow one to confirm the edit summary to prevent the editor from saving the page accidentally (proposed in Wikipedia:Village pump (proposals)/Archive 30#Being able to edit your edit summaries by Rjd0060) does look like something that might be helpful sometimes... --Martynas Patasius (talk) 15:24, 5 September 2009 (UTC)

Ah, thanks for pointing out the other proposals. I searched high and low for them, but I must have been using the wrong keywords (I suspect that "edit edit" and the like is a real issue for search engines, here). Anyway yea, I see a lot of nay-saying, but I don't see any real criticism of the idea/proposals (I'm obviously for the idea though...). The gadget implementation/functionality already exists, but that is not even close to a complete solution.
— V = I * R (talk to Ω) 17:03, 5 September 2009 (UTC)

Organ harvesting poll

A poll has been created on whether Reports of organ harvesting from Falun Gong practitioners in China‎ is a standalone topic, or should it be merged to Organ harvesting in the People's Republic of China? Please go to Talk:Organ harvesting in the People's Republic of China/FG poll. Ohconfucius (talk) 14:04, 3 September 2009 (UTC)

I fixed that link for you. UltraExactZZ ^Claims ~ Evidence 18:05, 3 September 2009 (UTC)

Request move discussion {{otheruses4}} → {{about}}

I am requesting discussion on moving the common hatnote template {{otheruses4}} → {{about}} (or → {{otheruses}}) because the current name (with an arbitrary 4) is hard to remember and esoteric. I have started the discussion at Template_talk:Otheruses4#Request_move_discussion. If you are interested, please come to discuss whether the template should be moved and if so, to where. Thanks, -Sligocki (talk) 20:43, 3 September 2009 (UTC)

Deletion discussions with "No Consensus" as a result

There are some articles which were nominated for deletion and the reult is "No consensus". Should we then be given information about the default position being keepig the article? ACEOREVIVED (talk) 21:28, 3 September 2009 (UTC)

What information are you looking for? — The Hand That Feeds You:^Bite 22:51, 3 September 2009 (UTC)

I can give an example - if you look at the article on Bob Taggart and go to its talk page, you can see that the article was nominated for deletion in August 2009; the tag on the talk page just says "The result of the discussion was no consensus". I guess that I am really saying that this tag needs modification, so that it should say something to the effect of "The result of the discussion was no consensus, and therefore the article is being kept, as that is the default position". ACEOREVIVED (talk) 23:09, 3 September 2009 (UTC)

Isn't that sort of implied by how the article wasn't deleted? Mr.Z-man 23:32, 3 September 2009 (UTC)

[edit conflict] ¶ I think that, in general (and not just with –fD discussions), when no clear consensus for a specific, articulable change can be gathered, the bias is in favor of stability and thus no action. [For one thing, to echo Eugene V. Debs' refusal to lead workers to the Promised Land, if something can change easily one way without a firm consensus, it could just as easily change back in the other direction, resulting in ping-pong or a magnified but legitimate variation of edit warring.] There are many things that I, like any editor, might like to change, but the onus is on the innovators rather than (despite WP:Ownership) upon those who prefer to keep the status quo ante. But that's probably a philosophical point when you're asking something more practical. —— Shakescene (talk) 23:46, 3 September 2009 (UTC)

The template ({{oldafdfull}}) uses the "result=" parameter, with result being what we want, so we couldn't change the existing ones without massive edits. They are linked in the form {{oldafdfull|page=<pagename>|date=<date of nom>|result='''keep'''}} below the afd tag for easily copy/pasting them to the talk page. So it would be too much cost for a little benefit in any way we proceed. Cenarium (talk) 00:01, 4 September 2009 (UTC)

We could, I think (if I understand correctly, not guaranteed), add some jiggery-pokery to the template to display something different from the input parameter ( {{#ifeq:{{{result}}}|'''No consensus'''|'''No consensus[1]'''|{{{result|}}}}} ?) which would probably add some overhead but which would ultimate be one edit. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 19:06, 4 September 2009 (UTC)

Thank you Jarry 1250, that is the type of thing I had in mind. A template such as "No consensus - result = keep article (default position)" would be more informative than what there is at present, and would not require major editorial changes. ACEOREVIVED (talk) 23:13, 4 September 2009 (UTC)

I've done a quick mockup to test that the theory works at Template:Oldafdfull/sandbox - but everything about it can be changed. Hope that helps, - Jarry1250 ^{[ In the UK? Sign the petition! ]} 18:12, 5 September 2009 (UTC)

I can see how this could be helpful for clarity. But I don't think the wording is right. Saying that our default position is 'keep' sounds too much like an official standing. As said above, "no consensus" just means to leave it be. A closure as "keep" can be held as future evidence that the article is worthwhile, whereas a "no consensus" means that no agreement was reached, and the article could still reasonably be deleted or kept. Perhaps the text should state something more like '* This technically equates to a "keep" consensus, but shouldn't be considered as such.' Thus it states that the result isn't to keep the article, but physically the article is in the same state as it would be should a "keep" result appear.

I'm aware that that wasn't explained brilliantly. But do people see what I'm getting at? Greg Tyler ^{(t • c)} 22:17, 7 September 2009 (UTC)

Link to the introduction instead of the community portal in the sidebar

Please see and comment here on this proposal. Thanks, Cenarium (talk) 23:03, 3 September 2009 (UTC)

Proposal: Always indicate length of block

(I am not sure if this is the right place for this proposal. I looked around but didn't find anywhere better...)

I have noticed that some "you've been blocked" messages that admins add to the talk page of a blocked user do not include the duration of the block. The length of the block can be found elsewhere, but it seems like a fundamental characteristic of the block and should be included in the blocked user's talk page entry. Is there some reason why it's not included? If not, I propose that the length of block always be included in such messages, and block templates be adjusted (docs and otherwise) to indicate the requirement. Alternatively, perhaps there is some way for the Wiki software to detect the length of the current block and the templates could be modified to use that mechanism and thus avoid the need for the admin to specify the information manually.

FYI, here is one recent example. (I am not criticizing the admin involved in that edit.) Here's is another example by a different admin who apparently added the length of the block by adding text that wasn't part of the template. — John Cardinal (talk) 15:49, 4 September 2009 (UTC)

I think you are a little confused with your diffs - the first one you give is for a second block notice that does contain the length. The second one is not an admin adding the block length to another admin's notice, but rather a single admin placing a block notice with a note about the length after it. In any event your core point remains - block notices should absoultely specify the length of the block being made. This should probably be mentioned in WP:BLOCK. Shereth 16:00, 4 September 2009 (UTC)

Hmm... I did post the wrong URL for the first block--sorry about that. For the second, I didn't explain it well. I was indicating that the admin was different from the first URL. My point was that the length of the block seemed to be added outside of the block template the admin used. In other words, the admin keyed something like this:

{{someblocktemplate}} Blocked for 1 week

... as opposed to specifying the length of the block as a parameter to the template. — John Cardinal (talk) 18:17, 4 September 2009 (UTC)

Some admins don't use a template at all... –xeno^talk 18:19, 4 September 2009 (UTC)

Sometimes I don't want the vandal to know how long they've been blocked for. I don't want them coming back. EVula // talk // ☯ // 19:30, 4 September 2009 (UTC)

The message the blocked person sees when they try to edit shows the length of the block already, the talk page note is just for other people looking at the block, who can also look at the block log. MBisanz ^talk 20:05, 4 September 2009 (UTC)

Agreed, I don't think this is a big issue. –Juliancolton | ^Talk 01:41, 5 September 2009 (UTC)

I wasn't concerned about the blockee; this is about the other interested parties. If the message is going to be there at all, why not have it be complete? — John Cardinal (talk) 02:50, 5 September 2009 (UTC)

I often leave out the length particularly with IPs so that they don't just mark their calender and come back. Chillum 02:57, 5 September 2009 (UTC)

That doesn't seem like good logic to me. If we don't want them to come back, we should make the block longer or permanent. In addition, if they try to edit they are told the length of the block (I've never seen this—never been blocked—but someone described it above). If the length is not a secret, then it's not a secret. — John Cardinal (talk) 03:14, 5 September 2009 (UTC)

Just because something is not a secret doesn't mean we should go out of our way to broadcast it. And for IPs, lengthening the block sometimes isn't an option. The block duration may be shown when they try to edit, but there's also the very real possibility that they may not notice it, become discouraged by having the fun ruined, and simply go away. EVula // talk // ☯ // 04:14, 5 September 2009 (UTC)

IPs sometimes change owners, sometimes they do not. I don't do a longer or indefinite block to avoid collateral damage. Chillum 03:19, 5 September 2009 (UTC)

I have to admit that the idea behind "sometimes I don't want them to know" makes me uncomfortable. I understand completely where that's coming from, I've been there myself, and there is no means to actually keep it secret, but... Anyway, this doesn't really bother me personally, but I wanted to mention my thoughts there.
— V = I * R (talk to Ω) 04:37, 5 September 2009 (UTC)

Whenever I block someone, I add the length of the block in the template and in the message. It's a matter of courtesy. The blocked person has a right to know the duration of the block. JoJan (talk) 14:34, 5 September 2009 (UTC)

(outdent) The current situation doesn't seem rational to me: any blocked user who tries to edit is told they are blocked and for how long, yet some admins don't put the length of the block in the talk page entry where it's useful to other editors. It doesn't make sense to me that omitting the length of the block helps avoid collateral damage, as uninvolved editors who happen to use the same IP and try to edit will see the block info. Moreover, it's unlikely they'll see the talk page entry unless they are veterans, in which case they'll know how to find the block info. I thought through some other use cases and I don't think there are any where hiding the length of the block has any real benefit.

I can't accept arguments based on users not noticing information that we deliberately put into the message. It's irrational: if we put the info in the message, we intend the user to see it. If we don't want them to see it, we should leave it out. If we want some users to see it, and others not, well... how does it feel to want? Once we display the message, we can't control which readers notice and which ones don't.

On the other hand, the info is available and my proposal was only intended to make it more convenient to see it. There's clearly not consensus and while I don't agree, it's not a big deal. Thanks for considering this proposal. — John Cardinal (talk) 15:06, 5 September 2009 (UTC)

As nonsensical as the current situation may seem to you, I'm just as puzzled at your insistence that not including the block duration on the talk page is some actual issue. Who needs to see the block durations the most? Admins (useful in gauging how long to block a repeat offender). Sysops can see that from the Special:BlockIP page, they don't need to refer to the talk page (at least, they should be doing that). Regular editors most likely don't care, and if they do, they can always click on the very readily apparent Block Log link on Special:Contributions. The argument can be made that a user's contribs are a better gauge of their actions than their talk page (where warnings and block notices can easily be removed); in reality, any user who is only looking at a talk page without checking contribs or the block log when dealing with a suspected vandal (account or IP) is doing a poor job of investigating. As has already been pointed out, the user that's been blocked doesn't need it on their talk page either.
As I can only think of three parties that might reference a block's duration, and have illustrated how it's a non-issue for all three parties, I'm wondering what the exact problem is. EVula // talk // ☯ // 19:51, 5 September 2009 (UTC)

I agree with EVula, I don't put the block time because people should be referring to the block log. An admin can make a mistake in the talk page message, a vandal can change the message, two admins can block simultaneously making the block length message incorrect. Maybe you want to see the block log at the bottom of the talk page if a user is currently blocked? Possibly a good idea.--Commander Keane (talk) 11:11, 6 September 2009 (UTC)

Add more html tags... especially abbr and acronym

wikipedia has <code></code> <u></u> <b></b> <i></i> <s> </s> but is missing very useful tags such as CSS or <acronym title="North Atlantic Treaty Organisation">NATO</acronym> which would really help with the readability of articles. This would make it so users wouldn't have to scroll up to the top of the page to remember what an acronym stood for. Personally, I think all acronyms/abbreviations should use this tag. We could start by just enabling the feature. Dragonsshadows (talk) 16:08, 4 September 2009 (UTC)

Well, I am in no way against this per se, but to remind eveyone, all initialisms should be spelt out the first time they're used, which might devalue the suggestion. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 16:10, 4 September 2009 (UTC)

I tend to spell them out at least once per section, personally. Of course, the really well known abbreviations (NATO, NASA, US, etc...) don't normally need to be spelled out at all, but that's a whole different story.

You can acomplish the goal here with linking, by the way (as long as there is a redirect, at least). For example: CSS shows "Cascading Style Sheets" when you hover over the link.
— V = I * R (talk to Ω) 16:27, 4 September 2009 (UTC)

It's worth pointing out that the current HTML 5 proposal is leaning toward deprecating both <abbr> and <acronym>, because the suggested use – marking up a string once so that specialized tools get a hint about how to treat the same string elswhere – doesn't really fit the HTML model. It's probably not a good idea to add tags that will have to be ignored by most clients in the future. — Gavia immer (talk) 18:34, 4 September 2009 (UTC)

<acronym> is to be obsolete in HTML 5, but <abbr> is listed as what should be used in its place^[3] and it says that they should be treated the same^[4]. Mr.Z-man 16:34, 5 September 2009 (UTC)

• The following templates may be of interest:
  • {{tooltip}}, which uses the title attribute, available on most (X)HTML elements: CSS 2
  • {{abbr}}, which uses the abbr attribute: IMF , and {{abbrlink}} which wikilinks the term: IMF Tooltip International Monetary Fund
     –Whitehorse1 16:55, 5 September 2009 (UTC)

Editing tools

Any time I want to edit, I have to wait while all those cutesy icons load (not all of which will function on the computer I use). when they are finally loaded, the screen jumps, and I usually have to scroll to get to the top of the section or article to be edited. It is an awkward mess. Is there any way I can turn off all this fancy stuff that makes Wik compete with MSW for bloat? Kdammers (talk) 09:35, 5 September 2009 (UTC)

It's in your preferences, amazingly enough. Algebraist 12:47, 5 September 2009 (UTC)

Editing tab -> untick "Show edit toolbar (requires JavaScript)" I would think. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 12:52, 5 September 2009 (UTC)

Finding out when an article was created in the "History" of an article

At present, if you go to the "History" of an article, it is not easy to find when an article was first created if it has had a long history - for example, the article Criticism of Wikipedia has been in existence since at least August 2005 (I gave up back-tracking after then). Please forgive me if you are more informed about the mechanics of Wikipedia than me, as there may be an ansewr to this one already - is there a simple way to find out the date when an article was first created? If I am making a proposal here, it is to have something like a little note saying when an article was first created in the "History" of the article. ACEOREVIVED (talk) 20:42, 5 September 2009 (UTC)

There certainly is. Click History, scroll down, and click "earliest". It's underneath the 'Compare selected revisions' button. The creation date is the first entry at the bottom of that page. –Whitehorse1 21:01, 5 September 2009 (UTC)

^ That. By the way, I've replied re Oldafdfull up ^^^ there somewhere. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 21:13, 5 September 2009 (UTC)

It's not even necessary to scroll down to click the "earliest" button, it's at the top too. -- œ^™ 02:18, 6 September 2009 (UTC)

Photo tags

Wikipedia will benefit greatly from photo tags. When looking for a picture of a specific person, every article on a person, place or thing can have itself tagged on specific pictures. Like that, when looking for a picture of "Barack Obama", all the pictures tagged with his name will appear. This will make editing much more convenient. Raaggio 03:07, 6 September 2009 (UTC)

Search Commons. Categories there are used to similar effect (e.g. category:Barack Obama --Cybercobra (talk) 03:37, 6 September 2009 (UTC)

Categories aren't the same. And not all pictures are in Wikimedia Commons. Raaggio 12:31, 6 September 2009 (UTC)

Categories are supposed to be what you're looking for, though.
— V = I * R (talk to Ω) 13:27, 6 September 2009 (UTC)

Mind maps

I think it would be great to use the "what links here" and "what links from here" information for creating mind maps. The reader would only need to specify in how many "levels of links" he or she is interested. For example, I would like to see all "what links here" and up to two levels of articles linked from the current page, i.e. a map with the current page in the midle, pages linking to the current page, pages linked to from the current page ("at level 1") and pages linked to from these ("at level 2"). Anša (talk) 12:22, 6 September 2009 (UTC)

Oh, oh oh! Can we play the 7 degrees from Kevin Bacon game with his article using this proposal?! "How many articles can you use to link Kevin Bacon with gravity?" It sounds like a fun game to me.Camelbinky (talk) 17:58, 6 September 2009 (UTC)

I seem to remember something, probably an off-site tool, that allows you to do just that. ♫ Melodia Chaconne ♫ (talk) 18:08, 6 September 2009 (UTC)

There's the six degrees of Wikipedia game (google it), but it's a bit out of date and different from this, AFAIK. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 18:09, 6 September 2009 (UTC)

Cool, I like the Six degrees of Wikipedia project. However, my motivation is to get a "mind map", i.e. a picture showing connections between concepts. The link structure should reflect this to a large degree, although the average distance from one article to any other being around 4.5 (as to March, 2008) makes it clear that this works only on the first few levels. Still, it could work nicely in the more specialized areas, such as links among articles on special topics in the natural sciences. Maybe, mindmaps could be constructed from some more elaborate list of wiki articles, such as the division into categories. Anša (talk) 09:44, 7 September 2009 (UTC)

Would this help identify WP:Orphans ? —— Shakescene (talk) 10:19, 7 September 2009 (UTC)

Invitation to edit: Orange links

Note: This is a proposal I created on the Strategic Planning wiki. Since it is primarily relevant to the English Wikipedia I decided to post it here to get some feedback. GeometryGirl (talk) 21:08, 6 September 2009 (UTC)

Observations and background

Wikipedia currently has two types of links: blue links (for existing articles) and red links (for nonexistent articles). The major benefits of blue links are navigational. As for red links, it has been shown that they stimulate article production. Indeed, Wikipedians want to "turn all links blue" and this has been, and still is, a major bolster to article production, especially for small Wikipedias. For larger Wikipedias, the focus is changing from article production to article amelioration, and the disappearing red links are losing their former impact.

Details of proposal

Description

As an addition to the positive red links, orange links (or links of some other descriptive colour) could attest for articles in poor shape. For example, all stubs and start class articles could be linked to by orange links. Various implementations are possible, from offering orange links to every user by default, to limiting them to signed-in users.

Potential benefits

The potential benefits are similar to red links in prompting users to produce content. Orange links would encourage editors to expand and improve articles, as a support to the already existing red links that encourage editors to start articles. In effect, similarly to red links, orange links would drive editors to where work is needed.

Extensions

The idea can be extended to different classes of articles. For example, we could have all featured and good articles be linked to by green links. This may incite viewers to read articles they would not have otherwise read, so as to drive users to quality content.

Choice of colours

The similarity between the orange and red colours is significant since stubs and start class articles are almost nonexistent, containing barely any information. As for the green colour for good and featured articles, it would reflect upon the green logo already used for good articles. A careful choice of colour should be made to minimize potential confusion for colour blind people.

References

• Erik Moeller's talk from the 2009 Wikimania in Buenos Aires. Specifically, slide 6 of his presentation Problem recognition: in the past there were red links, and slide 20, step 2 Solution: create new micro-opportunities.
• Diomidis Spinellis and Panagiotis Louridas (2008). The collaborative organization of knowledge. In Communications of the ACM, August 2008, Vol 51, No 8, Pages 68 - 73. They noted that "Most new articles are created shortly after a corresponding reference to them is entered into the system."

Discussion

This is an interesting and ingenious suggestion, and you have obviously thought out this proposal well.However, I am not too sure it would work. Many Wikipedians might prefer the simple task of having any article, no matter how small, linked by a blue link and red links for articles that are not in Wikipedia - to implement this change would mean much editing to Wikipedia. Perhaps it would be easier to reserve orange articles for those articles where, if you type a word in the box on the left, you get redirected elsewhere, i.e. where there is not an article with verbatim that name in Wikipedia, but there is an article on a similar topic. If we had the orange article as a marker of quality of an article, it could lead to edit wars on whether articles should be linked by red or orange links. ACEOREVIVED (talk) 23:45, 6 September 2009 (UTC)

Thank you for the reply. Why do you say that "to implement this change would mean much editing to Wikipedia"? Isn't that the goal? GeometryGirl (talk) 23:56, 6 September 2009 (UTC)

I would guess that this would require some modification of the underlying MediaWiki software. --Cybercobra (talk) 00:18, 7 September 2009 (UTC)

That seems pretty clear. Hopefully it's not too horrendous a job. Anyway, I don't think we should worry about this as yet per WP:Performance. GeometryGirl (talk) 00:54, 7 September 2009 (UTC)

I like the idea, but you can't sweep under the carpet how the colours will be determined in practice: it's the key issue. How will the software decide whether to show the link as red, orange, blue, green? Rd232 ^talk 01:51, 7 September 2009 (UTC)

The software would use categories to determine the colour:

• red for nonexistent articles (as usual)
• orange for Category:Stub-Class articles and Category:Start-Class articles
• green for Category:GA-Class articles and Category:FA-Class articles
• blue for the rest (C class, B class, A class, etc.)

That seems awfully arbitrary. Why should C-class articles be treated the same as B-class? And A-class is supposedly higher than GA-class, why is it treated worse? Why should articles that went through a rigorous FAC be treated the same as articles that were marked as "good" by a single person? What about articles that are in multiple classes? Some projects don't use C or A-class. Some projects have strict standards for what classes to use, others (most, really) are just an arbitrary rating. Mr.Z-man 17:35, 7 September 2009 (UTC)

Are you aware of the existing functionality to show articles of less than a given size as a differently-coloured link? It can be triggered by changing "Threshold for stub link formatting (bytes)" to a non-zero value in the Appearances tab of Special:Preferences.-gadfium 02:18, 7 September 2009 (UTC)

If you go into your User Preferences, click the Advanced tab, and scroll to the bottom, there is an option for stub linking. You enter a threshold number of bytes, and any links to articles smaller than that size will show up poo coloured. I personally changed mine to orange because the poo colour resembles clicked-upon blue links. You can do this by editing your theme's CSS file (In most cases, this would be monobook.css) and adding the following text:

 a.stub:link {color: #ff6600;}
 a.stub:active {color: #ff6600;}
 a.stub:visited {color: #ff6600;}
 a.stub:hover {color: #ff6600; font-weight: bold;}

You may need to fiddle with it to make it suit your needs, but this does the trick. You can also change the third line to

 a.stub:visited {color: #cc5500;}

to make visited links a deeper orange - ʄɭoʏɗiaɲ ^τ _¢ 02:33, 7 September 2009 (UTC)

That is a great functionality I was not aware of. However, what I propose is more subtle: it is not based on size but on quality. GeometryGirl (talk) 12:00, 7 September 2009 (UTC)

the problem here is that you're trying to mix up two different systems. MediaWiki is the software that runs Wikipedia, and it is used for much more then just Wikipedia (Wikinews, WikiBooks, all fo the Wikia sites, etc...). The quality rating categories are something that we specifically do here on Wikipedia, and not every article even has a quality rating (although, by this point, it is awfully ubiquitous). So... implementing this sort of suggesting in software would be next to impossible, and even if is was specially made as a plugin/extension for Wikipedia it's application woudl be (very) uneven and prone to gaming. All anyone would have to do in order to change the link color that everyone (who is using the gadget/skin) sees is to go to the talk page and switch the Class in a wikiproject template (or simply add a cat). Worse, categorization is not mutually exclusive, so it's not only possible but probable for an article to either have both Category:Stub-Class articles and Category:GA-Class articles at the same time, or none of the X-Class categories, which leads to the obvious question of what the software should set the link class to in that case.

It's not a bad suggestion at all, it's just... impractical. Sorry.
— V = I * R (talk to Ω) 13:37, 7 September 2009 (UTC)

Thank you for your comment User:Ohms law. First of all, this proposal is only intended for Wikipedia. Second, what is the problem in "mixing up" categories with MediaWiki? Isn't that one of the purposes of MediaWiki, to serve Wikipedia? I don't understand your concern, are we not in an age where software has become flexible? Also, why is "All anyone would have to do in order to change the link color that everyone (who is using the gadget/skin) sees is to go to the talk page and switch the Class in a wikiproject template" a big concern? Wikipedia is prone to vandalism, true, but Wikipedia has dealt pretty well with vandalism in the past. And what do you mean by "it's application would be (very) uneven"? As for articles with conflicting categories, these are "anomalies" which should not occur, and we can easily code robots to deal with the problem. As for articles without any quality assessment, it is a good incentive to have them assessed! GeometryGirl (talk) 14:05, 7 September 2009 (UTC)

I actually agree with the view towards vandalism, but that's the sort of thing that always seems to be said in these proposals so... I guess that I felt obligated to do so as well. The underlying reliance on the category system is extremely problematic, though. There's simply no means to control category use, and there shouldn't be, which makes attempting to bolt external extensions to it generally a bad idea. Categories are a search assistance first and foremost, and proposals which distract from that focus are likely to meet considerable resistance. If you really look around, you'll notice that articles with conflicting (Class) Categories, or none at all, is far from a rarity. That articles can have different assessments for different projects is actually a feature of the current assessment system as well, and I don't think that should be discouraged. The more heavily trafficked articles have largely been assessed but certinaly not all of them have, and there are numerous lightly trafficked articles (which are largely the target of this proposal, it seems) that are not assessed at all.

I don't want to be all negative though, since I do sort of like the idea behind this... I think that the current assessment system using the Category system is a slight problem as well. The best bet would probably be to completely decouple this proposal from the Category system, which would mean the addition of a separate special assessment field for all articles. I'm not sure how that would play with many Wikipedians (I could imagine that some Wikiproject groups would not be happy with it), but it's probably worth floating the idea around just to find out. The link color issue itself should be shelved for now though, in order to keep the focus on the "global assessment property" proposal. A case could certainly be made to add on functionality for assessments outside of the Category system, since assessments are clearly supported by the community, and are only using the category system because there's nothing better to use.
— V = I * R (talk to Ω) 15:13, 7 September 2009 (UTC)

I disagree with you when you say that "There's simply no means to control category use". Take for example featured articles and good articles. These categories are extremely well controlled, and no article can suddenly claim featured status without passing through FAC. I am also surprised when you say "Categories are a search assistance first and foremost". Can't the function of categories evolve over time? Anyway, I don't really care (for now) about the specific way this link colouring feature would be implemented, I mainly want to know if Wikipedians think it is a good idea. If they think it is a good idea then this will certainly bolster some brainstorming as to how exactly we will implement this. This brings me to my last point, that I disagree the "color issue itself should be shelved for now" since the colour issue justifies thinking (or rethinking) categories. GeometryGirl (talk) 15:27, 7 September 2009 (UTC)

More accurately, the GA and FA categories are simply well watched. Anyone can place any article in the GA or FA class categories (or even both), it's just that with the number of people involved in those two assessment classifications the article is unlikely to stay there. Simply removing articles from such classes is equally easy as well, but those articles are trafficked enough that such removals are also reverted fairly quickly.

The use of categories can certainly evolve though, it's just that the underlying functionality really shouldn't. There's simply no need for the functionality itslef to do so, really. Using Categories informally for tasks such as classification is one thing, but formalizing such relationships in software is an entirely different issue, and should generally always been avoided. If the proposal is good enough to implement in software, adding a new system specifically for the purpose is a much preferred design pattern to follow for many reasons (ease of implementation, encapsulation, maintainability, etc...).

Color itself isn't actually the central issue here either, by the way. That is the way that you're expressing your desire, but what you're asking for is the addition of a couple anchor CSS classes. Different skins actually handle the coloring in their own fashion, and individual users can custumize link coloring for themselves (I currently do. all "redlinks" are green, to me). That's the primary reason that I recommend shelving the color aspect for now, since it's really a (technical) secondary aspect to this. Determining how to consistently decide what class an anchor to an article should use is the primary issue, and adding a new field/property to articles is the means to achieve that.
— V = I * R (talk to Ω) 15:49, 7 September 2009 (UTC)

• Excellent proposal. Now I've got to highlight these pale links just to read them. Thank you, dear Academy, another cool use for my mouse. NVO (talk) 16:25, 7 September 2009 (UTC)
• KISS. Five different colors for links (regular blue link, regular red link, the two proposed additions, and the lighter blue interwiki link)? That's confusing for the average editor; our readers shouldn't need a cheat-sheet just to use the website. For those that are interested (before clicking the link) about what the page's quality is, isn't this what we have pop-ups for? It should be an opt-in feature (ie: a gadget), not default behavior. EVula // talk // ☯ // 16:34, 7 September 2009 (UTC)

  Agreed. I seem to recall somewhere there was an informal poll or survey at one time that asked if readers actually knew what the FA-star in the tops of FAs actually meant, and the majority of non-editors didn't. While improving content is a great goal, it shouldn't be done at the expense of making the site more confusing and harder to use for readers. Mr.Z-man 17:35, 7 September 2009 (UTC)

  What about the more Wikipedia-knowledgeable logged-in users? Anyway, wouldn't the benefits outweigh the possible confusion? Also, keep in mind that redlinks are now (very rare), and FA and GA articles are also pretty rare. So most links would be blue or orange. GeometryGirl (talk) 17:47, 7 September 2009 (UTC)

  You can set up a colour-coding system (though it doesn't run by default, for performance reasons) using this rather neat script. Shimgray | talk | 17:54, 7 September 2009 (UTC)

  These two criticism's directly hit at the reasons why I was suggesting adjusting the proposal, above. I think that there is a good core to this proposal, it's just the implementation details that are slightly askew.
  — V = I * R (talk to Ω) 18:12, 7 September 2009 (UTC)

  @GeometryGirl: What about them? They make up a rather small minority of total users. If people are confused by it, then we don't get the full benefits. My reference to the FA-star was not about FAs, it was about how we put things in articles like that without actually considering whether or not readers know what its for. With redlinks its rather obvious. But since everything from Start to B (even including GA to some extent) is typically an arbitrary rating chosen after only a cursory review, it will not be very obvious what the difference is. By adding more colors into the text, pages also get harder to read. Mr.Z-man 19:05, 7 September 2009 (UTC)

Remove the sandbox functionality from the intro page

I am talking about Wikipedia:Introduction, a page that welcomes our new users. The page has sandbox functionality, in other words, the users are free to make test edits there as long as the intro template stays untouched. Too bad it doesn't, and new editors may be greeted by something along the lines of "lol wikipedia is teh suxx0rz haxd" or "Get stuff online www.fakesite.com". This is mostly incompetence and misunderstanding the purpose of the page instead of actual vandalism, but to ensure that the page looks the way it's supposed to when a new user views it, I suggest we remove the sandbox functionality from this page altogether. Obviously, it's good to have a sandbox page for our newcomers, so I suggest editing our current sandbox template to point forward to Wikipedia:Introduction_2 (titled "Learn more about editing") so new editors wouldn't have to look for the next page of the introduction OR creating a new sandbox page between the first and the second introduction page. Any support, comments, suggestions? Kotiwalo (talk) 19:03, 19 August 2009 (UTC)

I would vehemently oppose such a change. It's really helpful, in my opinion, to be as encouraging and as forthwith as possible with readers and editors alike when they reach Wikipedia. If anything, the links to WP:Introduction should be more prominent on the Main Page. The more links someone has to follow, the less likely she or he is to actually follow them. Yeah there's vandalism there, but the vast majority of it is really just people flexing their wikimuscles and testing their boundaries. Besides, unlike most other areas, it's not really harming anyone greatly. Screwing with a sandbox makes it worse for the next guy, but it's not exactly libelous. ~ Amory (user • talk • contribs) 01:43, 20 August 2009 (UTC)

Yes, screwing with a sandbox wouldn't be a big deal, but it's also our introduction page, and since many new editors have wiped out the welcome template, either accidentally or intentionally, there is a good chance of our new editors being greeted by profanity or other not especially "welcoming" content. It wouldn't matter as much if there was a way to ensure that the welcoming template wouldn't be deleted, accidentally or in bad faith. Kotiwalo (talk) 09:53, 20 August 2009 (UTC)

Why not add something like the sandbox header, so that the page would get refreshed with the proper content every 12 hours? Warrior4321 22:00, 20 August 2009 (UTC)

There is one on the intro page I guess, but it would have to be cleaned after every single edit to ensure that the template stays intact, and that would take away the entire point of the sandbox. Separate page would be better. Kotiwalo (talk) 05:41, 21 August 2009 (UTC)

Is there anyway you can divide the page so one part(or section) can be semi-protected and the other part gets cleared every 12 hours? Warrior4321 17:47, 21 August 2009 (UTC)

I'm very sure that there's a way but I'm also rather sure that it won't be too quick an' easy. Kotiwalo (talk) 18:23, 21 August 2009 (UTC)

Perhaps creating a page with the introduction on another page (like the sandbox header), and then transcluding it into there? We can place a invisible comment right beside the transclude, telling them to leave it alone? That would provide new users who are not sure where to edit much more room. Warrior4321 19:22, 21 August 2009 (UTC)

Actually the intro page has the following:
{{Please leave this line alone}}
<!-- Feel free to change the text below this line. No profanity, please. -->
Sadly, this doesn't always work. Kotiwalo (talk) 08:11, 22 August 2009 (UTC)

(outdent)I have recently been watching the introduction page. No idea how that started, but I regularily check out the new user contributions and revert offensive or immature edits. It has begun to irk me that the message we use to greet newcomers is routinely vandalised into absolute nonsense. Wikipedia is not the place to read about ketchup farts, or at least a main page isn't.

I wish to propose that the page for editing WP:Introduction redirect to the page for editing WP:Sandbox. This way, new users can read the introduction, still click edit, and edit the sandbox instead of defacing the message that they just read. WP:Introduction could then be protected from editing. - ʄɭoʏɗiaɲ ^τ _¢ 14:01, 22 August 2009 (UTC)

I really like that idea! Any idea, how we could edit the edit button? Warrior4321 19:11, 22 August 2009 (UTC)

Why not make it work the way {{doc}} works on protected templates (via transclusion of the sandbox -- in this case -- onto the protected intro page). That way the message stays intact, and you can have a special edit link right there (though the "edit this page" tab won't work right, unfortunately). Maybe have Cluebot and/or its friends lightly patrol the sandbox for profanity to stop that. --Thinboy00 @117, i.e. 01:48, 29 August 2009 (UTC)

Relisting since this got ignored and archived and since its a very logical and easy to implement idea that could really improve what new users first impression is. - ʄɭoʏɗiaɲ ^τ _¢ 01:59, 7 September 2009 (UTC)

I don't see how transcluding the sandbox onto a protected page will help - as far as I can see users still won't be able to edit/save. We could use an edit notice and a cleaning bot; we could also revisit the idea that the Intro page needs to allow people to save; mightn't telling people to go to the Sandbox for further testing, be enough? Rd232 ^talk 08:20, 7 September 2009 (UTC)

As far as I can see the template documentation transcludes a link onto a protected page, which goes to a sandbox in edit mode. WP:Introduction already has such a link, so the only thing that would need doing is protecting it. That breaks the "edit this page" example function though. Is there any way to make the "edit this page" button edit a different page? Surely not. Is it worth filing a bug for a single page? Not sure. Rd232 ^talk 15:01, 7 September 2009 (UTC)

Thats why I proposed above that the page for editing WP:Introduction redirect to the page for editing WP:Sandbox. - ʄɭoʏɗiaɲ ^τ _¢ 16:48, 7 September 2009 (UTC)

I don't understand. On Wikipedia:Introduction people edit the page by clicking the Edit This Page button, not by clicking a link like this [5]. Rd232 ^talk 17:08, 7 September 2009 (UTC)

(Because the "Click here to edit the sandbox" link on that page already goes to WP:Sandbox.) Rd232 ^talk 17:09, 7 September 2009 (UTC)

Then so should the edit button at the top of the page. I really don't see why this suggestion isn't better received... It keeps the functionality, but ends the vandalism at the introduction. - ʄɭoʏɗiaɲ ^τ _¢ 17:25, 7 September 2009 (UTC)

So you do mean making the Edit This Page button do something other than Edit This Page? Unless you know something I don't, that's currently not possible. Rd232 ^talk 21:05, 7 September 2009 (UTC)

Upgrade of the "Categories" system

“Categorization is a feature of Wikipedia's software, enabling pages to be placed in categories which can then be used by readers to find sets of articles on related topics. Categories can be defined as subcategories of other categories, allowing easy navigation between connected subject areas via a tree-like structure. This helps readers find articles on particular topics even if they don't know which articles exist or what they are called.”

However, the current system is not intuitive; it is hidden at the bottom of the page; it does not make the most of its navigational potential; category pages look unappealing.With the minimum change it should be possible to display the same information much more effectively. The following is suggested:

• The current information is displayed in a fixed size box
• The box could be accessed as a drop-down tool or as a permanent box on the right hand corner (or wherever).
• Lists of categories are the same as at present but are scrollable hence no need for huge boxes
• Lists are single-column and clickable
• There is the facility to go “up” in category levels as well as “down”
• Entries are sometimes quite long so the use of a small but clear font would assist – there are small black fonts that would do the job

I would be pleased to discuss further with any programmers willing to give it a try. There are probably many other category-based improvements that could be achieved at the same time: a tool to edit and manage categories for example.Granitethighs (talk) 10:32, 7 September 2009 (UTC)

Feature request: The ability to view a category as "flattened"; that is, see all pages in the category and its subcategories, recursively, on one logical page. --Cybercobra (talk) 11:34, 7 September 2009 (UTC)

"a tool to edit and manage categories" Are you aware of WP:HotCat? --Cybercobra (talk) 11:34, 7 September 2009 (UTC)

Not entirely sure what this proposal would look like, but certainly categories are not currently doing their job very well, and it's mainly a problem that requires developer assistance (though various requests for improvements at Bugzilla have brought little effect). In fact I'd like to see categories dumped in favour of a far more natural and powerful system - some syntax for stating characteristics of article subjects ( {profession=singer;sex=male;birthdate=...;nationality=...}, that sort of thing), then users could search based on exactly what characteristics they chose, without editors constantly having to make judgments about what levels of categorization are going to be a help or a hindrance.--Kotniski (talk) 11:47, 7 September 2009 (UTC)

The proposals at Wikipedia:Category intersection and Wikipedia:Link intersection may be of interest. ---— Gadget850 (Ed) ^talk 12:53, 7 September 2009 (UTC)

I find Categories rather confusing. They seem to a casual user as performing the same function as (A) the lists of ... in small type at the foot of pages and (B) the "List of ..." articles. In fact what is the functional advantage over a "List of" article?

Also category pages are confusing when (as very often happens) "There is one sub-category" which appears at the top and 134 regular entries underneath. As said above, the pages are more unattractive and do not seem to adopt the "house style" of a Wikipedia page.Sussexonian (talk) 21:40, 7 September 2009 (UTC)

More Privacy and Rights for Users Who Are Being Checkusered

Users who are being checkusered and accused of having sockpuppet accounts should have more privacy and the right to defend themselfs when banned/blocked. At the moment such users get blocked and banned without any warnings and have their private information displayed for everyone to see. They cannot edit or defend themselfs either.

My proposal is:

1.) Being more discreet about private information such as related IP-info (even when used for editing)

2.) The right to edit their talkpage so they can defend themselfs. — Preceding unsigned comment added by 7853hgh (talk • contribs) 14:12, 7 September 2009 (UTC)

I don't think we give out private information unless it is relevant to addressing behavioral problems. And generally people are allowed to edit their talk page unless they have a history of abusing it. If this has happened to you then perhaps you could link to where this has happened? Chillum 14:16, 7 September 2009 (UTC)

Their private information is not displayed for everyone to see, and with the exception of extreme cases, blocked editors are allowed to defend themselves on their talk pages. That said, Checkuser information covers more than just their IP; a CU won't take action based on weak evidence. EVula // talk // ☯ // 16:14, 7 September 2009 (UTC)

• Disclosure: I have checkuser privilege, but not on en.wp.

The WMF privacy policy provides very strong protection of logged user information. Are you familiar with it? Do you have reason to believe it has been breached? Otherwise, how would you characterise it as being deficient in relation to being 'discreet'?

To my knowledge, the vast majority of user-specific blocks permit the user to continue editing their talk page. This courtesy isn't extended where the talk page is used for abuse, or there is good reason to assume it will be used for abuse.

Detecting sockpuppets with the aid of data provided by the checkuser tool is not particularly difficult unless the puppeteer devotes significant effort to hide their tracks. Please, remember this is combined with publicly available information such as user contribution history. --Brian McNeil /^talk 17:58, 7 September 2009 (UTC)

Proposal to add link to Wikinews in Template:Recent death

A proposal to add a link to Wikinews articles in {{Recent death}}. Please see Template_talk:Recent_death#Optional_link_to_a_Wikinews_obituary. Thank you for your time, Cirt (talk) 17:25, 7 September 2009 (UTC)