사용자를 존중하는 코딩

포용성은 Android 문화의 핵심이며, Google에서는 상대방을 존중하는 자세를 소중하게 여깁니다. 따라서 모든 사람이 편견과 차별로 인한 피해를 받지 않으면서 참여할 수 있어야 합니다. 하지만 코드베이스, 사용자 인터페이스, 문서에 포함된 용어로 인해 이러한 차별이 계속될 수 있습니다. 이 정책은 코드, 인터페이스, 문서에 무례한 용어가 포함되지 않도록 안내를 제공합니다.

정책

직접적 또는 간접적으로 경멸하거나, 감정을 상하게 하거나, 지속적으로 차별하는 용어를 사용해서는 안 됩니다. 이는 포용적인 문서 작성 방법에 관한 Google의 안내와 일맥상통하는 내용입니다.

이 정책의 범위에 해당하는 항목에는 어떤 것이 있나요?

참여자가 Android에서 작업하면서 읽을 수 있는 모든 항목을 포함하나 이에 국한되지 않습니다.

  • 변수, 유형, 기능, 파일, 빌드 규칙, 바이너리, 내보낸 변수의 이름
  • 테스트 데이터
  • 시스템 출력 및 표시 항목
  • 댓글 및 문서(소스 파일 내부 및 외부)
  • 커밋 메시지

원칙

  • 예의 지키기: 작동 원리를 설명할 때 무례한 표현은 필요하지 않습니다.
  • 문화적으로 적합한 언어 사용: 일부 단어에는 역사적이거나 정치적인 의미가 포함된 경우도 있습니다. 이 점을 고려하여 대안을 사용하세요.

특정 용어를 사용해도 괜찮은지 어떻게 알 수 있나요?

위의 원칙을 적용하세요. 궁금한 점이 있으면 android-community@googlegroups.com으로 문의해 주시기 바랍니다.

피해야 할 용어의 예로는 무엇이 있나요?

이 목록에 모든 예가 포함되어 있지는 않습니다. 여기에는 자주 사용되는 몇 가지 예시가 포함되어 있습니다.

댓글을 달았을 때 가치가 창출되는지 고려해 보는 것이 좋습니다. 댓글을 완전히 삭제하는 것이 가장 좋은 방법일 때도 있습니다. 예를 들어 verify_header라는 기능 앞에 '헤더 온전성 확인'이라고만 적힌 댓글은 공개 API의 문서 댓글인 경우에도 어떠한 가치도 더해 주지 않습니다. 확인해야 하는 항목을 더 구체적으로 지정하세요. 예를 들어 '헤더에서 범위 외의 값이 있는지 확인하세요'라고 적는 것이 좋습니다.

용어 추천 대안
마스터/슬레이브 기본/복제, 기본/보조, 리더/팔로어, 컨트롤러/디스패처, 관리자/작업자, 믹서/리프, 애그리게이터/콜렉터, 게시자/구독자, 시작자/대응자
레드라인 우선순위 행, 변경사항 추적, 디자인 사양, UI 주석, 예외, 이상치, 특수 사례, 교체 목록
화이트리스트 허용 목록, 허용됨, 포함 목록, 안전 목록
블랙리스트 거부 목록, 차단됨, 제외 목록, 차단 목록
(다크|라이트) 그레이리스트 API:
  • (그레이리스트) 'SDK가 아닌 API 목록', '숨겨진 API 목록'
  • (다크 그레이리스트) '조건부 차단됨' 또는 특정 목록 참조 시 최대 대상 X
  • (라이트 그레이리스트) '사용 지양됨', '임시'
크레이지, 인세인, 크리플 차별 언어 피하기에서 가이드라인을 확인하세요.
온전성 확인 '확인'이라는 단어는 하나의 뜻만 전달할 때가 많습니다. 유효성 검사, 검증, 빠른 확인, 초기 확인, 신뢰도 확인, 건전성 확인, 보정 확인, 준비도 확인이라는 표현을 고려해 보세요.
더미 사용되지 않음, 자리표시자, 노옵스(no-ops), 베이스, fake/mock/stub.
그랜드파더링 면제, 기존, 보류, 이월, 기준, 이전
성별 대명사(예: 그 또는 그녀) 복수 대명사(그들)
중간자(MITM) 경로별 공격자
(블랙|화이트|그레이) 해트 윤리/비윤리
일급 객체 핵심 기능, 빌트인, 최상위

이 정책을 위반하는 항목이 인터페이스에 포함되면 어떻게 되나요?

이러한 상황은 이전에 몇 차례 발생했으며, 특히 사양을 구현하는 코드에서 나타났습니다. 이때 사양과 다른 표현을 사용하면 구현 내용을 이해하기 어려워질 수 있습니다. 이러한 상황이 발생했다면 다음 조치 중 하나를 사용하여 편향성을 줄이시기 바랍니다.

  1. 대체 용어를 사용해도 내용을 이해하는 데 문제가 되지 않는다면 대체 용어를 사용합니다.
  2. 인터페이스 작업을 실행하는 코드 이외의 상황에서는 용어를 전파하지 마세요. 필요한 경우 API 경계에서 대체 용어를 사용하세요.
  3. 언어를 직접 수정할 수 없다면 관련 팀에 버그를 제출하세요.