Its all about them schemes

Last week we took a look at cleaning up your fields to help improve your system performance. So now we move on to our next Atlassian TAM suggested topic: How to standardize workflows and screens. But before we dive in…

Last week was amazing. I had a lot of engagement on this topic, and even had two more people come forward with requests for more topics to write about. I’m always up to do a reader suggested topic, so if you have something you want to see covered, let me know! It may be a few weeks before I can write on your topic (For once, it’s nice to have a backlog!), but I’ll definitely get to it. You can use the contact form on the blog’s website, or email me directly at

Anyways, lets get into it.

So, let me ask: Why would you want to standardize?

Fair question. This is going to be a lot of work, negotiation, and may come down to you telling them this is how it’s going to be. Why bother?

What’s the benefit that will make all this worthwhile? Well, the first benefit it helps teams within your organization work better together. If a person has to move from Team A to Team 1, they don’t have to relearn how to use JIRA. They’ll see the same fields and the same workflows. They’ll know how to use the tool as they’ve always have and be able to focus on getting to work that much quicker.

Secondly, It will help with reporting. With all the teams using the same workflows and fields, we have a consistent set of data across all teams with which to run reports and measure performance. While you should NEVER compare teams’ velocities to each other (as each team will value story points differently, therefore you will never get an oranges-to-oranges comparison), you can measure most other things consistently across the teams if they are all working from the same field set.

And the third, and I’d argue the most important reason to consider standardizing your schemes is your sanity. Look, there is only so much JIRA Admin to go around. If you are lucky, your organization has two or three of them to help out – but that’s usually for the largest organizations. Most small and medium businesses, it’s on you. Having standardize schemes stops you from having to play “What impact will this change have?”. You’ll know, and be able to get on with it that much faster.

But what about the exceptions?

Look. There will always be exceptions. A process or team that doesn’t adhere to normal business models. My Approvals workflow is such an example. But it’s your job to make it just that: An Exception. If you standardize your workflow, any change that is proposed by a team using the standard schemes should be measured on “How will this benefit the entire group?”. If it’s a benefit, it should be applied to the entire scheme. No breaking off a scheme to apply to a specific team. It’s all or none.

This, in and off itself, can help limit JIRA bloat. If a team has to defend why their change will benefit everyone, not just themselves, they will sometimes decide it’s not worth it.

So, where do I get started?

Honestly, I’d start with the screen schemes. And the first step is to talk with each and every one of your teams. Figure out what fields each one is using, and how they are using them. This will be time consuming – just a fair warning. But to do this successfully requires you to put in the work and really get to know your teams and how they work within JIRA.

Once you have that, sit down and compare your notes from all the teams. (You did take notes, right?) Find similarities, and try to get down to the fields you can get away with to allow as many teams to work as they already do as possible. Try to avoid fields that are used by only one team – opting instead to put that information in another field if possible, or the description. Take this time to use your test instance to make the changes. This will be both your testing and give you a way to demonstrate the change in a real way in our next step.

Now that you have your proposed standardized fields, this next step is probably the most important. Go back to each team, and present the new scheme proposal to them.

No, Seriously. Review what changes will impact their team specifically, and explain why you are making each change. Get feedback. Listen. Negotiate. Being willing to work with each team on this process is how you build buy-in, and it’s how you will make this process a success. Not everyone will be a 100% happy, and you may have to add some fields back in, but you can get them to a point where they can at least agree to the change. Again, I know this will take time, but having gone through this process myself, it is absolutely required.

So, you have con-census and buy in from your teams, and you have the changes ready to go in your test instance. You are now ready to push this to production..which in vanilla JIRA isn’t going to be fun. Without any plugins, you will need to manually recreate the new schemes in your production JIRA Instance, then assign all the appropriate projects to it. Or – you can use a tool like Botron’s Configuration Manager to copy over the new config as it exists from your test to production. Either way, I usually schedule a full change window for this during a relative down period for the instance (which invariably ends up being Saturday). No need having people try to work around you as you make these changes.

And that’s your Screen schemes standardized! When you are meeting with the teams, they may not understand why you are doing this. Stick with it – they will see the benefits eventually, and wonder why it wasn’t always like that.

But…uh…what about workflows?

Are you Forgetting something? Maybe you are,
Maybe you aren't - Are you Forgetting something? Maybe you are,
Maybe you aren't  Scumbag Brain

