Proposal - <podcast:acceptsGuests>

[jamescridland]

EDITED:::

I'm not sure this really fixes anything. The existence of the word "guest" in episode notes seems just as easy to work out whether a show has a guest or not. Can we withdraw this proposal?

---

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:person tag)
• A method for podcast hosting companies to only ask about podcast:person for 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

[daveajones]

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. 🤔

[theDanielJLewis]

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.

[HersheyCognosco]

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.

[theDanielJLewis]

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.

[HersheyCognosco]

@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

1. May podcasts don't have websites
2. 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.

[genebean]

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.

[jamescridland]

@genebean - I'm absolutely fine with that.

[theDanielJLewis]

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?

[jamescridland]

I'd really like to avoid freeform text. It's impossible for computers to understand.

[theDanielJLewis]

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."

[drpancake]

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.

[genebean]

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.

[theDanielJLewis]

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.

[si]

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).

[theDanielJLewis]

@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>

[si]

@theDanielJLewis good idea. That way, all contexts can be provided in the description attribute e.g. frequency, type of guests, any characteristics suitable.

[theDanielJLewis]

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>

[geeknews]

Since we are all heading to no email in feeds, guest booking services will need to do their jobs and start researching shows to see if they have guests versus spamming podcasters with guest bookings. The original inquiry proposal is enough.

podcast:acceptsGuestsyes</podcast:acceptsGuests> - this podcast regularly has guests on its episodes

podcast:acceptsGuestsno</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

This way we help the booking services understand they do not need to reach out to this show but they still need to research the show and maybe even listen to it.

[Alex-Sanfilippo]

I think the solution here is to show no email address in feeds. Then services like PodcastHawk cannot be used to spam hosts. (I get over 50 emails a day with pitches from people using that service alone.)

The RSS I dream of is the one that has LESS information in it, not more. Anything to keep the wrong people away is ideal.

The first thing we all need to do is remove the email address from RSS; that's the important one.

Going back to the original thought here, "guests y/n" one thing I run into ALL the time is people telling me, "I've not had guests because I didn't know how to, but since meeting PodMatch, I know have a way to find them." So even if people say no to guests today, doesn't mean they won't want them tomorrow. <--- Just a thought!

[ryan-lp]

@jamescridland Have you considered inferring this information from the person tags? If you look through the people in the feed and find that there are guests, that would be evidence that the podcast accepts guests. I will consider each of your motivations below just to check that the idea could work:

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"

Yes, I think this could be done with the inference approach, except for new podcasts with few enough episodes to really show any evidence of it, but I think a new podcast probably won't suffer any inconvenience from being discovered and contacted by anyone. Or a problem could arise if the feed only includes a short moving window of the most recent N items and the last guest appearance has already scrolled off that window. But probably this would still work in most cases, since the items that are in the feed could logically be assumed to be representative of the types of episodes we can expect to get.

• 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:person tag)

Ditto.

• A method for podcast hosting companies to only ask about podcast:person for each show if that show has guests, and otherwise not surface that set of dialogs

But wouldn't it be good to include a person tag for the main host (and the co-host if there is one) even if the podcast doesn't have guests? I'd imagine there would be creative ways to solve any UX problem to make it less intrusive even without the proposed tag.

• 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

I haven't seen the tool, would it not work to infer the has-guests status in this case?

• 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

Would this not work with the inference approach?

I see the intended use case, but I'm also conscious of feature/tag creep. If we are to get a new tag for each and every boolean fact you might imagine to be useful, that adds to the complexity of the software libraries people need to build and maintain to read and parse podcast feeds, and keep them up to date with the changing standard. So if it is at all possible to exclude proposed boolean tags for facts that can already be derived from other data that is already in the feed, then I suggest we exclude such tags in order to not have the tag set grow out of control.

[snookfin]

The RSS feed just doesn't feel like the right place to provide this type of information. I think information like this should live on your podcast website, and your feed provides a link to your site.

[jamescridland]

I'd like to withdraw this proposal.

The ideal use-case is: "Oh, this podcast doesn't have guests - I'll not bother emailing them with my guests", but this information is already relatively clear from other things anyway, and I don't believe it worth cluttering up the RSS feed with another tag.