IssueProcess

Issue Process

For the OD Toolbox project, we need to track specific work items such as bug reports, feature requests, action items, etc. These are all referred to as issues. Issues can apply to any significant change or work performed on the project such as MATLAB or Java code and documentation, testing infrastructure, Wiki documentation, or even Mantis, Git and Trac configuration and infrastructure.

All issues are tracked using Mantis as the Issue Tracking System (ITS) on the FFTB server. Matlab source code, Matlab help documentation and project management artifacts such as schedules and requirements are configuration managed. All configuration managed items are stored using an approved Configuration Management Tool (CMT). For this project the CMT for source code and manuals is Git and the Requirements Management Tool (RMT) is Trac. They are both hosted on the OD Toolbox SourceForge Site.

The procedure for submitting, resolving, and closing an issue is summarized below.

1. The Reporter of an issue:

1. Creates the issue in the ITS by filling in as much detail as possible and as many fields as possible,

2. If applicable, includes the ODTBX Release number or source control information to specify the code in question,

3. (Optional) Includes priority and/or targeted Increment/Release number, (This may be altered by the CCB)

4. Attaches any files or test cases that will help the developer replicate the problem,

5. May make a recommendation for resolution to the developer in the Notes,
   (An Issue number is assigned by the ITS that stays with the issue throughout its lifecycle.)

6. Sets the status to “New”,

7. Submits the issue.
8. If the issue is urgent, requiring attention before the next CCB meeting, sends an email to the Project Manager requesting early resolution.

2. The Project Manager

1. Monitors the progress of all the issues on a regular basis
2. Reviews any urgent issues and assigns a developer, if warranted

3. The Configuration Control Board (CCB), consisting of at least the NASA TM (or the designated alternate), the project manager (or the designated alternate), and the lead developer (or the designated alternate),

1. Reviews all the “New” issues to ensure all issues are regularly addressed.
   • Determines the issue type: a bug fix, a new feature or an action item
   • Determines an initial estimate of scope and work required to achieve. (If this is not possible during the meeting then a developer is assigned to investigate.)
   • Makes a decision to:
   • Reject the issue (perhaps not appropriate or infeasible): the status changes to "Closed",
   • Postpone or defer from the current work scope: the status changes to "Acknowledged"
   • Request more information from the Reporter: the status changes to "Feedback" and the "Assigned To" field is set to the Reporter (see Using "Feedback", below)
   • Request an analysis of scope and work estimates from the Developer: the status changes to "Assigned" and the "Assigned To" field is set to the Developer
   • or assign a developer (to work): the status changes to "Assigned" and the "Assigned To" field is set to the Developer
   • Resets the priority, Increment/Release target, and other fields, as appropriate
   • Adds information to help the developer with a recommended resolution path
2. Reviews all issues with "Acknowledged" to determine if they should be acted upon (a status change) or kept as "Acknowledged".
3. Reviews all the open issues with status “Assigned” or “Feedback” to determine progress
   • Reprioritizes and/or reassigns, if needed, based on schedule, work estimates of each issue, roadblocks, etc.
   • Evaluates information from the Developer, Project Manager, or Reporter as required for issues with a status of “Feedback”.
   • As above, and if warranted, the issue can still be rejected ("Closed"), or postponed or deferred ("Acknowledged").
4. Ensures:
   • By the end of the meeting there are no "New" issues.
   • All "Assigned" issues are prioritized and scheduled against the developer resources and Project plan targets.
   • Only "Assigned" or "Feedback" issues are represented on the current schedule.
   • Developers have their prioritized list of "Assigned" or "Feedback" issues to work.
5. Meets at least biweekly.

4. The assigned Developer receives an email of the assignment from the ITS and

1. Evaluates the issue scope and work estimates.
   • If this is the only direction from the CCB then notify the Project Manager when the work estimate is complete.
   • Record this work estimate and details that support the estimate in the issue for further CCB evaluation.
   • If this is a new feature or a significant change to the code, a design review should be conducted. This can be informal or formal (if the change is pretty extensive). The Developer would present a preliminary design to the CCB of how the new feature/change would be implemented or through a separate meeting (even by email exchange). The approval of the CCB of the design should be documented in the ITS.
