Wikipedia:Village pump (proposals): Difference between revisions
→Ads, but not for money: it does require some thought |
No edit summary |
||
Line 1,200: | Line 1,200: | ||
::''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. --[[User:Cybercobra|<b><font color="3773A5">Cyber</font></b><font color="FFB521">cobra</font>]] [[User talk:Cybercobra|(talk)]] 01:33, 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. --[[User:Cybercobra|<b><font color="3773A5">Cyber</font></b><font color="FFB521">cobra</font>]] [[User talk: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. —[[User:Noisalt|Noisalt]] ([[User talk:Noisalt|talk]]) 02:34, 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. —[[User:Noisalt|Noisalt]] ([[User talk:Noisalt|talk]]) 02:34, 13 September 2009 (UTC) |
||
==Articles containing images without [[Wikipedia:Alternative text for images|alternative text]]== |
|||
There's currently a discussion concerning whether a bot should categorize these articles at [[Wikipedia:Bots/Requests for approval/Erik9bot 12]]. [[User:Erik9|Erik9]] ([[User talk:Erik9|talk]]) 04:33, 13 September 2009 (UTC) |
Revision as of 04:33, 13 September 2009
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- 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.
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:
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)
|
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:
- Interest from editors. Other potential benefits. Perhaps a straw-poll.
- Critical comments, including reasons why this might not be as useful as stated.
- Solid estimates of cost - can this be done without locking the site? How long would it be read-only for?
- Input from a developer. Should one be contacted to check feasibility?
Comments addressing any of these four points are especially welcome. –MT 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? –MT 02:36, 28 April 2009 (UTC)
- I guess it should be the latter... –MT 04:28, 5 May 2009 (UTC)
- How might the column increase performance? 20:37, 13 May 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? –MT 02:36, 28 April 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. 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
- You could just use variables, like
- 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. 22:13, 15 May 2009 (UTC)
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. –MT 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. –MT 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. –MT 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 20:29, 13 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)
- 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 Baastalk 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). 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.) --Ckatzchatspy 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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.
![](http://upload.wikimedia.org/wikipedia/en/thumb/4/4c/Interface_mark_one.png/400px-Interface_mark_one.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/9/95/Interface_mark_three.png/400px-Interface_mark_three.png)
![](http://upload.wikimedia.org/wikipedia/en/thumb/2/2c/Interface_mark_two.png/150px-Interface_mark_two.png)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Just visually, there's too much whitespace on the page anyway. — V = I * R (talk to Ω) 14:03, 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)
- 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)
- 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)
- 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)
- 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
![](http://upload.wikimedia.org/wikipedia/commons/thumb/3/34/Interface_mark_four.png/800px-Interface_mark_four.png)
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)
- 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)
- 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)
- 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)
- 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)
- 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'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. [citation needed]) 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:
- 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)
- 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)
- 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)
- 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)
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)
- I do. See the links on my own user page. As a matter of fact, I hardly ever use my own watchlist any more.
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
OpposeComment 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)
- 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)
- 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)
- Unless you subscribe to the extension nobody will be able to change your watchlist. — Jake Wartenberg 00:04, 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)
- That sums up my own POV perfectly (pun completely intentional!)
- 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)
- (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 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)
- 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. –xenotalk 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)
- 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.
- In which case it would be entirely unnecessary makework and inconsistently applied. –xenotalk 17:40, 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)
- 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)
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? –xenotalk 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? –xenotalk 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. –xenotalk 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. –xenotalk 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)
- 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.
- I was talking about the complexity of changes we would be asking the Mediawiki developers to make. –xenotalk 14:39, 5 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)
- 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.
- (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.
- 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? –xenotalk 18:06, 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.
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)
- 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.
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)
- 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 (
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... –xenotalk 18:19, 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:
- 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)
- 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)
- 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)
- 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.
- 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)
- 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)
- 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
–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)
- Categories are supposed to be what you're looking for, though.
- Categories aren't the same. And not all pictures are in Wikimedia Commons. Raaggio 12:31, 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)
- 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)
- 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
![]() | It appears that this template ({{Help me}} ) is being used somewhere other than a talk page. Please remove this instance of the template.
This template is meant for use on talk pages. Your user talk page can be found here. If you added this template, please remove this template and re-add it on your user talk page. If you did not add this template, please remove it from this 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)
- Actually the intro page has the following:
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
(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)
- 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)
- (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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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.
- 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 Lemmiwinks2 stated clearly, he is using white text. Algebraist 00:18, 9 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?
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
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)
- 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)
- Then what's the point of taking FA off the main page? EVula // talk // ☯ // 20:05, 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)
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)
- 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)
- 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)
- 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.
- (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)
- Why say "obfuscation" when you can say "deceive"? Granitethighs (talk) 00:24, 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 backgroundWikipedia 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 proposalDescriptionAs 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 benefitsThe 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. ExtensionsThe 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 coloursThe 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
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)
a.stub:link {color: #ff6600;} a.stub:active {color: #ff6600;} a.stub:visited {color: #ff6600;} a.stub:hover {color: #ff6600; font-weight: bold;}
a.stub:visited {color: #cc5500;}
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)
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)
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)
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)
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)
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)
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"?
Why orange?
Discussion (edit tab)Don't bite too hard! :) GeometryGirl (talk) 11:56, 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"?
Why add "please"?
Why red?
Why green?
Why stubs?
For who?
Discuss (edit tab new proposal)Don't bite! GeometryGirl (talk) 17:27, 9 September 2009 (UTC)
|
Changing the stub template
Proposed at WP:Stub
|
---|
I propose to change or something similar.
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) | to
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)
- 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)
- 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)
- Wow, it just kicked me an edit conflict over converting '~~~~' to my sig... --King Öomie 13:50, 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)
- 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)
- 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.
- 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)
- 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)
- 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)
- 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)
- i know, but I think that it should be made clearer.Accdude92 (talk) (sign) 14:25, 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?
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
- "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."
- "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)
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 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)
|
- 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)
- 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)
- 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)
- 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)
- 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)
- After a little poking around: Fastflow. Subject has very little coverage. --King Öomie 14:47, 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)
- 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.
- 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)
- 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)
- It has to be written before a notice can go out. Poke around WP:RQ. --King Öomie 14:38, 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)
- 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)
- 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)
- 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)
- 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)
- This could be adapted from that easily by adding a colour choice to it. - ʄɭoʏɗiaɲ τ ¢ 17:16, 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- We lack 'good' editors because we fail to well introduce editing to newcomers. Cenarium (talk) 22:09, 11 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)
- 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)
- 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?
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- 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.
- Which articles will be chosen?
- How do we nominate and choose articles? Will it be like FAC?
- Will new criteria have to be created?
- 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)
- 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 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)
- 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)
- 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)
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)