데비안 규범

데비안 프로젝트 규범 (v1.0)

개요

데비안 프로젝트는 자유로운 운영체제를 만들고자 하는 공통적인 대의를 갖는 개개인의 자발적인 참여로 이루어지는 공동체다.

이 문서는 데비안 프로젝트에 있어서 공식적인 의사결정을 위한 전체적인 조직을 기술한다. 여기에는 프로젝트의 목적이나 의사결정 과정에 관계되지 않는 어떠한 정책도 포함하지 않는다.

의사결정단과 개개인들

프로젝트에서 의사 결정은 다음의 내용에 따라서 결정한다:

1. 일반적인 결정이나 선거에 있어서 개발자들;
2. 프로젝트팀장;
3. 기술위원회나 그 회장;
4. 개별 작업을 하는 개개의 개발자;
5. 특정작업을 위해 프로젝트팀장이 지정한 대표자들;
6. 프로젝트 비서단;

이 문서의 나머지 대부분은 이 결정단의 권위와 조직과 약속과 의사결정 단계를 명시한다. 그들의 힘은 다른 사람들이 견제를 할 수 있다; 이러한 경우에 검토를 하는 사람들은 이 부분에 대한 언급을 할 것이다. 위의 목록에서 개개인이나 그룹이 대개는 그들이 무효로 하거나 그들이 정할 수 있는 그룹이나 사람들에 앞서서 기술된다 - 하지만 앞서 목록에 올라온 모든 사람이 목록의 뒤에 있는 사람들의 의견을 무효로 할 수는 없다.

일반적 규칙들

1. 프로젝트를 위해서 일을 하는 누구에게도 강제는 없다. 주어진 작업을 하고 싶지 않는 경우는 하지 않아도 된다. 하지만, 여기의 규범들과 결정된 내용들을 위반하여 작업을 해서는 안된다.
2. 프로젝트 팀장, 프로젝트 비서와 기술고문들이 구별되어야 하는 것과 프로젝트 팀장은 그들 자신을 대표자로 정할 수 없다는 것을 제외하고 개개인은 몇가지 직책을 수행할 수 있다.
3. 개개인은 그들이 수행하는 특정한 직책에서 사임을 하고 프로젝트를 공식적으로 언급하고 떠날 수 있다.

개개의 개발자들

권한

개개의 개발자는

1. 그들의 작업에 대한 어떠한 기술적이나 비기술적인 결정을 할 수 있다;
2. 일반적 결정들에 대한 제안과 지원을 할 수 있다;
3. 선거에서 프로젝트 팀장 후보로서 스스로를 내세울 수 있다;
4. 일반적 결정들과 후보자 선출에 대한 투표권한을 갖고있다;

구성과 할당

1. 개발자들은 그들이 참여하고자 하는 한에서 프로젝트의 목표를 좀더 발전시키기 위한 자원봉사자들이고 프로젝트의 패키지들을 관리하며 프로젝트 팀이 가치 있다고 생각하는 작업을 수행하는 사람들이다.
2. 프로젝트 팀은 새로운 개발자를 선발할 것인지에 관한 것이나 현재의 개발자의 권한을 없애는 것에 대한 결정을 한다. 만일 개발자들이 팀이 개발자들의 권한을 무시한다고 느낀다면 그들은 일반적인 규칙에 따라서 그 결정을 무시할 수 있다 - s.4.1(3), s.4.2를 참조

과정

개발자들은 그들이 적절하다고 생각하는 결정을 내릴 수 있다.

일반적인 결정과 선거에 있어서 개발자들

권한

개발자들은:

1. 프로젝트팀장을 정할 수 있다.
2. 3:1 정도의 비율로 다수가 동의한다면 이 규범을 개정할 수 있다.
3. 프로젝트 팀장과 팀단원이 내린 어떠한 결정도 무효화할 수 있다.
4. 2:1 정도의 비율로 다수가 동의하면 기술위원회에서 결정한 내용을 무효화 할 수 있다.
5. 비기술적인 정책 문서와 언급을 할 수 있다.

프로젝트의 목적을 기술하고 다른 자유 소프트웨어와의 관계와 데비안 소프트웨어가 만족해야 하는 자유소프트웨어 라이센스와 같은 내용을 기술하는 문서를 포함한다. 이 문서들은 그날의 주제에 관한 문구들을 포함할 수 있다.

