So I have my little mediawiki 1.4rc1 running OK on my PB G4 (Panther at the moment, Tiger coming up), and am looking at the bugzilla list, but it's somewhat unclear on how to choose what to look at - priorities and criticalities seem kind of random. I have some bigger projects in mind, but this is my first foray into web apps, so I'd like to try some simpler hackery to begin with. Any suggestions?
Stan
Stan Shebs (shebs@apple.com) [050225 12:12]:
So I have my little mediawiki 1.4rc1 running OK on my PB G4 (Panther at the moment, Tiger coming up), and am looking at the bugzilla list, but it's somewhat unclear on how to choose what to look at - priorities and criticalities seem kind of random. I have some bigger projects in mind, but this is my first foray into web apps, so I'd like to try some simpler hackery to begin with. Any suggestions?
Seconded (almost got it up on FreeBSD). Is there any categorisation of bugs that count as small things no-one's gotten around to for those unfamiliar with the codebase, or something like that?
- d.
David Gerard wrote:
Stan Shebs (shebs@apple.com) [050225 12:12]:
So I have my little mediawiki 1.4rc1 running OK on my PB G4 (Panther at the moment, Tiger coming up), and am looking at the bugzilla list, but it's somewhat unclear on how to choose what to look at - priorities and criticalities seem kind of random. I have some bigger projects in mind, but this is my first foray into web apps, so I'd like to try some simpler hackery to begin with. Any suggestions?
Seconded (almost got it up on FreeBSD). Is there any categorisation of bugs that count as small things no-one's gotten around to for those unfamiliar with the codebase, or something like that?
Hm, a few things off the top of my head...
Adding test cases for reported parser bugs to parserTest.txt would be super nice, and should be really easy. If you can come up with fixes for them too that would be even better of course. :)
Also nice would be looking for bugs marked with the 'patch' keyword, where there's a posted patch which hasn't been applied. If it looks good, and you can confirm it works (or fix it / improve it) and give us a reminder, that would be helpful.
[1478, 1334, 1120, 1403, 1423, 1479, 1539, 1455] There are several open bugs for language file updates; these need cleanup and testing. Hardcoded 'Wikipedia' names need to be removed from some files, and some older HTML formatting needs to be changed to wiki or plaintext. This is mostly some search-and-replace and testing that things look ok.
[1037, 1023] Many UI messages are not properly sanitized for HTML output, or are explicitly done in HTML; moving on to new versions these need to be appropriately fixed to plaintext (wrapped in htmlspecialchars()) or wiki text (output with $wgOut->addWikiText()). At the least, HTML should be valid.
If someone can manage to reproduce and fix the 'cannot redefine class' errors that some people have on installation, that would be great! It's probably something to do with include paths and/or path normalization, but I've never been able to reproduce it and nobody experiencing the problem has been able to debug it. After the PHPTAL temp file problems (now gone in 1.4) this is probably the most common installation complaint.
Every now and then people complain that Special:Whatlinkshere cuts off after 500 items. (Some pages have over 30,000 backlinks; showing them all at once is *not* an option.) The links are unsorted, and the display is additionally complicated by it showing subtrees for redirects. Your mission: find a sensible, performant way of displaying and paging through this list.
-- brion vibber (brion @ pobox.com)
Stan Shebs schrieb:
So I have my little mediawiki 1.4rc1 running OK on my PB G4 (Panther at the moment, Tiger coming up), and am looking at the bugzilla list, but it's somewhat unclear on how to choose what to look at - priorities and criticalities seem kind of random. I have some bigger projects in mind, but this is my first foray into web apps, so I'd like to try some simpler hackery to begin with. Any suggestions?
There's a page on Meta, but it's pretty out of date: http://meta.wikimedia.org/wiki/Development_tasks
Some small and medium-sized tasks that would make a big difference, in my opinion:
1) Per-page blocks (only from an individual page, not the associated talk page). This could be a very useful tool in addition to full blocks. Some more radical thoughts on blocking and vandalism: http://mail.wikimedia.org/pipermail/wikitech-l/2004-March/021341.html
2) Filters for Special:Recentchanges, e.g. namespace filter. Paging ("next 50") like on history and contributions pages. Simplify RC patrol - is it used for anything but new pages?
3) Summarize uploads into one line in Special:Recentchanges, instead of two (could omit the Image:Foo.jpg line and just linkify the Image:Foo.jpg in the upload comment)
4) Transclude shared repository (Wikimedia Commons) image information from a shared database ($wgSharedDB). Tricky part would be cache interaction, though simply transcluding dynamically and purging manually might be enough for now. Having an "extlinks" table in the shared DB that collects data on where the files are used would be excellent.
5) Add a simple license selection dropdown list to the upload form. This could get its data from MediaWiki:Licenses, which could be a paired list like:
GNU Free Documentation License=>{{GFDL}}
The part before the "=>" would be shown in the dropdown. The part after the "=>" would be inserted into the image description page if the option is selected.
6) Structure category pages by namespace: http://bugzilla.wikimedia.org/show_bug.cgi?id=450
7) "Save as" for upload form: http://bugzilla.wikimedia.org/show_bug.cgi?id=1105
8) EXIF data for uploads: http://bugzilla.wikimedia.org/show_bug.cgi?id=1555
9) Rename "Image:" namespace to "File:", but make sure "Image:" (*or its localized equivalent, that is the hard part*) continues to work as a synonym.
10) Delayed editing as alternative to protecting pages. This is medium to big. When protecting a page, allow the user to set a timer. The page remains openly editable, but users are actually editing a copy (how to best explain this UI-wise - on edit screen, page history?). The copy only replaces the live version after the timer has elapsed. The timer is reset to the full time whenever someone else makes an edit within the set timespan.
These should keep you busy for a while ;-). On the bug, security and performance side of things, Brion can give you the priorities. Let me know if I can help with any of these.
Regards,
Erik
On Fri, 25 Feb 2005 05:40:20 +0100, Erik Moeller erik_moeller@gmx.de wrote:
- Per-page blocks (only from an individual page, not the associated
talk page). This could be a very useful tool in addition to full blocks. Some more radical thoughts on blocking and vandalism: http://mail.wikimedia.org/pipermail/wikitech-l/2004-March/021341.html
Apart from per-page blocks, a block for the main namespace would also seem useful. Then someone could be forbidden from making changes themselves, but still propose them or state his own case.
- Filters for Special:Recentchanges, e.g. namespace filter. Paging
("next 50") like on history and contributions pages. Simplify RC patrol
- is it used for anything but new pages?
I and several others on nl: are using it for anonymous edits as well. I even have http://nl.wikipedia.org/w/index.php?title=Speciaal:Recentchanges&hideliu... as one of my starting pages. If I have the time I go through those 20, then take 20 _with_ logged in users then without again...
- Add a simple license selection dropdown list to the upload form. This
could get its data from MediaWiki:Licenses, which could be a paired list like:
GNU Free Documentation License=>{{GFDL}}
The part before the "=>" would be shown in the dropdown. The part after the "=>" would be inserted into the image description page if the option is selected.
Yes! That would be good!
Andre Engels
On Thu, 24 Feb 2005 17:12:32 -0800, Stan Shebs shebs@apple.com wrote:
So I have my little mediawiki 1.4rc1 running OK on my PB G4
I just wanted to comment that a lot of the things people have mentionned are of the order of brand new features, so won't it make more sense for some of them to be developed on HEAD (1.5) rather than 1.4?
Or am I doing the wrong thing hacking at that branch? [Trying to rationalise the image syntax parsing somewhat]
Rowan Collins wrote:
On Thu, 24 Feb 2005 17:12:32 -0800, Stan Shebs shebs@apple.com wrote:
So I have my little mediawiki 1.4rc1 running OK on my PB G4
I just wanted to comment that a lot of the things people have mentionned are of the order of brand new features, so won't it make more sense for some of them to be developed on HEAD (1.5) rather than 1.4?
Or am I doing the wrong thing hacking at that branch? [Trying to rationalise the image syntax parsing somewhat]
Pretty much anything that's not a security fix, localization correction, or relatively straightforward bug fix should be done in the HEAD branch for 1.5.
If a bug fix can be cleanly worked into REL1_4 without breaking things, then we'd be thrilled to have it in 1.4 too. :)
Personally, I keep three branches checked out and have three test wikis on my two development machines (a PowerBook running Mac OS X and a desktop PC running Linux): a REL1_3 checkout for security updates on 1.3, a REL1_4 for current fixes, and a HEAD for major work on the next release.
Remember less is more; new features should strive to remove complexity rather than add it.
-- brion vibber (brion @ pobox.com)
Rowan Collins wrote:
On Thu, 24 Feb 2005 17:12:32 -0800, Stan Shebs shebs@apple.com wrote:
So I have my little mediawiki 1.4rc1 running OK on my PB G4
I just wanted to comment that a lot of the things people have mentionned are of the order of brand new features, so won't it make more sense for some of them to be developed on HEAD (1.5) rather than 1.4?
I just started there to have a known-working-more-or-less version; if I actually do something worthwhile, I'll set up a test copy of the head as well.
Stan
wikitech-l@lists.wikimedia.org