Don't rush. Start putting things together earlier. If a deadline is nastily approaching, change it.
Do things properly with thought-out rationales — don't just redirect last year's page to the new page, move all of the pages at once (either with a bot or script) so we can keep them around. You never know when we'll need them again, either for translations, code, or just to see what last year was like.
Communication amongst the team members could be better. A public fundraising channel on IRC is the best solution (we had something like this in 2008)... private things can be moved to IM or PM.
Use a testing platform/site (dev.donate.wikimedia.org) that's actually like the final destination... create draft notices *in* CentralNotice, so we don't have to re-invent things.
Numbers in the translation request are helpful.
Quadruple^nth check that you have all the strings included in the translation request.
If we're going to have a link within a string, make sure that that's noted in the translation request.
Have working drafts available. Screenshots are better than nothing, but a working demo is <3.
Community feedback was weird this year: the beginning (donation buttons, etc.) was full of it and then the final result (WIKIPEDIA FOREVER) was just handed to the community without much say in the matter.
Be more diligent in responding to translator questions.
Staggered launches worked great.
Create a separate notice template with all the shared pieces that are specific to this fundraiser. (all donate-url's, all Support Wikipedia's, etc.)
Communal To do list worked well.
Cross-browser checking *while developing*.
Don't go half-way on the Wikipedia vs. Sister projects issue, it just leads to confusion.
Don't piss of the chapters.
Reuse. Multiple pages with exactly the same thousand characters (save for a few small changes) should be avoided (e.g. Support Wikipedia/en & Support Wikipedia2/en)
