Per recent development chats, we’ve worked out a project schedule for 3.3. The plan:

July 20, 2011 Confirm planned timeline.
July 27, 2011 Confirm planned scope.
August 31 September 14, 2011 Non-Leads Feature freeze. No new features added after this point by contributors. After this a week for lead developers to assess the state of trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. and identify anything that needs to be pulled for lack of maturity, or to drop in things that were intended for the releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. but hadn’t been finished yet.
September 7 21, 2011 Complete Feature freeze. No new features added after this point, so that testing can begin on a stable-ish product (including usability testing of new features).
September 14 28, 2011 Usability Test Results. Review results of testing, makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). fixes based on findings.
September 21 October 5 7, 2011 Target date for betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1.
UIUI User interface freeze and primary code freeze. Any last adjustments based on testing after feature freeze should be finished by now and the focus shifts to fixing bugs to get to a stable beta.
From this point on, no more commits for any new enhancements or feature requests in this release cycle (including blessed), only bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes. Any enhancements/feature requests not completed and committed by this point will be punted to future. Please don’t get angry and complain when this happens; it’s necessary to get us to an on-time release. You can keep working on your pet ticketticket Created for both bug reports and feature development on the bug tracker. and have it ready for 3.4 early.
October 15 29 November 11 or 14, 2011TBA Target date for RC 1. String freeze; translators rejoice.
November 15 29, 2011TBA Target date for WordPress 3.3 launch.

So: if you have made a 2011 new year’s resolution to get involved in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development, now’s the time to head on over to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and pick a 3.3 ticket (that sounds kind of like a carnival game, doesn’t it?). Get your patches done and submitted as soon as possible, then drum up people to test the patches and leave feedback on the ticket. As stated above, no patches for enhancements or feature requests will be committed after the posted deadlines, so that we can all focus on squashing bugs and hopefully deliver the most bug-free WordPress to date. Wish us luck!