Pentaho Case Tracking Processes

JIRA is the system that Pentaho uses to track issues related to the Pentaho projects.

JIRA Case Field Descriptions

FieldDescription| Project | The project is the first thing chosen when you create a new issue. This categorizes your issue into the chosen project. |

Issue Type	The issue type identifies the issue as a bug, improvement, new feature, or task.
Summary	This should be a brief, descriptive statement identifying why the topic of the issue.
Priority	The priority level of the issue. Priorities range from trivial to blocker.
Due Date	When is issue completion due?
Component(s)	Each project has a list of components associated with it that helps further categorize issues.
Affects Version(s)	What versions (of this project's deliverables) does this issue affect?
Fix Version(s)	What versions (of this project's deliverables) was this issue finally fixed in?
To Be Fixed In Version(s)	What versions (of this project's deliverables) are we slating this issue to be fixed in?
Assign To	Who is assigned to work on / own this issue?
Community Assignee	If a community member has contributed this feature/fix, or is involved in the issue, list them here. They will need to have a JIRA account in the system to appear in this list.
Reporter	The individual that reported the issue. Will default to the person logging the issue. But can be changed.
Browser	What browsers can this issue be reproduced in?
Operating System	What operating system can this issue be reproduced on?
Environment	What other information do you know about the environment that this issue occurs in?
Description	Give the full repro path, feature or improvement specifications and other details about the issue.
PM Status	For PM Use – is the feature/fix committed?
Support Customer	The customer associated with this issue – only appears in the Support project.
Support Customer Contact	Contact information associated with the support customer – only appears in the Support project.
Support Level	Level of support this customer has purchased - – only appears in the Support project.
Resolution Method	How did this issue get resolved? Dev-resolved means that the developer deemed the issue resolved. Reporter-resolved means the reporter deemed the issue resolved. Independently-resolved means that the case was assigned to an independent reviewer and tester for resolution.
Needs Review	Check this box if this case requires a code review.

Case Tracking Workflow

Default JIRA Workflow

The Default JIRA Workflow is the workflow that is used for all new projects in JIRA that are not development projects. Today, these are the Internal project and the Support project.

Step NameLinked StatusTransitions| Open | Open | Start Progress >> In Progress
Resolve Issue >> Resolved
Close Issue >> Closed |

In Progress	In Progress	Stop Progress >> Open Resolve Issue >> Resolved Close Issue >> Closed
Resolved	Resolved	Close Issue >> Closed Reopen Issue >> Reopened
Reopened	Reopened	Resolve Issue >> Resolved Close Issue >> Closed Start Progress >> In Progress
Closed	Closed	Reopen Issue >> Reopened

Workflow For the Pentaho Development Group / Projects

All development projects follow the customized workflow described below. The custom transitions accommodate the development group's work process.

The Coded transition should be set when the code for a feature, improvement or bug is coded. There is no assumption being made as to whether the code is checked in to SVN or not. At this point in the process, if the Needs Review checkbox is checked, the case can be optionally assigned to another developer for code review. The Needs Review checkbox can also be used by the developers to designate issues for which the code is complete but is awaiting review.

Once the code has been reviewed (if necessary) and checked-in, the case should be transitioned to Ready for Test. This transition happens when the user clicks the Review and Check in Issue transition.

And finally, once tested, the case can be moved from Ready For Test to Resolved (if the case is resolved) or to Re-Open Issue if there are problems after testing. If resolved, the Resolution Method should be set to the appropriate value now.

Step NameLinked StatusTransitions| Open | Open | Start Progress >> In Progress
Resolve Issue >> Resolved
Close Issue >> Closed |

In Progress	In Progress	Stop Progress >> Open Coded>> Coded Close Issue >> Closed
Coded	Coded	Review and Check In Issue >> Ready For Test
Ready For Test	Ready For Test	Resolve issue >> Resolved Re-Open Issue >> Reopened
Resolved	Resolved	Close Issue >> Closed Reopen Issue >> Reopened
Reopened	Reopened	Close Issue >> Closed Start Progress >> In Progress
Closed	Closed	Reopen Issue >> Reopened

Internal Projects vs. Public Projects

In JIRA, projects are protected by one of two security schemes. The Default security scheme allows all issues in a project to be viewable by anyone and editable by internal employees only. The Pro security scheme restricts issues in the project to be viewable and editable only to members of the group "jira-developer", which represents internal Pentaho employees. Projects such as Support, Pentaho Pro, and Internal Projects are protected by the Pro scheme. The others fall under the Default scheme, making them public projects for all intents and purposes.

Our direction is to eventually open JIRA up to the community for submitting cases, commenting on existing cases, voting and watching issues of interest, and possibly allowing them to participate in the workflow. We will need to define our workflow and field permissions more granularly to allow the community in, which is coming soon.

The Support Project

The Support Project is unique in that the cases that are created in the Support project a.) contain support information (READ customer info) and b.) are duplicated out into the other projects if it looks like the case will turn into a bug, new feature, or improvement in a deliverable project.

Should a support case need to be addressed in a deliverable project, follow this process:

CLONE the existing support case.
LINK the cloned case to the original support case.
MOVE the cloned case to the deliverable project it belongs in, changing the issue type to a type that is appropriate – new feature, improvement, bug or task.

The support information cannot live outside of the Support project, so the cloned case will lose the customer information as soon as it is moved into the deliverable project. The link to the Support case cannot be seen by anyone who is not an internal Pentaho employee, so the support information is still well guarded.