In practice, like any other organization, we have limited bandwidth for puttering with tools, so teams tend to piggyback on the experimentation of others. Two tools for bug tracking are currently used most widely: Trac and RedMine. So naturally my project team looked most closely at these. They are both free open-source solutions that have been stable for about 4 years.

Image courtesy of San Diego State University; © 2009 Lee Passmore Family

There are, of course, many other bug tracking solutions. There are even many other free open source bug tracking solutions. Bug tracking is the kind of itch that lots of people think they can scratch better than the next guy. The kinds of features that developers and managers find especially helpful include:

• email integration–so that people don’t have to go to the tracker unless it’s absolutely necessary.
• access control–the more nuanced the permission structure, the better.
• custom fields–the opportunity to make the tool conform to your organization’s use, and not the other way around.
• reports–what some people call “dynamic documentation.” Also important is the ability to sort by custom fields.
• customizable workflows–fancier tools allow for ticket routing choices, reminders, escalations, and vacation or time-away re-routing.
• integration with the version control system of choice.

Other considerations might be internationalization (Unicode support), the difference between a hosted or installed solution, and what costs might masked by the label “free open source” tool. That is to say, when is free not so free? I recall Karen Schneider highlighting that question a few years ago at Code4Lib by putting up a slide showing free cats vs. free beer. (I see she’s been talking about it again more recently.)

A final factor may have more influence than many of the others, and that is the weight of inertia: the sheer reluctance to allocate precious project time to converting from one tool to another. Even though there are often automated ways to migrate tickets from some systems to another, many of us dislike this process.

So, I was surprised by the response I got at a recent demo of RedMine to a group of Trac users. The main thrust was that RedMine did everything Trac did, and then some. They liked the Gantt chart and calendar views that come with RedMine, for example. And, we are in the process of adopting Mercurial source control management software as a standard tool, and RedMine has native support for this, whereas Trac support requires a plug-in.

The bottom line is that it looks like some Trac-to-RedMine conversions are in the offing, and my team is adopting RedMine. Perhaps we will move toward a defacto standard after all!

Courtesy of Pomona Public Library

You are probably in good company. I suspect there are lots of Service Level Agreement (SLA) templates available online for the very reason that many people prefer to relegate this work to the back burner. And, to be fair, there certainly is a category of SLA that can be treated as “repeat business,”  with little customization needing to be done for each new iteration.

If you feel this way about SLAs, I’d like to try to convince you otherwise–that the SLA is, in fact, a unique opportunity for one or more very interesting conversations.  I hold this view for several reasons. Many technology groups in Library Land are only now beginning to develop an understanding of what it takes to provide a genuine production-level service to their end users. This means that prior to negotiating an agreement about what production services might entail, managers and the technology staff must do some thinking, planning and discussing among themselves. They may even need to put some infrastructural changes in place.

So, the first interesting conversations are the ones you have even before you talk to those you serve. You have to answer questions like:

• What kind of services are we ready to provide, under what circumstances?
• When we say “available,” what do we mean?
• How do end users report problems, and how does problem escalation work?
• Where will we test fixes and enhancements while production services continue to run?

Courtesy of Oxnard Public Library

If you are in a co-development arrangement with a partner, the SLA may become one of the key frameworks for working out the nuts and bolts of that relationship. The SLA can actually open up into something more like a hybrid SLA-collaborative work agreement, where you have an opportunity to document the understandings you have with one another about code ownership, location of the code repository, tool and documentation conventions, and so forth. This can also be a place to document any processes or structures you want to introduce for joint change management.

So, take a new look at SLAs. As the record of a conversation, they can be a very useful tool for you.

A Library IT Department Head said to me last week, “Techies are weird, you know?” Since he said it about himself, I couldn’t exactly disagree, but I actually believe we can all sound incomprehensible or, worse, willfully uncomprehending to each other. So how do we work together?

I’m going to have a little fun and make an admission here, which is that I’m a sucker for big picture showtunes. I’m thinking here of those fabulous song and dance productions of the 1960′s, and I have one in particular in mind: Oklahoma! There is a wonderful scene in which the orderly, settled down farmers butt up against the dashing, out-of-control cowboys. A wise old woman enters from the back and says,  “Aint nobody gonna slug out anything!”

And that rousing song “The Cowhand and the Farmer should be friends” follows. The chorus is “Territory folks should stick together!” Now, I’m not going to assert that all project managers are farmers, nor are all developers cowboys–not by a long shot! But we do sometimes see ourselves on the opposite end of some spectrum.

One of the trickiest times this comes up, I’ve found, is over the question of the project plan itself. And, when I say “project plan” here, I am really referring to the task list with resources, time estimates and interdepencies baked in. A working game plan, if you will, not the full blown set of project documentation.

When you work with a technical lead on a project, you want to build the strongest partnership you can to enhance the chances of success for the project. Interestingly, strength in this case means some letting go of control. The first place to practise this is with the task list. Have a good conversation at the outset of the project about how the two of you want to track progress. Here are some of the questions you will want to ask each other:

• What are the high level technical milestones?
• It is useful to both of you track these in the overall project plan? How will that work?
• Will the techinal manager be tracking technical tasks in a separate plan? If so, can you view this plan? Do you want to?
• If the technical team is adopting an agile approach, what role can you serve? (Here’s an article about the challenges traditional project managers face in fitting into agile teams*).
• If you are going to track technical tasks in the overall project plan, can you choose the tracking tool together?

It’s worth taking the time to sort through these issues with each other. You have things to learn from one another, and the project has a lot to gain from your successful relationship. After all, territory folks should stick together!

*You may need to create a free account on gantthead to access this.