JIRA: Looking out for motorcycle riders since 2013

It’s no secret from this blog that I’m an avid motorcycle rider.   About 9 months ago, the tech chair and I moved all of our club operations onto JIRA and Confluence using Atlassian’s generous community licensing model.  In fair disclosure, I do work for Atlassian and blog a fair amount about JIRA at work on blogs.atlasssian.com.    It’s also no secret that I do love JIRA.  It enables all sorts of teams to do great things together: from software development teams to motorcycle riders.  I’ll be doing a few blogs here explaining how we use JIRA and Confluence to make our lives easier.

Motorcycle riders are an interesting bunch.  Sometimes we love to ride together and hang out.  Other times we choose to be alone.  It can be very freeing to be on the open road alone to clear one’s head or just enjoy the day out on the bike.  Here in California you can ride to some pretty desolate places and still be within a day’s ride of the Bay Area.  Riding alone has some special benefits.  You are alone.  You can do what you want. You can do it when you want.  You can even do it how you want.

Why track rides?

However, riding alone has one major drawback.  You are alone.  If anything happens out on the road, you are alone.  Will anyone know where you are?  If so, will they know if you may need help?  I’ve done some pretty long rides alone well out of cellular range.  We needed an automated system to help check up on those who were out on the road alone.  If a rider doesn’t check in, then JIRA will alert the board via email that someone has gone missing.  We can then proactively take action.  I’ll show you how it works as we go along.  A ride has a very simple workflow that we were able to model in JIRA.

Configuring JIRA

How does it work?  Anyone in the club can log a ride plan in JIRA using a simple link from the club’s Confluence dashboard:

We’ve got a range of technical skills in the club so I wanted a direct way to create a new issue in JIRA.  JIRA supports creating issues directly with links.   I used the link format:

https://example.com/jira/secure/CreateIssue.jspa?pid={my_project_id}&issuetype={my_issue_type_id}

How do you get the issue type id and the project id?  Go to the issue type config and hover over the links to edit the issue types.  You’ll see the issue type id in the status bar.  Project ids are the same way.  Links to the right pages are below.  Just add your JIRA server location instead of example.com.

https://example.com/jira/secure/admin/ViewIssueTypes.jspa

https://example.com/jira/secure/project/ViewProjects.jspa

Issue types and custom fields

To keep things tidy, I created a new issue type called motorcycle ride.  I added some custom fields like stating location and ending location to the motorcycle ride issue type.  I also created a new JIRA project for the ride register.  I used an issue type scheme so only motorcycle rides can be created in the ride register project.  We use JIRA’s custom fields to ask for things like starting and ending points, start and end times, and a Google maps link if they have one.  I wanted to have all the information for the rider in one place.  We also use the JIRA Suite Utilities plugin from beecom.  It provides a location field that renders the start and end points right inside of JIRA!

This ticket then serves as the single point of contact for that ride.

JIRA Notifications and alerts

The other plugin that makes this system work is the Notification Assistant for JIRA by Riada Labs. You can configure that plugin to send email in a time based fashion using JQL queries.  The big benefit to using this plugin is that you can schedule notifications and send them to users outside of JIRA.

I set up three emails using the Notification Assistant:

• An email to acknowledge that the ride has started.
• An email to note that the ride is expiring in 1 hour.
• An email to the club’s board that a rider has not checked in.

To use the plugin each notification has two components: a notification and an email template.

Setting up a notification

I need a notification set up for each type of email I want to send.  Each notification has a recipient, a schedule, and a JQL query to run that looks for issues.  When an issue matches the query, email gets sent.  For more details, check the documentation.

In my example I’ve set up three JQL queries to match up with the three emails I’d like to send.

• Ride is starting: type = “Motorcycle Ride” and resolution is EMPTY and  (“Ride Start Time” > now() and “Ride Start Time” < 65m)
• Ride is expiring soon: type = “Motorcycle Ride” and resolution is EMPTY and  (“Ride Finish Time” > now() and “Ride Finish Time” < 65m)
• Rider is missing: type = “Motorcycle Ride” and status = open and “Ride Finish Time” < now()

Why the complex JQL on the first two entries? All the queries run hourly, so I only wanted each ride to evaluate once to generate an email.  I use 65 min so I know each ride will evaluate at least once.

If the recipient is the reporter, the email will only have his or her rides in it.  The plugin is smart enough to send a custom email to each person that matches the query.  The same logic applies to other user fields.  What’s truly awesome is that we can send email to a mailing list outside of JIRA.  When a rider is missing, JIRA mails the club’s board so we all are on the same page. See the email tab for details.

Setting up the email template

When the Notification Assistant sends email it uses a configurable template.  Whenever sending email always make it clear to the reader why they are getting that email.  In this case, there were three different rationales for why I was sending email.  Thus I wanted to use three different email templates.  Let’s take a look at an example email using the expiring soon template.

Also, take the time to configure the issue fields that get sent in the email.  Less is always more. The email is designed to be a vehicle to get to the issue, not the issue itself.  The more conversation you can keep inside of JIRA and out of email, everyone benefits.

Ride On!

JIRA helps us stay in touch when riders are not reachable. Should someone need assistance, JIRA keeps a record of a rider’s intended plan.  Since we store each member’s emergency contact in JIRA we can easily engage the right people should someone not report in on time.  We also can use the system for group rides to ensure that everyone checks in at the end of the day.  A simple kanban board shows who is on the road at any given time.

JIRA does for us equally well as it does for teams at work.  JIRA keeps everyone on the same page so that the organization is more efficient.  Hopefully we don’t have to escalate ride when someone doesn’t check in.  It’s better to be prepared than not.