“In the post, “Appeals Are Not Failures,” I wrote that appeals are not failures. I meant it.”

Standards organizations need ways for people to challenge decisions they cannot live with. Without that, “consensus” can become little more than a polite word for exhaustion, hierarchy, or whoever had enough time to stay on the call.

A healthy process has to make room for principled dissent. It has to allow someone to say, “This is wrong, and the result needs to change.” That is not a problem to be solved out of existence. It is part of what makes consensus-based work legitimate.

But there is another side of this, and it is uglier.

The same processes designed to protect fairness can be used to grind a group down. Appeals, objections, process complaints, meeting challenges, and code-of-conduct-adjacent behavior can all become tools for obstruction when the goal is no longer to improve the work, but to make progress too costly for everyone else.

That is when process stops protecting the work.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

The difference between dissent and obstruction

Disagreement is not abuse.

Let’s get that part clear up front, because otherwise this whole conversation goes sideways quickly.

Standards development depends on people being willing to disagree. If everyone in the room is too polite, too tired, or too politically cautious to say when something is wrong, the group is not doing consensus. It is doing theater with minutes.

Real dissent can be uncomfortable. It can be persistent. It can come from someone who is deeply frustrated because they believe the group is ignoring a serious technical, privacy, security, accessibility, deployment, or governance problem. Sometimes that person is right. Sometimes they are partly right. Sometimes they are wrong, but still raising a concern that forces the group to explain itself better.

That is healthy. Obstruction is different.

Process is weaponized when someone uses the rules less to resolve a concern than to make forward progress costly, risky, or impossible. That is a pattern that makes disagreement impossible (or at least really, really hard) to resolve.

Every answer generates a new procedural objection. Every decision becomes evidence of bias. Every attempt to move forward becomes proof that the group is suppressing dissent. Every request for specificity is treated as evasion. Every effort to summarize the group’s position is challenged as bad faith. Eventually, the technical work becomes secondary to managing the person who refuses to let the group work.

That is not healthy process. That is procedural warfare.

Standards organizations already recognize this tension. The IETF’s working group guidance describes part of the chair’s job as balancing open and fair consideration of issues against the need to make forward progress. That balance is the heart of the problem. Too little openness, and dissent gets suppressed. Too little discipline, and the process can be used to make progress impossible.

The hard part is that both failures can be defended in the language of fairness.

What process abuse looks like

Process abuse rarely announces itself clearly. If it did, it would be easier to handle. It often looks like one more objection. One more request to revisit a decision. One more claim that the group did not follow the process correctly or a demand that the chair prove, again, that the same issue was considered. One more comment that is not quite a code of conduct violation, but leaves everyone on the call a little less willing to speak.

It can look like spurious appeals that repackage already-answered arguments without new evidence. It can look like endlessly reopening settled issues through slightly reframed objections. It can look like procedural flooding, where the group spends more time responding to complaints about process than improving the specification.

It can look like accusing chairs, editors, or contributors of bias, bad faith, incompetence, or corruption without evidence. It can look like treating minor procedural ambiguity as proof that the entire result is invalid. It can look like using delay as leverage. And since all of this is open to interpretation, not everyone will agree when this behavior crosses the line.

Sometimes, it looks like staying just barely on the acceptable side of a code of conduct while making everyone else miserable.

That last one is particularly hard to manage. Standards organizations are used to dealing with technical disagreement. They are less good at dealing with people who understand exactly where the line is and hover over it with intent.

They may not use the prohibited words. They may not make the obviously sanctionable statement. They may not do the single thing that makes the formal path easy. Instead, they create drag. They create fear. They make participation expensive in ways that are difficult to capture in a meeting note. By the time the behavior becomes undeniable, many of the people most worth keeping have already stepped back.

Why I am not naming examples

I could point to several public examples. I am not going to.

That is not because examples are hard to find; I wish they were. It is because naming them would almost certainly turn this post into a fight about the people involved rather than the pattern I am trying to describe.

More bluntly: I do not trust people who behave this way to learn from the criticism. I expect some would simply make me the next target, and I do not have the time or energy to donate myself to that particular bonfire.

That, by itself, is part of the problem.

If standards development is going to bring in more people, especially people who are not already steeped in the culture, it has to be safe enough for them to participate. Not perfectly comfortable. Not free from disagreement. Not protected from criticism. But safe enough that raising a concern, chairing a difficult discussion, editing a controversial draft, or asking a naive-but-useful question does not mean signing up for personal attack, procedural harassment, or months of bad-faith escalation.

People who abuse the system take away that safety.