Yeah…workflows. I hadn’t forgotten about it – I was strategically putting it off. I promise!

My experience has been standardizing workflows is a bigger fight than screen schemes, which is why I chose to lead with that. People are willing to be flexible on fields – most people don’t use most custom fields anyways. But when you start messing with their workflows, you are messing with how they work. And yeah – that is part your job – but it’s going to be a fight. So start out with the screen schemes and build up some good will. That will make this easier.

With the Workflow schemes at least, you have the information at hand for each team. Teams are somewhat free-form in how they use fields, so you have to interview them first. But a workflow can only be used as designed. So start by looking at all the workflows for the projects you wish to standardize. Figure out the common points, and design a workflow (in your test instance!) that matches as many of them as possible.

Now that you have something designed, take it to those same teams. Explain to them what you hope to achieve, and demonstrate how the standard workflow you are proposing differs from the one that particular team is currently using. Go through the same thing with each team you did with the fields. Explain the benefits of everyone working on the same scheme. The object here is to build con-census from the ground up.

Look, I’m not going to sugarcoat it. People are going to disagree with you. Some are even going to do so passionately. Don’t make enemies of these people. If they care about how JIRA is being used THAT much, they are a person to have on your side. Figure out what their objections are, and figure out a way to address or otherwise work-around those objections. But show you are willing to work with their concerns, and they will be more willing to work with you.

Once you have all the concerns addressed and con-census built, schedule a change window and put it in place. You can do it manually, or by a plugin. Honestly, I keep harping on the plugin as an option as it eliminates some possibilities of you making a mistake. But if you are going to do it manually, at least export the workflow and re-import it into production, so you don’t have to worry about a mistake there.

And that’s it!

Look, this won’t be the easiest thing to do as a JIRA admin. People can be very passionate about how they work, and if you are seen as messing with that, they can get upset. But remember that they are upset because they do care, so if you can show that you are willing to listen and work with them, it should help.

So I know everything else in the world has been going a little crazy right now. I really hope you all survived the transition and ramping up your teams to work remotely. I’ve been stuck at home anyways while I recover from the surgery, but even before that I’ve been a remote employee for some time, so it still business as normal for me. I can write a post on tips and tricks from working from home, but it’s all likely advice you’ve heard elsewhere already, so unless requested I don’t have a plan to write on that topic. But if you are interested, let me know!

Don’t forget you can subscribe to receive new posts from this blog via email! To subscribe, just put your email in the form below this post! We also have an officially Unofficial Atlassian Discord chat. Swing in, ask questions, and see what’s going on!

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

How to train your Workflows

You know what? We’ve been a little system heavy the last few months. Lets try something different…

So, we all know JIRA workflows. They guide your issues through their life-cycle, apparently only know three colors, and otherwise just sit there, right? What if I told you that you can train your workflows to do tricks? It’s true!

Today we will go over some of the ways I have trained my workflows over the years, and when you’d want to use each trick. The ultimate goal here is to get you to see your workflow as an equal part of the issue life-cycle – that is to say not only as a faithful guide, but an active participant!

Some of these tricks will require a plugin to enable – but where so I will clearly mark them as such and give you a link to the plugin.

With that being said, let’s get into it.

Conditions, Validators, and Post Functions, Oh My!

So to get started, we’ll need to review the three parts of a transition: The Condition, Validator, and Post Function. Each of these are evaluated at a different part of the Transition execution, and therefore are able to do different things.


These are evaluated any time JIRA needs to see if you are even able to see that the transitions exists. On the surface, seems straight forward enough. If a user doesn’t meet the conditions, they don’t see the transition, so what tricks could we do with that?

Trick: Secret Cleanup Transition

So, here’s the situation. As a part of your workflow, you require certain information be filled in to close issues normally. For example, you require a fix version be assigned to a new feature or bug. This is because your users had a bad habit of just closing critical bugs that really needed to be fixed.

Which is great, but as time goes along, the project lead comes to you, saying they have too many issues that being honest, they won’t ever get to. However, you realize that because of the requirements, you can’t just close those issues. You obviously don’t want to get rid of the requirements, but you want to enable the Project lead to do their cleanup. How do you do this?