1. 프로젝트 팀장과 SPI는 함께 데비안과 연관된 확신이 있는 사안에 대해 결정을 해야한다. (s.9.1.을 참조하라)

과정

1. 개발자들은 다음과 같은 표준 의사결정 단계를 따라야한다. 다른 개발자와 적어도 K 명의 다른 개발자들에 의해 보장되거나 프로젝트 팀장이나 기술위원회가 지원을 한다면 의사결정이나 개정을 할 수 있다.
2. 프로젝트 팀장이나 그 팀에 의해서 의사결정이 연기됨
   1. 프로젝트 팀장이나 팀 또는 기술 위원회가 의사결정을 한 경우, 개발자들은 결정을 그냥 넘겨버림으로써 이를 무효화할 수 있다; s4.1(3) 참조
   2. 만일 결정이 적어도 2K 명의 개발자들이 지지하거나 기술위원회에서 제안되었다면, 그 결정은 즉시 나오게 표결에 오르게 된다.
   3. 원래의 결정이 토론 기간이나 투표기간을 변화시키거나 의사결정이 기술위원회의 결정을 무효로 한다면 단지 K 명의 개발자들이 그 결정을 즉시 표결에 올릴 수 있다.
   4. 결정 내용이 표결에 부쳐지면 총투표가 이루어지거나 원래의 결정을 그때까지 연기할지에 대해서 즉각적인 투표가 이루어질 것이다.
   5. 만일 프로젝트 팀이나 팀장이 원래의 결정을 철회하면 투표는 더이상 행해지지 않는다.
3. 투표는 프로젝트 비서에 의해 주재된다. 투표결과들은 투표기간 동안은 볼 수 없다; 투표 후에 프로젝트 비서단이 모든 투표의 결과를 보여준다. 투표기간은 2주이지만 프로젝트 팀장에 의해 1주 정도는 변화를 줄 수 있고 프로젝트 비서에 의해 마칠 수도 있는데 이경우는 투표의 결과가 더이상 의심할 여지가 없는 경우이다.
4. 최소의 토론 기간은 2주이지만 프로젝트 팀장에 의해 1주까지 변경될 수 있다. 프로젝트 팀장은 캐스팅보트(역자주: 의장도 투표권한을 갖는 것)를 할 수있다. 3Q의 정족수이다.
5. 제안과 스폰서와 개정과 투표에 대한 요청과 다른 공식적인 조치는 프로젝트 팀에 선정한 누구나 볼 수 있는 메일링 리스트에서 가능하다 할 수 있다.
6. 투표는 이메일로 비서에게 보내진다. 비서는 각각의 투표에 대해서 그들이 결정을 변경할건지 결정한다.
7. Q는 현재의 개발자 숫자의 이중근호의 1/2이다. K는 Q이거나 5인데 더 작은 값이다. Q와 K는 굳이 정수일 필요도 없고 반올림을 하거나 그럴 필요도 없다.

프로젝트 팀장

권한

1. 팀원들이나 팀원들의 결정을 기술위원회에 할당한다. 팀장은 현재의 책임의 범위나 특정한 결정에 대한 영역을 정하고 이것을 다른 개발자나 기술위원회에 넘긴다. 한번 특정한 결정이 내려지면 팀장은 그 결정을 번복하기가 힘들게 된다; 하지만 특정한 책임 영역에 대한 부분을 철회할 수 있다.
2. 다른 개발자에게 권한 빌려준다. 요청이 되는 경우 프로젝트 팀장은 여러 관점이나 프로젝트의 다른 멤버에 대한 지원을 언급할 수 있다. 그렇지 않는 경우; 팀장이 문제가 되는 결정을 오직 한다면 그 언급은 힘을 갖게 된다.
3. 긴급한 조치가 필요한 어떠한 결정도 내릴 수 있다. 이는 데드라인이 없는 경우 조치가 부족한 경우는 점차로 긴급하게 상황이 바뀌는 결정에 대해서는 적용이 되지 않는다.
4. 어느 누구도 책임지지 않는 어떠한 결정도 내릴 수 있다.
5. 일반적인 결정사항과 개정에 관한 제안서를 제출할 수 있다.
6. 기술위원회와 함께, 새로운 회원을 지목할 수 있다. (s.6.2. 참조)
7. 개발자들이 투표를 할 때 캐스팅 보트를 행사할 수 있다. 프로젝트 팀장은 그러한 상황에서 다른 회원들과 같이 투표권을

