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 WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals Editors here can help.
• Proposed new wikis belong at m:Proposals for new projects.

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

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): Erik9, on 09/13/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)
  • Please read the proposal before commenting. I've replied to this objection 3 or 4 (or more) times now. The list would not expose all unwatched pages. Why would we need an external tool?    M   06:38, 12 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)
• Oppose: Of course, it's always tempting to say "I want something", but we have to look at the cost. As Protonk points out, it is not trivial to implement and may require even an additional tool. That's not worth our developer's time. There are more important bug requests, and the watch problem can be better addressed with flagged revisions. — Sebastian 01:09, 12 September 2009 (UTC)
  • Nothing is trivial to implement, but this is certainly not on the difficult end of the spectrum. Could you give more details on what exactly you think makes this non-trivial, or what aspect may require an additional tool?    M   06:38, 12 September 2009 (UTC)
  • Now that I read it, this reply makes we want to support the proposal here based on "it would be better to use flagged revisions", which I think is a terrible idea.
    — V = I * R (talk to Ω) 09:34, 12 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)

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)

Shakescene, I seem to remember hearing that the researchers managed to compensate for that sort of thing, by giving people back reputation rating when other editors reverted to their version of an article. I'm sure that the top-rated editors will still be "quiet" ones who make plenty of uncontroversial changes, but that's par for the course with an automatic assessment. {{Nihiltres|talk|edits}} 01:35, 8 September 2009 (UTC)

In short, if the nationalists are quiet enough that nobody reverts the next FYROM, they will become trusted editors, and their POV will become trustworthy. God preserve this, and keep it far from us! Septentrionalis PMAnderson 15:47, 9 September 2009 (UTC)

Yeah, I was looking at where it was implemented, and, I'm not sure how well that would work. Shouldn't trust be based on weather or not it is cited, not how trusted that contributor is?--Unionhawk ^{Talk E-mail Review} 16:01, 9 September 2009 (UTC)

• This probably takes no account for copy editting does it? Which means it will treat a copy edit of an article in the same way it would a fact correction. Having someone copy edit over my work, or copy editting over my own work, would in effect be lowering my "quality rating". Seems to me this might discourage copy editting.. —Charles Edward ^{(Talk | Contribs)} 18:55, 9 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)

Unless you subscribe to the extension nobody will be able to change your watchlist. — Jake Wartenberg 00:04, 8 September 2009 (UTC)

Excellent! In that case I have no objection to implementation. -- Derek Ross | Talk 06:13, 8 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)

• Support GeometryGirl (talk) 22:32, 10 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)

Rollback should theoretically trigger this also- it's supposed to be used solely to revert blatant vandalism (or other non-controversial tasks, like reverting your own edits to your own talkpage), since under normal circumstances you CAN'T add an edit summary. --King Öomie 19:44, 8 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)

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)

I agree that no consensus means do nothing or perhaps do not delete. I would support an explanatory link worked into the text, pointing to WP:Articles for deletion#How an AfD discussion is closed. WP:Guide to deletion#Recommendations and outcomes is an alternative if an explanation of no consensus is added. Flatscan (talk) 04:11, 8 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)

My "Show edit toolbar (requires JavaScript)" is not ticked, but I still get the bloat. Kdammers (talk) 06:33, 12 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)

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)

Yes... I'm sure the nifty programmers could come up with a simple code to make it work. - ʄɭoʏɗiaɲ ^τ _¢ 06:31, 8 September 2009 (UTC)

Mmm, fine with me if you want to file a bug. Can't imagine it being a priority for the overworked programmers though... Rd232 ^talk 10:09, 8 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)

To that, I'll add Semantic MediaWiki and Dynamic Pagelist. Both are fairly intensive extensions, though SMW seems a popular one to be added in the near future. --Izno (talk) 14:23, 8 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) In answer to the question of what is the advantage of a category over list, the answer can be summarized in one word - hierarchy. If you click on a category, and then go the bottom of that category, you will see that often the category is itself a member of a more superordinate category. I personally rather like the category system in Wikipedia - as do many other Wikipedians, as is evidenced by the Association of Categorist Wikipedians. After all, if one wishes to learn about the Linneaan division of the world, this could be an extremely useful tool. One might find that a gibbon is a primate, which in turn is in mammal, which in turn is a vertebrate, which in turn is a chordate and so on and so forth. ACEOREVIVED (talk) 22:55, 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)

specifying foreground color when changing background color.

when people create tables and mboxes and such things and they change the background color why do they automatically assume that the foreground color is going to be black? I use white forground and, while it works well enough for most of the pages that I actually use, a few pages (including some important ones) are nearly unreadable. when people change the background color they should also specify exactly what foreground color to use as well. would it be reasonable to ask that this be made into a policy? Lemmiwinks2 (talk) 00:15, 8 September 2009 (UTC)

Do you have a specific example? Most boxes and the like have associated CSS that set defaults. ---— Gadget850 (Ed) ^talk 01:37, 8 September 2009 (UTC)

Virtually all that I have seen. But if you want specific examples then:

{{portal|Bible}} {{Biblical longevity}}

plus the barnstar on my user talk page (before I changed it)

the mbox on my user css page.

virtually the entire 'my preferences' page.

I'll try to find more. Lemmiwinks2 (talk) 23:31, 8 September 2009 (UTC)

Something's obviously wrong with your configuration somewhere, then. If what your describing were common people would be screaming and tearing the place apart... are you using any customized CSS/js? what skin are you using?
— V = I * R (talk to Ω) 00:16, 9 September 2009 (UTC)

As Lemmiwinks2 stated clearly, he is using white text. Algebraist 00:18, 9 September 2009 (UTC)

Ah, I just re-read his first post and I see that now. All I can say is, if you do non-standard things you've got to expect that it will create some issues. I don't want to sound rude but, why should you're personal style choices be the basis for all of the rest of us being required to do makework? You should be able to, and in fact can (as demonstrated by this thread) do what you like for yourself, but expecting the rest of us to conform to the choices of individual customizations seems... egocentric? But, what do I know. If someone want to go around and add foreground color values to style tags, I seriously doubt that anyone would stop them.
— V = I * R (talk to Ω) 00:44, 9 September 2009 (UTC)

I'm not even going to try figuring out all the rules you have in User:Lemmiwinks2/monobook.css and User:Lemmiwinks2/vector.css, but there appears to be a bunch related to boxes. Try clearing out whichever you are using and purging. If that fixes it, then add stuff back in a bit at a time. Nor do I know why you have boxes on your user and talk pages with that blue background. ---— Gadget850 (Ed) ^talk 00:26, 9 September 2009 (UTC)

As I said in the discussion below on the proposal to introduce orange and green wikilinks, we must be careful not to confuse people with colour blindness (black and white text should not do this).

♣ Questionnaire on Wikipedia Editors' Motive and Characteristics

Greetings.

Korea Information Society Development Institute (KISDI), a government-affiliated research institute, conducts a research on motive for contribution as well as cultural characteristics of participants in collective intelligence sites as Wikipedia and Yahoo Answers. (See www.kisdi.re.kr for the detailed information about our Institute.)

The survey aims to identify factors affecting Wikipedia users' usage and participation. Your responses are absolutely confidential and will only be used to extend our understanding of collective intelligence. We count on your responses to help us make policies for encouraging collective intelligence.

A small amazon gift card will be offered for those who complete the survey.

Thank you for your full cooperation.

Sincerely,

Joo-Seong Hwang | Senior Research Fellow | Convergence and Future Strategy Research Division

E-mail redacted

→Click

Please do not include contact details in your questions. We are unable to provide answers by any off-wiki medium and this page is highly visible across the internet. The details have been removed, but if you wish for them to be permanently removed from the page history, email this address.--Unionhawk ^{Talk E-mail Review} 01:19, 8 September 2009 (UTC)

Alternate proposal

Instead, let's take FA off the main page; the others can stay, they cause less harm. This would immediately reduce the amount of nationalist POV-pushing, where each national gang tries to get their national glory on the main page, like Samuel of Bulgaria - which was written out of the nationalist schoolbook of Bulgaria, vintage 1912. The source, and the article, give Samuel and his allies all the positive adjectives; his enemies, including his brother, get the negative ones. Fortunately Karanacs noticed this and declined the star, but that doesn't happen anywhere near often enough.

The useful aspects of FA and GA would continue; there would continue to be stars for ego-boo, and reviewers would continue to look at articles. About one time in three, as now, review would improve an article; actual harm would be rare, as now. Septentrionalis PMAnderson 16:10, 8 September 2009 (UTC)

I doubt POV pushers are coming directly from the Main Page; they're likely looking up the articles that interest them, same as any other editor (vandal or otherwise). EVula // talk // ☯ // 16:14, 8 September 2009 (UTC)

But the more sophisticated ones are writing articles that suit them, as here; I'm talking about the FA nominator and his friends. Septentrionalis PMAnderson 16:33, 8 September 2009 (UTC)

Then what's the point of taking FA off the main page? EVula // talk // ☯ // 20:05, 8 September 2009 (UTC)

I've said it often enough; if anything's to be taken off the main page, it should be DYK and ITN. These highlight what Wikipedia does worst; newly created unfinished stubs, and articles on rapidly changing topics prone to editwars. At least FAC means someone looks at the article (and Sandy, Raul and Karanacs are generally fairly good at spotting blatant puffery). – iridescent 20:38, 8 September 2009 (UTC)

But it's good to have those on the main page, so people go to them and improve them. I've found many a page to work on via ITN and DYK. OrangeDog (talk • edits) 02:39, 10 September 2009 (UTC)

Disambiguation

I am an academic and understand the need for formal technical terms. I also understand that the word “disambiguation” has some history in linguistics as a technical term for clearing up ambiguities between similar or identical words. I also understand the need for Wikipedia to follow high standards in presentation and procedure. There is, however, another view. Wikipedia is a kind of “peoples” encyclopaedia and should not use complex terms when adequate and perfectly clear substitutes are available that can be immediately understood by all users - including those that are young or less educated than those familiar with the word “disambiguation”. I am saying it is not a very “user-friendly” word and suggest it be replaced with something like one of the following. “Clarification”, “Different senses” “Different meanings for this entry”. I’m sure there must be a simple word or phrase which does the same job and I would be happy with any of these suggestions. A global replace would then be a relatively simple matter. Granitethighs (talk) 23:44, 8 September 2009 (UTC)

• I'm very much not an academic, and my reaction to this is... huh? Sure, "disambiguation" isn't a common word, but it's meaning is immediately clear when it's first encountered.
  — V = I * R (talk to Ω) 23:57, 8 September 2009 (UTC)

  Why say "obfuscation" when you can say "deceive"? Granitethighs (talk) 00:24, 9 September 2009 (UTC)

  And I would agree with that. However, in this case you're saying "Why say "obfuscation" when you can say... something else. What would be simpler? Do you have any suggestions?" Hey, I'm all for simpler myself, and in most cases I'd likely be on your side. This though... what else would you call a page with makes an ambiguous title not ambiguous? This is what we used to call "Nuking it"; over thinking and over analyzing a common task, process, procedure, etc.. (in this case a word) until it turns into a problem.
  — V = I * R (talk to Ω) 00:36, 9 September 2009 (UTC)

  To be a pedantic academic for a moment - I think the use of the word "ambiguous" and hence "disambiguate" here is not the most appropriate word anyway. It is a subtle point but it seems to me that the the words themselves are not ambiguous, they just have different meanings ... the same words with different senses. I suppose what is "ambigious" relates to the particular meaning the enquirer is seeking. Anyway, I gave my suggestions. What is wrong with "Different senses" or “Different meanings for this entry”? If they are regarded as unnecessarily long then "Clarification" would do the trick. Do you have children? If they were using Wikipedia do you think "disambiguation" is the way to point out that the same word or phrase can have different meanings? Granitethighs (talk) 01:16, 9 September 2009 (UTC)

  Not commenting on the merits of this proposal, but WRT children and non-native speakers, we do have Simple English Wikipedia, so we really shouldn't use them as a reason to change the word. Dabomb87 (talk) 03:59, 9 September 2009 (UTC)

  Actually, I remember my first few days on Wikipedia. The first time I saw a disambiguation page, I did not know what was meant by a disambiguation page, until I actually went to more than one disambiguation page. This showed me, that a disambiguation page was merely a index to other pages. It can be confusing to all, and we've all gotten past it smoothly, others will too. It's all part of the learning process, we call life. warrior4321 04:04, 9 September 2009 (UTC)

  (edit conflict) If a user was having trouble understanding the meaning of disambiguation, they Simple English Wikipedia may be better for him or her. However, that Wikipedia even uses the word. I don't think it's an issue. hmwith☮ 04:06, 9 September 2009 (UTC)

  This is like saying "why SMS CU4T when we all understand that it means "See you for tea" - - - learning English is part of the language learning process in life that we must all undergo so just put up with it and write "See you for tea". The point is that it is simpler, easier, and therefore more efficient and appealing to say CU4T (or "Clarification"). Granitethighs 04:15, 9 September 2009 (UTC)

