Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Johantheghost (talk | contribs) at 15:46, 4 February 2006 (→Era Proposal). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The proposals section of the village pump is used to discuss new ideas and proposal that are not policy related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are discussed at Wikipedia:Village pump (perennial proposals). If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Please sign and date your post (by typing "~~~~" or clicking the signature icon in the edit toolbar).

Please add new topics at the bottom of the page.

Before posting your proposal:

  • If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
  • 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.
  • If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

Proposals archive

Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

edit "article not found" page

i was told to post my request here so i have copy-past the whole thing here:

http://en.wikipedia.org/w/index.php?title=Article_not_found&action=edit

i want to change this

"We don't have an article with this title, but you can create it if you log in or create an account. As an unregistered user, you may also submit the content that you wish to have created. Please read our introduction for more information about Wikipedia"

into this

"We don't have an article with this title, but you can create it if you log in or create an account(Registering a free account takes only a few seconds, and has many benefits:you simply need to choose a username and password and click "create account".). As an unregistered user, you may also submit the content that you wish to have created. Please read our introduction for more information about Wikipedia"


why: because most of the website use e-mail for submiting password and procedures are quite long and so we need to show that it's very fast and convenient...

i didn't get an acount for a long time for this reason

there is also a huge number of pages that are waiting to be created at http://en.wikipedia.org/wiki/Wikipedia:Requested_articles mabe a lot of theses people have posted their articles here because of the same reason(i did once(about a comparison of unix subsystem under windows(sfu,cygwin...)))

I would suggest that you try Wikipedia:Village pump and look under the Proposals section. CambridgeBayWeather (Talk) 14:49, 28 January 2006 (UTC)[reply]
This is not a page that a "ordinary" editor can alter. You would need to get some consensus for your proposed changes and then a more privileged user may make the changes you desire. Rmhermen 15:03, 28 January 2006 (UTC)[reply]

Editing feature

I just moved to a new computer and accidentally made a few changes without logging in. I propose that every attempt to edit by someone not logged in results in them being presented with the option to log in, create a new account or continue on anonymously. Hackwrench 23:19, 30 December 2005 (UTC)[reply]

Support. I've had a simmilar exeperience. This would not stop people from editing as an IP but still give new users the idea that they can become a member easily. Also it wouldn't be intrusive. Witty lama 09:49, 4 January 2006 (UTC)[reply]
Strong Support. This has been something that has bothered me since I started using Wikipedia. The problem is significantly worse when you sign on a talk page with tildes and end up signing with a IP on accident. Noneloud 04:10, 9 January 2006 (UTC)[reply]

It's a good idea, but I imagine it would become very irritating for anonymous users to have to click a "continue anonymous editing" option every time they edited. — Knowledge Seeker দ 04:28, 9 January 2006 (UTC)[reply]

Support. To avoid that irritation, let the anonymous user check a box "continue anonymous editing" and store the results in the cookie. If the would be editor wants to edit anonymously, she only has to say so once. Hiyya54 20:51, 9 January 2006 (UTC)[reply]
But what if the user is posting anonymously because he/she doesn't want to / can't use cookies? Ma.rkus.nl 23:40, 28 January 2006 (UTC)[reply]
Support, with the option to turn off the login page as Hiyya54 suggests. Hairy Dude 00:34, 13 January 2006 (UTC)[reply]
Support (and strongly) - but not without the checkbox. --Celestianpower háblame 12:03, 14 January 2006 (UTC)[reply]
Support but let the login fields be above the edit box, so you don't have to click extra. This will be a strong enough reminder for people, but not intrusive. Cookies is evil. --vidarlo 21:26, 16 January 2006 (UTC)[reply]
Support, very strongly, as Celestianpower. -b 19:55, 18 January 2006 (UTC)[reply]
Support only if the checkbox feature is implemented. тəzєті 05:45, 24 January 2006 (UTC)
Support - as above -Chairman S. 22:51, 26 January 2006 (UTC)[reply]
Strongly support, brilliant idea, this gets me all the time -- SAMIR  ! Talk 10:20, 27 January 2006 (UTC)[reply]
Strongly Support, I'm all for registering to make edits. This is a great comprise to hopefully cut back on vandals and keep post counts more accurate. Pattersonc(Talk) 12:37 AM, Monday; January 30 2006 (EST)
Support Strongly' Its happened to me. --Larsinio 16:14, 2 February 2006 (UTC)[reply]
Suport this would be helpful, and unexpected logouts do seem to happen with significant frequency. But ther would need to be an easy way for an anon to respond once and not again for that sesson, or at elast a significant time -- intil a "not-logged-in" cookie expired, perhaps? Is this on bugzilla yet? DES (talk) 16:28, 2 February 2006 (UTC)[reply]
Logged as Bugzilla bug #4841 express your support on bugzilla. DES (talk) 16:37, 2 February 2006 (UTC)[reply]

Creating syntax for date preference formatting that isn't linking

This has come up in repeated discussions and I think it's important enough that something needs to be done. Currently, the only way to get date preference formatting to work is to link the date. While this works, it has the unsightly side effect of cluttering up a page with unnecessary links. Wikipedia:Make only links relevant to the context is a good guide in this regard. Unfortunately, because of the desire to get date formatting preferences to work, you end up seeing lots of unnecessary links. Let's take the high profile Christmas article. It has over a dozen links to December 25 and all sorts of links to other dates as well. It's ugly and it clutters up the page. Links should only be used when the user would actually have some valid reason to click through and find out about a topic. But I can't think of any reason anyone would need to be able to click through to December 25 a dozen times from the Christmas article. The desire to get dates working with the date preferences formatting is causing our Wikipedia pages to unnecessarily be cluttered with useless links.

Also, keep in mind that the majority of the people browsing or viewing Wikipedia either do not have user accounts or are not logged in, so they are not receiving any kind of benefit from the date preferences formatting. They're only perceiving the negative aspect of it: articles that are way overlinked to irrelevant dates and years.

I am therefore proposing the creation of a new kind of syntax or function in Wiki source that identifies a phrase as a date so that it can be properly formatted without having to have a date be linked. I don't exactly have something in mind, so for now let's just call it <date> and </date>. I'm sure someone else around here can figure out the appropriate way to implement it. With this feature implemented our article could be a lot better. We could link the first occurrence of December 25 on the Christmas page as [[December 25]] because it is conceivable that someone may want to know what else happened on that date, but for subsequent uses of December 25 we would use <date>December 25</date>. This would help to drastically cut down on the number of unnecessary links.

I'd link to point out one more area in which my proposal would be useful: chronological lists. Many, many articles have them, and typically they consist of bulleted lists starting with the date and then a description of what happened on that day. And those dates are always linked for the sole reason of getting the date preferences formatting to work. Wikipedia:Make only links relevant to the context makes it very clear that something should only be linked when it's relevant to the context; a date link is pretty much never relevant to the context as who exactly is going to want to randomly click through and see what else happened on that day in any other number of thousands of years? So what if the first launch of the Ariane rocket occurred on the same day as the signing of the Treaty of Ghent. Who cares? It's not relevant to the context!

One more thing I'd like to add - it's not obvious to me why date preferences formatting was implemented in the fashion it is now. There are two separate issues: linking to other articles and automatically formatting dates. Why the two were conflated as in the current implementation is beyond me. From the current state of matters one thing appears to me: the situation must be fixed. That is all. --Cyde Weys votetalk 21:47, 25 December 2005 (UTC)[reply]

Addendum: Please see Talk:Christmas#Snipping extraneous links for relevant discussion. --Cyde Weys votetalk 21:49, 25 December 2005 (UTC)[reply]

simple suggestion; ISO format dates (2005-12-25) could just be auto detected. Surpression with some simple sequence (2005-12‐25) in the very rare case it's needed. These have the advantage that they are reasonably country neutral and understandable for all when seen in edit mode. Mozzerati 21:56, 25 December 2005 (UTC)[reply]
  • So your suggestion is to not have any special formatting but just recognize ISO 8601 dates via some sort of regex, i.e. /\d\d\d\d-\d\d-\d\d/ (yyyy-mm-dd in common English). I'm not sure if this will work. Anonymous users, which describes the majority of the people who use Wikipedia, are always going to be seeing ISO 8601, which isn't necessarily as clear as spelling out the month. It might be possible to detect which country the IP address belongs to and format the dating appropriately, i.e. "December 25, 2005" for Americans and "25 December 2005" for Europeans. But I still think the best solution would be some kind of added syntax. It doesn't seem right that it should be done automatically (and only for ISO dates). Wikipedia as it is is very explicit: words are only linked when you specifically say they should be linked, etc. A lot of this could be done automatically but there is going to be some error rate. A workaround like 2005-12‐25 in the situation where you wouldn't want auto-formatting seems very clumsy. I think the easiest way to resolve this issue is to just create the <date> and </date> tags (or whatever they end up being called). That way as you're editing articles that have too many repetitive linkings you simply convert [[ and ]] to <date> and </date>. You wouldn't have to go around changing all of the dates to match ISO format. --Cyde Weys votetalk 22:10, 25 December 2005 (UTC)[reply]

(after edit conflict) I strongly support the addition of such a feature. The "simple" suggestion above is a start, but the vast majority of dates are NOT in ISO format, and that format is not the most helpful one for people without any prefernces (which is the majority of users) so i think it is unlikely to become the dominant format any time in the near future. The mechanics of the synmtax don't matter to me -- it could be pesudo-HTML as shown above or soem more wiki-like markup such as <<5 March 2003>>. Ideally, whatever methos is used, it would involve a single markup for each complete date. DES (talk) 22:13, 25 December 2005 (UTC)[reply]

Please see Wikipedia:Manual of Style (dates and numbers) and Wikipedia Talk:Manual of Style (dates and numbers) for more related discussions. DES (talk) 00:12, 26 December 2005 (UTC)[reply]

Someone tell me why we should add new syntax to the parser to replace something that is intuitive and works already, just because it's "ugly". rspeer / ɹəədsɹ 04:56, 26 December 2005 (UTC)[reply]

It's intuitive to you because you've 'grown up' learning how to do it that way. If you had learned to enclose dates in #12/25/2005#, do you really think it would be all that much harder to figure out? Some of us have a problem with overdetermining the bracket syntax. -- nae'blis (talk) 09:35, 26 December 2005 (UTC)[reply]
  • There's absolutely nothing intuitive about it. Most new users to Wikipedia get very confused by this. Why should you have to turn a date into a link to get it to format properly? That's actually very counter-intuitive. And guess what, something being ugly is a very good reason to change it, especially because Wikipedia is a resource used by millions of people. --Cyde Weys votetalk 15:58, 27 December 2005 (UTC)[reply]

Strong support; I've been meaning to propose this myself. I also strongly support auto-parsing yyyy-mm-dd syntax. The default date format can be something other than yyyy-mm-dd. Other possibilities like {{yyyy-mm-dd}} or {yyyy-mm-dd}.