This is one of the hardest jobs for standards development organizations: protecting healthy process without allowing process to become a weapon. Leaders have to preserve the right to object, appeal, dissent, and challenge decisions. They also have to recognize when those rights are being used to exhaust the group, intimidate participants, or make progress impossible.

Again, that line is not always obvious. Sometimes abuse is partly in the eye of the beholder. Sometimes the person blocking the work genuinely believes they are doing the right thing. They may believe the technology is harmful, the architecture is dangerous, the process is compromised, or the group is moving too quickly. They may see themselves as the last responsible person standing in the way of a bad outcome. And sometimes they may even have a point.

Intent matters, but it is not the whole story. Someone may sincerely believe they are protecting users, blocking a harmful technology, or preventing a bad architectural decision. They may even be right about the risk.

But sincerity does not erase impact.

Believing you are right does not give you permission to make participation unsafe for everyone else. A standards process has to make room for principled dissent. It does not have to reward procedural warfare.

The cost is not just delay

When process is weaponized, the obvious cost is delay. The document does not advance. The issue queue grows. Meeting time disappears into procedural churn. Chairs spend their time writing careful summaries instead of helping the group make decisions. Editors spend their energy defending the same choices again and again instead of improving the text.

That is bad enough. But the deeper cost is who leaves.

People do not usually engage in standards work because they are excited by conflict. They engage because they care about the technology, the users, the deployed reality, the public interest, the market, the architecture, or some combination of all of the above.

They want to solve technical problems in a way that other people can implement. They want the work to be better because they were there. They want their corner of the internet, or security, or identity, or accessibility, or privacy, or infrastructure to function a little more predictably than it otherwise would.

That motivation is powerful. It is also not infinite.

When people have to stop thinking about how to solve technical problems in a standardized way and start thinking about how to survive the next procedural attack, the work becomes less worth doing. To put it another way, that is not what people think they are signing up for when they participate.

Experienced contributors leave first quietly, then permanently. Newer contributors decide the room is not for them. Editors burn out. Chairs become cautious, defensive, or numb. Implementers with real deployment knowledge go back to the work that pays them, because they were already squeezing standards participation around everything else.

The group may still exist after that. The calls may still happen. The repository may still receive comments. The process may still appear to be functioning. But something critical has been lost.

The perverse reward

A few weeks ago, I watched a version of this pattern unfold in another group and found myself saying something I have not been able to stop thinking about.

The person behaving badly was a senior developer. They were pushing their agenda hard, and the effect was clear: other people were stepping back. People who had been trying to advance the work were losing patience, losing energy, or deciding that no technical outcome was worth the cost of staying engaged.

And at some point, the person causing the problem was almost the only person left to advance the work.

That is a perverse reward.

I do not mean the group intended to reward bad behavior. Of course it did not. But when the person making collaboration unbearable is the one who remains, the process has selected for endurance rather than judgment, aggression rather than collaboration, and obstruction rather than contribution.

That should scare standards organizations.

If your process drives away the careful people and leaves the most combative person holding the pen, the process has not preserved consensus. It has laundered dysfunction into authorship. I understand I’m being harsh with this, but I think it is true.

What to do if you are in the middle of it

If you are in the middle of process abuse, the first instinct is often to argue harder. That is understandable. It is also usually a trap.

When someone is using the process to exhaust the group, more argument often just creates more material for them to challenge. Every clarification becomes another opening. Every response becomes another procedural object. Every attempt to prove good faith becomes another demand to prove it again.

The second instinct is to give up.

That is understandable, too. Sometimes it may even be the right personal decision. Standards work matters, but it is not helped by turning thoughtful contributors into procedural kindling.

But if you are trying to stay engaged, the most useful thing you can do is keep clear documentation before you need it.

That sounds unsatisfying because it is. It does not deliver the emotional release of winning the argument. It does not stop the bad behavior in the moment. It does not restore the joy of the work. But it gives you something to stand on if and when escalation becomes necessary.

Keep track of the specific decisions being challenged. Save links to issue comments, meeting minutes, mailing list threads, pull requests, consensus calls, and prior resolutions. Note when the same concern has been raised and answered. Capture the difference between a new substantive concern and a repeated attempt to reopen a settled issue. If the behavior is affecting participation, document that impact as well: who stopped engaging, which discussions were derailed, what work stalled, and how much meeting time was consumed.

The point is not to build a secret prosecution file. Please, no. The point is to avoid having to reconstruct months of dysfunction while you are already exhausted.

If escalation becomes necessary, you want to be able to say: here is the pattern, here are the examples, here is the effect on the work, and here is the kind of help the group needs.