I think I'd encountered the word disambiguation before I went on Wikipedia or else apprehended its meaning from etymology once I had. But that didn't tell me what it was; it just looked like more of that forest of incomprehensible technical jargon best avoided when possible. And knowing an ordinary English meaning of a word can sometimes be positively misleading, as I found out when I learned that "deprecation" didn't just mean what it had meant to me for the previous three or four decades, "deplore" or "disparage". Something like "alternative meanings" or "alternate uses" would be much clearer. And editors should forbear from "dab" as an abbreviation for diambiguation; it's certainly not intuitive. —— Shakescene (talk) 04:55, 9 September 2009 (UTC)

Granitethighs is right, and the existence of Simple English Wikipedia is not a reason to make this one inaccessible. However, I'm not sure about the suggested alternatives. --Apoc2400 (talk) 09:44, 9 September 2009 (UTC)

What I was saying is that they don't even see using the word as a problem there, and that's a simplified version of this Wikipedia. I think most young readers can establish what the word means based on its roots, or at least relate it to ambiguity or ambiguous, and gather the meaning from that with the addition of the prefix. hmwith☮ 13:52, 9 September 2009 (UTC)

"Disambiguate" was once the answer to a question on Wikipedia on University Challenge, so let us leave things as they are! ACEOREVIVED (talk) 23:17, 9 September 2009 (UTC)

Two, four, six, eight! Time to disambiguate! Go-o-o-o-o-o-ohhh, State! —— Shakescene (talk) 03:21, 10 September 2009 (UTC)

Link color proposals

Invitation to edit: Orange links

Archived

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 (orange links) 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) Shimgray, I use the same script for quite some time now, and it is (according to me), one of the best scripts on Wikipedia. It provides the reader with the quality and importance of the article, right from the article, rather than having to go to the talk page. Concerning, the proposal, I don't see how the orange links can help. While showing the readers which articles are high quality articles which are FA and GA, it will not do anything but create a new "rule" that only article with a green wikilink are "good" and should be clicked on. Warrior4321 02:34, 9 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) Sorry, what I meant was: What about implementing this ONLY for logged-in users. Anyway, I have started a more modest/mature/first-step proposal below. GeometryGirl (talk) 14:11, 8 September 2009 (UTC) I use User:Anomie/linkclassifier.js, which provides similar functionality. You can also use the CSS line #bodyContent a.external { color: #008000 } if you, like me, find it hard to tell the difference between the colours of internal and external links (it turns them green). Dendodge T\C 16:02, 8 September 2009 (UTC) GeometryGirl invited me to comment here - I think that finding intuitive ways to highlight articles that need attention is a good idea. I do want to note that red links being somewhat annoying is probably a significant part of the reason they work - there's something particularly satisfactory about seeing an article with lots of red links "turn blue". That said, I do share the concern about making the reader experience potentially significantly more confusing. How about an implementation that adds a simple summary in an appropriate location, such as "22 articles linked from this one could use your help (expand)", which would then list the articles and the specific problems when expanded?--Eloquence* 02:08, 9 September 2009 (UTC)

Invitation to read: green wikilinks

Dismissed

