Access Keys:
Skip to content (Access Key - 0)

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:

  1. CLONE the existing support case.
  2. LINK the cloned case to the original support case.
  3. 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.


This documentation is maintained by the Pentaho community, and members are encouraged to create new pages in the appropriate spaces, or edit existing pages that need to be corrected or updated.

Please do not leave comments on Wiki pages asking for help. They will be deleted. Use the forums instead.

Adaptavist Theme Builder Powered by Atlassian Confluence