That is very different from saying, “This person is impossible.” Even when they are. Especially when they are.

Documentation also helps avoid overclaiming. In emotionally draining situations, it is easy for everything to blur together into one large, miserable cloud of process nonsense. A clear record helps distinguish between forceful dissent, ordinary frustration, procedural confusion, and actual abuse of the process.

That distinction matters so much.

The goal is not to punish disagreement. The goal is to protect the work, the participants, and the legitimacy of the process itself.

And if you do decide you need to step back, documentation still helps. It gives the chair, staff contact, ombuds, area director, governance body, or whoever comes next something concrete to work with. Silence is understandable. A clean record is more useful.

I don’t expect anyone in the middle of this kind of situation to find this a satisfying answer. But in situations where someone is turning process into a weapon, clear documentation may be the only thing that keeps everyone else from having to fight the same battle from scratch.

If this is happening	A more useful response
Someone keeps reopening a settled issue	Ask what new information changes the prior decision. Link to the earlier discussion and decision record.
Someone makes broad accusations	Ask for the specific decision, text, conduct, or process step at issue.
Someone hovers near the code of conduct line	Document the pattern and its effect on participation, not just the individual incidents.
The chair is absorbing all the conflict	Support escalation to staff, ombuds, area directors, governance bodies, or other available support structures.
You are burning out	Step back if you need to, but leave a clear record where possible so others are not starting from nothing.

None of this is glamorous. It will not fit nicely on an inspirational poster. But when process abuse is happening, boringly clear documentation is often the most useful defense.

“The chairs should handle this” is not enough

It is easy to say, “The chairs should handle this.” Chairs, after all, have a responsibility to manage the process, protect participation, and keep the group focused on the work.

But chairs are people, too. They are also targets.

In volunteer-driven standards communities, chairs are often absorbing the conflict while also trying to keep the work moving, support editors, maintain trust with participants, and avoid making the situation worse. They may be dealing with someone who has more time, fewer constraints, and less concern for the health of the group.

Telling chairs to “just enforce the process” sounds neat from the outside. From the inside, it can mean asking one or two volunteers to stand between the group and a person who has turned process into a weapon. That is not a governance plan; that is a blast shield with an email address.

If the only answer to process abuse is “the chair should be stronger,” the organization has failed the chair.

Chairs need support. Editors need support. Participants need to know that the organization will not leave them alone when healthy disagreement turns into harassment, intimidation, or strategic exhaustion.

Chairs may be the first line of defense because they understand the group’s history and working context. But first line should not mean only line. Codes of conduct, ombuds functions, staff support, area directors, councils, boards, and other governance bodies exist because some situations are bigger than a chair can or should handle alone.

Defending the process without weakening it

The answer is not to make appeals harder for people with real concerns. That would be the wrong lesson.

People need real ways to challenge decisions, especially in consensus-based systems. If anything, the right to dissent becomes more important when the work is high-stakes, politically sensitive, or likely to affect people who are not in the room.

The answer is to make abuse harder for people using the process to exhaust everyone else.

That starts with documentation. Not because documentation fixes bad behavior, but because memory is fragile and narratives are contested. If the group is heading into conflict, the record needs to be clear enough that someone outside the immediate argument can understand what happened.

Track the issues. Record the decisions. Capture dissent accurately. Document the rationale. Keep timelines. Make clear when a topic is open for discussion and when a decision has been made.

Specificity helps, too. When someone makes a broad accusation, ask for the specific decision, text, behavior, or process step at issue. When someone says the group ignored a concern, ask where the concern was raised and what response they believe was inadequate. When someone says the process was violated, ask which part of the process and what remedy they seek.

This is not about being bureaucratic for the joy of it. There is no joy in that. It is about refusing to let vague accusation become permanent leverage.

Standards organizations should also be willing to bring in neutral review earlier when the situation warrants it. Not every conflict needs escalation, but some conflicts become worse because everyone keeps pretending the working group can resolve something it plainly cannot.

There also has to be real meeting discipline. If someone is hovering near the code of conduct line in every interaction, that is not just an interpersonal problem. It affects participation. It affects who is willing to speak. It affects whether the group can do the work. A pattern of near-the-line behavior is still a pattern.

Leaders should not wait for the perfect single incident before acting. Sometimes the harm is cumulative.

ISO’s Code of Ethics and Conduct makes a useful point here, even though ISO’s structure is different from W3C or the IETF. It ties standards work to good faith, consensus-building, constructive engagement, and agreed mechanisms for escalating and resolving disputes. Different organizations use different machinery, but the underlying expectation is similar: disagreement is allowed; abuse of the process is not.

