Using Redmine¶

Using Redmine

Introduction¶

The FWD project uses this Redmine system to track bugs, track feature requests, participate in forums, access documentation and otherwise manage all public and private work related to the FWD open source project. This page helps users understand how to use the Redmine system.

Public, read-only access is provided to some areas of the system. You will need an account if you want to submit a bug report, submit a new feature request, post to an issue's history, post to a forum or access non-public portions of the system.

Self registration for this system is currently disabled because spammers/scammers are using bots in an attempt to create Redmine accounts. To obtain an account please contact register@goldencode.com. Only authenticated requests from a real person will be granted.

Projects¶

The Redmine system organizes all work in "projects". Each project can have its own users, its own issues/tasks, its own wiki pages and crucially, its own visibility (or invisibility) to the public. It is important to create tasks and look for tasks in the correct project.

Some projects like FWD (and its sub-projects) are public, which means everything in them is visible to anonymous visitors from the Internet. If you have anything confidential, do not post in one of those public projects. You can tell that a project is public when it is visible to you without signing in to the Redmine system.

If your organization is working with Golden Code (GCD), you may have a private project dedicated to your work. Anything posted in that project is safe and can only be seen by those at GCD or who have been explicitly added as members of that private project. Any confidential information can be posted in a private project. If you don't have such a project but wish to establish one, please contact fwd AT goldencode.com.

When you first log into Redmine, you should see a drop-down list (combo-box) in the upper right corner of the screen. Its initial value will be "Jump to a project..." (or the equivalent, if you've selected a different language).

Expand that list and you should see FWD and its numerous sub-projects. If you select one of these, you will be in the public area of the site. If you have access to one or more private projects, you will see them in this drop-down list. Select any project to navigate into that area of the system.

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 -> Base Language instead of in FWD itself). Work that is specific to an organization is usually done in that organization's project. If you are a member of an organization opening a task that is specific to your application, it should be opened in the application specific project which you've been provided. For more information, see Where to Create Bugs.

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 an agreed/allocated start date, then it should not appear in those charts.
Newly created tasks should be left in the New status.
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 Edit to 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 Edit to 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 custom issue fields to allow us to track things that are otherwise missing in the standard Redmine issue headers. 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.
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 could put the Acme issue № into this field. Warning: if you have a private project and are reporting a bug to GCD, you can only set this field at the initial creation of the task. Any edits after that time must be made by GCD.
env_num	text	This allows encoding of an environment name, which might be the name of the site or customer that is associated with an issue.
production	boolean	This is a flag to mark an issue as one that is being seen in or relates to a production environment.
reviewer	User	This is the list of people that are responsible for providing advice and who will review the results of the task before it is tested or merged.
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.
version_reported	text	The version of the related project in which the issue is caused, recreated or which the report is related to. If this is a feature request, this is the version of the project in which the feature is requested.
version_resolved	text	The version of the related project in which the issue is fixed or in which the feature is provided.

Reporting a Bug¶

The following information is required when reporting a defect:

Description of the behavior or result which is a problem.
Clear and repeatable recreation instructions. These must be written assuming NO knowledge of the application.
Comparison screens and/or output that differs from OE and FWD. These must be clearly labeled to identify the source system for each screen/output.
If this is a compatibility issue in FWD, one of the following:
1. A standalone 4GL program (or a small set of related 4GL code) which demonstrates the defect. This is PREFERRED and will greatly speed up the delivery of a fix.
2. The program (and if possible line number) of the 4GL application code where the problem manifests.
Version Numbers
- FWD revision used for conversion.
- FWD revision used for runtime.
- If OO4GL is in use, the skeleton version used during conversion.
- If the ADE/Possenet code is used during conversion the ADE/Possenet version.
- 4GL application code version.
- OE version that was tested and shows the difference.
If more than one runtime type is associated with the application, that type should be reported:
- Swing/Web GUI
- WIN32/NCURSES/Swing/Web ChUI
- batch
- classic/PASOE appserver agent
- classic/PASOE REST
- classic/PASOE SOAP
- classic/PASOE Webspeed/Web Handler
- ABLUnit/OEUnit
Dependencies required for the recreate (all applicable). Ensure that these 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 XYZ and so on), this may require a specific database dump.
- 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. connect to a REST server at URL ABC)
- Specfic system, OS, HW, child process, library or other environmental dependency.

Please DO NOT use the "Description" field of the "New issue" form. The recreate and other information needed about a defect should be in the first history entry. History entries are added by clicking the "Edit" link located at the top (and bottom) of the ticket. Leave the "Description" field empty and put anything to describe the bug in the first history entry.

Where to Create Bugs¶

If you have a private project associated with the bug, that is often the best place for it.

If a problem can be posted with recreate details and discussion that is not confidential, then it can be created in a public project. As an open source project, we like to be as transparent as possible, so most of our development is discussed in those public parts of the site. Practically speaking, however, sometimes it is easier to manage all customer tickets in customer-specific, private projects. It's safer for the customer as well, since there's less of a chance of accidentally publishing private information.

There are sub-projects of the FWD project which are specific to functional areas of FWD. If you know your issue is related to one of these areas and your bug can be posted in a public project, then it is best to create the bug in one of those sub-projects.

As a last resort the you can create the bug in the FWD » Bugs project. This is a holding area for bugs that have not yet been properly categorized.

Priorities¶

Priority	Definition
Immediate	* The system has completely failed and is no longer able to process data. * A Defect that affects the entire system or one critical function. * Integrity of data is at risk.
Urgent	* The system has a serious malfunction of an essential business function. * Data entry or access to data is materially impeded on a limited basis.
High	The system has a serious malfunction of a business function.
Normal	A non-essential problem in the system where users can continue to use the system and/or application, or a workaround is available.
Low	A problem in the system that can not be classified as Immediate, Urgent, High, or Normal including cosmetic issues.

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

Watchers¶

The author of a ticket will receive email notifications automatically when history entries are added. If you want other users to receive the same notifications, add them as watchers to the ticket. You can do this either when creating the ticket, or later from the "Add" link in the "Watchers" section in the menu bar on the right side of the screen. The creator of each project and possible one or two others at GCD are watching everything in the private projects automatically, but for the avoidance of doubt watchers need to be added explicitly.

TODO: How to pick watchers by functional area in FWD and by point of contact at GCD.

Project

General

Profile

FWD

Wiki