• Download
• Release notes

I'm very excited to announce a new release of Worklog Assistant. This new release features a JIRA worklog and timesheet report built into the app. See the video below for a demonstration. The timesheet answers the question: what the heck did I do this week?

Why is this useful?

Keeping tabs on your own activity is useful because it helps you realize how much of your time has been spent on your core job activities. If you feel that you are spending too much time on unimportant activities or your job description is changing, you now have some proof to ask for that raise. You can't improve what you don't measure, which is something I try to live by.

There are also a few other changes so be sure to see the release notes. If you find that something could be more efficient or obvious, please let me know.

Thanks for your time and have a good week!

If you do this, you will be asked to synchronize filters. If you choose not to synchronize all filters, then a cache built up while you were working will be used. This is usually enough.

While you are working offline, all the JIRA worklogs will be collected in the "Pending Worklogs" tab so remember to submit them once you are back online!

In addition to these changes, Worklog Assistant now supports Ubuntu 10.04 LTS as the base. Support for 8.04 LTS has been dropped.

Check out the release notes for more.

Thanks for your time!

When I initially put out the custom scripts feature in the latest release (documentation), I was a bit worried that no one would be able to see it being useful. No one had asked for it except me! Upon release, I got some very good feedback but nothing that made me too confident.

Today I was pleasantly surprised. Doing the usual customer support rounds, I came across a feature request from "t" which was a bit particular to his/her requirements: the ability to copy a specific JIRA field to the clipboard. I usually try and keep from implementing such specific requests because it clutters the application.

So the first thing I suggested, just because I thought t's workflow was similar to mine, was to do what I did and use custom scripts to do all the checking in/out of source control.

S/he had other things in mind:

sudo apt-get install xclip

and than:

echo $JIRA_Key | xclip

perfect!!! thx

Just to clarify, t realized that s/he could install xclip (the first line) and use a custom script to copy it to the clipboard using xclip (the third line). I could only think of one response:

Haha, that's freaking awesome!

When I added custom scripts, I really wanted to empower the users to do stuff that I wouldn't or couldn't for whatever reason. I'm glad to see that promise fulfilled in this little way. Great job "t"!

• Download
• Release notes
  

This new release has a few new features and improvements. One is an improved update experience which has been a long time coming! There are also some JIRA worklog and time tracking-related improvements. You can find more in the release notes linked above.

The biggest, something I've been itching for myself, is the capability to extend Worklog Assistant by adding your own custom commands. In a nutshell, you can attach and execute a shell script against any JIRA issue and Worklog Assistant passes down the issue fields as environment variables. For example, the key is passed down as the "JIRA_Key" environment variable. Custom fields are also passed down and spaces are replaced with underscores.

You can see an example of a custom script I use in the screenshot below (configuration dialog is pictured):

This script optionally creates and switches to a new branch. You can also see the custom scripts in the context menu for the selected issue (right-click on selected issue):

This is useful for me because I usually create a new branch for each issue. This extension makes it more likely that I will keep up that very good practice.

Like it? Hate it? You can send me feedback about this or other things, I'm always happy to hear it.

Happy time tracking and have a good week!

JIRA time tracking allows you to log work against issues. In fact, many issue tracking systems now support logging work against issues with varying degrees of functionality, but my happiest experience is with JIRA. My product, Worklog Assistant, is a hassle-free time tracker for JIRA so this is a topic near to my heart.

Why would you want to measure and manage your time? The most fundamental reason as an organization is to improve whatever service it is you deliver. For example, if you are a consultancy, you want to make sure the best and highest margin consultants have as many billable hours as possible. If you are a software development organization, you want to be sure that your star developers are not mired in meetings or spending too much time working on legacy components. As a support organization, you need to know which customers are using the most support hours so you can sign them up for the Platinum support contract.

But most people really hate time tracking. I still do, believe it or not. It is notoriously difficult to track your time without the help of a robot.

So what service do I deliver? Is it a time tracking application for JIRA? Not exactly. I deliver something that makes it easy to track your time directly in JIRA. A subtle difference! If something is possible but annoying, it's still not going to get done properly. Some anecdotal evidence from my testimonials page:

I'm happy to report that the logged hours across my team doubled since we started using your tool. They're also much more accurate since the tool is completely objective.