Wikipedia currently only has two types of links: the blue links for existing articles, and the red links for nonexistent articles. I propose to add a system of green links whereby any wikilink to a good or featured article would be coloured green. Q&A (and summary of discussion) Q: Why implement this? A1: Green links would invite users to read quality articles, relevant to the article they are currently reading, that they might not have otherwise read. A2: Green links would complement "Today's featured article" in showcasing article for which the quality has been vetted by Wikipedia. A3: Green links might motivate editors to "turn all links green". Q: How would this be implemented? A1: Using the well watched and controlled categories Category:GA-Class articles and Category:FA-Class articles, and the help of a script similar to this rather neat one, or this one. A2: Some other ingenious way! Q: For who would this be implemented? A: Green links would be implemented by default for all readers. Q: What are the drawbacks? A1: This proposal assumes that FA and GA represent our best work. (Comment from Septentrionalis and iridescent, see below.) Reply: Green links don't claim to link to "the best" articles, just articles who's quality has been vetted by the Wikipedia community. A2: Some colourblind may not distinguish green/red or green/blue. A3: There are potential performance problems. Reply: Per WP:PERFORMANCE, users should not worry about performance. A4: People might not understand the purpose of green links after clicking one. (Comment from EVula, see below.) A5: Quality articles are not necessarily articles that people want to read. (Comment from Kotniski, see below.) Reply: Green links are only a suggestion for a read, similarly to "Today's featured article". Also, links in an article are relevant to the article being read, and hence relevant to the reader interested in the article in the first place. A6: This add complexity to the linking system, and may cause confusion. (Comment from EVula) Reply: True, but only very few links would be green, since very few articles are good or featured. Q: Why green? A1: Because of the connection with the green GA logo . A2: Because green is very distinct from the existing blue and red. (Except for certain colourblind, see above.) Q: Why does this proposal exist in the first place? It does not solve any problem! (Comment from EVula.) A: The goal of this proposal is not to solve a problem, but to improve the current wikilinking system for collateral benefits. Discussion (green links) Please discuss here. In good wikispirit, I am leaving this proposal "open". Feel free to edit it! GeometryGirl (talk) 14:05, 8 September 2009 (UTC) This assumes that FA and GA are better than other articles. This is true only to the extent that, having received attention, they are less likely to be grossly incompetent or stubs. (Unfortunately, gross incompetence and bias are possible; for examples, see the appallingly sourced Daniel Webster, the appallingly written Names of the Greeks (now removed after four years), and the tendentious Kingdom of Mysore.) FA and GA are sometimes useful processes, but their utility consists of examining articles (often competently and thoroughly, sometimes not) and of being an array of incentives to write decent articles. They evaluate articles very badly, being prone to PoV log-rolling and sheerly irrelevant comments (such as Wikipedia:Featured_article_candidates/Battle_of_Red_Cliffs, which was primarily some editor's snit about Harvard referencing - but none of the comments, including my own, were significant.) In short, I very strongly oppose this, until FA and GA acquire a better population of reviewers, which I expect shortly after publication. My only edit would be to insert the word never as often as necessary. Septentrionalis PMAnderson 14:49, 8 September 2009 (UTC) Wow, that's a pretty interesting and extreme point of view. Sure, Wikipedia is not perfect, and nor are FA or GA (or the underlying processes). But remember, perfection is not the goal. And let's face it, FA and GA are better than other articles, at least on average, and by a large margin! Please do not take it personally, but I think your elitism might obstruct Wikipedia from moving on. What I mean is that we cannot wait for perfection to be attained before showcasing work. GeometryGirl (talk) 15:19, 8 September 2009 (UTC) We can wait until the processes become more than the prejudices of the ignorant and the incompetent, however. FA and GA are failures - at evaluation; they always have been, and may be expected to continue to be indefinitely. They do far too much showcasing of our worst work as it is; and cause far too much strife in the process. As long as it is very hard to evaluate content, hard to correct the writing of English, and easy to apply the semi-literate prescriptions of the Manual of Style, FAs and GAs will have lots of useless footnotes, a decorative spattering of dashes, and will be - on average - only slightly better than the run of articles - and sometimes much worse. (This of course assumes an equal amount of attention; the mere fact that a dozen editors have looked at an article - and one has presumed to nominate it - means it is better than a stub - usually.) Septentrionalis PMAnderson 15:42, 8 September 2009 (UTC) Far too often, those who cannot write articles review them, and the reviews are exertions of power by those who do not understand the article, the subject, or the English language. I will not give any examples of the worst, because it would be unfair; instead, I will give an example where one reviewer tied up an article for days - on a point where he was, to his credit, eventually convinced he was wrong. Now consider the number of reviews made by less competent reviewers who decline to admit that they were wrong. FA and GA are themselves impediments to improving Wikipedia; the only way through is to ignore them, and above all, not honor these failures. Septentrionalis PMAnderson 15:50, 8 September 2009 (UTC) Well I would be interested to see if a majority of Wikipedians think like you, Septentrionalis. I have not seen many folks like you in the past. GeometryGirl (talk) 16:00, 8 September 2009 (UTC) Oh, we're not hard to find. Look for experienced editors no longer involved in FA or GA, and mention the subject. Many have not enough experience to find, as I do, that the problem is endemic, but that's a difference of degree. Septentrionalis PMAnderson 16:10, 8 September 2009 (UTC) Still not a fan of the change. We've got two colors for links (red and blue), with another derivative color (light blue), all of which is rather easy to determine rather quickly. Someone can click a green link and not see what the difference is once they've arrived at that page (as opposed to a redlink, where they are prompted to create the article, or a blue link, which is an article, or a light blue link, which is an interwiki link). Make it a gadget, that'd be fine, but implementing it as an actual standard feature of the wiki, no. EVula // talk // ☯ // 15:59, 8 September 2009 (UTC) "Someone can click a green link and not see what the difference is once they've arrived at that page (as opposed to a redlink, where they are prompted to create the article, or a blue link, which is an article, or a light blue link, which is an interwiki link)." Interesting point. Did you think you could find some solution to this problem? GeometryGirl (talk) 16:17, 8 September 2009 (UTC) That's the thing right there: I don't think there's a problem that this proposal is trying to resolve. Are people not clicking on links that they'd otherwise be interested in because they're afraid of the linked article's quality? Doubtful. EVula // talk // ☯ // 16:35, 8 September 2009 (UTC) This goal of this proposal is not to "solve a problem", just to "make things better"! "Are people not clicking on links that they'd otherwise be interested in because they're afraid of the linked article's quality?" I'm also doubtful. But that's not the point! The point is to make people read relevant quality articles that they would not have even thought of reading. GeometryGirl (talk) 16:43, 8 September 2009 (UTC) Look, I'm not trying to be a wet blanket, but I'm just not seeing any benefit to this. We don't need to fill our articles with a slew of different colors, especially for the relatively unimportant purpose of drawing people's attention to links that they probably don't care about. It's already possible to over-link and make an article illegible with a mass of blue links; making everything blue or green isn't an improvement. We shouldn't try to "make" anyone read anything; if they're interested, they'll click the link. EVula // talk // ☯ // 20:03, 8 September 2009 (UTC) Why should we want to make readers read particular articles that they're not really interested in? Aren't the FA and GA processes and categories themselves (and the "Featured content" link on every single page) enough by way of showing off?--Kotniski (talk) 16:15, 8 September 2009 (UTC) This feature is not "article forcing", it is a milder "article suggestion" :) similar to "Today's featured article". GeometryGirl (talk) 16:20, 8 September 2009 (UTC) OK, so if I had an extra colour of link to play with, to suggest particular articles to readers, I would base it not on alleged quality, but on alleged close relevance to the subject of the present article. For example, the colour could indicate an article that links back to the current one (implying a close degree of relevance). --Kotniski (talk) 16:28, 8 September 2009 (UTC) That's an interesting suggestion! You should maybe make a proposal... Going back to your previous comment, links in an article are relevant to the article being read, and hence relevant to the reader interested in the article in the first place. GeometryGirl (talk) 16:31, 8 September 2009 (UTC) Agree entirely with Pmanderson. You're presupposing that GA/FA are our best articles; in reality, most of what the GA/FA processes measure is compliance to arbitrary guidelines which have little relevance to actual usefulness. Aside from conforming to the MOS, what makes A215 road or A Ghost Is Born better articles than Winter Palace? – iridescent 16:55, 8 September 2009 (UTC) Actually I am just presupposing that these articles follow the relevant criteria, which are Wikipedia's quality criteria. Isn't it the purpose (although this purpose may not have been attained) of the current quality assessments, to discriminate quality articles? And, as you point out, quality is subjective. But that's the nature of quality, and we have to deal with it. Anyway, you have taken the example of A215 road. To (maybe) reassure you, this link will appear in only very specific articles (I don't know, road articles...) and I'm sure the reader would be happy to know that if he clicks that link he will find a road article that follows MOS and other FA criteria, i.e. what Wikipedia considers to be a quality article. GeometryGirl (talk) 17:04, 8 September 2009 (UTC) To put it another way, green links don't claim to link to "the best" articles, just "quality articles (according to Wikipedia)". GeometryGirl (talk) 17:11, 8 September 2009 (UTC) Wholly opposed to the idea, per Pmanderson. FA/GA, the GA in particular, are far too overrated as it is; there is little community oversight in the process. There is no need to "advertise" these articles any more than they already are. Shereth 17:14, 8 September 2009 (UTC) What if the proposal was limited to FA? Would you be happier? GeometryGirl (talk) 17:16, 8 September 2009 (UTC) If, by "happier", you mean "less stridently opposed", then I suppose I would be. I still see no value in green-linking FAs. It has been my experience that the featured article process is a misguided attempt to demonstrate an article is "good" in that it can abide by the vagaries of the Manual of Style, and has very little to do with the quality of the information in the article itself. Again, I see no reason to promote the process as it stands by making links to these articles more visible. Shereth 17:20, 8 September 2009 (UTC) Sorry, I don't agree at all, and you seem to be missing the point; Shereth has it spot-on. FA and GA aren't "Wikipedia's best articles", they're "Wikipedia articles, which conform to the Manual of Style, have appropriate alt-text on the images, and whose primary contributor has decided to submit them to the timesinks of GAN/FAC". Plenty of our most prolific writers don't submit anything to the assessment processes (Giano is one who springs to mind); many, probably most, of our best articles will never qualify for GA/FA without major rewrites due to MOS issues, or a primary contributor who's either left the project or isn't interested in FAC. Plus, most obviously, Wikipedia has 10,000 active editors but 10 million readers, and those readers who aren't editors will have no clue what GA/FA represent and will likely take them as some kind of endorsement. (Imagine the furore when Gropecunt Lane was on the main page, multiplied almost infinitely as users find themselves directed towards 1987 (What the Fuck Is Going On?), Super Columbine Massacre RPG!, Fuck the Millennium, 1993 child sexual abuse accusations against Michael Jackson, The Year of the Sex Olympics...) Sorry, but I really do think this is an unsatisfactory solution, to a non-existent problem, that will only confuse our users. By all means make it a gadget, but something this arbitrary should never be a part of the standard software. – iridescent 17:23, 8 September 2009 (UTC) I think I got your point Iridescent. Thanks. But something bothers me. There are many opponents to the FA process! Why does the FA process still exists? Why haven't the plentiful opponents removed time/energy sink from Wikipedia? GeometryGirl (talk) 17:30, 8 September 2009 (UTC) Because we have no interest in tilting at windmills; the process of trying to get rid of it would be a time/energy sink in and of itself, and there are better things to be concerned with. If people want to while away their hours amassing rows of gold stars to display on their user pages, then I say more power to them - but I will oppose efforts to further glorify the process. Shereth 17:32, 8 September 2009 (UTC) And it will be tilting at windmills: FA, especially, does have some utility - just not as an evaluation mechanism; those who point this out will be supported by all those who are pleased by the present system. Editors like GA because getting stars for articles without having to go to the effort of writing good ones can be pleasant; on the other hand, every Language Reformer at Wikipedia will swarm, first to get their pet fix written into the Mass of Stupidity, and then to enforce it at GA and FA. Septentrionalis PMAnderson 18:35, 8 September 2009 (UTC) (ec) There are 10,000 active editors. How many names do you see at WP:FAC? And I speak as someone who does still participate there; I doubt that even the most ardent supporters of the FA/GA processes would dispute that the current process-creep and "oppose, article fails to comply with MOS subsection 43.4.3(m)" crowd are driving people away (just read this thread...). – iridescent 17:33, 8 September 2009 (UTC) I worry about communicating to readers that these are "approved" articles, when our approval process doesn't include elements like fact-checking that most readers would assume were present. This seems like a useful gadget, but not an appropriate default setting. Christopher Parham (talk) 17:48, 8 September 2009 (UTC) "Reply: Per WP:Performance, users should not worry about performance." - WP:PERF applies to things done in the normal course of using the site and policy decisions. Proposed changes to the MediaWiki software or changes to global JavaScript, as this would require, do need to worry about performance. Mr.Z-man 17:32, 8 September 2009 (UTC) Good point. To be honest, I know nothing about it! Why don't you edit the Q&A yourself to reflect the matter? GeometryGirl (talk) 17:38, 8 September 2009 (UTC) I'm opposed to giving FA/GA articles special wikilink colors. We can't even get consensus on whether GA articles should have an icon on the article page, so I doubt there would be consensus for turning their wikilinks a special color. In general, I think that this system of multiple wikilinks colors would confuse most readers. I'm an experienced editor, and I don't think it would be very helpful. I am not more likely to click on a wikilink because the article is rated highly; I am likely to click on the wikilink if I am interested in the topic. Karanacs (talk) 19:43, 8 September 2009 (UTC) Unlike most of the editors who have opined here, I don't think the MOS-creep problem is not nearly as prevalent or burdensome as some think it is, aside from the alt text requirement (which arose recently). However, I'm opposed to this wikicolor proposal because a) as Karanacs said, links are for topics relevant to the subject, not for high-quality articles; b) not all FAs and even more so GAs are created equal; and c) the extra colors would confuse and distract readers from what they are reading. Dabomb87 (talk) 21:27, 8 September 2009 (UTC) Iridescent, I'm dying to see examples of high-quality articles that failed FAC because they failed a single MOS criterion. Seriously, show us some, and we'll be happy to address them. I don't doubt that there are occasional problems, but saying a problem is epidemic and not offering any examples is weak. I think all this furor against FAC/GAC is sour grapes by people who don't like having to go out of their comfort zone. Following the MOS is not hard (you can always ask for help) and any point in the MOS is there for a reason. That said, I'm not sure whether I agree with this proposal. I agree with Karanacs that we shouldn't have colors on Good Articles unless there's an icon to go with it, and that's a very different discussion. And to color only FA links seems pretty worthless – FAs are so rare that the links will be more of a distraction than anything. Noisalt (talk) 21:56, 8 September 2009 (UTC) Er... my record at FAC reads 9 nominated, 9 passed; I'm not sure you can really accuse me of sour grapes here. Most of the current problems are summed up here; if you want specific recent examples of what I'd consider high-quality articles being opposed over trivia, try [6] and [7] are a couple of recent ones off the top of my head, but everyone will have their own favourite example (just search the recent archives for "too many redlinks"...). – iridescent 22:18, 8 September 2009 (UTC) "Too few links" is a rare comment (not even an oppose there), but I will concede that fair-use images have become far more contentious lately. However, that doesn't prove that MOS issues are burdensome at FAC—perhaps except that complaints about alt text are quite frequent. Dabomb87 (talk) 22:36, 8 September 2009 (UTC) (ec) Mr iridescent, please. Your first example of what you "consider high-quality articles being opposed over trivia" is slightly unfair. The point was maybe trivia for you but it was just a comment, not an opposition as you claim. @Dabomb I didn't say there was "too few", just "few". GeometryGirl (talk) 22:39, 8 September 2009 (UTC) In reply to both of the above : the essential thrust of the argument is that these types of nitpicking opposes or "comments" have a habit of placing a large amount of emphasis on style while routinely glossing over content. The one time I tried my hand at getting something featured, I spent far more time chasing after stray dashes, tweaking alt text and weeding out single unspelled digits than paying any attention at all to the actual content thereof. While in the end the attempt was successful, it was not a process I would like to repeat again. Shereth 22:43, 8 September 2009 (UTC) IMO, in an ideal content review process, the article submitted would already be comprehensive, neutral, accurate and suitably referenced to reliable sources, meaning that the only issues that would need to be resolved should probably be minor prose/stylistic/formatting points. Dabomb87 (talk) 22:49, 8 September 2009 (UTC) Well, yes, if an article does not require review, FA would not have to do one; if we had a review system that did FAC's work for it in checking accuracy, verifiability, neutrality, and clarity, FAC could then tweedle ad libitim about "MOS breaches" without much further harm. But is an FA like that any use whatever to the encyclopedia? Septentrionalis PMAnderson 14:57, 9 September 2009 (UTC) In case of confusion, GeometryGirl and I are unrelated. I haven't considered this proposal in detail, but I can see the idea and its merits. If I were proposing something similar, I would keep blue-links in general, and suggest something between blue-links and red-links (yellow-links?) for articles that existed but are not currently of much help to the reader. I've no idea how such a criterion would be defined or implemented, but "not yet a GA or FA" is not the right choice as these account (depressingly) for about 99.7% of our articles (I sincerely hope we can make an impact on that appalling figure in the coming years). Anyway, I'm certainly not proposing anything, but am open minded to any ideas which might help readers. Geometry guy 00:55, 9 September 2009 (UTC) Thank you for raising this proposal, and for leaving a message on my userpage about it. It seems to me that the rationale for this proposal was different to your that for your above rationale for the "orange links" one - you took the view there that certain orange links would be a good way to get Wikipedians to improve certain articles, just how red wikilinks, you claimed there, help Wikipedians to create new articles. For this very reason, I am not too sure of this suggestion. This is only my own personal view, but I cannot quite work out why you may wish to draw attention to articles that do not need improvement. Please do not take that comment the wrong way - it is only my own humble view, and I expect you have good reasons for this proposal. ACEOREVIVED (talk) 19:55, 9 September 2009 (UTC)

Stub edit tab: emphasis and invitation

Archived

For stubs, I suggest having the edit tab changed from edit this page to edit this stub. Why change "page" to "stub"? The word "stub" is more of a invitation to contribute. Indeed, "stub" suggests work is needed and that the reader is welcome to help. This would help create editing micro-opportunities. Why orange? Orange is a more "visible" colour than the current blue. Orange is similar to red, underlying the similarity between stubs and nonexistent articles. Discussion (edit tab) Don't bite too hard! :) GeometryGirl (talk) 11:56, 9 September 2009 (UTC) To more directly address the stub proposals though: You gloss this over potential problems section above, but the fact is that stub articles are not really special, and certainly should not be singled out as potentially needing attention. The root of this proposal seems to lie in a fundamental misunderstanding of what a Wikipedia:Stub article actually is. — V = I * R (talk to Ω) 13:04, 9 September 2009 (UTC) "A stub is an article that is too short to contain suitably encyclopedic material" is the definition of a stub. Since this is indeed an encyclopedia, I think that means this most definitely does mean that they should be singled out as needing attention, and not just potentially. A stub article is not appropriate for an encyclopedia. I have seen some editors say "some articles just cant ever get beyond a stub", the correct response to those people is- 1- the article shouldnt then exist and should probably be merged with similar stubs as a list article or 2- its a short article but not a stub, a short article that has encyclopedic content and is a good article can be classified as more than a stub even an FA. I see no misunderstanding in what a stub is in this proposal, give good faith that people know what they are proposing, since doing otherwise and lecturing that they dont is bad-faith. With that done I do have to say that this is still a bad idea because its simply semantics. Who cares if it says "edit this article" or "edit this stub", it wont actually bring in more editors in my opinion.Camelbinky (talk) 13:35, 9 September 2009 (UTC) That is very much my point, thank you Camelbinky. What do you think of the orange link proposal above? And why don't you think making the link orange will not attract more people? GeometryGirl (talk) 13:40, 9 September 2009 (UTC) I see that is what the lead says now, but if you actually read the document it does (more accurately) state that stub articles are not specifically an issue to be resolved. Some articles should be stubs, and there's nothing wrong with that. They simply don't need attention due to the fact that they are stubs alone. — V = I * R (talk to Ω) 13:55, 9 September 2009 (UTC) (edit conflict)Actually, merits aside, I have to wonder if this is technically feasible. Presently, tab names are assigned based on namespace, with no regard for content. --King Öomie 13:42, 9 September 2009 (UTC) That's what I was attempting to get across, above. It's really not technically feasible right now. — V = I * R (talk to Ω) 13:55, 9 September 2009 (UTC) Well, it COULD be done, but it'd have to be global javascript, and could potentially play hell with people's Monobooks. Again, not seeing a possibility of global deployment. Looks fine for opt-in, though, I'm sure a script could do it (you can already reduce the "Discussion" tab to "Talk"). --King Öomie 14:00, 9 September 2009 (UTC) While well intentioned, I find it extraordinarily doubtful that this change would result in any increase in the amount of stubs being upgraded. It is the article/subject itself - not an orange link at the top - that determines whether or not someone is interested in editing it. Shereth 16:21, 9 September 2009 (UTC) Why are there 300 000 000 different viewers a month but only 90 000 active editors in a given month? Come on! It's not just "the article/subject itself". Sure, that is a necessary condition, but it surely is not sufficient. GeometryGirl (talk) 16:30, 9 September 2009 (UTC) I don't follow your point. There are 300M visitors but only 90K editors because the vast majority of people are interested in reading, not editing. Visitors know Wikipedia is editable by anyone. As a general rule people edit articles that interest them. Put simply: if I am looking for information on Horse Mesa Dam, I go to the article and find very little information, so I move on to another source. How is changing the color of the "edit" link is going to cause a revelation that I should jump in and improve the article? I appreciate what you are trying to do, but colorizing the tabs at the top is not going to incite people who have no interest in editing to chagne their minds. Shereth 16:44, 9 September 2009 (UTC) My point is that Wikipedia is giving out the wrong message with everything blue. Basically, the current message is "you can edit Wikipedia if you want, but we are doing fine without you". The message Wikipedia ought to give is "you can edit Wikipedia and we really need you to do so". Get my point? GeometryGirl (talk) 16:47, 9 September 2009 (UTC) To put it another way, Wikipedia needs money, and they periodically ask for donations. Well Wikipedia also needs editors, and we should be advertising the NEED, not just the possibility of becoming an editor. There is a real need... (and a lot of potential). GeometryGirl (talk) 16:51, 9 September 2009 (UTC) I get your point. I don't agree with it. I do not agree that bluelinks imply "This article is finished and doesn't need improvement". I do not see how orange links would thusly imply "This article needs help", and I especially do not see how the casual reader is going to understand that implication. Moreover, I don't think you get my point. People who are not here to edit are not here to edit; changing link colors is not going to change that fact. People who are here to edit, edit what interests them; changing link colors is not going to change that fact. Again, I appreciate what you are trying to do, but I just don't see this as doing anything to help. Shereth 16:53, 9 September 2009 (UTC) So you do not think that there are people who come to Wikipedia "to read", would be willing to contribute, but do not contribute because they do not feel the need to contribute, or are not prompted enough to contribute? (Because, e.g., Wikipedia already has 3 000 000 articles and is doing just fine.) GeometryGirl (talk) 16:57, 9 September 2009 (UTC) The goal is to convert people from readers to editors. Really basic. GeometryGirl (talk) 16:59, 9 September 2009 (UTC) As Shereth said, everyone who comes here knows that anyone can edit. It's on the logo. If they don't WANT to edit, and they come across a lackluster page, they're STILL not going to want to edit. It doesn't matter how colorful the blown piston is, I still don't want to learn how to fix my engine. The tab name change is fine, for consistency's sake, but the color change is really not required. --King Öomie 17:04, 9 September 2009 (UTC) (ec, response to GG) No, I don't think so. Take an example. I am a casual reader who is willing to contribute, and I go to Horse Mesa Dam. I see that the article is really short, and even has stub templates that say "This article ... is a stub. You can help Wikipedia by expanding it." Are you saying that, when I go to hit the "edit this page", I will see the blue link and therefore conclude "Oh wait, it is bluelinked, they must not need my help?" Really, I should be dispensing with all of these hypotheticals and simply ask : how does an orange link (as opposed to a blue link) convey, to the causal reader, that we really want their help? If they are a casual reader, how are they supposed to understand this distinction between blue and orange links? I agree with your goal of trying to entice readers to become editors. Put simply, however, orange-linking a tab is very unlikely to contribute to this goal. Shereth 17:07, 9 September 2009 (UTC) (e/c)I think you're completely misunderstanding his argument. I agree with Shereth. Bluelinks do not imply that the article is complete, or doesn't need any work. I don't what you're basing that on, other than personal opinion. Every article could be improved. No article is ever "finished" I don't see how changing link color is going to do anything other than make articles harder to read and introduce accessibility problems for people with poor vision (orange text on white background has rather poor color contrast, and I believe it fails WCAG AA priority level). Mr.Z-man 17:08, 9 September 2009 (UTC) I agree with you guys, bluelinks do not imply that the article is complete, or doesn't need any work. I agree. However, what I am saying is that there is a difference between "YOU CAN EDIT" and "YOU NEED TO EDIT"? I agree with you, most people know that they can edit. But do they know that Wikipedia needs them? For you engine, you can just ask a mechanic. But Wikipedia is volunteer based... Can't ask people other than our readers. I really don't see how the proposed change reflects that though. It relies too much on implied meaning by color and a slight wording change. Imagine if {{cleanup}} was nothing but a box with a picture of a broom in it. 1) I don't think the connection is very obvious and 2) As Shereth said, people edit what they're interested in, not what we tell them they should be editing. Mr.Z-man 17:21, 9 September 2009 (UTC) And in response to GG, in the case of a busted engine, I'd likely rely instead on the volunteer network of 'My Neighbor Jeff', who keeps my car running because I do the same for his computers. --King Öomie 17:28, 9 September 2009 (UTC) Pale orange, as proposed, is barely visible. It looks darker on cheap uncalibrated office-type LCDs; step up to a properly calibrated screen, you'll be amazed how light it is. As long as background is white, orange is a no-no. On a completely different issue, don't rely on article ratings below FA. Never. English wikipedia has no way of enforcing consistent and reliable article ratings. Take a look at this diff. Stub to GA. Guess what? It was not a stub. It was not GA either. How long could it go unnoticed? NVO (talk) 17:14, 9 September 2009 (UTC)

