JIRA Issue Management

We use JIRA to track feature requests, bug reports, improvements, and other development-related work in Vixen. This page will explain the structure and layout of some of the JIRA tickets, the processes we go through when working on them, and any other related notes.

The JIRA bug tracker can be found here. If you have a question that is not answered on this page, please ask!

The purpose of JIRA is to keep track of any outstanding issues relating to Vixen. These might be bugs with existing functionality, or requests for new features (or improvements to existing ones). Please try and make sure that we track ALL work that needs to be done in JIRA, as it lets us keep a record of it. So often there is a bug report posted on the DIYC forum, or the Dev mailing list, which goes unanswered (or unsolved), and gets forgotten. Please try and make new tickets for everything; they’re easy to close if needed!

JIRA Tickets

JIRA tickets have a number of fields that can be used to help describe and categorize an issue. Some are mandatory, some are useful, and some not as much. When creating a ticket, ensure you complete the items in the following list with an asterisk (*).

Issue Type (*): Can be one of five values:

Epic: To track larger projects that are underway. Do not use.

Bug: Something in the software does not work as described or expected.

Improvement:An existing feature could be improved with this work.

New Feature: This does not exist in the software, and would improve it.

Task: used to track miscellaneous development work, not strictly tied to the software functionality (eg. code cleanup, research, etc.)

Summary (*): one-line title of the issue.

Priority: Defaults to ‘major’, not often changed. Can change if it’s particularly important or not.

Component/s (*): one or more areas of the software that this relates to. Ask for new ones if needed.

Affects Version: only used when reporting a bug.

Fix Version: This should be added when the code is merged and will be included in the next version.

Assignee/Reporter: Who is working on it, and who reported it.

Description/Attachements (*): include as much detail about the problem here. If needed, attach config files, sequences, logs, etc.

Task Group: We tried to use this to track a rough timeframe of when work would be done. Finding it too hard to predict, so we’ve stopped using it.

Epic Link: which ‘project’ of work this falls under, if any. Leave empty unless you’re sure of what it should be.

Epic/Project Tickets

The ‘Epic’ tickets are used to track large chunks of work, as there may be a number of bugs or requested improvements related to one particular field. For example, there’s many improvements to the sequencer to be considered when we revamp the sequencer, so these are all grouped together to make it easy to track them, review them, etc.

We have a number of Epics are the moment. Some are just to collate small related problems, and others are to section out large chunks of work that have many facets that need considering. Presently (Jan 2014), these are:

VIX-373: Display Preview Improvements: many small additions/improvements to the preview, as well as any big new features (eg. possibly a new interface to set up a 3D display view, or hardware acceleration of the preview window, etc.)

VIX-375: Runtime Data Format Changes: collates the work we need to do to improve performance of the software. In 2013, shows used too much memory and CPU, and were often slow to load in the scheduler. This can be improved with changes to the internals of the core framework/engine.

VIX-376: Serialization & Data Persistence Improvements: there are many problems with the way we store data on disk (configuration, sequences, etc.) Size, readability of the XML, migratability, portability between computers. This attempts to address anything related to that area.

VIX-377: Color & Level Handling: there have been some bad design decisions made related to the way colors and levels have been used in the software. (Library operations, data formats, discrete colors, interfaces, etc.) This can all be improved.

VIX-378: Controller Improvements: We can improve the controllers quite significantly. One idea is to separate the idea of a controller ‘bus’ from a controller ‘device’, to help users model it more accurately. Another is to add the concept of a ‘smart controller’ which takes more than just raw command values.

VIX-384: Scheduler Improvements: Any and all improvements/bugs related to the scheduler.

VIX-385: Display Setup Improvements: Anything related to the way the display setup works — new features, bugs with the new setup form, addition of filters/wizards/helpers, etc.

VIX-404: Display Setup: positioning and ‘views’: This attempts to address the group of work related to improving the data we have available about a display, in relation to element physical locations, order, and the presentation plane to a viewer.

VIX-411: Data Inputs into Vixen: These ideas have been floating around for a while, and haven’t been firmed up: anything related to Vixen reading in data somehow, and acting on it or recording it (eg. MIDI inputs, live triggers, etc.)

These should help to make it easier to track work on a single ‘topic’. Since we often get developers that are interested in one particular area, this will make it easier to point them at a single point to manage the work being done.

Lifecycle of a Ticket

The lifecycle of a Vixen ticket can be seen below. A full explanation of the process follows.

Note that to be able to do a bunch of these functions, you need to have appropriate permissions — you need to be a ‘JIRA developer’. If you are unable to take tickets or progress them through the workflow, ask the dev group, and we can change your permissions.

A ticket is created (eg. a user reports a bug, requests a feature, or a developer makes a ticket for work he’s been doing). It may be assigned to someone specific if relevant.

Someone takes it and starts working on it (even if it’s just reviewing it, or reproducing the issue). They assign it to themselves, and change it to “In Progress”. This helps prevent multiple people duplicating work.

They finish their work on it. If it has not been fixed or completed, leave a comment explaining what has happened with it, and put it back to “Open”. If work has finished on it, mark it as “Work Complete”. If code has been committed, make sure it has been pushed (ie. available for someone else to get to). Leave a comment explaining where to get the code (eg. “Finished and pushed, available on my master”).

The maintainer reviews it. If it’s OK, they will merge it into master, and progress it to ‘Testing and Review’. If there’s some concerns about it, the maintainer comments or asks, and reopens the ticket. It then goes back to the developer to review, fix, etc. (go to step #3).

Someone else (not the original developer, and hopefully not the maintainer) reviews and tests the ticket. This should have an automatic devbuild that they can use for testing. If they’re happy with it, it’s done and they “Resolve” it. If they’re not, they “Reopen” it. (go to step #3).

The ticket stays “Resolved” for a while, until we do a public release. At this point, all ‘resolved’ tickets are used to build up release notes (to track what work as been done), they can be edited to include what version they have been fixed in, etc. Once the release is public, these tickets are “Closed”.

Note that this process does not have any documentation steps integrated into it. This can be added if most people feel it’s needed (once we figure out the documentation system, process, etc.)