My thinking is like this. ( Sorry I would be typing the same thing :))
To be honest, I’m not too sure why so many people (it seems) are interested in having this done via series.
It seems more work and dev clutter to update Picard and Series entities to somehow make them suitable for storing all the required data and then be able to tag this data, then it does to just implement a style guideline that makes use of a system that we already use for very similar things like broadcasts and audiobooks.
Releases might seem like ‘overkill’ to some, who perhaps haven’t tried tagging podcasts, or for another reason that I don’t quite get, but most of the advantages provided by MB’s release system are useful or even indispensable when it comes to Podcasts. An episode release date, an image, a label, an annotation, an album artist and a track artist are not optional if we want to provide and store podcast information in a practical and useful way.
Luckily MB already has all of this capability! We just have to let people know they can use it.
If people want to take a look at a tidy example they can see one here:
The Infinite Monkey Cage: Series 1
I can tag everything I need using this structure (making a few adjustments, eg using the the release group as the ‘album’). It’s still missing useful data like album art, and crediting all the guests as artists on the individual tracks, but that’s not a problem if we’re using releases!
There are a few other examples that are tricky enough using the release group > release structure.
If someone can get a similar taggable result (without waiting another 3 years for updates to X and Y) using another method, and wants to draft a guideline for that, I’m perfectly happy to see it, but I think people may be overestimating the simplicity of podcast data and the variety of cases. And as the delineation between broadcast/music/podcast blurs more and more in future, we might run into a bit of trouble as well.
I can already sense the “When is it a podcast series / when is it a music or mix release?” thread in the far off future
Of course if anyone wants to give their time to making a release structure specifically for podcasts (eg storing all the necessary information inside the tracklist or series list) I have nothing against that.
We will have to make special rules for podcasts either way. There has been a fair amount of thought in various different podcasts with this those interested should read a summary of these thoughts in the forum post linked at the start.
That thread was initially before series came out but I am not sure there is any difference as it is around now.
Maybe this is one of these tagging vs database mindset issues that often butt heads here from time to time. I don’t see the release structure proposed as being especially problematic and it also works well for tagging, in any tagger.
For example what would the pseudocode for the default file name script be for allowing these podcasts as a series of recordings? Currently the default works fine. And it is always worth considering other data consumers (in this case I am thinking of other taggers) when open data projects start to grow beyond a hobbyist project into a mainstream de facto project.