Stub edit tab: new proposal

Dismissed for now

For stubs, I suggest having the edit tab changed from edit this page to please edit this stub or please edit this stub or Please edit this stub pr Please edit this stub. Why change "page" to "stub"? The word "stub" is more of a invitation to contribute. Indeed, "stub" suggests work is needed and that the reader is welcome to help. This would help create editing micro-opportunities. Why add "please"? To make readers understand that they contribution is required for Wikipedia to exist and evolve. "Please" also formally expresses an invitation to contribute. Why red? Red is a more "visible" colour than the current blue. Red expresses the similarity between stubs and nonexistent articles. Red expresses a need. Orange is too pale. Why green? Because red links on Wikipedia exclusively mean "this page does not exist". Why stubs? Because stub articles are not appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material". Also, new editors would less likely get lost in the small amount of wikisyntax contained in stubs. Finally, in many ways, improving a stub is easier than improving a developed article. For who? For all readers by default. Discuss (edit tab new proposal) Don't bite! GeometryGirl (talk) 17:27, 9 September 2009 (UTC) Weak Oppose Working through the rainbow now. Red links on Wikipedia exclusively mean "this page does not exist". --King Öomie 17:32, 9 September 2009 (UTC) Ok, we can find some other colour. Green? GeometryGirl (talk) 17:34, 9 September 2009 (UTC) And subconsciously suggest that the article is fine? The full gamut of begging readers to expand the stub is accomplished by the {{stub}} template itself- if that won't sway them, more pressing will only serve to irritate. <Creative slippery-slope argument that sways your opinion> --King Öomie 17:36, 9 September 2009 (UTC) (ec) I don't want to badger you. Really I don't - I like what you are trying to do in encouraging more participation and in getting more readers to become editors. Really. This proposal, however, is just the last one re-done in new colors. The choice of color (red, blue, green, orange, magenta, ultraviolet, whatever) is not relevant. Even the wording ("Edit this page", "edit this stub", "please edit this stub", "We really need some help expanding this stub so please lend us your expertise and expand it into something bigger") is of little relevance. The whole point of my argument is that a tab at the top of a page is not going to encourage participation in the project. The ultimate goal of this proposal is noble but at the moment the energies here are being misdirected down a dead-end street. You are aware that the wording of pretty much every single stub template reads "This article ... is a stub. You can help Wikipedia by expanding it." The appeal has already been made, making it again is expending effort where it is not effective. I'm sorry, I just can't support a proposal that has little to no real benefit to it. Shereth 17:37, 9 September 2009 (UTC) Have you tested this proposal? Does it really have little to no benefit? That's slightly pretentious. But anyway, the template says "You can help Wikipedia" and not "please help Wikipedia" (in the same way that we have "Please donate" and not "You can donate"). It is a (subtle) matter of sending the right message. GeometryGirl (talk) 17:41, 9 September 2009 (UTC) Then perhaps your energies would be better spent on trying to refine existing mechanisms (by proposing changes to the stub templates) rather than by trying to re-invent the wheel? Shereth 17:44, 9 September 2009 (UTC) Please, assume good faith, and don't bite. Why not even do both? (For the template, I hadn't even thought about it.) GeometryGirl (talk) 17:46, 9 September 2009 (UTC) Pardon? I'm not sure where I have failed to assume good faith or violated WP:BITE? I have made every effort to be civil with my replies and I expect not to have these kinds of policies waved in my face for no apparent reason. As far as "why not do both" - it is woefully inefficient to do something twice when once will suffice. Modifying templates requires simple edits, whereas what you are proposing requires changes to the MediaWiki software itself. When a simple solution exists, why continue to pursue the more complex? Shereth 17:50, 9 September 2009 (UTC) Well you where saying I was "reinventing the wheel" when that was not at all my intention (faith). Maybe I just took the comment badly after all the negative comments I have been having in exchange of all the time I am donating. I have created a new proposal below. GeometryGirl (talk) 17:55, 9 September 2009 (UTC) Proposing something has become a battle. It seems editors are having the same problems with editing. No wonder editors are leaving. GeometryGirl (talk) 17:57, 9 September 2009 (UTC) Pass/fail statistics aren't subject to a grade curve. --King Öomie 17:59, 9 September 2009 (UTC) I think this has almost all the same problems as the orange proposal. It still relies too much on the meaning being implied by using colors and "stub" instead of "page." It doesn't have the accessibility problems of orange. However, green sends the wrong message entirely. Green suggests that the article is fine, a lot more than blue does. Red on the other hand, would be confusing by having it serve 2 different (albeit related) purposes. And to reply to some recent comments, proposing things is a discussion. If nobody disagreed with the idea, chances are we'd already be doing it. Mr.Z-man 18:05, 9 September 2009 (UTC) Again, I'm not sure why changing the edit tab would encourage editors; there's a lot of made-up "this would help!" arguments being made, but without any explanation as to why or how. EVula // talk // ☯ // 18:07, 9 September 2009 (UTC) (edit conflict)Ok, make it blue, but underline it, I don't know. What do you think of Please edit this stub? ...why? Why would it be underlined? None of the other tabs are, and it's more important (in my mind) for things to be consistent. EVula // talk // ☯ // 18:12, 9 September 2009 (UTC) OK, OK, as you want. Remove the underlining, Please edit this stub GeometryGirl (talk) 18:21, 9 September 2009 (UTC) @EVula Why this would help? Because it changes the attitude Wikipedia has towards readers. Instead of saying to them "you can edit this page" which doesn't imply any need for this page to be edited, Wikipedia would say "please edit, you must!". It's a PR campain. GeometryGirl (talk) 18:12, 9 September 2009 (UTC) Ah, that's why we disagree: you are wrong (I mean that in the nicest way possible, but after so many proposals in short order where everyone has been nice, I feel that someone needs to be a bit more blunt about it). Our readers don't have to edit Wikipedia; to say that they must is a lie. We, of course, would like to encourage more readers into getting involved, but honestly, it just plain isn't something for everyone. We need to remain open so that anyone can edit, but we don't need to be going out of our way to make sure that everyone does edit. As it is, I'm still not sure how "please edit" will achieve any sort of change whatsoever; I really think you're wasting your (apparently boundless) energy. You'd be better served trying to figure out a way to make editing more approachable by those readers who are interested in editing, rather than trying to fit square pegs into round holes. EVula // talk // ☯ // 18:21, 9 September 2009 (UTC) I exaggerated a bit when I said "they must". But please see this video, it is my inspiration. GeometryGirl (talk) 18:25, 9 September 2009 (UTC) I don't what to badger you either, but ultimately I agree with Shereth. I ahve all along, actually. I agree with the underlying goal here (encouraging participation), but this just isn't he means to achieve it. I can tell that you're feeling a bit embattled here, and for that I'm really sorry especially since you're obviously highly motivated to address the participation issue. I don't want to discourage you at all, and I don't think that Shareth or anyone else does either. We're just trying to say that you're energy is currently misdirected a little bit, is all. My recommendation is to check out, and jump into participating in and assisting, the Usability Initiative. This whole subject area is exactly what their tasked (and funded!) with pursuing. — V = I * R (talk to Ω) 18:13, 9 September 2009 (UTC) Thanks for the advice. I have already posted two proposals (one for green links, and one for orange links) on the usability wiki. The project seems dead, no one participates. Money doesn't make everything... GeometryGirl (talk) 18:19, 9 September 2009 (UTC) A lot of people participate, actually. My watchlist moves faster than my car. --King Öomie 18:23, 9 September 2009 (UTC) Well not mine! What is on your watchlist? GeometryGirl (talk) 18:26, 9 September 2009 (UTC) Approaching 400 pages. I could add WP:AIV and WP:ANI to make it REALLY fly. --King Öomie 18:46, 9 September 2009 (UTC) Oh, so you are watching every page! Well I'm just watching two, and they are basically dead. I looked around other pages and haven't found very active pages... GeometryGirl (talk) 18:49, 9 September 2009 (UTC) I'm watching less than 0.014% of all the articles on En. Non-contentious articles can remain stagnant for weeks, and tend to see a flurry of activity when the subject is reported on in some fashion (read: Colbert). This is perfectly normal. Try following Barack Obama. Articles like Nickelback are plastered with vandalism multiple times daily (and my heart goes out to the vandals, they who know the truth, but lack the means to express it civilly :D). --King Öomie 18:57, 9 September 2009 (UTC) She was talking about at the Usability Initiative, not en.wikipedia. — V = I * R (talk to Ω) 19:03, 9 September 2009 (UTC) Hmm, I'm not sure. She referred to posting these proposals twice, and then referred to "the project" as dead, which I interpreted as the entire project. --King Öomie 19:07, 9 September 2009 (UTC) Quote: "I have already posted two proposals (one for green links, and one for orange links) on the usability wiki. The project seems dead, no one participates." :) — V = I * R (talk to Ω) 19:09, 9 September 2009 (UTC) Quote: "The project seems dead, no one participates." :D Final word goes to GG. --King Öomie 19:12, 9 September 2009 (UTC) I was talking about the usability wiki, obviously. Thank you Ohms law. GeometryGirl (talk) 19:52, 9 September 2009 (UTC) =( --King Öomie 20:16, 9 September 2009 (UTC) Just because they don't use the wiki that much doesn't mean the project is dead. Its still very much active on the software development side. Mr.Z-man 21:59, 9 September 2009 (UTC)

Changing the stub template

Proposed at WP:Stub