Related date gripes/suggestions:

  • Signature timestamps should obey date locales.
  • This is probably assumed by the <date></date> proposal: [[December 25, 2005]] should work like [[December 25]], [[2005]].
  • Group linked yyyy-mm-dd dates by yyyy-mm in addition to mm-dd
  • Format any date such as year-month or just year in addition to year-month-date
    • e.g. <date>December 2005</date> should show up as 2005-12 in ISO8601 locales.
    • e.g. <date>567 AD</date> should show up as "0567" in ISO8601 locales.
  • Dates in various article names/categories would be better as yyyy-mm-dd or yyyy-mm instead of spelled-out or American "middle-endian" style (e.g. Wikipedia:Articles for deletion/Log/2005-12-26, Category:Cleanup from 2005-12)

--Quarl 10:18, 26 December 2005 (UTC)[reply]

This edit gives clear evidence why something really needs to be done on this issue. Look at how ridiculous it is to create literally dozens of unnecessary links on a page just to get date preferences formatting working. Some sort of syntax like <date> and </date>, discussed above, is absolutely essential. --Cyde Weys votetalk 20:23, 27 December 2005 (UTC)[reply]

Looking into this one now. :) Rob Church Talk 20:23, 3 January 2006 (UTC)[reply]

Just wondering how this is going. Hope it's going well. --Cyde Weys votetalk 01:06, 10 January 2006 (UTC)[reply]

Someone said this same kind of proposal is somewhere on the Wikipedia Bugzilla but I have been unable to find it with relevant search terms. Can anyone confirm? Thanks. --Cyde Weys votetalk 19:30, 12 January 2006 (UTC)[reply]

Now enter3ed as bugzilla bug #4582. DES (talk) 21:21, 12 January 2006 (UTC)[reply]
That bug was marked WONTFIX, although I am tempted to reopen it. I'll probably do so as I'm implementing it, which will be...whenever, I'm afraid. I've been distracted from development by a number of things; but should be back on track within a few days. Rob Church (talk) 19:02, 14 January 2006 (UTC)[reply]

I think that <date> and </date> is a little too bulky, but otherwise yes — using the same syntax for two things is very bad practice. I would introduce a new, and simpler, syntax that could be used for user-preferred formatting of things other than dates. My suggestion: 

 <<January 13>>           produces  13 January                       formatted by user prefs
 <<2000-01-13>>           produces  13 January 2000                           ditto
 <<2000>>                 produces  2000                                      ditto*
 <<12 BC>>                produces  12 BCE                                    ditto*
 [[<<January 13>>]]       produces  [[13 January]]                            ditto
 [[<<January 13, 2000>>]] produces  [[13 January]], [[2000]]                  ditto
 <<1000 kg>>              produces  2400 pounds (1000 kg)                     ditto*
 [[<<1000 kg>>]]          produces  2400 [[pound]]s (1000 [[kilogramme|kg]])  ditto*

Note *: I'm assuming that in the future, user prefs might be extended. For example, there might be a user pref for BCE/CE versus BC/AD in years, for currency and units formatting, etc. So you could choose to have "1000 kg" presented as "1000 kg", or "2400 pounds", or "2400 pounds (1000 kg)", etc.

Thoughts? — Johantheghost 13:04, 16 January 2006 (UTC)[reply]

I like that idea, I was actually thinking of using double angle brackets originally (it's parallel to [[ and ]]), but I was worrying if it might throw people off, so I went with the universally understood pseudo-HTML code. --Cyde Weys 2M-VOTE 02:02, 18 January 2006 (UTC)[reply]

It's not so much the syntax, as the idea that by not saying "date", we can use the same feature for more generic user-preferred formatting (in the longer term; it wouldn't have to be implemented all at once). — Johan the Ghost seance 11:51, 18 January 2006 (UTC)[reply]
For dates, this seems like a great idea. If we have a locale feature for dates, it should of course support unlinked dates. For unit conversions, this is only good if you can provide the number of significant digits to be used. For example, 1000 kg should usually be converted to 2200 pounds, but 999.95 kg to 2204.51 pounds. Automatic conversion that gives a wrong number of significant digits is misleading, see WP:MOSNUM#Units. Kusma (討論) 23:49, 19 January 2006 (UTC)[reply]
I think unit conversion (i.e. kilograms and pounds) is not nearly as necessary as these proposed changes. Overloading of the linking syntax to mean two separate things is a pretty big problem right now. --Cyde Weys 21:14, 25 January 2006 (UTC)[reply]
I strongly support some kind of action on this subject. My user preferences are set to yyyy-mm-dd and it is so frustrating seeing dates not in that format mixed in with links that are. Additionally we need to review date ranges such as [[December 25]] - 26 or December 25 - 26.
For those unsure how the various options currently are displayed (EG me), I have listed a few variants below to see what your preferences do to the display (The third section in each is what I see with my ISO preference - links shown as italics.) -
      • [[December 25]], [[2005]] - [[December 31]].
        December 25, 2005 - December 31.             2005-12-25 - December 31.
      • December 25, 2005 - December 31.
        December 25, 2005 - December 31.             December 25, 2005 - December 31.
      • [[25 December]] [[2005]] - [[31 December]].
        25 December 2005 - 31 December.           < > 2005-12-25 - 31 December.
      • 25 December 2005 - 31 December.
        25 December 2005 - 31 December.             25 December 2005 - 31 December.
      • [[December 25]] - [[December 31|31]].
        December 25 - 31.             December 25 - 31.
      • [[December 25]] - 31.
        December 25 - 31.             December 25 - 31.
      • December 25 - 31.
        December 25 - 31.             December 25 - 31.
      • [[March 2005]] - [[June 2005]].
        March 2005 - June 2005.             March 2005 - June 2005.
      • March 2005 - June 2005.
        March 2005 - June 2005.             March 2005 - June 2005.
      • [[March 2005]] - [[June 2005|June]].
        March 2005 - June.             March 2005 - June.
      • March 2005 - June.
        March 2005 - June.             March 2005 - June.
-- SGBailey 12:03, 29 January 2006 (UTC)[reply]

Annotated categories instead of lists

I'm sure this is old news, but it seems to me like many WP "List of XXX" pages are unhelpful. Case in point: List of sailors, which is a randomly-selected and small subset of articles from Category:Sailors. This list totally fails to mention some extremely prominent sailors, and of course needs to be manually maintained to keep it in sync with Category:Sailors. Trouble with that is, it would be either a selected subset (and hence inherently POV), or huge.

So, let's ditch the list and just use Category:Sailors, which is guaranteed to be complete, and is neatly organised into sub-categories. Trouble with that is that it's not annotated; unlike List of sailors, which at least provides a useful "who's-who and why" index of some sailors.

So, my proposal: modify the [[Category]] syntax as follows: 

[[Category:Sailors|Slocum, Joshua|first single-handed circumnavigation of the world]]

That is, include the annotation in the article, where it can be maintained with the article itself. Then we just need a change to the [[Category]] feature to (optionally) include annotations in Category pages. Then we can ditch the lists, and replace them with appropriate use of categories.

Note that this proposal works well with articles in multiple categories. Example: 

[[Category:Sailors|Slocum, Joshua|first single-handed circumnavigation of the world]]
[[Category:Authors|Slocum, Joshua|wrote ''Sailing Alone Around the World'']]

would place Joshua Slocum in two category/lists, with appropriate annotations for each. This feature could also be used in categories themselves, to annotate their entries in their parent categories.

What do you think? — Johantheghost 23:05, 15 January 2006 (UTC)[reply]

intresting idea, but it would make it much harder to read thru categories - some of them are very big as it is without notations. BL kiss the lizard 00:04, 16 January 2006 (UTC)[reply]

Thanks for the comment; the idea would be to design categories that replace the lists; so if the list isn't too big to read, then the category wouldn't be either. For example, List of islands of Central America currently is a pointer to other lists, such as List of islands of Honduras. This would be replaced by a category, "Islands of Honduras", which would be a member of category "Islands of Central America". In fact, I note that Category:Islands of Honduras already exists. The difference is that the category will maintain itself; if I add a new island, it won't automatically appear in the list, but it will in the category.
Also, note "(optionally) include annotations" above; ie. you would be able to choose between a conventional category view, and one with annotations.
By the way, I don't think that all lists will convert to categories. But the proposed feature would replace many, if not most, lists (which are currently mostly incomplete) with self-maintaining categories; the result being to make Wikipedia more reliable. — Johantheghost 11:20, 16 January 2006 (UTC)[reply]

Me thinks it's a great idea, but it will be a pain to update all articles. Plus, this is something that must be hardcoded inside the wikipedia progam, I don't know how much trouble would be to do that, or witch person to contact about the proposal. By the way, there might be someone allready thinking a way to implement this, because this is a great idea (well, at least in my point of view). algumacoisaqq 02:38, 16 January 2006 (UTC)[reply]

