User:Gwern/Suggestions

This is a list of suggestions for changes in Wikipedia I'd like to see eventually.

Bad ideas

 * The first letter of page names being case insensitive. It may make the search code simpler, but dammit, it makes the lives of us editors much harder!
 * Images cannot be moved. I don't think I need to make a case for this one. The editors over on Commons especially need this one. It's an old and much requested "enhancement".

Page rating/voting

 * Our warning templates, like unreferenced, tone, and their brethren, work fairly well at what they do, but they are rather ad hoc and somewhat arbitrarily applied. It'd be much nicer to have some sort of super-easy rating system whereby readers too afraid to post to Talk pages or engage in any editing at all could register concerns. It may seem silly to us editors, but a lot of people just won't edit Talk pages - are they really allowed to? How do they? What's a Talk page? Won't I get in trouble? There must be some security problem here, the page can be edited by anyone! and so on. On the other hand, little radio box polls are understood by everyone and obviously solicit feedback. And of course, it could have side benefits; suppose each vote came with an optional edit-summary size box, where you could add a comment? This would drastically lower the cost of getting feedback, allowing people who would never dream of adding to these weird and obscure "discussion" or "talk" pages to give their feedback and quickly and easily point out little things or problems. Such easy feedback is very much in the whole spirit of a wiki - and fears of vandalism might be a little much. After all, vandals can preserve vandalism quite effectively through edit summaries, but mercifully there's been little of that (mercifully since it does take some time for one of the few administrators to delete that particular revision).


 * So some sort of voting system would be good; obviously it shouldn't actually do anything besides register votes and concerns (we don't want silly scenarios like to allowing people to game the system by hitting the "hoax" button 50000 times using programs and get the article automatically deleted).

Redirects

 * A bot which would make redirects. An obvious example is for capitalizations. For example, R. A. Lafferty has a number of possible capitalizations - even if the user gets the spelling perfectly right, they could easily come up with "R. A. lafferty", "R. a. lafferty", "r. a. lafferty", "r. a. Lafferty", "r. A. Lafferty", "r. a. lafferty", or "R. a. Lafferty". (I think I listed them all!) Anyway, even if all the possible variants don't convince you of the need for this, I am: I've seen far too many red links which were caused by the article having the second capitalized or not - but no corresponding redirect from the other! It is a diligent editor indeed who will foresee this problem and make an appropriate redirect. One may object,"But what about cases in which there is a disambiguation page at one capitalization, and one or more regular articles at the others?" Well, what of them? Is it so hard to have the bot check all capitalizations, and see what articles are there? If only one article of any sort exists, then redirect all the capitalizations to that article. If there are multiple articles, then look for a disambiguation article. If there is one, then redirect all to it - ambiguous links can always be sorted out later by a disambiguation bot or something. If there are multiple regular articles, then either raise an error and ask for the user to resolve things (I suspect most such instances will turn out to be cases in which duplicate articles need to be merged); or just skip that set of capitalizations. On a wiki of millions of articles, it's OK for a bot to simply say it cannot handle some cases.

Better citing and archives

 * We should somehow preserve external links; when one references another internal link, one doesn't need to worry too much about "link rot" or the infamous "404 error", since page moves are accompanied by redirects, page history is usually preserved somewhere, and even deletions (which are fairly rare for serious articles like one is presumably linking to) are recorded. So no real referencing solution is needed for articles - if one must, one can link to a particular revision, but it's basically a solved problem.


 * But what about external links? They can't simply be mirrored, since that raises major fair use issues, and would expose Wikipedia to all sorts of spam problems; and Wikipedia has not the infrastructure. But the Internet Archive has been doing that for a long time, they have the legal immunities needed, and they understand how to do it. But the Internet Archive is not perfect. Archiving lags by many months, and they often miss pages. The limits of the IA's shotgun approach are many and obvious, which is why we have nice services like WebCite. Even better, WebCite in particular seems to allow on-demand archiving, so we could cite links as they came in.


 * An expensive solution in bandwidth or coding, perhaps, but I believe that this or something akin to it is the Right Thing.


 * The foregoing is just the minimal solution, I said. An even better solution would be that, and also a bot or some sort of automatic routine to go around annotating external links with a link to the cached Internet Archive or WebCite copy (ideally pointing to the copy closest in date to when the external link was added to Wikipedia, with maybe a redundant link in a comment).


 * Real Revision control. Wikipedia's single-history system is not too bad, but a little experience with advanced version control systems like darcs have made it clear to me that the present situation is not ideal. This is particularly apparent on pages with edit warring, or complex pages in general: imagine being able to search for a specified string to find the first or last version it appeared in; imagine being able to easily branch and merge entries - especially useful for drafts, major overhauls, or pretty much all Wikipedia 1.0 proposals; imagine being able to check in partial changes but passing over others to have more sensible diffs instead of distorting one's work flow so that the referencing goes in one edit, the formatting in another, the spellchecking in a third, and the controversial edits in yet a fourth (so a revert doesn't wipe out the undisputed edits).

New system of E2 Links

 * Everything2-style links. Everything2 sucks in many ways, both technical and social, and lacks many things; it's a dying community and so on and so forth. But I visited it a while ago at the suggestion of another editor, and I discovered one truly awesome innovation: soft links. In even only a little browsing, I've found them invaluable for finding articles which were related and interesting to the current on, but nevertheless probably shouldn't be linked directly within the article; categories don't fully substitute, and aren't supposed to anyway. Soft links are useful: You can think of them as analogous to the articles on see in the "What links here?" special page, but in reverse, and better as the relevant links aren't always mentioned strongly enough or included in the See Also or whatever (since an exact inverse would only show the links in the article, while softlinks would encompass those, but also include the pages users search for, or visit directly after viewing the article).
 * There was a bug report for it on Wikipedia's Bugzilla here, but Rob Church rejected it out of hand. :(