I propose to change to This article is a stub. Please help by expanding it. or something similar. If I'm not mistaken, this belongs at Template talk:Stub. But for good measure, Support. --King Öomie 18:00, 9 September 2009 (UTC) Actually, there are about 20,000 stub templates. I'm not really sure where it should go. --King Öomie 18:02, 9 September 2009 (UTC) Thanks to one very sexy bot operator all stubs are now built with Template:Asbox. One simple change could make that phrase green, whether there is consensus to do so is another story. Discussion about that should occur here or maybe at WT:Stub. –xenotalk 18:04, 9 September 2009 (UTC) All narcissism aside, I'd think a notification of this discussion at WT:STUB would be sufficient. But of course, we are all very thankful for sexy bot operators :) Shereth 18:12, 9 September 2009 (UTC) I'm not sure where the obsession with green is coming from, but it's getting ridiculous... EVula // talk // ☯ // 18:10, 9 September 2009 (UTC) Happier now? No green? Please, I wrote "or something similar", be constructive. GeometryGirl (talk) 18:14, 9 September 2009 (UTC) I can support a wording change but I am not a fan of the current format. Why the green? Shereth 18:12, 9 September 2009 (UTC) Changed the colour. GeometryGirl (talk) 18:15, 9 September 2009 (UTC) This is a potentially helpful tweak: please raise it at Template talk:Stub. Geometry guy 21:30, 9 September 2009 (UTC) I have just had a thought. As any lecturer who has presented using overhead acetates or Powerpoint will know full well, one has to be very careful with choice of colours, so as not to confuse students who may suffer from colour blindness. Are you sure that your choice of colour scheme will not do this? One thing I should say is that perhaps the most common form of colour blindness is red-blue colour blindness - so perhaps you are right, we do not need to change the colours of wikilinks! ACEOREVIVED (talk) 23:11, 9 September 2009 (UTC) I have a feeling I was actually thinking of red-green colour blindness - please, pleaes, consider this. Although I do not suffer from colour blindness myself, remember, Wikipedia should be accessible to all. ACEOREVIVED (talk) 23:23, 9 September 2009 (UTC) FWIW, red-green is the most common form of colourblindness, followed by total colourblindness, then blue-yellow - though that's all beside the point. I have a question, though... why is this change being proposed? If it serves no purpose (and for the life of me I can't see what purpose it would serve), then it simply seems to be wasting effort. What difference does centring the text do other than moving the icon away from the left margin and potentially making formatting look odd in a few cases? Similarly, what difference would changing the colour make other than making readers wonder whether the stub message is a hyperlink? In both cases it would increase the visibility of the stub template (something which we've been doing as much as possible to avoid at WP:WSS - the more discreet a stub template is, the better), but other than that, it wouldn't really make for any other than a cosmetic change. By the way, King Oomie is right - changes to the stub template(s) are normally discussed over at either Template talk:Stub or at Talk:Stub. Indeed, there have been numerous suggestions on changing the look of stub templates there in the past in many different ways - including, IIRC, a rejected suggestion to centre stub messages. Grutness...wha? 01:27, 10 September 2009 (UTC)

Auto update?

It would be cool if http://en.wikipedia.org/wiki/Special:Statistics auto updated. Accdude92 (talk) (sign) 13:14, 10 September 2009 (UTC)

The page would have to be a dynamic frontend, and I'm not sure that's technically possible on Wikipedia at this point. --King Öomie 13:27, 10 September 2009 (UTC)

It does "auto-update". That page is part of the software, and is updated as part of a batch job on the server. That's my understanding, at least. It's not real time, but it is regularly updated.
— V = I * R (talk to Ω) 13:29, 10 September 2009 (UTC)

90% sure he means dynamically updating without having to reload the page. That's what my response was referring to, anyway. --King Öomie 13:31, 10 September 2009 (UTC)

(edit conflict)(edit conflict) i would like it to update in real time.Accdude92 (talk) (sign) 13:33, 10 September 2009 (UTC)

The dreaded double-conflict? Ouch. Again, that would be a WHOLE lot of coding work, not to mention possible performance issues, for an update that would really only be "increased coolness", with no actualy fuctionality boost. --King Öomie 13:39, 10 September 2009 (UTC)

lol yep, its the wikipedia apocalypse!!! Anyways, since this is the proposal section, I just posted this as an idea. So no hard feelings.Accdude92 (talk) (sign) 13:42, 10 September 2009 (UTC)

No, none at all. I agree, that would be cool (I'd love to see that for the Watchlist, as well as sorting and dynamic searching), but it's just not feasible. --King Öomie 13:48, 10 September 2009 (UTC)

Wow, it just kicked me an edit conflict over converting '~~~~' to my sig... --King Öomie 13:50, 10 September 2009 (UTC)

I told you its the wikipedia apocalypse!Accdude92 (talk) (sign) 13:55, 10 September 2009 (UTC)

Almost all of the statistics are up to date when you load the page. I think the "active users" count is the only thing that isn't. However, most of the statistics (except the number in each user group) are off somewhat anyway. The total number of pages is off by ~57,000. The number of images is off by ~8,500. The number of user accounts is off by ~29,000. (All of the numbers on the statistics page are lower than the actual.) There's no real efficient way to calculate the number of articles in the same way used to increment the count for the statistics, but its probably off by ~7,000. Mr.Z-man 18:22, 10 September 2009 (UTC)

warning?

I think wikipedia should have a warning at the top of the main page saying that since anyone can edit here, its not a good school resource.Accdude92 (talk) (sign) 13:56, 10 September 2009 (UTC)

See disclaimer at the bottom of every page. ♫ Melodia Chaconne ♫ (talk) 14:11, 10 September 2009 (UTC)

i know, but I think that it should be made clearer.Accdude92 (talk) (sign) 14:25, 10 September 2009 (UTC)

I know where you're coming from, but the fact is, most articles are FINE to use as citations (with exceptions for old-fashioned or close-minded professors), especially because they contain references themselves. More warnings about Wikipedia not being a reliable source would really just make the site look foolish. "WARNING, DON'T BELIEVE ANYTHING YOU READ HERE" ...then what's the point at all? Why not just shut it down? --King Öomie 14:30, 10 September 2009 (UTC)

Also, "WARNING, DON'T BELIEVE ANYTHING YOU READ HERE" is self-referential in a way that's liable to make your head hurt if you think about it too much. :) Rd232 ^talk 14:40, 10 September 2009 (UTC)

"ONLY BELIEVE THE PREVIOUS WARNING IF YOU FOLLOW THIS INSTRUCTION" --King Öomie 14:45, 10 September 2009 (UTC)

Most articles are fine to use as citations? Eh? Citing Wikipedia is a pretty terrible idea at the college level, and probably not a very good idea in high school either for any sort of serious research writing. I mean, even on Wikipedia we don't consider Wikipedia to be a reliable source. Mr.Z-man 17:40, 10 September 2009 (UTC)

We can't cite Wikipedia in articles because that would cause a circular reference. I could change a page, cite the new information elsewhere, and then cite my addition with the page I just used it as reference. Regardless, the large warning being discussed here would be redundant to the general disclaimer, and if a particular professor refuses to accept papers that use Wikipedia as a reference, he'll put it in the class syllabus. Also, see below. --King Öomie 17:58, 10 September 2009 (UTC)

Its not about what professors will accept. Its just poor research to use tertiary sources, especially ones with no official fact-checking or peer-review, by, effectively, an unknown author as a citation in a serious research work. Mr.Z-man 20:05, 10 September 2009 (UTC)

Unless and until every page on the internet carries such a warning – in boldface, above the title – I'm not sure that we need to be more thorough about this. TenOfAllTrades(talk) 15:01, 10 September 2009 (UTC)

Microformats in stubs redux

A number of stub templates already emit microformats. I have made a request for a change to {{Asbox}} to facilitate their use with less inline HTML markup, but a couple of editors have expressed concerns. Additional input (at that page, please) would help. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:33, 10 September 2009 (UTC)

Creating micro-opportunities: a new colour for stub wikilinks

Note: The coloured link proposal has evolved to what is now a more mature proposal, explained below. For clarity I have made a new thread. I have also added a poll. GeometryGirl (talk) 23:12, 10 September 2009 (UTC)

Description

What?

Wikipedia currently uses two colours for links, namely blue for existent articles and red for nonexistent articles. This proposal suggests using yet a different colour for stubs. The goal is to engage readers in article contribution, specifically stub expansion.

Why?

Micro-opportunities for user participation currently exist, such as red links, that stimulate article creation. However, red links have become rare and the focus is nowadays on expansion and improvement, rather than creation. With most links blue, an impression of completion transpires, and not much enticement to participate is provided. This proposal attempts to address both the deceptive appearances and the lack of enticement.

Why stubs?

Because stub pages not are appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material". Also, in many ways, stubs are much easier to improve than developed articles.

How?

Using scripts similar to this one and this one.

For who?

Non logged-in readers will not be affected, to avoid confusion. This will be an opt-in option (i.e. not enabled by default) for registered users, advertised via a sitenotice or a watchlist notice.

Which colour?

The choice of colour will be left to the discretion of each user, according to preference and sight (e.g. colourblindness).

Which Wikipedia?

This proposal is first intended to the English Wikipedia, but other Wikipedias may be interested in a similar functionality.

Past experiences

User:Charles Edward

"I have a script like the ones mentioned above for some time and find it very helpful. Anything that encourage a growth in quality is good in my book."

User:Floydian

"Having coded my own version of this into my monobook theme, I have noticed how much of an effect the orange links have on me. They immediately stand out above things and they make me want them to be blue."

Potential problems

Stub articles are not necessarily articles that people want to edit.

The extra colour merely suggests stub editing, like red links suggest article creation.

This proposal assumes that stubs are Wikipedia's worst articles.

The extra colour focuses on undeveloped articles, no assumption of quality is made.

This adds complexity to the linking system and will cause confusion.

Only logged-in users will be affected to limit confusion, and registered users can decide not to use an extra colour.

Some undeveloped articles have no rating.

Links to these articles we be blue until appropriate rating is done.

There are potential performance problems.

No programmer has expressed his/her concern as of yet.

A different colour for stubs might prove obnoxious for some readers.

Each registered user will decide if he/she wishes a new colour for stubs.

The colourblind may not distinguish the different colours.

Each registered user will be able to decide the colour he/she wishes to use.

Discussion (new colour for stubs)

Past discussion (agreeing on the details)

Don't bite too hard. :) GeometryGirl (talk) 11:59, 9 September 2009 (UTC) I admire your dedication, but I'm still not convinced that the basic underlying idea is a good thing here. What exactly is a stub article? Those articles that are less then X bytes? Articles with a {{stub}} templates on them? Without addressing the fundamental question of how to unambiguously determine the state of all articles I'm unwilling to support any of these proposals. I personally am ready and willing to discuss the addition of some sort of added "quality field", "assessment property", or some other such thing to articles, but unless and until that it implemented all of these proposals are premature. — V = I * R (talk to Ω) 12:43, 9 September 2009 (UTC) Ok, let discuss this! What do you propose? GeometryGirl (talk) 12:58, 9 September 2009 (UTC) I tried to in the first proposal, but the bulk of that seems to have been overlooked. Before any of these can be implemented, something needs to be added to the software itself so that internal links can be given CSS classes based on article quality. Using the category system is a bad idea for two reasons: Categories are not required to be used on articles at all, which is important because we're talking about replying on some property to determine how pages are rendered. If there isn't a specific property for the software to rely on, then these proposals are pretty much dead in the water from a programming perspective. Categories are not intended to be used in this matter. They currently are, but that could be changed at any time, and then where would that leave this system (assuming that it was somehow implemented)? Assessments can currently utilize the category system because nothing in software is currently reliant on article assessment, but if that changed then something would specifically need to be done to prevent the categories from ever changing. Stubness suffers from the exact same issues here. This doesn't even address the concerns with the current quality assessment systems in use here on the English Wikipedia, which I think are fairly significant. The fact is that some significant groundwork is required before even considering these specific proposals. — V = I * R (talk to Ω) 13:20, 9 September 2009 (UTC) For who: "All readers by default." Why on earth? People have heard tales of Wikipedia's upcoming "orange text" system, adding orange links at this time would confuse readers to an INCREDIBLE degree. Leave it as a gadget, if anything (I'd certainly use it), or even a custom userscript. --King Öomie 12:48, 9 September 2009 (UTC) I haven't heard of "tales of Wikipedia's upcoming "orange text" system". And saying that "orange links at this time would confuse readers to an INCREDIBLE degree" is highly speculative. GeometryGirl (talk) 12:58, 9 September 2009 (UTC) Not so much. [8][9][10][11][12][13][14][15][16][17] --King Öomie 13:25, 9 September 2009 (UTC) Ah, I see. You're mistakenly conflating these proposals with Wikitrust. Wikitrust is a completely separate issue. — V = I * R (talk to Ω) 13:57, 9 September 2009 (UTC) I'm not making the error. I'm saying rolling out orange links after a slew of news about orange text will confuse others. --King Öomie 14:01, 9 September 2009 (UTC) Oh, I get it... well, even if this were to suddenly gain tons of traction and everyone was onboard with implementing it, it would likely be months before an actual implementation went live on Wikipedia. By then I doubt that confusion with Wikitrust would be an issue. Or... it could still be an issue, I suppose. Regardless, the actual color used would be the last thing to consider, so specifically using orange is just a minor detail. — V = I * R (talk to Ω) 14:05, 9 September 2009 (UTC) I think this is a marvelous idea and wholheartedly support it. I have a script like the ones mentioned above for some time and find it very helpful. Anything that encourage a growth in quality is good in my book. —Charles Edward (Talk | Contribs) 16:10, 9 September 2009 (UTC) Thank you for your support Charles Edward. Since you have experienced using such a script, can you give us feedback as to what are the advantages, and what are the possible drawbacks? GeometryGirl (talk) 16:35, 9 September 2009 (UTC) Discussion settled: By default or not by default? There is some utility to this suggestion (I currently am trying it out through a little CSS hack and a preferences change). It certainly is interesting to those who have an interest in developing stubs. That said, I don't think the color change is useful enough to the general population to enable this as for all readers by default. Perhaps as a gadget, this would be nice. Shereth 17:41, 9 September 2009 (UTC) Great. Please tell us when you are done with your hacking. GeometryGirl (talk) 17:59, 9 September 2009 (UTC) There isn't much to add, really. There are some editors who enjoy expanding stubs, and to offer this as an option to these editors makes sense (ideally with the option to pick a color of their choosing). However, to those editors who are not generally interested in expanding stubs, the addition of another color of links could prove obnoxious. This is not something that should be enabled by default, but rather an option for interested editors. Shereth 21:17, 10 September 2009 (UTC) I understand your concerns Shereth. May I point out however that red links have been successful precisely because they where obnoxious/annoying. Editors will want to "change links to blue". GeometryGirl (talk) 21:39, 10 September 2009 (UTC) Some undoubtedly will; some undoubtedly will just be frustrated at multiple colors. Red links also serve to let people know that a link does not exist and that clicking on it would not result in seeing any information. Leaving links to non-existent articles undifferentiated would be disingenuous. Blue implies something exists, red implies it does not, and this is a wholly objective difference. The addition of any other colored links will result in necessarily subjective and/or arbitrary differences. Like I've said, this is a useful suggestion for those interested but it should be optional, not standard behavior. Shereth 21:44, 10 September 2009 (UTC) If we make it a gadget then I fear this would not at all have the same impact. There is an interesting question raised here: Are the potentially massive benefits of this proposal more, or less, important than the potential frustration for some? I don't have an answer... GeometryGirl (talk) 21:51, 10 September 2009 (UTC) I believe you are overstating the "potentially massive benefits" of this proposal. I also believe that intentionally "annoying" users as a means to an end is a wrongheaded approach to a problem. However as these are inherently subjective questions and points, and there is no objective "right or wrong" answer, it appears we are going to just have to agree to disagree, as it is apparent we have different views on the matter and we don't seem to be swaying one another. So I'll just reiterate my stance and leave the community to further discuss this issue : I think this is a fine idea for a gadget but should not be enabled by default. Shereth 21:57, 10 September 2009 (UTC) Exactly, may the community decide. But what about an option for frustrated editors to disable the new colour? That would solve the problem, no? GeometryGirl (talk) 22:03, 10 September 2009 (UTC) Not entirely. I am of the opinion that such a thing should be opt-in, not opt-out. Shereth 22:06, 10 September 2009 (UTC) What about this: If and when this is implemented, for every account have a message basically saying "Coloured links for stubs is new. Do you want to enable them? YES PLEASE/NO THANK YOU". GeometryGirl (talk) 22:14, 10 September 2009 (UTC) Something to that effect would be perfectly acceptable. Shereth 22:44, 10 September 2009 (UTC) Awesomeness! Consensus is in fact possible. GeometryGirl (talk) 22:49, 10 September 2009 (UTC) I support this. It encourages participation, which wikipedia certainly could use more of. I don't think orange is the right colour, but that is a later issue. Having coded my own version of this into my monobook theme, I have noticed how much of an effect the orange links have on me. They immediately stand out above things and they make me want them to be blue. I think this is useful for all signed up editors, but not for visitors, who may be unaware of the system in place. - ʄɭoʏɗiaɲ τ ¢ 18:23, 10 September 2009 (UTC) That's great. I agree with you that orange is not the best colour and that this should probably only be for signed up editors to avoid too much confusion. What do you think of purple? I can't find any appropriate colour at HTML color names. It is a shame that green gives out the wrong impression. GeometryGirl (talk) 20:02, 10 September 2009 (UTC) That purple is too similar to links you've already clicked on in many browsers, but another may work. I'd suggest a vibrant shade of blue (Perhaps an electric blue), or a mix between blue and green (Perhaps turquoise) that wouldn't cause a color-blind issues (Though in all reality, any color is going to be hard to see by a certain small percentage of the population who can't distinguish colours well). Another option could be bolding the text. I like the orange the best myself, but I just think it may cause confusion with others. - ʄɭoʏɗiaɲ τ ¢ 21:19, 10 September 2009 (UTC) Orange is also my personal best. I think I have found a solution: let each user decide for themselves. GeometryGirl (talk) 23:15, 10 September 2009 (UTC)