We can do this simply with one condition! First we’ll add an “All” transition to the closed state we’ll call “Cleanup” Then we’ll put a condition on it that says only Project Administrators can see this cleanup transition. This way we don’t open up the workflow to the abuse we’ve previously tried to stop, but we give the Project lead the power to cleanup when they need to.


Validators are similar to conditions in the fact that they evaluate whether a transition could occur. However, the key different is WHEN they do their processing. Conditions are evaluated before a transition ever occurs. On the other hand, a validator is evaluated during the processing of the transition.

One thing Validators are great for is that when they fail, they provide an error message. When a condition fails, the relevant transition just doesn’t show up. From experience, this usually leads to a lot of panicked questions from new people saying “I can’t close an issue!” This problem is avoided entirely if you use a validator instead. “Oh, I can’t close it because I need a Fix Version – cool.”

Trick: Written Approval

Note: Requires JIRA Misc Workflow Extensions

So, you have an approval chain workflow, but you want to be sure whoever approved it really MEANT it. Lets say this involves a P.O. process, so you want to know whoever approves it really meant you to spend that money.

This is easy enough with JMWE’s “Comment Required” Validator. To make sure the phrase is added as, we’ll add a conditional to evaluate the comment field.

issue.getAsString("comment") != "I Approve"

This is a bit counter-intuitive, but the condition is what makes the validator active in JWME. Here, the validator only ever validates if the comment is anything other than “I Approve” – which includes an empty string! Having the comment be “I Approve” disables the validator and lets the transition occur!

Post Functions

Post functions have no evaluation purpose, but are executed “After” all conditions are evaluated and things are ready to move forward. This gives you a chance to update fields, fire off internal events or web-hooks, or a myriad of other tasks. Most of the time when I’m looking to automate some function that is based on a workflow, Post functions are where I’ll look to first.

Trick: Auto-assign on transition

So this is great for any situations where a specific person needs to do something on a specific status….such as an approval chain. This lets you set it up to reassign the issue on demand without having the user remember to take that action. Very Handy!

To accomplish this, we’ll use the “Update Issue Field” Post function, select “Assignee” from the drop-down, then select the last radio button to specify which user you’d like to transfer it to.

There are additioonal post functions from various Apps that will do the same thing, but you can do this with just vanilla JIRA Functionality.

Workflow Properties: The forbidden technique

Okay, so maybe I’m being a little dramatic…

Transition and Status properties are a powerful technique for customizing how your workflow behaves. However, they are somewhat hidden, dubiously supported, and tricky to get right. Basically, if you do choose to go this route, you will be pretty much on your own, with your only company being whatever articles you can google. By the way, Hi googlers! Welcome to the blog!

In general, I don’t really like to use Workflow properties, but there are some cases where they can’t be helped. One use case I’ve used them for is to limit who can reassign an issue in a given status…which being honest I learned from another blog.

To access the properties screen, select your transition or status of your choice, then click “Properties”

This will open up another screen where you can see a list of that item’s properties. By default there should be none.

Trick: Re-order the Transition buttons

So lets say you have a project lead that is a little…particular. They want the most relevant transition to be the first button, with anything else being second. But you can’t re-order the Transition buttons, right?

Well, I wouldn’t be writing this section if that was the case. We can use a property on each transition called opsbar-sequence. This is a setting that will allow us to specify which transition gets priority on the issue view screen. To do this, we’ll need to add the key “opsbar-sequence” to each transition, along with a unique value. It is recommend you increment the value by 10’s on each transitiono, so if you add more transitions later, you have a place to put them between existing transitions

Remember, in this arrangement, the lowest opsbar-sequence value will go first, with each increasing value following afterwards.

You are now a workflow trainer!

My goal here is to get you to think about different automations you can enable for your users. It may seem trivial to you, but if you can save them 10 seconds on each transaction, that can really add up over time. And you don’t have to stop with this list! Look over what post functions, validators, conditions, and yes even properties you have available, and keep an open mind when you get these unusual requests.

However, a word of caution. If you go crazy with these, you may find you have too many workflows and actions within workflows to manage. It’s best to think of it like candy. Every once in a while is fine, and can make you feel happy for a bit. But too much too often can make you regret it before too long!

As always, don’t forget to subscribe to be notified by email of new posts! You’ll find a signup form at the bottom of the post. Also don’t forget to check out our Atlassian Discord Chat! It’s still ramping up, but I’m always happy to see people getting questions answered there!

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

