This page is not current and is based on an older project run by Creative Commons. Please take a look at github.com/creativecommons
for our current projects.
ccPublisher uses a slightly customized Roundup Issue Tracker for tracking development efforts. The tracker is available at http://roundup.creativecommons.org/ccpublisher. Information that should be recorded in the tracker includes:
- bug reports
- feature requests
- software engineering decisions
Keywords are used by the tracker in order to group or target issues. For example, issues that are intended to be addressed before a particular release will share a keyword, and issues relating to a particular area of functionality (i.e., i18n) are assigned a particular keyword. The following keywords are in use in the tracker. Please attempt to assign appropriate keywords to your issue upon creation.
- this keyword is assigned to issues created via the crash reporter included in ccPublisher; manually created issues should never use this keyword
- issues to be addressed for ccPublisher 2 Beta 2; at this point open issues with this keyword are considered massive regressions
- issues to be addressed prior to the final ccPublisher 2 release; at this point open issues with the keyword are considered bugs which need to be fixed in a future 2.0.x release
- issues we are planning to address in ccPublisher 2.2 which will be released before the iCommons Summit (23 June 2006)
- issues we are planning to address in ccPublisher 2.4 (November 2006)
- issues pertaining to internationalization (which in itself is targeted for 2.2)
The Tracker works best when users and developers provide comments and feedback on specific issues. When writing comments there are some guidelines which help us fix bugs and implement features:
- Be specific If you can record the exact steps to reproduce a crash, it greatly simplifies tracking down the problem.
- Be explicit When marking an issue resolved, you should explicitly record when it was resolved (i.e. which Subversion revision). However, it is still better to record the revision and provide a summary of what the fix actually was. This is useful if the fix introduces a regression or if a similar bug is reported in the future.