Remove podcast:images #584
-
|
The new podcast namespace defines
I would like to propose that It won't make any impact on any podcast app, since podcast apps will fall back to the standard image tags. It won't make any impact on podcasters, almost none of whom are using this tag. Its "replacement" is more capable, and, importantly, also in use. As a matter of policy, I believe that we should support tags that are used by the community - but remove tags that go un-used, or that we have made a mistake with. That would be the sign of a mature specification and ecosystem. Since we have empirical evidence that this tag is unused after more than 12 months in the specification, it's hard to argue that it should remain in a specification. |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 15 replies
-
|
Can you expand on how removing an unused tag from the namespace is a benefit for the community? I’m having trouble understanding how keeping it takes away support from any other tags. On the other hand, I have concerns that removing tags will set a precedent where developers will take a "wait and see" approach to make sure their efforts won’t be wasted. |
Beta Was this translation helpful? Give feedback.
-
|
We can, of course, keep a tag which is unused. No harm comes from filling
the podcast namespace with all kinds of tags that nobody uses, and that are
duplicates of objectively better tags which are. Where storage is free, we
can come up with all kinds of ideas, and even if they fail to be adopted,
keep them as part of the specification.
But, I believe we're better than that. The namespace - **our** namespace -
should be curated to *only* offer features that advance podcasting. We
should be proud enough to allow input from elsewhere, and also proud enough
to keep our specification compact and focused.
By making it easy to support *all* features in Podcasting 2.0 - and not
have to sift through a raft of unused, badly-drafted features to work out
which are actually in-use - we will encourage adoption of the namespace as
a whole.
I have concerns that removing tags will set a precedent where developers
will take a "wait and see" approach to make sure their efforts won’t be
wasted.
Of course, this is the approach many developers have taken anyway. You
could argue that Libsyn, Megaphone and ART19 have taken that approach to
the entire project. And, who could blame them - tags like this, which are
unused, are a reason why they would think twice about any form of support.
I believe that every feature on Podcasting 2.0 should have an "owner", who
evangelises about the feature and works to get it implemented. If we fail
to get a feature enthusiastically adopted by the community, we should
examine the reasons why, and retire that feature.
The reasons why here are:
1. It was an overly open specification, with no recommendations for use, or
examples of use-cases. It's unclear why you'd ever want to use it. We
should learn from that.
2. It was also a specification which was too constricting, since it didn't
take into account those that wanted images of different aspect ratios, or
even other formats like video. We should learn from this, too.
3. A feature existed already in the media namespace. It was well specified,
and could have been extended to specify filetypes. But we failed to do our
due diligence in researching it, and produced a less-capable duplicate.
4. It had no evangelist to promote its use; and as a consequence is only
implemented in one podcast app, and not by any podcast hosts. If it's not
supported by the Podcasting 2.0 podcast, that's a pretty large red flag
that the community doesn't want it.
I'm keen to see this namespace as a living, breathing thing: not a dumping
ground of unwanted failures. Deprecation of this feature would be the right
thing to do.
…On Sat, 18 Nov 2023, 06:09 Nathan Gathright, ***@***.***> wrote:
Can you expand on how removing an unused tag from the namespace is a
benefit for the community? I’m having trouble understanding how keeping it
takes away support from any other tags. On the other hand, I have concerns
that removing tags will set a precedent where developers will take a "wait
and see" approach to make sure their efforts won’t be wasted.
—
Reply to this email directly, view it on GitHub
<#584 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABYUBJ6ACMBQMQY7V3NSITYE677LAVCNFSM6AAAAAA7IPFIQOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMMBSHA3TQ>
.
You are receiving this because you authored the thread.Message ID:
<Podcastindex-org/podcast-namespace/repo-discussions/584/comments/7602878@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
@jamescridland please know I agree 100% with what you are saying. However can we also just point out that many tags being added are not for the benefit of podcasters but for music which goes against your "The namespace - our namespace - should be curated to only offer features that advance podcasting" I personally questioned why PodcastIndex or this namespace would be promoting things like livestreams and music when that too is technically not the definition of Podcasts (in the traditional sense). I think the namespace will become bloated with useless tags and while am not against adding tags like livestream or others that grows the media landscape. I think the namespace might be getting lost with its mission of supporting podcasters. It's almost like another namespace should enter of music or even live-streaming. But then you're starting from scratch and gee who wants to do that when you can just add anything to this one. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I ran some numbers across all 4 million podcasts and found 647 podcasts with the |
Beta Was this translation helpful? Give feedback.
-
|
647 is still a really low number in comparison to over 4million. And I have to agree that the image tag is kinda obsolete when you think YouTube doesn't accept it but does accept the RSS media tag which is what images is meant to do. |
Beta Was this translation helpful? Give feedback.
-
|
what's the number using v4v? |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to ask questions in a methodical way that ensures I fully understand. If the questions don't make sense, humour me please. I wouldn't ask it if it wasn't necessary for me to get a full picture in my head. First question: Are you proposing that we remove any tag that doesn't reach a particular threshold within the "12 months" time frame you mentioned? |
Beta Was this translation helpful? Give feedback.
-
I'm proposing that we review, after an appropriate time, whether a particular feature has gained any traction - and, if it has not, to deprecate it. "Deprecation" means removing from the main documents, shifting the documentation to a "deprecated" tag. In a validator, you might see a warning that the feature is deprecated. It would not be an error and would not fail validation - it's deprecated. I'm not wedded to a 12 month timeframe. In fact, the proposal was made in October 2020. It's had more than three years for people to use it. |
Beta Was this translation helpful? Give feedback.
-
|
How do we determine an appropriate time:adoption ratio? We currently have no formal deprecation policy, so everything would have to be spelled out in black and white before taking action. |
Beta Was this translation helpful? Give feedback.
-
|
Taking one step back: should we adopt a policy of deprecating features that haven't gained adoption? I think we should. But I suspect it might be sensible taking these on a case by case basis, and just as we accept proposals for new features, we also accept proposals for deprecated ones. I don't think a set timeframe is appropriate really. |
Beta Was this translation helpful? Give feedback.
-
|
By it's nature, it wouldn't be something that's a rush. So, as a start I can create a Discussion category for proposing deprecations and move the discussions there. |
Beta Was this translation helpful? Give feedback.
-
|
@daveajones I'd like to recommend that removing this tag is announced in phase 7. It fails the test of being implemented in enough apps (as I understand it, it's only implemented in one); and it fails the test of being adopted by many podcasts after two years. It's a duplicate of an existing tag that existed before we worked on it, and that does a better job (since it deals with different aspect ratios). |
Beta Was this translation helpful? Give feedback.
-
|
It's @jamescridland's #3 issue, "It is limited only to square thumbnails," that I think makes this feature almost useless. I think we do need a way to specify additional images, especially 16:9 and circle-friendly. That's what I thought we could do with Something to keep in mind regarding development is that it always goes two ways: the publishing tools must implement support for users (and highlight the new feature with education), and podcasters must use it. It's that second one that might be the bigger barrier because not all podcasters have alternate branding images, let alone even know there could be be a need for different images. In this case, I care less about the method for supporting alternative images and more about simply having the support that's flexible for current and future applications. |
Beta Was this translation helpful? Give feedback.
-
I'll be frank: I don't agree with this. The point of RSS is that you can use more than one namespace. There is no benefit to be gained by insisting that all other namespaces are "not invented here" and thus not useful. The Media RSS namespace is being used by 9,000 podcasts. Just as we'd not recommend that the |
Beta Was this translation helpful? Give feedback.
-
|
It's all right there on this very repo's landing page.
Plus, it's been said many times by both @daveajones and Adam that they want the Podcast Namespace to eventually be a drop-in replacement so developers could get all the features they need from the Podcast Namespace instead of having to also use the "iTunes" namespace or any others. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, well. shrug Good luck with it all |
Beta Was this translation helpful? Give feedback.
-
|
@jamescridland i take it you have a different view of the podcast namespace. I do agree we should not be reinventing the wheel. (For others in this convo) As we know the likes of Spotify and Apple won't follow unless everyone tomorrow removed iTunes namespace from their podcast which I can tell you will not happen. We need to coexist. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like we've reached consensus in Australia, for starters :-) I see no reason why the project's goals couldn't be changed to reflect the interests of its constituency. That sort of already happened with the mission statement which was changed from being about protecting free speech to being about open standards. We don't need to make this standard into a monopoly to serve that mission, it can coexist. |
Beta Was this translation helpful? Give feedback.
-
This was done on 9b1c3fb And a new https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/tags/image.md - permalink |
Beta Was this translation helpful? Give feedback.
This was done on 9b1c3fb
And a new
podcast:imagetag was formalized with #716https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/tags/image.md - permalink