행사할 수 있다.

1. 위에서 보았듯이 개발자 투표 동안 토론 기간을 변경할 수 있다.
2. 개발자들 사이에서 토론을 이끌어낸다. 프로젝트 팀장은 개발자들 사이의 토론에 적극 참여해야 하며 도움을 주는 방식으로 긴급하게 해결해야 할 내용에 관한 토론을 이끌어 내어야 한다. 프로젝트 팀장은 그 자신들의 개인적인 관점을 내세우기 위해 그 위치를 이용해서는 안된다.

• SPI와 함께 데비안과 관련된 목적을 위해 연관된 사항들에 영향을 주는 결정들을 한다. (s.9.1.을 참조하라.)

임명

1. 프로젝트 팀장은 개발자가 선출한다.
2. 선출은 팀장의 자리가 비기 9주 전부터 시작하거나 너무 늦은 경우 즉시 시작한다.
3. 그 다음 3주 동안 팀장 후보로 스스로를 추천할 수 있다.
4. 그 후의 3주 동안은 어느 누구도 더이상 후보가 될 수 없다; 후보자들은 이 시간에 자신을 알리는데 주력해야한다. 후보추천

기간에 아무도 후보가 나오지 않으면 후보 추천기간은 3주 더 연장된다.

1. 그 다음 3주는 개발자들이 투표를 하는 기간이다. 팀장 선출 투표는 선거가 끝날 때까지 비밀에 부쳐진다.
2. 투표용지에는 후보 중의 한 사람을 선택해도 되고 그냥 무효표로 해도된다. 어느 누구도 선거에서 이기지 못하면 그 투표는 계속하게 된다.
3. 결정은 Concorde Vote Counting 방법을 사용한다. 정족수는 일반적 결정(s.4.2)과 동일하고 기본 옵션은 위의 것 중 어느 것도 해당하지 않는다.
4. 프로젝트 팀장의 임기는 1년이다.

과정

프로젝트 팀장은 개발자의 의견일치와 같은 결정을 내려야한다.

비공식적으로 팀장은 개발자들의 의견을 모을 수 있다.

프로젝트 팀장은 그들 자신의 의견을 강조하는 것을 자제해야한다.

기술위원회

권한

1. 기술적인 정책에 관한 내용을 결정한다. 이는 기술적인 정책 설명서의 내용과 개발자의 참조 문서와 예제

패키지들과 안정된 패키지 개발 상황에 대한 내용을 포함하고 있다. (각각의 경우 관련 소프트웨어의 관리자나 문서의 관리자는 처음부터 결정한다; 6.3(5) 참조)

