Industry standards are facing significant financial and governance challenges. Here's the deck from a related presentation given during my recent visit with the STAR standards community.

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:

How to Change

They say "a change we'll do you good." That "the only thing that is inevitable is change." We know change brings opportunities and challenges and that change is hard. In Part 1 of this series, I wrote about the importance for standards organizations to have a maturity plan in the same fashion that a maturing commercial product would have such a plan. In Part 2, I provided some background on HR-XML's origin and its early years. In this post, I take a look at some of the events that led to the HR-XML 3.0 project.

Tool Troubles

In business and in life in general, someone can tell you exactly what you need to know, when you need to know it, but the information doesn't always get acted upon immediately. I mentioned that in our very early days, Microsoft had helped raise our profile by allowing us to participate in the BizTalk launch. The very gentleman who had been so helpful back in 1999, visited us at our April 2004 New York meeting and gave us a review of our then 2-year-old version 2.* library. Let's just say this was delivered in the blunt manner characteristic of engineers. He covered items such as the complexity of the xsd:includes (see my Part 2 of this series), the use of troublesome schema features (e.g., the way we had used xsd:union within the date types throughout the library) as emphasizing that interoperability required a solid data model - not just XML. He concluded his presentation by saying something to the effect that we could fix these deficiencies or just become another group that travels, eats a lot of "hotel chicken," and shares a few beers together after work group meetings. The presentation did trigger a lot of discussion, but not necessarily any particular next step.