Subject: Re: [Hls-interest] Inclusive Language

From: Roger Pantos <[email-masked]>
Date: Thu, 05 Nov 2020 11:03:48 -0800

> On Jul 31, 2020, at 10:09 AM, Roger Pantos <rpantos=[email-masked]> wrote:
> 
> 
> 
>> On Jul 24, 2020, at 2:12 PM, May, Bill <Bill.May=[email-masked] <mailto:Bill.May=[email-masked]>> wrote:
>> 
>> 
>> 
>>> On Jul 24, 2020, at 12:07 PM, John Bartos <bartsjb=[email-masked] <mailto:bartsjb=[email-masked]>> wrote:
>>> 
>>> Thanks everyone for the support so far. Regarding intention, I don't believe that it matters at this moment. The fact that the terms can be interpreted in that way is the issue, and it's clear that that interpretation does happen. We don't get to determine how people interpret it. Furthermore, people reading the spec don't have the context Bill provided here which digs into its origin.
>>> 
>>> I don't want to get caught up on semantics, but I see it like this: the two files are presented hierarchically and one is called "master". I don't think it's a stretch if someone interprets the other as "slave”.
>> 
>> I’m not going to debate here, but you’re exactly caught up on semantics.  
>> 
>> The whole argument is that you’re interpreting a phrase in a way that wasn’t intended when the definition in the specification explicitly states a different interpretation.
>> 
>>> 
>>> To be clear I'm not blaming or attacking the authors. What I am saying is that we can improve ourselves.
>>> 
>>> As for the terms, I like "playlist" over "rendition". So we have:
>>> Main playlist
>>> Variant playlist
>>> Content playlist
>>> Root playlist
>>> Index playlist (I do agree with JL, and I think we can acknowledge the prevalence of "index.m3u8")
>>> And for the segments:
>>> Media playlist
>>> Variant playlist (again, but in a different context. It is a variant instead of it contains variants, which is a bit confusing imo).
>>> 
>>> I have been using Main/Media at work for a while now and have not run into any confusion yet. So I prefer those.
>> 
>>> 
>>> For next steps, I think we should narrow down the above and then I'll send out a poll. Of course until Apple/Roger weighs in this is all voluntary and up to each organization to implement. But as Bill said, consistency is good.
>> 
>> 
>> I believe that the term "Master Playlist” is the only term up for consideration to be changed.  
>> 
>>  “Media Playlist”, “Variant Playlist” and “Rendition” have exact meanings in the specification and are used consistently and correctly.   I’m not aware of any objections to these terms .  Is there?
>> 
>> If not, they should not be up for any type of change.
>> 
>> In addition, I don’t believe any poll we have would be binding and may actually be counterproductive.
>> 
>> Roger is exacting in his terminology and if Apple decides that it should be changed, I trust him to come up with an exact term that will correctly describe the relationship.
>> 
>> Unless someone believes that there is something else offensive in the terminology in the specification, I believe that this conversation raised the point and should wait for Roger’s official verdict.
> 
> Hi folks. I’m catching up after a few days of vacation and saw this thread. I don't have an answer for you yet but I want to acknowledge the discussion
> 
> I agree that the name "Master Playlist” is an issue that we should consider seriously. That said, I also want to make clear that changing it is by no means free. While it’s easy enough to search-and-replace in the current Internet-Draft, we have also have an RFC and over 10 years of documents and videos produced by Apple and others that use the current name. Some of that can change; some cannot. A new name will add friction to learning and will trigger a long tail of “what’s this, oh, do you mean that?” type of conversations.
> 
> So while we might change the name, it’s not a casual decision. And, this isn’t the only such discussion going on within Apple right now. Technologies other than HLS are facing the same or similar questions. Since I recognize that my own biases may prevent me from judging the true weight of this problem, I think that it’s important that I seek broader input than I usually do. 
> 
> So, that’s what I’m doing now. Thanks for your patience in the meantime.

Okay, I finally have a response on this for you all. Thanks for your patience.

Inclusive language is an important issue that we take seriously. Apple has a specific initiative to improve the language we use and that we encourage our partners to use. This has driven an update to our Style Guide, https://help.apple.com/applestyleguide, which specifically is taking immediate action on the use of some terms, notably blacklist/whitelist and master/slave.

We are committed to improving the inclusivity of our language overall. This message concerns the term “master” that is used in HLS and forms a major part of the way that HLS sessions are referenced and described in other places and documents.

Because it’s part of the “interface” to HLS we want to proceed carefully; we went and looked at several communities, and did a survey of the style guides of various standards bodies, such as ISO (https://www.iso.org/ISO-house-style.html).

Where ‘master’ is part of a term that is cited across an industry (e.g. in video production the idea of a ‘mastering display’), the introduction of a new term needs to respect not only the place where it is defined, but also the places where it is used (e.g. to avoid conflicts or confusion when it is cited). A new term also needs to be introduced in a way that doesn’t cause dislocation, (where the origin/meaning of either the new or old term is no longer clear from the base specification).

At this point, we feel that the disruption caused by an immediate, abrupt, change of a well-established term of art — such as HLS master playlist — is not justified.

We are, however, keeping the question of changing this term open, so we can have a conversation with the community about your need for change, and considerations over both the alternatives and how we might orchestrate a harmonious change without causing dislocation or disruption.

We will also avoid using “master" for new terminology. 

Roger Pantos
Apple Inc.
> 
> 
> Roger Pantos,
> Apple Inc.
> 
>> 
>> Thanks, 
>> Bill
>> 
>> -- 
>> Hls-interest mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/hls-interest <https://www.ietf.org/mailman/listinfo/hls-interest>
> -- 
> Hls-interest mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/hls-interest <https://www.ietf.org/mailman/listinfo/hls-interest>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 6 Nov 2020 09:10:29 +1100

Hi Roger,

Thanks for the update.

One thing to note (and I'm writing only in an individual capacity) -- if one day you want to get a specification onto the Standards Track, this will be an issue.  Even if you only publish on the Independent Stream, the ISE may impose a terminology review on you. 

That's not to say that the reasons you give for leaving the terminology as-is won't be persuasive, but it will require a discussion, and that could be divisive (thereby consuming time and effort).

It might be helpful to lay the foundation for an eventual change, even if it isn't made yet. For example, the first use of 'master' in draft -08 is:

> A Playlist is either a Media Playlist or a Master Playlist

If you were to introduce an alternative term, it would reduce the impact of an eventual change in the future, e.g.:

> A Playlist is either a Media Playlist or a Master Playlist (also known as a Main Playlist).

You could also introduce some text explaining the situation, e.g., something like:

~~~
Future revisions of this specification may use the term 'Main Playlist' in place of 'Master Playlist'. The latter is used here to avoid confusion by those familiar with previous revisions of this specification, but 'Main Playlist' is preferable.
~~~

This would not only prime the audience for a future change, it would also help to break what could be a deadlock with the other standards efforts you refer to -- I suspect that similar reluctance to change elsewhere is justified by "look, HLS isn't changing."

Cheers,

> On 6 Nov 2020, at 6:03 am, Roger Pantos <rpantos=[email-masked]> wrote:
> 
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/hls-interest
>> 
>> -- 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hls-interest
> 
> -- 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hls-interest

--
Mark Nottingham   https://www.mnot.net/

---

From: Roger Pantos <[email-masked]>
Date: Thu, 05 Nov 2020 15:58:50 -0800

> On Nov 5, 2020, at 2:10 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Roger,
> 
> Thanks for the update.
> 

Thanks Mark. That seems like a solid idea.

Roger.