Protect the people, or lose the work

I recently read an article from a very different environment about “toxic complaints.” The setting was military legal process, not standards development, so the analogy is not exact and should not be stretched too far.

But one part translated painfully well: systems designed to protect fairness can be used to intimidate, exhaust, and hamstring the people trying to operate them. The recommended response was not to take shortcuts. It was to document everything, protect the process, use independent review when needed, and resist letting chaos become normal.

That is good advice for standards work, too. The answer to process abuse is not less process. It is better-protected process.

That sounds joyless, and in some ways it is. It takes away some of the ease and trust that make standards work rewarding. It means chairs and editors may need to be more careful, more explicit, and more formal than they would like.

That is unfortunate, but the alternative is worse.

The alternative is allowing the people most willing to abuse the process to define the culture of the group. The alternative is losing careful contributors because participation has become too costly. The alternative is teaching new people that standards development is not a place for thoughtful collaboration, but a place where the most persistent combatant wins.

That is not a lesson we should be teaching.

Standards work is already hard. It asks people to collaborate across companies, countries, legal systems, deployment models, technical assumptions, and personal egos. It asks people to build shared infrastructure out of disagreement. That is difficult even when everyone is behaving well.

When someone weaponizes the process, they are not just slowing a specification. They are making it harder for the next person to believe the work is worth doing. And that is why standards organizations have to take this seriously.

Process exists to make collaboration possible. Appeals exist to protect legitimacy. Codes of conduct exist to protect participation. Chairs exist to help groups make decisions without pretending the hard parts are easy.

None of these things should be used to make the work unbearable.

The goal is not a conflict-free process. That would be fantasy, and frankly not a very useful one. Instead, focus on having a process strong enough to handle disagreement without rewarding abuse.

That is harder than writing down the rules. It requires judgment, documentation, support for leadership, and a willingness to act before the best people quietly leave. Because when process becomes the thing that drives good people away, it is no longer protecting the work, which is a failure for everyone.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

A few weeks ago, we explored why appeals are not a failure of the standards process.

In healthy standards organizations, appeals serve an important purpose.

They provide a structured way for participants to say:

• A decision is wrong.
• A concern has not been addressed.
• The outcome deserves another look.

Without that opportunity, consensus can easily become little more than:

• Exhaustion
• Hierarchy
• Persistence

However, there is another side to the story.

The very mechanisms designed to protect fairness can sometimes be used to prevent progress.

And that is when process stops protecting the work.

---

Dissent Is Not the Same as Obstruction

Standards development depends on disagreement.

People need to be willing to raise concerns about:

• Security
• Privacy
• Accessibility
• Deployment
• Governance
• Architecture

Sometimes those concerns completely change the outcome.

Sometimes they improve the final work.

Even when a concern is ultimately rejected, it often forces the group to explain its reasoning more clearly.

That is healthy.

Obstruction, however, is something different.

---

When Process Becomes a Weapon

Obstruction begins when process is no longer used to resolve disagreements.

Instead, it is used to make progress increasingly difficult.

The pattern often looks like this:

• Every answer generates another objection.
• Every decision becomes evidence of bias.
• Every attempt to move forward is treated as suppression.
• Every clarification becomes another opportunity to reopen debate.

Eventually, technical work becomes secondary.

The group spends more time managing conflict than improving the specification.

---

Why This Is So Difficult to Recognize

Process abuse rarely announces itself.

Instead, it often appears perfectly reasonable.

For example:

• Another request to revisit a decision
• Another procedural complaint
• Another appeal without new evidence
• Another attempt to reopen a settled issue

Each individual action may seem acceptable.

The problem is rarely one event.

It is the cumulative pattern.

---

Living Just Below the Line

Some of the most difficult situations involve behavior that never quite violates a formal code of conduct.

Instead, the individual remains just inside acceptable boundaries while creating:

• Fear
• Frustration
• Exhaustion
• Constant procedural drag

There may be no single statement worthy of formal sanctions.

Yet participation becomes increasingly expensive for everyone else.

By the time the pattern is obvious, many valuable contributors have already stepped away.

---

Why This Matters

This isn’t simply about making meetings uncomfortable.

It directly affects who feels able to participate.

Standards organizations need to be safe enough that people can:

• Raise difficult questions
• Chair challenging discussions
• Edit controversial specifications
• Admit when they don’t understand something
• Offer new perspectives

That does not mean eliminating disagreement.

It means preventing disagreement from becoming personal harassment or procedural warfare.

---

Good Intentions Are Not Enough

One of the hardest realities is that people causing disruption often believe they are protecting the work.

