데비안 규범

데비안 프로젝트 규범 (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년이고 다시 그때는 다른 사람을 임명해야 한다.