Words matter. They have the power to inspire and unite, fostering a culture where we can be our true selves. At Dell Technologies, we’ve established an inclusive language philosophy where we embrace diversity and inclusion (D&I), no matter what language we’re using – this includes coding language. After all, our code speaks for our technology.
I’m part of a working team from across Dell Technologies that meets regularly to identify and remediate non-inclusive language, no matter the platform where it’s used – be it web pages, product marketing material, user manuals, user interface text, and the source code that make up these products.
Read More: DEA-1TT4: Dell EMC Information Storage Management (DECA-ISM)
Below are examples of non-inclusive words with alternatives:
- Master/Slave
- Alternatives: Primary/Secondary, Parent/Child, Active/Standby
- Blacklist/Whitelist
- Alternatives: Denylist/Allowlist, Blocked/Allowed, Reject/Accept
- Blackhat/Whitehat
- Alternatives: Unethical hacker/Ethical hacker
- Segregate
- Alternative: Separate
- Man-hour/Man-day/Man-month/Manpower
- Alternatives: Person-hour/Person-day/Work-month/Workforce
- Rule of thumb
- Alternatives: Guideline
Dell’s goal is to replace non-inclusive text within application source code. Identifying and remediating every instance of non-inclusive text within our products represents a large and complex set of challenges. I’ll walk you through lessons we’ve learned on how to increase inclusion.
There are various ways to remove non-inclusive text from software products, including manual inspection of every line of code, building a tool to globally find and replace instances of offending text or putting policies in place to prevent new instances from being added to source code repositories. However, when developers are required to scan code manually or invoke a secondary tool to do so, there are two possible side effects: the process will be circumvented or releases will be delayed as D&I adds another layer of activity to the development and deployment process.
To address these challenges, I formed a multi-step solution that relies on automation with intelligent, assistive tools that become a natural part of the software development process:
◉ At coding time: Automated source code scanning via an editor or integrated development environment (IDE) extension.
◉ At build time: Static code analysis via a custom lint tool invoked during developer local builds.
◉ At commit time: Automated source code scanning via a Git Webhook when code is pushed to a repository.
Step 1) Driving inclusiveness at coding time – The goal of the first step is to help developers catch non-inclusive text as they write code. For example, popular IDEs, such as Microsoft Visual Studio Code (VSCode), perform syntax checking and error highlighting in real time. This boosts productivity since it’s easier and quicker for a developer to fix an error in code just written. If you apply the same philosophy to D&I scanning, you can achieve the same goal: identification and remediation of non-inclusive text without impacting developer productivity. To try this, I built a VSCode extension to automatically search for and mark up instances of non-inclusive text in real time as though they are syntax errors (see Figure 1).
0 comments:
Post a Comment