Use case-driven standards development

XKCD encapsulates a situation in standards development that we all want to avoid well in their epitome Standards comic:

In the IndieWeb community, I have learned to ask myself the question "what is my use case?" when I start to think about standards or developing infrastructure around standards (i.e. implementations, libraries). This question is then followed by "is there a way that I can enable this behaviour within existing features?" These two questions help divert me from the aforementioned scenario: creating a new extension to a standard without the need for one.

Standards are at the heart of the web: from HTML to JavaScript all the way to ActivityPub, the standard that underlies Mastodon, and that Meta has said will be used in Threads by Instagram, their new social network. A change to a standard may solve a problem, but the question "for whom?" always exists. Standards must be technically excellent and use-case driven. They should solve the problem of real-world implementors, rather than hypotheticals.

I am able to discuss web standards more fluently when I have:

1. Researched and experienced the issue the standard is solving or trying to solve.
2. Read and implemented the specification, if one exists.
3. Communicated with other implementors to learn from them.
4. Document my own learnings as I go, either in code that I can share and explain, blog posts, wiki entries, or chat logs.

My participation in standards discussions -- parser development, discussing and sharing feedback on extensions, providing notes on a specification -- starts with my being passionate about a problem, and being someone who will consume the standard.

I rarely embolden words on this blog, but "experienced" up there is crucial. I have implemented and often discuss specifications like Webmention and Micropub because: (i) they solve a problem I am experiencing, and; (ii) I want the technology to be as broadly useful as possible.

Also posted on IndieNews.