Using Redmine¶
what project
priorities
minimum details for a bug
- versions
- FWD revision used for conversion
- FWD revision used for runtime
- skeleton version
- possenet version
- 4GL application code version
- OE version
- application environment (GUI, ChUI, batch, appserver agent, REST, SOAP...)
- clear and repeatable recreation instructions (written assuming NO knowledge of the application)
- comparison screens/output from OE and FWD
- dependencies required for the recreate
Ensure that critical dependencies are available to GCD and/or are documented so they can be duplicated on GCD test/debug systems.
Configuration (e.g. you need to have this .xml file in that location)
Test Data (e.g. use company D200 and so on)
Preconditions (e.g. execute this business process to create the conditions in the database/application that allows this problem to be seen)
External Systems (e.g. User Management)
Specfic system, OS, HW...
- small, standalone 4GL example that recreates the problem
- specific location (filename and line number) of the 4GL code that fails and why
Creating Tasks¶
In Redmine, all work is a set of one or more "issues". An issue is the same thing as a "task" and Redmine makes no distinction. Tasks have a type which is Bug, Feature or Support.
Redmine supports multiple projects and sub-projects (projects that have a parent project). Work that is public is often done in sub-projects (e.g. FWD -> Bugs instead of in FWD itself). Work that is specific to a customer is usually done in that customer's project. If you are a customer opening a task that is specific to your application, it should be opened in the application specific project which you've been provided.
Some key points to remember when creating a new task:
- When creating new issues that have no scheduled start date, make sure to NULL out the start date field. The reason is that any task with a start date will cause the system to track it for inclusion in gantt charts and other project metrics. If something doesn't have a start date, then we don't want to track it.
- Newly created tasks should be left in the
Newstatus. - Unscheduled tasks usually should not have an assignee.
- Do NOT put any data in the description field for the issue. Just enter a useful subject. Then make an
Editto place whatever details are needed in the 1st task history entry. Using the description field for recreates and other technical information creates the situation where gathering all the information for a task/issue then requires processing 2 database tables (description and history) instead of a single table (history). - Do NOT make attachments in the initial issue creation screen. Use an issue
Editto add any files, images or other text. That way we always know where to look to find all details for an issue.
We have created 3 custom issue fields to allow us to track somethings that are otherwise missing in Redmine. Always fill the first 2 custom fields (billable and vendor_id) out for every new task. Use the case_num field when it makes sense. Details about the custom fields:
| Custom Field Name | Data Type | Purpose |
|---|---|---|
| billable | boolean | Set to true when the task is something that must be individually billed as consulting work for a Golden Code client. For most issues, this would be set to false, even though the work may be on a project for a specific client. Most project work is not done on a billable hours basis. Only tasks that are billed by the hour will have this set true. |
| vendor_id | list | We have encoded a list of strings from which to choose. Generally, this will encode for whom the work is being done. If it is something "internal", it should be "GCD". If for a client, then it is "external" work and should be set to the list ID that matches that client's name. If the task is a problem report/case associated with a 3rd party vendor (a supplier instead of a client), then that vendor (e.g. "IBM") would be set as the id. |
| case_num | text | This is a vendor-specific code that is used to track or cross-reference a specific case number in the client or vendor's issue management system. For example, when working on Acme tasks that are "cross-linked" to Golden Code's Redmine, we would put the Acme issue № into this field. |
Status Codes¶
The following task status codes are defined:
| Status | Meaning | Possible State Changes | Considered Active |
|---|---|---|---|
| New | A task that has not yet been worked/is not being worked. | Usually will shift into WIP to be worked or Feedback for more details to be provided. It can be Rejected or Closed if this is a duplicate or otherwise somehow invalid. | Yes |
| WIP | Work In Process (task is being worked) | Usually will shift into Review if the work is complete or has reached a phase needing review. It can be Feedback when more details to be provided. It can be Rejected or Closed if work shows this is a duplicate or otherwise somehow invalid. | Yes |
| Review | Work is complete enough to require code review or obtain other technical feedback. | Back to WIP if the task is not complete. Into Test if the all changes have been merged into trunk or are otherwise finalized. Very rarely, the review process might require Feedback or identify conditions that cause Rejected or Closed. | Yes |
| Test | Task is considered complete and the original submitter of the task should test the result to confirm. | If the testing confirms the task it done, it will be Closed. If some items remains open, then the task will be put into WIP. | No |
| Feedback | Work on the task is blocked until the original submitter of the task provides more information. | After enough information is provided, the task is put back into WIP. In some cases, it can be found that the task itself should be Closed or Rejected. | No |
| Pending | Work on the task is blocked until another task is complete OR until some external dependency is cleared. | After the dependency is resolved, the task normally is put into New or WIP status. | No |
| Hold | Work on the task is not planned at this time. Usually this is due to priorities and resources. | After this becomes a high enough priority to work, this will be put into New or WIP status. Or the task could be Rejected. | No |
| Rejected | This task will never be worked for some reason. The most common example is a Bug which turns out to not actually be a problem. | Unless this was set incorrectly, there is no expected state change. | No |
| Closed | This task is complete. | Unless this was set incorrectly, there is no expected state change. | No |
© 2004-2023 Golden Code Development Corporation. ALL RIGHTS RESERVED.