편집
715
번
바뀜
둘러보기로 가기
검색하러 가기
편집 요약 없음
전체적인 조직을 기술한다. 여기에는 프로젝트의 목적이나 의사결정
과정에 관계되지 않는 어떠한 정책도 포함하지 않는다.
== 의사결정단과 개개인들 ==
=== 과정 ===
개발자들은 그들이 적절하다고 생각하는 결정을 내릴 수 있다.
== 일반적인 결정과 선거에 있어서 개발자들 ==
# 데비안 규범의 해석에 따른 어떠한 분쟁도 중재한다.
# 그 누구에게도 권한의 일부와 전부를 줄 수 있고 어떠한 때라도 다시 그 권한을 가져올 수 있다.
=== 임명 ===
=== 과정 ===
비서는 정당하고 논리적인 결정을 해야 하며 개발자들의 의견과 일치해야 한다.
팀장을 대신해서 하는 경우 기술위원회의장과 비서는 정말 필요하고 개발자들과 의견이 일치하는 경우 그 결정을 내려야 한다.
== 프로젝트 팀 ==
=== 권한 ===
프로젝트 팀:
* 은 프로젝트 팀장이 그들에게 권한을 줄 수 있다;
* 개발자를 새로 정하거나 쫓아내거나 패키지를 관리하지 않는 사람을 개발자로서 정하는 것을 포함해서 팀장이 직접적으로 결정할 수 없는 것들을 결정할 수 있다. 이는 권력이 팀장에게 모두 집중되는 것을 막는다.
=== 임명 ===
프로젝트 팀은 프로젝트 팀장에 의해서 임명되고 교체될 수 있다.
프로젝트 팀장은 팀에 의해 결정되는 특별한 결정에 중요한 자리를 잡거나 팀에 의해 한번 결정된 내용을 무효화할 수 없다.
=== 과정 ===
팀은 그들이 적합하다고 생각하는 부분을 결정하지만 좋은 기술적인 결정과 일치된 의견을 따라야한다.
== 공통의 관심사로서의 소프트웨어(Software in the Public Interest) ==
SPI와 데비안은 공통적인 목적을 공유하는 분리된 조직이다. 다행히, 데비안은 SPI에 의해 제공되는 법적인 지원을 받고 있다.
데비안의 개발자들은 현재 그들의 개발자로서의 지위로서 SPI의 구성원이 된다.
=== 권한 ===
# SPI는 데비안의 기술적이거나 기술적이 아닌 부분들의 결정에 관해서는 권한이 없는데 단지 SPI가 갖고 있는 재산권에 대해서
데비안이 결정하는 어떤 결정도 SPI로 하여금 외부의 법적인 조치를 취하게 할 수 없고 데비안의 규범은 SPI를 마지막 결정의
수단으로 사용할 수 있다.
# 데비안의 개발자들이 SPI와 SPI의 규법들 내에서 권한이 주어지지만 데비안은 SPI의 특정한 권리를 넘거나 SPI를 넘어서는 권한은 선언하지 않는다.
# 데비안 개발자들은 SPI의 요원이나 고용인도 아니고 각각은 데비안 프로젝트에서 개인의 권한을 갖고 있다. 개발자로서 개개인은 자신을 대변할 수 있다.
=== 데비안과 관련된 자산 관리 ===
데비안은 돈이나 자산을 관리할 권한이 없기 때문에 데비안 프로젝트에 기부되는 돈은 그러한 작업을 담당하는 SPI가 담당한다.
SPI는 다음과 같은 작업을 수행한다:
# SPI는 돈과 상표와 다른 유,무형의 자산을 관리하고 데비안과 관련된 다른 사항들을 관리한다.
# 이러한 자산은 이분에 나온 내용에 따라서 데비안과 SPI가 결정하여 관리된다.
# SPI는 데비안의 인증 없이 자산을 마음대로 처리할 수 없고 이는 프로젝트 팀장이나 개발자들의 일반적인 동의 없이는 할 수 없다.
# 프로젝트 팀장이 요청이 있는 경우 자산의 처리와 사용에 관해서 고려를 할 것이다.
# SPI는 SPI의 법적인 권한과 상응하는 경우 개발자들의 요청이 있는 경우 자산을 처리하거나 사용할 수 있다.
# 데비안에 필요한 자산을 사용하거나 처리할 때 SPI는 데비안 메일링 리스트로 메일을 보내어 알려줄 것이다.
== A. 표준 결정 과정 ==
이 규칙은 위원회와 투표단이 결정하는 의견에 적용되는 것이다.
=== 제안 ===
초안이 제안되고 지지를 받을 때 정식 과정은 시작된다.
=== 토론과 수정 ===
# 초안을 따라서 그에 대한 결정이 논의에 부쳐진다. 새로운 결정에 대한 요구사항에 따라서 제안되고 지지를 받음에 따라서 개정작업이 이루어지거나 아니면 원래의 결정을 내린 제안자가 직접 개정할 수 있다.
# 공식적인 수정은 초안이 맞게 수정된 상황에서 받아들여질 것이다.
# 제안이 받아들여지지 않거나 그 결정의 지지자들이 제안자의 공식적인 개정에 동의하지 않으면 개정은 투표에 부쳐질 것이다.
# 원래의 제안자가 받아들인 개정이 다른 사람들의 동의가 없는 경우 그전의 변경사항과 반대되는 개정을 제안할 수 있다. (다시 이는 제안자와 지지자들의 요구사항을 맞추어야 한다.)
# 제안자나 결정은 개정의 단어들의 쓰임에 관한 제안을 할 수 있다; 개정의 제안자가 동의를 하고 지지자가 반대를 하지 않으면 이것은 효력을 발휘할 것이고 이 경우 변형된 개정은 원래의 것 대신에 다시 투표에 부쳐질 것이다.
# 제안자는 작은 에러를 수정하거나(예를 들면 오타나 비일관성) 의미를 바꾸지 않는 변화들에 대한 수정을 24시간 내로 제안하고 작업한다. 이 경우 최소의 토론 기간은 재시작되지 않는다.
=== 투표요청 ===
* 개정에 관한 제안자나 지지자는 일정 토론 기간이 지나면 투표를 요청할 수 있다.
* 제안자나 지지자는 개인적으로나 함께 개정에 관한 내용이나 그 어떤것에 대해서도 투표를 요청할 수 있다; 이들은 그 개정과 그 와 관련된 내용에 대해서만 제안할 수 있다.
* 투표를 요청한 사람은 내용이 어떤 것인지 언급을 하고 투표가 어떤 형태로 진행되는지 언급해야 한다. 하지만, 투표에 관한 최종 결정은 비서의 작업이다 - 7.1(1), 7.1(3), A.3(6)을 참조.
* 최소의 토론 기간은 마지막 개정이나 개정이 투표되고 마지막 공식적인 개정이 받아들여질 때부터이거나 어떠한 개정이 제안되지도 않고 받아들여지지도 않았을 때 모든 결정이 제안된 때부터이다.
=== 투표과정 ===
# 연관된 개정된 내용 각각을 각각 분리하여 투표할 수 있다. 각각의 투표는 모든 개정과 선택사항을 포함하고 있다. 만일 계속적인 논의가 잘되면 모든 결정과정은 토론과정의 초기로 돌아간다. 개정에는 특별하게 정족수가 필요하지 않다.
# 결정의 최종형태가 결정될 때, 이는 최종투표로 넘어가며 여기에 나오는 선택은 예, 아니오와 토론이 있다. 지속적인 토론이 우세하면 모든 과정은 초기로 돌아가게 된다.
# 단일 투표메세지를 이용하는 경우에도 한 명의 투표자든 여러명이든간에 동시에 올라온 투표들에 대해 정리할 수 있다. 만일 개정 투표와 마지막 투표가 이러한 식으로 묶어지면 투표자는 반드시 최종의 개정안의 가능한 모든 형태에 관해 다르게 투표가 가능하다.
# 투표는 투표기간만 가능하다. 투표결과가 확실하다면 투표기간은 끝나고 투표자들의 의견을 고칠 가능성은 없다.
# Concorde Vote Counting 원칙에 따라서 투표자들 숫자를 센다. 만일 정족수가 필요하면 기본 선택사항에 대한 논의가 더 이루어진다.
# 뭔가 이상한 경우에 프로젝트 비서는 과정에 대한 문제를 결정할 것이다 (예를 들어, 특정한 개정이 의존성이 있는지 없는지에 관해)
=== 결정이나 받아들여지지 않는 개정 취소하기 ===
개정이나 받아들여지지 않는 개정의 제안자는 그것을 취소할 수 있다.
이 경우 새로운 제안자들은 계속해서 그 제안을 이끌어 나갈 수 있고 처음 이것을 한 사람은 첫번째 제안자가 되고 다른 사람들은 지지자가 이미 없는 경우 지지자가 되는 것이다.
지지자 또한 취소할 수 있다.
만일 제안자와 지지자들의 취소가 결정이 더이상의 지지가가 없고 충분한 지지자가 없다는 의미라면 결정이 만기가 되기전에 수정되지 않으면 투표는 하지 않게 된다.
=== 만기 ===
제안된 결정을 토론하지 않고, 개정되지 않고 투표가 된 상황이 않거나 4주 동안 그대로 있다면 취소된 것으로 여겨진다.
=== Concorde Vote Counting ===
# 이는 여러 명의 후보가 있는 경우 한명을 선택하는 데 이용된다. 각 투표용지는 투표자가 원하는 사람이 선호하는 것으로 순서를 매길 수 있다. 순서가 완전할 필요는 없다.
# 만일 엄격하게 A보다 B를 좋아하는 것보다 B보다 A를 좋아하는 경우가 많다면 A가 B에 비해 우세하다고 할 수 있다.
# 투표의 우세가 확실시되는 경우 다른 것들은 의미가 없어지게 된다.
# 별다른 이변이 없는 한 가장 많이 득표한 사람이 최종 승리자가 된다.
# 한 명 이상의 후보가 남이 있는 경우 투표는 남아 있는 선택에서 결정해야할 것이다: 각각의 선택에 대한 첫번째 참조의 숫자를 세고 반 개라도 숫자가 앞서는 것이 승리자가 된다. 그렇지 않은 경우 가장 적은 수의 첫 번째 숫자는 무시하고 두 번째 참조의 숫자에 따라서 결정한다. 이러한 과정이 반복되고 계속해서 두 번째, 세 번째.. 이렇게 나가게 된다. 결국 이는 첫번째 참조의 수가 반 개 이상이 될 때까지 계속된다.
# 동점인 경우 캐스팅 보트의 권한이 있는 사람이 결정한다. 캐스팅 보트는 보통의 투표권과는 다르다. 이 사람의 경우는 결국 투표를 두 번 하게 되는 것이다.
# 과반수가 필요한 경우, 최종 투표에서 "예"라고 대답한 숫자는 적당한 숫자로 줄인다. 엄격히 말하면 F:A의 경우 X를 선호하는 것에 "예"를 한 숫자나 첫번째 참조를 "예"한 숫자 (승리자와 그 이외의 사람을 제거하는 과정을 비교할 때)는 비교를 하기 전에 A/F의 숫자만큼 곱한다. 2:1의 투표가 있다면 이는 두배 정도 많은 사람이 투표를 했다는 의미가 된다. 기권표는 포함되지 않는다.
# 정족수가 필요하면 승리자를 선택한 많은 투표에 대한 것이 적어도 필요하다. 없다면 기본 옵션이 결국 승리하게 된다. 과반수를 원하는 경우 실제로 "예"를 대답한 사람은 정족수에 도달했는지 안 했는지 확인할 때 사용된다.
표준 결정 과정이 쓰일 때 충분하게 무엇이 초안 결정을 정해주는지 알려주는 것과 최소의 토론 기간, 투표기간을 알려주는 것이 필요하다.
이는 또한 과반수와 정족수도 정해주어야 한다.
== 언어의 사용과 오타 ==
현재를 알려주는 동사 같은 것은 그 문구가 이 규범의 규칙이라는 것이다. 일거 같다'와 일 수 있다'는 개인이나 단체의 결정이다. `Should'는 문구를 지키게 되는 경우 좋다는 것이지만 강제는 아니다. 인용구의 경우 이 규범의 일부가 아니다. 이는 설명을 좀더 쉽게 해주는데 사용한다.