1. 개발자들 간의 의견불일치 문제에 관한 내용에 대한 기술적인 문제를 결정할 수 있다. 개발자들이 예를 들어 충돌하는 패키지의 우선성에 관해 의견이 일치하지 않거나 명령어의 소유권, 버그가 보고된 경우 어떤 패키지가 그 버그에 해당하는지, 누가 그 패키지의 관리자인지에 관한 기술적인 정책을 정할 수 있다.
2. 어떠한 요청이 있을 때 결정을 내릴 수 있다. 어떠한 사람도 기술위원회에 의견을 개진할 수 있고 거기에서 조언을 구할 수 있다.
3. 3:1의 다수가 결정한 일이라면 한 명의 개발자를 제외할 수 있다. 기술위원회는 개발자에게 부탁하여 그 개발자가 원하지 않는다 하더라도 3:1의 다수가 결정하면 기술적인 조치를 취해줄 것을 요구할 수 있다. 예를 들어, 기술위원회는 버그를 보고한 사람이 제기한 언급이 정당한지와 버그 보고자의 해결방법이 구현가능한지를 판단한다.
4. 조언을 줄 수 있다. 기술위원회는 어떠한 문제에 대해서도 그 관점에 관해 공식적인 언급할 수 있다. 개개의 구성원들도 물론 그들의 관점과 위원회와 비슷한 관점을 공식적으로 언급할 수 있다.
5. 프로젝트 팀장과 함께 새로운 구성원을 정할 수 있고 기존의 구성원을 바꿀 수 있다. (s.6.2.를 참조.)
6. 기술위원회장을 정할 수 있다. 기술위원회장은 기술위원회의 구성원들이 선출한다. 위원회의 모든 구성원들은 자동적으로 후보가 된다; 포스팅 일주일 전에 위원회의 투표는 아무 의미가 없다. 자기 자신을 포함해서 다른 동료 구성원에 대해 공적인 선언을 통해서 투표할 수 있다; 위의 선택사항 중에 없는 것은 없다. 투표는 모든 구성원이 투표하거나 결과물이 더이상 의심할 필요가 없을 때까지 투표할 수 있다. 그 결과는 Concorde Vote Counting 원칙에 따라서 결정된다.
7. 위원회장은 팀장으로 비서와 함께 나설 수 있다. s.7.1(2)에서처럼, 기술위원회장과 프로젝트 비서는 팀장이 없는 경우 팀장으로서의 역할을 할 수 있다.

구성

• 기술위원회는 8명 내의 개발자로 구성되며 최소한 4명 이상은 되어야한다.
• 8명 이하의 구성원인 경우, 새로운 구성원을 팀장에게 추천할 수 있는데 팀장은 새로운 구성원을 지목하거나 안할 수 있다.
• 5명 정도의 멤버의 경우 6명이 될 때까지 새로운 구성원을 지목할 수 있다.
• 적어도 한 주 동안 5명 내의 구성원밖에 못 만드는 경우 한 사람을 새롭게 지목할 구성원에 한 주씩 할당해서 팀장이 새롭게 지목할 수 있다.
• 기술위원회와 팀장은 기술위원회의 기존의 구성원을 교체하거나 할때 동의를 해야한다.

과정

1. 기술위원회는 표준 결정 과정을 따른다. 초안에 대한 결정이나 개정은 기술위원회의 구성원 중에 아무나 제안할 수 있다. 최소한의 토론 기간은 없다; 투표기간은 한 주 동안 지속되거나, 결과가 확실할 때까지 지속된다. 구성원들은 그들의 투표내용을 변경할 수 있다. 2명의 정족수가 있다.
2. 투표에 관한 세부사항들 의장은 캐스팅 보트를 할 수 있다. 기술위원회가 기술위원회의 구성원이 될지나 구성원이 의장이 아니라면 투표할 수 있는지 투표한다.
3. 토론과 의사결정 토론, 초안 결정과 개정, 위원회 구성원들의 투표들은 기술위원회의 토론 리스트에서 이루어진다. 기술위원회를 위한 다른 것은 없다.
4. 구성원 지정의 신뢰성 기술위원회는 개인적인 메일이나 메일링 리스트, 위원회의 구성에 대한 지정을 위한 토론을 신뢰성 있게 해야한다. 하지만 구성원 지정은 반드시 공적으로 이루어져야 한다.
5. 세부의 기획작업 필요없음. 기술위원회는 새로운 제안과 정책에 관여하지 않는다. 그러한 기획작업은 개인에 의해서는 안되고 반드시 공식적인 기술 정책에 따라 이루어져야 한다. 기술위원회는 해결책과 위에서 제안된 결정들을 잘 참고하여 충분한 토론을 거친 후에 적절한 선택을 해야 한다. 기술위원회의 개개인들은 모든 기획과 정책 작업에 참여해야 한다.
6. 기술 위원회는 마지막으로 결정을 한다. 기술위원회는 의견조율이 계속 해서 이루어지는 동안은 기술적인 결정을 하지 않고 그 결정에 책임이 있는 개인이나 단체가 결정을 할 수 있는지 기다려야 한다.

프로젝트 비서

권한

비서는:

