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:

One of the LinkedIn Groups I subscribe to is the "Informal Network of Standards Professionals". There have been a few interesting threads over there, including one about how standardization processes have changed -- or need to change.

In the case of information and software-related standards, the issue is simply that standards development methodologies haven't kept up with the pace of change in software development methodologies.

Software development methodologies have undergone revolutionary change in just the past decade. By comparison, the development methodologies of most SDOs and consortia have remained largely the same. SDOs and consortia tend to be the last great bastion for "death march" projects and "waterfall design". Under traditional standards development approaches, the balance of development time is spent in upfront design and drafting of specification documents. Key quality assurance processes, such as testing and the development of reference implementations tend to be activities that happen at the very end of the standards-approval project (if they occur at all).

What is needed?

• Realistic planning and estimation of what it will take to get a standard to a reasonable state of maturity.
• Some notion of iterative and test-driven development.
• Better delination of roles and responsibilities among a broader, more inclusive set of standards stakeholders.
• Better specification of requirements and interim testing and retrospectives as means to ensure requirements are effectively dealt with.

Who are Contributors?

Contributors are individuals, who with the specific consent of their employer or the affiliated organization they represent, formally join an HRInterop working group and sign the contributor and intellectual property agreement for the specific development effort being pursued.

Representatives of sponsor organizations can become contributors at no additional cost, but sponsors do not become contributors unless their representatives formally join a working group and sign the associated contributor agreement.

All materially affected parties, including those from non-sponsor organizations, can participate in working groups. A separate per-contributor fee applies in the case of contributors from non-sponsor organizations.

Learn More

Contact us with your specific standards proposal or project.