If you encounter technical software behavioral anomalies (bugs) while playing, visit the Task Tracking System. This page defines the terminology and workflow (task lifecycle) used to track tasks.

Note: The terms task, issue, and bug are essentially interchangeable.

The category field indicates to which part of the system an issue relates:

Notice that Protocol issues imply more than Common library updates, and should be used to particularly denote behavioral aspects of the client-server interaction, such as timing issues, coordination of actions, and actual messaging issues. Avoid using this category for library improvements, even if they are network related.

Note: Gameplay may include non-technical design issues as well as technical development (implementation/integration) issues.
Update: Until design issues are phased out of this tasking system…

Explanation of bug task type field:

Note: Design-based tasks may be phased out of this issue tracking system.

The status field represents a task's state in its lifecycle:

The lifecycle of a task begins as Unconfirmed or New. When the Assigned developer takes on the task, it moves to Researching, Coding, and to Awaiting Test. When released to test, the state moves to Testing, where the issue may be Closed. During Testing, however, any lingering issues with the task may push it back to Assigned state (for the developer to perform continuing research and coding until the task reaches testing once again).

Note: Since I'm the only one here right now (and Flyspray seems to have a problem with Assigned state not sticking), I usually skip from New directly to Coding. I fall back on Researching state when coding work is being postponed.

The severity field is subjective. These guidelines guide the use of the severity levels:

The priority field is subjective. These guidelines guide the use of the priority levels:

Note: Flyspray also includes Urgent, Immediate, and Flash priorities, which seems excessive. Urgent might be used to indicate something that absolutely positively must be accomplished as soon as possible.

Flyspray does not include any notion of frequency, which would (vaguely) indicate how often a bug tends to occur in practice. Frequency could be measured, for example, as high,medium,low or frequent,occasional,rare. Frequency would be set during investigation, in order to provide more information for deciding severity and priority (even a low severity bug may be deemed higher priority if it occurs frequently). This field would only impact Bug Report tasks.

Note: I'm planning to phase out this technique of subtasking. Tasks can have dependencies, as supported by Flyspray, but the practice of creating parent tasks for the sole purpose of containing subtasks is overkill (at this time). What's more, task “grouping” is often best represented by assigning a future release version.

A subtask is a task that represents some portion of another (parent) task. Create subtasks to break down a larger task into smaller units of work.

Flyspray does not yet have the concept of a subtask (all tasks are top-level, first-class elements). To represent subtasking, make the parent task dependent on all subtasks. The parent task cannot be closed until its subtasks are complete. This technique helps ensure several related tasks are completed together to fulfill the parent task. As a side effect, the dependency graph will show the relation of the subtasks to their parent.

This explanation of subtasks will be made redundant if/when Flyspray supports an explicit parent-subtask relationship.

There is no formal issue-to-revision integration. By convention, revision comments should start with the issue tracking ID like this: (#nnn,mmm,..)

Game design tasks may be likewise referenced in its documentation revision system.

Note: As stated above, game design tasking may be phased out of this process.

Flyspray does not seem to have any notion of Impact, Effort, or Risk. These elements would be specified in the issue tracking system as research-based estimates, used to aid in scheduling decisions.

Consequently (or irrespective of), I just wing it.

These estimates are independent. A task with high impact could affect several developers' work. A task with high effort may tie up parts of the code for some time. A task with high risk may not be an advisable undertaking depending on deadlines.

For example, repackaging Java classes can be high impact (import statements of all dependencies must be changed), but low effort (just file moving and basic search-and-replace) and low risk (strong typing is a wonderful thing). On the other hand, implementing a new combat artificial intelligence routine could be low impact (very isolated code changes), but high effort (difficult to get it right, thus taking longer to debug and test) with moderate risk (can fall back on previous AI).