포용성은 Android 문화의 핵심이며, Google에서는 상대방을 존중하는 자세를 소중하게 여깁니다. 따라서 모든 사람이 편견과 차별로 인한 피해를 받지 않으면서 참여할 수 있어야 합니다. 하지만 코드베이스, 사용자 인터페이스, 문서에 포함된 용어로 인해 이러한 차별이 계속될 수 있습니다. 이 정책은 코드, 인터페이스, 문서에 무례한 용어가 포함되지 않도록 안내를 제공합니다.
정책
직접적 또는 간접적으로 경멸하거나, 감정을 상하게 하거나, 지속적으로 차별하는 용어를 사용해서는 안 됩니다. 이는 포용적인 문서 작성 방법에 관한 Google의 안내와 일맥상통하는 내용입니다.
이 정책의 범위에 해당하는 항목에는 어떤 것이 있나요?
참여자가 Android에서 작업하면서 읽을 수 있는 모든 항목을 포함하나 이에 국한되지 않습니다.
- 변수, 유형, 기능, 파일, 빌드 규칙, 바이너리, 내보낸 변수의 이름
- 테스트 데이터
- 시스템 출력 및 표시 항목
- 댓글 및 문서(소스 파일 내부 및 외부)
- 커밋 메시지
원칙
- 예의 지키기: 작동 원리를 설명할 때 무례한 표현은 필요하지 않습니다.
- 문화적으로 적합한 언어 사용: 일부 단어에는 역사적이거나 정치적인 의미가 포함된 경우도 있습니다. 이 점을 고려하여 대안을 사용하세요.
특정 용어를 사용해도 괜찮은지 어떻게 알 수 있나요?
위의 원칙을 적용하세요. 궁금한 점이 있으면 android-community@googlegroups.com으로 문의해 주시기 바랍니다.
피해야 할 용어의 예로는 무엇이 있나요?
이 목록에 모든 예가 포함되어 있지는 않습니다. 여기에는 자주 사용되는 몇 가지 예시가 포함되어 있습니다.
댓글을 달았을 때 가치가 창출되는지 고려해 보는 것이 좋습니다.
댓글을 완전히 삭제하는 것이 가장 좋은 방법일 때도 있습니다. 예를 들어
verify_header
라는 기능 앞에 '헤더 온전성 확인'이라고만 적힌 댓글은
공개 API의 문서 댓글인 경우에도 어떠한 가치도
더해 주지 않습니다. 확인해야 하는 항목을 더 구체적으로 지정하세요.
예를 들어 '헤더에서 범위 외의 값이 있는지 확인하세요'라고 적는 것이 좋습니다.
용어 | 추천 대안 |
---|---|
마스터/슬레이브 | 기본/복제, 기본/보조, 리더/팔로어, 컨트롤러/디스패처, 관리자/작업자, 믹서/리프, 애그리게이터/콜렉터, 게시자/구독자, 시작자/대응자 |
레드라인 | 우선순위 행, 변경사항 추적, 디자인 사양, UI 주석, 예외, 이상치, 특수 사례, 교체 목록 |
화이트리스트 | 허용 목록, 허용됨, 포함 목록, 안전 목록 |
블랙리스트 | 거부 목록, 차단됨, 제외 목록, 차단 목록 |
(다크|라이트) 그레이리스트 | API:
|
크레이지, 인세인, 크리플 | 차별 언어 피하기에서 가이드라인을 확인하세요. |
온전성 확인 | '확인'이라는 단어는 하나의 뜻만 전달할 때가 많습니다. 유효성 검사, 검증, 빠른 확인, 초기 확인, 신뢰도 확인, 건전성 확인, 보정 확인, 준비도 확인이라는 표현을 고려해 보세요. |
더미 | 사용되지 않음, 자리표시자, 노옵스(no-ops), 베이스, fake/mock/stub. |
그랜드파더링 | 면제, 기존, 보류, 이월, 기준, 이전 |
성별 대명사(예: 그 또는 그녀) | 복수 대명사(그들) |
중간자(MITM) | 경로별 공격자 |
(블랙|화이트|그레이) 해트 | 윤리/비윤리 |
일급 객체 | 핵심 기능, 빌트인, 최상위 |
이 정책을 위반하는 항목이 인터페이스에 포함되면 어떻게 되나요?
이러한 상황은 이전에 몇 차례 발생했으며, 특히 사양을 구현하는 코드에서 나타났습니다. 이때 사양과 다른 표현을 사용하면 구현 내용을 이해하기 어려워질 수 있습니다. 이러한 상황이 발생했다면 다음 조치 중 하나를 사용하여 편향성을 줄이시기 바랍니다.
- 대체 용어를 사용해도 내용을 이해하는 데 문제가 되지 않는다면 대체 용어를 사용합니다.
- 인터페이스 작업을 실행하는 코드 이외의 상황에서는 용어를 전파하지 마세요. 필요한 경우 API 경계에서 대체 용어를 사용하세요.
- 언어를 직접 수정할 수 없다면 관련 팀에 버그를 제출하세요.