Skip to content

Commit

Permalink
Translate For local\zh-CN\about (#1721)
Browse files Browse the repository at this point in the history
  • Loading branch information
Maledong authored and fhemberger committed Jul 15, 2018
1 parent 6f164f7 commit 4a9fff2
Show file tree
Hide file tree
Showing 8 changed files with 557 additions and 0 deletions.
56 changes: 56 additions & 0 deletions locale/zh-cn/about/community.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
---
title: 社区委员会
layout: about.hbs
---

# 社区委员会

社区委员会(CommComm)是 Node.js 最高级别的委员会。委员会对外拥有一定的权利,其中包括:
- 社区 [布道](https://github.com/nodejs/evangelism)
- 教育倡议
- Node.js 基础的文化指导
- 社区组织拓展
- 翻译及国际化项目
- 项目审核 / 调解
- 公共拓展以及 [出版物](https://medium.com/the-node-js-collection)

参与社区委员会类型总共分为四类:

- **贡献者** 任何创建或评论议题,或者发送 PR 的个人。
- **合作者** 被授予直接可以向 Node 仓库“写”操作权限的贡献者。
- **观察者** 指任意一个个人,他(被)要求参与社区委员会的会议。这也是他走向会员的第一步。
- **会员** 符合参与要求,具备投票权利的个人,由社区委员会投票选举产生。

欲了解目前的社区委员会成员,请参考 [README.md](https://github.com/nodejs/community-committee)

## 贡献者与合作者

发展壮大 Node.js 社区是社区委员会的使命。当你读到这时,你其实已经是社区的一份子了——同时也是 Node.js 社区的一份子。我们热爱你的帮助!

[nodejs/ 社区委员会](https://github.com/nodejs/community-committee) 中,GitHub 是一个很好的开始。请查看 [标记为“首要议题”](https://github.com/nodejs/community-committee/labels/good%20first%20issue) 相关内容以便了解我们需要在哪里需要你的帮助。如果你有关于我们如何更好地鼓励和构建我们社区的建议,放心大胆地提出议题并向我们已有的工作提出 PR。或者通过我们在 GitHub 上已有的讨论中分享你的相关想法。

你可以进一步参与我们持续构建社区的活动——像本地化、布道、Node.js 意见收集和其它活动——通过对 Node.js 源仓库的深入挖掘开始融入其中!

在此之前,请确认你已经细读了 [合作者指南](https://github.com/nodejs/community-committee/blob/master/COLLABORATOR_GUIDE.md)

如果你对以社区会员身份参与社区委员会活动感兴趣的话,你应该阅读以下 **观察者与会员** 相关章节部分。随后发出请求希望成为我们下一届社区委员会的观察者。你可以在 [此处](https://github.com/nodejs/community-committee/issues/142) 寻找到相关的内容。

## 观察者与会员

如果你对更进一步参与社区委员会以及相关项目感兴趣的话,我们鼓励你成为一个活跃的观察者,为直接成为会员而努力工作。要想成为一个会员,你必须做到:

1. 参与每周两次的会议,探讨那些标记为首要议题、会议文件以及 PR。并通过 GitHub,以贡献者或者合作者的身份凸显你的洞察力。
2. 通过发起请求成为一个观察者。一旦作为观察者被邀请加入参与会议,我们会持续三个月跟踪记录你的参与度以符合我们的治理准则。你可以在 [ 此处 ](https://github.com/nodejs/community-committee/issues/142) 寻找到有关于此的绝好例子。
3. 当你已经符合了三个月的最低考勤条件,且符合期望参与度,社区委员会将投票把你纳入会员。

会员身份可以保持六个月。小组会定期询问逾期会员是否继续愿意留任。会员只需回复“留任”即可。社区委员会虽无固定大小限制,但是,希望的人数最好在九到十二人之间。你可以在 [治理准则](https://github.com/nodejs/community-committee/blob/master/GOVERNANCE.md) 中阅读更多有关会员身份的资料信息,以及其它管理信息。

定期社区委员会的会议每两个月通过变焦视频举行,然后会在 YouTube 上向公众播放。任何一个社区会员或者贡献者都可以通过 GitHub 发起请求参与下一次的会议议程。

在会议开始前,相关的宣告以及议程都将在相关组织 [GitHub 议题](https://github.com/nodejs/community-committee/issues) 中列出。你也可以在 [Node.js 会议安排](https://nodejs.org/calendar) 中找到相关计划会议。为跟上 YouTube 上的 Node.js 实时会议,你应该订阅 [YouTube 频道](https://www.youtube.com/channel/UCQPYJluYC_sn_Qz_XE-YbTQ)。请勿忘记点击铃铛,这样每次有新的会议你就会收到提醒了!

## 寻求协商一致的过程

社区委员会遵循着 [寻求共识](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 的原则来决定规划。

当任意一个议题将进入达成共识的阶段时,主持人会问大家“有人有不同意见吗?”作为最后的提醒,确保达成了共识而没有异议。如果实在无法达成共识但是又没有异议,那么只能采取多数投票。但是我们希望多数的决议是通过寻求共识做出的,而投票只是最后的备选方案。
76 changes: 76 additions & 0 deletions locale/zh-cn/about/governance.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
---
title: 项目管理
layout: about.hbs
---
# 项目管理

## 技术指导委员会

本项目由技术指导委员会共同管理,它同样也对项目技术方面最高级别的指导进行负责。

技术指导委员会对于本项目有最终相关权利,其中包括:

* 技术指导
* 项目管理及推进(已包含在此政策中)
* 贡献政策
* GitHub 库托管
* 指导准则
* 维护其余的合作者列表

最初的成员资格邀请给了技术指导委员会的个人,他们是积极的贡献者以及具备丰富的经验来管理项目。根据项目的需要,成员资格预计会随着时间的推移而演变。

关于目前的 技术指导委员会成员列表,你可以参照 [README.md](https://github.com/nodejs/node/blob/master/README.md#tsc-technical-steering-committee)

## 协作者

[nodejs/node](https://github.com/nodejs/node) 中的 GitHub 仓储库是由技术指导委员会和其它协作者共同维护的,这些协作者都是通过技术指导委员会不断地基础累增的。

作出重大和有价值贡献的个人成为合作者,并给予提交权限。这些个人由技术指导委员会确定,并在每周的技术指导委员会会议上讨论合作者的加入。

_附加说明:_ 如果你已经做出了重大贡献,但是仍然没有被授予提交权限。你可以直接提交一个请求或者联系技术指导委员会会员,这样他们就会在下一次的技术指导委员会会议中涉及到此议题。

nodejs/node 存储库内容的修改是在协作基础上进行的。任何有 GitHub 帐户的人都可能建议通过请求修改,并且它将被项目合作者考虑。所有请求都必须由具有足够专业知识的合作者审阅和接受, 并能够对变更负全部责任。对于现有合作者提出的请求要求, 签署时需要额外的合作者。如果有更多的合作者参与, 并且在特定修改周围存在分歧, 则应寻求协商一致意见。见 _寻求协商一致的过程_ 下面的进一步细节的协商一致模式用于治理。

合作者可选择提升重大或有争议的修改,或对于技术指导委员会而言尚未找到协商一致、并标记为 ***tsc-agenda*** 的改动。技术指导委员会应在必要时作为最终仲裁者。

目前的协作者列表,请查阅 [README.md](https://github.com/nodejs/node/blob/master/README.md#current-project-team-members)

协作者指南在 [COLLABORATOR_GUIDE.md](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md) 中维护。

## 技术指导委员会会员身份

技术指导委员会的人数没有时间限制。没有固定大小的 TSC。然而,预期的目标是在 6 至 12 之间,以确保充分涵盖重要的专门知识领域,并与有效作出决定的能力保持平衡。

在这些规则之外,技术指导委员会成员资格没有特定的规定或资格。

技术指导委员会可以通过标准的 技术指导委员会活动为 技术指导委员会增添更多的成员。

一个技术指导委员会成员可以通过自愿辞职或从技术指导委员会中删除。

对技术指导委员会成员数目的改动应张贴在议程中,并可作为任何其它议程项目提出(见下文“技术指导委员会会议”)。

不超过 1/3 的技术指导委员会成员可能隶属于同一雇主。如果技术指导委员会成员的免职或辞职,或由 技术指导委员会成员改变工作,就会造成 1/3 以上的 技术指导委员会成员与雇主共享的情况,则必须立即因辞职或免职的一个或多个与超过代表的雇主有关的 技术指导委员会成员而得到补救。

## 技术指导委员会会议

技术指导委员会每周通过谷歌广播碰头进行,此会议由技术指导委员会批准指定的主持人召开。每个会议应该都在 YouTube 上公开。

项目被添加到技术指导委员会议程中。这些项目往往是被认为是有争议的,或者是对治理、贡献政策,以及技术指导委员会成员发布过程的修改。

议程的目的不是批准或审查所有补丁。这应该持续发生在 GitHub 上,,由更大的合作者来处理。

任何社区成员或参与者都可以通过记录 GitHub 问题来要求将某些内容添加到下一会议的议程中。任何合作者、TSC 成员或版主可以通过添加 ***tsc-agenda*** 标记把项目添加到到议程。

在每次技术指导委员会会议之前, 主持人将与技术指导委员会的成员分享议程。技术指导委员会成员可以在每次会议开始时将他们喜欢的任何项目添加到议程中。主持人和技术指导委员会不能否决或删除项目。

技术指导委员会可以邀请某些项目的人员或代表参加非投票能力。这些被邀请者目前是:

* 通过该项目从 [build](https://github.com/node-forward/build) 选出的示例性案例。

主持人负责总结每个议程项目,并将其作为请求在会议后发送。

## 寻求协商一致的过程

社区委员会遵循着 [寻求共识](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 的原则来决定规划。

当任意一个议题将进入达成共识的阶段时,主持人会问大家“有人有不同意见吗?”作为最后的提醒,确保达成了共识而没有异议。如果实在无法达成共识但是又没有异议,那么只能采取多数投票。但是我们希望多数的决议是通过寻求共识做出的,而投票只是最后的备选方案。
46 changes: 46 additions & 0 deletions locale/zh-cn/about/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
---
layout: about.hbs
title: 关于
trademark: Trademark
---
# 关于 Node.js®

作为异步驱动的 JavaScript 运行时,Node 被设计成可升级的网络应用。在下面的“Hello World”示例中,许多连接可以并行处理。每一个连接都会触发一个回调,但是如果没有可做的事情,Node 就进入睡眠状态。

```javascript
const http = require('http');

const hostname = '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
res.statusCode = 200;
res.setHeader('Content-Type', 'text/plain');
res.end('Hello World\n');
});

server.listen(port, hostname, () => {
console.log(`Server running at http://${hostname}:${port}/`);
});
```

这与今天使用 OS 线程的更常见并发模型形成了对比。基于线程的网络效率相对低下,使用起来非常困难。此外,Node 的用户不必担心死锁过程, 因为没有锁。Node 中几乎没有函数直接执行 I/O 操作,因此进程从不阻塞。由于没有任何阻塞,可伸缩系统在 Node 中开发是非常合理的。

如果你对这门语言其中的一部分尚未熟悉理解,这里有一篇专门关于 [阻塞对比非阻塞][] 的文章供你参考。

---
Node 在设计上类似于 Ruby 的 [事件机][] 或 Python 的 [扭曲][] 之类的系统。 Node 更深入地考虑事件模型。它呈现一个 [事件轮询][] 作为运行时构造而不是库。在其它系统中,总是有一个阻止调用来启动事件循环。

通常 Node 的行为是通过在脚本开头的回调定义的,在结束时通过阻塞调用(如 `EventMachine::run()` )启动服务器。在 Node 中没有这样的启动-事件循环调用。Node 在执行输入脚本后只需输入事件循环即可。
当没有更多要执行的回调时,Node 退出事件循环。此行为类似于浏览器中的 JavaScript ——事件循环总是对用户不可见的。

HTTP 是 Node 中的一等公民。它设计的是流式和低延迟。这使得 Node 非常适合于 web 库或框架的基础。

仅仅因为 Node 是在没有线程的情况下设计的,这并不意味着您无法利用环境中的多个内核。子进程可以通过使用我们的 [`child_process.fork()`][] API 来生成, 并且被设计为易于沟通。建立在同一接口上的是 [`cluster`][] 模块, 它允许您在进程之间共享套接字, 以便在核心上启用负载平衡。

[阻塞对比非阻塞]: https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/
[`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
[`cluster`]: https://nodejs.org/api/cluster.html
[事件轮询]: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
[事件机]: http://rubyeventmachine.com/
[扭曲]: http://twistedmatrix.com/
Loading

0 comments on commit 4a9fff2

Please sign in to comment.