Development Workflow

This page summarizes the development workflow that was agreed upon at the ParaView Summit. The goal of this workflow is to organize ParaView development process making it easier for various projects contributing to ParaView to coordinate with each other as well as the release cycle.

The bug-tracker serves as the central tool that drives the process.

• A project is created for every customer/development team contributing to ParaView.
• Every task is must be reported as bug. When a issue is reported, if the issue is originating from a particular customer, the reporter will assign the issue to a particular project or leave it unassigned. If a customer gets interested in an issue, he can assign the issue to his project.
• A issue then moves over different states as described in the figure below:

• The bug reporting page also gets simplified as follows:

State Transitions

• (new) ==> backlog: A bug enter the bug tracker in the "backlog" state. This is default state indicating that the bug has been noted.

• backlog ==> expired: If a bug has no activity for 6 months, it automatically gets marked as expired. An issue in expired state indicates that there was no enough interest to get the bug resolved.

• expired ==> backlog: If the reporter or some other developer or manager gets interested in the issue, he can always re-open it by moving it to backlog. There it will again have a 6 month timeout to be addressed or will be timed-out.

• backlog <==> todo: Managers (and Developers) can periodically select a subset of bugs from the backlog to be addressed in the near future (say month or so). These get moved to the "todo" state. Of course, they can always out those issues back to backlog if deemed necessary due to workload or changed priorities. Ideally, there should not be more that 3-5 bugs per active developer for a project in the todo state.

• todo <==> active-development: When a developer starts working on an issue, he moves the bug to the "active-development" state (and back if he decides to postpone the work for later). "active-development" state helps everyone get an idea of what the developers are actively working on.

• active-development <==> gatekeeper-review