번역자 서문

이 문서는 http://www.w3.org/2004/02/Process-20040205/ 의 한국어 번역판으로 영어 원본에는 없는 번역 상 오류가 들어 있을 수 있습니다. 오직 영어 원본만이 규범력을 지님에 유의하시기 바랍니다. 번역 상 오류에 대한 지적이나 제안하실 내용이 있으면 chan@w3.org로 연락해 주시기 바랍니다.

This document is a Korean translation of "World Wide Web Consortium Process Document, 5 February 2004" at http://www.w3.org/2004/02/Process-20040205/). Note that only the English version of this document is normative and the translation may contain errors that are not present in the English version.

W3C

월드 와이드 웹 컨소시엄 프로세스 문서

2004년 2월 5일

본 버전:
http://www.w3.org/2004/02/Process-20040205/
최신 유효 버전:
http://www.w3.org/Consortium/Process/
이전 유효 버전:
http://www.w3.org/2003/06/Process-20030618/
편집자:
Ian Jacobs, W3C

이 문서에 대해 몇 가지 기본 교정 사항을 포함하고 있는 정오표를 참조한다.

이 문서는 다음과 같은 비표준 패키지에서도 사용 가능하다. 단일 파일, 자체적으로 압축되어 있는 tar 아카이브, 자체적인 zip 아카이브.

이 문서의 번역본이 있을 수 있다.


요약

월드 와이드 웹 컨소시엄(W3C)의 사명은 월드 와이드 웹의 진화를 촉진하고 그 호환성을 보장하는 공통 프로토콜을 개발함으로써 월드 와이드 웹이 지닌 잠재력을 최대한 이끌어내는 것이다. W3C 프로세스 문서에서는 W3C의 조직적 구조와 W3C의 사명을 달성하기 위해 W3C를 뒷받침하는 책임 및 기능과 관련된 프로세스를 설명한다. 이 문서에서는 팀의 내부적 작업이나 W3C의 공공 통신 메커니즘은 설명되지 않는다.

W3C의 사명과 역사에 대한 자세한 내용은 W3C 소개 [PUB15]를 참조한다.

본 문서의 상태

이 문서는 W3C 프로세스 문서의 2004년 2월 5일 버전이다. 이 문서는 W3C 자문 이사회에서 작성되고 W3C 회원에서 검토되었다.

프로세스 문서의 이번 버전은 W3C 특허 정책의 2004년 2월 5일 버전 [PUB33]에 맞춰 조정되었다. 공개 프로세스 문서에 대한 변경 사항 목록은 웹에서 구할 수 있다.

이 문서에 대한 의견이 있으면 process-issues@w3.org (회원 전용 아카이브)로 보내주기 바란다. 프로세스 문서에 대한 추가적인 회원 전용 정보 (예: 발행 목록, 회원 전용 초안 및 회원 전용 초안에 대한 변경)는 프로세스 계획 페이지에서 이용할 수 있다. W3C 회원 가입을 비롯하여, W3C 소개에 대한 일반적인 정보는 웹에서 이용할 수 있다.

MUST, MUST NOT, SHOULD, SHOULD NOT, REQUIRED 및 MAY가 강조 표시될 때 (스타일 시트를 통해, 그리고 원본에서 대문자로 쓰일 때)는 RFC 2119 [RFC2119]의 설명에 따라 사용된다. NOT REQUIRED (RFC 2119에는 정의되어 있지 않음)는 면제 사항을 나타낸다.

이 문서에서의 시간 간격은 스타일 시트를 통해 강조 표시된다.

특허 정책에 대한 프로세스 문서의 관계

W3C 회원은 회원 가입 동의서 [PUB6]에 따라 프로세스 문서의 각 조항이 회원에 대해 구속력을 가진다는 사실에 주의해야 한다. 특허 정책 W3C 특허 정책 [PUB33]은 본 프로세스 문서의 일부로서 표준 참고로 인용되어 있으므로, 동일한 구속력을 지닌다.

특허 정책은 W3C의 회원, 팀 및 기타 참가자에게 추가적인 의무를 규정하고 있다. 본 프로세스 문서에서는 이러한 요구 사항을 다시 언급하지는 않지만, 그에 대한 참조 문서가 포함되어 있다. 본 프로세스 문서와 특허 정책은 독자적으로 진화할 수 있도록 고안되었다.

목차

세부 목차


1 개요

대부분의 W3C 작업은 웹 기술의 표준화를 중심으로 이루어지고 있다. 이 작업을 하기 위해, W3C는 회원, 팀 및 대중의 합의를 바탕으로 하여 질 높은 표준 개발을 촉진하는 프로세스를 따른다. W3C 프로세스는 W3C 사명의 모든 측면이라 할 수 있는 공정성, 대응 능력 및 프로세스를 촉진한다. 이 문서에서는 사명 완수를 위해 W3C가 따르는 프로세스를 설명한다.

여기서는 W3C가 웹 기술을 표준화하는 방법에 대한 일반적인 개요를 기술한다. 많은 경우에 있어서, 이 작업의 목표는 웹 표준과 동등한 지위에 있는 W3C 권장 사항의 개발이다.

  1. 사람들은 특정 주제 (예: 웹 서비스)에 관심이 많다. 예를 들어, 회원들은 회원 의뢰의 형식으로 이러한 관심을 표명하고, 은 관심의 증표로서 W3C의 내부와 외부 작업을 감시한다. 또한 W3C는 W3C 커뮤니티에 관심을 유발시키는 주제들을 함께 논의하기 위해 워크숍을 조직하기도 한다. 예컨대, 웹 서비스 문제에 대한 워크숍이 열린 적이 있다.
  2. 어떤 주제에 관해 충분한 관심이 유발되는 경우 (예: 워크숍이 성공리에 치러지고 자문 위원회 메일링 리스트에 대한 논의가 있은 후), 담당 감독은 관심 주제의 폭에 따라 새로운 활동에 대한 제안서 개발 또는 워킹 그룹 헌장을 발표한다. 활동 제안서에서는 의도하는 작업의 범위, 지속 기간 및 기타 특징이 설명되고, 작업의 수행을 위해 하나 이상의 워킹 그룹, 이해 집단 및 조정 그룹의 헌장이 포함된다. W3C 회원들은 각 활동 제안성와 관련 워킹 그룹 헌장을 검토한다. 관심 주제에서 자원 투자를 위해 W3C 내부에 지원이 있는 경우, 감독은 새로운 활동과 그룹이 작업을 시작할 수 있도록 승인한다. 웹 서비스 활동을 위해, 최초 활동 제안서에서는 웹 서비스 아키텍처에 대한 작업을 위한 워킹 그룹 하나와 웹 서비스 설명을 위한 언어 작업에 대해 워킹 그룹 하나를 요청했다. 또한 활동 제안서에서는 XML 프로토콜에 대한 작업을 하는 기존의 워킹 그룹 (다른 활동을 하던 워킹 그룹)도 포함시켰다.
  3. 참가하는 워킹 그룹에는 회원 대표, 초빙 전문가팀 대표의 세 가지 유형이 있다. 팀 대표는 모두 기술 작업에 기여하고 그룹이 나머지 W3C와 적절히 통합되도록 돕는 역할을 한다. 워킹 그룹 헌장은 각 그룹의 작업 결과에 대한 기대치를 정해둔 것이다. (예: 기술 보고서, 기술 솔루션 및 튜토리얼).
  4. 워킹 그룹은 일반적으로 W3C 권장 사항의 상태를 발전시켜 나감에 따라 개정과 검토 주기를 겪는 사양과 가이드라인을 작성한다. 이러한 기술 보고서를 만들기 위한 W3C 프로세스에는 회원과 대중에 의한 의미 있는 검토와 워킹 그룹이 구현과 호환성에 관한 경험을 보여줄 수 있는 요구 사항이 포함된다. 프로세스 막바지에는, 자문 위원회가 성숙한 기술 보고서를 검토하고, 지원 사항이 있는 경우 W3C는 이것을 권장 사항으로 발표한다.

본 프로세스 문서는 합의를 장려하고, 권장 사항 추적의 일환으로 회원과 대중 모두에 의한 검토를 요구하고, 자문 위원회에 대한 상고 과정을 통해 기술 상의 의사 결정에 있어 그 적절성과 공정성을 달성한다는 목표에 한 발 가까이 다가선다.

프로세스 문서의 다른 절에서는 다음 내용을 다룬다.

  1. W3C 그룹에 참가하기 위한 정책을 설명한다.
  2. W3C 내의 두 영구적 그룹, 즉 컨소시엄 전체의 기술적 문제 해결을 돕기 위한 기술 아키텍처 그룹 (TAG)과 컨소시엄 전체의 비기술적 문제 해결을 돕고 W3C 프로세스의 진화를 관리하기 위한 자문 이사회 (AB)를 설립한다.
  3. 회원 (W3C 자문 위원회가 대표함), 팀 및 일반 대중 사이의 다른 상호 작용을 설명한다.

2 회원, 자문 위원회, 팀, 자문 이사회, 기술 아키텍처 그룹

W3C의 사명은 웹이 지닌 잠재력을 완벽히 이끌어내는 것이다. W3C 회원 조직은 이 목표를 위해 자원을 제공하고, W3C 은 이러한 노력을 조정하기 위한 기술적 리더십과 조직을 제공한다.

2.1 회원

W3C 회원은 W3C 프로세스에서 주로 다음과 같이 대변된다.

  1. 자문 위원회는 각 회원 조직으로부터 온 한 명의 대표로 구성된다 (현재 자문 위원회 대표회원 전용 목록 참조 [MEM1]). 자문 위원회는 다음과 같은 역할을 한다. 자문 위원회 위원들은 이 문서에서 설명되는 몇 가지 프로세스에 대한 상고 권한을 가진다.
  2. 회원 조직의 대표자들은 워킹 그룹, 이해 집단 및 조정 그룹에 참가하고 권장 사항 추적에 대한 문서를 저술하고 검토한다.

W3C의 회원 자격은 "W3C에 가입하는 방법" [PUB5]에 설명된 대로 모든 조직에 그 기회가 열려 있다 (현재의 W3C 회원 [PUB8]의 공개 목록 참조). 각 조직은 회원 가입 동의서 [PUB6]에 따라 가입하면 된다. 팀은 반드시 회원 가입 동의서가 팀 전용으로 남아 있고 W3C 내에서 어떠한 회원도 특혜를 받지 못하도록 해야 한다.

W3C는 개인에 맞는 회원 자격 등급이나 그에 따른 가입비 정책을 지니고 있지 않다. 하지만 개인은 가맹 회원으로 W3C에 참가할 수 있다. 이 경우, 개인 역시 또 다른 W3C 회원을 대표할 때 관련 회원에 해당하는 동일한 제한이 적용된다.

2.1.1 회원의 권리

각 회원 조직은 다음과 같은 권리와 혜택을 누린다.

또한, 회원 조직의 대표자들은 다음과 같이 W3C에 참가한다.

회원 조직 자체가 하나의 컨소시엄, 사용자 협회이거나 회원 또는 스폰서가 있는 경우(회원 가입 동의서의 5g 항에 설명), 그 조직의 유급 직원과 자문 위원회 대표는 W3C 회원 자격에 관한 모든 권리와 특권을 행사한다. 또한 자문 위원회 대표는 해당 조직에 고용되어 있지는 않더라도 회원 대표자의 권리를 행사할 수 있는 개인을 최대 4명까지 (또는 팀의 재량에 따라) 지명할 수 있다. 이들 개인은 W3C 작업에 참여 시 그 고용 관계를 반드시 밝혀야 한다. 관련 회원에 대한 조항이 적용된다. 나아가, 이들 개인은 W3C 회원 조직의 폭 넓은 이해를 대변할 것으로 기대되며, 그 고용주의 편협한 이익을 대변해서는 안 된다.

W3C 회원의 권리와 이익은 이 문서에서 설명하는 프로세스에 따르는 것을 전제로 한다. W3C 회원 대다수는 이들 프로세스의 문구상의 절차뿐 아니라, 그 정신도 충실히 따르고 있다. 심각하거나 반복적인 위반 사항이 발생하는 경우, 그리고 이러한 위반 사항을 해결하려는 반복적인 시도에도 불구하고 상황이 개선되지 않은 경우, 감독은 징계 조치를 취할 수 있다. 기타 규정에 불일치 문제가 발생한 경우의 중재는 회원 가입 동의서의 19항에 따라 처리된다. 징계 조치에 대한 가이드라인 [MEM14]을 참조한다.

2.1.2 관련 회원

합의 프로세스의 무결성을 보장하는 이익에 있어, 이 문서에서 다루는 몇 가지 프로세스에 회원 여부는 관련 회원의 상태에 의해 영향을 받는다. 여기서 사용되는 대로, 다음과 같은 경우 두 회원이 관계를 맺게 된다.

  1. 한쪽 회원이 다른 회원의 자회사인 경우
  2. 두 회원 모두 공통 조직의 자회사인 경우
  3. 회원들이 W3C 참가에 영향을 미치는 고용 계약이나 컨설팅 계약을 맺고 있는 경우

자회사는 유효 통제권 및/또는 대부분의 소유권이 또 다른 단일 조직에 속하는 조직을 말한다.

관련 회원은 신규 회원 오리엔테이션 [MEM4]에 설명되어 있는 메커니즘에 따라 이러한 관계를 반드시 공개해야 한다.

2.1.3 자문 위원회 (AC)

어떤 조직이 W3C에 가입하는 경우("W3C에 가입하는 방법" [PUB5] 참조), 그 조직은 회원 가입 동의서의 일부로서 그 자문 위원회 대표를 반드시 지명해야 한다. 신규 회원 오리엔테이션에서는 자문 위원회 메일링 리스트에 가입하거나 탈퇴하는 방법을 설명하고, 자문 위원회 회의에 관한 정보를 제공하고, 새로운 자문 위원회 대표를 지명하는 방법 등을 설명한다. 자문 위원회 대표는 신규 회원 오리엔테이션에 설명되어 있는 메커니즘에 따라 정보를 공개함으로써 이해 정책의 충돌반드시 따라야 한다. W3C 특허 정책 [PUB33]에 설명되어 있는 자문 위원회 대표의 추가 역할도 참조한다.

회원에 대한 추가 정보는 회원 웹 사이트 [MEM6]에 나와 있다.

2.1.3.1 자문 위원회 메일링 리스트

