Proposal - <podcast:acceptsGuests>
jamescridland opened this issue · 17 comments
What:
A simple way to show, in the channel of a podcast RSS feed, whether a podcast has guests.
How:
<podcast:acceptsGuests>yes</podcast:acceptsGuests> - this podcast regularly has guests on its episodes
<podcast:acceptsGuests>no</podcast:acceptsGuests> - This podcast does not have guests on its episodes
<podcast:acceptsGuests></podcast:acceptsGuests> or an absence of this tag - This podcast may or may not have guests
Why:
- A method to ensure that promoters of guests do not waste time contacting podcasters with news of their "amazing guest who would be perfect for your show"
- A method to signal to a UX element within a podcast player that this podcast has guests, and perhaps to display a different form of UX to allow individual guests to be clearly visible (using the already existing
podcast:persontag) - A method for podcast hosting companies to only ask about
podcast:personfor each show if that show has guests, and otherwise not surface that set of dialogs - A method to populate podcast guesting tools such as Acast's Podchaser without being forced to claim shows and keep a separate set of databases updated
- A way to allow enhanced search within a podcast app and/or to signal to the app to perform a different filter on the description field or others to look for guest names and links; or to prepare for an unknown voice when producing a transcript; or other similar opportunities
Impact:
- Filesize: this is heavily compressible and would add negligible weight to the RSS feed
- This could be set, or unset, using a tickbox within the "podcast settings" section of a podcast host's UI, and should not add appreciably more time for the user
- This is a simple boolean value (yes/no/NULL) and has low impact on database schemas or storage
This was edited to change the proposal to acceptsGuests rather than hasGuests
I like the thinking here because just having a guest person tag doesn’t mean that you are a show that has guests. Some shows have guests infrequently, but it’s not part of their main format.
On the solicitation side, I wonder if that could be a different tag altogether. Something like <podcast:solicit> which describes the way you are willing to allow solicitation for things: guests, advertising, hosting, etc. 🤔
I like this idea!
I also wonder if we might want to expand it to a bigger <podcast:has> tag that could potentially accept more types of "has …" indicators. I don't know what we might want to future-proof for, so it's only a consideration at this point.
I think this idea.
As someone who has had to pitch hundreds of podcasts, something else that would be helpful for potential guests is knowing the level of editing
a) no-editing (single take--short of some major issue)
b) light editing (e.g. you can redo an answer)
c) full editing (review of entire recording, removal of disfluencies, etc.)
Also, but in a separate tag, is knowing whether it's audio only or also video.
a) audio only
b) still photos (often used in social media promotion)
c) video clips (often used in social media promotion)
d) full video
People need to know if they need to do hair and makeup, or have a potentially hot lighting setup on. Likewise knowing you're on camera the whole time versus just for part of it helps people relax.
I like that thought, @HersheyCognosco. I only think that might be more appropriate to communicate on the podcaster's website as part of the "pitching" process.
@theDanielJLewis I would agree. I'd even argue whether or not a podcast takes guests is best communicated on the podcast website. I believe the argument implied by @jamescridland (he came comment if I'm wrong) is
- May podcasts don't have websites
- Many podcast matching and indexing platforms like Podmatch and Podchaser pull data from the RSS feed, not the website, since the RSS follows a standard format.
The goal is to ensure that promoters of guests do not waste time contacting podcasters with news of their "amazing guest who would be perfect for your show". I think that's a good one. Having it in the RSS feed lets someone quickly filter to only pitch podcasts with guests, saving guests and hosts time. Likewise, some guests may prefer audio only, or may be nervous and only want to do podcasts where there is editing.
In another case some podcasts are also done live-streamed. In theory no editing and live-streamed. Some people may be very nervous and want to avoid those. Having all this in the RSS filter lets them select ones that are a fit. In yet another case perhaps they only want shows with preset questions because the guest, who may be brilliant in her field, isn't good on the fly.
I like your idea of has since that allows for this more general extensibility. E.g. podcast has video, podcast has full editing, podcast has live Q&A with audience.
What about renaming this to acceptsGuests? I think it would clarify the use better and be less likely to be confused with an episode that happens to have guests as represented by the guest bit of the person tag.
@genebean - I'm absolutely fine with that.
Do you think it would be helpful to have more than a yes/no value? Like maybe some freeform text for the podcaster to say what kind of guests they want?
I'd really like to avoid freeform text. It's impossible for computers to understand.
My thinking is that a "yes" value would signal to apps to display the freeform text within an appropriate context instead of indicating only "this show accepts guests."
In case it's helpful in the discussion, we at Rephonic try to determine whether a podcast takes guests automatically (by looking for certain keywords and human names in episode metadata) and according to that measure 29% of all active shows take guests.
I’m with @jamescridland on the boolean aspect of the field so that it’s machine readable, but could certainly see the value of a sub tag that provided context to the human reading the results of the machine parsing. Another proposal I read yesterday did something similar.
Yes, that's what I'm suggesting: an additional attribute or style that can allow freeform text that can be displayed based on the boolean value.
Maybe it would help to know if your podcast accepts single or multiple guests on an episode, suggesting whether it would be one to one conversation or panel based (requiring additional facilitation and possibly put people off being in a crowded discussion).
@si, that would be good to communicate and I think the right place for that would be in an additional attribute.
So here's my suggestion, in code:
<podcast:acceptsGuests description="We interview married entrepreneurs, and we love it when your
spouse can join, too!">yes</podcast:acceptsGuests>@theDanielJLewis good idea. That way, all contexts can be provided in the description attribute e.g. frequency, type of guests, any characteristics suitable.
Oh, and probably a URL feed for more information or applying.
<podcast:acceptsGuests url="[URL for information or application]" description="We interview married entrepreneurs, and we love it when your
spouse can join, too!">yes</podcast:acceptsGuests>