User:Tim Starling/Feature poll

From Wikipedia, the free encyclopedia

You have new messages (last change).

I'm interested to know what kinds of programming tasks editors feel are most important. So I've grouped feature requests into a few major categories. Please vote on which category you think developers should be working on. Add your votes with ~~~.

If you want to comment on categories rather than vote (or in addition to voting), you can do that underneath the votes.

Vote on one category only.

Contents

[edit] Quality (24)

Screening for vandalism, with better watchlists, more configurable contributions pages and RC, etc. Features for organised patrol, marking edits as checked.

  • Add your vote in a bullet point below
  1. ALargeElk | Talk 09:05, 5 Jul 2004 (UTC)
  2. well, if we only get one, this has got to be it. get quality right and it fixes most other issues. Erich 09:06, 5 Jul 2004 (UTC)
  3. Yes, this is by far the most important. →Raul654 09:06, Jul 5, 2004 (UTC)
  4. Yes, sounds good, as long as (a) it doesn't slow down the database, and (b) it doesn't place any obstacles in the path of contributors. -- Heron 10:03, 5 Jul 2004 (UTC)
  5. Agree with everyone. This would be terribly nice to have. blankfaze | •• | •• 10:42, 5 Jul 2004 (UTC)
  6. Yes, keeping track of changes is the most important thing we do -- I find it hard enough to keep up with my watchlist! -- Arwel 12:35, 5 Jul 2004 (UTC)
  7. Yes, edit checking would be useful. It should at least allow a short summary for the reason for accepting or rejecting the edit. Jrincayc 12:53, 5 Jul 2004 (UTC).
  8. Pcb21| Pete. Tim doesn't want details here but I would welcome brainstorming at User:Pcb21/Checked edits so we have good ideas to offer the developers should the time come.
  9. Agree. Edits should be marked as "checked", nothing more complicated. [[User:Meelar|Meelar (talk)]] 19:57, 5 Jul 2004 (UTC)
  10. Agree. I try to spend about half an hour a day on RC patrol, and I'm clicking like a mad thing during that time trying to keep up. Anything which allows me to see from the RC page that some other logged in user has verified an anonymous edit would be great. --gadfium 20:47, 5 Jul 2004 (UTC)
  11. I'm pretty tempted to vote for performance, but the truth is we could always add a couple of servers, but we can't cope with the increase in vandalisms, etc. Dori | Talk 01:10, Jul 6, 2004 (UTC)
  12. This “feature” should be considered a requirement. —Lady Lysiŋe Ikiŋsile | Talk 01:49, 2004 Jul 6 (UTC)
  13. Agree. A nice feature would be if the Special:Contributions page for a user had "diff" and "hist" links (like Special:Recentchanges) for each edit, rather than just "hist". —Stormie 04:03, Jul 6, 2004 (UTC)
  14. Elf | Talk. Hard choice between this & performance. These tools aren't necessarily as useful if performance sucks. But when performance is good, it's still laborious to detect & fix vandalism. Umm--I guess this isn't really a vote since I'm supposed to vote only once (for performance). But I really want these features, too.
  15. Yes, to all, but especially screening for vandalism. If we want to attract a greater readership as well as more contributors, it is absolutely necessary to make it a safe for all who add valuable and legitimate content. Dieter Simon 23:18, 6 Jul 2004 (UTC)
  16. I think quality is the most important feature, and searching a close second. Performance is good right now, it would be most important otherwise. Anything to help track quality would help a lot right now. --ssd 04:59, 7 Jul 2004 (UTC)
  17. Furthermore, some karma system where people could mark other users as okey or something like that, and those with sufficient votes would have a different color in RC, that would enable people to not waste so much time checking trusted users when they're looking for vandalism. Of course all edits should deserve a check but practically thats not going to happen. Meanwhile a checked box would be great, with some way of stopping people from having two accounts, vandalising on one and marking as checked on the other, could lead to false security. --Ævar Arnfjörð Bjarmason 02:55, 2004 Jul 12 (UTC)
  18. A simple checkmark so that others could note that they approved of the article or a change sounds reasonable. Stopping two accounts could be partly faked by checking IP addresses (if the IP address is too similar, say the first 24 bits are identical, then there's a larger likelihood it's the same person). Rules to help detect "likely problems" (using naive Bayesian, pages often vandelized in the past, adding exernal hypertext links, people who haven't committed as many accepted articles, etc.) to mark recent changes that are more likely to be vandalism could help too. Dwheeler 05:13, 2004 Jul 25 (UTC)
  19. Make alternative language version lists transitive automatically: currently, have to edit the page in every language version to manually copy those listed in other language versions. -- anonymous, 19:14, Jul 19 (CEST)
  20. Yes to all. mnemonic 04:12, 2004 Jul 23 (UTC)
  21. Yes to all. Better watchlists especially will help keep vandalism at bay. These features shouldn't take too long, then focus on performance. - Taxman 14:14, Jul 28, 2004 (UTC)
  22. Sounds good. Ability to add a user's contribution list to your watchlist would be handy. This would be one way to combat vandalism. DivisionByZero 20:30, Jul 31, 2004 (UTC)
  23. Yes. Watchlist... maybe. Node 21:12, 24 Aug 2004 (UTC)
  24. BrokenSegue 20:10, 21 Sep 2004 (UTC)

[edit] Performance (25)

Full text search, regularly updated special pages, response time, avoiding error messages in peak times, scalability. Working on performance keeps hardware costs down.

  • Add your vote in a bullet point below
  1. Deepak IMO, all other aspects are pretty good/acceptable. A slow website is a killer and will prevent widespread adoption by the public. OTOH, this is probably a hardware issue. Can programming help beyond a point?
  2. Jongo 12:52, 19 Jul 2004 (UTC)
  3. --Grouse 13:26, 8 Jul 2004 (UTC)
  4. Jay
  5. Angela. The other options are fairly pointless if people can't even use the site. This one has to be the priority.
  6. Elf | Talk. Poor performance is the biggest thing that has discouraged me from patrolling new pages & recent changes. Hence = more vandals getting away with it.
  7. Not sure this is really called "performance", but yes, we should make the software stop breaking as a top priority. anthony (see warning)
  8. I'd like a title only search...especially when searching in categories. I keep unchecking everything but category, and I do a search and it brings up all these non-category articles that don't even have my word in the title. I'm sure that hurts performance while not doing what I want. --ssd 04:54, 7 Jul 2004 (UTC)
  9. I waited to vote and consider this a bit. My immediate inclination was to go with the herd and vote for Quality, but IMO quality is more a matter of human effort. It would be nice to have better tools to help maintain quality, but it is all for nothing if the WP is so slow as to deter people from using it. I may be mistaken on this, but I do not think improving performance is simply a matter of throwing more hardware into the mix. I think that optimizing performance is very challenging work and possibly not as gratifying to developers as creating new user-interface features (which often have a sort of "gee-whiz" factor). And speaking personally, I know that I avoid doing things like check RC or new pages when things are running slowly. older≠wiser 15:15, 7 Jul 2004 (UTC)
  10. AaronSw
  11. Acegikmo1 18:54, 10 Jul 2004 (UTC) I don't know what full text search means, but any kind of search is useful, especially the one we have currently is very good. Google never helped me when searching for words within Wikipedia, maybe Google's indexing of W'pedia is poor. W'pedia doesn't have to rely on Google. Jay 15:10, 5 Jul 2004 (UTC)
  12. Etaoin 02:36, 11 Jul 2004 (UTC)
  13. Yes. The site is down too often for my liking, and it's often slow during busy times, to the point where editing anything is impossible. Decrypt3 00:44, Jul 12, 2004 (UTC)
  14. DocUK 21:29, Jul 14, 2004 (GMT) Wikipedia is awesome, but the only thing keeping it from surpassing any software alternative is the speed. Lower response times and increased search performance would be a definite improvement, and the highest priority.
  15. I agree with Angela; performance, scalability and stability must be the number one priority. What is the point of adding features etc. if no one can use the site (or using it is a pain in th...)? As a programmer myself, I see that PHP probably ain't the best choice. Have other languages been considered? Ie. rewriting MediaWiki (for Wikipedia) in Perl? Perl/mod_perl and Apache is quite a bit faster than PHP. I know, 'cause I've developed load-extensive applications in both these languages. Toreau 11:32, 20 Jul 2004 (UTC)
    • PHP being slower than Perl is news to me — equal, arguable, but slower? Odd. Anyhow, the others' comments here have convinced me. I can still remember waiting forever for my edits on VfD to happen, only to find out that there was an edit conflict. Johnleemk | Talk 13:14, 20 Jul 2004 (UTC)
      • I've only benchmarked applications in Perl and PHP running under mod_perl/mod_php (Apache). I'm not sure how "standalone" Perl and PHP are compared to each other. But that's not an issue, as a site like Wikipedia have to run under a "boosted environment". Most of the benchmarks floating around on the web seems to be done by person not familiar with either programming language (or how to properly configure mod_perl and Apache to get the most out of it). My own personal conclusion is that it's easy to create fast and small application with both languages, but it's a lot easier to scale with Perl. Toreau 17:06, 20 Jul 2004 (UTC)
  16. gracefool 03:55, 28 Jul 2004 (UTC)
  17. Paddu 18:19, 31 Jul 2004 (UTC)
  18. Patik 16:31, Aug 5, 2004 (UTC)
  19. KneeLess 06:38, 07 Aug 2004 (UTC)
  20. Johnleemk | Talk 14:17, 8 Aug 2004 (UTC)
  21. rhyax 05:15, 2 Sep 2004 (UTC)
  22. AHM 01:46, 8 Sep 2004 (UTC)
  23. [[User:Eequor|ηImage:Venus symbol (blue).gifυωρ]] 20:28, 12 Sep 2004 (UTC)
  24. – Quadell (talk) (help)[[]] 16:08, Sep 19, 2004 (UTC)
  25. Ellmist Configurable contribution pages don't do much good when articles take forever to load.

[edit] Syntax and rendering (5)

Templates with parameters that actually work, new kinds of data e.g. chemical structural formulas, chess, music, etc., browser compatibility, WAP access.

  • Add your vote in a bullet point below
  1. [[User:OldakQuill|Oldak Quill]] 11:48, 6 Jul 2004 (UTC) Very useful feature. No more ASCII chemical formulae. Very useful for musicologists such as myself
  2. Neutrality 05:09, 14 Jul 2004 (UTC)
  3. FiP 16:31, 26 Jul 2004 (UTC) a tool to create chemical formulas could be nice ^^
  4. WAP access would be nice. But then there's the issue of compatability - for example, in Japan they use iMode rather than WAP (though I think Japanese devices might be able to read WAP as well), not all devices support Unicode or images... New kinds of data... hmm... what about "tree" charts? ie, to show a family tree, or a language family (which would differ significantly from a family tree), or the taxonomic relationship between genera? Node 21:29, 24 Aug 2004 (UTC)
  5. [[User:Eequor|ηImage:Venus symbol (blue).gifυωρ]] 20:29, 12 Sep 2004 (UTC)

[edit] Distribution (4)

Formal review, CDs, DVDs, print, static HTML dumps.

  • Add your vote in a bullet point below
  1. [[User:Sverdrup|❝Sverdrup❞]]
  2. arj 15:59, 5 Jul 2004 (UTC)
  3. Utcursch July 6, 2004
  4. Vrabcak 15:11, 14 Jul 2004 (UTC) WAP acces will be great

[edit] User rights (1)

Partial bans on users, e.g. from namespaces or given sets of articles, or number of edits per day. Alternative methods for sysopping and desysopping. Dangerous actions by quorum or consensus. Partial page protection, using file replacement or similar. Automated sock puppet checks. Trust metrics.

  • Add your vote in a bullet point below
  1. theresa knott 17:51, 5 Jul 2004 (UTC) this would give the AC much more flexibility

[edit] Feature suggestions

This is a vote, not a feature suggestions page! But you can add your suggestions below anyway.

  • Search engine should be significantly improved, to my mind. Let's say, if a person is not sure how to spell "parachute" and types "parachu" in the search window, Wiki can't find any article with the same combination of letters. In this sense, Webster.com, for example, is much better. KNewman 20:15, Aug 9, 2004 (UTC)
  • Sysops should be able to view a logged-in users' IP address to check for sockpuppetry. Because this is also privacy issue, it should be limited just to sysops. →Raul654 08:51, Jul 5, 2004 (UTC)
    • I have concerns about this. It is indeed a privacy issue, and I'm not sure that I'm happy with all Administrators having this ability. However, there may well be similar options. How about admins being able to see information along the lines of "User:PotentialSockpuppet has the same IP address as User:EstablishedWikipedian" - but not to actually see what the IP address is. -- ALargeElk | Talk 09:04, 5 Jul 2004 (UTC)
      • I disagree highly with Raul.-SV
  • Viewing contributions from a range - it's entirely possible that we will be vandalized by a range of IPs and the sysops will never know. One IP (a.b.c.50) will vandalize until he gets blocked by sysadmin Q. Then the vandal switches to another IP (a.b.c.56) until he is blocked by admin R. User should be able to view recent contributions from a given range of IPs to check for concerted attacks. →Raul654 08:55, Jul 5, 2004 (UTC)
  • Please, please, give us an easy way to revert page moves. →Raul654 08:56, Jul 5, 2004 (UTC)
    • Second this one. I guess it falls under "performance". anthony (see warning)
      • Good. Maybe dump the target text (usually a redirect) to a subpage. -SV
  • A way to move/copy pages between wikis, ie. "Trans" pseudo namespace.
  • [edit] links for section 0. It's minor, but it'd help. Dysprosia 09:03, 5 Jul 2004 (UTC)
    • Second this one. — OwenBlacker 01:58, Aug 8, 2004 (UTC)
  • "History for all pages on my watchlist since I last looked" - rather than the most recent history entry for each page in the last three days (or whatever). In other words, recent changes but filtered to my own watchlist, showing changes I might need to review. "Since I last looked" could be based on a cookie storing the last time of access to the page. Also allow fixed time periods as with the current watchlist, for those who accidentally refresh the page. -- Avaragado 10:29, 5 Jul 2004 (UTC)
    • Absolutely, this would be one of my favorite features ever! :o) — OwenBlacker 01:58, Aug 8, 2004 (UTC)
  • Ditto, enhanced recent changes but filtered to my own watchlist ("since I last looked" not needed, a selectable time period is sufficient for me).--Patrick 13:16, 5 Jul 2004 (UTC)
    • Similar to the above two, how about 'hide articles I last edited' in watchlist, or 'hide pages edited/not edited last by this user'... --ssd 20:26, 5 Jul 2004 (UTC)
      • I like this one too. — OwenBlacker 01:58, Aug 8, 2004 (UTC)
  • Renaming of categories. -- Avaragado 10:29, 5 Jul 2004 (UTC)
  • Category visualisation. A third party software way to visualise category links as like a genealogy/ tree, rather than as simply a list. This could help with pruning / eliminating redundancy, maybe a special page that lets sysops run specific bot scripts to prune categories.? -SV 19:05, 25 Jul 2004 (UTC)
  • [Security/Vandalism] : "Soft protection" of individual pages. A "soft protected" page can be edited but not moved. I envisage that pages with huge histories like the pump and vfd would be permanently soft protected. Certain vandals have learnt that page moving is an effective tactic.. our current defence against this (turn off all page moves) is not as effective as it requires intervention from devs whilst that the "soft protection" model could be administered by admins. Pcb21| Pete 11:11, 5 Jul 2004 (UTC)
  • Marking edits as checked would be very useful. I think that it needs to make it easy to see which edits have been accepted. It also should allow a short comment (like the edit summary) to be attached, so the reason that the edit was checked or not can be written (without going into talk every time). I would propose that each editor can mark the edit as one of the following:
    • Accept - The edit is a useful contribution and needs no further work.
    • Neutral - The edit is not obviously a vandalism, but the editor can't check its correctness at the present time. For example, in the minimum wage article, I recently saw a change to the minimum wage amount for Canada. I have no idea if it is right or not, so I would not mark it accept, but I might want to add a text comment even if I cannot accept it at the present time.
    • Needs work - The edit is an improvement, but needs spell fixing, grammar fixing etc.
    • Reject - The edit should be reverted. If this flag was there, it would help with problems with not knowing if there is a general consensus to revert an edit.
