Launch! Product Release and Community Process

Making a good product release is about more than just slapping some code up for download. Before taking the plunge and creating a public release for your product by listing it on plone.org, make sure you're ready to make the commitment! Here's what you should do to help the Plone community find, learn about, get started with and help you improve your products.

Connect With Other Add-on Product Developers

Your fellow developers can be an amazing source of advice, help, enthusiasm and support.  And they hang on on the product-developers list.  Come join us!

Put Your Code in the Plone Collective

Every publicly released product should have a public SVN repository, preferably the Plone Collective, unless there is a compelling reason to put it elsewhere.  Without a public SVN repository, the Plone community won't be able to help test or contribute to your product.  The Collective is the single most "accessible" place for code in the Plone community. Be sure to "tag" all of your releases in the Collective (that is, copy the code (usually the trunk) to the "tags" directory), and never change or delete anything you tag — people might be depending on this form of accessing your code in zc.buildouts!

Listing Your Product on Plone.org

Each released product should have an entry in plone.org/products with accurate, up-to-date information on current and past releases.  There's no need to make an entry before your first public release. Because the Plone community is standardizing around using zc.buildout, it's critical that you not remove or rename any releases you make on plone.org!

Plone Software Center (which powers plone.org/products) also offers a few extremely useful features to help you maintain and improve your code.  We strongly recommend that you take advantage of:

• Issue tracker: Every product should have a public issue tracker, preferably on plone.org/products unless there is a compelling reason to put it elsewhere.  This helps users of your product report bugs and find out when they're fixed.
• Roadmap: Active products should have a roadmap for future improvements and improvement proposals.

Tip: a lot of people like to see examples of an add-on product in action before deciding to use it.  If it's appropriate and possible, try to include in your product description a couple of URLs that show your add-on product in action.

See http://plone.org/documentation/tutorial/plone-software-center for more tips on making the most of Plone Software Center.

If you're code is distributed as an egg, be sure to release each new version to the Python Package Index (aka PyPI; formerly known as the Cheese Shop) to make your code available to a zc.buildout-based setup in a matter of a few lines of buildout configuration.

• Learn how to get write access to the Collective.

Documentation

Products that expose functionality to end-users of Plone should have end-user documentation, preferably at plone.org/products, so it is easily accessible to people who do not have filesystem access.

• Every product should have an INSTALL or README document that clearly describes how to install and uninstall the product, and lists any dependencies on other products or libraries.
• If appropriate, a product should have documentation for integrators that describes how the product can be customized or extended.

• Your product should include an open source license (preferably GPL), credits and have an appropriate version number.

• You should maintain a HISTORY.txt file that lists the important changes with each release. Note that this shouldn't necessarily be a verbatim listing of the subversion log, but should be clearly distilled to a list of known bugs that were fixed, new features, and noteworthy structural improvements.

   

Engaging the Community

The most powerful part of Plone is its strong, diverse and friendly community of users and developers.  The most successful add-on products for Plone tend to be ones whose authors successfully engage with and participate in the wider Plone community.  Participating in the Plone community will help you become a better Plone developer.  Open source communities are driven by social capital and reputation, and more that people get to know you, the more confidence they'll have in your code, and the more they'll be willing to pitch in to help you extend and maintain your product.

• For help with add-on product development: the best place to ask is Add-on product developers.
• To announce a new add-on product: address both Add-on product developers and General questions.

Stewarding a Product

Once you've released a product, be a good steward! This doesn't mean that you need to be the sole developer for future enhancements, but that you take some responsibility to drive development forward and address the needs of users. This means:

• listing your email address as the product's contact on it's Plone Software Center page
• responding to bug reports and grooming the bug tracker
• making point releases when needed
• finding a new steward if you no longer are up for the job.