How to Enter a Standards Working Group

As the OAuth specification editor, I am approached daily with comments, questions, ideas, and some very odd solicitations. It is quite fun. It seems that most people joining the work are determined to undermine their contribution by doing their best to alienate or insult the community, and often the editor.

This is not unique to OAuth – I have seen the same mistakes in many other places. Since working on an early draft of the OAuth 2.0 specification, I started collecting tips for newcomers. Here are some that would make your entrance into a standards working group much smoother and productive.

Don’t start with a proposal, start with a question.

Assume you don’t understand everything, especially if you have feedback or ideas for changes. Instead of jumping in with some new re-architecture of the entire protocol, start by asking why it is the way it is. Engage the community first with a question, and work your way to change requests based on the answer you receive. By asking a question, you allow for the possibility that whatever if bugging you has a valid reason.

Keep your message as short and to the point as possible.

You are an unknown so people will look for reasons to ignore your message. Most people don’t even open messages from newcomers. Instead, they wait to see if a thread develops. In other words, they wait until someone else puts in the extra work to deal with the new guy. If your message is short, it is more likely not to be ignored.

Don’t email the editor privately, asking for permission before asking the list.

You don’t need permission to ask questions or post to the list. All the specification editors I know (and certainly me) are usually busy and work in bursts. This means your email is most likely going to be moved to some queue of questions and feedback about the specification, to be processed right before the next editorial cycle. You are also wasting their time by forcing them to read your message twice (once directly and once on the list), and in many cases, repeat the discussion. This is why we have a public list – just join and post away.

Don’t prefix your message with I’m new here.

It’s never a good idea to start a relationship with an excuse. The only reason to put an “I’m new here” disclaimer on your message is if you were too lazy to do your homework, read group archives, read the full specification (and revision history), and think before writing. If you do all that, your contribution is as valid and relevant as that of anyone else. The working group regulars know you are new.

Focus on what you know best.

Pick an area where you have experience and provide feedback to show you know what you are talking about. Don’t start with a multi-page review of the entire specification. Instead, focus on the areas you are most knowledgeable about and demonstrate your skills and experience through the quality of your contribution. Don’t provide a summary of your career – saying you have many years of experience is the least effective way to get that message across. Let you work speak for itself.

Never start with an editorial suggestion.

Editors like to write, and they take pride in their work. They also have their own unique voice. Starting a relationship with a specification editor by criticizing their style is not a good way to get them to listen. Typos, mistakes, and other technical issues with the specification are always welcomed, but offering replacement text or ideas on how to say something differently will most likely be ignored, no matter how good the suggestions are. Wait for an editor to ask you to suggest text before sending in your own revision.

Start with a compliment, show good progress.

Pick something you think is good about the work, and highlight it. This isn’t rocket science, just common sense. Don’t compliment any one person in particular (like the editor or chair). Compliment the work and the community and do it in a way that adds value, like highlighting what is strong and good about the work, providing additional support.

Clearly state your role and introduce yourself.

Spend a few words to introduce yourself the first time you write something. Don’t just barge in – it’s rude. Also, standards are highly political, and in a political environment, people want to know who they are dealing with. No need for life story, just the basic facts (lurker, developer, representative for a big company). And don’t assume everyone know who you are just because you think you are important.

Do your political homework.

Identify the key participants and align yourself with those you agree with, showing you are well versed in the internal politics. Joining the discussion through agreement with a primary participant allows you to establish a work relationship with those most likely to be in a position to listen and impact. Agreeing with someone is usually better than disagreeing – it adds emphasis to an existing view, and doesn’t cost you political points going directly against someone else.

Make sure to be right if you are going to keep a thread going.

If you are going to stand your ground and keep an argument going, against the group consensus, make sure you know what you are talking about. It is perfectly fine to keep an issue going if you are unhappy with the resolution, but if you are new, this behavior is more likely to alienate the group than win your argument. If you are going to keep at it, make sure to add new facts and new examples to make your point.

Don’t explain basic standards principals.

Assume everyone knows what bike-shedding, design by committee, or KISS are. Don’t lecture the working group about process and other philosophical ideals. For most of the people involved, this is probably not the first standard.

Don’t prefix more messages with “I’m still new here”.

You didn’t need to state it the first time, so please don’t keep repeating you are (still) new. Yes, we got it, you are new here.

One thought on “How to Enter a Standards Working Group

Comments are closed.