Standards communities are weird places. There aren’t many communities where people can hone in on a single sentence and have arguments about it that span years or months.
Or maybe it’s not so weird to do that. When rules need to be changed, the same sort of process happens for the moderators/admins who need to discuss the rule change. In government, the same sort of process and discussions might happen while a piece of legislation is being debated.
But really, standards communities are still weird. Discussions can get pretty dang heated (but you shouldn’t show it), and people can stop participating to the process as a whole because of disagreements, which isn’t great for a community that tends to rely on people deciding to voluntarily participate.
I’d like to have a chat about those discussions and disagreements, based on what I’ve seen around. The main standards group I’m a part of is the IRCv3 Working Group, so most of my experience comes from there, but hopefully this is useful in other places as well.
The main purpose of most standards communities is to develop consensus. Sometimes changes to the standard are decided on before being added in, and sometimes changes to the standard are made and feedback is given afterwards, but either way the basic process is similar.
When people agree on changes, it’s usually a pretty simple affair. You agree that this is a good thing, I agree that this is a good thing, change is made without a fuss.
Most of the time when people don’t agree on changes, it can be resolved just fine. We have different thoughts about this change? Either we chat about it and our minds get changed, or the change is altered/withdrawn and we’re fine.
Where it gets negative is when people don’t agree on a change, and the disagreement doesn’t resolve itself naturally.
An example:
A protocol exists that describes how parts are made in a warehouse. This protocol specifies things like ‘move drill in this way’ and ‘rotate part in that way’.
Bob wants to add a clause to a protocol where if one side tries to make more than 300 rotations in a row, the machine can simply ignore all the rotations after that and move to the next step.
Alice really doesn’t agree with this change because:
1. Lots of rotations may be useful for things like casting hollow moulds, so restricting these sort of commands is bad and may cause unexpected failures.
2. It places undue processing needs on the part of the machine, which should blindly follow orders and not need to count how many consecutive rotations it’s been tasked with doing.
…
And so the discussion, the back-and-forth, and the arguing continues. Bob really thinks there should be some limit there, Alice really disagrees with it.
It’s a pretty common sentiment to ask something like “How can people be so pedantic about a single line in a document that has over a hundred of ‘em?” Well, people can get caught up on the weirdest things. As I’ve gotten more familiar with standards documents, it gets easier to be passionate about a really small clause or a single line.
Regardless, Alice and Bob probably aren’t not going to change each others’ minds.
Because the nature of standards communities is to edit documents and processes continuously, every time the discussion comes near that place where the disagreement happened it’ll just launch the discussion again, over and over. In the IRCv3 WG, we’ve had a longstanding disagreement about how, or even whether, the protocol should use JSON for framing. Every time the topic is brought back up, all the old passions flare up again and we’re derailed for an hour or two with all the arguments and discussion.
All-up, this makes for a pretty miserable experience being a part of the community. If the discussion goes on long enough, or it gets gets heated enough, one or all of the people who are a part of it will end up taking a break from the community or simply refuse to continue participating outright.
The solution isn’t to just hand-wave and say “Well don’t argue then” or something similar, these people are passionate about setting the standard in the way they prefer, and won’t be quiet about what they think’s the best way just because someone else asks them to be quiet. And it’s not to keep discussion open so that everybody can explain their position properly, because all that’ll do is keep the negative, taxing talk going on.
In this case, it can be useful to have someone make a decision and end the discussion. Chairs of the standards community, the author of the specific document being discussed, etc. Whoever has the authority to make the decision. Exactly how that person decides can change how much people want to be a part of a group being run by them, but it’s usually a better outcome than a negative, aggressive discussion that lasts for years with no resolution.
End of the day, standards communities are weird. All of them. What we should be focused on preventing isn’t that a bad line might get into the standard, but that useful people are gonna stop contributing because there’s too many negative, taxing arguments that stop them from focusing on just getting work done.
Where to stop fighting about something obviously depends on the specific change, but I’m gonna do my best to let things slide when in the grand scheme of things they don’t really affect that much.