Skip to content

Commit f46bad7

Browse files
outsiderisoutsideris
committed
translate about menu as Korean
1 parent e047830 commit f46bad7

8 files changed

+1451
-9
lines changed

‎locale/ko/about/governance.md

+247
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,247 @@
1+
---
2+
title: 프로젝트 거버넌스
3+
layout: about.hbs
4+
---
5+
# 프로젝트 거버넌스
6+
7+
## 기술 결정 위원회(TSC, Technical Steering Committee)
8+
9+
<!--
10+
The project is jointly governed by a Technical Steering Committee (TSC)
11+
which is responsible for high-level guidance of the project.
12+
13+
The TSC has final authority over this project including:
14+
15+
* Technical direction
16+
* Project governance and process (including this policy)
17+
* Contribution policy
18+
* GitHub repository hosting
19+
* Conduct guidelines
20+
* Maintaining the list of additional Collaborators
21+
-->
22+
프로젝트의 고수준 지침에 대한 책임이 있는 기술 결정 위원회(TSC)가 함께 프로젝트를 운영하고 있습니다.
23+
24+
TSC는 다음을 포함해서 이 프로젝트의 최종 권한을 가집니다.
25+
26+
* 기술적 방향
27+
* 프로젝트 거버넌스와 절차 (이 정책을 포함해서)
28+
* 기여 정책
29+
* GitHub 저장소 호스팅
30+
* 행동 지침
31+
* 추가적인 협업자 목록의 관리
32+
33+
<!--
34+
Initial membership invitations to the TSC were given to individuals who
35+
had been active contributors, and who have significant
36+
experience with the management of the project. Membership is
37+
expected to evolve over time according to the needs of the project.
38+
39+
For the current list of TSC members, see the project
40+
[README.md](https://github.com/nodejs/node/blob/master/README.md#tsc-technical-steering-committee).
41+
-->
42+
최초의 TSC 멤버십 초대는 활발한 기여자나 프로젝트 관리에 충분한 경험을 가진 사람들에게 주어졌습니다.
43+
멤버십은 프로젝트의 요구사항에 따라 발전될 것입니다.
44+
45+
현재 TSC 회원 목록은 프로젝트
46+
[README.md](https://github.com/nodejs/node/blob/master/README.md#tsc-technical-steering-committee)에서
47+
볼 수 있습니다.
48+
49+
<!--
50+
## Collaborators
51+
52+
The [nodejs/node](https://github.com/nodejs/node) GitHub repository is
53+
maintained by the TSC and additional Collaborators who are added by the
54+
TSC on an ongoing basis.
55+
56+
Individuals making significant and valuable contributions are made
57+
Collaborators and given commit-access to the project. These
58+
individuals are identified by the TSC and their addition as
59+
Collaborators is discussed during the weekly TSC meeting.
60+
-->
61+
## 협업자
62+
63+
TSC와 TSC가 지속적으로 추가한 협업자들이
64+
[nodejs/node](https://github.com/nodejs/node) GitHub 저장소를 관리하고 있습니다.
65+
66+
중요하고 가치 있는 기여를 하는 개인이 협업자가 되고 프로젝트의 커밋-접근 권한을 받습니다. 이러한 개인은
67+
TSC가 인정하고 주간 TSC 회의에서 협업자로 추가하는 것을 논의합니다.
68+
69+
<!--
70+
_Note:_ If you make a significant contribution and are not considered
71+
for commit-access, log an issue or contact a TSC member directly and it
72+
will be brought up in the next TSC meeting.
73+
74+
Modifications of the contents of the nodejs/node repository are made on
75+
a collaborative basis. Anybody with a GitHub account may propose a
76+
modification via pull request and it will be considered by the project
77+
Collaborators. All pull requests must be reviewed and accepted by a
78+
Collaborator with sufficient expertise who is able to take full
79+
responsibility for the change. In the case of pull requests proposed
80+
by an existing Collaborator, an additional Collaborator is required
81+
for sign-off. Consensus should be sought if additional Collaborators
82+
participate and there is disagreement around a particular
83+
modification. See _Consensus Seeking Process_ below for further detail
84+
on the consensus model used for governance.
85+
-->
86+
_Note:_ 중요한 기여를 했음에도 커밋 접근 권한을 얻지 못한다면 이슈를 남기거나 TSC 멤버에게
87+
직접 연락을 취하면 다음 TSC 회의 때 다루게 될 것입니다.
88+
89+
nodejs/node 저장소 내용의 수정은 협업을 통해서 이뤄집니다. GitHub 계정을 가진 누구나 풀 리퀘스트로
90+
수정을 제안할 수 있고 프로젝트 협업자가 이를 검토할 것입니다. 모든 풀 리퀘스트는 반드시 리뷰를
91+
받아야 하고 변경사항에 대한 전체 책임을 지고 상당한 전문성을 가진 협업자가 이를 받아들일 것입니다.
92+
기존의 협업자가 제안한 풀 리퀘스트는 다른 협업자가 승인해야 합니다. 다른 협업자가 관여해서
93+
특정 수정 부분에 대해서 동의하지 않는다면 합의가 이루어져야 합니다. 거버넌스의 합의 모델에 관한
94+
더 자세한 내용은 아래의 _합의점을 찾는 과정_을 보기 바랍니다.
95+
96+
<!--
97+
Collaborators may opt to elevate significant or controversial
98+
modifications, or modifications that have not found consensus to the
99+
TSC for discussion by assigning the ***tsc-agenda*** tag to a pull
100+
request or issue. The TSC should serve as the final arbiter where
101+
required.
102+
103+
For the current list of Collaborators, see the project
104+
[README.md](https://github.com/nodejs/node/blob/master/README.md#current-project-team-members).
105+
106+
A guide for Collaborators is maintained in
107+
[COLLABORATOR_GUIDE.md](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md).
108+
-->
109+
협업자는 TSC에서 논의하려고 풀 리퀘스트나 이슈에 ***tsc-agenda*** 태그를 할당함으로써 중요하거나
110+
논쟁이 되는 수정사항이나 합의점을 찾지 못한 수정사항을 개선하려고 할 수도 있습니다.
111+
TSC는 필요한 경우 최종 중재자가 되어야 합니다.
112+
113+
현재 협업자 목록은 프로젝트
114+
[README.md](https://github.com/nodejs/node/blob/master/README.md#current-project-team-members)에서
115+
볼 수 있습니다.
116+
117+
협업자 가이드는
118+
[COLLABORATOR_GUIDE.md](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md)에서
119+
관리되어 있습니다.
120+
121+
<!--
122+
## TSC Membership
123+
124+
TSC seats are not time-limited. There is no fixed size of the TSC.
125+
However, the expected target is between 6 and 12, to ensure adequate
126+
coverage of important areas of expertise, balanced with the ability to
127+
make decisions efficiently.
128+
129+
There is no specific set of requirements or qualifications for TSC
130+
membership beyond these rules.
131+
132+
The TSC may add additional members to the TSC by a standard TSC motion.
133+
-->
134+
## TSC 멤버십
135+
136+
TSC 멤버십은 기간 제한이 없고 TSC에 인원 제한도 없습니다. 하지만, 전문성과 균형을 가진 채
137+
효율적인 결정을 하면서 중요한 영역을 충분히 다룰 수 있도록 6 ~ 12명 정도가 적당하다고 생각합니다.
138+
139+
이 규칙을 뛰어넘는 TSC 멤버십의 요구사항이나 자격에 대한 특정 조건은 없습니다.
140+
141+
TSC는 표준 TSC 발의를 통해 새로운 회원을 TSC에 추가할 것입니다.
142+
143+
<!--
144+
A TSC member may be removed from the TSC by voluntary resignation, or by
145+
a standard TSC motion.
146+
147+
Changes to TSC membership should be posted in the agenda, and may be
148+
suggested as any other agenda item (see "TSC Meetings" below).
149+
150+
No more than 1/3 of the TSC members may be affiliated with the same
151+
employer. If removal or resignation of a TSC member, or a change of
152+
employment by a TSC member, creates a situation where more than 1/3 of
153+
the TSC membership shares an employer, then the situation must be
154+
immediately remedied by the resignation or removal of one or more TSC
155+
members affiliated with the over-represented employer(s).
156+
-->
157+
TSC 회원은 자발적인 사퇴나 표준 TSC 발의를 통해 TSC에서 제외될 수 있습니다.
158+
159+
TSC 멤버십의 변경은 의제에 올라와야 하고 다른 의제로 제안될 수도 있습니다.(아래 "TSC 회의"를 보세요.)
160+
161+
TSC 회원의 1/3 이상이 같은 고용주와 관련되면 안 됩니다. TSC 회원이 제외되거나 사퇴하거나 TSC 회원의
162+
고용상태가 바뀔 때 TSC 멤버십의 1/3 이상이 같은 고용주를 갖게 되는 상황이 만들어질 수 있습니다.
163+
이 상황은 같은 고용주를 가진 1명 이상의 TSC 멤버가 사퇴하거나 제외됨으로써 즉시 해결되어야 합니다.
164+
165+
<!--
166+
## TSC Meetings
167+
168+
The TSC meets weekly on a Google Hangout On Air. The meeting is run by
169+
a designated moderator approved by the TSC. Each meeting should be
170+
published to YouTube.
171+
172+
Items are added to the TSC agenda which are considered contentious or
173+
are modifications of governance, contribution policy, TSC membership,
174+
or release process.
175+
176+
The intention of the agenda is not to approve or review all patches.
177+
That should happen continuously on GitHub and be handled by the larger
178+
group of Collaborators.
179+
-->
180+
## TSC 회의
181+
182+
TSC는 구글 행아웃으로 매주 만납니다. TSC가 승인해서 선정한 중재자가 회의를 주최합니다.
183+
각 회의는 YouTube로 발행되어야 합니다.
184+
185+
논쟁이 필요하거나 거버넌스, 기여 정책, TSC 멤버십, 릴리스 절차의 수정에 대한 주제가
186+
TSC 의제에 추가됩니다.
187+
188+
이 의제의 의도는 모든 패치를 승인하거나 리뷰하는 것이 아닙니다. 이러한 승인이라 리뷰는
189+
GitHub에서 계속해서 이루어지고 더 큰 협업자 그룹에서 다뤄집니다.
190+
191+
<!--
192+
Any community member or contributor can ask that something be added to
193+
the next meeting's agenda by logging a GitHub Issue. Any Collaborator,
194+
TSC member or the moderator can add the item to the agenda by adding
195+
the ***tsc-agenda*** tag to the issue.
196+
197+
Prior to each TSC meeting, the moderator will share the Agenda with
198+
members of the TSC. TSC members can add any items they like to the
199+
agenda at the beginning of each meeting. The moderator and the TSC
200+
cannot veto or remove items.
201+
-->
202+
어떤 커뮤니티 회원이나 기여자도 GitHub에 이슈를 남김으로써 다음 미팅 일정에 무언가를 추가하도록
203+
요청할 수 있습니다. 어떤 협업자, TSC 회원, 중재자라도 이슈에 ***tsc-agenda*** 태그를
204+
추가해서 의제를 추가할 수 있습니다.
205+
206+
각 TSC 회의 전에 중재자는 TSC 회원과 의제를 공유할 것입니다. TSC 회원은 각 회의를 시작할 때
207+
원하는 의제를 추가할 수 있습니다. 중재자와 TSC는 의제를 거부하거나 제거할 수 없습니다.
208+
209+
<!--
210+
The TSC may invite persons or representatives from certain projects to
211+
participate in a non-voting capacity. These invitees currently are:
212+
213+
* A representative from [build](https://github.com/node-forward/build)
214+
chosen by that project.
215+
216+
The moderator is responsible for summarizing the discussion of each
217+
agenda item and sending it as a pull request after the meeting.
218+
-->
219+
TSC는 특정 프로젝트의 사람들이나 대표자가 투표권 없이 회의에 참여하도록 초대할 수 있습니다. 현재 이렇게 초대된 사람은 다음과 같습니다.
220+
221+
* [build](https://github.com/node-forward/build) 프로젝트에서 선택된 대표자
222+
223+
중재자는 각 의제를 논의한 내용을 요약하고 미팅 후에 풀 리퀘스트로 보낼 책임이 있습니다.
224+
225+
<!--
226+
## Consensus Seeking Process
227+
228+
The TSC follows a
229+
[Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
230+
decision making model.
231+
232+
When an agenda item has appeared to reach a consensus, the moderator
233+
will ask "Does anyone object?" as a final call for dissent from the
234+
consensus.
235+
236+
If an agenda item cannot reach a consensus, a TSC member can call for
237+
either a closing vote or a vote to table the issue to the next
238+
meeting. The call for a vote must be approved by a majority of the TSC
239+
or else the discussion will continue. Simple majority wins.
240+
-->
241+
## 합의점을 찾는 과정
242+
243+
TSC는 [합의점 찾기](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 의사결정 모델을 따릅니다.
244+
245+
의제가 합의점을 찾았을 때 중재자는 합의점에 대한 반대의견을 받기 위한 마지막 요청으로 "반대하는 사람 있습니까?"라고 물을 것입니다.
246+
247+
의제가 합의점에 이르지 못한다면 TSC 멤버는 투표를 종료하거나 다음 회의에 이슈를 올리도록 하는 투표를 요청할 수 있습니다. 투표요청은 반드시 TSC의 과반수가 동의해야 하고 그렇지 않으면 논의를 계속할 것입니다. 간단히 과반수가 이깁니다.

‎locale/ko/about/index.md

+115
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,115 @@
1+
---
2+
layout: about.hbs
3+
title: About
4+
trademark: 트레이드마크
5+
---
6+
# Node.js&reg;에 대해서
7+
8+
<!--
9+
As an asynchronous event driven JavaScript runtime, Node is designed to build
10+
scalable network applications. In the following "hello world" example, many
11+
connections can be handled concurrently. Upon each connection the callback is
12+
fired, but if there is no work to be done Node is sleeping.
13+
-->
14+
15+
비동기 이벤트 주도 JavaScript 런타임으로써 Node는 확장성 있는 네트워크 애플리케이션을 만들 수 있도록
16+
설계되었습니다. 다음 "hello world" 예제는 다수의 연결을 동시에 처리할 수 있습니다.
17+
각 연결에서 콜백이 실행되는데 실행할 작업이 없다면 Node는 대기합니다.
18+
19+
```javascript
20+
const http = require('http');
21+
22+
const hostname = '127.0.0.1';
23+
const port = 3000;
24+
25+
const server = http.createServer((req, res) => {
26+
res.statusCode = 200;
27+
res.setHeader('Content-Type', 'text/plain');
28+
res.end('Hello World\n');
29+
});
30+
31+
server.listen(port, hostname, () => {
32+
console.log(`Server running at http://${hostname}:${port}/`);
33+
});
34+
```
35+
36+
<!--
37+
This is in contrast to today's more common concurrency model where OS threads
38+
are employed. Thread-based networking is relatively inefficient and very
39+
difficult to use. Furthermore, users of Node are free from worries of
40+
dead-locking the process, since there are no locks. Almost no function in Node
41+
directly performs I/O, so the process never blocks. Because nothing blocks,
42+
scalable systems are very reasonable to develop in Node.
43+
-->
44+
이는 오늘날 OS 스레드가 일반적으로 사용하는 동시성 모델과는 대조적입니다. 스레드 기반의 네트워크는
45+
상대적으로 비효율적이고 사용하기가 몹시 어렵습니다. 게다가 잠금이 없으므로 Node의 사용자는 프로세스의
46+
교착상태에 대해서 걱정할 필요가 없습니다. Node에서 I/O를 직접 수행하는 함수는 거의 없으므로 프로세스는
47+
결과 블로킹 되지 않습니다. 아무것도 블로킹 되지 않으므로 Node에서는 확장성 있는 시스템을 개발하는 게
48+
아주 자연스럽습니다.
49+
50+
<!--
51+
If some of this language is unfamiliar, there is a full article on
52+
[Blocking vs Non-Blocking][].
53+
54+
---
55+
-->
56+
여기서 나오는 용어가 익숙하지 않다면 [블로킹 대 논-블로킹][]에 대한 글을 읽어보세요.
57+
58+
---
59+
60+
<!--
61+
Node is similar in design to, and influenced by, systems like Ruby's
62+
[Event Machine][] or Python's [Twisted][]. Node takes the event model a bit
63+
further, it presents an [event loop][] as a runtime construct instead of as a library. In other systems there is always a blocking call to start the
64+
event-loop.
65+
Typically behavior is defined through callbacks at the beginning of a script
66+
and at the end starts a server through a blocking call like
67+
`EventMachine::run()`. In Node there is no such start-the-event-loop call. Node
68+
simply enters the event loop after executing the input script. Node exits the
69+
event loop when there are no more callbacks to perform. This behavior is like
70+
browser JavaScript — the event loop is hidden from the user.
71+
-->
72+
Node는 Ruby의 [Event Machine][]이나 Python의 [Twisted][]같은 시스템과 설계상 유사하고
73+
영향을 받았습니다. Node는 좀 더 발전된 이벤트 모델을 선택해서 라이브러리가 아닌 런타임 생성자로
74+
[event loop][]를 제공합니다. 다른 시스템에서는 이벤트 루프를 시작하는 블럭킹 호출이 항상 존재합니다.
75+
76+
보통은 스크립트의 시작 부분에서 콜백을 통해서 동작을 정의하고 마지막에서 `EventMachine::run()`같은
77+
블로킹 호출로 서버를 시작합니다. Node에서는 이와 같은 이벤트 루프를 시작하는 호출이 없습니다. Node는
78+
입력 스크립트를 실행한 후에 이벤트 루프에 바로 진입합니다. 더이상 실행할 콜백이 없다면 Node는
79+
이벤트 루프를 종료합니다. 이 동작은 브라우저 JavaScript과 같이 사용자에게서 이벤트 루프를 감춥니다.
80+
81+
<!--
82+
HTTP is a first class citizen in Node, designed with streaming and low latency
83+
in mind. This makes Node well suited for the foundation of a web library or
84+
framework.
85+
86+
Just because Node is designed without threads, doesn't mean you cannot take
87+
advantage of multiple cores in your environment. Child processes can be spawned
88+
by using our [`child_process.fork()`][] API, and are designed to be easy to
89+
communicate with. Built upon that same interface is the [`cluster`][] module,
90+
which allows you to share sockets between processes to enable load balancing
91+
over your cores.
92+
-->
93+
Node에서 HTTP는 일급 시민(first class citizen)이고 스트리밍과 저지연은 염두에 두고
94+
설계되었습니다. 이는 Node가 웹 라이브러리나 프레임워크의 기반으로 아주 적합하게 하였습니다.
95+
96+
Node는 스레드를 사용하지 않도록 설계되지만 멀티 코어 환경의 장점을 얻지 못한다는 의미는 아닙니다.
97+
[`child_process.fork()`][] API를 사용해서 자식 프로세스를 생성할 수 있습니다. 같은 인터페이스로
98+
만들어진 [`cluster`][]을 사용하면 다수의 코어에 로드 밸런싱이 가능하도록 프로세스 간에
99+
소켓을 공유할 수 있습니다.
100+
101+
<!--
102+
[Blocking vs Non-Blocking]: https://github.com/nodejs/node/blob/master/doc/topics/blocking-vs-non-blocking.md
103+
[`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
104+
[`cluster`]: https://nodejs.org/api/cluster.html
105+
[event loop]: https://github.com/nodejs/node/blob/master/doc/topics/the-event-loop-timers-and-nexttick.md
106+
[Event Machine]: http://rubyeventmachine.com/
107+
[Twisted]: http://twistedmatrix.com/
108+
-->
109+
110+
[Blocking vs Non-Blocking]: https://github.com/nodejs/node/blob/master/doc/topics/blocking-vs-non-blocking.md
111+
[`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
112+
[`cluster`]: https://nodejs.org/api/cluster.html
113+
[event loop]: https://github.com/nodejs/node/blob/master/doc/topics/the-event-loop-timers-and-nexttick.md
114+
[Event Machine]: http://rubyeventmachine.com/
115+
[Twisted]: http://twistedmatrix.com/

0 commit comments

Comments
 (0)