Phriction Trusted Firmware Collaboration Community Guidelines Community Inclusive Language History Version 3 vs 10
Version 3 vs 10
Version 3 vs 10
Edits
Edits
- Edit by abhishek-pandit, Version 10
- May 20 2021 5:50 PM
- Edit by abhishek-pandit, Version 3
- Dec 9 2020 3:39 PM
Edit Older Version 3... | Edit Current Version 10... |
Content Changes
Content Changes
# 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).
# 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 may not normally be part of code but are barred from use within the project regardless.
- Blackball
## Coding Standard
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 does not 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).
```
# 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 may not normally be 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' not 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).
```