Start specs where you know; don't over-envision
Quote
this happens to all specifications. You you start where you know, you, you know, you start where you know, but it's like, Okay, here's the things we have in front of us. And if you go too far, and try to envision everything that could possibly come in the future,
Episode 152: Drop the TOC (episode page, opens in a new tab) 00:13:26 (play audio from this timestamp, opens in a new tab)
Speaker-labeled
Summary
Every specification starts with the problems in front of you. Try to envision everything that could come in the future and you go too far. When new use cases show up, respond by extending the spec responsibly rather than ripping it out and starting over.
Also said
Episode 152: Drop the TOC (episode page, opens in a new tab) 00:27:49 (play audio from this timestamp, opens in a new tab)
We're not going to rip the chapter spec out and start from scratch, it would be so disruptive.
Speaker-labeled
Episode 152: Drop the TOC (episode page, opens in a new tab) 00:29:38 (play audio from this timestamp, opens in a new tab)
So you just have to respond. You just have to respond to this thing. And I think the spec is the format of the file is flexible enough to handle. I mean, if we do it in a responsible way,
Speaker-labeled
Episode 175: Everyone's an Actor (episode page, opens in a new tab) 01:18:40 (play audio from this timestamp, opens in a new tab)
OPML everything in podcasting is geared towards RSS. On the subscription front. And it's just, it would be such it would be a big it'd be a heavy lift to make people parse OPML.
Speaker-labeled