Phriction Trusted Firmware Collaboration Community Guidelines Community Inclusive Language History Version 5 vs 6
Version 5 vs 6
Version 5 vs 6
Edits
Edits
- Edit by abhishek-pandit, Version 6
- Dec 9 2020 5:45 PM
- Edit by abhishek-pandit, Version 5
- Dec 9 2020 5:42 PM
« Previous Change | Next Change » |
Edit Older Version 5... | Edit Older Version 6... |
Content Changes
Content Changes
(WARNING) Draft in review
# Inclusive Language Policy
TrustedFirmware.org has strict policy that requires use of inclusive language in all the projects which are part this organization. Any terminology that is against this policy is banned from being used in the projects.
## Coding Standards
Maintainers are required to adopt the specific addition below to their coding guidelines and ensure adherence to it. Project has code and documents which predate this policy and the current guideline doesn't mandate a retrospective action.
```
==================
Inclusive Language
------------------
The use of the terms "blacklist / whitelist" and "master / slave" in
code and documentation is considered deprecated and should be avoided
for new submissions. The former can usually be substituted with
"blocklist / allowlist". Suitable substitutes for the latter should be
selected based on the individual situation. Common examples include
"controller / peripheral", "host / device", "initiator / target" or
"main / secondary".
Exceptions can be made in cases where the code or documentation is
directly referring to hardware that already uses these terms (e.g. in
register names) or to a common industry standard (until an updated
version of that standard avoiding these terms is available).
```
(WARNING) Draft in review
# Inclusive Language Policy
TrustedFirmware.org has strict policy that requires use of inclusive language in all the projects which are part this organization. Any terminology that is against this policy is banned from being used in any part of TrustedFirmware.org.
## General terms
Terms listed here is not normally part of code but are barred from use within the project regardless.
- Blackball
## Coding Standards
Maintainers are required to adopt the specific addition below to their coding guidelines and ensure adherence to it. Project has code and documents which predate this policy and the current guideline doesn't mandate a retrospective action.
```
==================
Inclusive Language
------------------
The use of the terms "blacklist / whitelist" and "master / slave" in
code and documentation is considered deprecated and should be avoided
for new submissions. The former can usually be substituted with
"blocklist / allowlist". Suitable substitutes for the latter should be
selected based on the individual situation. Common examples include
"controller / peripheral", "host / device", "initiator / target" or
"main / secondary".
Exceptions can be made in cases where the code or documentation is
directly referring to hardware that already uses these terms (e.g. in
register names) or to a common industry standard (until an updated
version of that standard avoiding these terms is available).
```
(WARNING) Draft in review
# Inclusive Language Policy
TrustedFirmware.org has strict policy that requires use of inclusive language in all the projects which are part this organization. Any terminology that is against this policy is banned from being used in the projects.any part of TrustedFirmware.org.
## General terms
Terms listed here is not normally part of code but are barred from use within the project regardless.
- Blackball
## Coding Standards
Maintainers are required to adopt the specific addition below to their coding guidelines and ensure adherence to it. Project has code and documents which predate this policy and the current guideline doesn't mandate a retrospective action.
```
==================
Inclusive Language
------------------
The use of the terms "blacklist / whitelist" and "master / slave" in
code and documentation is considered deprecated and should be avoided
for new submissions. The former can usually be substituted with
"blocklist / allowlist". Suitable substitutes for the latter should be
selected based on the individual situation. Common examples include
"controller / peripheral", "host / device", "initiator / target" or
"main / secondary".
Exceptions can be made in cases where the code or documentation is
directly referring to hardware that already uses these terms (e.g. in
register names) or to a common industry standard (until an updated
version of that standard avoiding these terms is available).
```