I can just say that I totally agree with the topic. Il giorno sabato 11 luglio 2020 alle 10:38:10 UTC+2 Lukas Kahwe Smith ha scritto:
> Aloha, > > So the topic of naming things has become even more discussed as in the > previous years in part due to recent protests in the world. > > I think most of us are familiar with the saying "There are only two hard > things in Computer Science: cache invalidation and naming things." > > Many of us are also familiar with the concept of design patterns and the > value there is when discussing approaches to having commonly understood and > agreed upon words for these design patterns. > > Let me also add this link here to explain that language in fact also > shapes how we think > > > https://www.ted.com/talks/lera_boroditsky_how_language_shapes_the_way_we_think > > So I hope this video helps to understand that technical jargon isn't just > technical jargon. But I still often hear the argument that changing words > isn't really needed since it is not a big deal and there are bigger issues. > So I invite you to read this twitter thread > > https://twitter.com/btanderson72/status/1279507428128718848?s=20 > > Now I do agree that there are bigger issues but those go beyond the scope > of this group. I do however think that offering inclusive terminology is > within the scope of this project, especially since it is very useful for us > all to agree on the same terminology. > > More importantly we have come to accept a lot of very inaccurate terms for > technology that needlessly complicate things for new comers. > > For example if you don't know the term "whitelist" or "blacklist" you > don't know what they mean. While black might refer to the absence of light, > white might also refer to the absence of color. As such "allowlist" or > "denylist" are simply more expressive ways to describe things. Similar > master/slave isn't as accurate as primary/replica to describe the > relationship (though of course depending on the specific context there > might be even better terms to use). So all I want to say is that if you > don't agree that technical jargon can be offensive, I hope you still agree > that if we re-use terms from non technical contexts, we should make sure > that the analogy is as self-descriptive as possible to prevent > misunderstandings with new comers or even just people we interact with as > part of our work (product owners, investors etc). > > As part of the IETF there is a a document that addresses the above noted > terms: > > https://tools.ietf.org/id/draft-knodel-terminology-00.html > > Chromium project also has some more guidelines that cover also terms we > might commonly find in documentation or comments > > > https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md#racially-neutral > > Now there has also been discussion about the git master branch (and yes it > is derived from master/slave > https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask?WT.mc_id=-blog-scottha#L231-L232, > > though I don't think it matters much if it does or not, see above twitter > thread). > > Here to it might make sense to actually recommend projects to not use > master as the default branch for “latest” > > > https://mikevanriel.com/2020/07/07/master-has-always-been-a-poor-branch-name/ > > Python has been a language and community that has already done steps in > this direction a long time ago > > https://bugs.python.org/issue34605 > > https://github.com/django/django/pull/2692 > > Drupal as well https://www.drupal.org/node/2275877 > > Other PHP projects like PHPUnit and Doctrine, Symfony more recently > > I have started a discussion about this on slack a while ago already but > would like to bring this to the list. Based on the discussion on slack > there were opinions that ranged from: > > * do nothing > > * agree to not use those terms in PSRs > > * create a bylaw to clarify that those terms will not be used in PSRs > > * create a PSR as a recommendation for a unified (and inclusive) language > used within Frameworks when it comes to naming things. (and then a bylaw to > also follow that PSR) > > I believe the latter should be done. This is also a huge benefit (not only > about the currently hot debates) for PHP developers as they know how things > are named across libraries. We had a similar topic about PSR-14 "Events" > (what do people mean when they say "Events"). So the scope can be wider > than “just” inclusive language. > > I also believe this topic is very much within the scope of FIG. We have > PSRs for PHPDoc naming. I once proposed a PSR for security disclosure which > got abandoned not due to a discussion about the scope but simply because > work was never pushed forward sufficiently. > > We may or may not include other terms than those I mentioned above. If the > list needs to be expanded later we can always publish another PSR, just > like for PHPDoc etc. > > From what I have seen on the web, this topic tends to get incredibly > heated. As such I would ask everyone to spend a few extra minutes > formulating their replies to ensure maximum clarity. Also I would ask > readers to spend some additional time digesting responses and potentially > throttle your responses. I really hope we can have a productive discussion > here and not a shouting match. > > There might be people reading this and they think it's not as important, > but still would be up for adopting it, if a Working Group would work on it. > Feedback as such would be helpful as well from this list > > -- > > regards, > > Lukas > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/3a7d9429-3ffc-4438-9e8f-7b9bada9b7fan%40googlegroups.com.