Here is another one that just came in as I was typing this blog post [Note: This blog post was written in January]:

Your product has made my daily management considerably easier.

Exactly my goal. Thank you dear users!

At the end of last year, I felt it was important to review what I could do to serve my current and future customers better. I believe one of the ways that I can serve them better is by spending as little time as possible doing administrative things because that keeps me from improving the product. Administrative work is usually never completed, only obsoleted. I made it a point to record tasks like manual testing, planning new releases and building new releases. I turned to JIRA's new query language to help me decide what was taking the most time:

And man, was I surprised:

The above image shows that making new releases took 3 full days out of the whole year. That is 3 days I do not fix bugs, add features or talk with customers. To put this in perspective, I spend up to one week a month on Worklog Assistant. So nearly 10% of the time I spent developing Worklog Assistant was put into making new releases. Completely unacceptable. All the other tasks above were one-time jobs. That is, once the work was done, I usually did not need to revisit that task.

The question, to me, was obvious: how can I modify my process to reduce or eliminate the time I spent making releases? I reviewed the process for making a release:

1. Merge development into main line
   
2. Build the software: manually check out on Windows and Linux VMs and execute build and test scripts. Do the same on Mac build machine.
   
3. Wait for about an hour.
   
4. Fix any issues.
   
5. Repeat until no more build issues.
   
6. Generate updated website and upload all build artifacts
   
7. Make release announcements
   

Believe me when I tell you that I am completely embarrassed by the above procedure. Although I never made a mistake, it was quite easy to do by checking out the wrong branch or forgetting to update the working tree. Building and uploading artifacts was all automated, but I had to manually start and babysit the process. That was what ate up the most time!

The solution is probably obvious by now: I needed some build machines.

Fortunately, buying some good build machines was within the budget. So as soon as they got here, I set them up immediately using TeamCity. I wondered how long it took:

The above image shows that setting up the build machines took me around four days. Hmm, oops? Not quite! Remember, this is a one time investment and I just had really bad luck with installing Ubuntu (had to do it twice with two different versions to get some VMs to work.)

Compare the old process above for making an official release compared to the new process:

1. Merge into main line of development
   
2. Make release announcements

As some of you may know, I have an active beta program. You may also be actively using the beta. If there is a bug fix or experimental feature, I need to get these out as soon as possible to the people who are most interested. And believe me, if there is a bug fix, I want to get it out to the user yesterday!

Perhaps unsurprisingly, I rarely made beta releases last year because it just took too long. Not anymore. Here is my new process:

• Merge feature or bug fix into beta branch

That's it.

In January of this year alone, I've been able to make more beta releases than I was able to in 2009 altogether. And I can tell you that the users are happy.

They are happy because I can prove that I am paying attention. They are happy because they can give me feedback on improvements they can touch.

In the same month, I had a relative torrent of really great comments and feedback in my inbox directly related to the support I am able to provide thanks to the beta, which was previously languishing. I know I've made the right decision.

You can't improve what you don't measure.

How true! So how did time tracking with JIRA help me serve my customers better? Simple:

1. Tracked all my tasks in Worklog Assistant
   
2. Found the least efficient task using JQL: babysitting builds
3. Purchased and configured build machines: no more need to babysit builds!
   
4. Reduced average time required for a release to 5 minutes down from an hour: more frequent beta releases with bug fixes and new features
5. Customers like being able to use features and fixes as soon as possible: happy customers!

I had no idea I could improve customer satisfaction just by time tracking. What can you improve by tracking your time in JIRA?

• Download
• Release notes

A new release is available. From the last release announcement on this blog (for 1.0.1355), there are some minor improvements which you will probably not notice but I hope you are inexplicably a little happier when using Worklog Assistant. I know I am!

One you may notice is that the time tracker for a JIRA issue is now automatically started when you start the progress and progress is automatically started when you start the timer.

In addition, there are a few bug fixes that probably won't affect most people but annoyed the people who found them:

• Automatic JIRA worklog rounding is delayed until submission time
  
• "Unknown error" caused by JIRA's version of Axis sending different types
  
• JIRA worklog entry window no longer discards incorrect data
  

Big thanks to the reporters for helping me debug the "Unknown error" in particular.

Keep 'em coming.