Thanks for the comments. As for updating all articles, no, the idea is that adding the feature wouldn't immediately change anything; but people could gradually go and change the lists into annotated categories. I would do List of sailors, for example, in a few hours. Other "List of" pages might hang around for a year before getting converted. But yes, this would require a change to the Wiki software — if it got enough support. — Johantheghost 11:20, 16 January 2006 (UTC)[reply]
Feature requests are made using the bug tracking mechanism, see Wikipedia:MediaZilla. There have been a variety of proposals to extend the categorization syntax. One argument against doing this is that many mirrors do not implement categories and to make the content as easily accessible as possible this should not be required (which would lead to a preference not to provide any content, like annotations, using categories). I don't know whether this is actually a consideration in the design of the category feature, but it certainly could be. -- Rick Block (talk) 18:06, 16 January 2006 (UTC)[reply]
Thanks; re MediaZilla, I was kind of wanting to float the idea here, to see if people think this is a good way to replace lists, before requesting the software change (so I can say please implement this, and we'll actually use it).
Re mirrors, your point is an interesting one; but since these people are essentially "ripping off" (albeit in a legally and morally correct way (mostly)) WP content, should we take them into account when deciding the best way to do Wikipedia? Shouldn't we make Wikipedia as good as we can, whatever shape that makes it, and let the mirrors handle it however they like? Or does Wikipedia have a policy of accommodating mirrors? Also, it's not like the content wouldn't be available, since the annotation would just be a summary. — Johantheghost 18:17, 16 January 2006 (UTC)[reply]
It is my understandign that we do have a general policy of accomodating and encourigign mirrors, provided that tney are propeorly compliant with the GFDL. See WP:FORK for more on this. Our fair use policy is designed in aprt to accomodate and encourage commercial mirrors. DES (talk) 20:22, 16 January 2006 (UTC)[reply]
  • IMO there are cases where list are better. First of all, when many entries on a list are significant enough to lsit, but not to have separate articles about. Indeeed "List of minor characters in..." is often a good way to merge many stub articels conencted with a work of fiction. Also, lists can esaily be seperated into sections but presented together, while if items are soreted intoa sub-category, they do not appear on the main category page. Simialrly, a list is much easier to sort according to a non-alphabetical principle. We aslo do not need any software enhancement to ahve an annotated list, while we woudl for an annmoteated category. There are many cases where a category is the better solution, but there are many others where IMO it is not. There are tradeoffs in each case. DES (talk) 19:46, 16 January 2006 (UTC)[reply]
  • Yah, I see what you're saying, and the example "List of minor characters in Hamlet" would be OK, because that'll never change. But the "List of XXX", where XXX is a more general category — like "List of sailors" — should really be abolished, because it will always be wrong (ie. there will continually be things getting added to Category:Sailors but not List of sailors, because people don't even know there is a List of sailors). The software engineer in me can't accept manually-maintained parallel data like this, and my proposal would, IMO, make it easier to replace "problem" lists with appropriate categories. — Johantheghost 20:05, 16 January 2006 (UTC)[reply]
  • But there may well be "sailors" who are wanted in the list, but about whom there are not articles, and if articels were created they would be nothing but stubs. Perhaps "sailors" is a case where a category would be better, but there are many many cases where this is not true, IMO. It is easy enough to get a list of all articles in a a particular category and insert them into or merge them with a list -- there is automated software for doing this (see WP:AWB for one piece of software that can be so used). I have often seen AfDs on list pages where the decision was that a category would be better, and also seen CfD discussions where a cat was deleted in favor of a list, and in many cases i think that having both is the better choice. There just isn't a one-size fits all solution here. DES (talk) 20:15, 16 January 2006 (UTC)[reply]
  • That said, I think your proposal to allow annotation in listing items in a category wouid be a good one. In soem cases it might well dispense with a list, and in many cases it might make a category easier to navigate. Have you loged this as a feature regquest on Bugzilla yet? If so, what is the big number? If not, i suggest that you do so. DES (talk) 20:15, 16 January 2006 (UTC)[reply]
Thanks again for the comments — I guess I'm coming round to thinking that AfD case-by-case is the better way to handle this. The thing about the annotation feature is that it would need to be widely used to be worth it, and I'm not seeing too much support here. Thanks for the pointer to AWB, but I use Linux... :-(
I'll tell you what I would find really useful though: a "list all" feature in a category page's toolbox, that showed all the contents of the category: ie. including all members of sub-categories. IMHO this is a really painfully obvious omission. Eg. maybe one day I go to Category:Sailors, and see all the sailors; next day I go back, and it's been organised into sub-cats, and I have to manually and tediously browse them all just to see the same list. Has a request for this been floated before, do you know? — Johantheghost 21:12, 16 January 2006 (UTC)[reply]
I agree that such a feature would be quite useful. I do not recall seeing it proposed before. I wouldn't think it would be hard to implement. DES (talk) 21:36, 16 January 2006 (UTC)[reply]
Category intersection is an existing request, see bugzilla:2285. "Show all members, including subcats" has also been suggested, but since categories don't form a tree (they're not necesssarily acyclic) enumerating all "members" is potentially quite expensive (to avoid the potential infinite loop, you have to check whether you've already visited each subcat as you go). I suspect this is not likely to be implemented any time soon. -- Rick Block (talk) 21:42, 16 January 2006 (UTC)[reply]
Unless there is soemthing odd about the way PHP works in such matters, this seems to em to require merely the addition of one extra data structhure, a list of sub-cats visited so far, to be passed through the routine. As a list of sub-cats already detected but not yet visited would need to be maintained even of the category structuyre were known to be acyclic, it deosn't seem to me that theis would be likely to be highly expensive in most cases -- the cost of the large lsit of member being developed, and of removing duplicates (if that were to be done) ought to be much higher, i would think. Going from a loop-based or recursive routine that uses one list to one that uses two lists is not likely to increase the cost by a huge factor. When the list of sub-cats is indeed long the checkign code would get more costly, but in that case the results are likely to be large and the call would be costly in any case. If need be the call could terminate after an arbitrary number of sub-cats or members has been returned, just as soem other special calls have a fixed upper bound on their results. DES (talk) 21:57, 16 January 2006 (UTC)[reply]
On further consideration, this is one thing that would really make me trash my proposal! If someone is actively using a category as a list of XXX, and then it suddenly breaks just because someone (constructively) organised the category into sub-cats, then IMO categories can't do the job, and we need lists.  :-( — Johantheghost 23:06, 16 January 2006 (UTC)[reply]

I've just found that bug #1775 is the same as my proposal; also bug #2725 covers the category issue. — Johan the Ghost seance 13:14, 20 January 2006 (UTC)[reply]

Category browsing and intersection have been implemented on the toolserver: CategoryTree and CategoryIntersect. They are wonderful! JesseW, the juggling janitor 11:35, 27 January 2006 (UTC)

How does that help casual users? How are they even supposed to know about this "toolserver"? I didn't until yesterday. I still say that a "Show all" button in a category is necessary to make the category system really useful. (Having said which, yes, they are useful, in the absence of the real thing.) — Johan the Ghost seance 13:06, 27 January 2006 (UTC)[reply]
I agree, it does not help casual users, but it's a lot better than the deeply crappy systems we had before(one of which I wrote, so I know what I'm talking about when I say they were crappy). That's why I'm so excited by them. It would certainly be great, and, I agree, important, to add these features to MediaWiki. JesseW, the juggling janitor 06:50, 28 January 2006 (UTC)

Wikipedia:Arbitration Committee/Clerk's office

(cross-posted as this is an odd little policy, so here is good, too)

This expansion of ArbCom to include "officers" doesn't appear to have gotten much press. It involves someone whose job it to summarise and present the information presented into digestable packets for the Arbitration Commitee.

It's "going live" any day now, but there have been concerns expressed that it's a "back door" for people who failed re-elction to maintain their powerbase. Additional concerns around why this person would need access to the abritrator only mailing list have been raised.

brenneman(t)(c) 02:13, 25 January 2006 (UTC)[reply]

/me listens to the crickets chirping since nobody else seems interested enough to reply JtkieferT | C | @ ---- 01:16, 27 January 2006 (UTC)[reply]
Please see WP:CIV. Also, despite your sarcasm and an odd spree of comment blanking and page protections by various parties, this issue does appear to be attracting some attention. - brenneman(t)(c) 01:40, 27 January 2006 (UTC)[reply]
In the UK, we elect a government, and they appoint their officers. There is no popular scrutiny, as we empower the elected ones to delegate at will to thir 'administration'. I see this in the same way. --Doc ask? 01:48, 27 January 2006 (UTC)[reply]
Perhaps. But the incivility, blankings (over 3RR in one case), hurried archiving, and application of page protection all seem like bad form to me. We're not seeing anything like "discussion" over this. Can we at least admit that it looks bad if nothing else?
brenneman(t)(c) 01:55, 27 January 2006 (UTC)[reply]
Given the fact that there has been such inexplicable vitriol shown to KM by one section of the community, this was always going to be a very provocative move. But if she is willing to do it, and our elected Arbcom willing to trust her, that should be sufficent. Is anyone arguing that she's not up to it? Or that the folk the community has elected are so weak, that she'll bewitch them and usurp their power? No. Rather this is about a silly personal vendetta, a conspiracy theory, and a lot of paranoia. As for the blanking etc, I don't know. I removed a thread (mistyped threat) from a user RfC, as it was commenting on an Arbcom decision not the actions of a user. Aaron, this whole thing has got totally out of hand. Someone deleted a bunch of non-encyclopedic stuff (perhaps unwisely), the deletion quickly was reversed - and then this crazy hysteria errupted. One admin was made into some form of hate figure - and WP:AGF, WP:NPA and WP:CIVIL were thrown out the window. Frankly, Kelly deserves a medel for putting up with all this crap, instead she is given a thankless job to do. And the problem is? --Doc ask? 02:11, 27 January 2006 (UTC)[reply]
The problem is that as long as we keep doing things that re-enforce the appearance (at the very least) of an "old boy's" network, we'll keep having problems with "hysteria". The facts that the ArbCom need the work done and that they don't have to ask anyone ignore the underlying issue: Why again and again are things done in the most difficult way possible, in the way almost certain to raise a storm. Nothing that the clerk is going to be doing actually requires a quasi-official position to be created, and by first doing so (process wonking?) and by then saying "it's done, stuff you's all" all we do is fire the flames of discontent. Happy happy campers will contribute better, and if nothing else doing things a different way will mean that less time has to be spent arguing about it. - brenneman(t)(c) 02:31, 27 January 2006 (UTC)[reply]
I strongly favor having a secretary or clerk for the ArbCom. There are numerous clerical tasks that have to be performed to help keep the cases tidy, and that burden does not need to fall on ArbCom members. Without a chair of the ArbCom, if it difficult to even know how to address a question or comment to the ArbCom as a whole. A former ArbCom member seems well-suited to the task, since he or she already knows the workings of the group, but anyone could do it or help. -Will Beback 04:00, 27 January 2006 (UTC)[reply]
Re the argument that we don't need an official Clerk's office for this, I would ordinarily agree but for the fact that while pretty much anyone can tackle evidence, the workshop, etc., only trusted users can post to the Arbcom mailing list, close cases on behalf of the arbcom, etc. Since we're going to need some official way of identifying those users the Arbcom trusts, we might as well mention that these guys are also trusted to properly write up evidence, etc. Johnleemk | Talk 13:59, 27 January 2006 (UTC)[reply]
I don't understand this argument.
  • Whomever wishes to can edit the workshop pages, and that's where the real mean-and-potatoes of this effort should be going. That's where the largest amounts of noise are, and the most guidance needed.
  • As to "trusted effort" the evidence pages are (by convention) edit-only-your-own areas. Anyone "trusted" can just put their tid-bits of summarised evidence there as opposed to the mailing list. Unless what the clerk will be sending to the mailing list isn't evidence but conclusions, which would suggest that the ArbCom was then not going to read the evidence?
brenneman(t)(c) 15:05, 27 January 2006 (UTC)[reply]
You're presuming the mailing list is going to be only used for issues directly related to arbitration. There are a lot of maintenance duties, etc. that a private mailing list could very well be required for. To cite one recent instance, Kelly Martin emailed the list saying she would close a particular case within 24 hours if no arbitrator objected. Fred Bauder later withdrew his vote to close the case, and it stayed open. (This can easily be verified from the talk page of the Clerk's office.) I'm sure that as we go along, other uses for the list will be found. The existence of Clerks should not prevent anyone from presenting evidence or editing the workshop -- clerks are just certified to be people whose advice should generally be listened to WRT arbcom matters -- not a whole segregated class of their own, above the hoi polloi. Johnleemk | Talk 05:12, 28 January 2006 (UTC)[reply]

My two penn'orth. On the personalities: I don't approve of vitriol, but I've seen Kelly Martin behave both badly and very dubiously; I'd certainly not trust her as an ArbCom member, and people like me voted against her for that reason. On the various recent antics: she's clearly in a little group of chums who tend to stick together with a "my friend right or wrong" sort of attitude, and who include many editors of long-standing and (what is perceived by many people as being) authority; this has probably been part of the cause of hasty actions such as the protection of Talk pages and RfCs and other attempts to suppress criticism of her. On the procedural issue, it is indeed very difficult to see why the ArbCom needs these "clerks", especially why they need a "head clerk", and most especially why they appointed someone who has just been rejected as sufficiently trusted for an ArbCom rôle. I've seen the excuse that it's no big deal, as anyone can do what the clerks do — but then why appoint clerks? We're not a state with a government, and so the analogy with the appointment of officials is inapt, pace Doc Glasgow; the only reason that most of us can see for this extension of official or semi-official (or quasi-official) positions is some variation on jobs for the boys and girls, and you don't have to share my anarchist leanings not to like it very much. --Mel Etitis (Μελ Ετητης) 17:22, 27 January 2006 (UTC)[reply]

Presumably the arbcom is well aware of Kelly's personality and chose anyway to appoint her as Head Clerk. People like me voted for them (Filiocht, Mackensen, Sam Korn, et al) for that reason. I trust their judgement. If Kelly makes a mess of it, I expect them to "sack" or "fire" her. Johnleemk | Talk 05:12, 28 January 2006 (UTC)[reply]

some ideas...

Hello everyone. I was brainstorming some ideas for Wikipedia and this is what I came up with:

  1. A more user friendly main page with icons (I like the new proposed main pages with the icons on top) would be less intimidating to novice and new users.
  2. It is hard to find other wikimedia sites as I don't see any links to them in a sidebar, something many people are familiar with.
  3. I personally believe this website would benefit from Google ad technology. In my opinion, you can keep the integrity of your website and not disturb uninterested visitors while covering operating expenses.
  4. Another idea I brainstormed was a one-time-only page that would pop up after users read a certain number of articles. A kind request for a donation and a keep doing what I was doing setup would help.
  5. It would be interesting to see if biographies and other disputable subjects could be confirmed as accurate by someone who isn't connected to the project such as a family organization, authors, or the general public.

Keep up the awesome work! —The preceding unsigned comment was added by 65.31.187.201 (talk • contribs) .

First off, sorry for editing your comment a little; the formatting was messing up the page. I can't deal with points one and two, but point three has been discussed before, and we've agreed not to have any ads on Wikipedia. There are a group of users actively opposing any attempt to add advertising to Wikipedia, and I don't think Wikimedia is in that much financial trouble yet. Not to mention that having seen other MediaWiki-based sites with them, I think Google ads would look terrible. Point 5 is also interesting, but AFAIK we prefer to internally review articles and make sure we cite sources for their claims. Johnleemk | Talk 15:43, 25 January 2006 (UTC)[reply]
See Wikicities for an example of a Mediawiki site with Google ads. One good reason we might not want to use Google ads is because they impose content restrictions that would effectively censor Wikipedia (see [1], section 5, "You shall not...display any Ad(s)...on any Web page or any Web site that contains any pornographic, hate-related, violent, or illegal content"). No comment on other points. Deco 22:55, 25 January 2006 (UTC)[reply]
John, yes we are in that much trouble. To continue to grow at the current rate, the hardware guru's have estimated our harware expenditures should be $4-5million for 2006. Fundrives probably cannot raise that kind of money, though anything is possible. Eventually the people that are so strongly against ads may reallize how much farther we can go towards meeting the Foundation's goals if we did accept some form. Getting information to people in their own language is going to require serious money and may require different strategies. Currently the only languages we have a significant number of articles in are those languages from the developed world. For Hindi, Arabic, Bengali, and Punjabi, each top 10 by number of speakers in most counts, we have 1,000, 10,000, 500, and 39 articles respectively. - Taxman Talk 19:16, 26 January 2006 (UTC)[reply]
Hiring full-time multilingual Wikipedians to work on expanding the scope of the project is a great idea. But any kind of advertisement would place us in a position where the ad provider could pressure us to censor or include certain content. Certainly Google Adsense does, and I don't know of any other unobtrusive advertisement system. Sacrificing the integrity and values of the encyclopedia, along with a good chunk of our best contributors who don't like the idea, isn't the best way to achieve these goals. Deco 01:53, 27 January 2006 (UTC)[reply]
Well we certainly wouldn't accept anything without a firm rule of no influence. Though I'm sure they'd try. Our own ad supported mirror is a possible idea to avoid the influence. In any case, something's going to have to give. - Taxman Talk 05:26, 27 January 2006 (UTC)[reply]
I find the Wikipedia search engine somewhat lacking in usability, and sometimes will instead use Google to do a wikipedia domain specific search. Google is making $ off of my use of their search engine, but none of that $ is going back to Wikipedia. What about adding Google, Yahoo!, and other search boxes to Wikipedia:Searching#External_search_engines or some special search page? We can't endorse just one search engine, so maybe we could put multiple search boxes. While I'm opposed to ads on Wikipedia itself, the ads would be on search results hosted by Google, Yahoo!, ... and contains ads like any google/yahoo results page. -Kmf164 (talk | contribs) 00:07, 29 January 2006 (UTC)[reply]
http://openusability.org/reports/view.php?group_id=109&repid=69 is a report (November 2005) on usability testing for the German Wikipedia. Searching is one of the key frustrations and usability problems with Wikipedia. Why reinvent the wheel, improving Wikipedia's internal search engine, when Google, Yahoo!, and others already do a good job with searching? As well, people already have familiarity with Google's (or Yahoo! ...). It's good usability practice to allow such familiarity to transfer across different websites (incl. Wikipedia). -Kmf164 (talk | contribs) 00:18, 29 January 2006 (UTC)[reply]
I would argue that if searching is one of the main frustrations, than perhaps we could provide, in addition to the simple google-like search box, an advanced search page, like google has, for more specific searches. A feature has been suggested on bugzilla for wikinews which would allow users to have a news search with category filters, for doing research. This would be a nice option. Kevin Baastalk 00:32, 29 January 2006 (UTC)[reply]
I agree there. Maybe after a break once the main page redesign is completed, Wikipedia:WikiProject_Usability could next work on improving searching of Wikipedia. An advanced search page would indeed be useful. And only recently, I came across this searching page that explains more how to use the search feature, yet alone these links to external search engines. We should make Special:Search page more useful, with link to Wikipedia:Searching, advanced search options, as well as a page for using Google, Yahoo, and other external search engines. -Kmf164 (talk | contribs) 00:56, 29 January 2006 (UTC)[reply]

Band Formatting

I've been working on a lot of bands recently and I've noticed that for the major bands there tends to be some consistent formatting, but for less significant bands there's really almost no formatting. Is there, and I simply haven't found it? If there's not, wouldn't it be great if there was? If you agree with the last, how do we go about creating that? A bot? Or would this be too complicated?

I feel like the formatting should include sections for band history, members, and discography, and a picture if available, and of course an overview/intro before sections. Those nice little boxes are cute too. From what I've seen now, when some of those sections do exist, sometimes albums are linked, sometimes not. Sometimes the albums are in italics, sometimes with dates, sometimes neither. Sometimes band members are linked, sometimes not. What do y'all think are good formatting policies for this? Is this even the right place to ask about this? Anyway, I'd like to know what the community thinks of this. -GlamdringCookies 08:01, 27 January 2006 (UTC)[reply]

I don't think there's a current guideline for sections of band articles - although it seems like a good idea - but start by reviewing Wikipedia:WikiProject Music and its subprojects. I'm sure you'll find a good place to make your suggestions. — Catherine\talk 02:34, 29 January 2006 (UTC)[reply]

Football (Association Football) League Fixture Maintainers required (coca cola league 1&2)

Hello there, tis i, Spum. I have managed to now get the Football Portal on Wiki/news to churn out relevant stories, and there's been a good stready flow of them appearing from other users. Now, shortly, i'm going to be adding a transfers section, listing recent club transfers. Now, I require 2 people - One for coca cola league 1, and another for coca cola league 2 to maintain the results, fixtures and upcoming matches section..If you can add news stories which are important in those leagues, then go fo it; the more the merrier! It's not much work, as there aren't many football matches in a week for the coca cola league, but i'm currently maintaining a large proportion of all the content, and would like some help with it.

Click here to look at the portal.

If anyone wishes to help, or knows anybody who would like to; then please get stuck in, or get in contect with me; you don't need an explicit knowledge of football, you just need to know about how league tables work, and what days to update the table, which isn't too much work for some of those clever-pedians we have here!

I really appreciate any help we can get; i can only see the portal getting wikinews more hits, and making the footy portal get more contributors! Tergards, muchly;

The magical Spum-dandy 13:34, 28 January 2006 (UTC) ![reply]


Wikipedia contribution for technical dummies but academic geniuses

I couldn't find this exact suggestion anywhere on perennial proposals or elsewhere, so apologies in advance if it's been mentioned a lot. Basically, is there any movement at all on here to make Wikipedia something that the less-technically savvy but very non-tech-subject savvy experts out there can contribute to? I'm talking about people who can cope with e-mails and entering web addresses and typing letters, but who run away at the sight of anything resembling code or scripting (which is what Wikipedia looks like when you try to edit an article, or if you even try to discuss an article). I guess ideally it could be some kind of web-based Wizard, which would take someone through the editing process step by step (and maybe layout too, although I suspect beginners would rather stick to the actual text at first). It could also invite people to register if they wish to, if they haven't logged in. Links to the "boot camp" and how-to guides could be peppered throughout the Wizard so existing efforts wouldn't be duplicated. I'm just frustrated at how editing a Wikipedia article can be as tricky as handcoding HTML, whereas most of the world's experts on non-technical topics (the kind of topics Wikipedia needs experts on the most) would have little or no experience in such matters or concepts. --Krisse 18:52, 28 January 2006 (UTC)[reply]

I disagree. There are links to help on editing near the submission button, and i find wiki markup to be MUCH easier than using word processors The magical Spum-dandy 19:24, 28 January 2006 (UTC)[reply]
Pretty much the only things you have to know to get started are (1) how to generate a wiki-link (to another article) and (2) maybe add a picture. Everything else beyond that can easily be fixed later by others. And all of this is covered in wikipedia:tutorial Raul654 19:29, 28 January 2006 (UTC)[reply]
One of the beauties of the wiki syntax is that, for the most part, it's just the text on the page, with blank lines between paragraphs. That's all you need to know to contribute at the simplest possible level. Other contributors can add other formatting. On the other hand, editing an existing page can be a daunting experience when it's full of scary markup and you have trouble even finding the text you want to change. WYSIWYG would definitely have advantages if we could do it in a way that doesn't suck. Deco 00:59, 29 January 2006 (UTC)[reply]

Image maps

Wouldn't it be great if we could use image maps? This could be useful in the article Worms weapons and tools for instance, so the user can click on an icon in the weapons grid (on the right) for a #redirect to its description. Of course, the possibilities are endless: imagine watching a picture of a pediment and being able to click through to articles on the different characters depicted by clicking on them or using a picture of a piston engine as a base for linking articles on the separate parts at a central location. Ma.rkus.nl 23:51, 28 January 2006 (UTC)[reply]

Image maps are quite handy in many situations, but with current editing support still limited to text fields and file uploading, it seems like they would be quite cumbersome to edit. I think they'd still be justified though in the relatively rare situation where they're needed - but a nice editing interface would make them even more useful. Deco 00:45, 29 January 2006 (UTC)[reply]
I've long wanted something like this. I've tried a few tricks to try and get such image maps, but all are quite cumbersome. One example in use can be seen at Wellington Street, Ottawa, and something similar to this could be done for Worms weapons and tools. - SimonP 03:44, 29 January 2006 (UTC)[reply]

Edit Article Intro (without having to edit whole page)

You can edit any section of an article without having to load the whole page up, but this is impossible if you want to edit the intro section at the top. Could a discreet link be introduced that allows you just to edi the pre-section section of an article? I'm think an option in the sidebar where "What links here" is, just another link saying "Edit introduction". -- Alfakim --  talk  01:03, 29 January 2006 (UTC)[reply]

Mediawiki used have an edit link for the lead section. I don't understand why it was removed; it's clearly much more sensible than adding "&section=0" to the end of an edit URL. ‣ᓛᖁ♀ᑐ 01:44, 29 January 2006 (UTC)[reply]
There are a couple of user scripts that add a tab to edit section 0. General scripting information is at Wikipedia:WikiProject User scripts and the list of scripts available is at Wikipedia:WikiProject User scripts/Scripts. the top two scripts on the list enable editing of the top section of an article. --GraemeL (talk) 01:49, 29 January 2006 (UTC)[reply]

Month Year in Something Events

EG February 2005 in science January 2005 in Britain and Ireland.

The "Current events" versions of these pages are, (IMO rightly), in reverse chronological order. When they become history, we are keeping them reverse chronological. However new pages dealing old things are almost always done in chronological order. I think we should reverse the date order within the older pages to forward chronological.

What do folk thinlk and how old is "history" and how new is "current". I would suggest that the previous month should remain reverse chronological, but previous months be swapped round. IE on Feb 1 2006 we could/should shuffle all the entries for Dec 2005.

Comments? -- SGBailey 11:44, 29 January 2006 (UTC)[reply]

All these pages follow the example for Current events and its "archiving" methods. If this page changes its way, those will all follow, I would guess. Have you asked this question in the talk page, there? Awolf002 00:13, 31 January 2006 (UTC)[reply]

Special:Listusers

I have a suggestion that I would like to bring up and get some opinions on. I am proposing that Special:Listusers be divided into users and indefinantly blocked/vandal accounts. This would provided better navigation on the list of users and would help better identify vandal accounts. Thoughts? SWD316 talk to me 16:26, 29 January 2006 (UTC)[reply]

Wikipedia:WikiRPG

It is old proposal, but I suppose hardly nobody knows that this project in pl wiki is very very fine. More than 40 Players, more than 30 department of quests. And it is more useful that asks for quests wherever in wikispace. All players gives points for realised quests and all quests are controled by WikiMasters. And last but not least it is very funny game. Look here and for related changes here. It is now not only game but work too - work in WikiFactory!. MetaWikiMaster ;) of WikiFaktoria. Przykuta 21:14, 29 January 2006 (UTC)[reply]