Creating a Custom Workflow

There are times as a JIRA Admin that you will get an odd request. Something that is well outside your strong-suit, but also something you can’t (or shouldn’t) say no to.

This happened to me at one point at my last job. the CFO of our small company came to me and my manager, saying that he had been told by our CEO that we needed to clean up our purchase order process, and that the CEO had told him to use JIRA to get it done.

Now, JIRA – strictly speaking – isn’t a finance tool. But, JIRA is a tool that can manage a process, and this was a process. So I told him what I’d need and what time frame we are looking at, and off we went to get it done.

I should note that I was working with a JIRA Software instance. There are some different ways to handle this in JIRA Service Desk, but I was limited to the version I was managing at the time.

Today’s post will be looking at the workflow that resulted from this, and how I came to the workflow.

Getting to know the pain points.

My Mom used to tell me a story about when she was in served in the U.S. Army. As a Sergeant, she developed a reputation as a “fix it” sort of leader. Put her in charge of a group, and she’d get them working together properly in no time.

One day, her Commander put her in charge of the company’s logistics group. Now my Mom specialized in Missile repair, not Logistics, and didn’t have a clue what they even really did. When she brought her concerns to her commander afterwards, he said this. “The team knows logistics, but you know how to lead. Trust them to know what they need to do and work with them to make sure it gets done.”

That story has stuck with me for some reason, and I find it oddly helpful in my role as a JIRA admin. You don’t need to know every little facet of how your teams do what they do, you just need to know what their pain points are and work to make sure they can get stuff done. If you become known as a problem fixer, your teams will let you know what problems need to be fixed.

Such as it was here. At University, finance was the one class that caused me the most problems. To me at least, it all seemed rather arbitrary, requiring lots of memorization. It’s the one class I had to work hard at to succeed in. But, as a JIRA Admin, I didn’t need to know every facet of Finance, just what were the problems they were trying to resolve.

So I sat down with the person the CFO loaned to me for this purpose. My first question was “What are the biggest problems in the current PO Process?”

I was told we had a paper-based process that required gathering actual signatures to move forward. However, as these papers were spread around multiple desks throughout the office, no one had any visibility into what had already started the process, what any one item was waiting on which signature, and double-ordering items because of this lack of visibility was a common occurrence.

Aha! There was the problem, and it’s one I knew I can fix with JIRA. With that, we move forward.

Drafting the workflow

With that discussed, I started asking about what the process should look like if it was to work as expected (ignoring the pain points mentioned earlier). I like to do this in front of a white-board – preferably with a few color options available.

As he goes through, I start building out a flow chart of what he is describing. It’s important to note that this won’t become the exact workflow, but it’s a way to work together to describe what the process currently is to come to a common understanding. So with these two bits of information, I go back to my desk and start working on the workflow.

What he described was a process where first the Manager would sign off on it, than the VP over that group. After VP approval was gotten, the Finance office would review it (usually the CFO himself). Here, depending on the price tag, the Finance office could approve it outright, or forward it on to the CEO for a final approval.

After all the needed approvals were gotten, it’d then be ordered, but no one was tracking when we received it, and lost items were also a thing that happened occasionally.

So with this, I came up with the following workflow:

It’s a bit spaghetti, but it works!

So, what’s going on here? Well, one of the biggest pain points was that no one had any visibility on who a particular PO was waiting on. As such, I made the approval chain status “Pending X Approval”. But rather than use actual names, I made them positions so I can re-use them (this will come up later).

I also simplified this by making the re-assignments automatic for most of the workflow. This is done using the “Update Issue Field” Post function, with the field being “Assignee” and the Assignee being selected directly.

As an added level of security, I also made it where the current assignee was the only person who could transition a status, using the “Only Assignee” condition:

This may lead you to the next logical conclusion: What’s stopping a user from assigning something to themselves and moving it forward anyways? Well…this actually happened. I had over-looked this in my first version of this workflow, and someone (who I won’t name) reassigned something pending CEO approval to themselves and moved it forward. Lets just say it’s NOT a good morning when you get to work with the CEO waiting at your desk.

There is a solution here, however. If you highlight a status in the workflow editor, you will see a “Properties” option. These status properties allow you to tweak how an issue behaves at a granular level. Much respect to the J-tricks blog for showing me what options are available and how to do this.