• Comment As I have my own css preferred link colours set, I am not sure how this would work for me. Would it interfere, against my will, with my colour preferences? (I haven't read all the stuff in the box above - too detailed and strenuous a read.) Can't anyone who wants to expand stubs just look under the thousands of stubs? Plus, the designation "stub" variies from full articles to one sentence pages. Xme (talk) 00:07, 11 September 2009 (UTC)

This is not a default option, just an opt-in option for interested users. Users who already have a preferred link colours set will not need such a feature. GeometryGirl (talk) 12:36, 11 September 2009 (UTC)

• Question Maybe I'm missing something here, but this is already implemented, at least in the monobook skin. Go to 'My preferences', click on the 'Appearance' tab, and scroll down to 'Advanced options'. There you should see a box labelled 'Threshold for stub link formatting', where you can set the threshold in bytes for what you consider a stub. Such links will then appear in a slightly darker red than a normal red link. The actual colour is defined for the class a.stub in http://en.wikipedia.org/skins-1.5/monobook/main.css. Individual users could of course override this colour in their own monobook.css. Dr pda (talk) 02:09, 11 September 2009 (UTC)

The state of being a stub is not measured in bites. Rather, it is measured in encyclopedic content. GeometryGirl (talk) 14:44, 11 September 2009 (UTC)

• Stubs I wanted to add a comment here about something said at User talk:Cacycle#coloured links for stubs. The quote from there is "4) Stub pages not are appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material".". I understand that there is probably a policy or guideline page that says that somewhere, but the fact is that it's simply not true. There are many "stubs" that do need to be expanded, but there is also a significant portion of them that really should not. I know that I'm far form the only one to have that view as well, so I'm fairly comfortable in saying it.
  — V = I R (talk to Ω) 12:50, 11 September 2009 (UTC)

Thank you for raising the point. Do you have specific examples of stubs "that really should not [be expanded]"? GeometryGirl (talk) 14:40, 11 September 2009 (UTC)

After a little poking around: Fastflow. Subject has very little coverage. --King Öomie 14:47, 11 September 2009 (UTC)

A article with no sources surely should be expanded. There exist small and developed articles... The smallest featured article is not much longer than Fastflow. GeometryGirl (talk) 14:54, 11 September 2009 (UTC)

You said "expanded", not "Improved". The Fastflow article doesn't need to be longer is my point. --King Öomie 15:01, 11 September 2009 (UTC)

This is just a wording issue. There is "lengh (prose) expansion" and "sources expansion". Both are expansion. Improvement is done on something already existing. I can improve the existing prose, but I certainly can't improve the current sources, since there are none! :) GeometryGirl (talk) 15:08, 11 September 2009 (UTC)

Just as a point of information, in my experience, an article like Fastflow, with so many sentences clamoring for elaboration, could easily be doubled in size once sources are provided to support the claims made. Geometry guy 21:39, 11 September 2009 (UTC)

The other aspect of this is that I'm addressing the idea that was brought up, which is why I haven't and will not provide specific examples. As a concept, the idea that stub must be expanded is simply wrong. They are definitely good candidates, as a class of articles, for expansion (statistically, you're much more likely to find an article needing expansion by looking at stub articles).
— V = I * R (talk to Ω) 15:12, 11 September 2009 (UTC)

Poll

Support

• Support as nominator. GeometryGirl (talk) 23:12, 10 September 2009 (UTC)
• Support This would be great. Encouraging stub expansion is something I've seen for the first time, and it makes well enough sense. warrior4321 23:38, 10 September 2009 (UTC)
• Support only because of: "Registered users will the prompted to use a new colour". You can do what you like, and you can even advertise for it in a limited fashion and I wouldn't mind in the least. When you cross over into actively pushing me to adopt something that I'm not looking for myself, then I'm very likely to just tell you to hush and ignore whatever you're saying. Aside from that, the post above applies to myself as well. I have custom colors, and I would appreciate it if everyone else were able to respect my personal choices.
  — V = I * R (talk to Ω) 00:18, 11 September 2009 (UTC)

  There is no question of enabling this by default. We shall advertise it via a sitenotice or a watchlist notice. (See Shereth's comment below.) I have rephrased the proposal to remove any confusion. GeometryGirl (talk) 12:30, 11 September 2009 (UTC)

  OK, changed to support, as long as it's understood that this is a gadget, and not a proposal to change the MediaWiki software. (I likely won't use it, but I'm certainly not going to stand in the way). Thanks.
  — V = I * R (talk to Ω) 12:41, 11 September 2009 (UTC)

• Support per my above comments. In response to Ohms plight, perhaps it could be enabled by default, but can be disabled in preferences. Current users would default off and have to enable it themselves, only new users would have it checked by default. - ʄɭoʏɗiaɲ ^τ _¢ 02:24, 11 September 2009 (UTC)
• As I indicated previously, I am okay with the creation of a gadget of some kind that people can use to provide this kind of functionality. I am also okay with advertising it via a sitenotice or a watchlist notice, or the like. So long as it is opt-in and not opt-out (enabled by default) I am okay with it. Shereth 05:16, 11 September 2009 (UTC)

To clear up any confusion, this is opt-in, not opt-out. Thank you for your support. GeometryGirl (talk) 12:18, 11 September 2009 (UTC)

• Support An excellent idea. The easiest way to implement it would be enable to settings mentioned above as a default setting, or to create this as a gadget accessible throuugh preferences and enabled by default. Then if users don't like it, they can simply change the setting. —Charles Edward ^{(Talk | Contribs)} 14:20, 11 September 2009 (UTC)
• Support The argument for the proposal makes a lot of sense. I don't see much of potential problem, either. -- Taku (talk) 23:49, 11 September 2009 (UTC)

Oppose

• Strong oppose. (1) This would be a usability nightmare. (2) It is technically not possible at the moment and it is completely unlikely to be implemented anytime soon. One reason for this is the enormous resource intensity to make it happen: the articles for every single link on a page would have to be retrieved and searched for a certain string for every page call. (3) The proposal conceptually mingles English-Wikipedia specific content with a function of the underlying general software. (4) We do not necessarily want stubs to become expanded, especially by people not qualified to do this, and, (5) more importantly, nobody will go and expand stubs just because their link is displayed in a different color. (6) Other triggers for a new link color would be much more useful, such as disambiguation pages^[1]. (7) It is out of the question to make this the default behavior. (8) Whoever wants the functionality anyway, can already use a user script such as User:Anomie/linkclassifier.js. Cacycle (talk) 03:09, 11 September 2009 (UTC)

Replied on User:Cacycle's talk page. GeometryGirl (talk) 12:19, 11 September 2009 (UTC)

Thanks for having now clarified your proposal into a real opt-in option. But if all this fuzz is only about having a new gadget then I see no reason to vote for it here. Ask somebody to adapt an existing script and go through the approval process on Wikipedia:Gadget/proposals. Cacycle (talk) 12:49, 11 September 2009 (UTC)

It is easy to say "ask somebody to write code". Who is that somebody? Also, we need consensus that this is a worthy enough cause to have a sitewide notice. (May I also ask you to remove your "strong oppose"?) GeometryGirl (talk) 14:31, 11 September 2009 (UTC)

It has to be written before a notice can go out. Poke around WP:RQ. --King Öomie 14:38, 11 September 2009 (UTC)

The code is already there, only the category/template names need to be adjusted to stub categories/templates. User:Anomie/linkclassifier.js uses a relatively fast and resource friendly api call that (afaics) does not require full text analysis server-side. Cacycle (talk) 23:32, 11 September 2009 (UTC)

• Oppose - 1) I don't think this is important enough for a sitewide notice. 2) If we're going to encourage as many users as possible to use this, we should be promoting the already existing "stub threshold" user preference rather than creating inefficient scripts. Mr.Z-man 17:04, 11 September 2009 (UTC)

This could be adapted from that easily by adding a colour choice to it. - ʄɭoʏɗiaɲ ^τ _¢ 17:16, 11 September 2009 (UTC)

I'm not entirely sure what you mean, "this," "that," and "it" in you statement are rather vague. Mr.Z-man 17:25, 11 September 2009 (UTC)

Haha, my bad. This idea could be adapted to the stub threshold preference by adding the ability to choose which colour you use instead of the default maroonish colour. Many people, myself included, have modified our theme.css to make it a different colour. - ʄɭoʏɗiaɲ ^τ _¢ 20:35, 11 September 2009 (UTC)

It could be, yes, but we've apparently moved from discussion to voting, and it wouldn't really be proper to change the proposal after several people have already voted. Mr.Z-man 21:11, 11 September 2009 (UTC)

• Not with the current stub system. Currently, we have tons of stubs that are just marked as stubs because they are small. I just opened a random article: Octávio Machado. While that article could be improved, I don't see that it needs particularly more attention than any other random article. — Sebastian 15:57, 12 September 2009 (UTC)

Other

• Indifferent as to gadget status, which is neither here nor there; Strong oppose to any mention of this being default or opt-out. (Moved, direct response to Charles Edward) --King Öomie 14:31, 11 September 2009 (UTC)
• As above don't mind or care if it is just an optional opt-in gadget but absolutely opposed to this being a default setting for anyone and/or anyone having to opt-out to stop seeing it. Wikipedia is here for the readers first and foremost and anything that makes the experience worse for them (as I think this will by making article links more obtrusive - 3 different colours in an article is not a benefit for readers). It would also discourage people from linking to stubs (featured articles already have a de-facto no redlink policy and stub links would I'm sure be discouraged if they were a different colour). Davewild (talk) 16:27, 11 September 2009 (UTC) p.s. if the views of those in support who want this an opt-out device pervail then consider this a strong oppose. Davewild (talk) 16:29, 11 September 2009 (UTC)

"FA have already have a de-facto no redlink policy" Check out recently passed Chinese classifier. (I know of this one because I contributed a bit.) GeometryGirl (talk) 16:44, 11 September 2009 (UTC)

True but I notice the relinks did get a comment on the discussion on promoting the article to FA status and had to be defended there. I could change my statement to "relinks are viewed negatively at FA". Davewild (talk) 16:50, 11 September 2009 (UTC)

Redlinks are not disallowed in FAs (one of several misconceptions about FA and related processes), although I do agree that reviewers often like to see red links blued where possible. Dabomb87 (talk) 21:12, 11 September 2009 (UTC)

• I honestly don't care if this is a gadget (or just a user-script), but it'd be nice if the same proposals weren't rehashed day after day after day. If I see one more blasted thread about changing link colors, I'm going to scream. EVula // talk // ☯ // 19:38, 11 September 2009 (UTC)

Ads, but not for money

We need more editors. We used to have a tag at the top saying something like "You can edit this article right now" (I forget exactly what it said, and it changed a bit over time). Now it's "The encyclopedia that anyone can edit", which isn't as motivating. Because of our decline in editors, I think we should do something even more punchy. We should do adds that emphasize that you can edit this article, with some sort of advertisement. I know that ads for money are a perennial proposal that have been rejected, and maybe this it too, but I think it could really help to increase the improvement of articles. We could do it for every 100th visitor (I think, with current capabilities) or we could add it to stubs, or do it on every article for a week, or whatever we want. - Peregrine Fisher (talk) (contribs) 03:21, 11 September 2009 (UTC)

I'm quite sure, that anybody who is already on the site knows that you can edit it. The advertisements that we could use, are ads on the internet, inviting users to come to this site. warrior4321 03:27, 11 September 2009 (UTC)

Those would be nice too, but that cost money I don't think we have. I disagree that readers are really that aware that they can edit, or at least they need a little push. - Peregrine Fisher (talk) (contribs) 03:49, 11 September 2009 (UTC)

I agree that a little push to invite readers to become editors would be nice. This is essentially my proposal above... Other forms of advertising would be nice as well. GeometryGirl (talk) 12:23, 11 September 2009 (UTC)

On-wiki advertising for the wiki itself? Kind of like seeing a commercial for a show you're already watching. You can already add this into your userspace- see Template:Wikipedia ads. Users are fully aware they CAN edit, I honestly don't see how reminding them again and again will do anything but irritate them. If they don't want to edit, they won't. --King Öomie 13:29, 11 September 2009 (UTC)

Well, they do have ads for shows that you are watching while you are watching them, so apparently marketing gurus have deemed this a good thing to do. Ads in userspace are the ones where people are fully aware that they can edit, so those aren't going to bring in new users. Also, people are not really aware that they can edit wikipedia. They've heard things, but don't really understand what it means. They pretty much read the article, and don't give editing a first or second thought. The usability study found that people were very unsure how to edit, and I think people who were interested in editing were chosen. I thought we had a small weak add saying "the encyclopedia that anyone can edit" but it looks like we don't even have that. When I log out, I see "Wikipedia is sustained by people like you. Please donate today." Maybe that says different things at different times, I don't know. - Peregrine Fisher (talk) (contribs) 17:19, 11 September 2009 (UTC)

Those messages displayed to anons are defined at MediaWiki:Monobook.js, most are on donating, and there's one linking to Wikipedia:Contributing to Wikipedia. We'd need to better introduce editing to newcomers, for example by linking the introduction in the sidebar. Cenarium (talk) 22:09, 11 September 2009 (UTC)

• Strong Oppose banner ads on articles. This is an encyclopedia, not a blog. Hatnotes are a different story- as I recall, that "you can edit this page now" tag resulted in a lot people treating the entire encyclopedia like the Sandbox. --King Öomie 19:29, 11 September 2009 (UTC)
• Oppose We don't need ads to tell people to edit. People are very aware that we can edit. We do not have a lack in editors, we just more more vandals than editors, we just have more people adding unsourced information than people adding proper cited information. What we need are people who want to edit and improve the encyclopedia. We have more than enough editors, we just lack strong good ones. warrior4321 21:01, 11 September 2009 (UTC)

We lack 'good' editors because we fail to well introduce editing to newcomers. Cenarium (talk) 22:09, 11 September 2009 (UTC)

Well, the majority of "bad" editors are IP users. Most IP users have no interest in editing and improving the encyclopedia, that is why they don't even want to sign up. warrior4321 22:12, 11 September 2009 (UTC)

Many "would-be-good" editors don't contribute because it seems too difficult for them or we don't explain editing well enough. Making 'good contributions' is relatively difficult (formating, sourcing, etc), while vandalizing Wikipedia is easy. We need to better introduce editing on Wikipedia to good-faith users. While I would oppose ads, a link 'introduction to editing' in the sidebar could help in achieving this. Cenarium (talk) 00:15, 12 September 2009 (UTC)

Until this claim is anything but "baseless", you'll forgive me taking it with a grain and a half of salt. --King Öomie 00:59, 12 September 2009 (UTC)

Haven't you heard of the usability team's findings (linked several times on this very page) ? We get a multitude of new user's comments confirming this, as well as other investigations and surveys conducted by the wmf (it's one of the reasons they launched the usability initiative) and other parties. This is a widely recognized problem. Don't say a claim is 'baseless' if you have no idea if it actually is, please, AGF. Cenarium (talk) 01:52, 12 September 2009 (UTC)

