Hi y’all
I’d like to propose and exchange ideas about what we can do about process and initiatives to adopt and encourage Diversity, Equity and Inclusion (DEI), starting but not limited to inclusive terminology.
Context
We as programmers are used to use some language that have a negative impact when used the standard terminology such as:
- master/slave
- whitelist/blacklist
- dummy
- etc
For people where the cultural bias has never been close to witness what does some terminology implies and hurt (yes, hurt), it may not be that bad, but it actually is (source: I’ve been experienced that by my own). As Olle Johnson commented to me, is kind of something as basic as human decency. In my opinion, this can be an addendum or complement to what the Code de Conduct tries in conjunction with what our guidelines may have in place (if applies).
What I’m expecting is some kind of agreement on what we may need to do if the dry-rb community is open to take an inclusive position and openness to the current and future collaborators.
I acknowledge it may not be fast, nor easy to achieve (specially talking about public APIs), but is definitely doable if we are committed to.
What would this initiative include?
Basically every piece we can read on the projects:
- git branch → master → main (?)
- code
- documentation
- comments
- examples
Some efforts and guidelines we can take as example:
– Linux Kernel,
https://lkml.org/lkml/2020/7/4/229
Recent events have prompted a Linux position statement on inclusive
terminology. Given that Linux maintains a coding-style and its own
idiomatic set of terminology here is a proposal to answer the call to
replace non-inclusive terminology.
– Google Developers
We write our developer documentation with inclusivity and diversity in mind. This page is not an exhaustive reference, but describes some general guidelines and examples that illustrate some best practices to follow.
Thanks for you attention and please let me know what do you think about this proposal.
- Esparta