They may sincerely believe:

• The technology is dangerous.
• The architecture is flawed.
• The group is moving too quickly.

Sometimes they may even be correct about the underlying concern.

However, sincerity does not erase impact.

Believing you are right does not justify making participation unsafe for everyone else.

---

The Hidden Cost of Process Abuse

The obvious cost is delay.

Documents stop advancing.

Issue lists continue growing.

Editors repeatedly defend previous decisions instead of improving the specification.

Meeting time disappears into procedural debates.

Those costs are visible.

The deeper costs are much harder to measure.

---

The People Who Quietly Leave

Most people participate in standards because they care.

They want to:

• Solve real technical problems
• Improve interoperability
• Build better systems
• Contribute to the public good

That motivation is powerful.

But it is not unlimited.

Eventually, people stop asking:

“How do we solve this problem?”

Instead, they begin asking:

“Is this worth it anymore?”

When that happens, experienced contributors often leave quietly.

---

What Organizations Lose

When participation becomes exhausting, organizations lose far more than meeting attendance.

They lose:

• Experienced editors
• Knowledgeable implementers
• Thoughtful reviewers
• Future leaders
• New contributors

Meetings may continue.

Repositories may remain active.

The process may appear healthy.

But something important has already been lost.

---

When Bad Behavior Gets Rewarded

One of the most troubling outcomes occurs when persistent obstruction outlasts collaboration.

Imagine this scenario:

• Collaborative contributors gradually leave.
• The person creating the conflict remains.
• Eventually, they become the primary contributor.

No one intended that outcome.

Yet the process has effectively rewarded endurance rather than collaboration.

It has selected persistence over judgment.

And that is a dangerous signal.

---

Arguing Harder Usually Doesn’t Help

When people encounter this behavior, the first instinct is often to argue more forcefully.

Unfortunately, that usually creates:

• More debate
• More objections
• More opportunities to reopen settled issues

The second instinct is to walk away entirely.

Sometimes that is the healthiest personal decision.

However, if you choose to remain involved, there is a more productive approach.

---

Document Before You Need It

Clear documentation becomes essential.

Keep records of:

• Previous decisions
• Meeting minutes
• Mailing list discussions
• Pull requests
• Issue comments
• Consensus calls
• Prior resolutions

Also document:

• Which discussions stalled
• Which issues repeatedly resurfaced
• When participation began to decline

The goal is not to build a case against an individual.

It is to preserve an accurate record of what actually happened.

---

Focus on Patterns, Not Incidents

Single interactions rarely tell the whole story.

Instead, look for recurring patterns.

For example:

• The same issue repeatedly reopened
• Broad accusations without specifics
• Repeated procedural challenges
• Behavior that discourages participation

Patterns provide context that isolated incidents cannot.

That distinction matters.

---

Support the People Doing the Work

It is easy to assume that chairs should simply handle difficult situations.

In reality, chairs are often volunteers facing the same pressures as everyone else.

They may be simultaneously trying to:

• Maintain forward progress
• Support editors
• Encourage participation
• Resolve disagreements
• Avoid escalating conflict

Expecting chairs to solve every problem alone is unrealistic.

Organizations need to support:

• Chairs
• Editors
• Contributors
• Governance bodies

Healthy processes require healthy leadership structures.

---

Protect the Process Without Weakening It

The answer is not fewer appeals.

Nor is it making dissent more difficult.

Healthy organizations still need:

• Appeals
• Objections
• Independent review
• Due process
• Careful governance

What they also need is protection against the process being used against itself.

That requires:

• Good documentation
• Consistent meeting discipline
• Neutral review when necessary
• Clear escalation paths
• Leadership support

---

Better Process, Not Less Process

Interestingly, similar lessons appear well beyond standards organizations.

Strong governance depends on:

• Documenting concerns
• Following established procedures
• Avoiding shortcuts
• Maintaining independent review
• Preventing chaos from becoming normal

The answer to process abuse is not abandoning process.

It is strengthening it.

---

Final Thoughts

Standards development has never been easy.

It brings together people with different:

• Technical perspectives
• Business interests
• Deployment realities
• Cultural backgrounds
• Priorities

Disagreement is inevitable.

That is not the problem.

The problem begins when process itself becomes the mechanism that discourages thoughtful participation.

---

Conclusion

Healthy standards processes must be strong enough to handle genuine disagreement without rewarding obstruction.

That balance is difficult.

But it is essential.

Because when the very process designed to protect collaboration instead drives away the people doing the work, it no longer serves its purpose.

It stops protecting the work—and begins consuming it.

---