Hitachi Vantara Pentaho Community Wiki
Child pages
  • Pentaho Case Tracking Processes
Skip to end of metadata
Go to start of metadata

 

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.

  • No labels