Here I would put the first person with the ability to reassign to the user that was auto-assigned the issue. The second person was myself. Being a small company, there wasn’t a tools team, so I didn’t need to worry about making this a group. If you do however, you’d use “” as the Key and your group name as the Value. Be aware that this puts a magnifying glass on you, so people will know if you abuse the system yourself. Also, if you have more than one user or group keys, you will need to numerate them like in the example above. Otherwise JIRA will get confused. Odd, but true.

This works well for one group, but as you may know, JIRA doesn’t really know or care who a particular person’s manager is, or who their VP is. This honestly caused me the most problems.

However, the solution I came to was to have multiple workflows, one per group, and assign them to different custom issue types name for that Group. So we initially had “IT Purchase Orders”, “Facilities Purchase Orders”, “Engineering Purchase Orders” Issue Types. This allowed each workflow to be tailored to each specific group and track through their management chain accordingly. This is why using generic Statuses was so important earlier, as it allowed the same statuses to be used by all of these workflows.

After the approval chain, I added a couple of more statuses describing the wait for it to be ordered and delivered. This was to track an issue all the way to make sure it was actually delivered as expected – as this was a stated problem as well.

One last note I’ll make on this workflow. I added an open step at the beginning to give the requestor one last chance to review everything before sending it into review. This also gave me a status to send things back to if an approver didn’t want to reject a request, but felt it still needed more information from the requestor. However, this caused some requests – especially when I first put this process in place – to sit in this opening status because it was never actually sent for approval. You can – as an option – send things from issue creation directly to Pending manager approval, then just have an offshoot status for requesting more information that goes back into Pending Manger Review. I personally don’t like this option, as I like the “Are you sure?” approach to submitting requests. But, on the whole sending items directly for approval is technically sound and a valid approach.

Closing thoughts

Now, this wasn’t the whole project. I still had to go through three more meetings about what fields were needed, but that is another blog post altogether…probably something along the lines of “What to do when you and your users disagree.” But before I go, I wanted to thank my previous company and my former Manager. I actually had to get her approval to be able to share this story with you, as well as her encouragement that lead me to originally start this blog. So, until next time, this is Rodney, asking “Have you updated your JIRA Issues?”

Using JIRA For a Job Search…well…that’s a thing.

So, I’ve been quiet here for a bit. There’s a reason. At the end of July, I was laid off. I’m told it had nothing to do with my performance, that is was just a matter of us loosing a major client and the numbers not adding up.

Either way, that puts me squarely back in the job market, which has been my focus for the past month. However…

The JIRA Angle

The thing about a job hunt is – you gotta keep on it. It’s on you to follow up with an HR representative and figure out whats going on. Don’t be pushy, obviously, but be engaged. To that end, it was quickly getting to the point last week where I couldn’t keep track of all of it in my head.

Job hunting is also a project – and I happen to know a good deal about a highly customizable Project tracking tool. So, I fired up my personal JIRA instance, patched it up to 8.3.1, and created myself a new project: JobHunt (JOB)

This was a custom project from the ground up. It was as much a task to keep my skills sharp as it was to solve a practical problem. But I’ve also realized it’s a great way to show just how flexible JIRA really is. So I’m going to break it down for you, so if you also would like to do something similar, you can.


This project uses a simplified workflow. The reason I chose that style of workflow is simply the fact that it isn’t a terribly complicated affair. I don’t have to show parallel work on my end per application/recruiter, so there isn’t a need for subtasks, but at the same time I’m not trying to do automatic reassignments. Basically, a simplified workflow allowed me enough flexibility without becoming a burden.

Each status is a step in the process. As usual with such workflows, I like to use the past tense, with each issue in the project moving to that status when the appropriate condition is met, such as I’ve completed a phone screen with a given Recruiter or HR department, I’ve done at least one Interview with a given company, etc.

I understand this can probably be refined further, but the best way to see those refinements would be to use it, and in the past week of use those possible refinements have yet to reveal themselves to me.

Screen and Fields