Someone else thought of this first? I thought I was the only one. I scrubed it when people started talking about how the editors thought of wikipedia as an RPG and didn't take their work seriously. I restored my work, is this what you meant, Przykuta? -> User:Rayc/Wikiquest --Rayc 22:20, 29 January 2006 (UTC)[reply]
Something like that. For beginning one or two simple quests. And one important info - people want... points. A simple quest is "do interwiki" - 2 points for each in en wiki; 4 points for interwiki in other Wikipedias linked to en wiki. It's not all - narration.

Look for schema in pl wiki: 

== Quest Name ==

Narrator's note
*'''Desription:'''
*'''WikiMaster:'''
*'''Start date:'''
*'''Number of points for quest:'''
**'''xxx points''' per...
**'''yyy points''' per...
*'''Realized by:'''
*Below write your realized quests + ~~~~
*#

Here is link to the quest "Interwiki" with a lokal hall of fame. It is boring work when we do it daily, but not when it is Quest.

But it is only a tutorial ;) Now I want to lead a campaign.

First quests in pl wiki was Writing articles about castles and legends, Welcoming - it is still big quest - almost everybody newcomer is welcoming (without vandals of course). But pl wiki has another problems. I think it is worth to find a group of Wikipedians who want to start WikiRPG. Przykuta 00:19, 30 January 2006 (UTC)[reply]

