From RNWiki
Jump to: navigation, search
(Introduction)
(Issue Tracking)
Line 18: Line 18:
 
'''"Resolved" vs. "Closed"''' - The '''Change Status''' is important as it affects how we keep track of the status of the issue, but when it comes to completing the issue, there are two statuses to consider.  There are going to be times when an issue is raised that we find out later no change is needed.  Since there was no change, we do not want/need the '''Change Log''' to reflect a non-existent change.  Therefore, in this case, and this case only, please use "'''Closed'''".  For all other completions, we should use "'''Resolved'''".  In either case, a brief summary should be given as to the final results (use your judgment, but just keep in mind that we're not mind readers, so if it seems like there would be some helpful text to convey, feel free to do so).
 
'''"Resolved" vs. "Closed"''' - The '''Change Status''' is important as it affects how we keep track of the status of the issue, but when it comes to completing the issue, there are two statuses to consider.  There are going to be times when an issue is raised that we find out later no change is needed.  Since there was no change, we do not want/need the '''Change Log''' to reflect a non-existent change.  Therefore, in this case, and this case only, please use "'''Closed'''".  For all other completions, we should use "'''Resolved'''".  In either case, a brief summary should be given as to the final results (use your judgment, but just keep in mind that we're not mind readers, so if it seems like there would be some helpful text to convey, feel free to do so).
  
'''Target Version''' - In order to help Raven with roadmap planning and tracking, he desires that EVERY issue upon being opened is given a "Target Version".  The current release version will always be available to choose here, but if you feel that a different version should be used and its not there, just ask Raven or montego to add it.
+
'''Target Version''' - This is an important field and helps to drive the '''Road Map''' feature of Mantis. Every issue upon being opened is to be given a "Target Version".  The current release version will always be available to choose here, but if you feel that a different version should be used and its not there, just ask Raven or Montego to add it.
  
'''Fixed In Version''' - This is another important field and helps to drive the '''Change Log''' feature of Mantis (it saves us a ton of time pulling together the detailed change log to go with the release documentation!). Upon marking an Issue as '''Resolved''', please mark the release version it was resolved in. THANKS!
+
'''Fixed In Version''' - This is another important field and helps to drive the '''Change Log''' feature of Mantis (it saves us a ton of time pulling together the detailed change log to go with the release documentation!). Upon marking an Issue as '''Resolved''', please mark the release version it was resolved in.  
  
 
'''Issue Summary Text''' - Again, just think Change Log as the issue summary is automatically placed into that log.  Just try to make them read well and reflective of the change being made.
 
'''Issue Summary Text''' - Again, just think Change Log as the issue summary is automatically placed into that log.  Just try to make them read well and reflective of the change being made.

Revision as of 04:34, 24 July 2008

Process>Issue and Change Management

These pages are not meant to be taken by the general public as "end-all" static statements of direction. They are more "guiding principles" and they can and will change over time. We make these available here so the RavenNuke Team has one place to go to for this type of information, when decisions on direction have been made, and we decided to give the "public" a "peek" into what we are trying to accomplish... a "process roadmap" if you will.

You will note that we intend for this to be light-hearted! How else are we to have fun with "standards". :-)

Introduction

Bottom line is good issue and change management gives us and our end customers the following benefits:

  • When issues are raised in the support forums and a true issue is identified, it gets logged into the Mantis Bug Tracker System so we do not lose track of it (we're all VERY busy and so to rely on memory or each of us having our own methods, just does not make sense)
  • It helps us to plan our next release (roadmap)
  • It helps us to give a clear Change Log to the end customers
  • It helps us to track down the discussion and reasons for every change that is made to the code - this helps us to support the product better, as well as to help all of us to know what is changing from release to release

These are only a few that quickly came to mind. There are sure to be others.

Issue Tracking

Our standard tool for tracking our issues (which include enhancements and bugs) is Mantis. (Sorry, not going to give out the URL!) In order to meet the expectations for issue management laid out above, we need to be diligent in doing the following:

Every Change Needs an Issue - This pretty much goes without saying. If we cannot tie a change to an issue, we have no idea the reasons why the change was made. This goes for enhancements as well as for raised bugs. However, what about bugs that we introduce during the development of a release? (Yes, we're not perfect...lol) Of course these do not have to have their own NEW issue because the bug was introduced as a result of another change! Therefore, the fix for that bug is done under the original issue which caused it. But, again, this only applies to on-going development work. Bugs that we introduce in prior releases (that are already released) should have new Mantis issues to address (think "Change Log").

"Resolved" vs. "Closed" - The Change Status is important as it affects how we keep track of the status of the issue, but when it comes to completing the issue, there are two statuses to consider. There are going to be times when an issue is raised that we find out later no change is needed. Since there was no change, we do not want/need the Change Log to reflect a non-existent change. Therefore, in this case, and this case only, please use "Closed". For all other completions, we should use "Resolved". In either case, a brief summary should be given as to the final results (use your judgment, but just keep in mind that we're not mind readers, so if it seems like there would be some helpful text to convey, feel free to do so).

Target Version - This is an important field and helps to drive the Road Map feature of Mantis. Every issue upon being opened is to be given a "Target Version". The current release version will always be available to choose here, but if you feel that a different version should be used and its not there, just ask Raven or Montego to add it.

Fixed In Version - This is another important field and helps to drive the Change Log feature of Mantis (it saves us a ton of time pulling together the detailed change log to go with the release documentation!). Upon marking an Issue as Resolved, please mark the release version it was resolved in.

Issue Summary Text - Again, just think Change Log as the issue summary is automatically placed into that log. Just try to make them read well and reflective of the change being made.

That is it! We're doing much of this already.

Change Control

Our change control tool is Subversion. We don't need to explain the benefits of this tool! Just keep these things in mind regarding change control:

Subversion Client - Our standard for a windows desktop subversion client has been Tortoise. It really does not matter what client you use, but this one certainly is excellent. Whatever client you use, just make sure to keep it updated and that the client approach is to remain backward compatible.

Trunk vs. Branch vs. Tag - All of our development shall be done on the trunk unless otherwise communicated. We don't have the resources to maintain multiple branches of development, so we're pretty much sequential. Tags will be used to, well, "tag", our released revision. We should just let Raven create the tags.

Always Update Prior to Commmit - This is very important as it has caused us some grief in the past. Since we're all collaborating on the code, it is possible for multiple people to be updating the same script at the same time. ALWAYS run an SVN update on your scripts just prior to committing them! Thanks!

Conflict Resolution - If when you perform the above update, you find that other code changes have been merged into yours OR a conflict occurs (subversion will tell you when this occurs), more action must be taken. If other code changes are merged into yours, it would be a good idea to re-test that portion of the code if you think there could be any issues with the code changes you have to commit. If there are conflicts, well, read the help within Tortoise as to how to deal with those. This means that you have modified a line of code that someone else has committed changes to! If you just commit your changes, everybody's working copies, upon an update, will be broken!

Change Description - It is important within the change description (called "Change Message" in the client) back to the Issue which drove the change (that is where the discussion and/or reasons for the change are kept, plus the tie back to the Change Log). It is also helpful to provide a brief description of the change that was made. No, we don't need to go hog wild there as we can always do a revision diff and see the changed code. But, anything you feel would be helpful to someone to quickly get a sense for the change and/or amount of change, it just helps when people do an update of their working copy to see what could likely be impacted.

Just as a helpful "hint", it is extremely easy when you are in your issue, to just copy the whole Summary text line and paste it up-front into your change description. For example:

0000968: Allow users to set maximum number of items per feed

That sure gives a nice clean and very clear "picture" of what that change was! Hint... hint...


That is it. Nothing new from what Raven has already communicated from time-to-time.