Also, to clarify my motivation in doing this...
I agree that not all the ideas are great ideas... although, as I looked through the list, I didn't find one single instance where I thought "Hmm, this is probably a bad idea, this shouldn't be done." What I have tried to do is first, identify "easy" versus "hard." UI tweaks are easy, it's a few lines of code and a few minutes of testing. At the other extreme, some things are hard. Multiple database support requires a lot of design, a lot of coding, a lot of testing. And so I took the things that seemed, from my own experience, harder, and put them under the major integration heading. I took the things that the API doesn't support--and thus we have to wait, or, devise a work-around--and put those in a separate section. Then all the stuff that is left is grouped into basic categories. The idea of categorizing is that if Mikko is going to go work on a logging feature, why not have all the logging-related requests in one place so he can easily see if there are any that he'd like to "shim" in while he's in that code neighborhood.
