От 'pow-wow' до 'dummy': убито 1000 программистских слов — и это только начало
NewsMakerLinux Foundation устроила массовую зачистку кода.
Альянс по OpenUSD (AOUSD) и Academy Software Foundation (ASWF), действующие под эгидой Linux Foundation , представили обновлённое руководство по инклюзивной лексике и одновременно объявили о вступлении в AOUSD новых участников — Coca-Cola, Renault и Accenture. Документ адресован разработчикам и командам опенсорс-проектов и поясняет, какие выражения стоит исключать из документации, интерфейсов и исходного кода, а также на какие нейтральные формулировки их заменять.
С 2021 года ASWF использует рекомендации по замене устоявшихся, но проблемных терминов — в частности, отказ от пар «master/slave» и «blacklist/whitelist», а также от гендерно окрашенной лексики. Новая редакция расширяет перечень и добавляет примеры для повседневной инженерной практики, чтобы выровнять стиль в репозиториях и технических текстах.
Среди обновлений — корректировки «социально чувствительной» лексики. Вместо оборота «native support» предлагаются «core support» или «built-in support», чтобы избежать неоднозначных коннотаций. Слово «pow-wow» рекомендуется заменить на нейтральные «huddle» или «meeting», уместные для рабочих обсуждений и встреч.
Отдельно оговорены выражения с эйблистской окраской. Проверку корректности предлагают называть «validation check» или «consistency check», а не «sanity check». Для вспомогательных элементов кода предпочтительнее «placeholder», «stub» или «sample» вместо «dummy», чтобы исключить стигматизирующие ассоциации.
Есть и правки по лексике с насильственной коннотацией: в описаниях ошибок и зависаний вместо «hung» рекомендуется использовать «unresponsive» или «stalled». Такие формулировки точнее описывают поведение процесса и остаются нейтральными — и в сообщениях об исключениях, и в логах, и в комментариях к коду.
Обновлённый гайд опубликован на сайте ASWF.io ; при желании можно сверить изменения с версией 2021 года, доступной в архиве. Авторы подчёркивают, что документ призван упростить внедрение инклюзивной терминологии в ежедневные процессы — от коммит-сообщений и README до строк интерфейса и программных API — без ущерба для точности и инженерной ясности.
Альянс по OpenUSD (AOUSD) и Academy Software Foundation (ASWF), действующие под эгидой Linux Foundation , представили обновлённое руководство по инклюзивной лексике и одновременно объявили о вступлении в AOUSD новых участников — Coca-Cola, Renault и Accenture. Документ адресован разработчикам и командам опенсорс-проектов и поясняет, какие выражения стоит исключать из документации, интерфейсов и исходного кода, а также на какие нейтральные формулировки их заменять.
С 2021 года ASWF использует рекомендации по замене устоявшихся, но проблемных терминов — в частности, отказ от пар «master/slave» и «blacklist/whitelist», а также от гендерно окрашенной лексики. Новая редакция расширяет перечень и добавляет примеры для повседневной инженерной практики, чтобы выровнять стиль в репозиториях и технических текстах.
Среди обновлений — корректировки «социально чувствительной» лексики. Вместо оборота «native support» предлагаются «core support» или «built-in support», чтобы избежать неоднозначных коннотаций. Слово «pow-wow» рекомендуется заменить на нейтральные «huddle» или «meeting», уместные для рабочих обсуждений и встреч.
Отдельно оговорены выражения с эйблистской окраской. Проверку корректности предлагают называть «validation check» или «consistency check», а не «sanity check». Для вспомогательных элементов кода предпочтительнее «placeholder», «stub» или «sample» вместо «dummy», чтобы исключить стигматизирующие ассоциации.
Есть и правки по лексике с насильственной коннотацией: в описаниях ошибок и зависаний вместо «hung» рекомендуется использовать «unresponsive» или «stalled». Такие формулировки точнее описывают поведение процесса и остаются нейтральными — и в сообщениях об исключениях, и в логах, и в комментариях к коду.
Обновлённый гайд опубликован на сайте ASWF.io ; при желании можно сверить изменения с версией 2021 года, доступной в архиве. Авторы подчёркивают, что документ призван упростить внедрение инклюзивной терминологии в ежедневные процессы — от коммит-сообщений и README до строк интерфейса и программных API — без ущерба для точности и инженерной ясности.