Originally published June 30, 2020
In the last few weeks, the anti-racism protests and movements around the world have sparked a need for action and impact in many of us. At D2L, we stand against racism and support equality and justice, always. We are using this opportunity to take an inward look at ourselves, our processes, and our deliverables to see where we can be more inclusive and better allies.
The D2L Technology, Engineering, and Design (TED) team is committed to doing our part and have implemented an Inclusive Language development policy to help guide our teams and foster inclusion inside of our own organization.
In doing research and listening to the voices of our learners, we know that oppressive language can be present in our daily lives and can be harmful to inclusion efforts. Our Inclusive Language policy will help us to avoid oppressive terminology when building our software and equip us with alternative language when interacting with other software vendors and partners. We are also auditing our legacy code, infrastructure, and features for oppressive terminology that we can replace with more helpful and inclusive alternatives.
Many of the changes we are making won’t be visible to Brightspace users, but you might notice some small updates to default language terms in our user interface (UI) and supporting documentation. For example, we are moving away from using the terms “blacklist” and “whitelist” to describe the restrictions/allowances of specific sets of users, tags, IP addresses, API routes, etc. Any changes will be listed in our release notes so that administrators can make any corresponding updates to custom language packs or additional documentation.
At D2L, we are committed to creating a safe and inclusive environment for all – for users of Brightspace, our partners, and our employees. If you have any suggestions for further improvements we can make to terminology or language in Brightspace, please let us know by commenting here, contacting Support, or creating a PIE item for larger ideas.