What can players do with the points? Who judges whether quests were completed with sufficient quality and care? Deco 03:39, 31 January 2006 (UTC)[reply]
WikiMaster is the person, who judges players and enter players (with their points) on a list (Hall of Fame) Przykuta 21:06, 31 January 2006 (UTC)[reply]
It's an interesting idea, but as it is now it's not very practical. Eluchil 07:04, 31 January 2006 (UTC)[reply]
So - on pl wiki start has not been easy too... Przykuta 21:06, 31 January 2006 (UTC)[reply]
I think the idea is to make a game of production as a opposed to a game of finding stuff. The problem I see is point tallying. It's almost more work checking to see if work is done then actually doing the work. I was thinking for this welcoming quest, you could give each player a link that they could include in their welcome, and then the "wikimaster" could just go to the page and click what links here to get a tally. Of course, maybe we could just set up the quest and have the players edit the accomplishments, sort of like the Wikiholic hall of fame.--Rayc 22:41, 31 January 2006 (UTC)[reply]
Yes, yes. This is only example of Wikiquest (Quests with finding stuff - NPOV, NPA, vandalisms - it is very funny too :) Others quests are: killing stubs, finding Cthulhu rituals (special vandalisms like "gfdkfdgkfdskgsd"). Maybe this quest (Welcome) will be easier (for wikimaster), if players will put only links to logged users, not IP. And - maybe it is quest for 2 WikiMasters on en wiki... This is hardy work for WikiMaster. Look for archives of that quest on pl wiki ;). So, about sort - if you want :) (but maybe without comments ;) We have on pl wiki local tally on every quest's page and global Hall of Fame. Przykuta 12:45, 1 February 2006 (UTC)[reply]

Volatility

There has been a discussion again on slashdot about edit wars, and bokmann had an interesting suggestion: to include some sort of indication of the volatility of the article in the header. Lots of ways to do this - last edit date, edits in past week/month/year, whatever. It may be worth considering.

http://politics.slashdot.org/comments.pl?sid=175545&cid=14594374

Edit wars and volatility are one of the primary issues dealt with by the Wikipedia:Stable versions proposal, which delegates such arguments to a working version that is not considered "official" while the stable version remains reliable. Deco 07:26, 31 January 2006 (UTC)[reply]

Restructuring ref/help desk with subpages

There is currently discussion at Wikipedia_talk:Reference_desk#Restructure_with_subpages about restructuring the reference desk with subpages instead of having one huge page. This idea could potentially extend to the help desk. Your comments and thoughts would be most appreciated. Thanks! enochlau (talk) 23:27, 29 January 2006 (UTC)[reply]

New Wikipedia Page Type Proposal

Wikipedia is a tremendous resource for so many things, but there is one NPOV 'type' page that I am forever looking up on the internet that Wikipedia does not currently offer. That is verses pages, or comparison pages. I constantly trying to find out what the differnces, pros and cons, of a great many items, though mostly in the area of hardware and software. in many cases there are non-wiki sites that offer such comparisons but sometimes i use Wikipedia for the comparison by comparing two or more items' page. Book vs. Movie, PPC iMac vs.Intel iMac, H.264 vs. DivX (XivD), et cetera. Perhaps "vs." isn't the best phraseology but it's a common format used for looking up comparisons. Thank you, Pattersonc(Talk) 9:58 PM, Sunday; January 29 2006 (EST)

I don't think this is a good idea. Wikipedia is an encyclopedia, which means each article should (ideally) be a descriptive exposition on a single tangible topic. Choosing comparisons to write about is inherently arbitrary and the content would be original research, which is forbidden. It is also very difficult to make meaningful comparisons within the NPOV. Perhaps, this could be a sustainable project elsewhere, but Wikipedia should not host it. Superm401 - Talk 05:41, 30 January 2006 (UTC)[reply]
  • I understand your point quite well and agree with it. I'm on the fence here. On one hand I think Wikipedia should maintain a strict adherence to an encyclopediac format, while on the other I want it to be a repository of all knowledge possible. Pattersonc(Talk) 10:16 AM, Monday; January 30 2006 (EST)
I'm unconvinced that choosing comparisons to write about is arbitrary, after all if we have sources for the comparison already being done elsewhere, I see no reason not to report the facts. The important thing is that we report comparisons whose importance has already been established by their appearance in some reputable source, e.g. the Freedom House rankings; creating our own comparisons would be original research. Christopher Parham (talk) 01:05, 31 January 2006 (UTC)[reply]
We have a page like this for drug legalization: Arguments for and against drug prohibition. It has an interesting history; people can't agree on what should be included or how material should be presented. This month it's been gutted.
In my opinion, Wikipedia should have lots of pages like these for controversial issues, in order to capture the full depth of each side. This doesn't violate NPOV: representing all sides is vital to NPOV. We do teach the creation-evolution controversy quite extensively; there are many other more important issues that should receive the same level of attention. ‣ᓛᖁ♀ᑐ 01:40, 31 January 2006 (UTC)[reply]
Having kept a fair eye on that article, it's not in great shape -- its current state (still not too good) only exists because one wise soul just knifed about 60% of the text. The point being just that articles which exist precisely to play up something controversial and to highlight the most controversial aspects need to be watched extremely carefully. Christopher Parham (talk) 09:07, 31 January 2006 (UTC)[reply]
We discuss pros and cons in many places. For example, articles on data structures and algorithms routinely compare them to other data structures and algorithms. Articles on noneuclidean geometry compare to Euclidean geometry. Articles on Civil War Union generals compare to other Civil War Union generals. It's just a natural thing to do within the context of an existing article. That said, having separate articles could help to avoid redundancy and maintenance problems where both of the articles for two topics compare it to the other. Honestly, if you think there's enough to write about a comparison that it deserves an article, as in the evolution/creation controversy, just come up with a name and write it. AfD will hardly ever destroy a good article - at worst they'll merge it into something. Deco 07:25, 31 January 2006 (UTC)[reply]

