Please note: This is a re-post of a section in a weekly status update from early November. Some feedback indicated that it's worth an individual blog post. Since most of it still applies, also given the upcoming qooxdoo 1.0-beta1 release, please read this copy in case you missed it before.

"[...] Talking of maturity this is to remind you of qooxdoo's ramp down towards the 1.0 release, which is still planned for the end of the year. During the last weeks, actually for several months now, a huge number of bugs have been resolved, enhancements implemented, larger topics and inconsistencies in the framework addressed. The testing infrastructure, that was established and improved in the course of the year, became a valuable tool as it helps ensuring a sufficiently high level of software quality. Among all the regular development activities, which we're able to pursue ourselves as full-time framework developers, the input and support of the community, contributors and committers naturally is of great importance. This is especially true for the challenges when approaching a 1.0 release.

We'd like to ask for your dedicated help and support during the next few weeks. For instance, if you encounter issues and inconsistencies that to your knowledge (please scan bugzilla first) aren't recorded or addressed already, please let us know. Pay special attention to all API related issues, as it gets naturally much harder to address those after a 1.0 release, which is supposed to gain much from API stability. Clearly, not all open issues can be resolved for qooxdoo 1.0, or any release after, but we're focused on addressing the most important and relevant defects as well as the most significant enhancements in a reasonable manner. Again, when reporting real defects, or requesting enhancements, please choose qooxdoo's regular bugtracking over the mailing list. This usually guarantees for the most effective and least redundant workflow without cluttering up the list.

All assignees of a bug are asked to review the issues soon, possibly working closely with the reporters in resolving them. If you happen to be the reporter of a defect or an enhancement, or otherwise interested in the issue being resolved, please feel free to approach the current assignee and offer your help. We regularly perform bug triage to never have a real defect unassigned. That doesn't mean that the assignee is going to work on such an issue promptly. If he/she does or plans to, the status is supposed to be switched from "new" or "reopened" to "assigned". See the bug handling documentation for more info. If you're in doubt, talk to each other.

In the next few days we'll also prepare for the 1.0 copy of the qooxdoo manual (Update: available now). Like the rest of the homepage it is just a wiki, so after a simple registration you can collaborate in improving the existing documentation. Everybody is encouraged to review the current articles, i.e. finding, reporting and preferably enhancing/fixing the docs. Language corrections by native English speakers are appreciated. Much of this also applies to the API reference, which is generated from the JSDocs of the qooxdoo code base. If you identify issues that should be addressed, at least report them, at best fix them yourself. It would make sense to carefully go through a current SVN checkout and review individual namespace packages. After you make the changes to your local copy, a patch file can easily be generated and attached to a corresponding bug report. We'd take care of applying your API corrections asap. Does anybody feel like participating and help coordinating efforts around the wiki and/or API docs?

When preparing the wiki for 1.0 in the next few days, we'd also like to correct a milestone misnaming: being in the ramp down for qooxdoo 1.0 for a while now we decided to rename the formerly planned (but then postponed) 0.9 release to a 1.0-beta pre-release (Updated: renaming to 1.0-beta1 finished). While there are certainly pros and cons of having another "formal" major release, this renaming matches best the status and progress of previous and current framework development. As with any release, beta or major, we'd appreciate you tried this code base at the time of availability, planned for end of November, in order to spot any open issues. This even more applies to SVN trunk, thus anyone of you that is able to run his/her qooxdoo apps against a recent trunk version, is encouraged to do so. Of course, we can't expect you to do this for your production code, i.e. in its deployed version, but often it might not be much effort for you to have a parallel version built and tested against qooxdoo trunk as well. Besides helping framework development, you'd also help yourself and your investment as being close to the qooxdoo trunk helps you to notice and react to any changes and regressions you'd not be comfortable with in a 1.0 or after.

It would be great if you kept an eye on the mailing list to help other community members with their problems and answer their questions. On a daily basis the members of the core team use to take care of supporting the mailing list. With more users helping out others (and some of you are really excellent in doing so!), the time saved could rather be invested in framework development and the upcoming releases.

Think about all ways you could (even more actively) support qooxdoo. Thanks!"