Then if this was tied into watchlists, it could be made easier to see if anyone has examined the edit and if I have examined the edit (make self checking specially marked, maybe bold or something). Also, if it was tied into recent changes, it would make finding unexamined edits easier. Jrincayc 12:53, 5 Jul 2004 (UTC)
I replied at User:Pcb21/Checked edits where I saw your points first. Pcb21| Pete 16:50, 5 Jul 2004 (UTC)
  • Deleting copyvios from the history
    • This isnt really necessary - but deleting ugly history (like insane revert wars and vandalism) might be demystified. -SV
  • User-configurable edit toolbar and personal toolbar
  • Live RC, ok, IRC is good enough, but in the long run I'd like to see some web interface.
  • More sorting options for RC - it zips by too fast now. -SV
  • "Add to watchlist" link on RC, and "Remove from Watchlist" link on Watchlist. -SV
  • Automatic archiving; It's silly we have to break our backs cleaning out VP, Vfd, FAC etc discussions; we have to develop some automatic archiving. (This is a challange to develop while managing the simple wiki database structure, I guess)
    • IRC is the new VP, but lacks direct username interface, and automatic ip cloaks. Forums was a bust, but simple threaded post capability for extremely active pages could work, provided they function within the same login interface.-SV
  • Divide wikitext into wikitext and meta fields; the meta field will contain stubmessages, langlinks, categories and other things we might add in the future.