팀은 자문 위원회에서 사용할 수 있도록 다음과 같이 2개의 메일링 리스트를 반드시 제공해야 한다.

  1. 팀이 자문 위원회에 공식적으로 공개하기 위한 목록 1부(예: 이 문서에서 요구되는 목록. 이 목록은 자문 위원회 대표만 읽을 수 있는 것이다.
  2. 자문 위원회 대표들 사이에 논의를 위한 목록 1부. 이 목록은 주로 자문 위원회 대표들을 위한 것이지만, 팀은 적절하다고 판단되는 경우 반드시 논의를 감시하고 논의에 참가해야 한다. 앞으로 계속될 세부 논의는 적당한 다른 목록으로 이전되어야 한다 (워크숍을 위해 작성된 메일링 리스트와 같은 신규 또는 기존 목록).

자문 위원회 대표는 자신이 속한 조직으로부터 추가로 개인이 이 목록에 가입되도록 요청할 수 있다. 내부적인 배포를 억제하지 못하면 팀의 재량에 따라 추가로 전자 우편 주소가 유보되는 결과를 초래할 수 있다.

2.1.3.2 자문 위원회 회의

팀은 1년에 두 차례 자문 위원회를 위한 직접 대면 회의를 조직한다. 팀은 이 회의의 의장을 지명한다 (일반적으로 W3C 의장 또는 COO (Chief Operating Officer)). 각 자문 위원회 회의에서, 팀은 다음 사항에 관해 자문 위원회에 업데이트 정보를 제공해야 한다.

리소스
할당

각 회원 조직은 각 자문 위원회 회의에 한 명의 대표파견해야 한다. 예외적인 상황 (예: 한 조직을 대표하는 대표자 간 교체 시기 중)에서, 회의의 의장은 회원 조직이 두 명의 대표를 한 회의에 보내도록 허용할 수 있다.

팀은 각 자문 위원회 회의의 날짜와 장소를 늦어도 이전 회의가 끝날 때 반드시 발표해야 하며, 1년의 공지 기간을 권장한다. 팀은 최소한 1년 전에 각 자문 위원회의 지역을 반드시 발표해야 한다.

자문 위원회 회의 [MEM5]에 대한 자세한 정보는 회원 웹 사이트에서 이용 가능하다.

2.2 W3C 팀

W3C 팀은 W3C의 유급 직원, 무급 인턴 사원 및 W3C 동료로 구성된다. W3C 동료는 팀의 일부로 근무하는 회원 고용인이다. W3C 동료 프로그램 [PUB32]을 참조한다. 팀은 웹 기술에 대한 기술 리더십을 제공하고, 실용적인 한도 (가용 자원 등) 내에서 목표에 달성하기 위한 W3C의 활동을 조직 및 관리하고, 회원과 대중에 웹 및 W3C 기술에 대한 정보를 전달한다.

팀은 감독, W3C 의장 및 COO가 이끈다. 세 개인이 이 문서에 설명되어 있는 그들의 역할 중 어떤 것에 대해서도 책임 (일반적으로 팀의 다른 개인에 대한 책임)을 위임할 수 있다.

감독은 W3C에서 주도적인 기술 아키텍처 설계자로서, 아키텍처 선택, 기술 보고서의 공개 및 새로운 활동에 대해 W3C 내부의 합의를 평가할 책임이 있다. 감독은 그룹 의장을 지명하고, 워킹 그룹에서 적격성의 문제에 대해 "타이 브레이커" 역할을 하거나 워킹 그룹 의사 결정을 상고하는 역할을 한다. 감독은 일반적으로 TAG의 의장이다.

W3C 의장은 회원 관계와 다른 조직, 정부 및 일반 대중과의 연락을 맡는다.

최고 운영 책임자 (COO)는 하나의 조직인 W3C의 운영을 주도한다. 여기서 하나의 조직이란, 사람, 호스트 기관 및 절차가 모여있다는 의미에서 쓴 말이다.

팀 급여, 세부 예산 계획 및 기타 비즈니스 의사 결정 사항과 같은 팀 관리 정보는 호스트 기관의 감독에 따라 팀 전용 정보로 관리된다.

주: W3C는 현재 법인 조직이 아니다. 법률적 계약을 위해, W3C는 세 곳의 "호스트" 기관을 대표자로 하는데, 그들은 ERCIM (European Research Consortium for Informatics and Mathematics), 게이오 대학교 및 MIT 공대이다. W3C 내에서, 호스트 기관들은 공동 후원 계약을 맺고, 호스트 기관 그 자체는 W3C 회원이 아니다.

2.2.1 팀 의뢰

팀은 감독이 W3C 웹 사이트에서 정보 공개를 해줄 것을 요청할 수 있다. 감독의 재량으로, 이 문서들은 "팀 의뢰서"로 공개된다. 이들 문서는 회원 의뢰서 (예: 예상 범위에서)와 유사하다. 하지만 추가 팀 의견은 없다.

팀 의뢰는 권장 사항 추적 프로세스의 일부가 아니다.

발표된 팀 의뢰서 [PUB16] 목록은 W3C 웹 사이트에서 이용할 수 있다.

2.3 자문 이사회 (AB)

1998년 3월에 설립된 자문 이사회는 전략, 관리, 법률 문제, 프로세스 및 의견 충돌 해결의 문제에 대해 팀에 지속적인 길잡이 역할을 하고 있다. 또한, 자문 이사회는 자문 위원회 회의 간에 제기된 문제들을 추적하여 그 내용을 회원들에게 알려주기도 하여, 이러한 문제에 대한 회원의 의견을 구하고 이러한 문제 해결을 위한 조치를 제안한다. 자문 이사회는 프로세스 문서의 진화를 관리하고, 자문 위원회는 웹 아키텍처에 관계없는 이유로 각하되는 회원 의뢰 요청의 상고를 청취한다. 또한 TAG도 참조하도록 한다.

자문 이사회는 이사들로 이루이진 임원단이 아니고, W3C 내에서 의사 결정 권한이 없으며, 그 역할은 엄격히 자문의 성격으로만 제한된다.

팀은 자문 이사회와 팀에 기밀인 통신 방식을 이용해 자문 이사회에서 사용할 수 있도록 메일링 리스트를 반드시 제공해야 한다.

자문 이사회는 자문 위원회와 다른 그룹의 의장들에게 각 회의 내용의 초록을 송부해야 한다. 자문 이사회는 각 자문 위원회 회의에서의 활동에 대해서도 보고해야 한다.

자문 이사회에 대한 세부 사항 (예: 자문 이사회 참가자 목록, 메일링 리스트 정보 및 자문 이사회 회의의 요약)은 자문 이사회 홈 페이지 [PUB30]에 나와 있다.

2.3.1 자문 이사회 참가

자문 이사회는 9명의 선출된 참가자와 1명의 의장으로 구성된다. 팀은 자문 이사회의 의장을 지명하는데, 일반적으로 W3C 의장이 맡는다.

나머지 9명의 자문 이사회 참석자는 AB/TAG 지명 및 선출 과정에 따라 W3C 자문 위원회에 의해 선출된다.

의장을 제외하고, 모든 자문 이사회 참석자의 재임 기간은 2년 이다. 기간은 서로 엇갈리게 되어 있는데, 매년 네 명 또는 다섯 명의 참석자 재임 기간이 만료된다. 한 개인이 완료되지 않은 재임 기간을 채우기 위해 선출되는 경우, 그 개인의 재임 기간은 해당 기간의 정상적인 만료 일자에 끝난다. 정규 자문 이사회 재임 기간은 7월 1일에 시작되어 6월 30일에 종료된다.

2.4 기술 아키텍처 그룹 (TAG)

2001년 2월에 설립된 TAG의 사명은 웹 아키텍처를 관리하는 것이다. 이 사명에는 다음 세 가지 측면이 있다.

  1. 웹 아키텍처의 원리를 중심으로 문서화 및 합의 구축 및 필요한 경우 이러한 원리를 해석 및 명확화
  2. TAG로 가져온 일반적인 웹 아키텍처에 관련된 문제 해결
  3. W3C 내부와 외부의 교차 기술 아키텍처 개발 조정 지원.

TAG는 웹 아키텍처와 관련된 이유로 각하된 회원 의뢰 요청의 상고 내용을 청취한다. 또한 자문 이사회도 참조한다.

TAG의 범위는 웹 아키텍처에 관한 기술적 문제로 제한된다. TAG는 일반적으로 W3C 자문 위원회, 자문 이사회 및 팀에 의해 처리되는 관리, 프로세스 또는 조직의 정책 문제를 고려해서는 안 된다. TAG의 배경과 범위, 그리고 TAG 참가자의 기대되는 자격 요건에 대한 자세한 내용은 TAG 헌장 [PUB25]을 참조한다.

팀은 TAG에 다음과 같은 2개의 메일링 리스트를 반드시 제공해야 한다.

또한 TAG는 추가적인 주제별 공개 메일링 리스트의 작성을 요청할 수도 있다. 몇 가지 TAG 논의 (예: 각하된 회원 의뢰 요청)를 위해, TAG는 회원 전용의 목록을 사용할 수도 있다.

TAG는 각 회의의 요약서를 자문 위원회와 다른 그룹의 의장들에게 송부해야 한다. TAG는 각 자문 위원회 회의에서의 활동에 대한 보고도 해야 한다.

TAG가 어떤 문제를 해결하기 위해 투표하는 경우, 각 TAG 참석자 (지명되거나 선출된 자 또는 의장을 불문하고)는 저마다 한 표의 투표권을 가진다. TAG 헌장의 투표 [PUB25]에 대한 단원과 본 프로세스 문서에 있는 투표에 대한 일반적인 단원도 참조한다.

TAG에 대한 세부 사항 (예: TAG 참석자 목록, 메일링 리스트 정보 및 TAG 회의의 요약서)은 TAG 홈 페이지 [PUB26]에 나와 있다.

2.4.1 기술 아키텍처 그룹 참가

TAG는 선출 또는 지명된 8명의 참석자와 의장으로 구성된다. 팀은 TAG의 의장을 지명하는데, 일반적으로 감독이 맡는다.

3명의 TAG 참석자는 감독이 지명한다. 지명된 자는 W3C 팀에 소속되어 있을 필요가 없다. 감독은 TAG에 W3C 동료지명할 수 있다.

나머지 5명의 TAG 참석자는 AB/TAG 지명 및 선출 과정에 따라 W3C 자문 위원회에서 선출된다.

의장을 제외하고, 모든 TAG 참석자의 재임 기간은 2년 동안이다. 기간은 서로 엇갈리게 되어 있는데, 매년 두 명 또는 세 명의 선출직 재임 기간 및 하나 또는 두 명의 지명직 재임 기간이 만료된다. 한 개인이 완료되지 않은 재임 기간을 채우기 위해 지명 또는 선출되는 경우, 그 개인의 재임 기간은 해당 기간의 정상적인 만료 일자에 끝난다. 정규 TAG 재임 기간은 2월 1일에 시작되어 1월 31일에 종료된다.

2.5 자문 이사회 및 기술 아키텍처 그룹 참가

자문 이사회와 TAG 참석자들은 W3C 내에서 특별한 역할을 하고 있다. 이들은 단순히 특정 네트워크, 기술, 벤더 또는 사용자를 위해서가 아니라, 웹을 위한 최선의 솔루션을 찾기 위해 최선의 판단력을 활용할 것이라는 기대를 가진 회원들이 선출하고 감독이 지명한다. 자문 이사회와 TAG 참석자들은 정기적으로 빠짐없이 참석하는 것이 바람직하다. 워킹 그룹 참석자들을 위해 정의된 적격성 규칙은 자문 이사회와 TAG 참석자들에게도 적용된다. 자문 이사회와 TAG 참석자들은 자문 위원회 회의출석해야 한다.

개인은 그 개인의 재임 기간이 시작되는 시점부터 그 기간이 끝나거나 공석이 될 때까지 자문 이사회나 TAG에 참석한다. 자문 이사회 및 TAG 참석자들은 자신의 고용주의 상업적 이익을 옹호하지는 않지만, 그들이 참석하는 것은 회원 대표, 초빙 전문가 상태 또는 팀 대표와 관련된 책임(AB/TAG 지명 및 선출 과정에 대한 단원에 설명되어 있는 책임)을 수행하는 것이다. W3C 특허 정책 [PUB33]의 단원 3에 있는 TAG 참석자에 대한 라이센스 의무와 단원 4의 클레임 배제 프로세스도 참조한다.

2.5.1 자문 이사회 및 기술 아키텍처 그룹 참가 제한

자문 이사회와 TAG에 소수의 좌석이 있는 경우, 그리고 W3C 회원의 다양성이 대변될 수 있도록 하기 위해 다음 사항이 적용된다.

어떤 이유에서든, 이러한 제한 사항이 만족되지 않는 경우 (예: TAG나 AB 참석자가 업무를 바꾸었기 때문에), 한 참석자는 반드시 그 상황이 해결될 때까지는 TAG나 AB에 참석해서는 안 된다. 그 상황이 해결된 지 30일 후, 의장은 한 참석자의 자리가 공석임을 선언하게 된다. 2명 이상의 개인이 관련되어 있는 경우, 아래에 설명된 검증 가능한 무작위 선정 절차를 사용해 지속적인 참석이 이루어지도록 한 사람을 선택하게 된다.

2.5.2 자문 이사회 및 기술 아키텍처 그룹 선출

자문 이사회 및 기술 아키텍처 그룹의 일부는 자문 위원회에서 선출된다. 팀이 자문 위원회로 지명 요청을 보내면 선거가 시작된다. 모든 지명 요청에서는 해당 좌석 수, 지명 마감 시한 및 지명이 송달되는 주소가 지정된다.

각 회원 (또는 관련 회원의 그룹)은 한 명의 개인을 지명할 수 있다. 후보 지명은 반드시 지명된 후보의 동의를 얻어 이루어져야 한다. 회원 대표로 지명된 개인에 대한 요청서에서, 해당 개인은 반드시 회원 대표로서의 자격을 갖추어야 하고, 회원의 자문 위원회 대표는 반드시 워킹 그룹에서 회원 대표에게 요구되는 (동일한) 정보를 가진 지명 후보를 포함해야 한다. 초빙 전문가로 지명되는 개인에 대한 요청에서, 해당 개인은 반드시 워킹 그룹에서 초빙 전문가에 요구되는 (동일한) 정보를 제공해야 하고, 후보를 지명하는 자문 위원회 대표는 반드시 그 정보를 후보 지명 시 포함해야 한다. 팀 대표로 지명된 개인에 대한 요청서에서, 후보를 지명하는 자문 위원회 대표는 반드시 우선 팀 관리자로부터 확실한 승인을 받아야 한다. 지명된 후보자가 회원 조직의 직원일 필요는 없고, W3C 동료수도 있다. 각 후보 지명서에는 해당 후보에 대한 몇몇 정보 제공용 조항이 포함되어야 한다.

만약 후보 지명에 대한 마감 시한 후 후보자의 수가 다음과 같은 경우를 생각해본다.

투표가 있는 경우, 각 회원 (또는 관련 회원의 그룹)은 선출하려는 자리 수만큼의 후보자에게 투표할 수 있다. 자문 위원회 투표에 대한 단원을 참조한다. 투표 마감 시한이 경과되면, 팀은 자문 위원회에 그 결과를 발표한다. 최다 득표를 한 후보자가 선출된다. 선출하려는 자리보다 많은 후보자가 동률을 이룬 경우 (예: 세 후보가 두 자리에 대해 각각 10표씩 받은 경우), 아래에 설명되어 있는 검증 가능한 무작위 선정 절차를 사용해 선출하려는 자리를 채우게 된다.

자세한 내용은 자문 이사회 또는 TAG 선거를 조직하는 방법 [MEM15]을 참조한다.

2.5.2.1 검증 가능한 무작위 선정 절차

검증 가능한 무작위 선정 과정을 사용할 필요가 있는 경우 (예: AB 또는 TAG 선거에서 후보자들이 동률을 이루거나 짧은 기간 동안 자리를 채울 필요가 있을 경우 “제비 뽑기”를 하기 위해), W3C는 RFC 2777 [RFC2777]에 정해져 있는 무작위의 검증 가능한 절차를 사용한다. 이 절차에서는 이름 목록 (달리 명시하지 않는 한, 성의 알파벳 순서에 따라 나열함)을 “결과 순서”로 입력하도록 하고 있다.

W3C는 이 절차를 다음과 같이 적용한다.

  1. N명의 사람이 M개의 자리를 두고 동률을 이루었다. 이 경우, 동률을 이룬 N명의 개인의 이름만 이 절차에 대한 입력 정보로 제공된다. M개의 자리는 결과 순서에 따라 개인에게 할당된다.
  2. 선출된 참석자에게 하나 이상의 단기직을 할당할 필요가 있는 경우. 이 경우, 선출된 모든 개인의 이름 (동률 문제가 해결된 후)은 이 절차에 입력 정보로 제공된다. 단기직은 선거 결과의 순서대로 개인에게 할당된다.

2.5.3 자문 이사회 및 기술 아키텍처 그룹 공석

자문 이사회나 TAG 참석자의 자리는 다음 중 한 가지가 발생할 때 공석이 된다.

자문 이사회 또는 TAG 참석자가 가입 지위를 변경하는 경우, 자문 이사회 및 TAG 참가 제한 사항이 존중되는 한, 해당 개인은 그 그룹에 대해 다음으로 예정되어 있는 선거 때까지 계속 참석할 수 있다. 그렇지 않으면, 그 자리는 공석이 된다.

한 자리가 공석이 되면, 해당 그룹에 대해 다음 번에 예정된 정기 선거에서 채워진다.

3 W3C 그룹에 대한 일반적인 정책

이 단원에서는 참석, 회의 요구 사항 및 의사 결정에 관해 W3C 그룹에 대한 일반적인 정책을 설명한다. 이들 정책은 다음 그룹의 참석자에게 적용된다. 자문 위원회, 자문 이사회, TAG, 워킹 그룹, 이해 집단조정 그룹.

3.1 개인 참가 기준

개인이 W3C에 참여하기 위해 입증해야 하는 것으로 기대되는 세 가지 자격 요건이 있다.

  1. 자신의 역할에 있어서의 기술적 역량
  2. 공정하게 행동할 수 있는 능력
  3. 자신의 역할에 있어서의 사회적 역량

W3C 활동에 참석하기 위해 자신의 조직으로부터 개인을 후보로 지명하는 자문 위원회 대표는 그 후보자들의 자격을 평가하고 증언할 책임이 있다.

W3C 특허 정책 [PUB33]의 단원 6에 설명되어 있는 참석 요구 사항도 참조한다.

3.1.1 이해 정책의 충돌

W3C에 실제로 참석하고 있는 개인들은 W3C에서 그 개인들이 가진 역할과 이해가 상충되는 것으로 판단할 충분한 이유가 있는 경우, 반드시 중요한 의미를 지니는 관계를 공개해야 한다. 이러한 공개는 개인의 가입 지위가 바뀌고 W3C 회원 자격 지위가 높아짐에 따라 반드시 최신 정보로 유지되어야 한다. (예컨대, W3C에 참가하거나 탈퇴하는 조직과 해당 개인이 어떤 관계를 가지고 있을 수 있는 경우) W3C 그룹을 설명하는 이 문서의 각 단원에서는 해당 그룹에 대한 공개 메커니즘에 대해 보다 세부적인 정보를 제공한다.

이해의 충돌이 발생할 위험이 없는 그룹 내에서의 한 가지 역할을 이행하는 개인의 능력은 명백히 그 개인의 가입 지위가 가지는 직능이다. 이러한 가입 지위가 바뀌는 경우, 해당 역할에 대한 개인의 임무 할당은 반드시 평가되어야 한다. 그 역할은 적절한 프로세스에 따라 다시 지정될 수도 있다. 예를 들어, 감독은 현 의장이 가입 지위를 바꾸는 경우, 새로운 그룹 의장을 지명할 수 있다. (예: 이해의 충돌이 발생할 위험이 있는 경우 또는 의장의 새 고용주가 W3C 활동 내에서 너무 자신의 입장을 대변하려고 하는 위험이 있는 경우)

다음은 공개가 적절한 몇 가지 시나리오이다.

이러한 문제에 대한 지원을 필요로 하는 개인은 팀에 연락해야 한다.

팀원은 W3C Team 이해 정책의 충돌 [PUB23]에서 정한 바에 따른다.

3.1.2 회원 조직을 대표하는 개인

일반적으로, W3C 내부에서 공식적인 직능을 담당하는 회원을 대표하는 개인은 회원 조직의 고용인이다. 하지만 자문 위원회 대표는 비고용인을 지명하여 회원을 대표하도록 할 수 있다. 비고용인 회원 대표는 반드시 팀과 해당 개인이 참여하는 그룹에 관련 가입 지위를 공개해야 한다.

예외적인 상황 (예: 그룹의 프로세스가 위태로워지거나 이해의 충돌이 발생할 수 있는 상황)에서, 감독은 그룹에 참여하기 위해 자문 위원회 대표가 지명한 개인을 허용하지 않을 수도 있다.

그룹 헌장은 W3C 회원 (또는 관련 회원의 그룹)을 대표하는 개인의 수를 제한할 수 있다.

3.2 회의

W3C 그룹 (자문 위원회, 자문 이사회, TAG워킹 그룹 포함)은 이 단원의 요구 사항을 준수해야 한다.

W3C는 다음 두 가지 유형의 회의를 구별한다.

  1. 직접 대면 회의는 대부분의 출석자가 동일한 물리적 장소에 참석할 것으로 기대되는 회의이다.
  2. 분산 회의는 대부분의 출석자가 원격 장소에서 참여 (예: 전화, 화상 회의 또는 IRC를 통해)할 것으로 기대되는 회의이다.

의장은 예외 규정을 바탕으로 특별한 전문 지식을 가진 개인이 회의에 참석할 수 있도록 초빙할 수 있다. 이 사람은 그룹 참가자가 아니라 회의의 게스트이다. 회의 게스트는 투표권을 가지지 않는다. 모든 회의 게스트가 헌장에 명시된 기밀성 수준과 다른 그룹의 요구 사항을 존중하도록 하는 것은 의장의 책임이다.

회의 발표는 해당되는 모든 그룹 메일링 리스트, 즉 예상되는 회의 참석자들에 가장 관련성이 큰 사람들에게 송부되어야 한다.

다음 표에는 회의를 조직하기 위한 요구 사항이 나열되어 있다.

직접 대면 회의 분산 회의
회의 발표 (이전) 8주* 1주*
현안 의제 (이전) 2주 24시간 (또는 회의가 주말이나 공휴일 이후로 예정되어 있는 경우에는 더 길게)
참석 확인 (이전) 3일 24시간
실행 항목 공개 (이후) 3일 24시간
의사록 공개 (이후) 2주 48시간

* 적절한 계획 (예: 여행 계획)을 세울 수 있도록, 의장은 회의의 날짜와 장소에 대해 충분한 사전 공지를 할 책임이 있다. 그룹 참가자로부터 이의가 없는 경우에는 회의에 대한 공지를 좀 더 촉박하게 하는 것도 허용된다.

3.3 합의

합의는 W3C의 핵심적 가치이다. 합의를 촉진하기 위해, W3C 프로세스는 의장이 그룹으로 하여금 모든 적법한 조사와 이의를 고려할 수 있도록 하고, 이러한 조사와 이의가 그룹의 능동적 참가자나 타인 (예: 또 다른 W3C 그룹, 또 다른 조직의 그룹 또는 일반 대중)에 의해 표현되는지 여부에 상관없이 이러한 문제를 해결하도록 노력할 수 있도록 할 것을 요구한다. 의사 결정은 회의 (직접 대면 또는 분산 회의) 중에 이루어질 뿐 아니라, 전자 우편을 통해서도 이루어질 수 있다. 주: 감독, W3C 의장 및 COO는 자문 위원회 내부의 합의를 평가하는 역할을 담당한다.

이 문서에서는 자격을 갖춘 개인들 사이에서 의사 결정을 위한 지원의 수준을 설명하기 위해 다음과 같은 용어가 사용된다.

  1. 합의: 집단 내 대부분의 개인들이 결정 사항을 지지하고 아무도 이의를 제기하지 않는 경우. 어떤 개인은 기권할 수도 있다. 기권은 아무런 의견도 명시적으로 표현하지 않거나 결정 사항에 대해 침묵을 지키는 것이다. 만장 일치는 해당 그룹 내의 모든 개인이 결정 사항을 지지하는 합의의 특별한 경우이다. (즉, 아무도 기권하지 않는 경우)
  2. 이의 표시: 그룹 내 최소 한 명 이상의 개인이 이의를 제기하는 경우.

기본적으로, 어떤 의사 결정에 참여할 자격이 있는 개인으로 이루어진 집단은 적격성을 갖춘 그룹 참가자의 집합이다. 이 프로세스 문서에서는 의사 결정에 대한 정족수 (즉, 의장이 어떤 문제에 대한 결정을 요구하기 전에 출석해 있어야 하는 적격 참석자의 최소 인원 수)를 요구하지는 않는다. 헌장에는 합의 의사 결정을 위한 정족수 요구 사항이 포함될 수 있다.

만장 일치가 가능하지 않은 경우, 그룹은 상당한 지지와 소수의 기권이 있는 합의 결정을 하기 위한 노력을 기울여야 한다. 본 프로세스 문서에서는 어떤 의사 결정을 하기 위한 움직임에 적격 참석자들이 특정한 비율 이상 동의해야 한다는 요구를 하지는 않는다. 거의 모든 이가 무관심함 (즉, 아주 적은 지지 의사를 밝히는 사람과 대부분의 기권자가 있는 경우)에도 불구하고 어떤 결정이 내려지는 것을 피하기 위해, 그룹은 그 결정을 기록하기 전에 적극적인 지지 의사를 밝히는 사람의 최소 한계를 설정해야 한다. 적당한 비율은 그룹의 크기와 의사 결정의 본질에 따라 바뀔 수 있다. 헌장에는 합의 결정을 위한 한계 인원 수 요구 사항이 포함될 수 있다. 예를 들어, 헌장에서는 특정한 유형의 합의 결정을 뒷받침하기 위해 적격 참석자의 대다수 (즉, 50% 이상의 지지율로 설정)가 그 결정을 지지해야 한다고 요구할 수도 있다.

3.3.1 의견 차 조정

어떤 경우, 모든 관점에서 조심스럽게 고려한 후에도 어떤 그룹은 합의에 도달할 수 없는 경우에 봉착할 수도 있다. 해당 그룹의 의장은 의견 차이 (즉, 최소한 하나 이상의 공식적 이의 제기가 있는 경우)가 있어서 그 그룹이 계속 논의를 진행할 수도 있는 경우 (예컨대, 적절한 시기에 어떤 결과를 내기 위해), 어떤 의사 결정을 기록할 수 있다. 반대자는 그런 결정을 도저히 수용할 수는 없다는 이유만으로 그룹 전체의 작업을 중단시킬 수는 없다. 의장이 그룹 전체가 가능한 한 반대자의 의견을 적법하고 정당하고 합리적으로 고려했다고 생각될 경우, 그룹은 의사 일정을 계속 진행해야 한다.

그룹은 최소한의 강한 이의를 제기하는 제안을 각별히 검토해야 한다. 이것은 대다수의 참석자가 지지하지만 소수의 참석자로부터 강력한 이의를 불러 일으키는 제안에 대해 선호되는 방식이다. 의견 차이가 있는 의사 결정을 하는 과정의 일부로서, 의장은 어떤 참석자가 똑 같은 (또는 관련된) 회원 조직을 위해 일하고 있고 그에 따라 그들의 반응에 무게가 실리는지 잘 알고 있을 것으로 기대된다.

3.3.2 공식적 반대 기록 및 보고

개인이 어떤 의사 결정에 대한 공식적 이의를 등록하는 경우, 그 개인은 기술적 논거를 예증하고 그 이의를 철회할 수 있는 변경 사항을 제안해야 하며, 이러한 제안은 모호하거나 불완전한 것일 수 있다. 권장 사항 추적의 한 문서 또는 본 프로세스 문서에 관한 이의에 그러한 정보가 포함되어 있는 경우, 의장은 반드시 그 사실을 해당 문서에 대한 다음 진행 요청서 (예: 후보 추천에 기술 보고서를 제출하기 위해 감독에게 보내는 요청서에서)를 통해 감독에게 보고해야 한다. 이의에 그러한 정보가 포함되어 있지 않은 경우, 의장은 이후의 검토 단계에 이를 보고할 필요가 없다.

자문 위원회의 검토 작업 중에, 자문 위원회 대표는 반드시 공식적 이의를 조회할 수 있어야 한다. 각 공식적 이의서의 버전은 반드시 공개되어야 한다.

3.3.3 문제의 공식적 처리

이 문서의 문맥에서, 어떤 그룹이 문제를 제기한 검토자에게 실질 답변을 보내었다면 그 문제를 공식적으로 처리한 것이 된다. 실질 답변은 의사 결정에 대한 논리적 근거 (예: 기술적 설명, 헌장의 제정 범위에 대한 지침 또는 요구 사항 문서에 대한 지침)를 포함하는 것으로 기대된다. 답변의 적합성은 W3C 검토자가 일반적으로 고려할 때 기술적으로 타당하다고 판단하는 바에 따라 평가된다. 어떤 그룹이 검토자의 의견이 오해로부터 비롯되었다고 믿는 경우, 그 그룹은 의사 결정에 이르기 전에 명확성을 추구해야 한다.

의례적인 절차로서, 의장과 검토자 모두 답변 및 승인의 일정에 대한 예상 스케줄을 확정해야 한다. 그룹은 시기 적절하게 검토자의 최초 의견에 답변해야 한다. 그룹은 그 그룹의 실질 답변을 검토하는 검토자의 승인에 대한 시간 한계를 정해야 하며, 검토자는 그룹의 업무 진행을 막을 수 없다. 검토자가 실질 답변에 대해 승인하고 의견을 제시하기 위해 1주일 이상 요구하는 것이 일반적이다. 합당한 정도의 시간이 경과하더라도, 검토자에게 답변할 그룹의 책임은 끝나지 않는다. 하지만 검토자는 그들의 의견이 적시에 그룹에 전달되지 않으면 그 비중이 덜하게 될 것이라는 사실을 인식하고 있어야 한다.

실질 답변은 기록되어야 한다. 그룹은 모든 실질 문제와 답변에 대한 정확한 요약 내용을 관리하고 있어야 한다 (즉, 메일링 리스트 아카이브에 대한 링크가 있는 문제 목록의 형태로 관리).

3.3.4 새로운 정보가 제시될 때 의사 결정 재개

의장은 다음을 포함한 새로운 정보가 제시될 때 의사 결정 과정을 재개할 수 있다.

의장은 의사 결정 과정이 재개되었음을 기록해야 하고, 그룹 참석자로부터 요청이 있을 때는 반드시 그렇게 해야 한다.

3.4 투표

의장이 기술적 논의와 타협을 통해 합의에 도달하기 위한 모든 가능한 수단이 실패로 돌아간 것으로 판단하고 교착 상태를 깨기 위해서는 투표가 필요하다고 결정한 후, 그룹은 실질 문제를 해결하기 위해 투표를 수행해야 한다. 이 경우, 의장은 다음 사항을 반드시 기록해야 한다. (예: 회의의 의사록 또는 저장된 전자 우편 메시지에 기록)

실질적인 문제의 해결을 위한 투표를 하기 위해, 개인은 반드시 적격성에 부합하는 그룹 참가자여야 한다. 그룹에 대표를 파견한 각 조직은 그룹에 여러 명의 참석자를 대표로 내보낸 경우라 할지라도 반드시 최대 한 표의 투표권만을 가져야 한다. 투표의 목적을 위해 다음 사항을 준수한다.

헌장에서 달리 명시하지 않는 한, 초빙 전문가투표할 수 있다. 한 명 이상의 초빙 전문가가 대표하는 조직은 앞서 언급한 바와 동일한 1표 제한에 따른다.

어떤 참가자가 투표를 행사하기 위한 자리에 출석할 수 없는 경우, 그 개인은 다른 사람을 대리인으로 위임하여 투표권을 행사하도록 할 수 있다. 회의에 결석한 참가자는 반드시 누가 대리인으로 참석하는지를 서면으로 의장에게 알려야 하며, 이때 대리인에게 투표권을 위임한다는 사실을 서면으로 작성해야 한다. 워킹 그룹이나 이해 집단의 경우, 참가자의 대리인으로 회의에 참석하는 개인에 관한 관련 요구 사항을 참조한다.

그룹은 실질 문제를 해결하는 것 이외의 목적에 대해 투표할 수도 있다. 예를 들어, 의장은 잠재적인 결정 사항에 관한 합의가 성립되어 있는지 판단하기 위한 수단으로서 종종 투표를 수행하기도 한다.

그룹은 어떤 프로세스에 있어서의 의사 결정을 위한 투표를 할 수도 있다. 예를 들어, 회의 장소를 샌프란시스코로 할 것인지, 산 호세 (두 지역은 지리적으로는 큰 차이가 없음)로 할 것인지는 단순히 다수결로 결정하는 것이 적절하다. 크게 중요하지 않은 문제를 결정하기 위해 단순한 다수결 투표 방식을 이용하는 경우, 그에 대한 이의의 이유를 언급하지 않아도 되고, 그룹은 개별 투표를 기록할 필요가 없다.

그룹 헌장에는 실질 문제에 대한 의사 결정을 하기 위한 공식적인 투표 절차 (예: 정족수 또는 한계 요구 사항)가 포함되어 있어야 한다.

자문 위원회 투표에 대한 절차는 별도로 설명되어 있다.

3.5 의장의 결정 사항 상고

그룹은 대화를 통해 문제를 해결한다. 어떤 결정 사항에 강력하게 이의를 제기하는 개인은 이의 사항을 의장에게 등록해야 한다 (예: 투표의 결과로 성립된 결정 사항에 대해).

그룹 참가자들이 자신의 관심사와 의견이 그룹에 의해 정당하게 고려되지 않고 있다고 믿는 경우, 감독 (자문 위원회 대표를 통해 회원 조직의 대표자들을 위해)에게 그 결정 사항을 확인하거나 거부할 것을 요청할 수 있다. 또한 참석자들은 자신들의 요청 사항이 팀 연락 담당자에게도 알려지도록 해야 한다. 팀 연락 담당자는 그룹 참가자가 정당한 프로세스에 대한 우려를 제기한 경우 반드시 감독에게 알려야 한다.

감독에게 어떤 결정 사항을 확인해달라고 제기하는 모든 요청서에는 반드시 해당 문제의 요약 정보 (기술적인 것이든, 절차적인 것이든), 결정 사항 및 이의의 논리적 근거가 포함되어야 한다. 모든 반대 논증, 논거 및 결정 사항은 반드시 기록되어야 한다.

자문 위원회 상고 절차는 별도로 설명되어 있다.

3.6 그룹에서 사임

그룹 참가자는 그룹에서 사임할 수 있다. 팀은 참가자의 사임에 대한 행정적 절차를 마련할 것이다. 어떤 그룹에서 사임한 후에 남아 있는 의무에 관한 정보는 W3C 특허 정책 [PUB33]의 4.2절을 참조한다.

4 보급 정책

팀은 W3C 내부에서와 일반 대중과의 커뮤니케이션 (예: 언론 매체, 보도 자료, 웹 사이트 및 액세스 특권 관리, 일정 관리 등)을 관리할 책임이 있다. 회원은 W3C 내부에서의 작업에 대한 보도 자료를 발간하기 전에 팀의 검토를 요청해야 한다.

팀은 다음과 같은 공공 정보를 이용할 수 있도록 하기 위해 최선의 노력을 다한다.

W3C 회의 결과를 회원들이 알 수 있도록 하고 마감 시한을 검토하기 위해, 팀은 회원들에게 정기 (예: 매주) 뉴스 서비스를 제공하고 공식적인 W3C 행사의 일정 [MEM3]을 관리한다. 회원들이 이 일정에 맞출 수 있도록 하기 위해 팀에 일정과 행사 정보를 보내줄 것이 장려된다.

4.1 기밀 수준

W3C 웹 사이트에서 정보에 액세스하는 데는 공개, 회원 전용 및 팀 전용의 세 가지 주요한 기밀 수준이 있다.

W3C가 제공하는 대부분의 정보는 공개되지만, "회원 전용" 정보는 회원 조직의 대표자, 초빙 전문가, 자문 이사회, TAG 및 팀을 비롯하여 권한이 있는 당사자에게만 제공된다. 예를 들어, 일부 워킹 그룹의 헌장에서는 그룹 의사록에 대해 회원 전용 기밀 수준을 지정할 수 있다.

"팀 전용" 정보는 팀과 다른 권한 있는 당사자에게 제공된다.

회원 전용 및 팀 전용 정보에 액세스할 수 있는 권한이 있는 자는 다음 사항에 따라야 한다.

팀은 회원 전용 정보의 기밀성을 보호하고 권한 있는 당사자가 이 정보에 적절히 액세스할 수 있도록 보장하기 위한 메커니즘을 반드시 제공해야 한다. 문서에서는 회원 전용 기밀성을 요구하는지 여부를 명확히 밝혀야 한다. 어떤 정보의 기밀성 수준에 대해 잘 모르는 개인은 팀에 연락하도록 한다.

자문 위원회 대표들은 회원 전용 액세스 권한을 회원 대표와 회원이 고용한 개인으로서 적절한 수령인으로 간주되는 자에게 제공할 수 있다. 예를 들어, 회원 전용 뉴스 발표가 그 조직 내부에서 내부용으로만 배포되도록 하는 것은 자문 위원회 대표 및 기타 직원과 그 조직의 공식 대표자의 책임이다. 회원 메일링 리스트에 관한 정보는 신규 회원 오리엔테이션에 나와 있다.

4.1.1 기밀 수준 변경

회원 자격을 가진 자에 대한 혜택으로서, W3C는 특정한 유형의 통신을 위한 몇 가지 팀 전용 및 회원 전용 채널을 제공한다. 예를 들어, 자문 위원회 대표들은 팀 전용 채널로 검토 결과를 보낼 수 있다. 하지만 권장 사항 추적 프로세스와 같은 중요한 공공 구성 요소가 있는 W3C 프로세스의 경우, 공개되는 의사 결정에 영향을 주는 정보에도 중요하다. 팀은 워킹 그룹 또는 일반 대중에게 팀 전용 정보를 알려야 할 필요가 있을 수도 있다. 이와 비슷하게, 업무 진행 내용이 회원 전용인 워킹 그룹은 반드시 공공 정보가 권장 사항 추적 프로세스에 적절하도록 해야 한다.

이 문서는 정보가 처음에는 팀 전용 또는 회원 전용 채널 상에서 전달되었다 할지라도, 회원이나 일반 대중에게 어떤 정보를 반드시 제공해야 할지 분명히 밝히고 있다. 팀과 팀에서 공인한 당사자만이 이 정보의 기밀 수준을 변경한다. 이렇게 기밀 수준을 변경할 때는 다음 절차에 따른다.

  1. 팀은 반드시 새로운 기밀 수준에 대해 저작자에 의해 명시적으로 제공된 정보의 버전을 사용해야 한다. 검토 요청서와 기타 유사한 메시지에서, 팀은 수령인이 이러한 대체 방안을 제공하도록 상기시켜 주어야 한다.
  2. 팀은 절대로 새로운 기밀성 수준에 대한 버전을 저작자의 동의 없이 저작자에게 떠넘겨서는 안 된다.
  3. 저작자가 또 다른 기밀성 수준에 적합한 버전을 팀에 전달하지 않은 경우, 팀은 기밀성의 원래 수준을 존중하면서도 원 저작자에게 떠넘기지 않고 무엇이 필요한지 합당한 방식으로 알려주는 버전을 사용할 수 있도록 할 수 있다.

5 활동

이 단원에서는 컨소시엄이 추적하기로 한 웹 개발의 분야 내에서 합의를 형성하기 위한 메커니즘을 설명한다. 활동은 웹 기술의 개발 또는 진화에 필요한 작업을 조직하는 것이다.

W3C는 회원 및 팀으로부터의 이익을 바탕으로 활동을 시작한다. W3C 회원들은 자문 위원회 대표, 의장 및 팀 사이의 논의를 통해, 그리고 의뢰 과정을 통해 새로운 작업을 중심으로 이익을 실현한다. 팀은 W3C 내부와 외부의 웹 발전 상황을 추적하고, 연락 문제를 관리하고, 워크숍을 조직한다.

활동의 구조와 범위에 대한 팀 및 회원으로부터의 입력을 바탕으로, 팀은 자문 위원회에 활동 제안서를 보낸다. 이것은 웹 기술 또는 정책의 특정 분야에 팀과 회원이 가진 자원을 전력 투구하기 위한 제안으로서, 동기, 범위 및 제안된 작업의 구조에 대한 합의가 있을 때 W3C는 새로운 활동을 시작한다.

각 활동에는 일반적으로 워킹 그룹, 이해 집단 및 조정 그룹을 포함하는 자체적인 구조가 있다. 활동의 틀 내에서, 이들 그룹은 기술 보고서를 작성하고, 그룹의 작업을 검토하고, 샘플 코드 또는 테스트 수트를 개발한다.

각 활동의 진행 상황은 활동 일람표에 문서화된다. 활동 일람표에는 활동의 목표, 완성 및 미완성된 결과물, 경험을 토대로 하여 변화하는 전망 및 향후 계획이 설명되어 있다. 최소한 각각의 자문 위원회 회의가 열리기 전, 팀은 종결되지 않은 각 활동에 대한 활동 일람표를 교정해야 한다.

W3C 활동 목록 [PUB9]을 참조한다. 주: 이 목록에는 활동 생성 프로세스가 1997년에 형성되기 전에 시작된 몇 가지 활동이 포함될 수 있다.

5.1 활동 제안서 개발

팀은 반드시 새 활동 또는 변경된 활동에 대한 제안서가 개발 중일 때 자문 위원회에 알려야 한다. 이것은 아직 어떤 공식적 제안도 나와 있지 않다 하더라도 인식도를 높이기 위해서 이다. 자문 위원회 대표들은 자문 위원회 토론 목록에 대한 자신의 일반적 지지 의사를 표명할 수 있다. 팀은 토론의 논점을 활동 제안서에 수용할 수 있다. 권장 사항을 보다 빨리 준수하기 위한 추가적인 팁 [PUB27]을 참조한다.

5.2 활동 제안서에 대한 자문 위원회의 검토

감독은 반드시 모든 제안서에 대해 자문 위원회의 검토를 요청하여 활동을 만들고, 실질적으로 변경하고, 확대해야 한다.

감독으로부터의 검토 요청이 있은 후, 자문 위원회는 그 제안서를 검토하고 의견을 제시한다. 검토 기간은 반드시 최소한 4주 이상이어야 한다.

감독은 활동을 생성하거나 변경하기 위해 W3C 내부에 합의가 있는지 여부를 자문 위원회에 발표한다 (검토 중에 제안된 변경 사항과 함께). 새로운 활동에 대해, 이 발표는 공식적으로 그 활동을 생성한다. 이 발표에는 활동의 일부로 만들어진 그룹에서의 참석 요청포함될 수 있다.

이의 제기가 있었던 경우, 자문 위원회 대표는 결정 사항을 상고하여 활동을 생성, 변경 또는 확대할 있다. 주: 활동을 생성하지 않기로 한 결정의 상고가 없는 경우, 일반적으로 새로운 활동 제안서를 작성하는 것은 상고 과정을 따르는 것보다 더 간단할 것이다.

5.3 활동 변경

활동은 융통성을 가지고 이루어진다. W3C는 원래의 활동 제안서의 의미를 따르는 한편, 새로운 아이디어 (예: 회원 의뢰 요청)와 목표 및 문맥에 대한 이해가 증진되면서 참가자들이 이를 수용할 수 있을 것으로 기대한다. 활동에 실질적인 변경을 할 필요가 생길 경우 (예: 중요한 추가적 자원이 필요하거나 활동의 범위가 원래 제안에서 분명히 바뀌었기 때문에), 감독은 반드시 변화에 대한 논리적 근거를 비롯하여, 완전한 활동 제안서자문 위원회 검토를 요청해야 한다.

5.4 활동의 확대

감독이 활동의 구성에 대한 다른 실질적 변경 없이 활동의 지속 기간을 연장하기 위해 제안서에 대한 자문 위원회 검토를 요청하는 경우, 그 제안서에는 반드시 새 지속 기간이 표시되어 있어야 하고, 기간 연장에 대한 논리적 근거가 포함되어 있어야 한다. 감독은 완성된 활동 제안서를 제출할 필요는 없다.

5.5 활동 종결

활동 제안서에는 활동에 대한 지속 기간이 명시되어 있다. 자문 위원회 대표에 의한 상고에 따라, 감독은 다음과 같은 상황에서 제안서에 지정된 날짜 이전에 활동을 종결할 수 있다.

감독은 자문 위원회에 발표함으로써 활동을 종결한다.

5.6 활동 제안서

활동 제안서는 활동의 초기 범위와 구조를 정한 것이다. 이 제안서에는 반드시 다음 정보가 포함되거나 참조되어야 한다.

6 워킹 그룹, 이해 집단 및 조정 그룹

이 문서에서는 다음 세 가지 유형의 그룹을 정의한다.

  1. 워킹 그룹. 워킹 그룹은 일반적으로 결과물 (예: 권장 사항 추적 기술 보고서, 소프트웨어, 테스트 수트 및 다른 그룹의 결과물 검토)을 만들어낸다. 워킹 그룹 참가를 위한 적격성 요구 사항뿐 아니라, W3C 특허 정책 [PUB33]에 설명되어 있는 추가적인 참석 요구 사항이 있다.
  2. 이해 집단. 이해 집단의 주요 목표는 잠재적 웹 기술과 정책을 평가하고 싶어 하는 사람들을 한데 모아놓는 것이다. 이해 집단은 아이디어 교환을 위한 포럼이다. 이해 집단 참가를 위한 적격성 요구 사항은 없다. 이해 집단은 W3C 권장 사항을 만들지 않는다.
  3. 조정 그룹. 조정 그룹은 의존성을 관리하고 W3C 내, 외부적으로 다른 그룹과의 커뮤니케이션을 촉진한다.

6.1 모든 작업, 이해 및 조정 그룹에 대한 요구 사항

각 그룹은 반드시 헌장을 가지고 있어야 한다. 헌장에 대한 요구 사항은 그룹의 유형에 따라 달라진다. 모든 그룹 헌장은 반드시 공개되어야 한다. (그룹의 다른 업무 진행이 회원 전용인 경우에도) 아직 공개되어 있지 않은 기존의 헌장들은 다음 번에 개정 또는 확대될 때 (기밀 수준 변경에 대한 관심과 함께) 반드시 공개되어야 한다.

각 그룹에는 그룹이 맡은 과제를 조정하기 위해 반드시 의장 (또는 공동 의장)이 있어야 한다. 감독이 모든 그룹의 의장을 임명 (및 재임명)한다. 의장은 회원 대표, 팀 대표 또는 초빙 전문가 (감독에 의해 초빙됨)이다. 이러한 유형의 참가자들에게 적용되는 이 문서의 요구 사항은 의장에게도 적용된다. 의장의 역할 [MEM14]회원 안내서 [MEM9]에 설명되어 있다.

각 그룹에는 반드시 의장, 그룹 참가자 및 팀의 나머지 사람들 사이에 인터페이스 역할을 하는 팀 연락 담당자가 있어야 한다. 팀 연락 담당자의 역할은 회원 안내서에 설명되어 있다. 의장과 그룹의 팀 연락 담당자가 동일한 인물이어서는 안 된다.

각 그룹에는 반드시 공식적인 그룹 커뮤니케이션을 위해 보관된 메일링 리스트가 있어야 한다. (예: 회의 발표 및 의사록, 결정 사항의 문서화 및 결정 사항에 대한 이의 제기를 위해) 새로 참가한 자들이 모든 관련 메일링 리스트에 등재되도록 하는 것은 의장과 팀 연락 담당자의 책임이다. 그룹 메일링 리스트 [MEM2]을 참조한다.

의장은 자신의 그룹에 주어진 과제를 수행하기 위해 태스크 포스팀 (그룹 참가자로 구성됨)을 구성할 수 있다. 이들 과제의 범위는 절대로 그룹 헌장의 범위를 벗어나면 안 된다. 그룹은 태스크 포스팀을 만들기 위해 사용하는 프로세스를 문서화해야 한다 (예: 각 태스크 포스팀에는 비공식적인 "헌장"이 있을 수 있음). 태스크 포스팀은 기술 보고서를 출판하지 않는다. 워킹 그룹은 기술 보고서의 일부로 그 결과를 출판하는 쪽으로 선택할 수 있다.

6.2 워킹 그룹과 이해 집단

워킹 그룹과 이해 집단은 상이한 목적을 가지고 있지만, 이들은 몇 가지 공통적인 특징이 있으므로 다음 절에서 함께 정의된다.

6.2.1 워킹 그룹 및 이해 집단 요구 사항

워킹 그룹에는 세 가지 종류의 개인 참가자가 있다. 즉, 회원 대표, 초빙 전문가팀 대표가 있다 (팀 연락 담당자 포함).

이해 집단에는 네 가지 종류의 개인 참가자가 있다. 워킹 그룹과 동일한 세 가지 유형의 개인 참가자에다, 참가 요구 사항이 메일링 리스트 가입만 있는 이해 집단인 공공 참가자가 있다.

이 문서 또는 그룹 헌장에서 명시한 사항을 제외하고, 모든 참가자는 그룹에서 똑 같은 권리와 책임을 공유한다. 개인 참가 기준도 참조한다.

개인은 반드시 워킹 그룹 또는 이해 집단에서 하나의 조직만 대표해야 한다.

개인은 그룹이 존재하는 동안 언제든 워킹 그룹 또는 이해 집단 참가자가 수 있다. W3C 특허 정책 [PUB33]의 4.3절에 있는 관련 요구 사항도 참조한다.

예외적인 경우로서, 워킹 그룹 또는 이해 집단 참가자는 대리인을 선임하여 회의에 대신 출석토록 수 있고, 의장에게 이 사실을 통지해야 한다. 대리인은 투표권 행사를 포함하여, 자신에게 권한을 위임한 참가자의 입장에서 행동할 수 있다. 투표 대리를 위해, 참가자는 반드시 의장에게 사전에 서면으로 이를 통지해야 한다. 그룹에 대한 관례로서, 대리인이 그룹의 논의 내용에 정통하지 않은 경우, 정규 참가자는 또 다른 참가자가 투표 대리인으로 행동하도록 공인해주어야 한다.

신속한 진행을 위해, 워킹 그룹은 소규모로 하는 것이 좋고 (일반적으로, 15명 미만), 헌장에서 정의된 분야의 전문가들로 구성된다. 원칙적으로, 이해 집단은 참가자 수에 제한이 없다. 워킹 그룹의 규모가 너무 커져 효율성이 없는 경우, W3C는 워킹 그룹을 이해 집단 (토론 포럼)과 훨씬 더 작은 규모의 워킹 그룹 (고도의 전문성을 갖춘 참가자들로 이루어진 코어 그룹)으로 분할할 수도 있다.

W3C 특허 정책 [PUB33]의 3절에 있는 워킹 그룹 참가자에 대한 라이센스 의무와 4절의 특허 청구 배제 과정도 참조한다.

6.2.1.1 워킹 그룹의 회원 대표

다음의 모든 조건을 만족하는 개인은 워킹 그룹에서 회원 대표가 된다.

한 개인을 워킹 그룹의 회원 대표로 지명하려면, 자문 위원회 대표는 반드시 의장과 팀 연락 담당자에게 참가 요청서와 헌장 (W3C 특허 정책 [PUB33]의 참가 요구 사항 포함)에서 요구되는 다른 모든 정보 외에, 다음의 모든 정보를 제공해야 한다.

  1. 그 개인이 대표하는 W3C 회원의 이름과 그 개인이 그 회원 조직의 고용인인지 여부
  2. 그 개인이 헌장에서 명시된 참가 조건을 수용한다는 진술서 (헌장 제정 / 개정 날짜 또는 버전이 표시되어 있어야 함)
  3. 회원이 참가에 필요한 재정적 지원 (예: 여비, 전화비 및 컨퍼런스)을 제공할 것이라는 진술서

회원은 최초의 회원 대표가 그룹에 합류하는 시점부터 다음 사항 중 하나가 발생할 때까지 워킹 그룹에 참가하는 것으로 한다.

6.2.1.2 이해 집단의 회원 대표

참가 요구 사항이 이해 집단 메일링 리스트 가입 요건을 초과하는 경우, 다음의 모든 조건을 만족하는 개인은 회원 대표가 된다.

개인을 이해 집단의 회원 대표로 지명하려면, 자문 위원회 대표는 반드시 참가 요청서와 헌장에 나와 있는 지침을 따라야 한다.

이해 집단의 회원 참가는 워킹 그룹에서와 동일한 조건 하에서 중단된다.

6.2.1.3 워킹 그룹의 초빙 전문가

의장은 특별한 전문 지식이 있는 개인이 워킹 그룹에 참가하도록 초빙할 수 있다. 이 개인은 그룹에서 한 조직을 대표할 수 있다. (예: 또 다른 조직과의 연락 업무를 담당하는 경우)

어떤 개인이 다음의 모든 조건을 만족하는 경우, 그는 워킹 그룹의 초빙 전문가가 된다.

한 개인을 워킹 그룹에서 초빙 전문가로 지명하려면, 의장은 반드시 팀 연락 담당자에게 이를 통지하고 최종 선택에 대한 논거를 제시해야 한다. 의장과 팀 연락 담당자가 지명에 대해 동의하지 않는 경우, 감독은 그 개인이 워킹 그룹에 참가하도록 초빙을 받을지 여부를 결정한다.

초빙 전문가로 워킹 그룹에 참가할 수 있으려면, 개인은 반드시 다음 사항을 모두 이행해야 한다.

의장은 W3C 회원의 고용인인 개인을 워킹 그룹의 초빙 전문가로 지명해서는 안 된다. 의장은 절대로 헌장에 의해 부과된 참가 제한을 교묘히 피해가기 위해 초빙 전문가 상태를 이용해서는 안 된다.

초빙 전문가는 개인이 그룹에 합류하는 시점부터 다음 사항 중 한 가지라도 발생할 때까지 워킹 그룹에 참가하는 것으로 한다.

6.2.1.4 이해 집단의 초빙 전문가

참가 요구 사항이 이해 집단 메일링 리스트 가입 요건을 초과하는 경우, 이해 집단의 초빙 전문가에 대한 참가 요구 사항은 워킹 그룹의 초빙 전문가에 대한 요구 사항과 동일하다.

6.2.1.5 워킹 그룹의 팀 대표

W3C 경영진은 개인을 워킹 그룹의 팀 대표로 지명할 수 있다.

팀 대표는 개인이 그룹에 합류하는 시점부터 다음 사항 중 하나가 발생할 때까지 워킹 그룹에 참가하는 것으로 한다.

팀은 감독이 그룹의 생성을 발표하는 시점부터 그 그룹이 폐쇄될 때까지 워킹 그룹에 참가하는 것으로 한다.

6.2.1.6 이해 집단의 팀 대표

참가 요구 사항이 이해 집단 메일링 리스트 가입 요건을 초과하는 경우, W3C 경영진은 개인을 이해 집단의 팀 대표로 지명할 수 있다.

6.2.1.7 워킹 그룹의 적격성

지속적으로 워킹 그룹에 참가하는 것은 다음 모든 사항을 포함하여, 헌장을 진지하게 준수함을 의미한다.

의장과 팀 연락 담당자가 동의하는 경우, 의장은 참가자가 더 이상 적격성 요건을 갖추고 있지 못하다고 (이후 "부적격성"이라 함) 선언할 수 있다. 의장과 팀 연락 담당자 사이에 적격성에 대한 의견 불일치가 있는 경우, 감독이 해당 참가자의 적격성을 결정한다. 의장은 팀 참가자가 부적격 상태라고 선언할 수 있지만, 의장, 팀 참가자 및 W3C 경영진이 이 문제를 내부적으로 해결하는 것이 분명히 더 바람직한 것이다.

참가자는 다음 상황에서 부적격으로 선언될 수 있다.

한 조직을 대표하는 모든 참가자는 모든 회의에 출석해야 하지만, 조직의 한 대표만 출석해도 조직의 모든 대표에 대한 회의 출석 요건을 만족하는 것이 된다.

의장과 팀 연락 담당자가 상기 기준을 완화하더라도 워킹 그룹에 방해가 되지 않을 것이라고 동의하는 경우, 기준이 완화될 수 있다. 예를 들어, 출석 요건은 경비 (예: 여비) 또는 일정 (예: 이례적인 텔레컨퍼런스가 해당 참가자가 거주하는 지역 시간으로 오전 3시로 예정되어 있는 경우) 상의 이유로 완화될 수 있는 것이다. 적격성에 대한 기준을 일관되게 적용하는 것은 의장과 팀 연락 담당자의 책임이다.

어떤 참가자가 적격성을 잃을 위험이 있는 경우, 의장과 팀 연락 담당자는 그 참가자의 부적격성을 선언하기 전에 참가자와 참가자의 자문 위원회 대표 (또는 팀에 대한 W3C 경영진)와 그 문제를 논의할 것으로 기대된다.

의장은 참가자의 자문 위원회 대표와 참가자에게 결정 사항을 통지함으로써 참가자의 부적격성을 선언한다. 자문 위원회 대표와 의장의 의견이 다른 경우, 자문 위원회 대표는 감독에게 결정 사항을 확인하거나 부인해줄 것을 요청할 수 있다. 부적격으로 선언된 초빙 전문가는 감독에게 상고할 수 있다.

의장과 팀 연락 담당자는 적격성을 회복하고 부적격 상태의 개인이 상기 기준을 만족할 때 적격성을 회복시켜야 한다. 의장은 반드시 적격성에 어떤 변화가 있을 경우 이를 해당 개인의 자문 위원회 대표에게 통지해야 한다.

워킹 그룹에서 개인의 적격성이 변하더라도 W3C 특허 정책 [PUB33]에서 설명되는 워킹 그룹 참가와 관련된 의무에는 아무런 영향이 없다.

6.2.2 워킹 그룹 및 이해 집단 헌장 제정

팀은 새로운 워킹 그룹이나 이해 집단에 대한 헌장이 개발 중일 때 반드시 자문 위원회에 이를 알려야 한다. 활동 제안서에 대한 지지를 구축하기 위한 제안은 헌장에도 적용된다.

W3C는 언제든 워킹 그룹 또는 이해 집단 헌장에 대한 작업을 시작할 수 있다. 워킹 그룹 또는 이해 집단은 반드시 승인된 활동의 일부여야 한다.

6.2.3 워킹 그룹 또는 이해 집단 헌장에 대한 자문 위원회 검토

감독은 새롭거나 실질적으로 수정된 모든 워킹 그룹 또는 이해 집단 헌장에 대해 반드시 자문 위원회 검토를 요청해야 한다. 감독은 헌장 확대 또는 경미한 변경을 하기 전에 자문 위원회의 검토를 반드시 요청할 필요는 없다.

실질적으로 수정된 헌장에 대한 감독의 검토 요청서에는 반드시 중요한 변경 사항이 강조 표시되어 있어야 하고 (예: 결과물 또는 자원 할당에 관해) 그 변경 사항에 대한 논리적 근거가 포함되어 있어야 한다.

6.2.4 워킹 그룹 또는 이해 집단에의 참가 요청

워킹 그룹 또는 이해 집단 헌장에 대한 자문 위원회의 검토가 끝난 후, 감독은 자문 위원회에 참가 요청서를 발행할 수 있다. 새로운 그룹의 경우, 이 발표로 공식적으로 그룹을 만들게 된다. 이 발표에는 반드시 헌장, 그룹 의장의 이름, 그리고 팀 연락 담당자의 이름에 대한 조회처가 포함되어야 한다.

참가 요청 후, 모든 회원 대표초빙 전문가반드시 지명 (또는 재지명) 되어야 한다.

자문 위원회 대표는 워킹 그룹 또는 이해 집단 헌장의 작성 또는 실질 변경을 상고 있다.

6.2.5 워킹 그룹 및 이해 집단 헌장 확대

다른 실질 변경을 하지 않고 워킹 그룹 또는 이해 집단의 헌장을 확대하려면, 감독이 자문 위원회에 이 사실을 발표해야 한다. 이 발표에서는 반드시 새로운 지속 기간을 표시해야 하는데, 그 그룹이 속해 있는 활동의 지속 기간을 절대 초과하면 안 된다. 이 발표에는 반드시 기간 연장에 대한 논리적 근거, 헌장에 대한 조회처, 그룹 의장의 이름, 팀 연락 담당자의 이름 및 그룹에 합류하기 위한 지침도 포함되어야 한다.

헌장이 확대된 후, 자문 위원회 대표와 의장이 회원 대표초빙 전문가를 다시 지명할 필요는 없다.

자문 위원회 대표는 워킹 그룹 또는 이해 집단 헌장의 확대를 상고 있다.

6.2.6 워킹 그룹 및 이해 집단 헌장

워킹 그룹 또는 이해 집단 헌장에는 반드시 다음의 모든 정보가 포함되어야 한다.

W3C 특허 정책 [PUB33]의 2절3절의 헌장 요구 사항도 참조한다.

이해 집단 헌장에는 이해 집단에 (누구나) 참가하기 위한 유일한 요건은 이해 집단 메일링 리스트에 가입하는 것으로 충분하다는 것을 명시할 수 있다. 이러한 유형의 이해 집단에는 공공 참가자참가할 수 있다.

헌장에는 추가적인 투표 절차가 포함될 수 있지만, 이러한 절차들은 프로세스 문서의 투표 요구 사항절대 상충되어서는 안 된다.

헌장에는 이 문서에서 요구되는 것 이외의 조항이 포함될 수 있다. 헌장에는 추가적인 조항이 W3C 프로세스 문서의 제한 사항 (예: 똑 같은 회원 조직 또는 관련 회원의 그룹을 대표하는 워킹 그룹의 개인들의 인원 수에 대한 제한) 이외의 제한을 가하는지 여부가 강조 표시되어야 한다.

6.2.7 워킹 그룹 "하트비트 (Heartbeat)" 요구 사항

워킹 그룹이 최종 상태에 있지 않은 권장 사항 추적 프로세스에 하나 이상의 기술 보고서를 가지고 있는 경우, 최소한 매 3개월마다 그룹은 반드시 W3C 기술 보고서 색인 [PUB11]에 이들 중 최소 하나 이상의 새로운 초안을 출판해야 한다. 각 워킹 그룹은 최소한 매 3개월마다 각각의 유효한 기술 보고서의 새로운 초안을 출판해야 한다.

예외적인 경우, 의장은 감독이 이 출판 요구 사항으로부터 면제되도록 요청할 수 있다. 하지만 이 경우, 워킹 그룹은 반드시 새로운 초안이 출판되지 않은 이유에 대한 근거와 함께 공개적인 상태 보고서를 발행해야 한다.

이 워킹 그룹 "하트비트 (Heartbeat)" 요구 사항에 대해 다음과 같이 몇 가지 이유가 있다.

한 가지 예로서, 워킹 그룹이 제안 권장 사항으로서 출판하는 결과물로 기술 보고서를 하나 발표한다고 가정해보자. 하트비트 요구 사항에 따라, 워킹 그룹은 제안 권장 사항 문서의 상태를 개정하는 목적만 있다 할지라도 (예: 결정 사항의 상태에 대한 업데이트를 미리 제공하기 위해), 최소한 매 3개월마다 제안 권장 사항의 새로운 초안을 출판해야 한다. 그 문서가 권장안 (또는 워킹 그룹 노트)이 될 때 하트비트 요구 사항이 중단된다.

6.2.8 워킹 그룹 및 이해 집단 폐쇄

워킹 그룹 또는 이해 집단 헌장에는 그 그룹에 대한 존속 기간이 명시되어 있다. 자문 위원회 대표에 의한 상고에 따라, 감독은 다음 중 어떤 상황에서 헌장에 명시된 날짜 이전에 그룹을 폐쇄할 수 있다.

감독은 자문 위원회에 발표를 하여 워킹 그룹 또는 이해 집단을 폐쇄한다.

워킹 그룹 폐쇄는 W3C 특허 정책 [PUB33]과 밀접한 관련이 있다.

6.3 조정 그룹

W3C 활동은 여러 가지 방법으로 상호 작용을 한다. 동일한 활동 또는 상이한 활동 내의 그룹 간에는 의존 관계가 있다. 또한 W3C 활동과 다른 조직의 활동 사이에도 의존 관계가 있다. 의존 관계의 예에는 어딘가에서 개발되고 있는 다른 기술 중 한 기술의 이용, 그룹 간 일정의 제한, 그리고 결과물 발표에 대한 동시 공표가 포함된다. 조정 그룹은 문제가 공정하게 해결되고 솔루션이 W3C의 사명과 결과에 일치하도록 의존 관계를 관리하기 위해 만들어진다.

조정 그룹의 범위가 해결되지 않은 분쟁이나 긴장 관계를 가지고 있는 두 그룹을 포괄하는 경우, 이러한 분쟁의 해결이 제일의 관심사이다.

6.3.1 조정 그룹 참가 요구 사항

조정 그룹에는 네 가지 종류의 참가자가 있다. 그들은 의장, 조정된 각 그룹의 의장 (그룹들 사이의 효과적인 커뮤니케이션 증진을 위해), 초빙 전문가 (예: W3C 내, 외부의 그룹에 대한 연락 담당) 및 팀 대표 (팀 연락 담당자 포함)이다. 초빙 전문가 참석을 위한 요건은 워킹 그룹의 초빙 전문가에 대한 참석 요건과 동일하다.

조정 그룹 참가자는 반드시 그룹의 나머지 구성원에게 정보를 공개함으로써 이해 상충 정책에 따라야 한다.

조정 그룹 참가를 위한 적격성 요건은 없으며, 관련 조정 그룹에 정기적으로 참석하는 것이 그룹 의장의 역할 [MEM14] 중 하나이다.

6.3.2 조정 그룹 개설 및 폐쇄

감독은 자문 위원회에 조정 그룹 헌장을 보내어 조정 그룹을 개설하거나 변경한다. 조정 그룹은 활동 제안 (예: 해당 활동에서 다른 그룹을 조정하거나 미래의 그룹의 헌장을 작성하기 위해)의 일부로 개설되거나 의존 관계가 발생할 때 활동의 존속 기간 동안 개설될 있다. 조정 그룹은 여러 가지 W3C 활동의 일부로 운영할 수 있다.

조정의 필요성이 더 이상 없는 것으로 파악되는 경우 조정 그룹은 폐쇄되어야 한다.

6.3.3 조정 그룹 헌장

조정 그룹 헌장에는 반드시 다음 모든 정보가 포함되어야 한다.

헌장에는 추가적인 투표 절차가 포함될 수도 있지만, 이들 절차는 절대로 프로세스 문서의 투표 요구 사항과 충돌을 일으켜서는 안 된다.

헌장에는 이 문서에서 요구하는 것 이외의 조항이 포함될 수 있다. 헌장에는 W3C 프로세스 문서의 조항 이외에, 추가 조항이 제한을 가하는지 여부가 강조 표시되어야 한다.

7 W3C 권장 사항 추적 프로세스

권장 사항 추적 프로세스는 웹 기술을 표준화하기 위해 W3C 워킹 그룹이 따르는 일련의 단계와 요구 사항이다. 사양과 가이드라인 (이 절에서는 기술 보고서라고 함)을 관리하기 위해 워킹 그룹이 따르는 프로세스에는 다음 사항이 포함된다.

W3C 권장 사항 추적 프로세스는 기술 보고서의 내용에 대한 합의를 극대화하고, 높은 기술 및 편집 품질을 보장하고, W3C와 보다 폭 넓은 커뮤니티로부터 보증을 받을 수 있도록 고안되어 있다. W3C 특허 정책 [PUB33]의 2절에 있는 W3C 권장 사항에 대한 라이센스 목표도 참조한다.

다음 단원에서는 아래 내용을 설명한다.

완성도가 먼저 설명되고, 뒤를 이어 권장 사항 추적에 대한 단계와 각 단계에 대한 요구 사항이 설명된다.

7.1 권장 사항 추적 프로세스 완성도

출판된 기술 보고서의 완성도는 권장 사항 추적 프로세스에서의 입장을 나타낸다. "작업 초안" 및 "워킹 그룹 노트" 완성도는 권장 사항 추적 프로세스에서 기술 보고서의 가능한 초기 상태를 나타낸다. "권장 사항", "워킹 그룹 노트" 및 "권장 사항 폐기" 완성도는 가능한 최종 상태를 나타낸다.

7.1.1 권장 사항에 맞춰 기술 보고서 작성 시의 완성도

작업 초안 (WD)
작업 초안은 W3C 회원, 일반 대중 및 기타 기술 조직을 비롯하여, 커뮤니티의 검토를 위해 출판한 문서이다.
후보 권장 사항 (CR)
후보 권장 사항은 W3C가 워킹 그룹의 기술 요구 사항을 폭 넓게 검토하여 만족하는 것으로 믿는 문서이다. W3C는 실행 경험을 수집하기 위해 후보 권장 사항을 출판한다.
제안 권장 사항 (PR)
제안 권장 사항은 기술의 확실성과 구현 능력을 폭 넓게 검토한 후, W3C가 최종 승인을 위해 W3C 자문 위원회로 송부한 성숙한 기술 보고서이다.
W3C 권장 사항 (REC)
W3C 권장 사항은 광범위하게 합의를 구축한 후에 W3C 회원과 감독의 보증을 받은 사양 또는 일련의 가이드라인이다. W3C는 그 권장 사항의 폭 넓은 배치를 권장한다. 주: W3C 권장 사항은 다른 조직이 출판하는 표준과 유사하다.

7.1.2 기술 보고서에 대한 작업 종료 시 완성도

워킹 그룹 노트
워킹 그룹 노트는 특정 주제에 대한 작업이 끝났음을 나타내기 위해, 공인된 워킹 그룹에 의해 출판된다. 워킹 그룹은 작업 초안으로 사전 출판을 하거나 하지 않은 상태에서 워킹 그룹 노트를 출판할 수 있다. 또한 W3C는 그러한 종류의 그룹에 의한 유사 출판물에 대해 “이해 집단 노트”와 “조정 그룹 노트”도출판할 수 있다. 이해 집단과 조정 그룹은 권장 사항을 지향하는 기술 보고서를 작성하지 않는다.
주: 어떤 문서가 공인된 그룹의 작업 결과를 나타내는지, 그리고 어떤 문서가 W3C의 활동 (회원 의뢰팀 의뢰)에 입력으로서 제공되는지에 관해 개발자 커뮤니티와 매체에 혼선이 생기는 것을 방지하기 위해, W3C는 아직 충분히 발전되지 않은 완성도인 “노트”를 이용하는 것을 중단할 계획이다.

7.1.3 권장 사항 편집 시 완성도

제안된 편집 권장 사항
제안된 편집 권장 사항은 커뮤니티가 적합성에 일부 영향을 줄 수 있는 변경 사항을 검토할 수 있도록 출판된 권장 사항이다. 변경 사항에 대한 합의가 있는 경우, 이 문서는 권장 사항으로 출판된다.

7.1.4 권장 사항 폐기 시 완성도

폐기된 권장 사항
폐기된 권장 사항은 W3C가 더 이상 보증하지 않는 전체 권장 사항이다.

7.2 제출을 위한 일반적인 요구 사항

권장 사항으로 출판되는 것을 비롯한 실행 요청에 대해, 워킹 그룹은 반드시 다음 사항에 따라야 한다.

  1. 진전을 요청한다는 그룹의 의사 결정을 기록한다.
  2. 해당 문서가 이전 단계 이후에 실질적으로 수정되었는지 여부를 표시한다. 실질적인 변경 사항 (삭제, 포함 또는 기타 수정인지 여부 불문)은 그러한 변경을 함으로써 개인의 검토 또는 실행 경험을 무효화하게 될 것이라고 합당하게 예상할 수 있는 경우이다. 기타 변경 사항 (예: 명확화, 버그 수정, 편집 상의 교정 및 사소한 오류 교정)은 경미한 변경 사항이다. 워킹 그룹은 반드시 각 단계 간의 변경 사항 (실질적 변경과 사소한 변경 모두 포함)을 문서화해야 한다.
  3. 이 문서에 대한 워킹 그룹의 요구 사항이 있는 경우, 그 요구 사항이 이전 단계로부터 바뀌었을 때 이를 보고한다.
  4. 다른 그룹과의 의존 관계에 있어서의 변화를 모두 보고한다.
  5. 폭 넓은 검토의 증거를 보여준다.
  6. 이전 단계 이후에 이 문서에 대해 제기된 모든 문제를 공식 해결한다. 사실상, 워킹 그룹이 후보 권장 사항을 제출하거나 그 이상 나아가고자 하는 경우, 감독은 문제가 공식적으로 해결된 긍정적 문서를 기대한다. (예: 문제를 어떻게 처분했는지 보여주는 문제 목록) 권장 사항 추적의 초기 단계에서는, 일반적으로 덜 공식적인 문서로도 충분하다. (예: 보관된 메일링 리스트에 있는 증거)
  7. 모든 공식적 이의 제기를 보고한다.

다음 정보는 기술 보고서를 제출하기로 결정하는 데 중요하고, 따라서 반드시 공개되어야 한다.

7.3 검토 및 검토 책임

경험에 따르면, 다음과 같이 하는 것이 기술 보고서에 대한 합의 형성에 도움이 된다.

  1. 빈번한 출판 (워킹 그룹 “하트비트 (Heartbeat)” 요구 사항 참조).
  2. 조기 검토를 통해 오류를 신속히 찾아내고 기술 다변화 가능성 축소.
  3. W3C 내부와 외부의 다른 그룹에 의한 검토를 비롯한 폭 넓은 검토 작업.

문서는 그것이 최초로 출판되는 시점에서부터 검토를 받는다. 1차 공개 작업 초안부터 시작하여 제안 권장 사항 검토가 시작될 때까지, 워킹 그룹은 반드시 기술 보고서에 관한 모든 실질 검토 의견을 공식적으로 다루어야 하고, 이를 적시에 시행해야 한다. 감독은 제안 권장 사항, 제안된 편집 권장 사항 및 제안된 폐기 권장 사항 검토 기간 중에 자문 위원회 대표가 제기하는 모든 실질적 문제를 반드시 공식적으로 해결해야 한다. 워킹 그룹은 제안 권장 사항, 제안된 편집 권장 사항 및 제안된 폐기 권장 사항 검토 기간 중에 자문 위원회 대표 이외의 당사자가 제기한 모든 실질적 문제를 반드시 감독에게 전달해야 한다. (대개는 팀 연락 담당자를 통해 전달함)

검토자는 권장 사항 추적 과정에서 실질 기술 검토서를 늦게 보내면 안 된다. 검토자는 워킹 그룹이 문서를 성숙시키기 위해 곧 바로 실질 변경을 할 준비가 되어 있을 것이라 기대해서는 안 된다. 워킹 그룹이 폭 넓은 검토를 했다는 증거를 많이 보여줄 수 있을수록, 권장 사항 추적 과정에서 늦게 제공되는 경우 비중 있는 실질 의견이 덜 나오게 된다. 가치 있는 아이디어는 비록 성숙한 문서에 포함시키지는 않더라도 기록을 해두어야 한다.

워킹 그룹은 반드시 검토자의 질의에 답변하고 그들을 만족시키기 위한 노력을 다했음을 나타내는 증거를 보여줄 수 있어야 한다. 검토자는 워킹 그룹의 문제 처리 방식에 불만스러울 때는 언제든 공식적 이의등록할 수 있다.

워킹 그룹은 관련 연락을 비롯하여, 문서를 검토할 것으로 예상되는 다른 그룹과 검토 일정을 협의해야 한다.

권장 사항으로 제출할 때 지속 기간이 고정되어 있는 두 가지 공식 검토 기간이 있다. 최종 요청 발표 이후와 제안 권장 사항 검토 요청 이후가 그것이다. 워킹 그룹에 대한 고려 사항 외에도, 검토자는 검토 기간의 초기에 의견을 보내야 한다. 워킹 그룹은 현재 검토 작업의 예정된 종료 일자 이전에 새로운 검토 작업을 시작하면 안 된다 (예: 현재의 최종 요청 검토의 예정된 종료 일자 이전에 새로운 최종 요청 검토를 시작하지 않음).

보통, 검토자는 최종 요청 검토 기간이 끝난 이후에 기술 보고서에 관한 실질적 기술 문제를 제기하면 안 된다. 하지만 이런 일은 일어나게 마련이며, 위에서 언급한 바와 같이 워킹 그룹이 이러한 문제들을 공식적으로 해결해야 하는 요구 사항은 제안 권장 사항의 검토 기간이 끝날 때까지 연장된다. 하지만 워킹 그룹이 기술 보고서에 진척을 볼 수 있도록 하기 위해, 워킹 그룹은 최종 요청 검토의 종료 일자와 권장 사항의 출판 일자 사이에 제기되는 문제를 해결하기 위해 실질적 변경을 수 있다. 검토자는 공식적 이의등록할 수 있다.

자문 위원회 대표는 제안 권장 사항 검토 기간 중에 새로운 실질적 기술 문제를 제기하면 안 된다. (하지만 제기할 수도 있음) 감독은 제안 권장 사항 검토 기간이 종료된 후 검토자에게 답변할 수 있다. 주: 자문 위원회 대표가 워킹 그룹에 제기한 문제를 전달할 때 기밀성 수준을 변경할 필요가 있을 수도 있다.

회원에 의한 검토 중, 워킹 그룹은 자문 위원회 외부 (예: 일반 대중 또는 다른 W3C 워킹 그룹)에서 통지 및 제기되는 관련 문제도 공식적으로 해결해야 하며, 적시에 감독에게 이 사실을 보고해야 한다.

제안 권장 사항 검토 기간이 끝난 후 워킹 그룹이 실질적 문제를 받는 경우, 워킹 그룹은 반드시 검토자의 질의에 답변해야 하지만, 그 문제를 공식적으로 해결 있다. 이 경우, 워킹 그룹은정오표 추적의 일부로 그 문제를 고려할 수 있다.

7.4 기술 보고서를 권장 사항으로 제출

W3C는 기술 보고서를 권장 사항으로 제출할 때 다음과 같은 단계에 따른다.

  1. 1차 공개 작업 초안의 출판.
  2. 최종 요청 발표
  3. 실행 요청. 주: 다음 단계로의 진입 기준이 이미 충족된 경우, 감독은 워킹 그룹이 이 단계를 건너뛸 수 있도록 허용할 수 있다.
  4. 제안 권장 사항 검토 요청.
  5. 권장 사항으로 출판.

일반적으로, 워킹 그룹은 하나 이상의 권장 사항을 출판할 취지로 이 여정에 착수한다. 하지만 W3C는 언제든 기술 보고서에 대한 작업을 종료 있거나, 워킹 그룹이 향후 작업을 수행할 것을 요청할 수 있으며, 하나 이상의 단계가 반복될 가능성이 있다.

1차 공개 작업 초안과 최종 요청 발표의 출판 시점 사이에, 워킹 그룹은 일반적으로 실질적 변경을 포함하는 개정판을 출판한다. 최종 요청 발표 이후 어떤 두 단계 사이에서도, 워킹 그룹은 초기 단계 이후로 실질적 변경이 없는 경우와 동일한 완성도에서 기술 보고서의 새로운 초안을 출판할 수 있다.

팀은 반드시 자문 위원회와 다른 W3C 그룹에 후보 권장 사항 또는 제안 권장 사항에 대한 개정판을 통지해야 한다.

권장 사항 추적 프로세스의 이 단계들을 실행하는 데는 상당한 시간이 걸릴 수 있으므로, 참가자들은 권장 사항에 보다 빨리 접근하기 위한 팁 [PUB27]을 읽는 것이 좋다.

다양한 단계의 검토와 발표를 위한 준비에 관한 실용적 정보에 대해 회원 안내서에 있는 "권장 사항 추적 전환 방법"을 참조한다.

7.4.1 1차 공개 작업 초안

문서의 완성도: 작업 초안.

발표: 감독은 반드시 다른 W3C 그룹과 일반 대중에게 1차 작업 초안 출판을 발표한다.

목적: 1차 공개 작업 초안의 출판은 해당 문서를 검토하기 시작하는 커뮤니티에게는 하나의 신호이다. 1차 공개 작업 초안의 정책적 의미에 대한 정보는 W3C 특허 정책의 4.1절 [PUB33]을 참조한다.

진입 기준: 의장은 반드시 제출을 요청하는 그룹의 결정을 기록해야 한다. 이렇게 짧은 이름을 가진 문서가 기술 보고서 색인에 나타나는 것은 이번이 처음이므로, 변환을 위해서는 감독 승인이 요구된다.

지속적인 작업: 1차 공개 작업 초안이 출판된 후, 워킹 그룹은 일반적으로 이 헌장에 따라 기술 보고서를 교정한다(워킹 그룹 "하트비트(Heartbeat)" 요구 사항 참조).

작업 초안이 배포된 초기에 폭 넓은 계층의 독자에게 제공될 수 있도록 하기 위해, 작업 초안의 출판을 위한 요구 사항은 공인된 워킹 그룹이 기술 보고서를 출판하도록 하는 계약과 팀의 출판 규칙 [PUB31]을 만족하는 것으로 제한된다. 합의는 출판 승인을 위한 필요 조건이 아니다. 워킹 그룹은 그것이 불안정하고 모든 워킹 그룹 요구 사항을 만족하지 않는다 할지라도, 작업 초안의 출판을 요청할 수 있다.

워킹 그룹은 W3C 내부와 외부, 특히 기술 보고서에 대해 의존 관계가 있는 다른 워킹 그룹으로부터의 기술 보고서를 조기에 폭 넓게 검토하도록 권장해야 한다. 자문 위원회 대표는 1차 공개 작업 초안과 같은 시기, 즉 최종 요청 발표가 있기 전, 그리고 제안 권장 사항 검토 요청이 있기 훨씬 전에 조직 내부에서 검토하도록 권장해야 한다.

워킹 그룹은 적시에 문제를 해결하고 초안들 사이의 변경 사항을 분명히 표시함으로써 계속되는 작업에 대응하고 촉진해야 한다 (예: 실질적 변경 사항의 “차이점”과 요약본을 제공함으로써).

가능한 다음 단계:

7.4.2 최종 요청 발표

문서의 완성도: 작업 초안.

발표: 워킹 그룹은 반드시 최종 요청을 다른 W3C 그룹과 일반 대중에게 발표해야 한다. 최종 요청 발표는 반드시 다음 사항을 따라야 한다.

  1. 검토 의견에 대한 마감 시한을 지정한다.
  2. 알려진 의존 관계를 파악하고 모든 의존적 워킹 그룹으로부터의 검토를 요청한다.
  3. 공개 검토를 요청한다.

목적: 워킹 그룹의 최종 요청 발표는 다음과 같은 것을 의미하는 신호이다.

일반적으로, 최종 요청 발표는 워킹 그룹이 보다 이후의 완성도로 기술 보고서를 진전시킬 계획을 하고 있다는 신호이기도 하다.

워킹 그룹은 최종 요청에서 놀랄만한 일이 발생할 위험을 줄이기 위해 최종 요청 발표 이전에 다른 그룹과 협력해야 한다.

이상적인 것은, 최종 요청 발표 이후에 워킹 그룹은 실질적 변경 사항에 대한 제안 없이 해당 문서에 대한 지원의 표시만을 받는 것이다. 사실상, 최종 요청 발표는 때때로 문서에 실질적 변화가 생기는 의견을 만들어낸다. 워킹 그룹은 최종 요청 발표에 의하여 그룹의 작업을 완료한 것으로 가정하면 안 된다.

진입 기준: 최종 요청을 발표하기 전, 워킹 그룹은 반드시 다음 모든 사항을 수행해야 한다.

  1. 제출 요청을 위한 그룹의 결정을 기록한다.
  2. 워킹 그룹 헌장의 관련 요구 사항과 수반되는 모든 요구 사항 문서의 관련 요구 사항을 이행하거나, 어떤 관련 요구 사항이 이행되지 않았는지 보고한다.
  3. 워킹 그룹이 만족했다고 믿는 다른 그룹과의 의존 관계를 표시하고, 어떤 의존 관계가 만족되지 않았는지 보고한다.

검토의 지속 기간: 발표를 통해 최소한 3주 이상 지속되어야 하는 검토 기간이 시작되지만, 기술 보고서가 복잡하거나 상당한 외부적 의존 관계를 가지고 있는 경우 더 오래 지속될 수도 있다.

지속적인 작업: 검토 기간 중, 워킹 그룹은 팀, 회원, 다른 W3C 그룹 및 일반 대중으로부터 의견을 요청하고 그에 답변한다.

국제 커뮤니티에서 기술 보고서의 적절한 통합을 보장하는 것이 중요하다. 권장 사항 프로세스의 이 단계에서 시작하여, 기술 보고서에는 기술이 기존의 국제 표준과 W3C 외부의 관련 작업에 어떻게 관계되는지에 대한 진술서가 포함되어야 한다.

가능한 다음 단계:

7.4.3 실행 요청

문서의 완성도: 후보 권장 사항.

발표: 감독은 반드시 자문 위원회에 실행 요청을 발표해야 한다.

목적: 이 단계에서, W3C는 기술 보고서가 안정적이고 실행에 적합하다고 믿는다. 기술 보고서는 여전히 실행 경험을 바탕으로 변경될 수 있다.

진입 기준: 감독은 워킹 그룹이 제출을 위한 일반적인 요구 사항 이행 조건을 만족했을 때 실행을 요청한다.

워킹 그룹은 실행 요청 발표를 하라고 감독에게 요청하는 과정의 일환으로 기술 보고서가 두 개의 독립적이고 상호 운용 가능한 구현 방식을 가지고 있음을 보여주지 않아도 된다. 하지만 워킹 그룹은 요청의 일부로 현재 및 예상되는 구현에 대한 보고서를 포함시켜야 한다.

실행 요청에서, 워킹 그룹은 기술 보고서의 구체적 기능을 "위험에 처한 기능"으로 식별할 수 있다. "우리는 구현되지 않은 모든 기능을 제거할 계획이다" 등과 같은 일반적인 진술서는 받아들여지지 않는다. 따라서 워킹 그룹은 반드시 위험에 처한 모든 기능을 정확하게 식별해야 한다. 따라서 실행 요청에 대한 답변에서, 검토자는 그들이 식별된 기능의 제거에 대해 공식적으로 반대할지 여부를 파악할 수 있다.

실행 경험을 수집한 후, 워킹 그룹은 "위험에 처해 있는" 것으로 파악된 기능을 기술 보고서에서 삭제할 수 있고, 감독이 제안 권장 사항 검토를 요청하도록 요구할 수 있다. 워킹 그룹이 기술 보고서에 다른 실질적 변경을 하는 경우, 감독은 반드시 그것을 워킹 그룹에 되돌려 주어 향후 작업을 하도록 해야 한다.

기술 보고서를 후보 권장 사항으로 제출하도록 감독에게 요청할 때는 반드시 워킹 그룹이 기본 요구 사항 (아래에 설명됨) 이외의 모든 제안 권장 사항 진입 기준을 만족하기를 기대하는지 여부를 표시해야 한다.

자문 위원회 대표는 결정 사항을 상고하여 기술 보고서를 제출할 수 있다.

실행 기간: 발표를 할 때는 반드시 최소 지속 기간을 표시해야 하는데, 이는 워킹 그룹이 제안 권장 사항 검토 요청절대 요청할 수 없기 이전에 이루어 져야 한다. 최소 지속 기간은 의견을 제시할 시간을 허용하도록 정해져 있다. 또한 발표에는 충분한 실행 데이터를 수집하는데 필요한 워킹 그룹의 예상 시간도 포함되어야 한다.

가능한 다음 단계:

7.4.4 제안 권장 사항 검토 요청

문서의 완성도: 제안 권장 사항.

발표: 감독은 반드시 자문 위원회에 검토 요청을 발표해야 한다.

목적: 이 단계에서, W3C는 안정적인 기술 보고서의 보증을 추구하게 된다. 이 검토 작업의 결과는 해당 조직이 기술 보고서에 대한 지지 의사 표명으로 나타난다.

진입 기준: 감독은 워킹 그룹이 다음과 같은 기준을 만족했을 때 검토를 요청한다.

  1. 제출을 위한 일반적인 요구 사항 이행
  2. 기술 보고서에 기술된 각 기능이 구현되었음을 입증. 워킹 그룹은 각 기능의 두 가지 상호 운용 가능한 구현 방식을 입증할 수 있어야 한다. 감독이 즉각적인 자문 위원회의 검토가 기술 보고서의 성공에 결정적이라고 판단되는 경우, 감독은 적절한 실행 경험이 없더라도 제안 권장 사항 검토 요청을 수용할 수 있다.
  3. 발표된 다른 모든 진입 기준 만족 (예: 후보 권장 사항으로 제출하라는 요청서에 포함되거나 워킹 그룹이 실행 요청서를 발행할 의사가 없는 경우에는 최종 요청 시 발표).

자문 위원회 대표는 기술 보고서 제출을 위한 결정을 상고 있다.

검토의 지속 기간: 발표를 함으로써 최소한 4주 이상 지속되어야 하는 검토 기간이 시작된다.

지속적인 작업: 검토 기간 중, 워킹 그룹은 회원으로부터 보증과 지원을 요청한다. (예: 언론 보도의 일환으로서의 증명서)

가능한 다음 단계:

7.4.5 W3C 권장 사항의 출판

문서의 완성도: 권장 사항

발표: 감독은 반드시 자문 위원회에 W3C 권장 사항의 출판을 발표해야 한다.

목적: W3C는 기술 보고서에 나와 있는 아이디어가 널리 보급하기에 적합하고 W3C의 사명 달성을 촉진한다고 믿는 경우, 권장 사항을 출판한다.

진입 기준: 감독은 자문 위원회, 팀, W3C 워킹 그룹 및 일반 대중으로부터 기술 보고서에 대한 상당한 지지를 받은 경우, W3C 권장 사항을 출판한다. 문서를 권장 사항으로 제출하기로 하는 결정은 W3C 결정 사항이다.

회원 검토 중 이의가 있는 경우, 자문 위원회 대표는 권장 사항을 출판한다는 결정을 상고 있다.

가능한 다음 단계:

감독은 또 다른 표준 기구에 W3C 권장 사항을 제출하여 그 기구에 의한 채택과 공식적 승인을 받을 수 있다.

7.4.6 추가 작업을 위해 워킹 그룹으로 문서 반송

기술 보고서는 다음 중 한 가지 상황에 속하는 경우, 향후 작업을 위해 워킹 그룹으로 반환된다.

  1. 워킹 그룹이 최종 요청 발표 이후 및 권장 사항으로 출판 이전에 언제든 기술 보고서에 실질적 변경을 가하는 경우. 단, 그러한 변경이 실행 요청에서 파악된 위험에 처한 기능을 제거하는 것과 관련된 경우는 제외. 실질적 변경의 경우, 워킹 그룹은 반드시 기술 보고서를 작업 초안으로 다시 출판해야 한다.
  2. 감독은 워킹 그룹에 검토 중 제기된 중요한 문제나 실행 경험의 결과로서 이러한 문제를 해결할 것을 요청한다. 이 경우, 감독은 워킹 그룹이 실질적 변경을 하지 않았더라도 기술 보고서를 작업 초안으로 다시 출판할 것으로 요청할 수 있다.

기술 보고서가 향후 작업을 위해 워킹 그룹으로 반환된 경우, 감독은 반드시 자문 위원회와 그룹 의장에게 이를 알려야 한다.

작업 초안으로 다시 출판한 후, 워킹 그룹이 취할 수 있는 다음 진행 단계는 최종 요청 발표이다. 최종 요청 발표는 작업 초안의 발표와 동시에 수 있다.

감독은 워킹 그룹에게 기술 보고서를 후보 권장 사항으로 다시 출판할 것을 요구할 수 있다. 출판과 동시에, 감독은 실행 요청서를 발행한다.

7.5 기술 보고서 작업 완료

기술 보고서에 대한 작업은 언제든 중단될 수 있다. 워킹 그룹이 기술 보고서에 대한 작업을 완료하면, 그것을 권장 사항이나 워킹 그룹 노트로 출판한다. 예를 들어, 워킹 그룹은 요구 사항 문서의 여러 작업 초안을 출판할 수 있고, 그런 다음 워킹 그룹 노트를 출판하여 요구 사항 문서에 대해 작업할 계획이 더 이상 없음을 표시할 수 있다.

또한 W3C가 더 이상 그 작업을 생산적으로 수행할 수 없기 때문에 작업이 중단될 수도 있다. 예를 들어, 감독이 워킹 그룹을 폐쇄하거나, 참가자가 기술 보고서에 대한 관심을 잃거나, 그 아이디어가 다른 기술 보고서에 포함될 수도 있을 것이다. W3C가 완료 전에 기술 보고서에 대한 작업을 중단하기로 결정하는 경우, 그 기술 보고서는 워킹 그룹 노트로 출판되어야 한다.

가능한 다음 단계:

7.6 W3C 권장 사항 변경

W3C는 권장 사항의 유지 (예: 정오표를 추적하고, 테스트 베드 애플리케이션을 제공하고, 테스트 수트 제작을 도움으로써)와 널리 이를 실행하도록 장려하기 위해 모든 노력을 기울인다. 다음 단원에서는 오류의 관리와 권장 사항에 대한 표준적 변경을 하기 위한 프로세스를 논의한다.

7.6.1 정오표 관리

오류 추적은 워킹 그룹이 권장 사항에 대해 지속적으로 관심을 가지는 중요한 부분이고, 이러한 이유로 워킹 그룹 헌장의 범위에는 일반적으로 권장 사항의 출판 이후에 작업할 시간이 허용된다. 이 프로세스 문서에서, "정오표"라는 용어는 단순한 편집상 오류로부터 소프트웨어 또는 컨텐츠 (예: 컨텐츠 확인)에 의한 권장 사항 적합성에 영향을 미칠 수 있는 심각한 오류에 이르기까지, 모든 종류의 실수를 지칭한다. 주: 어떤 문서가 권장 사항이 되기 전, W3C 프로세스는 실질적 변경 (사전 검토에 관련된 것)에 중점을 둔다. 문서가 권장 사항으로 출판된 이후, W3C 프로세스는 컨텐츠 또는 배치된 소프트웨어의 적합성에 영향을 미칠 수 있는 기술 보고서에 대한 변경 사항에 초점을 맞춘다.

워킹 그룹은 반드시 “정오표 페이지” 에서 오류 내용을 추적해야 한다. 정오표 페이지는 교정 사항이 수반될 수 있는, 오류를 열거한 목록이다. 각 권장 사항은 정오표 페이지로 연결된다. 팀의 출판 규칙을 참조한다.

교정은 우선 워킹 그룹에 의해 "제안"된다. 교정 내용은 아래에 설명한 프로세스 중 하나를 통해 표준이 되는데, 이는 출판된 권장 사항에서 텍스트와 동일한 상태이다. 정오표 페이지에는 제안된 교정 내용과 표준 교정 내용이 모두 포함될 수 있다. 워킹 그룹은 반드시 어떤 교정이 제안되고 어떤 것이 기준에 적합한 것인지 명확히 식별해야 한다.

워킹 그룹은 독자와 실행자가 오류를 보고하면 정오표를 최신의 내용으로 유지해야 한다. 워킹 그룹은 반드시 이해 당사자에게 정오표 페이지를 보고해야 하고, 특히 팀의 요구 사항에 따라 교정 사항이 제안되거나 표준이 될 때는 더욱 철저히 보고해야 한다. 예를 들어, 팀은 워킹 그룹이 정오표 페이지에 변경 사항을 보고하는 권장 사항에 대해 메일링 리스트를 설정할 수 있다.

7.6.2 권장 사항에 대한 변경 등급

이 문서에서는 권장 사항에 대한 변경 등급을 다음과 같이 구분한다.

1. 텍스트 컨텐츠에 변경 사항 없음
이 변경 사항에는 절단된 링크나 무효 마크업을 고치는 것이 포함된다.
2. 적합성에 영향을 주지 않는 교정 사항
사양의 기술적 내용을 바꾸지 않는 편집 상의 변경이나 명확화.
3. 적합성에 영향을 줄 수 있지만, 새로운 특징이 추가되지 않는 교정 사항
이들 변경 사항은 권장 사항에 대한 적합성에 영향을 줄 수 있다. 적합성에 영향을 미치는 변화는 다음과 같은 변화이다.
  1. 적합성 데이터, 프로세서 또는 다른 적합한 에이전트를 적합하지 않은 에이전트로 바꾸는 것
  2. 비적합 에이전트를 적합한 것으로 바꾸는 것
  3. 적합성이 불명료했던 에이전트가 분명히 적합하거나 적합하지 않은 것으로 되는 방식으로 사양 중 정확하게 명시되지 않은 부분이나 모호한 부분을 정돈.
4. 새로운 기능
새로운 기능을 위해, W3C는 기술 보고서를 권장 사항으로 제출하는 전체 프로세스에 따른다.

워킹 그룹이 검토 요청서를 발행할 수도 있지만, 처음 두 종류의 변화를 위해서는 제안된 변경 사항의 기술적 검토가 요구되지 않는다. 수정된 권장 사항은 출판 규칙 [PUB31]을 비롯하여, 팀의 요구 사항에 따라 출판된다.

세 번째 종류의 변화의 경우, W3C는 다음 사항을 요구한다.

  1. 제안된 교정 내용의 기술적 확실성을 보장하기 위해 커뮤니티에 의해 검토될 것.
  2. 교정 사항이 적용되어 편집된 권장 사항의 적기 출판.

세 번째 종류의 변화를 위해, 워킹 그룹은 반드시 다음 중 하나를 수행해야 한다.

  1. 감독이 편집된 권장 사항의 검토 요청서를 발행할 것을 요청
  2. 편집된 초안에 들어있지 않은 제안된 교정 내용의 검토 요청서 발행 (예: 정오표 페이지에 나열된 것). 이 검토 작업 후, 감독은 제안된 교정이 표준임을 발표할 수 있다.

두 번째 접근 방식은 워킹 그룹이 표준적 교정을 신속히 할 수 있도록 고안되어 있지만, 변경 사항을 권장 사항의 편집 버전에 적용할 필요성을 미연에 방지해주지는 않는다. 특히, 교정 사항이 매우 많거나 복잡할 때는 이것을 단일 문서로 통합하는 것이 호환성에 중요하다. 그렇지 않으면, 독자들이 교정 내용을 다르게 해석할 수도 있기 때문이다.

7.6.3 편집된 권장 사항의 검토 요청

문서의 완성도: 제안된 편집 권장 사항.

발표: 감독은 반드시 다른 W3C 그룹, 일반 대중 및 자문 위원회에 검토 요청을 발표해야 한다. 발표에서는 반드시 이것이 권장 사항을 편집하기 위한 제안임을 분명히 밝혀야 하고, 반드시 다음 사항을 준수해야 한다.

  1. 검토 의견에 대한 마감 시한을 지정한다.
  2. 알려진 의존 관계를 파악하고 의존 관계에 있는 모든 워킹 그룹의 검토를 요청한다.
  3. 공개 검토를 요청한다.

목적: 이 단계에서, W3C는 제안된 교정을 권장 사항으로 확인하는 길을 모색한다.

진입 기준: 감독은 문서의 변경 사항에 관해 워킹 그룹이 제안 권장 사항 검토 요청에 대한 기준과 같은 진입 기준을 이행한다는 조건이 만족된 경우, 검토를 요청한다 (예: 워킹 그룹은 그러한 변화를 지원하는 실행 경험을 보여줄 수 있음). 이 상태로 진행하기 위한 요청에서, 워킹 그룹은 반드시 해결되지 않은 기술 보고서에 관한 모든 실질적 문제를 보고한다.

자문 위원회 대표는 그 결정을 기술 보고서로 진행하기 위해 상고 있다.

검토의 지속 기간: 발표를 함으로써 반드시 최소한 4주 이상 지속되어야 하는 공식적인 자문 위원회 검토 기간이 시작된다.

지속적인 작업: 검토 기간 중, 워킹 그룹은 팀, 회원, 다른 W3C 그룹 및 일반 대중으로부터 의견을 구하고 질의에 답변한다.

가능한 다음 단계:

7.6.4 제안된 교정 내용의 검토 요청

문서의 완성도: 권장 사항, 제안된 교정 사항의 목록. 워킹 그룹은 각각의 제안된 교정 사항에 대한 권장 사항의 텍스트를 워킹 그룹이 어떻게 변경할 계획인지에 대한 상세 설명도 포함시켜야 한다.

발표: 워킹 그룹은 반드시 다른 W3C 그룹, 일반 대중 및 자문 위원회에 검토 요청서를 발표해야 한다. 이것은 공식적인 자문 위원회 검토는 아니다. 하지만 이 발표는 반드시 이것이 권장 사항에 표준적 교정을 하기 위한 제안이라는 사실을 분명히 밝혀야 하고, 다음 사항을 실행해야 한다.

  1. 검토 의견에 대한 마감 시한 지정
  2. 알려진 의존 관계 파악 및 의존 관계가 있는 모든 워킹 그룹의 검토 요청
  3. 공개 검토 요청.

목적: 이 단계에서, W3C는 권장 사항에 대해 제안된 교정 내용을 확인하는 길을 모색한다.

진입 기준: 워킹 그룹은 문서의 변경 사항에 관해 워킹 그룹이 제안 권장 사항 검토 요청에 대한 기준과 같은 진입 기준을 이행한 경우 검토를 요청한다.

검토의 지속 기간: 발표를 함으로써 최소한 4주 이상 지속되어야 하는 검토 기간이 시작된다.

지속적인 작업: 제안된 편집 권장 사항에 대한 것과 동일하다.

제안된 교정 사항에 대한 공식적인 이의가 없는 경우, W3C는 이것을 표준으로 간주한다. 워킹 그룹은 반드시 공식적 이의를 감독에게 보고해야 하고, 감독은 제안된 교정 사항이 표준이라고 선언하기에 충분한 합의가 이루어 졌는지 평가한다.

가능한 다음 단계:

7.7 W3C 권장 사항의 폐기

예컨대, W3C가 권장 사항의 중대한 오류를 알게 되는 경우, 권장 사항의 내용이 오래된 내용인 경우, 또는 W3C가 실행자에게 영향을 주는 골치 아픈 특허 청구에 직면하는 경우, W3C는 때때로 전체 권장 사항을 폐기할 수도 있다. W3C 특허 정책 [PUB33], 특히 5절 (10번째 항목)과 7.5절을 참조한다.

권장 사항의 일부에 반대하는 경우, W3C는 권장 사항 수정을 위한 프로세스에 따른다.

일단 W3C가 폐기된 권장 사항을 출판하고 나면, 향후의 W3C 기술 보고서는 절대 그 기술 보고서에 대한 표준 참조를 포함하면 안 된다.

7.7.1 권장 사항 폐기 제안

문서의 완성도: 권장 사항에다 폐기 제안에 대한 별도의 논리적 근거.

발표: 감독은 반드시 다른 W3C 그룹, 일반 대중 및 자문 위원회에 권장 사항 폐기 제안을 발표해야 한다. 발표는 반드시 이것이 권장 사항 폐기 제안이라는 점을 분명히 표시해야 하고 반드시 다음 사항을 이행해야 한다.

  1. 검토 의견에 대한 마감 시한 지정
  2. 알려진 의존 관계 파악 및 의존 관계가 있는 모든 워킹 그룹의 검토 요청
  3. 공개 검토 요청.

목적: 이 단계에서, W3C는 권장 사항 폐기 제안을 확인하는 길을 모색한다.

진입 기준: 감독은 충분한 이유가 있어야 한다는 조건을 만족하는 경우, W3C가 권장 사항을 폐기할 것을 제안한다.

자문 위원회 대표는 권장 사항을 폐기하기 위한 제안을 상고 있다.

검토의 지속 기간: 발표를 함으로써 반드시 최소한 4주 이상 지속되어야 하는 검토 기간이 시작된다.

지속적인 작업: 검토 기간 중, 워킹 그룹은 팀, 회원, 다른 W3C 그룹 및 일반 대중의 의견을 요청하고 질의에 답변한다.

가능한 다음 단계:

7.7.2 폐기된 권장 사항의 출판

문서의 완성도: 권장 사항 폐기.

발표: 감독은 반드시 자문 위원회에 폐기된 권장 사항의 출판을 발표해야 한다.

목적: 이 단계에서, W3C는 이전에 출판된 권장 사항을 더 이상 보증하지 않는다는 것을 표시한다.

진입 기준: 감독은 자문 위원회, 팀, W3C 워킹 그룹 및 일반 대중으로부터 상당한 지지가 있어야 하는 조건이 만족된 경우, 폐기된 권장 사항을 출판한다. 문서를 폐기된 권장 사항으로 제출한다는 결정은 W3C 결정 사항이다.

팀은 무엇이 폐기되었는지, 그리고 이전 권장 사항에 대한 관계를 가장 잘 전달하기 위해 하나 이상의 문서를 출판해야 한다. (예: 출판은 이전에 출판된 권장 사항을 참조하는 커버 시트만큼 간단해질 수 있다.)

제안된 폐기 권장 사항 검토에 이의가 있는 경우, 자문 위원회 대표는 권장 사항을 폐기하기 위한 결정을 상고 있다.

가능한 다음 단계:

7.8 기술 보고서에 관한 일반 정보

권장 사항 추적 프로세스의 일부로 출판된 모든 문서는 반드시 공개 문서여야 한다. W3C 기술 보고서의 색인 [PUB11]은 W3C 웹 사이트에 나와 있다. W3C는 원래 형태로 원래 주소에서 언제든 구할 수 있는 보관된 문서를 만들기 위해 모든 노력을 다할 것이다.

권장 사항 추적 프로세스의 일부로 출판된 모든 문서는 반드시 문서의 완성도를 분명히 밝혀야 한다.

권장 사항 추적 프로세스의 일부로 출판된 모든 문서는 워킹 그룹 의장이 지명한 한 명 이상의 편집자에 의해 편집된다. 그룹의 의사 결정이 기술 보고서의 후속 초안에 올바르게 반영되도록 하는 것은 이들 편집자의 책임이다. 해당 그룹에서 선출 또는 임명된 참가자가 아닌 TAG 또는 자문 이사회를 위한 편집자는 반드시 그 그룹에 대해 회원 대표, 팀 대표 또는 초빙 전문가와 동일한 참가 요구 사항을 이행해야 한다. 다른 모든 W3C 편집자는 반드시 자신이 편집하는 문서에 대한 책임이 있는 그룹의 참가자여야 한다. 편집자가 꼭 팀 대표일 필요는 없다는 사실에 주의한다.

팀은 팀의 출판 규칙 (예: 이름 지정, 스타일 및 저작권 요구 사항)을 준수하지 않는 기술 보고서는 출판할 필요가 없다. 이 규칙들은 변경될 수 있다. 팀은 반드시 그룹 의장과 자문 이사회에 모든 변경 사항을 알려야 한다.

팀은 W3C 관행의 변화 (예: 기술 보고서 스타일 또는 문서 상태 단원에 대한 변화)에 따르기 위해 언제든 기술 보고서의 양식을 바꿀 권리를 보유한다.

W3C 기술 보고서에 쓰이는 주요 언어는 영어이다. W3C는 기술 보고서를 번역할 것을 권장한다. W3C 기술 보고서의 번역에 대한 정보 [PUB18]는 W3C 웹 사이트에 설명되어 있다.

7.8.1 문서 상태 단원

각 기술 보고서에는 반드시 문서의 상태에 관한 단원이 포함되어 있어야 한다. 이 상태 단원에서는 W3C가 왜 기술 보고서를 출판했는지, 다음 단계에 대한 기대치는 무엇인지, 누가 기술 보고서를 작성했는지, 보고서에 관한 의견은 어디로 보내야 하는지, 실행 경험이 필요한지, 이전 버전으로부터 어떤 주요한 변화가 있었는지, 기술 보고서에 대한 작업이 중단 또는 포함된 이유는 무엇인지, 기타 모든 관련 정보 또는 논거를 설명해야 한다.

팀의 출판 규칙에는 각각의 완성도에 대한 상태 단원 요구 사항이 포함된다.

8 자문 위원회 검토, 상고 및 투표

이 단원에서는 감독의 제안을 자문 위원회가 검토하는 방식과 자문 위원회 대표가 W3C의 결정 사항과 감독의 결정 사항을 상고하는 방식을 설명한다. W3C 결정 사항은 감독 (또는 감독의 대리인)이 활동 제안서자문 위원회가 검토한 후, 제안 권장 사항 검토 요청 후, 제안 권장 사항 검토 요청 후, W3C 권장 사항 폐기를 위한 제안 후, 그리고 제안된 프로세스 문서 검토 후에 합의를 평가하는 역할을 수행한 결정이다.

8.1 자문 위원회 검토

자문 위원회는 다음 사항을 검토한다.

8.1.1 검토 기간의 시작

각 자문 위원회 검토 기간은 팀이 자문 위원회에 보내는 검토 요청서와 함께 시작된다. 검토 양식은 제안 내용을 설명하고, 마감 시한에 대한 주의를 이끌어내고, 언제 결정이 날 것인지 예상하고, 다른 실용적 정보를 포함한다. 각 회원 조직은 자문 위원회 대표가 반드시 답변해야 하는 한 가지 검토 요청서를 보낼 수 있다.

팀은 반드시 자문 위원회 검토 의견에 대해 다음과 같은 두 가지 채널을 제공한다.

  1. 아카이브된 팀 전용 채널. 이것은 검토를 위한 기본 채널이다.
  2. 아카이브된 회원 전용 채널.

검토자는 한쪽 또는 양쪽 채널로 정보를 보낼 수 있다. 검토자는 자문 위원회 토론 목록에 대해 다른 회원과 검토한 내용을 공유할 수도 있다.

회원 조직은 검토 기간 중에 그 검토 내용을 수정할 수 있다. (예: 다른 회원의 의견을 반영하여).

8.1.2 검토 기간 이후

검토 기간 이후, 감독은 반드시 자문 위원회에 제안에 대한 지지 수준 (합의 또는 이의 제기)을 발표해야 한다. 감독은 반드시 변화하는 기밀성 수준에 대한 관심을 가지고 문서화된 이의 제기가 있는지 여부도 표시해야 한다. 이 W3C 결정은 일반적으로 다음 중 하나이다.

  1. 제안은 사소한 변경 사항이 있을 수도 있는 상태에서 승인된다.
  2. 제안은 실질적 변경 사항이 있을 수도 있는 상태에서 승인된다. 이 경우, 감독의 발표에는 반드시 실질적 변경 사항에 대한 제안에도 불구하고 문서를 제출하는 결정에 대한 논거가 포함되어야 한다.
  3. 제안은 특정 문제를 공식적으로 해결할 것을 촉구하는 요청과 함께 추가 작업을 위해 반환된다.
  4. 제안이 각하된다.

이 문서에서는 자문 위원회 검토 기간이 끝날 때와 W3C 결정 시점 사이의 시간 간격을 정하지 않는다. 이것은 회원과 팀이 검토 중에 수집된 의견들을 고려할 충분한 시간을 가질 수 있도록 해주기 위한 것이다. 자문 위원회는 제안 권장 사항 검토 기간이 끝난 후에 2주 이내에 발표가 될 것으로 기대해서는 안 된다. 만약 3주가 지난 후에도 감독이 결과를 발표하지 않은 경우, 감독은 자문 위원회에 업데이트된 정보를 제공해야 한다.

8.2 자문 위원회 대표에 의한 상고

상고는 특별한 상황에서만 발생할 것으로 예상되긴 해도, 자문 위원회 대표는 어떤 결정에 대해서는 상고할 수 있다.

자문 위원회 검토 결과 어떤 결정을 즉시 우선시하는 경우, 자문 위원회 대표는 이의 표시가 있을 때만 상고할 수 있다. 이러한 결정 사항은 다음과 같다.

자문 위원회 대표는 항상 다음 결정을 상고할 수 있다.

모든 경우에 있어, 상고는 반드시 결정이 난지 3주 이내에 개시되어야 한다.

자문 위원회 대표는 팀에 요청서를 보내어 상고 절차를 개시한다 (신규 회원 오리엔테이션에 세부 사항이 설명되어 있음). 팀은 반드시 자문 위원회에 상고 과정을 발표하고 자문 위원회 대표로부터의 의견을 반영하여 문제를 해결해야 한다. 이러한 구성 요소의 아카이브는 반드시 회원이 볼 수 있어야 한다. 만약 팀의 발표가 있은 후 1주일 이내에 5% 이상의 자문 위원회 구성원이 상고 요청을 지지하는 경우, 팀은 반드시 자문 위원회가 그 결정을 승인할 것인지 또는 각하할 것인지를 묻는 상고 투표를 조직해야 한다.

8.3 자문 위원회 투표

TAG 또는 자문 이사회의 자리에 대한 선거에서, 그리고 W3C 결정의 공식적 상고가 있는 경우, 자문 위원회는 투표를 실시한다. 자문 위원회는 투표할 때마다, 각 회원 또는 관련 회원의 그룹은 한 표씩 가진다. 자문 이사회 및 TAG 선거의 경우, "한 표"란 "한 석에 한 표"를 의미한다.

9 워크숍 및 심포지엄

팀은 워크숍심포지엄을 조직하여 회원과 일반 대중이 W3C 활동 전개에 일찍 개입할 수 있도록 촉진한다.

워크숍의 목표는 보통 어떤 기술이나 정책에 대한 아이디어를 교환하기 위해 전문가와 기타 이해 당사자를 불러 모으거나, W3C 회원이 압박을 받는 문제를 해결하기 위한 것이다. 첫 번째 유형의 워크숍을 조직하는 자는 워크숍 프로그램에 대한 의견서를 요청할 수 있고, 출석자 및/또는 발표자를 선정하기 위해 이러한 의견서를 사용할 수 있다.

심포지엄의 목표는 보통 특정 주제에 대해 이해 당사자를 교육하는 것이다.

워크숍 또는 심포지엄에 대한 참석 요청서에는 참석 요구 사항 또는 제한 사항, 그리고 예상되는 결과를 표시할 수 있다. (예: 보고서 및 의사록). 행사를 주관하는 조직은 특정 주제에 W3C가 추가 투자를 하리라 보장하지는 않지만, 새로운 활동 또는 그룹에 대한 제안으로 유도할 수 있다.

워크숍 및 심포지엄은 일반적으로 1일에서 3일까지 계속된다. 회원이 압박을 느끼는 문제를 해결하기 위해 워크숍이 조직되고 있는 경우, 팀은 반드시 워크숍이 시작되기로 예정된 날짜를 기준으로 6주 이내에 참석 요청서를 발행해야 한다. 다른 워크숍 및 심포지엄의 경우, 팀은 반드시 그 회의가 시작되기로 예정된 날짜를 기준으로 8주 이내에 참석 요청서를 발행해야 한다. 이것은 연설자와 저자가 의견서와 대담 내용을 준비하기에 적당한 시간을 가질 수 있도록 하기 위함이다.

주: 일반적으로, W3C는 컨퍼런스를 조직하지 않는다. 현재, W3C는 국제 월드 와이드 웹 컨퍼런스 위원회 (IW3C2)에 의해 조정되는 연례 월드 와이드 웹 컨퍼런스에서 그 작업 결과를 대중에게 공개한다.

10 연락

W3C는 매우 비공식적인 것 (예: 다른 조직의 개인이 W3C 워킹 그룹에 참가하거나 단순히 그 작업을 따르는 경우)부터 상호 회원 가입, 더 나아가 보다 공식적인 합의에 이르기까지, 수 많은 메커니즘을 통해 다양한 조직과의 활동을 조정하는 것을 연락(liaison)이라는 용어로 표현한다. 주: W3C는 연락의 한 당사자이며, 이 문서의 나머지 부분에서 연락이라는 용어는 상대방을 의미한다.

이 절에서 설명되는 공식 연락 프로세스의 목표는 다음과 같다.

  1. 양측 조직 모두 상호 이익에 관계된 목표 (예: 기술 사양)를 추구할 수 있도록 지원한다.
  2. 상호 의존 관계를 해결할 수 있는 보완 기술의 개발을 촉진한다.
  3. 양측 조직 모두로부터 자원과 원칙적인 측면에서 특정 분야에서의 작업을 추구한다는 사명을 문서화한다.
  4. 연락의 포커스에 관한 의사 소통을 조정한다.
  5. 일정과 달력상 날짜를 일치시킬 수 있도록 한다.
  6. W3C의 특허 정책 [PUB33], W3C 문서 라이센스 [PUB18] 및 기타 IPR 정책과 일관된 방식으로 기술 프로세스가 이루어질 수 있도록 한다.
  7. 시장 분할을 방지한다.
  8. 연락 헌장에 나열된 구체적 이익 (예: 상호 회원 가입)을 제공한다.

사실상, 연락에는 여러 가지 형태가 있으므로 (예: 연락에는 파트너의 프로세스보다 많은 W3C 프로세스가 관련되거나 그 역이 성립됨) 이 프로세스는 최소한으로 제한된다. 이 프로세스는 다음과 같이 구성된다.

  1. 연락처 작성 및 수정
  2. 연락 헌장
  3. 연락 상태 보고서

대중 커뮤니케이션, 특허, 저작권 및 기타 IPR 정책, 기밀 합의, 상호 회원 가입 동의서에 대한 요구 사항으로 인해, 공식적이든, 비공식적이든, 모든 연락은 반드시 팀에 의해 조정되어야 한다.

W3C 감독은 다른 조직과 양해 각서 (MoU)를 협상 및 서명할 있다. 하지만 그렇게 하기 전, 팀은 반드시 상고 있는 자문 위원회에 서명 의사를 발표해야 한다. 양해 각서는 반드시 회원에게 공개되어야 하고 승인 후 일반 대중에 공개되어야 한다.

다른 조직을 포함하여 W3C 연락처 [PUB28] 목록은 웹상에서 이용 가능하다.

10.1 공식 연락처 및 연락처 변경

감독은 자문 위원회에 발표를 하여 공식 연락처를 작성, 수정 또는 확대한다. 이 발표에는 반드시 연락 헌장에 대한 참조가 포함되어야 한다. 자문 위원회 대표는 연락처의 작성, 수정 또는 확대를 상고 있다.

연락처는 W3C 멤버십을 대체하는 의미가 아니다. 공식 연락 프로세스는 유사한 (멤버십) 조직들과의 조정 능력을 개선하는 의미를 지닌다. 어떤 조직이 W3C 작업에 참여하기를 원하는 경우, 그 조직은 W3C에 합류해야 한다.

10.1.1 공식 연락처 작성을 위한 결정 시 고려 사항

W3C가 파트너와 접촉하기로 하겠다는 결정은 궁극적으로는 W3C에 대해 인식된 비용과 이익을 토대로 하는 것이다. 중요 고려 사항은 다음과 같다.

  1. 두 조직 모두 서로에게 공동의 노력에 따라 요구되는 모든 정보를 제공할 것인가?
  2. 두 조직 모두 기술 보고서의 중간 및 최종 버전을 일반 대중에게 확실히 배포할 것인가?
  3. 두 조직 모두 민감한 정보의 기밀성을 존중할 것인가? 그러한 정보를 보호하겠다는 양 당사자의 의지는 신뢰를 구축하고 워킹 그룹이 보다 신속히 작업을 완료할 수 있도록 해준다. 하지만 해당 작업에 관련된 자들은 개방적이고 공개적인 사양의 궁극적 목표에 대한 관점을 버려서는 안 된다.
  4. 두 조직 모두 공동의 노력에 관련된 모든 특허, 저작권 및 기타 IPR 클레임을 공개할 것인가? 파트너가 W3C와 동일한 IPR 정책을 공유하지 않을 경우 어떤 일이 생기는가? 언제 그것이 더욱 엄격해지거나 더욱 느슨해지는가? 발표가 최소 요구 사항인가? 조직은 헌장을 구성하는 일부로서 파트너를 어떤 식으로 언급할 것인가?
  5. 두 조직 모두 공동의 노력에 관련된 모든 공개 진술서와 보도 자료를 조정할 것인가?
  6. 두 조직 모두 호환성을 보장하기 위해 적절하게 문서화된 이정표에서 동료 검토를 장려할 것인가? 검토자가 필요한 것으로 판단하는 변경 사항 협상에 동의하는가? 공개 검토 기간 중에 의견을 요청하고 그 의견에 답변하기로 동의하는가?
  7. 두 조직 모두 합의를 통해 결론에 도달하고 합의가 가능하지 않을 경우에는 이의 사항을 문서화할 것인가?
  8. 두 조직의 회원들은 공동의 노력에 관계된 작업에서 모(母) 조직을 대표하기로 할 것인가?
  9. 어떤 저작권과 배포 정책이 결과물에 적용될 것인가? W3C 문서 라이센스 [PUB18]에 따라 출판이 가능할 것인가? W3C 소프트웨어 공지 및 라이센스 [PUB19]에 따라 소프트웨어가 출시될 것인가?

다른 조직과 연락을 취하지 않는 이유에는 다음이 포함되어 있다.

  1. 다른 조직이 선재하고 있거나 지배적인 회원들에게 이익을 주기 위한 목적으로만 정해진 선택적이거나 임의적인 회원 가입 정책을 가지고 있는가?

10.2 공식 연락관 헌장

각각의 공식 접촉에는 다음 모든 정보를 반드시 포함해야 하는 공개 헌장이 있다.

조직
연락의 목표
프로세스 및 정책
자원
일정

10.3 공식 연락 상태 보고서

최소한 각각의 자문 위원회 회의에서, 팀은 반드시 연락 상태를 기술한 각각의 공식 연락 정보 업데이트, 달성되거나 달성되지 못한 목표, 그리고 만들어지거나 그렇지 못한 결과물을 제시해야 한다. 이 업데이트는 이전 업데이트 이후의 중요한 변경 사항, 성공과 실패를 강조 표시해야 한다. 또한 팀은 연락에 관한 중요한 사건이나 변경 사항을 자문 이사회에 정기적으로 (예: 분기 당 한 번) 통지해야 한다.

11 회원 의뢰 프로세스

회원 의뢰 프로세스를 통해 회원들은 팀이 고려 중인 기술 또는 다른 아이디어를 제안할 수 있다. 검토 후, 팀은 W3C 웹 사이트에 해당 자료를 발표할 수 있다. 회원들은 공식 프로세스를 통해 자신의 기여도를 기록할 수 있고, 프로세스에는 팀과의 업무 상세 내역 (IPR 클레임 포함)을 공개하기 위한 메커니즘이 주어진다. 또한 팀은 W3C 회원, 일반 대중 및 매체를 위해 제출된 자료에 대한 검토 논평도 발표한다.

회원 의뢰 과정은 다음과 같이 구성된다.

한 명 이상의 회원 (“의뢰자”라 부름)은 회원 의뢰 과정에 참여할 수 있다. W3C 회원만이 의뢰자로 등재될 수 있다.

의뢰 과정은 다음과 같은 단계로 이루어진다.

  1. 의뢰자 중 하나가 팀에 의뢰 요청을 승인해달라는 요청서를 보낸다. 팀과 의뢰자는 회원 의뢰가 완료되었는지 확인하는 절차를 거친다.
  2. 팀 검토 후, 감독은 반드시 의뢰 요청에 대해 승인 또는 각하해야 한다.

주:회원 의뢰 프로세스에 관한 혼선을 피하기 위해, 다음 사항에 주의하도록 한다.

W3C가 회원 의뢰서를 출판했다 하여 이것이 W3C 팀 또는 회원을 포함하여, W3C가 보증한다는 의미는 아니다. 의뢰 요청의 승인은 W3C가 어떤 행동을 취하게 될 것이라는 의미는 아니다. 이것은 단순히 의뢰자가 의뢰 요청을 했음을 공개적으로 기록하는 것일 뿐이다. W3C에 의해 발표된 회원 의뢰가 절대로 W3C의 "진행 중인 작업"으로 인용되면 안 된다.

승인된 회원 의뢰서 [PUB10]의 목록은 W3C 웹 사이트에 나와있다.

11.1 의뢰자의 권리와 의무

둘 이상의 회원이 공동으로 의뢰 요청에 참여하는 경우, 한 회원만이 공식적으로 요청서를 보낸다. 그 회원은 반드시 다른 참가 회원의 각 자문 위원회 대표를 대표해야 하고, 그 각각의 자문 위원회 대표는 반드시 의뢰 요청에 그들이 참가했음을 확인해야 한다. (팀에 전자 우편을 보내어 확인).

승인 이전에는 언제든, 어떤 의뢰자든 의뢰 요청에 대한 지지 의사를 철회할 수 있다 ("의뢰 요청서 송부 방법"에 설명되어 있음). 의뢰 요청은 그것을 지지하는 의뢰자가 없으면 "철회" 된다. 팀은 철회된 의뢰 요청에 대해 절대 어떤 진술도 해서는 안 된다.

승인 이전, 의뢰자는 어떤 상황 하에서도, 절대로 어떤 문서를 일반 대중 또는 회원과의 커뮤니케이션에 있어 “월드 와이드 웹 컨소시엄에 의뢰” 또는 “W3C가 고려 중인” 또는 이와 유사한 문구로 언급해서는 안 된다. 의뢰자는 W3C가 회원 의뢰서의 자료에 대해 (의뢰자와 함께) 작업하고 있다는 것을 일반 대중 또는 회원과의 커뮤니케이션에서 절대로 암시해서는 안 된다. 의뢰자는 승인 이전에 (의뢰 요청에 대한 언급 없이) 회원 의뢰서에 그 문서들을 발표할 수 있다.

승인 후, 의뢰자는 해당 자료가 W3C 활동의 일부로 채택될 때까지, 그리고 채택되지 않은 한, 어떤 상황 하에서도 절대로 W3C가 회원 의뢰에 대해 노력을 기울이고 투자하고 있음을 암시해서는 안 된다.

11.1.1 회원 의뢰의 범위

어떤 기술이 공인된 워킹 그룹의 작업 범위에 중첩되는 경우, 회원은 워킹 그룹에 참여하고, 회원 의뢰 프로세스를 통한 출판을 추구하기 보다는 그 기술을 그룹의 프로세스에 기여하도록 해야 한다. 워킹 그룹은 기여 기술을 결과물에 포함시킬 수 있다. 워킹 그룹이 그 기술을 포함시키지 않는 경우, 워킹 그룹 노트는 그룹에 대한 입력 사항이 아니라 출력 사항을 나타내므로 해당 워킹 그룹은 기여 문서를 워킹 그룹 노트로 출판해서는 안 된다.

반면, W3C가 활동 제안서 또는 헌장을 작성하는 초기 단계에 있는 동안, 회원은 의뢰 프로세스를 이용해 새로운 작업에 대한 구체적인 제안서를 놓고 합의를 구축해야 한다.

회원은 W3C의 사명 [PUB15]의 범위를 훨씬 벗어나는 주제를 다룬 자료를 제출하면 안 된다.

11.1.2 의뢰 요청 시 필수 정보

의뢰자와 의뢰된 자료의 다른 모든 저자는 그 요청이 승인되는 경우, 반드시 회원 의뢰서에 있는 문서들이 W3C 문서 라이센스 [PUB18]의 지배를 받게 되고 그에 대한 참조가 포함될 것이라는 점에 동의해야 한다. 의뢰자는 회원 의뢰서의 문서에 대한 저작권을 보유할 수 있다.

요청은 W3C 특허 정책 [PUB33]의 3.3절의 회원 의뢰 라이센스 준수 사항을 만족해야 한다.

의뢰자는 반드시 다음 정보를 포함시켜야 한다.

또한 요청서에는 반드시 다음 질문에 대한 답변도 포함되어야 한다.

의뢰 요청과 관련된 다른 행정적 요건에 대해서는, "의뢰 요청서를 보내는 방법" [MEM8]을 참조한다.

11.2 팀의 권리와 의무

기술 보고서는 아닐지라도, 회원 의뢰서의 문서들은 반드시 팀의 출판 규칙을 포함하여 팀에서 정한 요구 사항을 이행해야 한다.

팀이 의뢰 요청서를 검토하고 그것이 완전하고 타당한 것으로 판정하고 나면, 팀은 의뢰자에게 확인 통지서를 보낸다.

해당 요청에 대해 승인 또는 각하에 대한 결정을 하기 전에는, 그 요청은 팀 전용이고 팀은 반드시 그 내용을 가장 엄격한 수준으로 기밀을 유지해야 한다. 특히 팀은 절대로 해당 의뢰 요청에 대해 매체에 논평하면 안 된다.

11.3 의뢰 요청의 승인

감독은 자문 위원회에 발표 내용을 보내어 의뢰 요청을 승인한다. 발표는 언제든 할 수 있지만, 의뢰자는 확인 통지서를 받은 후 4주 ~ 6주 사이에 발표가 될 것으로 기대할 수 있다. 팀은 반드시 의뢰자에게 발표 예정 시기를 계속 알려주어야 한다.

의뢰 요청이 승인되고 나면, 팀은 반드시 다음 사항을 실행해야 한다.

의뢰자가 승인의 결과로서 발표된 문서를 수정하고자 하는 경우, 의뢰자는 반드시 처음부터 의뢰 프로세스를 시작해야 하며, 이는 단지 편집 상의 오류만 정정하는 경우에도 마찬가지이다.

11.4 의뢰 요청의 각하

감독은 다음 사항을 비롯하여, 여러 가지 다양한 이유로 의뢰 요청을 각하할 수 있다.

각하의 경우, 팀은 반드시 이 사실을 의뢰자의 자문 위원회 대표에게 알려야 한다. 의뢰자가 요청하는 경우, 팀은 반드시 의뢰자에게 각하의 논거를 제시해야 한다. 의뢰자 이외에, 팀은 절대로 의뢰 요청이 각하된 이유에 대해 진술해서는 안 된다.

의뢰자의 자문 위원회 대표는 그 이유가 웹 아키텍처에 관계되어 있는 경우에는 TAG에, 다른 이유로 요청이 각하된 경우에는 자문 이사회에 각하를 상고할 수 있다. 이 경우, 팀은 해당 기구에 각하 결정에 대한 논거를 제시해야 한다. 팀은 적당한 기밀 수준을 보장하는 상고에 대한 절차를 마련한다.

12 프로세스의 진화

W3C 프로세스 문서자문 이사회를 후원하는 워킹 그룹으로 삼아 권장 사항 추적 프로세스의 일부인 문서와 유사한 합의 구축 과정을 거친다.

자문 이사회는 다음과 같이 프로세스 문서에 대한 검토 작업을 시작한다.

  1. 자문 이사회 의장은 자문 위원회와 다른 W3C 그룹에 검토 요청서를 보낸다.
  2. 여러 가지 의견들이 공식 언급되고 필요한 경우에는 문서를 수정한 후, 팀은 제안된 프로세스 문서에 대한 자문 위원회 검토 작업을 시작하여 회원들로부터 보증을 받기 위해 노력한다. 검토 기간은 반드시 최소 4주 이상 지속되어야 한다.
  3. 자문 위원회의 검토 후 합의가 형성된 경우, 팀은 자문 위원회에 W3C 결정 사항을 발표함으로써 새로운 프로세스를 공식적으로 제정한다. 이의 제기가 있는 경우, 자문 위원회 대표는 그 결정 사항을 상고 있다.

또한 W3C는 권장 사항 수정을 위한 프로세스에 따라 프로세스 문서를 수정할 수도 있다.

프로세스 문서의 검토는 공개 검토 사안은 아니다.

13 참고문헌

13.1 공개 자원

다음의 공개 정보는 W3C Web 사이트 에서 찾아볼 수 있다.

[PUB5]
How to Join W3C
[PUB6]
Membership Agreement
[PUB8]
The list of current W3C Members
[PUB9]
The list of W3C Activities
[PUB10]
The list of acknowledged Member Submissions
[PUB11]
The W3C technical reports index
[PUB12]
Public list of Activity Proposals. In this version of the Process Document, there is no public reference to the list of Activity Proposals.
[PUB13]
Submission request overview
[PUB14]
The W3C Team
[PUB15]
About the W3C includes the W3C mission statement some background information about W3C, and additional information about W3C Activities and organization.
[PUB16]
The list of published Team Submissions
[PUB17]
Invited expert and collaborators agreement
[PUB18]
W3C Document License
[PUB19]
W3C Software Notice and License
[PUB20]
Translations of W3C technical reports
[PUB21]
Public W3C mailing lists
[PUB23]
Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities
[PUB25]
Technical Architecture Group (TAG) Charter
[PUB26]
The TAG home page
[PUB27]
Tips for Getting to Recommendation Faster
[PUB28]
W3C liaisons with other organizations
[PUB30]
The Advisory Board home page
[PUB31]
Publication Rules
[PUB32]
W3C Fellows Program
[PUB33]
5 Feb 2004 version of the W3C Patent Policy. The latest version of the W3C Patent Policy is available at http://www.w3.org/Consortium/Patent-Policy/.

13.2 회원 전용 자원

다음의 회원 전용 정보는 W3C Web 사이트에서 찾아볼 수 있다.

[MEM1]
Current Advisory Committee representatives
[MEM2]
Group mailing lists
[MEM3]
The calendar of all scheduled official W3C events
[MEM4]
The New Member Orientation, which includes an introduction to W3C processes from a practical standpoint, including relevant email addresses.
[MEM5]
Advisory Committee meetings
[MEM6]
Member Web site
[MEM8]
How to send a Submission request
[MEM9]
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators
[MEM14]
Guidelines for Disciplinary Action
[MEM15]
How to Organize an Advisory Board or TAG election

13.3 기타 자원

[RFC2119]
"Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997.
[RFC2777]
"Publicly Verifiable Nomcom Random Selection", D. Eastlake 3rd, February 2000.

14 감사의 말

본 문서 작성을 위하여 참여하여 주신 W3C 자문 이사회의 Ann Bassetti (The Boeing Company), Jim Bell (Hewlett-Packard), Carl Cargill (Sun Microsystems), Paul Cotton (Microsoft), Don Deutsch (Oracle), David Fallside (IBM), Paul Grosso (Arbortext), Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ken Laskey (MITRE), Ora Lassila (Nokia), Hokon Wium Lie (Opera Software), Larry Masinter (Adobe Systems), Bede McCall (MITRE), Thomas Reardon (Microsoft), David Singer (IBM), Lauren Wood, and Steve Zilles (Adobe Systems)에 감사드린다. Jean-Francois Abramatic는 자문 이사회 의장이었다.

초기 W3C 프로세스 문서는 프로세스 작업 그룹에서 작성되었다. 이 작업 그룹은 1996년 9월 16일에 자문 이사회에 의하여 선발되었으며, 1997년 11월까지 활동하였다. 이 작업 그룹에 참여하였던 사람은 Carl Cargill (Netscape), Wendy Fong (Hewlett-Packard), John Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson), Thomas Reardon (Microsoft), David Singer (IBM), and Steve Zilles (Adobe) 등이며, 프로세스 작업 그룹에 참여하였던 W3C 팀원은 Jean-Francois Abramatic, Tim Berners-Lee, Ian Jacobs, 그리고 Sally Khudairi 이다.

또한, 연락 프로세스 부분에 대한 작성을 도와준 Don Brutzman(Web3D)에게도 감사한다.