I agree w/ Cenarium and there is not a shortage of research indicating that wikipedia has a great deal of trouble hanging on to new good editors, for a variety of reasons (and in my opinion not least among them is our willingness to succumb to a number of logical fallacies in asserting that the majority of bad editors are IP editors). Protonk (talk) 02:21, 12 September 2009 (UTC)

We definitely have a problem. It looks like this is going to be a knee-jerk bunch of opposes and die on the vine, but how about this: Put ads on 10 pages, leave them there for a week, and see if it attracts new editors. We've got 3 million pages. What could it possible hurt? Worst case scenario, it works and we're forced to think about more ads. - Peregrine Fisher (talk) (contribs) 02:27, 12 September 2009 (UTC)

We do not need ads asking people merely just to edit. This will result in edits full of testing and vandalism, and the editors will blame the ad on the page for asking him/her to edit. I'm pretty sure everyone who comes to Wikipedia is aware that they can edit the page. What we need to do is educate the people to follow our policies and guidelines and eradicate the vandals. This is why I stand by the thought that everyone should be able to read Wikipedia, but only registered users should be able to edit. warrior4321 05:00, 12 September 2009 (UTC)

Sounds like you've made up your mind, but everything I've read says that people have very little understanding of wikipedia. If you think the elderly, minorities, people without the internet at home all understand WP perfectly, then whatever. As far as IPs go, I believe the consensus is that we'll accept them. If that changes, we can prevent editing without logging in, which is unrelated to my proposal. - Peregrine Fisher (talk) (contribs) 05:08, 12 September 2009 (UTC)

If senior citizens and minorities do not know that they can edit Wikipedia, then they probably do not know how to cite sources and create strong and proper articles. We do not have a shortage of articles or editors, we just have a lack of FA's and GA's versus all articles, just as we don't have a lack of strong, interested editors versus vandals and uninformed editors. We need to properly educate the editors we already have, not bring in more inexperienced users for the sake of increasing the number of editors. warrior4321 17:49, 12 September 2009 (UTC)

That sure worked out for citizendium. Protonk (talk) 08:15, 12 September 2009 (UTC)

The issue that most people have with editing isn't due to a lack of understanding that their allowed to edit. The problem is largely the interface, which relies on a "technical" text formatting system. It's not WYSIWYG editing, so most people simply won't take the time to learn the "language". This is a completely separate issue from what any advertisement could possibly address.
— V = I * R (talk to Ω) 17:50, 12 September 2009 (UTC)

We should make them subliminal like in "they live" *EDIT NOW*, *SOURCE THIS*, *GIVE JIMBO MONEY* --Cameron Scott (talk) 22:16, 11 September 2009 (UTC)

• Strong Oppose we need more ads in this world like we need extra holes in vital body organs. Hell no! - Denimadept (talk) 22:24, 11 September 2009 (UTC)
• NONBHNO Protonk (talk) 01:15, 12 September 2009 (UTC)

• Support exploring various avenues for attracting contributors. In order to maintain momentum, we seriously need more dedicated editors, and among our readers are vast numbers of would-be assets to the project. I think the best way to proceed with this is think of the different ways something like this could be implemented (e.g. banner ads, sidebars, hatnotes), creating mockups, testing, and then coming back to propose the best means here.  Skomorokh  02:59, 12 September 2009 (UTC)

  Honestly, I'm not so sure that we need more editors. I mean... we don't want to discourage people from editing, but I just don't see a real editor shortage issue now or going into the future. The level of editors has plateaued, but so what? That was bound to happen eventually, and it's a good thing because it shows that the project has matured. The number of editors hasn't actually declined, and isn't likely to, so what's the problem?
  — V = I * R (talk to Ω) 09:28, 12 September 2009 (UTC)

  It has declined, starting in 2007. There are signpost articles on it, and videos about it from the last wikimania. The usability thing is one thing being done to try and stop the decline. - Peregrine Fisher (talk) (contribs) 16:12, 12 September 2009 (UTC)

  Futile. There are editor-editor interactions which repel people, which are unavoidable. The project strikes me as healthy. Adding ads of any kind will repell more editors, and maybe users as well. If I see ads, I'm likely to start my own MediaWiki project on my own terms, to fix what I see as problem with this one. For details, ask on my talk page. - Denimadept (talk) 16:40, 12 September 2009 (UTC)

  The number of regular editors (those with more then a handful of edits) has plateaued, it hasn't dropped. The stats are available for anyone to look at.
  — V = I * R (talk to Ω) 17:42, 12 September 2009 (UTC)

• Oppose Ads are more likely to annoy people than make them edit. I know it would annoy me. Chillum 16:33, 12 September 2009 (UTC)
  • That's kinda like saying ads are more likely to annoy people than make them buy something. Apparently they work. - Peregrine Fisher (talk) (contribs) 16:42, 12 September 2009 (UTC)
    • Actually, ads work for a number of different reasons, and not as well as people might think. In this case I think wikipedia has a good reputation for being ad free and unobtrusive (save the occasional hideous donation notice). It is more important that we maintain that image (IMO) than we remind people they can edit in a banner ad. Protonk (talk) 18:01, 12 September 2009 (UTC)
• People are often reluctant to edit. Essentially everyone I know uses Wikipedia--most of them would make good editors, with interesting things to write about and the skill to do it. All of them see things in Wikipedia that they think should be edited--but yet they do not edit. Any way we can think of encouraging them is for the good--If our advertisements convert 1% of them, it will double the number of active editors. It's not just usability. Wer're concerned with getting people to fix errors initially--it often leads to further contributions. DGG ( talk ) 00:12, 13 September 2009 (UTC)
• Perhaps if targetted. I would not like to see a banner above every article, but maybe it would be ok in articles are in categories that are known to be weakly covered. Alternately, maybe a banner could appear for IPs known to be from colleges and universities. Gmail was first marketed this way, as I recall. Abductive (reasoning) 04:06, 13 September 2009 (UTC)
  • I do think we should have a strategy of some sorts, to (hopefully) maximize adding editors, without big glaring ads on every page, every view. - Peregrine Fisher (talk) (contribs) 04:15, 13 September 2009 (UTC)

multi-lingual search>

I propose that there be an option to search all languages of Wik at once. Thus, if I want to know if John Z. Doe has been written about in any Wik, I could click this option. It would be helpful for both editors and for people looking for rare items. If this feature already exists, it should be made easier to see, e.g., on the Wik start page as a small button at the bottom. Kdammers (talk) 02:45, 12 September 2009 (UTC)