1. 요청이 있을 때마다, 개발자들과 같이 투표할 수 있고 개발자의 숫자와 신분을 확인한다.
2. 기술위원회의장과 팀장으로 나설 수 있다. 만일 프로젝트 팀장이 없다면 기술위원회와 프로젝트 비서는 긴급한 작업이 있는 경우 같이 결정을 내릴 수 있다.
3. 데비안 규범의 해석에 따른 어떠한 분쟁도 중재한다.
4. 그 누구에게도 권한의 일부와 전부를 줄 수 있고 어떠한 때라도 다시 그 권한을 가져올 수 있다.

임명

프로젝트 비서는 프로젝트 팀장과 현재의 비서가 임명한다.

프로젝트 팀장과 현재의 비서가 새로운 비서 임명에 동의하지 않으면 SPI 위원회에 그 비서를 임명할지 안할지를 결정한다.

프로젝트 비서와 현재의 비서가 없고 권한 부여가 되어 있지 않으면 기술위원회의장이 비서로서 의사를 결정하고 권한을 부여받게 된다.

프로젝트의 비서 임기는 1년이고 다시 그때는 다른 사람을 임명해야 한다.

과정

비서는 정당하고 논리적인 결정을 해야 하며 개발자들의 의견과 일치해야 한다.

팀장을 대신해서 하는 경우 기술위원회의장과 비서는 정말 필요하고 개발자들과 의견이 일치하는 경우 그 결정을 내려야 한다.

프로젝트 팀

권한

프로젝트 팀:

• 은 프로젝트 팀장이 그들에게 권한을 줄 수 있다;
• 개발자를 새로 정하거나 쫓아내거나 패키지를 관리하지 않는 사람을 개발자로서 정하는 것을 포함해서 팀장이 직접적으로 결정할 수 없는 것들을 결정할 수 있다. 이는 권력이 팀장에게 모두 집중되는 것을 막는다.

임명

프로젝트 팀은 프로젝트 팀장에 의해서 임명되고 교체될 수 있다. 프로젝트 팀장은 팀에 의해 결정되는 특별한 결정에 중요한 자리를 잡거나 팀에 의해 한번 결정된 내용을 무효화할 수 없다.

과정

팀은 그들이 적합하다고 생각하는 부분을 결정하지만 좋은 기술적인 결정과 일치된 의견을 따라야한다.

공통의 관심사로서의 소프트웨어(Software in the Public Interest)

SPI와 데비안은 공통적인 목적을 공유하는 분리된 조직이다. 다행히, 데비안은 SPI에 의해 제공되는 법적인 지원을 받고 있다. 데비안의 개발자들은 현재 그들의 개발자로서의 지위로서 SPI의 구성원이 된다.

권한

1. SPI는 데비안의 기술적이거나 기술적이 아닌 부분들의 결정에 관해서는 권한이 없는데 단지 SPI가 갖고 있는 재산권에 대해서

데비안이 결정하는 어떤 결정도 SPI로 하여금 외부의 법적인 조치를 취하게 할 수 없고 데비안의 규범은 SPI를 마지막 결정의 수단으로 사용할 수 있다.

1. 데비안의 개발자들이 SPI와 SPI의 규법들 내에서 권한이 주어지지만 데비안은 SPI의 특정한 권리를 넘거나 SPI를 넘어서는 권한은 선언하지 않는다.
2. 데비안 개발자들은 SPI의 요원이나 고용인도 아니고 각각은 데비안 프로젝트에서 개인의 권한을 갖고 있다. 개발자로서 개개인은 자신을 대변할 수 있다.

데비안과 관련된 자산 관리

데비안은 돈이나 자산을 관리할 권한이 없기 때문에 데비안 프로젝트에 기부되는 돈은 그러한 작업을 담당하는 SPI가 담당한다.

SPI는 다음과 같은 작업을 수행한다:

1. SPI는 돈과 상표와 다른 유,무형의 자산을 관리하고 데비안과 관련된 다른 사항들을 관리한다.
2. 이러한 자산은 이분에 나온 내용에 따라서 데비안과 SPI가 결정하여 관리된다.
3. SPI는 데비안의 인증 없이 자산을 마음대로 처리할 수 없고 이는 프로젝트 팀장이나 개발자들의 일반적인 동의 없이는 할 수 없다.
4. 프로젝트 팀장이 요청이 있는 경우 자산의 처리와 사용에 관해서 고려를 할 것이다.
5. SPI는 SPI의 법적인 권한과 상응하는 경우 개발자들의 요청이 있는 경우 자산을 처리하거나 사용할 수 있다.
6. 데비안에 필요한 자산을 사용하거나 처리할 때 SPI는 데비안 메일링 리스트로 메일을 보내어 알려줄 것이다.

