Feature requests/Really ambitious and fanciful feature requests

Really ambitious and fanciful feature requests

• For famous writers: include pages of the books they have written, taken from the Project Gutenburg Library. PG is a library of books that have fallen into the public domain. Include them as links to the specific .txt files on PG's servers, so we don't have to deal with the endless defacement of Romeo and Juliet. Imagine being able to look up Kipling, read a description of his life, and then read all of his works.
  • This can't be done automatically in any easy way. It's something we're doing by hand. See [public domain resources]?.

• Make the category an article belongs to a property of the article. So one can look for all Mathematics articles, etc. This can already be done to some extent: you can always create a category page and add the article to it; but if someone forgets to do this the article will be missed. An automatically generated page could exist for each category, listing what articles belong to it; and also an automatically generated page for articles that do not belong to any category, so they can be assigned to one. Also:
• At the top of each topic page, I would like to see a link to the parent topic. chuckr30
  • These aren't just software feature requests, because it's not a programming task to determine what "category an article belongs to." (What does that mean?) Please see this column. Re: "This can already be done to some extent: you can always create a category page and add the article to it; but if someone forgets to do this the article will be missed." I reply: So? So the page will be (temporarily) imperfect. Better that than a totally controversial hard-wired category scheme of limited value. The content is the category scheme. --LMS

• I was just thinking about e-mail interface to Wikipedia. What for, you might ask. Sometimes it is for some people hard to get onto the Wikipedia server. I also think it would booster authors' productivity. Off the top of my head I can think of three commands that can be placed in subject line of an e-mail :
  • POST
  • GET - raw text of the page
  • RECEIVE - formatted text of the page
• of course there should also be 'an article a day' service. POSTing should be reserved to active memebers of this mailing list. There should be some way to safeguarde against accidental overwriting of existing pages. When POSTing raw text in body before '-- ', and author's id from e-mail before '@'.

• I would like a way for the author of an article to "lock" the article. If someone wanted to add something to it, they would email the changes to the author. If the author approves, the author can post the new article. I think you will see tons of poor quality articles here eventually, because some 12-year old thinks it's cool or funny to deface articles. I think it would be wise to be able to lock the articles. chuckr30
  • There is no such thing as "the author of an article" on Wikipedia, unless it's just an accident that one person has happened to work on an article so far. So this is not going to happen anytime soon. It is totally anti-wiki, for one thing. Eventually, some such solution might be necessary to make Wikipedia fully scaleable--but I doubt it. Right now it is clearly unnecessary: people are our protection against vandals. --LMS
  • I might worry about someone creating a script that would automatically deface pages. As a long term project, consider limiting (throttling) the rate of accepted changes from any one ip address -- [Pat Spinler]?
    • I don't like this idea, simply because I would have been throttled myself several times already. Unless we make the limit to something not humanly possible, or at least extremely unlikely--say, 1 or 2 changes each minute for several minutes straight. And actually I've submitted more changes than that on many occasions, especially when adding CIA factbook info but also when adding country codes to the */Communications pages. Also, I expect Simon J Kissane's contributions would have been curbed a few times as well. --Koyaanis Qatsi
    • I don't quite like this idea either, but it made me think of another thing: It would be nice with the possibility to roll back the latest change from the changes page. If someone defaces a page, I can just click something to get the previous version back, instead of having to edit it by hand. --Pinkunicorn
    • You can do that, with the View other revisions page...you just view the previous revision, click on the Edit this revision link at the bottom, then save it. It saves over later revisions. --The Cunctator

• The best way is to introduce a voting+visits system (like Google's PageRank) to make sure vox populi automatically kills unwanted changes. Let's say I want to navigate at 90% assurance. Let all poorly voted pages and corrections be invisible. Then I can change the assurance level and see all stuff - including kid's graffiti, Piotr Wozniak
  • Ick. I can't imagine any better way to ensure total mediocrity. Who cares what the masses think? I want to know what the one or two real experts who cared enough about the subject to slug it out on the /Talk? pages finally settled on. --LDC

• Ability to have multiple revision branches of an article, ala CVS. That way if there is a difference of opinion on how an article should look, different authors can each work on their own branch without constantly overwriting each others work, and then we can choose which one is better to become the main article, or to integrate them.

It sounds to me as if this would introduce very much complexity for a rather small gain. I think it's better to create Main/MyView? and Main/YourView? and have a short introduction to the different views on the main page. Even better would be to have both views presented on the main page (perhaps in different sections), but that can always be arranged once they are "finished"). --Pinkunicorn

• Giving to the user some 'pagehits per time' information would make Wikipedia even more dynamic. It's motivating for editors when they can see that there's a lot of interest in their work. --[Wolfgang Moecklin]?

• This partially related to that request for email-submission interface above: Open up the interface to the database in order to allow different front-ends. For example, if I'd want to use an interface with support for off-line working I'd have a data base front-end for that. On the other hand, if I'd want a fancy GUI I'd just write a new front-end. This naturally requires that the database interface is stable (and not continuously evolving). So, what I'd basically want is to open up the open project:) --Tbackstr
  • You might just get that in my Wikipedia PHP script. I already thought of a TCL/TK program as a frontend to reduce the server load that is coming from page rendering. Of course, you can get an article source automatically even today by scanning the edit page of the article. I am working on something like that to copy wikipedia to MySQL format.--Magnus Manske

• I like Everything2's "soft link" concept: the server monitors the pages from which visitors reach a given article, and the most common such pages are listed at the bottom of the article, to provide context. --AxelBoldt
  • Though I'm not familar with Everything2, it sounds like a good idea. There should be a way to see what pages link to a particular page easily. - Eean
• Rendering of mathematical formulas and chemical diagrams on-the-fly using TeX, similar to [Mathwiki]. The Mathwiki code is written in perl and I hear that it is not in very good shape and probably would have to be reimplemented. --AxelBoldt
• Have an wiki-code to insert the JavaScript for the "tool-tips"-like thing that Nupedia has. Then have a way to turn them off, like in Nupedia. -- Eean
• Add a java applet that users can specifically request when editing a page that will allow the user to create mathematical equations that the applet will parse in to MathML?.

• Have the "View other revisions" link allow access to future revisions as well as past ones. This would allow wikipedians to copy text that hasn't been written yet into the current revision, taking a lot of effort out of editing. Of course, there would have to be safeguards to make sure that no paradoxes resulted; some kind of edit lock that only allows a page to be saved when it matches its next predestined revision, perhaps.