The Screen and fields have a number of custom fields that I’ve added to the project to help with retaining pertinent information on each position. In detail they are:

  • CompanySingle Text Field – This is fairly self explanatory…it’s the company the position is with. In cases where it is a recruitment firm on behalf of another company, I’ll put this in the format of “Company (via Recruitment Company)”
  • Description – This is where I’m storing the Job Description. No need to create a new field when one is serviceable.
  • Job Location Label Field – This is a label field describing where the position is located. This saves me on retyping, as the location is usually only a handful of possibilities, but lets me add more on the fly without having to modify the field or reindex
  • Job URL URL Field – A URL field for a job listing so I can refer back to it later. It’s more of a “For your reference” field, and normally wouldn’t make the cut for my criteria for a custom field, but it’s saved me a lot of re-googling.
  • Job ID Single Text Field – a Field for storing a job ID number. This is helpful if I am contacted by mutliple recruitment agencies for a single position.
  • Recruiter/ContactSingle Text Field – Okay, so confession time, I often have a hard time remembering names. So – put a field for it. Then I can remember it was Sarah that I was speaking to about that position at that one company.
  • Contact Phone NumberSingle Text Field – places to remember the number for my Contact for a given position. It’s also meant to cut down on looking up information.
  • Contact Email Email Field – Does the same thing as the line above. If possible, I’d prefer an email rather than a phone call, so I usually give priority to this field
  • Last Contact Date Field – When I last heard anything on this position. This is useful for knowing a) when to reach out to a contact about a given position, or b) when to give up on a position should I not be contacted at all about it.
  • RateSingle Text Field – Simply put – what I’ve put down as my desired pay for a given position, or what the company is offering.

A note here, On all but the most intuitive of Custom fields, I’ve added a descriptor text. This is always a good idea, as even though it may be clear to you right now what a field is for, it may not be as clear to a user. Because this is my personal instance, I was a little more informal here than I would be on a corporate Production instance, but even then I still felt the need to be consistent with using them.


The Dashboard is a rather simple affair with four gadgets. Starting in the Upper Left, we have a Created vs Resolved gadget, then two Filter Result Gadgets, and then finally a two-dimentionsal Filter Stats Gadget. These are powered by three Queries. The first one is a simple query, which gives us everything not listed as done in the project.

project in (JobHunt) AND status not in (Done)

This is used on the two left most gadgets. The thinking here is the only time I care about one of these being done is when I accept a position, which would invalidate the whole reason for this project to exist. As such, beyond noting why I didn’t get a position, it doesn’t need to be on my radar, and thus I let it fall off my Dashboard.

I use the Created vs Resolved more to track how many positions I’m applying to each day. I’d like to apply to at least one per day, so this is more for personal goal tracking.

The Two dimensional Filter stats gadget is more for personal reference. I obviously want as many positions to move forward as possible, so this helps me see where they are as a group and encourages me to keep checking back on the various positions.

The second query is to list those that I need to reach out to.

project in (JobHunt) AND "Last Contact" <= startOfDay(-7) AND ("Contact Email" is not EMPTY OR "Contact Phone Number" is not EMPTY)

Basically, what this is doing is returning every position I haven’t heard back from in the past seven days, but only those that I’ve listed a contact phone number or email address for. It doesn’t help me to try to reach out to someone who I don’t have contact details for, so this is to help the list remain relevant.

The last query I use on this list is those I’ve applied to in the past seven days.

project = JobHunt AND createdDate >= -7d

This is again to help me visualize my goal of applying to at least one job per day. Now I don’t actively search on the weekends, but there are days I do get more than one position, so the average is usually better than one a day including weekends.

The Kanban Board

The final piece I want to look at is the Kanban Board. It’s fairly vanilla for the most part, with one column per status in the workflow above. The two areas I customized it, however, are two that don’t get alot of attention: the Card Layout and Card Color.

For the card layout, I wanted to be able to see the relevant information at a glance. As such, I’ve put the above three fields on it – Who is it with, where is it, and when was the last time I heard about it. This maxes out the card, but the Summary already answers “What it is”, and the “Why” isn’t something that will fit on a card anyways.

I also decided to use the card colors to help me identify how long it’s been since I heard back on a given position. This is more an aesthetic choice, but it does help me know what’s good and what’s in trouble.

Final Thoughts

So – I don’t know if this is going to help me in the long run – but as a JIRA Admin, I do need to keep my skills sharp, so it at least does that. I’m going to try to post here more often, with my next post going to be on how to install JIRA to a clean linux instance. Until then, I’m Rodney, asking “Have you updated your JIRA issues today?”