A. 표준 결정 과정

이 규칙은 위원회와 투표단이 결정하는 의견에 적용되는 것이다.

제안

초안이 제안되고 지지를 받을 때 정식 과정은 시작된다.

토론과 수정

1. 초안을 따라서 그에 대한 결정이 논의에 부쳐진다. 새로운 결정에 대한 요구사항에 따라서 제안되고 지지를 받음에 따라서 개정작업이 이루어지거나 아니면 원래의 결정을 내린 제안자가 직접 개정할 수 있다.
2. 공식적인 수정은 초안이 맞게 수정된 상황에서 받아들여질 것이다.
3. 제안이 받아들여지지 않거나 그 결정의 지지자들이 제안자의 공식적인 개정에 동의하지 않으면 개정은 투표에 부쳐질 것이다.
4. 원래의 제안자가 받아들인 개정이 다른 사람들의 동의가 없는 경우 그전의 변경사항과 반대되는 개정을 제안할 수 있다. (다시 이는 제안자와 지지자들의 요구사항을 맞추어야 한다.)
5. 제안자나 결정은 개정의 단어들의 쓰임에 관한 제안을 할 수 있다; 개정의 제안자가 동의를 하고 지지자가 반대를 하지 않으면 이것은 효력을 발휘할 것이고 이 경우 변형된 개정은 원래의 것 대신에 다시 투표에 부쳐질 것이다.
6. 제안자는 작은 에러를 수정하거나(예를 들면 오타나 비일관성) 의미를 바꾸지 않는 변화들에 대한 수정을 24시간 내로 제안하고 작업한다. 이 경우 최소의 토론 기간은 재시작되지 않는다.

투표요청

• 개정에 관한 제안자나 지지자는 일정 토론 기간이 지나면 투표를 요청할 수 있다.
• 제안자나 지지자는 개인적으로나 함께 개정에 관한 내용이나 그 어떤것에 대해서도 투표를 요청할 수 있다; 이들은 그 개정과 그 와 관련된 내용에 대해서만 제안할 수 있다.
• 투표를 요청한 사람은 내용이 어떤 것인지 언급을 하고 투표가 어떤 형태로 진행되는지 언급해야 한다. 하지만, 투표에 관한 최종 결정은 비서의 작업이다 - 7.1(1), 7.1(3), A.3(6)을 참조.
• 최소의 토론 기간은 마지막 개정이나 개정이 투표되고 마지막 공식적인 개정이 받아들여질 때부터이거나 어떠한 개정이 제안되지도 않고 받아들여지지도 않았을 때 모든 결정이 제안된 때부터이다.

투표과정

1. 연관된 개정된 내용 각각을 각각 분리하여 투표할 수 있다. 각각의 투표는 모든 개정과 선택사항을 포함하고 있다. 만일 계속적인 논의가 잘되면 모든 결정과정은 토론과정의 초기로 돌아간다. 개정에는 특별하게 정족수가 필요하지 않다.
2. 결정의 최종형태가 결정될 때, 이는 최종투표로 넘어가며 여기에 나오는 선택은 예, 아니오와 토론이 있다. 지속적인 토론이 우세하면 모든 과정은 초기로 돌아가게 된다.
3. 단일 투표메세지를 이용하는 경우에도 한 명의 투표자든 여러명이든간에 동시에 올라온 투표들에 대해 정리할 수 있다. 만일 개정 투표와 마지막 투표가 이러한 식으로 묶어지면 투표자는 반드시 최종의 개정안의 가능한 모든 형태에 관해 다르게 투표가 가능하다.
4. 투표는 투표기간만 가능하다. 투표결과가 확실하다면 투표기간은 끝나고 투표자들의 의견을 고칠 가능성은 없다.
5. Concorde Vote Counting 원칙에 따라서 투표자들 숫자를 센다. 만일 정족수가 필요하면 기본 선택사항에 대한 논의가 더 이루어진다.
6. 뭔가 이상한 경우에 프로젝트 비서는 과정에 대한 문제를 결정할 것이다 (예를 들어, 특정한 개정이 의존성이 있는지 없는지에 관해)