Time Delay for Non-Registered Users

  • I find that most non-registered editors fall into two groups: those doing small adjustments such as typos, and those blatantly vandalizing. If we incorporated a short wait time between posts (like on IMDb's message board) for non-registered editors, the positive contributers would still be able to make their changes while the cannonading by vandals would be minimized. Pattersonc(Talk) 12:55 AM, Monday; January 30 2006 (EST)
  • The usefulness of this may be limited. Recent changes in editing policy have led many vandals to create accounts where they would not before. Deco 03:34, 31 January 2006 (UTC)[reply]
  • Which is fine. Blocking a registered user for vandalism will not hinder the IP address of other's on their subnet. Also, the majortity of vandals are non-registered, and I suspect this will be the case for quite some time. Pattersonc(Talk) 1:07 PM, Tuesday; January 31 2006 (EST)

Add "Email this Article to a Friend" Option

This idea has probably come up already at this point and may already have either been shot down or put into the implementation process, but here goes anyway...

I think Wikipedia articles should have the option to "email this to a friend", like many online news sources do.

I frequently use this service option on other sites (e.g. BBCWorld.com, NYTimes.com, and TheOnion.com) to alert friends and acquaintences of interesting news items. I realize that Wikipedia is not really a news website, but as a constantly updating repositiory for information, it couldn't hurt to offer the option.

For instance... Say two friends are having a "discussion" (argument, if you will) about some topic. One says something, the other denies that it is true. Later that day the first is online, heads to Wikipedia, looks up the answer and discovers he is correct. He can then, right there, click and send a link to the article straight to his friend, with a little (gloating?) message. Now, I do realize that this very thing caused the scandal with mis-information on the site, but I still think that (with the new scurity messures that have been implemented) Wikipedia can act as a wonderful tool for personal intellectual debate and the emailing option would therefore be an attractive option.

It would also serve well for aiding in research or other academic endeavors through the site, as a student or teacher/professor, could easily alert class members or colleagues to reference information throught this service, which would aid the site's use as a learning tool, as well as giving it additional (free) adviertising within the academic world.

  • I love the idea. It's also simple to code and implement. Pattersonc(Talk) 11:17 AM, Monday; January 30 2006 (EST)
Doesn't your browser have this capability? I use IE, and ther's an icon at the top of the page which mails the current page. User:Zoe|(talk) 16:39, 30 January 2006 (UTC)[reply]
Blocking anonymous article creation was not a security measure. It was a policy decision that may or may not reduce vandalism. As for this, why can't you just email the url? I never got that. If you want to, you can even email the permalink. To get to the permanent version (permalink), click "permanent link" at the bottom of the navigation area on the left of your screen (assuming you're using the default interface). That means they'll see the exact version you do. Doing the email seems like an unnecessary drain on resources. It could also result in spam or copyright issues. Superm401 - Talk 23:55, 30 January 2006 (UTC)[reply]
I actually think this is a good idea - it would increase interest in Wikipedia and help us drive editing and new editor arrival rates. The mail should send out a permalink so that they see the same version. We could add little trailers to the e-mails going out linking to the main page and maybe even encouraging donations. Admittedly, this would've been more useful when Wikipedia was nascent and little-known. Deco 00:44, 31 January 2006 (UTC)[reply]
Could we accomplish the same thing with a simple mailto link including the URL? I created a template to demonstrate, {{email}}. It renders as:
@
The source is (previous post was wrong):
[mailto:?body=Check%20out%20the%20Wikipedia%20page%20{{FULLPAGENAMEE}}%20at%20{{SERVER}}/w/index.php?title={{FULLPAGENAMEE}}%2526oldid={{REVISIONID}} Email someone this page]
The template should work on any page and could be included in the toolbox with some adjustment. The only problem I see is that it puts underscores instead of spaces when mentioning the name of the article (to avoiding breaking the link). This could be easily fixed when converting to a toolbox link. The advantage to this solution (besides allowing adoption elsewhere on the wiki) is that it doesn't requre server resources to send the mail. The converse is that not everyone has access to a mail client (and some clients don't read mailtos) Superm401 - Talk 08:53, 1 February 2006 (UTC)[reply]
No need to use underscores - if you visit a URL with spaces the software will automatically convert them. This looks like a pretty good solution - let's bring it up on the talk page of whatever Mediawiki page corresponds to the toolbox. Deco 20:14, 1 February 2006 (UTC)[reply]
I know, but the problem is the wiki syntax for links. There can be no spaces in the mailto URL (which here is everything before "Email someone this page") because spaces separate the URL from the displayed text. That's why I've escaped the spaces in the text as %20 . I had to escape the page name (and permalink) using underscores because Wikipedia variables don't seem to provide a way to escape page names with %20 (and I spent a while working on this). Also, I looked through Special:Allmessages and I don't think there is a corresponding MediaWiki page for the toolbox. We would probably have to get the devs involved. Superm401 - Talk 01:56, 2 February 2006 (UTC)[reply]
We'd have to remember to include the full text of the GFDL in every email, e.g. as an attachment. Yay for the GFDL. -Splashtalk 00:47, 31 January 2006 (UTC)[reply]
Why would we have to do that? — Knowledge Seeker দ 02:11, 2 February 2006 (UTC)[reply]
Because the terms of the GFDL insist you include a full copy of the license with each copy of GFDL'd material you distribute. Which is why it's a PITA for e.g. images. See Wikipedia:Text of the GNU Free Documentation License#2. VERBATIM COPYING. -Splashtalk 02:29, 2 February 2006 (UTC)[reply]
You are correct, but this does not apply to mere links to the material, only if we send out the full text of the article, which we have no intention of doing. Deco 02:38, 2 February 2006 (UTC)[reply]
I agree with Deco: the GDFL may apply to the text of the articles itself, but not to the URLs that link to those articles. — Knowledge Seeker দ 03:46, 2 February 2006 (UTC)[reply]
I was interpreting the section heading literally. -Splashtalk 03:47, 2 February 2006 (UTC)[reply]

Improving Article Creation

Well, not really that dramatic, but as someone who works extensively on newpages, it seems to be that something needs to be done. People create articles without really understanding what they're doing, and that's understandable, we don't have a good enough system to help them avoid common mistakes. This leads to the vast ammounts of new articles being created (since many new users seem to want to create new articles more than they want to edit existing ones), which in turn is really at the heart of many problems WP faces. AfD gets overloaded, not because AfD itself is broken, but because too many articles are created that need to go to AfD. Potentially dangerous hoaxes can lie dormant for months because there are so many articles created that the experienced people looking at newpages and orphaned pages can't truly do a good job on every new page, and a lot falls through the cracks.

Right now, we are just giving people a blank page and saying "Have fun!" This really seems to be at the root of the problem. How can we expect people to not create "junk" that requires cleanup or deletion? Do we really think they're going to read through 20 scattered guidelines before creating a page? It's only natural that, given the system we have in place, we're in the situation we're in.

So to fix it, I think article creation needs to be changed, at least for new users (accounts created in the last 7 days, less than 50 edits, would seem like good criteria to me). I think WP:AFC has it right, providing them with a template instead of a blank page is a vast improvement. I propse that new users have this template added to the editbox when they create a new article:

