Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 6 Next »

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:

  • Help Desk for support issues (example: Crazy Robots for requesting lab equipment maintenance)
  • Process JIRA for tracking units of work within a process (example: Tracking one set of libraries in LCSETs)
  • ELab Notebooks, where individuals can track their experiments from design through conclusions. (example: DEV)

JIRA has several building blocks that are often referred to when trying to convey information:

  • Issues – the unit of work that we want to track (ex: one library set, one flowcell, one experiment). Interchangeable with ‘ticket’, as in submit a help ticket. JIRA gives us the ability to create custom issue types, for example each type of library has its own issue type.
  • 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.” DEV is 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 specific process step the issue is currently in.
  • Resolution – A resolution is different than statuses in that this field tells you the ultimate result of an issue. Issues are finalized with a ‘closed’ status, whereas some could have a ‘Completed’ resolution and others would have a ‘Reworked’ resolution. Both will be closed, but resolution tracks how it got there. This specific example is from the flowcell tracking project when we want to rework failed flowcells.
  • Transitions – the pathways to advance or return an issue to a particular status
  • Workflows – the predetermined set of statuses and transitions an issue goes through.

 

 

 

 

 

 

 

 

 

A full list of LabOpsJIRA projects and their keys can be found here. 

 

 

  • No labels