요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Maintainer의 의미와 책임
code-of-conduct-interpretation.rst:26-91이 문서에서 maintainer는 subsystem, driver 또는 file을 책임지고 kernel source의 MAINTAINERS 파일에 등재된 사람이다. Maintainer는 모범을 보여야 하지만 자신이 활동하는 모든 공간에서 다른 사람의 행동을 혼자 처리해야 하는 새 의무가 생기는 것은 아니다. Community 구성원 모두에게 책임이 있으며 unresolved conduct issue의 최종 escalation path가 별도로 있다.
문제가 생기면 maintainer는 다른 maintainer나 Technical Advisory Board에 도움을 요청할 수 있다. 단순 문의는 원하지 않는 한 violation report로 취급되지 않는다. 접근이 어렵다면 conflict mediator에게 연락할 수 있다.
최종 목표는 서로 친절하게 대하고 우호적으로 문제를 해결하는 것이며 formal enforcement는 마지막 수단이다.
기술적으로 복잡한 operating-system kernel을 만들려면 expertise 기준과 decision-making이 필요하다. 요구되는 expertise는 contribution 영역과 기술적 복잡성에 따라 정해진다. 기준과 결정은 토론할 수 있지만 결국 진전을 위해 결정을 내려야 하며 maintainer와 project leadership이 선의로 그 권한을 사용한다.
Expertise 기준을 정하고, 기술적 결정을 내리며, 부적합한 contribution을 거부하는 일 자체는 행동 강령 위반이 아니다. Maintainer가 제한된 시간 때문에 초보자 지원 우선순위를 정하는 것도 위반이 아니다.
Mailing list와 forum의 적용 범위
code-of-conduct-interpretation.rst:93-132MAINTAINERS에 정의된 모든 kernel mailing list의 email은 행동 강령 적용 대상이다. kernel.org Bugzilla와 subsystem bug tracker 사용자도 지침을 따라야 한다.
Kernel community에는 하나의 official project email이나 social-media account가 없다. kernel.org account는 kernel.org 규칙을, corporate account는 해당 회사 규칙을 따른다.
Mailing-list message, kernel changelog와 code comment에 이름·email·관련 comment를 계속 포함하는 것은 금지되지 않는다. 다른 forum은 원칙적으로 그 forum의 규칙을 따르며 극단적 상황에서는 예외를 검토할 수 있다.
새 contribution에는 적절한 언어를 사용한다. 행동 강령 이전의 기존 content를 지금 위반으로 다루지는 않지만 부적절한 표현은 bug로 보고 patch로 고칠 수 있다. User/kernel API 또는 공개 standard·specification의 용어는 bug로 보지 않는다.
Code of Conduct Committee와 TAB
code-of-conduct-interpretation.rst:134-177행동 강령의 신고 주소는 Committee로 전달되며 현재 구성원은 kernel.org의 code-of-conduct 페이지에 공개된다. 구성원은 합류 전이나 떠난 뒤의 report에는 접근할 수 없다.
Committee는 TAB이 임명한 volunteer community member와 neutral third-party professional mediator로 구성된다. Reporter가 전체 Committee에 알리고 싶지 않으면 특정 구성원이나 mediator에게 직접 연락할 수 있다.
Committee는 case를 review하고 필요하면 TAB에 kernel community 정보를 요청한다. Enforcement recommendation은 TAB으로 보내며 투표 참여자 3분의 2가 승인하면 관련 maintainer와 함께 집행한다. Committee와 TAB을 겸하는 구성원은 해당 measure 투표에 참여하지 않는다.
Committee와 TAB은 분기마다 익명화된 report 현황과 TAB 승인 결정, 식별 가능한 voting detail을 요약해 공개한다. 해석과 집행 방식이 발전하면 이 문서도 갱신한다.
허용할 수 없는 행동의 해결 절차
code-of-conduct-interpretation.rst:179-251많은 report는 개발 절차와 maintainer의 역할·결정권을 잘못 이해해 생기며 절차와 적용 범위를 설명해 해결한다. 실제 부적절한 행동은 당사자가 인정하고 발생한 공간에서 피해를 회복하면 해결되는 경우가 많다.
Community discussion으로 해결되지 않으면 Committee가 report를 받아 관련 당사자와 조사하고 생산적이고 존중하는 협업을 복구한다. Report와 reporter 정보는 비공개로 유지하며 injured party뿐 아니라 목격자도 신고할 수 있다.
목표는 모든 당사자가 동의하는 resolution이다. 개인과의 협력이 실패하면 피해 회복을 위한 공개 사과를 요청할 수 있다. Violation이 발생한 공간에서 행동을 공개적으로 지적하고 사과를 요청하며, 사과는 trust를 다시 세우는 첫 단계로 본다.
공개 사과가 없으면 Committee가 TAB에 remedial measure를 권고할 수 있다. 최대 한 번의 전체 kernel development cycle 동안 참여를 금지하고 사과를 해제 조건으로 둘 수 있다.
- Patch contribution과 pull request를 받지 않는다.
- Contribution을 무시하거나 email account를 block해 협업을 일시 중지한다.
- Mailing list와 social-media site 같은 kernel.org platform communication을 제한한다.
TAB 투표 참여자의 3분의 2가 승인한 measure를 Committee가 community, maintainer, sub-maintainer, kernel.org administrator와 집행한다. 공개 사과와 ban이 개인에게 미치는 영향뿐 아니라 심각한 public violation에 조치하지 않을 때 community가 입을 장기 피해도 함께 고려한다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _code_of_conduct_interpretation:
Linux Kernel Contributor Covenant Code of Conduct Interpretation
================================================================
The :ref:`code_of_conduct` is a general document meant to
provide a set of rules for almost any open source community. Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
community will interpret it. We also do not expect this interpretation
to be static over time, and will adjust it as needed.
The Linux kernel development effort is a very personal process compared
to "traditional" ways of developing software. Your contributions and
ideas behind them will be carefully reviewed, often resulting in
critique and criticism. The review will almost always require
improvements before the material can be included in the
kernel. Know that this happens because everyone involved wants to see
the best possible solution for the overall success of Linux. This
development process has been proven to create the most robust operating
system kernel ever, and we do not want to do anything to cause the
quality of submission and eventual result to ever decrease.
Maintainers
-----------
The Code of Conduct uses the term "maintainers" numerous times. In the
kernel community, a "maintainer" is anyone who is responsible for a
subsystem, driver, or file, and is listed in the MAINTAINERS file in the
kernel source tree.
Responsibilities
----------------
The Code of Conduct mentions rights and responsibilities for
maintainers, and this needs some further clarifications.
First and foremost, it is a reasonable expectation to have maintainers
lead by example.
That being said, our community is vast and broad, and there is no new
requirement for maintainers to unilaterally handle how other people
behave in the parts of the community where they are active. That
responsibility is upon all of us, and ultimately the Code of Conduct
documents final escalation paths in case of unresolved concerns
regarding conduct issues.
Maintainers should be willing to help when problems occur, and work with
others in the community when needed. Do not be afraid to reach out to
the Technical Advisory Board (TAB) or other maintainers if you're
uncertain how to handle situations that come up. It will not be
considered a violation report unless you want it to be. If you are
uncertain about approaching the TAB or any other maintainers, please
reach out to our conflict mediator, Joanna Lee <[email protected]>.
In the end, "be kind to each other" is really what the end goal is for
everybody. We know everyone is human and we all fail at times, but the
primary goal for all of us should be to work toward amicable resolutions
of problems. Enforcement of the code of conduct will only be a last
resort option.
Our goal of creating a robust and technically advanced operating system
and the technical complexity involved naturally require expertise and
decision-making.
The required expertise varies depending on the area of contribution. It
is determined mainly by context and technical complexity and only
secondary by the expectations of contributors and maintainers.
Both the expertise expectations and decision-making are subject to
discussion, but at the very end there is a basic necessity to be able to
make decisions in order to make progress. This prerogative is in the
hands of maintainers and project's leadership and is expected to be used
in good faith.
As a consequence, setting expertise expectations, making decisions and
rejecting unsuitable contributions are not viewed as a violation of the
Code of Conduct.
While maintainers are in general welcoming to newcomers, their capacity
of helping contributors overcome the entry hurdles is limited, so they
have to set priorities. This, also, is not to be seen as a violation of
the Code of Conduct. The kernel community is aware of that and provides
entry level programs in various forms like kernelnewbies.org.
Scope
-----
The Linux kernel community primarily interacts on a set of public email
lists distributed around a number of different servers controlled by a
number of different companies or individuals. All of these lists are
defined in the MAINTAINERS file in the kernel source tree. Any emails
sent to those mailing lists are considered covered by the Code of
Conduct.
Developers who use the kernel.org bugzilla, and other subsystem bugzilla
or bug tracking tools should follow the guidelines of the Code of
Conduct. The Linux kernel community does not have an "official" project
email address, or "official" social media address. Any activity
performed using a kernel.org email account must follow the Code of
Conduct as published for kernel.org, just as any individual using a
corporate email account must follow the specific rules of that
corporation.
The Code of Conduct does not prohibit continuing to include names, email
addresses, and associated comments in mailing list messages, kernel
change log messages, or code comments.
Interaction in other forums is covered by whatever rules apply to said
forums and is in general not covered by the Code of Conduct. Exceptions
may be considered for extreme circumstances.
Contributions submitted for the kernel should use appropriate language.
Content that already exists predating the Code of Conduct will not be
addressed now as a violation. Inappropriate language can be seen as a
bug, though; such bugs will be fixed more quickly if any interested
parties submit patches to that effect. Expressions that are currently
part of the user/kernel API, or reflect terminology used in published
standards or specifications, are not considered bugs.
Enforcement
-----------
The address listed in the Code of Conduct goes to the Code of Conduct
Committee. The exact members receiving these emails at any given time
are listed at https://kernel.org/code-of-conduct.html. Members can not
access reports made before they joined or after they have left the
committee.
The Code of Conduct Committee consists of volunteer community members
appointed by the TAB, as well as a professional mediator acting as a
neutral third party. The processes the Code of Conduct committee will
use to address reports is varied and will depend on the individual
circumstance, however, this file serves as documentation for the
general process used.
Any member of the committee, including the mediator, can be contacted
directly if a reporter does not wish to include the full committee in a
complaint or concern.
The Code of Conduct Committee reviews the cases according to the
processes (see above) and consults with the TAB as needed and
appropriate, for instance to request and receive information about the
kernel community.
Any decisions regarding enforcement recommendations will be brought to
the TAB for implementation of enforcement with the relevant maintainers
if needed. Once the TAB approves one or more of the measures outlined
in the scope of the ban by two-thirds of the members voting for the
measures, the Code of Conduct Committee will enforce the TAB approved
measures. Any Code of Conduct Committee members serving on the TAB will
not vote on the measures.
At quarterly intervals, the Code of Conduct Committee and TAB will
provide a report summarizing the anonymised reports that the Code of
Conduct committee has received and their status, as well details of any
TAB approved decisions including complete and identifiable voting details.
Because how we interpret and enforce the Code of Conduct will evolve over
time, this document will be updated when necessary to reflect any
changes.
Enforcement for Unacceptable Behavior Code of Conduct Violations
----------------------------------------------------------------
The Code of Conduct committee works to ensure that our community continues
to be inclusive and fosters diverse discussions and viewpoints, and works
to improve those characteristics over time. A majority of the reports the
Code of Conduct Committee receives stem from incorrect understanding regarding
the development process and maintainers' roles, responsibilities, and their
right to make decisions on code acceptance. These are resolved through
clarification of the development process and the scope of the Code of Conduct.
Unacceptable behaviors could interrupt respectful collaboration for a short
period of time and negatively impact the health of the community longer term.
Unacceptable behaviors often get resolved when individuals acknowledge their
behavior and make amends for it in the setting the violation has taken place.
The Code of Conduct Committee receives reports about unacceptable behaviors
when they don't get resolved through community discussions. The Code of
Conduct committee takes measures to restore productive and respectful
collaboration when an unacceptable behavior has negatively impacted that
relationship.
The Code of Conduct Committee has the obligation to keep the reports and
reporters' information private. Reports could come from injured parties
and community members who are observers of unacceptable behaviors. The
Code of Conduct Committee has the responsibility to investigate and resolve
these reports, working with all involved parties.
The Code of Conduct Committee works with the individual to bring about
change in their understanding of the importance to repair the damage caused
by their behavior to the injured party and the long term negative impact
on the community.
The goal is to reach a resolution which is agreeable to all parties. If
working with the individual fails to bring about the desired outcome, the
Code of Conduct Committee will evaluate other measures such as seeking
public apology to repair the damage.
Seek public apology for the violation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Code of Conduct Committee publicly calls out the behavior in the
setting in which the violation has taken place, seeking public apology
for the violation.
A public apology for the violation is the first step towards rebuilding
the trust. Trust is essential for the continued success and health of the
community which operates on trust and respect.
Remedial measures if there is no public apology for the violation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Code of Conduct Committee determines the next course of action to restore
the healthy collaboration by recommending remedial measure(s) to the TAB for
approval.
- Ban violator from participating in the kernel development process for
a period of up to a full kernel development cycle. The Code of Conduct
Committee could require public apology as a condition for lifting the
ban.
The scope of the ban for a period of time could include:
a. denying patch contributions and pull requests
b. pausing collaboration with the violator by ignoring their
contributions and/or blocking their email account(s)
c. restricting their ability to communicate via kernel.org platforms,
such as mailing lists and social media sites
Once the TAB approves one or more of the measures outlined in the scope of
the ban by two-thirds of the members voting for the measures, the Code of
Conduct Committee will enforce the TAB approved measure(s) in collaboration
with the community, maintainers, sub-maintainers, and kernel.org
administrators. Any Code of Conduct Committee members serving on the TAB
will not vote on the measures.
The Code of Conduct Committee is mindful of the negative impact of seeking
public apology and instituting ban could have on individuals. It is also
mindful of the longer term harm to the community that could result from
not taking action when such serious public violations occur.
The effectiveness of the remedial measure(s) approved by the TAB depends
on the trust and cooperation from the community, maintainers, sub-maintainers,
and kernel.org administrators in enforcing them.
The Code of Conduct Committee sincerely hopes that unacceptable behaviors
that require seeking public apologies continue to be exceedingly rare
occurrences in the future.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Linux kernel community에서 행동 강령을 해석하는 방법
1-22Contributor Covenant 행동 강령은 거의 모든 open source community에 적용할 수 있는 일반적인 규칙을 제공하는 문서다. 그러나 각 community에는 고유한 특성이 있고 Linux kernel도 예외가 아니므로, 이 문서는 kernel community가 행동 강령을 어떻게 해석하는지 설명한다. 이 해석은 영구히 고정된 것이 아니며 필요에 따라 조정된다.
Linux kernel 개발은 전통적인 software 개발 방식과 비교하면 개인의 기여가 매우 직접적으로 드러나는 과정이다. 제출한 변경과 그 배경의 생각은 세심하게 검토되며, 그 과정에서 비평과 비판을 자주 받는다. 대부분의 제출물은 kernel에 포함되기 전에 개선을 요구받는다.
이런 검토가 이루어지는 이유는 참여자 모두가 Linux 전체의 성공을 위한 최선의 해결책을 원하기 때문이다. 이 개발 과정은 매우 견고한 operating system kernel을 만들어 왔으며, community는 제출물과 최종 결과의 품질이 낮아지는 일을 원하지 않는다.
Maintainer의 의미
24-30행동 강령에는 “maintainers”라는 용어가 여러 번 나온다. Kernel community에서 maintainer란 subsystem, driver 또는 file에 대한 책임을 맡고 있으며 kernel source tree의 MAINTAINERS file에 등재된 사람을 뜻한다.
책임, 전문성, 기술적 의사 결정
32-84행동 강령이 maintainer의 권리와 책임을 언급하므로 이를 더 분명히 할 필요가 있다. 무엇보다 maintainer가 행동으로 모범을 보일 것이라고 기대하는 것은 합리적이다.
다만 community의 규모와 활동 범위가 매우 넓기 때문에, maintainer가 자신이 활동하는 영역에서 다른 사람의 행동을 일방적으로 모두 처리해야 한다는 새 의무가 생기는 것은 아니다. 이 책임은 우리 모두에게 있다. 해결되지 않은 행동 문제가 있을 때 사용할 최종 escalation 경로는 행동 강령에 규정되어 있다.
문제가 생기면 maintainer는 기꺼이 돕고 필요할 때 community의 다른 구성원과 협력해야 한다. 상황을 어떻게 처리해야 할지 확신이 없다면 Technical Advisory Board(TAB)나 다른 maintainer에게 연락할 수 있다. 본인이 원하지 않는 한 이러한 문의가 위반 신고로 간주되지는 않는다. TAB 또는 다른 maintainer에게 접근하기 어렵다면 conflict mediator Joanna Lee <[email protected]>에게 연락할 수 있다.
궁극적인 목표는 서로에게 친절하게 대하는 것이다. 누구나 실수할 수 있지만, 모든 사람의 우선 목표는 문제를 우호적으로 해결하기 위해 노력하는 것이어야 한다. 행동 강령의 강제 집행은 최후의 수단으로만 사용한다.
견고하고 기술적으로 발전된 operating system을 만드는 목표와 그 기술적 복잡성에는 자연스럽게 전문성과 의사 결정이 필요하다. 요구되는 전문성은 기여 영역에 따라 다르며, 주로 맥락과 기술적 복잡성이 결정하고 contributor와 maintainer의 기대는 부차적인 요소다.
요구되는 전문성 수준과 의사 결정은 토론의 대상이지만, 프로젝트가 전진하려면 결국 결정을 내릴 수 있어야 한다. 이 권한은 maintainer와 project leadership에 있으며 선의로 행사할 것으로 기대한다.
따라서 전문성 기준을 설정하는 일, 기술적 결정을 내리는 일, 부적절한 기여를 거절하는 일 자체는 행동 강령 위반으로 보지 않는다. Maintainer는 일반적으로 newcomer를 환영하지만 진입 장벽을 넘도록 도울 수 있는 역량은 제한되어 있으므로 우선순위를 정해야 한다. 이 역시 위반으로 보지 않는다. Kernel community는 이 한계를 인식하고 kernelnewbies.org 같은 여러 형태의 입문 프로그램을 제공한다.
적용 범위
86-119Linux kernel community의 상호 작용은 주로 여러 회사나 개인이 운영하는 서로 다른 server의 공개 mailing list에서 이루어진다. 해당 list는 kernel source tree의 MAINTAINERS file에 정의되어 있으며, 그 list로 전송된 모든 email에는 행동 강령이 적용된다.
kernel.org Bugzilla와 subsystem별 Bugzilla 또는 다른 bug tracking tool을 사용하는 개발자도 행동 강령 지침을 따라야 한다. Linux kernel community에는 공식 project email 주소나 공식 social media 주소가 없다. kernel.org email account를 이용한 활동에는 kernel.org에 게시된 행동 강령이 적용되고, 회사 account를 쓰는 개인에게는 해당 회사의 규칙이 적용된다.
행동 강령은 mailing list message, kernel change log message 또는 code comment에 이름, email 주소와 관련 설명을 계속 포함하는 것을 금지하지 않는다.
다른 forum에서의 상호 작용에는 해당 forum의 규칙이 적용되며 일반적으로 Linux kernel 행동 강령의 범위에는 들어가지 않는다. 다만 극단적인 상황에는 예외를 검토할 수 있다.
Kernel에 제출하는 기여물은 적절한 언어를 사용해야 한다. 행동 강령이 생기기 전에 이미 존재하던 content를 지금 위반으로 다루지는 않는다. 부적절한 언어는 bug로 볼 수 있으며, 관심 있는 사람이 이를 수정하는 patch를 제출하면 더 빨리 고칠 수 있다. 현재 user/kernel API의 일부이거나 공개된 standard 또는 specification의 용어를 반영하는 표현은 bug로 보지 않는다.
신고 접수와 집행 절차
121-161행동 강령에 기재된 주소로 보낸 email은 Code of Conduct Committee가 받는다. 특정 시점에 email을 수신하는 정확한 위원 명단은 https://kernel.org/code-of-conduct.html에 게시된다. 위원은 자신이 합류하기 전이나 떠난 뒤에 제출된 신고에는 접근할 수 없다.
위원회는 TAB가 임명한 자원봉사 community 구성원과 중립적인 제3자로 활동하는 전문 mediator로 구성된다. 신고를 처리하는 절차는 개별 상황에 따라 달라지지만 이 문서는 일반적으로 사용하는 과정을 기록한다. 신고자가 전체 위원회에 complaint나 concern을 공개하고 싶지 않다면 mediator를 포함한 위원 개인에게 직접 연락할 수 있다.
위원회는 정해진 절차에 따라 사건을 검토하고 필요하고 적절한 경우 TAB와 협의한다. 예를 들면 kernel community에 관한 정보를 TAB에 요청해 받을 수 있다.
집행 조치의 권고에 관한 결정은 필요할 경우 관련 maintainer와 함께 집행하도록 TAB에 전달된다. TAB 투표 구성원의 3분의 2가 ban 범위에 제시된 하나 이상의 조치를 승인하면 위원회가 그 승인된 조치를 집행한다. TAB에도 참여하는 위원회 구성원은 해당 조치 투표에 참여하지 않는다.
위원회와 TAB는 분기마다 위원회가 접수한 익명화된 신고와 처리 상태, TAB가 승인한 결정, 식별 가능한 전체 투표 세부 사항을 요약한 보고서를 제공한다. 행동 강령의 해석과 집행 방식은 시간에 따라 발전하므로 이 문서도 변화를 반영하도록 필요할 때 갱신된다.
용납할 수 없는 행동에 대한 처리 원칙
163-199위원회는 community가 포용성을 유지하고 다양한 논의와 관점을 장려하며 이러한 특성을 계속 개선하도록 노력한다. 접수되는 신고의 다수는 개발 절차, maintainer의 역할과 책임, code 수용 여부를 결정할 권리에 대한 잘못된 이해에서 비롯된다. 이런 경우 개발 절차와 행동 강령의 적용 범위를 설명하여 해결한다.
용납할 수 없는 행동은 존중을 바탕으로 한 협업을 단기간 방해하고 community의 건강에는 더 오래 부정적인 영향을 줄 수 있다. 당사자가 자신의 행동을 인정하고 위반이 발생한 자리에서 이를 바로잡으면 해결되는 경우가 많다.
Community 내 논의로 해결되지 않을 때 위원회가 신고를 받는다. 그런 행동이 관계에 부정적 영향을 주었다면 위원회는 생산적이고 존중하는 협업을 회복하기 위한 조치를 취한다.
위원회는 신고 내용과 신고자 정보를 비공개로 유지할 의무가 있다. 피해 당사자뿐 아니라 용납할 수 없는 행동을 목격한 community 구성원도 신고할 수 있다. 위원회는 모든 관련 당사자와 함께 신고를 조사하고 해결할 책임이 있다.
위원회는 해당 개인이 자신의 행동이 피해 당사자에게 끼친 손해와 community에 미치는 장기적 악영향을 이해하고 이를 복구해야 하는 중요성을 인식하도록 협력한다. 목표는 모든 당사자가 동의할 수 있는 해결에 도달하는 것이다. 원하는 결과에 이르지 못하면 손해 복구를 위한 공개 사과 요청 같은 다른 조치를 검토한다.
위반에 대한 공개 사과 요청
201-210위원회는 위반이 일어난 환경에서 해당 행동을 공개적으로 지적하고 위반에 대한 공개 사과를 요청한다. 공개 사과는 신뢰를 다시 쌓는 첫 단계다. 신뢰와 존중을 기반으로 운영되는 community의 지속적인 성공과 건강을 위해 신뢰는 필수적이다.
공개 사과가 없을 때의 시정 조치
212-250공개 사과가 이루어지지 않으면 위원회는 건강한 협업을 회복하기 위한 다음 조치를 결정하고 하나 이상의 시정 조치를 TAB에 권고하여 승인을 받는다.
위반자의 kernel 개발 참여를 최대 한 번의 전체 kernel development cycle 동안 금지할 수 있다. 위원회는 ban을 해제하는 조건으로 공개 사과를 요구할 수 있다.
- patch 기여와 pull request 수락 거부
- 기여를 무시하거나 email account를 차단하여 위반자와의 협업 일시 중지
- mailing list와 social media site 등 kernel.org platform을 통한 의사소통 능력 제한
TAB 투표 구성원의 3분의 2가 ban 범위의 하나 이상의 조치를 승인하면 위원회는 community, maintainer, sub-maintainer, kernel.org administrator와 협력하여 승인된 조치를 집행한다. TAB에도 속한 위원회 구성원은 해당 조치에 투표하지 않는다.
위원회는 공개 사과 요청과 ban 도입이 개인에게 끼칠 수 있는 부정적 영향을 유념한다. 동시에 이처럼 심각한 공개 위반이 발생했을 때 아무 조치도 하지 않아 community가 장기적으로 입을 피해도 고려한다.
TAB가 승인한 시정 조치의 효과는 이를 집행하는 community, maintainer, sub-maintainer, kernel.org administrator의 신뢰와 협조에 달려 있다. 위원회는 공개 사과를 요청해야 할 정도의 용납할 수 없는 행동이 앞으로도 극히 드물게 발생하기를 진심으로 바란다.
Linux kernel에 맞춘 해석
code-of-conduct-interpretation.rst:1-24Contributor Covenant는 여러 open-source community에 적용할 일반 규칙이다. 각 community의 작업 방식이 다르므로 이 문서는 Linux kernel에서의 해석을 설명하며, 필요하면 시간이 지나면서 갱신된다.
Kernel 개발은 contribution과 그 배경 idea를 공개적으로 면밀히 review하고 critique하는 개인적인 과정이다. 대부분의 제출물은 merge 전에 개선 요청을 받는다. 이는 개인을 공격하기 위해서가 아니라 Linux 전체의 성공에 가장 좋은 solution과 높은 품질을 얻기 위한 과정이다.