[[User:Sverdrup|❝Sverdrup❞]] 13:52, 5 Jul 2004 (UTC)
Note that we already have live RC using IRC. Pcb21| Pete 15:56, 5 Jul 2004 (UTC)
  • Tables with better looking CSS styles (an example of a nice looking table). why have they been so neglected here? many users are relcutant to add them or downright abhorrent to table usage because of their ugliness. tables now are unsightly blights on otherwise elegant-looking articles. ✈ James C. 19:22, 2004 Jul 25 (UTC)
  • a real poll system, i know this is no small feature. given that the democratic process is such an integral part of wikipedia though, i think such a convention deserves robust infrastructure. the current implementations of polls is crude and inconvenient, and not suitable for any large scale usage. ✈ James C. 19:22, 2004 Jul 25 (UTC)
  • A number which says how many users are watching a particular page. If I see a small number I'd stick on and watch the page until traffic increases and more people have it in their watchlists. Number of watchers would also be an indicator of the popularity of the page, this is a useful statistic. Jay 15:10, 5 Jul 2004 (UTC)
  • Expand and collapse of discussions on talk pages, something like the Google mail interface. Jay 15:10, 5 Jul 2004 (UTC)
    • agreed. i'd like an overhauled Talk page format that is more similar to that of an online forum. right now Talk pages are difficult to use for productive discussions. the format lacks clarity and simplicity so essential for frequent, complex debates. ✈ James C. 19:22, 2004 Jul 25 (UTC)
  • Expanded functionality in random page related to quality issues. For example, 'view random stub' (or view random article in this category...); random article not watched much (see watchlist count above); random recent edit, etc... This could be used as another means to spot check stuff. --ssd 20:32, 5 Jul 2004 (UTC)
    • Category sorting by via RC/preferences ?
  • Distributed Recent changes (DRC) and watchlists (DWL). A DRC would work by assigning to whomever is looking at the page certain edits so editors doing RC patrol don't look at the same edits. This could be as simple as having a small flag on the edits based on the userid of the user. A DWL would have to be separate from the main watchlist, and it would spread out the number of all articles to some set of active contributors. Ideally, there would be some overlap, but with our currect number of active users and articles, I am not sure that would be a good idea. Dori | Talk 01:18, Jul 6, 2004 (UTC)
    • I had an idea similar to this. On the diff page, there could be a "next" link, which picks an recent edit based on some tricky algorithm for the editor to review. Unchecked edits would be selected with high probability, edits checked only by a new user with slightly lower probability, edits checked by several trusted users with very low probability. Conceivably, the user's field of interest could be taken into account. -- Tim Starling 05:52, Jul 6, 2004 (UTC)
  • A "percentage of life-time online" display at the user page (like the Free Internet Chess Server), to give a warning of addiction. Pjacobi 00:28, 11 Jul 2004 (UTC)
  • Better mediawiki documentation to make it easier for interested developers to join, a chart of how it's based up, the workflow in rendering a typical page, where all the global variables are stored an so on. And actually write things like "your first feature" on meta. -- Ævar Arnfjörð Bjarmason 03:06, 2004 Jul 13 (UTC)
  • A user preference for editing articles in UTF-8, so that characters outside ISO Latin-1 can be typed in directly instead of having to convert them to character entity references. See Wikipedia:Unicode. Gdr 11:10, 2004 Jul 13 (UTC)
    • How about just going one step further and actually support UTF-8 on en. it's supported on all the others. -- Ævar Arnfjörð Bjarmason 11:21, 2004 Jul 13 (UTC)
      • That would be even nicer, but might be controversial. A user preference for editing in UTF-8 would only affect people who chose to use it. Gdr 12:06, 2004 Jul 13 (UTC)
    • The only reason it has not been done is that it's a bit of trauble converting the whole database, it being contriversial is not the reason. In a perfect world en. would already be using UTF-8. Nobody has thus far wanted to keep ISO-8859-1 in favor of UTF-8 for any other reason that. -- Ævar Arnfjörð Bjarmason 19:53, 2004 Jul 14 (UTC)
      • Note that it's not just en on ISO 8859-1, it's also da, de, sv, nl and es. -- Tim Starling 00:42, Jul 15, 2004 (UTC)
        • What is the trauble with the conversion though? Some unsolved technical diffuculties? and if so what?. -- Ævar Arnfjörð Bjarmason 06:53, 2004 Jul 15 (UTC)
          • This has been discussed on wikitech-l from time to time. The issue is minimising downtime. Currently it would be possible to convert it by switching the wiki to read-only mode for a couple of days. We've discussed a few ways to reduce the time spent in read-only mode, now someone has to code one of them. -- Tim Starling 05:54, Jul 17, 2004 (UTC)
            • Each article could have a flag indicating whether it was in UTF-8 or ISO 8859-1. Whenever someone edits an article in ISO 8859-1, it gets converted to UTF-8. Other articles can be converted as fast or as slow as you like, with no downtime. Gdr 12:06, 2004 Jul 21 (UTC)
              • I think you'll find there's a more fundamental problem than that. I suspect that changing the character set involves tweaking something low-level in the actual database. Whether you do this to an already-populated database, or to an empty database which has to then be re-filled, this is not a trivial process and will not take a trivial amount of time or effort. --Phil | Talk 13:52, Jul 21, 2004 (UTC)
                • But texts encoded in UTF-8 and ISO 8859-1 are both just byte streams; there's nothing fancy about either coding. I doubt the database knows or cares. Character conversion is straightforward since each ISO 8859-1 character appears at the same code point in Unicode. I don't yet see what the problem is. Gdr 16:50, 2004 Jul 21 (UTC)
                  • You're thinking along the right lines, Gdr, but such things are easier said than done. There's no shortage of ideas and no insurmountable technical challenges, just a shortage of manpower. -- Tim Starling 09:21, Jul 22, 2004 (UTC)
  • The ability to view an "expansion" of a category (ie. contents of a category including sub-categories.) Then we can expand, for example Category:People and show that is a silly idea to categorise like this: Thriller -> Michael Jackson -> Musicians. When it really should be Thriller -> Michael Jackson albums -> Pop albums. At the moment it is hard for people to visualise this as category "expansion" is not visible. -- Chuq 05:51, 19 Jul 2004 (UTC)
  • I agree with Chuq that be able to view category expansion is the thing that Wikipedia needs the most right now. Spalding 19:30, Sep 6, 2004 (UTC)
  • Special:Upload could have a drop-down menu of the possible copyright/license positions for the uploaded file, as listed on Wikipedia:Image copyright tags (or at least the most common tags). The selected tag would be added to the image page along with the initial comment. Gdr 12:06, 2004 Jul 21 (UTC)


  • (Not my idea initially, expanding it.) If a template is included with {{name}} would it be possible instead of just writing the contents of that template into the html file like it's done now to wrap it in
