Ideas for standards work

Ideas for standards work 

On today's mail page, I ran an email from Todd Boyle who I know from the Decentralization list suggesting that weblogs might help to organize standards work. The current method, mail lists plus periodic face-to-face meetings, seems not to be working well. I had come to the same conclusion. Mail lists are disempowering, but even weblogs aren't enough to get a standard to happen, although I'm sure they can help.

At lunch on Thursday, I was at the same table as Sam Ruby and Jon Udell, and in a sidebar, I told Sam a couple of stories about my experiences with standards-creation, and thought they were on-topic enough to re-tell now, esp since various standards organizations are in re-think mode. These are just some ideas that I have seen work.

Idea #1 -- Yield to others 

First, everyone involved, hopefully not too many people, must agree to the following statement.

If possible I'm going to do it the way you want to do it.

Look at how the words I and you are juxtaposed.

This is the inverse of how most mail list workgroups work, where people fight and dig in on having it their way. Instead of adopting the me-first approach, I'll adopt the you-first approach. This is how you reach closure quickly and get the best ideas into the spec, and cull out the weak ones.

I've seen this work. At a working session at Microsoft in 1998, the one that launched XML-RPC, I was the note-taker. I began by opening a Notepad window with an example of a RPC payload in the format my company was using. I asked the group, what would you like to change? And then what would you like to add?

The room went quiet. I don't think they were prepared for this. An idea was presented. I changed the payload accordingly. Another idea, another change.

This flips around things radically. People get more conservative about their wants because they sense they will have to live with the ideas they propose. With the everyone-welcome mail list approach, people feel disempowered, and present ideas not to make the spec better, but to get a chance to be heard. Unfortunately this process makes for standards that are poorly thought out and hard to implement; and rarely results in people being heard. A no-win approach.

Idea #2 -- Let the spec speak for itself 

Keep the working group as small as possible, not too many people, and they must all have "standing." No tire-kickers or bystanders. Everyone involved must be creating software in the area under discussion.

Further, they must not be working for their employers when they're working on the standard, they should be working for the standard. Ask "What does the spec want me to do?" not "What does my company want me to do?" Don't get into arguments about this though, it's very hard to read someone's mind and figure out their motives. There's nothing more disempowering than having a stranger tell you why you're saying something.

But if the standard is going to be a good one, it's going to be true to itself, its ego is the one that drives the process, not the egos of the the participants or their employers.

Idea #2a -- Think like a jury 

If you've never done jury duty, and you live in a country that supports that standard for justice, volunteer, you won't be disappointed, it will help you work with the human beings in your working group. Juries have just a few days to reach a verdict, something few working groups do. Humans can do it, but it requires that first, you listen to your peers, and then together, you listen to the spec.

In the jury system the goal is to find nothing less than justice; your job is actually easier -- you're just supposed to coax the truth out of a concept. It's the highest form of programming, it's not surprising that a lot of programmers want to do it, but it's also a humbling experience, when you realize that it's an external concept that drives it, not you (as it is with all software development, btw).

Idea #3 -- Respect prior art 

Too many people involved on the mail lists want to rip up the tracks and start over, with little respect for what's already been done. When adding a new feature to a spec, look at past related work, and do it the same way if possible. For example, if names of elements were inner-cased, then new elements shouild be too. This will create consistency among the specs and make adoption easier for newcomers, who are coming soon, if the spec is to become a powerful standard. Consistency reveals logic and relaxes the mind. Paving the way for newbies is always a good idea, imho.

Idea #4 -- Have clearly understood goals 

It could be the goal to create a spec that's as simple as possible. Then you'd judge each feature against the extra complexity it adds. It might be that the goal is to apply an existing technology, like RDF, to a new task; if so you'd judge each feature based on how well it applies the existing technology.

Although we take it for granted that every spec tries to accomplish all kinds of goals we've heard are good things to do, sometimes they contradict each other. Part of letting the spec speak for itself is to know, up front, what its goals are. Or, if necessary, as you do the work, you may find that you don't have a goal along a certain axis, you have no clear way to make a decision between two approaches with clear tradeoffs. So go back and adjust your list of goals. It's OK to iterate.

I've seen situations where there was fundamental disagreement over the most basic of goals. In those cases, the only thing to do is to split into two groups, and pursue each goal independently, with goodwill going both ways. The clearest form of goodwill is for the two groups, as implementors, to implement each others' specs and let the market decide.