Versions Compared
Version | Old Version 19 | New Version 20 |
---|---|---|
Changes made by | ||
Saved on |
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Originally developed for tracking software development and bugs, JIRA is flexible enough to be adapted to any process that follows a workflow. It is a powerful collaboration tool that allows us to follow processes across and between platforms, enhancing information dissemination at the Broad. (And cutting down on email!)
Due to JIRA’s customizable nature, we’ve been able to develop different projects for multiple processes at the Broad including:
- GP software support
- Lab automation asset/request tracking
- Product order tracking
- Production sample batch tracking
- Lab notebook for development experiments
JIRA has several key objects:
- Issues – the unit of work that we want to track (ex: one library set, one flowcell, one experiment). Interchangeable with ‘ticket’. JIRA gives us the ability to create custom issue types for easier queuing in the lab.
- Project – the highest level of groups of issues in JIRA. Every issue must belong to a project. Each project must have a unique key, and this is how people most often refer to an issue. Example – “I did an experiment looking at density, which is described in DEV-905.” DEVis the key for the Process Development project.
- Fields – the areas within an issue where data is captured. For example, “Summary”, “Hypothesis”, or “Number of Samples”.
- Status – The state the issue is currently in. (e.g, "Closed", "In LC".) Super customizable based on issue type - for example an instrument has a "Down" state, and LCSETs have a "Ready For Sequencing" state.
- Transitions – the pathways to advance or return an issue to a particular status. Lab automation is increasingly transitioning tickets automatically based on deck events.
- Workflows – the predetermined (by the lab and LIMS) set of statuses and transitions an issue goes through.
- Resolution – Issues are finalized with the ‘Closed’ status, but resolution tracks how it got there. For example in the Cell Line Factory project, one issue is one cell line. A 'Closed' CLF ticket for example could have a resolution of 'Terminated' if the cell line did not grow, or 'Validated Tumor' if the cell line was validated as a tumor.
We have three main production JIRAs (known as instances) in use in the Genomics Platform.
- LabOpsJIRA (labopsjira.broadinstitute.org) - Our main work horse for tracking most lab production processes as well as lab automation inventory and request tracking.
- CRSP JIRA (crspjira.broadinstitute.org) - Structured similar to LabOpsJIRA, but tracks processes within our more tightly regulated Clinical Research Sequencing Platform (May show up as link broken if you don't have permission to view.)
- GP Informatics JIRA (gpinfojira.broadinstitute.org) - A more 'traditional' JIRA, used for requirements tracking, bug tracking, support requests and feature requests for our Informatics teams. See their confluence page here.
Each Jira has a production and a development instance. LabOpsJIRA has a special integration instance that we use for testing against LIMS changes.
Production | |||
Development | LabOps JIRA Dev | GP Dev Jira | CRSP Test Jira |
LIMS integration | LabOps JIRA Test |
Panel | ||||
---|---|---|---|---|
| ||||
Official JIRA documentation (External link) |
Panel | ||||
---|---|---|---|---|
| ||||
See page: Genomics Platform Atlassian Applications |
Panel | ||||
---|---|---|---|---|
| ||||
A full list of LabOpsJIRA projects and their keys can be found here. |
Granting access to JIRA (Admin Use)
Adding new Illumina Instruments to JIRA (Admin Use)
Updating Instrument ticket summary (Crazy Robots) (Admin Use)