Issue Tracker (Redmine) Implementation Update

In a previous post, I talked about how we chose our issue tracker and then our implementation. Unfortunately, at the time, we had some trouble getting staff to use it so the team had strategized on how we might improve uptake.

Getting Staff to Use It

Our team

Within the team, it’s been working well though there is definitely room for improvement. In particular, reporting issues for documentation purposes not necessarily reported by someone else. So reporting an issue that they encountered and fixed themselves, but might be encountered again, especially if it’s institution specific (and not something you can just search for online). Related to that, is making greater use of the wiki for documentation.

Finally, I would like to see the team use the news area to report any updates that other team members might want to know about, but isn’t announced to the staff. For example, when I update the website’s theme and change it enough to change the version number, I’ll stick that in news.

General Staff

I briefly talked about the strategy in the previous post, but the basic idea was to go forward with getting people to use the tech help form for all projects. They can obviously still email us if they just want some advice and what not, or call us for immediate support.

We held a couple of information sessions for staff, where people posed some good questions, such as the ability to cc someone (which isn’t possible through the form, but we can add watchers in Redmine).

The general response has been pretty good though I’m not sure how often our team has been pushing back if they get an issue by email.

The System

For the most part, I’ve been really happy with Redmine. It was so quick to get going and the email integration worked right out of the box. There are only a few things that are missing or we haven’t managed to get working:

  • LDAP (our settings aren’t working though we’re not sure why)
  • creating issues on behalf of others or being able to change who reported it (think this might be implemented in the future, but have been adding as watchers in the mean time)
  • sending a copy of the issue to one or more email addresses
  • only allowing Anonymous users via email cron job
  • one team member asked about the ability to send reminders for open issues not recently updated

Conclusion

The two most important things for the project seemed to be strategizing to get staff on board, and having an easy workflow. The fact that everything after the initial reporting is through email has been a key factor in getting staff uptake. Communicating the change and the reasons along with providing sessions for them to ask questions seems to have made a fairly big difference as well.

Hopefully, things will continue to go smoothly and continue to improve.

Published by

Cynthia

A librarian learning the ways of technology, accessibility, metadata, and people

Leave a Comment

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s