2. Performs the work:
   • Fixes the defect/problem or adds the feature, adding code comments for other developers as needed.
   • Makes notes in the ITS describing any changes to software, hardware, or requirements, as well as any lessons learned. Notes containing status information are also highly encouraged.
3. Documents changes and/or new feature in the code documentation and applicable supporting help files and end-user documentation.
4. Validates and tests the fix or the feature
5. If related to code, as part of the QA process,
   • Makes sure the auto-regression test passes
   • Makes sure the demo examples run successfully and match the expected results (TBD:Need to make this part of the regression test step)
   • Creates a new regression test to add to the regression test suite, if applicable, to maintain the functionality of the new feature or to capture a possible reappearance of the defect.
   • Checks-in the changes to the source control repository. See the feature-driven development process and [OdtbxCheckInProcess] pages for more details.
6. Adds notes regarding the tests conducted and that the change has been checked into source control. As a minimum, provide the names of files that were affected or are new and a description of the tests. See the [OdtbxCheckInProcess] for more details.
7. Changes the status to “Resolved” and fills in the “resolution” field
8. If additional information is required from the Reporter or another Developer (see Using "Feedback", below):
   • Add a note describing the required information and change the status to "Feedback"
   • Then assign the issue (change the "Assigned To" field) to the person required to provide feedback for tracking purposes. This will cause the ITS tool to notify the assigned person to the request.
   • Otherwise, contact the Project Manager if the Developer cannot determine the appropriate person to provide the feedback. The Project Manager can forward the feedback request to the CCB for further scrutiny.
   • If the feedback is critical to meeting the work schedule, contact the appropriate person and/or the Project Manager so that the request can be managed.

5. The Reporter receives an email of the “Resolved” status from the ITS and

1. Reviews how the issue was fixed by the Developer
2. Performs testing to verify the issue has been resolved, a necessary QA step
3. If satisfied with the resolution and the test results,
   • Changes the status to “Confirmed”
   • An email is sent by the ITS to the Project Manager when an issue has been Confirmed
4. If not satisfied,
   • Changes the status to “Feedback”, sets the "Assigned To" field to the Developer, and includes the feedback information (see Using "Feedback", below)
   • An email is automatically sent to the Developer

6. The CCB, during its biweekly meeting,

1. Reviews how the “Confirmed” issues were resolved
2. Reviews the level of risk involved in the fix
3. If satisfied with the resolution, the test results, and the risk,
   • Changes the status to “Closed”
4. If not satisfied,
   • Changes the status to “Feedback” with a note, and
   • Reassigns the issue to the same or a different developer (see Using "Feedback", below).
5. Reviews any "Resolved" issues where the Reporter may be the same as the Developer.
   • This can occur on small projects and might be applicable for issues such as action items or low-risk changes.
   • The CCB itself performs the QA step or decides to skip the formal QA
   • Again, if satisfied with the resolution, the test results, and the risk, changes the status to “Closed”
6. An email is automatically sent by the ITS to the Reporter of any changed status of the issue

Using "Feedback"

In the Mantis ITS the "Feedback" status is used as a mechanism to denote issues that may be blocked because additional information is required. It is an optional, and often a temporary status, than can occur almost anywhere in an issue's life cycle. Some issues may never require its use. The "Feedback" status is useful to provide visibility into an issue's progress to all parties. The Project Manager and/or CCB can use it to see when action may help address project roadblocks.

An issue's "Assigned To" field in the Mantis ITS should be adjusted to reflect the individual that is responsible for that issue. This field can be adjusted as the issue moves through its life cycle. As mentioned above, when using the "Feedback" status set this "Assigned To" field to the person who will provide the feedback. Whenever the "Assigned To" field is changed the new assignee is notified via email from Mantis. If the appropriate person cannot be immediately identified then setting the "Feedback" status is acceptable as long as the Project Manager and/or CCB are notified of the problem.

The party that set the "Feedback" status shall reset the status and "Assigned To" fields back to their values before the feedback was provided. This occurs after the assigned person has provided adequate feedback to satisfy the query.

Finally, it is helpful to long-term project maintenance if the feedback question and the resulting feedback are both captured in the issue's notes. If the feedback is too lengthy a summary should suffice.

---

Navigation

[ForDevelopers] - Go to the main development page

WikiStart - Go back to OD Toolbox Home