Well, that's all for now. Have a good week!

Update: A new version has been released due to a bug affecting certain workflows with the auto-timer/progress starting.

• Download
• Release notes

Yesterday, there was a notice of a security breach at Atlassian resulting in the theft of some passwords. There were a number of things that combined to cause this problem and we are promised more details. I applaud Atlassian for having the guts to be open about the whole thing. I must say I thought it was a phishing attempt from the get-go.

The best thing for you to do in a case like this, whether you were affected or not, is to re-evaluate how you manage your passwords online. If you fall into any of these categories, you were likely running around changing passwords like mad:

• You have one password for all websites
  
• You have one password for all business websites and another for all social websites
  
• You have one password for X class of websites, another for Y, another for Z, and so on

There is one more step you can take: LastPass

LastPass is quite literally the last password you will ever choose to remember. It uses a single passphrase + client-side encryption to store your passwords and can generate random secure passwords for all the sites you use. That means that you can potentially have a different password for every website you use without having to remember each one.

Is it ultimately secure? No, nothing ever is. But because of the techniques used, even if all their database was belong to some h4ckrz, it should be very difficult to break the encryption.

However, it does mean that the "last" password you use must be incredibly secure. Really secure. Unguessable by brute force or even by your closest relations.

So if you were caught in yesterday's email bomb, you may want to consider it. I do wish LastPass was Open Source so that the security could be verified, but you can verify most of the client side stuff yourself.

Disclaimer: I'm a random dude on the Internet so do your own research :)

A new release of Worklog Assistant is available:

• Download
  
• Release notes
  

This update includes a new feature: worklog rounding. Typically, when you log work in JIRA, Worklog Assistant is as accurate as possible, to the second. This results in reports containing odd numbers like 5.833 h which inevitably end up as odd dollar amounts. However, in some situations, you may not want this behaviour.

For example, due to some contractual issue, you may instead want to log 6 hours. Conversely, if the above was 5.45 h, you may instead want to log 5 hours. A "banker's rounding" for time tracking, if you will.

The main control for this functionality is pictured below (found in the "Pending worklogs" tab). I'm not quite sure if the wording helps or hinders, but please let me know either way! As you can also tell, Worklog Assistant will now consolidate all your pending worklogs for a given issue into one. This means that you can apply the rounding to the sum of your pending worklogs, rather than individually, which is probably much closer to what you want.

In any case, I hope you find this new functionality useful. You can find more information in the documentation.

Happy time tracking and have a good week!

User feedback is critical to making your application better. I absolutely crave feedback from users. However, it is probably also one of the trickiest things to accomplish. Feedback helps me guide new features and heavily informs upcoming versions.

My application, Worklog Assistant, just helps with JIRA time tracking. In the big picture, it's really quite boring to most people. So if it does the job, most people are content not to say anything. I thought that I should get more people to offer feedback, for better or worse. Maybe there are some obvious things I am missing (hint: there are!)

So, some time in January, I tweeted about an upcoming (very unscientific) experiment. At the time, I did not mention details to anyone. As you can guess, it had something to do with gathering more feedback.

At the top of Worklog Assistant's main screen, there are a few icons as seen below:

The little blue speech bubble has a tooltip which simply said "Send Feedback". Using Thunderbird's filtering capability, let's see how much feedback I got through this button over a seven month period:

That is a grand total of 8. E-i-g-h-t. Wow. According to Google Analytics, that is from a total of about 200 unique visits, for roughly 4% over all of 2009. I repeat: ALL OF 2009! Initially, I thought maybe no one cared (sniffle.) But then I sat back and thought about it from a user's perspective. Do I really want to "send feedback" for any apps that I use? The answer: ABSOLUTELY NOT!

Generally, I want to have a conversation with the authors of the application. And this has been my exact experience when talking to users. So I thought about it for a little bit. Eventually, I settled on changing the blue speech bubble to the following:

Why "Shout!"? I'd like to say this was based on some intuition but basically, I wanted something that people would click on which had some vague relation to its intended purpose and was enough to interest people. I released this change around the end of January and didn't really bother to check into it until a certain someone reminded me. Of course, I tweeted about the "experiment's" success!

Here are the cold hard statistics:

• 170 unique visits to the target page in ONE MONTH due to this simple change. Compare this to 200 for the whole of 2009 and part of 2010.
  