You can find this information by going to the John Z. Doe article and looking at the left sidebar. EVula // talk // ☯ // 02:47, 12 September 2009 (UTC)

I think Kdammers' point is that if you go to an article that does not exist, there's no way to determine which other languages do have the article. —Noisalt (talk) 04:41, 12 September 2009 (UTC)

Yeah, but words change from language to language. If you are looking for an article on England on allwikis, it wouldn't work because in French, England is Angleterre. Do you get what I'm saying? warrior4321 04:51, 12 September 2009 (UTC)

True, there would be limitations, but with most proper names for many or most languages, and with the help of auto-translation technology, I think it would at least cover a fair bit of ground. Kdammers (talk) 06:29, 12 September 2009 (UTC)

How often do people search (or have the need to search) the English Wikipedia for non-English articles? Not only that, but while I'm sure that there are articles on topics (people, locations, etc) that are possibly only in those localized languages, the English Wikipedia is pretty comprehensive; I'd say that, nine times out of ten, if we don't have an article on something, one of the smaller wikis doesn't either. (again, I realize there are times where that isn't the case, but they are traditionally for very local topics, and probably wouldn't be covered by Kdammer's "fair bit of ground" comment above) EVula // talk // ☯ // 14:59, 12 September 2009 (UTC)

Exactly. Moreover: In the simple cases, when the title is the same across languages, people can always use Google. And those cases which need translation would need our programmers' time, which is not worth it. — Sebastian 15:46, 12 September 2009 (UTC)

Well, you could go to List of Wikipedias, click on a Wikipedia listed there that is a likely candidate,and find out whether

the article is there (for example, there was an article on Hjalmar Sunden in the Swedish Wikipedia before one in the English Wikipedia). I would not rely too fully on internet translations - I have heard they are not always all that reliable. ACEOREVIVED (talk) 21:14, 12 September 2009 (UTC)

Current weather

I came across mw:Extension:AccuWeather a few months ago, and thought it was a neat feature. Then, after thinking about it this evening, I decided it would be an excellent idea to implement something similar that would be put into place on city articles, specifically in {{Infobox settlement}}, that would display the current temperature at a given city in both Fahrenheit and Celsius. At first this seemed like a bit of a crazy idea, but it seems like it would be a rather minor, albeit useful, addition. Additionally I expect this will be technically feasible. Any thoughts? –Juliancolton | ^Talk 02:51, 12 September 2009 (UTC)

Support I like this idea a lot, though I think a new extension would need to be coded for it to work. I think the best application would be to include current conditions, and perhaps the chance of precipitation in the next 24 hours in infoboxes. — Jake Wartenberg 03:04, 12 September 2009 (UTC)

Well, I don't want to include too many details, else we are in danger of entering travel-guide territory. –Juliancolton | ^Talk 03:08, 12 September 2009 (UTC)

I was just thinking in terms of technical functionality; it is nice to have more options than less. We can decide what to put in the articles later. — Jake Wartenberg 03:27, 12 September 2009 (UTC)

Strong support it would be awesome for our readers. - Peregrine Fisher (talk) (contribs) 03:29, 12 September 2009 (UTC)

• I would warn on the possible issue of promotion. This would rely on an external service, presumably accuweather.com, but then what would be the appearance ? If it were silently encoded, it would be okay, but if for example a link to their website mentioning it is required... Cenarium (talk) 03:43, 12 September 2009 (UTC)

• I don't think it'll be any more problematic than external links sections personally. –Juliancolton | ^Talk 04:10, 12 September 2009 (UTC)

• Oppose: 1) Not really encyclopaedic knowledge, 2) Would have to rely on a third party service for the data, 3) Almost impossible due to the caching that we require. Peachey88 ^{(Talk Page · Contribs)} 06:44, 12 September 2009 (UTC)

• Err... don't we rely on third party sources for all our info? –Juliancolton | ^Talk 16:20, 12 September 2009 (UTC)

• The weather data would be stored on a third party service compared to our servers, so it would require additional requests on page loads making things slower pluse additional issues if something was to go wrong on their end. Peachey88 ^{(Talk Page · Contribs)} 01:45, 13 September 2009 (UTC)

• Conditional Oppose, to using an AccuWeather version of weather info. If it was anyone but AccuWeather (or any other branded commercial weather service, for that matter) I wouldn't mind one bit. Wikinews has weather info, so if we're going to do something like this it should be coming from there. I like the core idea of adding weather info, but using a commercial service to do so, here on Wikipedia, seems wrong.
  — V = I * R (talk to Ω) 09:18, 12 September 2009 (UTC)
• Encyclopedias include information about a location's climate, not weather forecast. That's more Wikinews' forte. I oppose. wodup 09:27, 12 September 2009 (UTC)
  • To be fair, comparisons between Wikipedia and traditional encyclopedias can only go so far, and this is one of the areas where a direct comparison cannot be made; it is absolutely impossible for a traditional encyclopedia to include current information about a location's weather. EVula // talk // ☯ // 14:50, 12 September 2009 (UTC)
    • Other encyclopedias that are on paper, cannot include current temperature. They print a copy maybe every 5 - 10 years? There is no plausible way to give current temperature. This is one of the advantages of using a website, instead of a book. warrior4321 14:56, 12 September 2009 (UTC)

Of course not. But that doesn't mean that a "weather right now" should be in Wikipedia just because it can be. It's simply not an appropriate thing to put in an article, here. ♫ Melodia Chaconne ♫ (talk) 16:17, 12 September 2009 (UTC)

• Oppose including this information in articles by default. Wikipedia is an encyclopedia. The current weather is useful, but it has nothing to do with the purpose of this encyclopedia. We also don't do plane fares, local movie times, or directions. These are all useful things that the internet is very good at, and that print encyclopedias cannot do, but that doesn't mean we need to do them. These things can already be found on the rest of the internet, by people who are much better at it than we can ever be. But if you want to implement this as a Gadget, then sure. —Noisalt (talk) 16:24, 12 September 2009 (UTC)
• Oppose - Any such service creates a dependency on a third-party site for the information. If the site goes down, the gadget breaks. If the site gets slowed down (like from having a top-10 website suddenly start getting its data for thousands of pages), then our site gets slowed down. There might also be copyright issues for the data, the way its presented, and the software the service uses. The AccuWeather extension linked above has several other problems that would pretty much guarantee it would never be enabled on Wikimedia sites in anything close to its present form. Mr.Z-man 16:44, 12 September 2009 (UTC)
• Oppose. Mr.Z-man has succinctly characterized the core issue. And to clarify: Yes, we use some outside tools, but these are used only for maintenance and not for content.---— Gadget850 (Ed) ^talk 16:52, 12 September 2009 (UTC)
• Oppose – this is an encyclopedia. No encyclopedia that I know provides up-to-the-minute tourist information. Shall we also update the status of London Underground lines? "The District line is currently closed due to a signal failure," would not befit Wikipedia, and it's precisely the same principle. ╟─TreasuryTag►Woolsack─╢ 17:00, 12 September 2009 (UTC)
• Oppose this well-intentioned idea per the valid reasons made by others above. In contrast, it makes perfectly good sense for pages about cities to state things like average yearly temperature and rainfall, but not this. --Tryptofish (talk) 17:22, 12 September 2009 (UTC)
• Qualified support/oppose: If you had something that gave the reader an idea of the most recent weather over a reasonably long period, say the last three or six months, that might be helpful. For example, an article about New England would say that we have hot humid summers, but that hasn't been true this year and without correction a reader would have to assume that the New England summer of 2009 was also hot and humid. But 2010 might be different, so a moving or self-refreshing source that avoids the other possible problems with Accu-Weather might be useful, and the kind of Wikipedia function that printed works can't offer. —— Shakescene (talk) 23:52, 12 September 2009 (UTC)

Proposed tweaks to Template:Convert's default precision

See the discussion at Template talk:Convert#Some suggestions for changes to the default precision. --___A. di M. 21:03, 12 September 2009 (UTC)

Main page feature suggestion

Hi i have suggestion, to have a "Today's featured article" section is great, but wouldnt it be good to have a "Article that needs your help" section to (or similar name). Where everyday 1 or up to 5 articles are posted which are in need of help, which could be any article basically. As long as it is not a Featured article. My suggestion would be to have a similar style like the "Todays featured article" with one listed article everyday that is todays help article, or to have a list of 5 articles that is todays articles that need help from the editors. Please come with more suggestions and we might get some consensus. would be nice. But my main suggestion is to have one article per day that is under the "Article that needs your help which perhaps could stand beside todays featured article or in a small column or similar. --Judo112 (talk) 21:24, 12 September 2009 (UTC)

My main reason for the suggestion is that i think that there is thousands of articles that could be mutch improved if more people knew about them and paid them attention. I also believe that it is a project that could improve the overall standard of articles on Wikipedia.--Judo112 (talk) 21:33, 12 September 2009 (UTC)

• Gosh, I think this is a very good proposal, and I support the idea. (Be warned Judo112, that you will certainly meet great resistance by a few very loud and conservative people. But don't discourage! I'm also happy to help you out if you feel discouraged.) GeometryGirl (talk) 21:35, 12 September 2009 (UTC)
• Dont worry im up for a fight;) No but seriously i hope that most of the Wikipedians see the greatness in this idea and that it will improve the overall standard of Wikipedias articles tat sometimes is low and sometimes is very high.--Judo112 (talk) 21:47, 12 September 2009 (UTC)

Strong support. The idea of a temporary collaboration has sprung up in myriad incarnations since 2001 – COTW, ACID, all kinds of WikiProject collaborations – but I think this is the kind of idea that needs a full-force reboot. Putting one article on the main page every day to be improved would do so much: it would rekindle some of the community magic lost in the last few years; it would encourage new users and help train them; it would actually convince people to start editing again. This is far more important, in my view, than ITN or DYK.

If you have too many articles, people will just ignore it. Highlighting a single article (which would be chosen much in the same way as the main page FA – underrepresented subjects, with clear and actionable paths for improvement) and giving it as much attention as possible would go much further than anything we've tried before. I absolutely support this idea. —Noisalt (talk) 21:44, 12 September 2009 (UTC)

Yes, and per Noisalts idea i change the first suggestion to One single article everyday as it will be the most effective. Hope to see a strong support for this so that we can start having this feauture on the main page up soon. Also agreeing that the "DYK" section could be moved or removed in favour of this new section which would be so mutch more productive.--Judo112 (talk) 22:03, 12 September 2009 (UTC)

• I guess I'm loud and conservative. Protonk (talk) 23:17, 12 September 2009 (UTC)
• Support I love this idea, and this would be a great way to improve articles. However, a few questions remain.

1. Which articles will be chosen?
2. How do we nominate and choose articles? Will it be like FAC?
3. Will new criteria have to be created?
4. Won't it be a huge vandal attractor? Will it have to be semi-protected? Does that ruin the purpose? warrior4321 23:38, 12 September 2009 (UTC)

Certainly any vandalism it attracts because of it would be dealth with swiftly for the same reasons. ♫ Melodia Chaconne ♫ (talk) 00:08, 13 September 2009 (UTC)

A possible answer for questions 1, 2 and 3 would be: pick a stub at random. There would be no nomination, no criteria, etc. GeometryGirl (talk) 00:20, 13 September 2009 (UTC)

The fact that you said stub means that you want criteria. The proposal is for the improvement of articles, not expansion of articles. This would mean that even a GA article aiming for FA would be able to fit in this proposal. This is why criteria is required. What do you mean stub chosen at random? By whom? When? If we allow stub choosing at random, we would get around 500 putting their stub that they just created over there. For something that is going to go on the main page, this will require some organization. warrior4321 00:27, 13 September 2009 (UTC)

This was just an idea. Basically there are thousands of stubs. My idea was to pick out one stub of all the existing stubs at random (using a functionality similar to Special:Random) where all stubs are equally likely to be picked (so that there is no bias). GeometryGirl (talk) 00:40, 13 September 2009 (UTC)

The main page is intended for readers, not editors, so perhaps it wouldn't be best to put this on the main page? Of course there is also the issue of where you would put it, the main page is full already. Prodego ^talk 00:41, 13 September 2009 (UTC)

Which articles will be chosen? How's C-class or lower sound? Will new criteria have to be created? I would suggest that articles be on approachable (non-technical, non-obscure) topics; those which a random, but interested researcher without specific expertise could reasonably make constructive contributions to. How do we nominate and choose articles? Will it be like FAC? I hope it would be lighter-weight than FAC. --Cybercobra (talk) 01:33, 13 September 2009 (UTC)

My one concern with this proposal is: we have a huge backlog of articles that are very long and moderately well-written but just don't have any sources cited, so they languish outside the GA/FA process. New editors aren't going to be interested in adding inline citations, so we'd just we adding to that backlog. —Noisalt (talk) 02:34, 13 September 2009 (UTC)

Articles containing images without alternative text

There's currently a discussion concerning whether a bot should categorize these articles at Wikipedia:Bots/Requests for approval/Erik9bot 12. Erik9 (talk) 04:33, 13 September 2009 (UTC)