<div class="template" id="name">Content of Template:Name</div>

so that it could be added to the CSS files to render specific templates in a certain way, this was initially suggested at the template:stub talk page, and was implemented so users could hide the stub template in their css, i think it would be great to make this global however. -- Ævar Arnfjörð Bjarmason 15:07, 2004 Jul 22 (UTC)

  • This is really minor but it's the kind of thing that drives me crazy: when displaying articles, I'd like it to drop out the line breaks before/after category and interlanguage links. Right now if an article has 10 categories, and each [[Category:]] was put on a separate line, you'll see a big blank space at the end (or beginning, depending on where the links were put). I'm calling this a feature request rather than a bug because this behavior is entirely logical, just annoying. --Hob 14:10, 26 Jul 2004 (UTC)
    • The problem with combining a load of Interwiki links on one line is that it distorts the display of DIFF pages, to give one example, making the displayed text very wide. I have discovered that the answer in many cases is to annotate the Interwiki links and Categories with HTML comments describing them, making sure you leave no actually blank lines: this seems to trigger a collapse of the white space. See recent discussion at the Village Pump. HTH HAND --Phil | Talk 14:40, Jul 26, 2004 (UTC)
  • A live CD project. A Knoppix variant that includes Apache and Wikipedia and contains any useful tools and configurations of developers to work on coding and editing for WP. If license issues preclude inclusion, the software is listed, and download/install links/processes are made easy.
  • Advanced random page button options. For example, half of the time it comes up with census information. I'd like to be able to limit my random to types of pages (at least x length, not automatically generated) and categories of pages (everything pertaining to biology but not biology history). --Ignignot 15:21, Jul 30, 2004 (UTC)
Retrieved from "http://en.wikipedia.org../../../t/i/m/User%7ETim_Starling_Feature_poll_aaf4.html"