Introduction to the use of Components, PDI Sub-components and Labels within the JIRA PDI space
Due to the high volume of issues and feature requests, we needed a way to group these cases more fine grained.
One concept to help here is to work with components like Step, Job entry, Spoon / User Interface, Database etc.
For some of the components we need sub-components, especially for Steps, Job entries and Databases. To be as flexible as possible and not maintain this list when new steps are released, we decided to use a labeled sub-component field.
The convention for sub-components is e.g. using the internal ID of a step, job entry or database since this ID is unique and also the same when you are working with a localized version. More detailed conventions are given below.
This makes working with JIRA more easily and powerful. Here is an example: When you are facing an issue with the Modified Java Script Value step you want to search for existing cases that might help you. This is for some steps easier than for others since the cases are filed often with different descriptions for this step, you will find: Javascript Step, JS step, java script step and other variants and misspellings. With the search for the sub-component ScriptValueMod (the internal ID of this step) you can find all cases for the Modified Java Script Value step. Just try it with a search for the ScriptValueMod sub-component!
When we are developing or fixing something, this is also useful, since we can find related cases more easily and may fix them together.
The Heatmap for sub-components is also a nice tool to find popular issues and help product management to set priorities.
We are also planning to link a help button on each step to the documentation and we can link to all cases for a specific step.
Status as of May 2012: The defining of sub-components for cases is a continuously ongoing effort (we have actually around 2000 open cases).
JIRA users, who have special privileges, can help in this effort when you file new cases with the correct Component, Sub-component and Label or when you search for some cases and see they are not marked correct.
Upper and lower case: The sub-components and labels are (unfortunately) case sensitive when you look at them at the heatmap or enter them and get suggestions. When you search for them, they are case insensitive. Due to this, we ask you to use the exact internal ID (see below) and upper / lower case spelling (copy/paste is best).
Scope of Labels and PDI Sub-components
- Labels are valid in all JIRA projects.
- PDI Sub-components use the JIRA label concept but are only valid within the PDI JIRA project.
Selected components and conventions for PDI Sub-components
Conventions for Steps, Job Entries and Databases
Select the appropriate component (Step, Job Entry or Databases) and select the internal ID from the Plugin browser (since PDI 5.0 within Spoon: select Help / Show plugin information) or from the following location:
- Pentaho Data Integration Steps or Pentaho Data Integration Job Entries and use the ID column. (Most job entries are upper case and steps are mixed case.)
- It is also possible to use the latest internal definition file and look for the appropriate id section: kettle-steps.xml / kettle-job-entries.xml
- For most plugins: List of Available Pentaho Data Integration Plug-Ins and use the Unique-ID column. Actually this list gets transferred to the Pentaho PDI Marketplace over time and the <id> within a <market_entry> is listed in marketplace.xml.
- For databases, use the latest internal definition file and look for the appropriate id section: kettle-database-types.xml (All database IDs are upper case.)
Conventions for 3rd party Applications (e.g. ERP, CRM), Information Quality and other 3rd party vendor labels
Select the appropriate component and use the most common name, e.g. OpenERP. When there are spaces in the name, use underscores between the words, e.g. Human_Inference
Conventions for Concepts / Solutions
Select the Concept / Solution component and add a label that starts with a lower case q followed by an underscore: q_ for example:
q_autodoc, q_consolidation, q_ease_of_use, q_realtime, q_security, q_ui_consolidation, etc.
These are concepts and solutions that are handled mainly by the product management, but are open to use for other concepts & solutions.
[Whoever wonders why I choose the letter Q: It's a naming convention I saw and loved on midrange systems for system objects because very few words begin with the letter Q.]
All other Components
Normally you do not need a label for the other components. They are most times modules of Pentaho Data Integration like Spoon, Pan etc. and do not need further fine grained grouping.
Special Labels
There are also a few special labels that are handled by the product management:
Label |
Meaning |
---|---|
low_hanging_fruit |
Cases get this label when they look like 'easy and quick to fix' (hopefully) and this is used for prioritization of cases. |
patch |
This case contains a patch and gets normally higher priority. |