Remove /lib/tools/test/ and add some emergency tools in /tools/ or /emergency
The theme system needs to be documented. This already has been started on the theme page.
Don't ship the final release with unneeded bloat, e.g. /lib/tools/, .po files, /modules/*/test/. (be careful of some modules that need modules/*/test/data like imagemagick)
See sf.net task 117349.
See sf.net bug 1241790.
A guide to document the common administration tasks as installing, upgrading, configuring, etc.
A guide for common user actions as adding albums, items, document each module and feature; what it does, how to use it, etc.
A module howto and an introduction to the G2 framework, how to do common stuff, etc.
Ideally, we'd have a package of all required and optional binaries for the supported platforms. Or link to the available precompiled binaries and offer a package of the missing binaries on our site.
Supported platforms: linux, WinXP, OSX, *BSD, Win2003Server, ...?
Binaries: NetPBM, ImageMagick, unzip, ffmpeg, jhead, dcraw, zip, php-cgi (with gettext, GD2, .. support)
Links to other requirements: apache, php, JRE,
A huge FAQ and a specialized knowledge base can simplify the everyday work as a support staff member tremendously. e.g. that blank site admin -> module pages could be caused by a too small memory limit (16mb is sometimes not enough), or how to deal with data corruptions, etc.
After Beta 4 was released, I have the impression there were more "install core module failed" issues than before. And it's very, very difficult to find the problem with the little output we get. Perhaps have much more $gallery->debug messages during the install process.
Of course it would be better if we had not to debug, i.e. if the installer was even more robust than it is at the moment.
Don't ship the final release with all available languages, only with en_UK. But users that can't extract a language archive over an existing G2 install will have a hard time adding the translation files in all modules manually via FTP.
The edit permissions UI was discussed again and again and the only conclusion was that it needs to be reworked. See [this forum thread] for a discussion of where this might lead.
See sf.net bug 903975.
See sf.net bug 1231227.
See sf.net task 111196.
Currently, we ask for at a memory limit of at least 16mb, else we show a warning in the installer. But even 16mb seem to be not enough for simple tasks like displaying the list of modules (site admin -> modules). 12mb seem to be not enough to delete an album. (in some cases). Most often, the user just sees an empty page or something like that. We should track down the memory consumption, e.g. if it is the translation files or what else.