• Thunderbird says 12 new questions/suggestions as a result, a rate of 7%

The bottom line here seems to be that not only did I get more click-through, but the target page encouraged more people to initiate participation!

But there is another side effect. Some people that had never participated before now started to comment and vote on things they were interested in. So I think I've comfortably got a lower bound for new participation.

Conclusion

There is none. This is not a proper statistical test. But I think there is something there. What do you think?

Nitpicks and clarifications:

• But this is not scientific! Yes, I know.
  
• But you don't know whether it was the presence of the text or the value of the text which caused the greater traffic! Actually, yes I do (within the boundaries of being unscientific to begin with.) The first screenshot shown above was preceded by exactly the same icon but with "Send Feedback". Miserable, miserable click through.
  
• But you could have had a 1000-fold increase in customers in that month! Oh, how I wish that were true.
• But it could be because February is after January! Yes, you're 100% right. It could be.
  
• But you said all of 2009 and 7 months! You liar! Well, I took a shortcut: The 7 months was the entire time the button was active so technically, I'm not lying.

Well I hope that was interesting for you. It certainly was interesting for me. Big thank you to "dermike" for reminding me to check into my experiment. You made my day.

Feel free to nitpick some more.

I am in need of some brave souls who are willing to be part of a small experiment. I suspect most readers of this blog will meet the simple criteria I have for participants which is why I posted here.

The purpose of this experiment is to get an idea of what your work on the computer is like, in terms of context switches and away time. This will be represented in a simple graphical way which you may find useful even after the experiment. You can see an example at the bottom of this post.

All I would require from you is to let the application run in the background and send me a screenshot of the state of the application when you are done your work day. You can do this as often as you like but at least once at the end of your day is requested.

If you are interested, please email me and include:

• Your primary job function (web developer, technical documentation, etc)
  
• Your operating system
  
• Whether you currently use JIRA or another project management tool
  

I look forward to hearing from you!

A new release is available:

• Download
  
• Release notes

This release brings a couple of major bug fixes as well as some minor new features. The rest of this post discusses one of the new features. Your life may be made more complete by reading it.

JIRA's standard workflow is a little something like:

1. Enter issue
   
2. Assign to user
   
3. User starts progress
   
4. User tracks time against issue
   
5. User resolves issue (progress implicitly stopped)
   
6. Issue is verified and closed
   

If you're anything like me, you probably forget to do steps 3 and 4 regularly. Worklog Assistant helps you track your time in JIRA by being an interface you can go to to accomplish 80-90% of the work you need to do with your JIRA tickets. Indeed, if all it did was let you log your time worked, it probably would not be very helpful. Some of the things you can do from the Worklog Assistant interface:

• Issue filtering and free text search
• Workflow transitions (stop progress, resolve issue, etc)
• Commenting on issues
  
• Issue operations (edit, move, etc)

Typically, when you start tracking time against an issue, you are starting progress on the issue. However, JIRA has no mechanism that I know of (besides writing a server-side plugin) to perform the "Start Progress" transition when you log work.

So now, Worklog Assistant will helpfully execute the "Start Progress" transition the first time you log work against an issue. This means you never have to remember steps 3 and 4 again! One less thing to remember makes for happy people and happy people can only be good for your project.

With that, I bid you good day and hope this coming week sees you make a lot of progress!

Now, if only Worklog Assistant could do my work for me...

The first release of the new year is available:

• Download
• Release notes

This release includes some bug fixes and a new feature. See the release notes for details on the bug fixes.

Some users and myself noticed that a lot of the time, as soon as we turn off a timer, we published the worklogs to JIRA right away. So my workflow would be a lot like:

• Start timer
• Do some work
• Stop timer
• Command-P for publish (or CTRL-P on Windows/Linux)

Now you can click the "Automatically submit worklogs" option in the redesigned configuration window as shown below:

Whenever a worklog is added to the pending worklogs, it is automatically submitted. Any errors that occur are reported to you otherwise you can continue on your work. This is a good way to ensure that you don't forget to submit your worklogs to JIRA. As it turns out, this is a common occurrence. Hopefully this lets you work with a bit more security on that end of things.

Well, that's all for now! Have a good week and happy time tracking :)