결정이나 받아들여지지 않는 개정 취소하기

개정이나 받아들여지지 않는 개정의 제안자는 그것을 취소할 수 있다. 이 경우 새로운 제안자들은 계속해서 그 제안을 이끌어 나갈 수 있고 처음 이것을 한 사람은 첫번째 제안자가 되고 다른 사람들은 지지자가 이미 없는 경우 지지자가 되는 것이다.

지지자 또한 취소할 수 있다.

만일 제안자와 지지자들의 취소가 결정이 더이상의 지지가가 없고 충분한 지지자가 없다는 의미라면 결정이 만기가 되기전에 수정되지 않으면 투표는 하지 않게 된다.

만기

제안된 결정을 토론하지 않고, 개정되지 않고 투표가 된 상황이 않거나 4주 동안 그대로 있다면 취소된 것으로 여겨진다.

Concorde Vote Counting

1. 이는 여러 명의 후보가 있는 경우 한명을 선택하는 데 이용된다. 각 투표용지는 투표자가 원하는 사람이 선호하는 것으로 순서를 매길 수 있다. 순서가 완전할 필요는 없다.
2. 만일 엄격하게 A보다 B를 좋아하는 것보다 B보다 A를 좋아하는 경우가 많다면 A가 B에 비해 우세하다고 할 수 있다.
3. 투표의 우세가 확실시되는 경우 다른 것들은 의미가 없어지게 된다.
4. 별다른 이변이 없는 한 가장 많이 득표한 사람이 최종 승리자가 된다.
5. 한 명 이상의 후보가 남이 있는 경우 투표는 남아 있는 선택에서 결정해야할 것이다: 각각의 선택에 대한 첫번째 참조의 숫자를 세고 반 개라도 숫자가 앞서는 것이 승리자가 된다. 그렇지 않은 경우 가장 적은 수의 첫 번째 숫자는 무시하고 두 번째 참조의 숫자에 따라서 결정한다. 이러한 과정이 반복되고 계속해서 두 번째, 세 번째.. 이렇게 나가게 된다. 결국 이는 첫번째 참조의 수가 반 개 이상이 될 때까지 계속된다.
6. 동점인 경우 캐스팅 보트의 권한이 있는 사람이 결정한다. 캐스팅 보트는 보통의 투표권과는 다르다. 이 사람의 경우는 결국 투표를 두 번 하게 되는 것이다.
7. 과반수가 필요한 경우, 최종 투표에서 "예"라고 대답한 숫자는 적당한 숫자로 줄인다. 엄격히 말하면 F:A의 경우 X를 선호하는 것에 "예"를 한 숫자나 첫번째 참조를 "예"한 숫자 (승리자와 그 이외의 사람을 제거하는 과정을 비교할 때)는 비교를 하기 전에 A/F의 숫자만큼 곱한다. 2:1의 투표가 있다면 이는 두배 정도 많은 사람이 투표를 했다는 의미가 된다. 기권표는 포함되지 않는다.
8. 정족수가 필요하면 승리자를 선택한 많은 투표에 대한 것이 적어도 필요하다. 없다면 기본 옵션이 결국 승리하게 된다. 과반수를 원하는 경우 실제로 "예"를 대답한 사람은 정족수에 도달했는지 안 했는지 확인할 때 사용된다.

표준 결정 과정이 쓰일 때 충분하게 무엇이 초안 결정을 정해주는지 알려주는 것과 최소의 토론 기간, 투표기간을 알려주는 것이 필요하다. 이는 또한 과반수와 정족수도 정해주어야 한다.

언어의 사용과 오타

현재를 알려주는 동사 같은 것은 그 문구가 이 규범의 규칙이라는 것이다. 일거 같다'와 일 수 있다'는 개인이나 단체의 결정이다. `Should'는 문구를 지키게 되는 경우 좋다는 것이지만 강제는 아니다. 인용구의 경우 이 규범의 일부가 아니다. 이는 설명을 좀더 쉽게 해주는데 사용한다.