Difference between revisions of "Reporting Issues with ccPublisher"

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

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.

autoreport 

this keyword is assigned to issues created via the crash reporter included in ccPublisher; manually created issues should never use this keyword

ccpublisher2-beta 

issues to be addressed for ccPublisher 2 Beta 2; at this point open issues with this keyword are considered massive regressions

ccpublisher2.0 

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

ccpublisher2.2 

issues we are planning to address in ccPublisher 2.2 which will be released before the iCommons Summit (23 June 2006)

ccpublisher2.4 

issues we are planning to address in ccPublisher 2.4 (November 2006)

i18n 

issues pertaining to internationalization (which in itself is targeted for 2.2)

Commenting on Bugs

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.