The Issue with Issue Trackers. New Ways of Working for Standards Groups

STAR Standards Chief Architect David Carver recently wrote a post about the W3C's use of a public issue tracker. A few people have "retweeted" the post and sent it my way via email. In the post, David gives kudos to the W3C for providing a publicly accessible issue tracker. I think the reason the post has some resonance is that at least a few readers recognize that the post is not so much about the use of about a particular feedback technology as it is about behavioral change within standards organizations and new ways of working. Actually, "new ways of working" isn't quite the right description. Between the lines, I think the post really is about bringing well-established and contemporary software development best practices to the work of standards organizations. If you read through David's other posts regarding the application of agile methodologies to standards development, they very much fit into this same theme.

David writes:

Unfortunately not all the [standards organization] workgroups take advantage of [issue tracking]. There are a handful of organizations, STAR being one, that make use of issue tracking systems to track the work and when it was completed. Visibility either to the public or at least to their membership can be key for helping adopters know what is coming and when it might be coming. Having the visibility into their process is a good thing, and should be encouraged.

I have enough experience with issue trackers in my years with HR-XML to be able to offer a few suggestions to standards organizations and other industry working groups:

• Be aware that what you are really getting at is behavioral change. There is a time and place for brainstorming and open discussion. On the other hand, if your industry initiative is more like "open mike night" than it is a software development project (or other commercial product development project) then you have a problem. An issue tracker can be used to structure working group discussions and meeting agenda. What also is good about trackers is documentation of why something didn't move forward. In "open-mike-night" discussions, you often come away with no forward progress after sitting through a lot of blocking and counter argument, but no real closure. You don't want an issue tracker to drive silly behavior, but you definitely need "closed for now" or "closed for this release" concepts for forward progress.
• Be prepared for maintenance and have a plan for security. The whole idea is to make a resource available that can be used by public stakeholders as well as working group members. When you make a resource like this publicly available, you also put out an invitation for mischief. You definitely need a captcha that works. Whatever technology you use, you'll need someone whose has the expertise and who has some time budgeted to keep the tracker software patched and secure (consider that there are hosted services).
• If you open the tracker to the public, you need to implement a "feedback policy" that covers intellectual property and terms of use. You want to keep the barriers to contributions very low, but some sort of simple registration process is necessary. You need to collect enough information to ensure the bug report is coming from a human being who can be consulted if necessary. The registration process also should include some type of "click-through" agreement under which the registrant gives anyone who has access to the feedback a royalty-free license to use it and that makes it clear that the feedback will be available publicly. Obviously, a significant contribution of IP that goes beyond a bug report would require a separate, more formal agreement with the contributor.
• Encourage and enforce proper use of the issue tracker. It shouldn't turn into a "blog," a place for position papers, or help desk. Link to lengthy discourse. Of course, you'll need to deal with some degree of purely self-serving entries that amount to "product placement," if not out right spam.
• Have a plan for versioning. Some trackers likely have built-in features to support this. Within HR-XML, we used the python-powered Roundup tracker. We created a new tracker within Roundup for each release. After working through open issues for a release, we used a "crawler" to create a static, HTML version of the tracker history for a particular release. We also burned these static versions of the "trackers" on to CD-ROM resource disks for face-to-face meetings. Having a plan to archive tracker history also is important for purposes of being able to track intellectual property contributions should controversies ever arise.

While David's post zeroes in on "issue tracker" technologies, there are obviously bigger issues just below the surface to which David also alludes:

It's hard to survive when your sole source of funding is on membership dues. It's also hard to recruit members when the perception is that it will take years for any changes to be made available to them.

Standard organizations in general are rightfully criticized for being slow moving organizations that by the time they react to change, the world has changed again, and business needs have changed.

The world has changed considerably since 1999 when I founded the HR field's first-ever standards organization. It is not an exaggeration to say that software development methodologies have been substantially transformed in the same period. Yet, as I've pointed out in prior posts, you can't say that the way most industry standards groups operate has undergone a similar transformation. As David points out, many standards organizations are struggling to survive under current economic conditions. I'd like to believe that current challenges might force some new thinking and openness to new approaches among the leaders of standards organizations. On the other hand, I suspect that one of the problems is that some leaders (or the member organizations that pay their salaries) are not themselves as invested in the interoperability mission of these standards orgs as they should be.