After about a year of active development, it's appropriate to give Timber a 1.0 release, why?

• The API has stabilized. A minimum number of breaking changes have been introduced in the last few months, and of those the vast majority have been minor ones.
• Test coverage exists over 50% of the code
• Timber is in use by hundreds of sites
• Other projects are now using Timber as the underlying layer for template
• The GitHub and WP.org channels have solidified as the dev/distribution channels

However, before 1.0 there are several things that need to be completed

• Update Starter Theme with best practices (@ricwa230)

  • Consider moving starter theme's official home into its own repo, with linkage back to main Timber

• Request the Timber page from the WP.org admins

• Launch new project homepage with updated logo

• Ensure that all classes have at least "medium" coverage (50%) (Ensure all classes have at least 50% code coverage #264)

• Consider separating Routes into its own repo, with support in Timber (Move Routes to its own class #273)

• Audit objects for universal use of magic methods, meta, id, name, title, slug (etc.) (Audit core objects for common methods #272)

• Create a 1.0 upgrade guide noting deprecated functions/properties

• Remove deprecated functions (Label Deprecated classes in PHPDoc formatting #263)

• Name Spacing of Timber classes Contributor wanted

• Reduce clutter of main Timber class, implement TimberPostGetter for getting stuff (Consolidate Methods in Timber class #262)

• Resolve Partial Inheritance Contributor wanted

  Re:namespacing & autoloading: yes! Yes! Yes! :) This is also a good occasion to think about the problem of partial inheritance: make it easier to extend Timber objects, without having to extend the lot. Eg. if you want to extend TimberPost, but not TimberImage, you still have to extend TimberImage and set TimberImage::$post_class to 'MyTheme\Post', because otherwise you'll end up with an ordinary TimberPost instead of your own postclass when you call TimberImage::get_parent. @mgmartel on #161

• Implementation of WordPress coding standards (http://make.wordpress.org/core/handbook/coding-standards/php/) where appropriate.

• Autoloading classes Contributor wanted

  First of all, yes the autoloading. I of course use composer for dev dependencies, but I also use it for auto loading my own code. So first I had to figure out how to auto load Timber using composer. It wasn't so hard but it would be nice to be able to just pull it down with composer and just rock'n roll. Not having to configure the auto loading in the composer.json manually. @ricwa230 #161

• Review global vars and functions Contributor wanted

  I work hard to get rid of all global vars/functions and hideous name spacing. By encapsulating everything in a singelton class for my theme. Then it feels little sad the Timber is written so that it creates global stuff, but I understand why. @ricwa230 #161

• Figure out a better way to manage context objects (Create TimberView object to handle view rendering #261)

• Examine Parent/Child theme twig inheritance Contributor wanted

  It's impossible to override twig-templates in child themes. Maybe it's a bug that have been fixed. But last time I did a Parent-Child theme I had to do it. @ricwa203 #161
  @jarednova: This should be good and I've worked lots with parent/child twigs to success. That said, it'd be great to understand how users expect this to flow so we can write docs and tests around those expectations

• Examine and document widget rendering Contributor wanted
  It keeps coming up like in the comment below:

  You can also see that I specify a second folder for widget views. That's how I utilize Timber for custom widgets. Then I have a base class for all my Timber based plugins that uses this second template dir to render widgets and widget forms using Timber::render(). How this should be done is not covered in the starter theme either. It would be great with some plugin best practice and example classes that use Timber to render widgets. @ricwa203 #161

• Solidify best practices

  Make it more opinionated and teach the WP community to embrace MVC and true OOP. I think this at least should be the case for the code you/we write. All the rest of the WP code we can't do so much about, but with some best practice it will suck a lot less! ;-) Any thoughts about providing some base classes for themes and widgets? @ricwa203 #161

From this I'm going to spin-off issues from this document, but limit additional items. I've noted Contributor wanted labels above on the most-important items that I want volunteers to contribute their expertise on. My goal is to release a 1.0 within 60 days (Aug 12, 2014).

Please respond in the comments with refinements on the items above or if you want to volunteer for specific items (from which, I'll spin into an issue with more clarity). Let's keep general discussion on #161