<!-- IMPORTANT: If you copy and paste from another website, the article you create here will be removed. If desired, seperate into sections like this: ==Section 1==, etc. Create links to other Wikipedia articles [[like this]] and links to external web sites [http://www.otherwebsite.org like this]. -->
'''{{PAGENAME}}''' is <!-- Write the initial content directly after this introductory phrase IN YOUR OWN WORDS--!>
== References ==
<!-- Give at least one PUBLISHED source for the information, like a newspaper article or book. Other editors must be able to check it, so "personal knowledge" is not enough, and your article may be deleted if it does not have a valid source.-->
<!-- Suggestion: Find one or more categories into which this article fits. Start at http://en.wikipedia.org/wiki/Category:Top_10 and click through until you find a specific one that fits, then write "[[Category:Nameofcategory]]" below this line --!>

(it looks a little junky formatted, but as text in an editbox it is much cleaner, try it out). That's just a rough draft anyway. This really isn't that drastic. It gives new users a more realistic opportunity to properly create an article by telling them how to avoid all of the mistakes we see all the time with newpages. This template, if followed, would really cut down on the routine cleanup needed on most articles new users create. The need to cite a reference will make it easier for us to detect hoaxes (and to not inadvertantly delete an article just because we're unfamiliar with it), and it would help new users in a rush to create articles know that a lot of things such people want to create articles about aren't appropriate topics, since there can never be a good reference for those topics.

Also, a bot could easilly be run to remove this template from pages older than 24 hours or so, since beyond article creation it would just be clutter in an article.

Even if this proposal seems a little wacky, I really believe we need to give people something better than a blank editbox to create articles with. A lot of problems are coming from the primitive, mistake-encouraging system we have in place now. --W.marsh 16:09, 31 January 2006 (UTC)[reply]

Good idea; I agree that the existing guidance for a new article is pretty minimal. How about going farther and putting up actual prompts for references, categories, etc? If we prompted the user to enter alternative names (eg. "Antipodes", "Antipodal Point", "Other Side of the World"), we would have a better chance of spotting whether the article already exists in some form. — Johan the Ghost seance 16:38, 31 January 2006 (UTC)[reply]
Yeah, the creation of duplicate articles is another common consequence. Often it's as simple as creating a page with the wrong capitalization or a common mispelling. I was going for a solution that would require minimal (or no) change in the software. A totally revamped, proactive creation process would be great, but as I'm not a developer I feel reluctant to propose stuff that might not be feasable to impliment. --W.marsh 16:45, 31 January 2006 (UTC)[reply]
Since I'm not a developer I find it easy to propose new features... ;-) But you're absolutely right, of course, your feature has the huge advantage that it would be very simple to put in. I have a tendency to look waaaay down the road... — Johan the Ghost seance 19:06, 31 January 2006 (UTC)[reply]
Template:New page did this. Unfortunately, someone changed it to place its articles in Category:Stubs, so it got jumped on and deleted at TFD. —Cryptic (talk) 16:54, 31 January 2006 (UTC)[reply]
I think this template makes a little more sense (some of the objections raised in the TfD have merit). It does more suggesting than "forcing", and the 2 conventions it does force (a standard intro, and listing references) are not really going to hurt any new article. The key idea is to just make blatantly obvious some suggestions to help new users avoid common problems. I mean, many new users do these things... I think just reacting to common mistakes endlessly is a waste of our time. Let's be proactive. Anyway, if adding a generic stub is going to ruffle the feathers of stub sorters I guess it can be forgone... but honestly these articles do need stub sorting too usually. --W.marsh 17:26, 31 January 2006 (UTC)[reply]
I think it's feasible to improve what what one sees at (for example) User:Kmf164/newpage and [http://en.wikipedia.org/w/index.php?title=User:Kmf164/newpage&action=edit http://en.wikipedia.org/w/index.php?title=User:Kmf164/newpage&action=edit, where one of the bullet points is "If you're a newcomer, please first read the introduction, tutorial, and your first article to ensure the quality of your new article." But the way the bullet point is shown on the page isn't prominent enough and easily overlooked. This text is at MediaWiki:Noarticletext and MediaWiki:Newarticletext. -Kmf164 (talk | contribs) 17:30, 31 January 2006 (UTC)[reply]
I hate to sound overly cynical, but there are a lot of users who I don't think will ever click a link to read guidelines before creating a page. This is a natural sort of thing webmasters should expect on the internet, and must design sites in anticipation of it. If the text is right there when they're trying to create the new article, I think they're much more likely to read it. --W.marsh 17:35, 31 January 2006 (UTC)[reply]
I hate to sound even more cynical, but I'd be surprised if many editors have ever read even that text. :-) Deco 18:02, 31 January 2006 (UTC)[reply]
I think you're right about people reading the linked guidelines. Let's pull the key points out of the introduction, tutorial, and your first article and put them directly on the edit page (either in and/or above the edit box - perhaps more feasible?). Some things to also consider warnings against: vanity pages, advertising, advocacy/POV, ... and Wikipedia:List of bad article ideas. -Kmf164 (talk | contribs) 18:10, 31 January 2006 (UTC)[reply]
I do think most new users are going to read text if it's in the very editbox they're about to use. Yeah, the final text (if this ever goes anywhere) should be improved beyond my draft to be as useful as possible to new users, but brevity and clarity shouldn't be sacrificed. I'm hoping to get some consensus going before changing anything... I know a lot of people would have a kneejerk reaction against something they assume is trying to curtail creating new articles. This is about helping people make better articles, not stopping them from making articles. --W.marsh 18:35, 31 January 2006 (UTC)[reply]
Why not lose the "hide-comment" mark-up, so that the boilerplate prompts appear in the new article? There's nothing will get the attention of a new creator more than a line saying "You can replace this text with your own introductory passage" across the top of their beautiful new page. And while deleting it, they'll read it. JackyR 18:45, 31 January 2006 (UTC)[reply]
I think it needs to be commented out... otherwise we'd end up with tons of articles where the phrases weren't removed, and looked quite junky. --W.marsh 18:50, 31 January 2006 (UTC)[reply]

WikiNews has a sophisticated article creation utility, that can do everything mentioned here. Kevin Baastalk 22:47, 31 January 2006 (UTC)[reply]

That feature is available here. Try following this link. Links like this can be generated by submitting inputboxes with the preload attribute set. Superm401 - Talk 06:12, 1 February 2006 (UTC)[reply]

It'd be nice if the "show preview" included a big warning at the start of the page about any links to disambig pages in the text. I suspect they creep in because people don't realize there's multiple usages, and highlighting would go a long way to eliminating them (for new work at least). — Kevin Ryde 22:49, 31 January 2006 (UTC)[reply]

The system doesn't know what is and is not a dab page. All it checks in links is if it exists, and what its length is (for proper color coding). How can it know if it's a dab page? Search if it contains one of the many disambig templates? I just think this would increase processor usage, but I'm no dev. (Or do you mean just a casual warning, not a link-by-link check?) --Golbez 22:55, 31 January 2006 (UTC)[reply]
I was thinking the system could check if a target is in Category:Disambiguation (or subcategory I suppose). More work for the cpu, but it's only on previewing, not normal browsing. — Kevin Ryde 23:54, 31 January 2006 (UTC)[reply]
Needless to say, such a feature if it were added would be highly specific to Wikipedia. Many other existing and potential Mediawiki projects have no concept of disambiguation. I think instead we should have some more generic scripting mechanism that we can use to inject our own content such as link colours and headers based on the contents of linked pages. Deco 08:12, 1 February 2006 (UTC)[reply]
If you set your stub display to an appropriate level, you'll see most disambiguation pages as stubs. Some actually will be stubs, but you can often tell which ones they are. -- Kjkolb 08:32, 1 February 2006 (UTC)[reply]
I sometimes see dab pages this way, but some dab pages have gotten longer than some complete articles. Deco 11:10, 2 February 2006 (UTC)[reply]
I've noticed that, too. I also watch out for words that are very likely to be disambiguation pages and ignore words that are almost certainly stubs. I didn't say my system was perfect. ;-) Kjkolb 11:37, 2 February 2006 (UTC)[reply]

Bayesian Classifier for contributions

Bayesian classification works very effectively for spam. A Bayesian classifier for contributions to Wikipedia could make it easier to more quickly detect edits which are highly likely to be reverted.

How would it work? Each revert would be automatically submitted to the Bayesian filter in order to train the filter to recognise edits that are likely to be reverted (for WHATEVER reason). New edits would be passed through the filter and classified according to their reversion probability. This could be used to compile a `revertability index' for each edit.

How could it be used? In the first instance the Bayesian filter's opinion could be indicated on the recent changes page to help flag edits in need of particular scrutiny. In the long term, if the filter proved as accurate as one might hope, then a more aggressive approach might be taken, whereby edits with a high revertability index would not be automatically implemented but would pass through a moderation process of some kind.

Note: Such an index would not pass any value judgement on the quality of an edit. It would simply judge its probability of being reverted. I would expect it to accurately flag all edits on both sides of an edit war, for example. This would have the effect of automatically calling attention to the dispute and possibly automatically invoking moderation procedures, not a bad thing in my opinion.

That's a really good idea. Difficult to implement, but I'd really like to see how it plays out. I can imagine a Recent Changes page with each edit colour coded. Likely vandalism would have a red background, while suspicious stuff would only have a yellow background, with a gradiant in-between. I suggest we do an offline trial of this with a training and test set. Deco 04:59, 2 February 2006 (UTC)[reply]
It is a very good idea. Another way of listing the frequently-reverted articles would be simply to do a database dump every couple of weeks, and list Wikipedia: Top 100 articles by number of reverts or similar. Grutness...wha? 05:18, 2 February 2006 (UTC)[reply]
The top 100 articles that Grutness refers to is pretty close to WP:MVP.-gadfium 07:40, 2 February 2006 (UTC)[reply]
A fairly subtle analyzer would be needed to provide useful input to any such clasifier. It would need to recognize the toopic, for example, and changes such as the addition of tags, presence or absence of references, adn the like. Also even if absolutely accurate, a high change of reversion could mean vandalism, or anb absolutely accurate commetn likely to be targeted by a PoV pusher. It would be interesting, but it wouldn't be simple to program. It would ahve soem server cost. Also to be at all sueful it would need to recognize non-rollback reverts, includign revrts to a version other than the just previous one. DES (talk) 15:58, 2 February 2006 (UTC)[reply]
You're right that ongoing training of the filter is a sticking point. However, if we give all registered users the rollback function (which is sort of like a current proposal), then rollbacks would be easy to identify and train on. Meanwhile we can guess from the edit summary pretty well. Deco 22:32, 2 February 2006 (UTC)[reply]
This idea is a good one. You could probably count edit summaries containg terms like "rv", "revert", etc. as reverts as well; there might be a few false positives, but they'd definitely be too small to seriously affect the algorithms. This seems very workable; the bot could just crawl through the recent changes RSS feed (or whatever the vandalism-catching bots use) and find the reverts, while at the same time using its past experience to determine which of the new edits are liable to be reverted. This information could then be fed to an IRC channel along the lines of the ones currently in use for the vandal-catching bots. Johnleemk | Talk 16:58, 3 February 2006 (UTC)[reply]
You want to talk to User:Gmaxwell, who has apparently done this a while ago. Lupin|talk|popups 14:52, 4 February 2006 (UTC)[reply]

WikiQuestion

The encyclopedic part of wikipedia is great, but has a minor problem. Making it bigger also means making it harder to use specially if the "topic" is a combination of different things - like science. In science it's not this or that but mostly all together.

So what I'd suggest for you to consider is making a "wikiQuestion" where topics and search are question based and not concept based. For example a user needs answering a question "WHY the Sun is round?", "HOW the fridge works?" or "WHO..", "WHEN", etc. where the page would be indexed on words in a question. The wikiQuestion would allow posting questions and wiki editing. Every wiki page would be linked by keywords to wikipedia and all other similar pages.

Why is this good.

  • First of all question needs an answer and if question is a combination of sciences, then the answer must be the same.
  • Making search would be easier, since the keywords are always based on the question and not on the contents, which means more accurate results.
  • Allowing users to ask questions would enable contributors to redefine them to be "as exact as possible" and also answer those that are most likely to be asked and link them to wikipedia.

For a building process this would imply, that you add text to the article, that is not on the page itself. For a question on "why the sun is round" I could borrow data from wiki "Add text from this address, this paragraph" and combine data to answer the question.

The question itself offers complete answer in a form of an article.

Wikipedia's reference desk exists to answer such questions. Superm401 - Talk 04:41, 3 February 2006 (UTC)[reply]

Full semi-protection of Wikipedia

Fellow Wikipedians,

I would like to propose that the editing of Wikipedia be permanently restricted only to registered users.

I have been monitoring countless articles here on WP for most of the past year. Increasingly, I am seeing that anonymous, unregistered users are taking advantage of WP's unprotected state to cause random acts of vandalism. The Green Day article is a prime example - every other "edit" is a reversion of vendalism to the article; there are many others.

It has been argued that the unprotected status of WP allows "minor" users who might otherwise not register to make little factual and biographical corrections. This is an outright fallacy. Anyone who cares about maintaining the content of Wikipedia would surely take the 20 to 30 seconds it takes to register a free account, even for a handful of articles. More and more, the unregistered, anonymous "contributors" add nothing but vandalism, while registered users are taking increasingly large scraps out of their time to revert the damage. This is time that could be better spent helping better this website.

-- CJ Marsicano 02:08, 3 February 2006 (UTC)[reply]

See Wikipedia:Village_pump_(perennial_proposals)#Abolish_anonymous_users. In my experience, somewhere between 10 and 20% of anon edits are vandalism or newbie tests. Try a little experiment for yourself: go to Recent changes by anons to articles, and look at the most recent ten edits. How many were positive, how many negative, and how many were you unable to tell because they were outside your field of expertise (e.g. changing the ranking of a music album you've never heard of)?-gadfium 04:16, 3 February 2006 (UTC)[reply]
I just did that test myself. Nine of the ten edits were positive. The other one I couldn't tell: in John F. Kennedy International Airport an anon changed the number of gates in terminal 6 from 13 to 14. I could probably research it, but even the Kennedy airport website may not be up to date. I'll leave it and some New Yorker who goes through the airport a couple of times a week will fix it if it needs to be fixed. I feel my experience this time was more positive than usual; usually I come across one or two negative edits in such a test.-gadfium 04:24, 3 February 2006 (UTC)[reply]
I checked the contributions of the anon who made the JFK airport edit. They've made lots of similar edits to airports, and have no warnings on their talk page. I can feel fairly confident they know their stuff.-gadfium 05:46, 3 February 2006 (UTC)[reply]
Interesting test. I found one obvious vandal edit (to the day's FA), eight obviously good edits and one where I was unable to be sure, about Dramatic Hearts [2]; the phrasing was poor but not necessarily obvious silliness. That makes 8/9 good edits. It'd be a might shame to have lost them. -Splashtalk 04:30, 3 February 2006 (UTC)[reply]
I just did it and found just 3 good edits (and lots of vandalism, unknowns and neutrals). Of course the results of any of our tests are not significant. Hmmm, how many uncaught vandals does it take to offset a few good edits? Is one bad edit sitting for several ours worth 5 minior improvements? I'm not saying that blocking anons is the best way to solve this though...Why do people oppose delayed editing? I'll never know. BrokenSegue 04:36, 3 February 2006 (UTC)[reply]
Wasn't the first time you corrected an article and saw it actually appear on screen a "surely I can't...that comma...maybe I can...wow. I can! I am Power." moment? I do believe it may have been: [3]. -Splashtalk 04:38, 3 February 2006 (UTC)[reply]
Why couldn't we make exceptions for certain pages (like the sandbox or when making new pages)? I'm sure there are other options we could use as well (an option to display the newest revision even if it hasn't elapsed its time or a version designed only for readers). If the only reason delayed editing isn't inplace is to serve as advertising (or to rope people in) then perhaps we can do without it. I don't want to have to be in a rush to review edits. Of course coding it would be hard. BrokenSegue 04:47, 3 February 2006 (UTC)[reply]
Actually, just such a thing is being coded at present — articles puttable into a 'validated' state. Apparently, this was in addition to the article rating system. In December, Jimbo mooted its appearance in January. -Splashtalk 04:51, 3 February 2006 (UTC)[reply]
A perennial proposal. We're not doing it. The primary reason is not that anons make substantial important contributions to the Wikipedia, but that this is how new contributors first get drawn in and involved - we are successful only because we set the bar low, inviting anyone to participate with minimal effort. Moreover, it's uncertain right now what percentage of vandals would create throwaway accounts to perform the same vandalism they perform now with anonymous IPs. Deco 06:09, 3 February 2006 (UTC)[reply]


Of course, not long ago, if somebody suggested blocking new article creation to anons, it was rejected as a "perennially rejected" suggestion. Ultimately, despite great opposition, anon editing will be ended entirely. There will probably also be some more limits imposed on new registered users. This is all currently happening piece-by-piece. The use of semi-protection on articles will simply be used on ever-more articles, for ever longer. It seems better to plan how it will happen, then pretend its not going to happen. --Rob 13:11, 3 February 2006 (UTC)[reply]

If that happens, you can expect a fork (barring a sudden and drastic change in Wikipedian culture). Allowing anyone to edit is a basic part of the wiki philosophy. Johnleemk | Talk 16:55, 3 February 2006 (UTC)[reply]
I'm hoping that Jimbo realises that pushing for even more limitations on anonymous users when the ones already instituted were highly unpopular, lacked consensus, and have shown no clear evidence of effectiveness could threaten the community. Deco 20:46, 3 February 2006 (UTC)[reply]
  • Personally I'd like to see the open edit policy remain until the wikipedia is pretty well populated. At that point, when the majority of the work is actually spent in fine tuning the articles, maybe there will be more of a need for some sort of limitation on edits. *shrug* — RJH 21:36, 3 February 2006 (UTC)[reply]
    • You assume the Closed Wikipedia Hypothesis (that there will come a point where we can no longer significantly grow in breadth). Not all people believe this. Also, most changes made by anons are fine tuning. Deco 21:40, 3 February 2006 (UTC)[reply]
  • Allowing anyone to edit is not incompatible with banning anons — unless you're assuming that there is a certain class of human being that is permanently "anon". Requiring people to give a username, password and email (with email verification) just one time is not a big deal by any normal Internet standard. And regardless of the ratio of "good:bad" anon edits, the fact is that there is tremendous vandalism by anons (see some actual statistics), and blocking doesn't work at present because an IP address is not a person. A huge amount of effort is expended by people fighting vandalism (see today's featured article's history page, on any day). Wouldn't that energy be better spent on improving Wikipedia? — Johan the Ghost seance 11:11, 4 February 2006 (UTC)[reply]

Standardization of Featured content interface

I just finished converting all featured article-related pages to use a new interface (see wikipedia:featured articles and related pages). It's gotten pretty good feedback so far -- I want to now convert the remaining featured content pages -- wikipedia:Featured pictures, wikipedia:Featured lists, and wikipedia:Featured portals to use the same interface. Raul654 09:29, 3 February 2006 (UTC)[reply]

Seems like a good idea. The only complication that I can forsee is that some of the more useful pages on Featured Pictures are the ones that show thumbnails of the pictures themselves. It should still be possible to conform the formatting, but there has been some previous discussion on changing the layout at Wikipedia_talk:Featured_pictures_visible. That was somewhat inconclusive, but we probably do need to break the page up into a collection of pages in order to reduce loading times. -- Solipsist 12:14, 3 February 2006 (UTC)[reply]
Good idea. I've started with WP:FLC and WP:FL. A couple of questions
  1. You don't seem to have a place for the shortcut in your design. I think top-right of the top-right pane is probably the best place - see WP:FARC.
  2. I think it makes sense for the page rubric (instructions/how this pagew works/nominating/etc) to be included in a double-width pane below the top two - again, see WP:FARC. -- ALoan (Talk) 13:45, 3 February 2006 (UTC)[reply]
Excellent ideas, Aloan. I've implimented them (if I missed any, go ahead and fix it). Raul654 17:29, 3 February 2006 (UTC)[reply]

All done! I think it came out quite nicely. Raul654 20:04, 3 February 2006 (UTC)[reply]

Ability to physically edit own top edition

If a user edits a page, and the last edit was made by him too, he should have the option (within a certain time period, say 15 minutes) to literally edit *that* item of the history, instead of creating a edition, and a new entry in history.

This would save lots of hard disk space, I imagine, since editions with bad spelling mistakes don't have to be saved to data. Infinity0 talk 13:29, 3 February 2006 (UTC)[reply]

As far as I know, the software compresses older revisions in such a way this isn't a problem (that caused the old, long fixed, "block compression bug"). --cesarb 21:22, 3 February 2006 (UTC)[reply]

Do you have a link to the details please? I'm quite interested. Infinity0 talk 21:24, 3 February 2006 (UTC)[reply]

Taking a look at the code, I found it's done at HistoryBlob.php, called (in a very indirect way) by Revision.php. If I understood the code correctly, if a revision's text (stored on the text table [4] — more than one revision can point to the same text) has the object flag, its contents are not (possibly gzipped) text as usual, but it's instead a serialized object. This serialized object, in turn, has both the identifier of another row on the text table and a hash which identifies the revision within it. On this second row is another serialized object, which has a gzipped serialized array of revisions, keyed by the hash. I lost track of the number of indirection layers. The compression code seems to be at compressOld.inc. --cesarb 22:34, 3 February 2006 (UTC)[reply]

Argh... :S What does the text table contain? The text of a few key revisions? And the serialised object contains keys indicating which lines to pick out of those revisions?

The page table contains data about the whole page; the revision table contains data about a single revision; and the text table contains the text of a single revision. The text table has a flags field; if it contains the object flag, it contains, instead of the text, a serialized object, which is unmarshalled and called to retrieve the actual text. The magic trick seems to be that the serialized object does not have the text within it; instead, it retrieves another serialized object from another row on the text table, which has within it the text for several revisions, compressed together (like solid compression). Which of these revisions to pick is selected by a key contained within the first serialized object. --cesarb 22:56, 3 February 2006 (UTC)[reply]

Oh right. Do you mean that all the different text from all revisions is stored in the text table, and the object picks out the relevant parts from that scramble of text? Infinity0 talk 23:00, 3 February 2006 (UTC)[reply]

Why aren't Discussion pages add-only?

I'm finding it hard to phrase my idea, since so many of the reasons are similar to those who wish to permanently protect actual articles, but I'll give it a shot. Is there any reason for a discussion on an article's talk page to allow users to delete/modify the comments of others? Not only is it next to impossible to catch on high traffic pages, but I can see no benefit to simply changing it so that you can only append to to page.

Take the mohammed cartoons page. So much energy is being wasted reverting vandals on the *talk* page alone. And making this change has absolutely no drawbacks as far as I can tell

The wiki philosophy allows anyone to edit anything. Vandals are a pain in the ass, but protection is typically a last resort, since vandalism is easily reverted. Some policies like NPA also require allowing editors to edit others' comments (i.e. to remove personal attacks). Johnleemk | Talk 16:52, 3 February 2006 (UTC)[reply]
There are some advantages to it, albeit they are mostly introduced by the lack of discussion thread features. Fixing mixformatted threads, adding section titles to stray comments, and blanking old or misplaced discussions, etc. are all important aspects of maintaining talk pages, which would be impossible if the pages were locked somehow. --W.marsh 17:06, 3 February 2006 (UTC)[reply]
We have strong conventions against editing of other's comments however. I would argue that a message board format, where a person can edit their own posts, would be a much better way of organizing talk pages. Wiki really just isn't suitable for this. Deco 20:50, 3 February 2006 (UTC)[reply]
Honestly I don't disagree with you. Wiki is brilliant for creating articles, not so much so much so for having discussions. It certainly works... but it is often a lot of needless hassle keeping things straight. I do not believe it would be easy to effect a change, though. --W.marsh 20:53, 3 February 2006 (UTC)[reply]
Wikipedia:Village pump (perennial proposals)#Discussion Pages - Bring Modern Interface. --cesarb 21:20, 3 February 2006 (UTC)[reply]

I'd like to announce the opening of the Featured Music Project, an attempt to encourage and facilitate successful featured article candidacies and peer reviews for articles on musicians and bands. You can help by evaluating articles, or by working on the articles that are already close to being ready for FAC. Tuf-Kat 19:30, 3 February 2006 (UTC)[reply]

Era Proposal

Hello, everyone. I am in support of the anno Domini terminology personally, but I have a different proposal that may just satisfy everyone who reads Wikipedia. This proposal would remove the edit wars, as well as all problems of "confusion" and the extreme likeness of BCE to CE. Also, it would stop confusing pages like this one from referring to years like 164 BC/BCE. I got this idea from the customs of the History Channel. Here is the proposal:


Years from 1 forward will be abbreviated with CE (Common Era; can be interpreted as Christian Era).

This ensures that nobody is acknowledging that Jesus Christ is God, and it also leaves Christians with the Christian era option.

Years 1 BC and previous will be abbreviated with BC (Before Christ; can be interpreted as Before Current).

Although this method would acknowledge Jesus (Christ) directly, noting this era as Before the Common Era simply masks the reasoning behind the Gregorian/Julian calendars. Unlike using AD, using BC does not acknowledge Christ as a god, simply as a historical figure, which most scientists agree that he is. It is basically the same as saying the days of the week, such as Wednesday, because it only acknowledges the historical meaning behind the word, not that the historical meaning is a god. It can also be difficult to speak BCE in dialog, and also, it has three letters. When we drop the "E" and use just BC, it has no grammatical similarities to CE, meaning the terms cannot be confused with one another easily. (One of the reasons of support given for the use of AD and BC on the common era page). Finally, using both BC and CE in a sentence also roll off the tongue easily (e.g - It was ongoing from 2 BC to 5 CE).
The best part about this proposal is that it will not be required that we change the current Wikipedia policy. The current Wikipedia years pages use BC, but they use neither CE nor AD for years after 1. Also, like the History Channel does, we can use AD in replacement of CE for exclusively Christian pages, and we can use BCE rather than BC for exclusively non-Christian religious pages. However for religion-neutral pages, meaning all pages other than those associated with religion, will use the proposal above. How does this sound? Darwiner111 07:15, 4 February 2006 (UTC).[reply]

Discussion

Request for rollback privileges poll closing soon

The requests for rollback privileges poll, a poll to gauge consensus on whether good contributors who are not admins should be given the rollback privilege, is closing at 00:00 UTC on Tuesday, 7 February 2006. If you haven't weighed in, please do so! Talrias (t | e | c) 11:14, 4 February 2006 (UTC)[reply]

January? Johnleemk | Talk 14:47, 4 February 2006 (UTC)[reply]
Don't tell me you didn't pack your time travelling device this morning! Talrias (t | e | c) 14:49, 4 February 2006 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=38155394"