I was going for "set up some code once and don't think about it again" to maximise the odds of the idea sounding tempting.
Proofreading would set up an expectation on the part of readers that it -had- been proofread and corrected and therefore a commitment to perform a repeated "boring but important" task going forwards for whoever's doing said proofreading.
That way would likely lie either delayed transcripts or never getting to initial activation energy to provide anything at all.
So I think "add a quick bit of code to your podcast publishing workflow and a CAVEAT IN BIG LETTERS" is better to do first.
If it turns out enough people care about the transcript, doing it a more labour intensive nicer way later is something they can decide, well, later.
Proofreading would set up an expectation on the part of readers that it -had- been proofread and corrected and therefore a commitment to perform a repeated "boring but important" task going forwards for whoever's doing said proofreading.
That way would likely lie either delayed transcripts or never getting to initial activation energy to provide anything at all.
So I think "add a quick bit of code to your podcast publishing workflow and a CAVEAT IN BIG LETTERS" is better to do first.
If it turns out enough people care about the transcript, doing it a more labour intensive nicer way later is something they can decide, well, later.
Shipping is feature zero, as ever.