init

dianhao · Sep 15, 2018 · a7c8abe · a7c8abe
1 parent 38d8aa0
commit a7c8abe
Show file tree

Hide file tree

Showing 109 changed files with 7,193 additions and 7,127 deletions.
diff --git a/.gitignore b/.gitignore
@@ -1,17 +1,17 @@
-*.log
-.idea
-.vscode
-.idea/**/*
-.vscode/**/*
-.nyc_output
-mochawesome-report
-.DS_Store
-npm-debug.log.*
-node_modules
-node_modules/**/*
-.eslintcache
-cert
-logs/*
-desktop.ini
-package-lock.json
+*.log
+.idea
+.vscode
+.idea/**/*
+.vscode/**/*
+.nyc_output
+mochawesome-report
+.DS_Store
+npm-debug.log.*
+node_modules
+node_modules/**/*
+.eslintcache
+cert
+logs/*
+desktop.ini
+package-lock.json
 .history
diff --git a/.operations/operations-manual.md b/.operations/operations-manual.md
@@ -0,0 +1,66 @@
+# Operations Manual - Organizing and Maximizing Our Work
+Building a community and knowledge by efficiently handling issues
+
+## Handling issues and PR
+
+<br/>
+In a nutshell, every issue and PR should get tagged by one of our core team and routed to the person who specializes in the related topic. This person then, will warmly welcome and kick the discussion shortly (hopefully within 48 hours). The goal of each issue/pr is to learn, improve and join the opener to our forces.
+
+We count on our core team to visit almost everyday and route inquiries - this way the workflow is not depend upon any specific person rather on our entire team.
+
+Any new content should conform to our writing guidelines
+
+## Monthly maintenance
+
+<br/>
+On every month a maintainer on call will open an issue for maintenance work and record within all the actions to perform by the end of the month (e.g. assign flower to a contributor). On the end of the corresponding month, the maintainer will run the following checklist
+
+Maintainer on call: @someone
+
+**Updates**
+
+- [x] Update top badges with best practices item count, last update date and Node.js version
+- [ ] Ensure all translations are aligned with the English version
+- [x] Update 'thank you' stars & flowers
+- [x] Notify and thanks the contributors of the month
+
+**Flowers**
+- @someone2
+- @someone1
+
+**Stars**
+- @someone1
+
+**Core Team**
+
+| Month   | Maintainer on call |
+|---------|--------------------|
+| 10/2018 | Sagir              |
+| 11/2018 | Bruno              |
+| 12/2018 | Yoni               |
+| 01/2019 | Kyle               |
+| 02/2019 | Sagir              |
+| 03/2019 | Bruno              |
+| 04/2019 | Yoni               |
+| 05/2019 | Kyle               |
+| 06/2019 | Sagir              |
+| 07/2019 | Bruno              |
+| 09/2019 | Yoni               |
+
+
+<br/>
+
+## Routing by areas of expertise
+
+| Topic                    | Examples                                            | Assignee                           |
+|--------------------------|-----------------------------------------------------|------------------------------------|
+| Code standards and fixes | Code typos, code standards,  examples refinements   | Bruno                              |
+| Translations             | Adding new language,  merging language PRs          | Monthly rotation  October - Yoni   |
+| General Writing quality  | Typos, text clarift                                 | Bruno                              |
+| Javascript runtime       | JS runtime, syntax correctness                      | Sagir                              |
+| Devops                   | Monitoring, hardening a production site, deployment | Kyle                               |
+| Architetecture           | Project structure, microservices                    | Yoni                               |
+| Testing                  | CI, linting, testing                                | Yoni                               |
+| Performance              | Efficient code, inspecting processes on fire        | Sagir                              |
+| Security                 | Security packages, secured code                     | Kyle                               |
+| General inquires         | Ideas, requests to contribute, etc                  | Monthly rotation   October - Bruno |
diff --git a/writing-guidelines.chinese.md → .operations/writing-guidelines.chinese.md b/writing-guidelines.chinese.md → .operations/writing-guidelines.chinese.md
@@ -1,31 +1,31 @@
-# 我们的内容写作声明
-如何提高访问者的阅读和学习体验
-
-## 1. 越简单越好
-
-<br/>
-我们的使命, 我们管理内容是为了使阅读和吸收知识更容易。因此, 我们专注于将复杂和无趣的话题转化为一个简化的清单, 用缩短和不那么精确的细节来交易超载信息, 避免 ‘易燃’ 和有争议的话题, 摆脱主观想法, 赞成普遍接受做法
-
-<br/>
-
-## 2. 以证据为基础并且可靠
-
-<br/>
-我们的读者应该有很大的信心, 他们浏览的内容是可靠的。我们通过包括引用、数据和本主题可用的其他资源等证据来实现这一点。实际上, 努力包括可靠来源的引用, 显示基准, 相关的设计模式或任何科学措施, 以证明您的主张
-
-
-## 3.	MECE (Mutually Exclusive and Collectively Exhaustive)
-除了大量编辑和可靠的内容, 通过它略读也应该提供全面覆盖的主题。不应排除重要的子主题
-
-## 4. 一致的格式
-内容是使用固定模板显示的。任何将来的内容都必须符合同一模板。如果希望添加新项目符号, 请从现有项目符号复制项目符号格式, 并将其扩展以满足您的需要。有关其他信息, 请查看[模版](https://github.com/i0natan/nodebestpractices/blob/master/sections/template.md)
-
-## 5. 关于Node.js
-每个建议都应直接与Node.js相关, 而不是一般软件开发。当我们建议在Node.js中实现通用模式/规则时, 内容应该集中在Node的实现上。例如, 当我们建议将所有请求的输入为了安全原因进行处理时, 应使用Node行话 - '使用中间件来处理请求输入'
-
-## 6. 仅限主要的vendor
-有时, 包括可以解决某些挑战和问题 (如 npm 软件包、开源工具甚至商业产品) 的供应商名称是很有用的。为了避免极长的列表或推荐信誉不好和不稳定的项目, 我们提出了以下规则：
-
--	只有排名前3的vendor应该被推荐 – 对于一个给定的相关关键词，如果某个vendor出现在搜索引擎结果中排名前3（谷歌或GitHub通过人气排序），那么它可以包含在我们的推荐里
--	如果它是一个npm包，它必须平均一天下载至少750次
--	如果它是一个开源项目，它必须在过去的6个月里至少更新一次
+# 我们的内容写作声明
+如何提高访问者的阅读和学习体验
+
+## 1. 越简单越好
+
+<br/>
+我们的使命, 我们管理内容是为了使阅读和吸收知识更容易。因此, 我们专注于将复杂和无趣的话题转化为一个简化的清单, 用缩短和不那么精确的细节来交易超载信息, 避免 ‘易燃’ 和有争议的话题, 摆脱主观想法, 赞成普遍接受做法
+
+<br/>
+
+## 2. 以证据为基础并且可靠
+
+<br/>
+我们的读者应该有很大的信心, 他们浏览的内容是可靠的。我们通过包括引用、数据和本主题可用的其他资源等证据来实现这一点。实际上, 努力包括可靠来源的引用, 显示基准, 相关的设计模式或任何科学措施, 以证明您的主张
+
+
+## 3.	MECE (Mutually Exclusive and Collectively Exhaustive)
+除了大量编辑和可靠的内容, 通过它略读也应该提供全面覆盖的主题。不应排除重要的子主题
+
+## 4. 一致的格式
+内容是使用固定模板显示的。任何将来的内容都必须符合同一模板。如果希望添加新项目符号, 请从现有项目符号复制项目符号格式, 并将其扩展以满足您的需要。有关其他信息, 请查看[模版](https://github.com/i0natan/nodebestpractices/blob/master/sections/template.md)
+
+## 5. 关于Node.js
+每个建议都应直接与Node.js相关, 而不是一般软件开发。当我们建议在Node.js中实现通用模式/规则时, 内容应该集中在Node的实现上。例如, 当我们建议将所有请求的输入为了安全原因进行处理时, 应使用Node行话 - '使用中间件来处理请求输入'
+
+## 6. 仅限主要的vendor
+有时, 包括可以解决某些挑战和问题 (如 npm 软件包、开源工具甚至商业产品) 的供应商名称是很有用的。为了避免极长的列表或推荐信誉不好和不稳定的项目, 我们提出了以下规则：
+
+-	只有排名前3的vendor应该被推荐 – 对于一个给定的相关关键词，如果某个vendor出现在搜索引擎结果中排名前3（谷歌或GitHub通过人气排序），那么它可以包含在我们的推荐里
+-	如果它是一个npm包，它必须平均一天下载至少750次
+-	如果它是一个开源项目，它必须在过去的6个月里至少更新一次
diff --git a/writing-guidelines.md → .operations/writing-guidelines.md b/writing-guidelines.md → .operations/writing-guidelines.md
@@ -1,31 +1,31 @@
-# Our content writing manifest
-How we enhance the reading and learning experience for our visitors
-
-## 1. Simple is better than better
-
-<br/>
-Making it easy to read and absorb knowledge is our mission, we curate content. As such we focus on transforming complex and exhausting topics into a simplified list, trade overloaded information with shortened and less-accurate details, avoid ‘flammable’ and controversial topics and escape subjective ideas in favor of generally accepted practices
-
-<br/>
-
-## 2. Be evidence-based and reliable
-
-<br/>
-Our readers should have great confidence that the content they skim through is reliable. We achieve this by including evidence like references, data and other resources available to this topic. Practically, strive to include quotes from reliable sources, show benchmarks, related design patterns or any scientific measure to prove your claims
-
-
-## 3.	MECE (Mutually Exclusive and Collectively Exhaustive)
-Apart from the content being greatly edited and reliable, skimming through it should also provide full coverage of the topic. No important sub-topic should be left out
-
-## 4. Consistent formatting
-The content is presented using fixed templates. Any future content must conform to the same template. If you wish to add new bullets copy a bullet format from an existing bullet and extend it to your needs. For additional information please view [this template](https://github.com/i0natan/nodebestpractices/blob/master/sections/template.md)
-
-## 5. It's About Node.js
-Each advice should be related directly to Node.js and not to software development in general. When we advise to implement generic pattern/rule in Node.js, the content should focus on the Node implementation. For example, when we advise to sanitize all requests input for security reasons, Node-lingo should be used - ‘Use middleware to sanitize request input’
-
-## 6. Leading vendors only
-Sometimes it's useful to include names of vendors that can address certain challenges and problems like npm packages, open source tools or even commercial products. To avoid overwhelmingly long lists or recommending non-reputable and unstable projects, we came up with the following rules:
-
--	Only the top 3 vendors should be recommended – a vendor that appears in the top 3 results of a search engine (Google or GitHub sorted by popularity) for a given relevant keyword can be included in our recommendation
--	If it’s a npm package it must also be downloaded at least 750 times a day on average
--	If it’s an open-source project, it must have been updated at least once in the last 6 months
+# Our content writing manifest
+How we enhance the reading and learning experience for our visitors
+
+## 1. Simple is better than better
+
+<br/>
+Making it easy to read and absorb knowledge is our mission, we curate content. As such we focus on transforming complex and exhausting topics into a simplified list, trade overloaded information with shortened and less-accurate details, avoid ‘flammable’ and controversial topics and escape subjective ideas in favor of generally accepted practices
+
+<br/>
+
+## 2. Be evidence-based and reliable
+
+<br/>
+Our readers should have great confidence that the content they skim through is reliable. We achieve this by including evidence like references, data and other resources available to this topic. Practically, strive to include quotes from reliable sources, show benchmarks, related design patterns or any scientific measure to prove your claims
+
+
+## 3.	MECE (Mutually Exclusive and Collectively Exhaustive)
+Apart from the content being greatly edited and reliable, skimming through it should also provide full coverage of the topic. No important sub-topic should be left out
+
+## 4. Consistent formatting
+The content is presented using fixed templates. Any future content must conform to the same template. If you wish to add new bullets copy a bullet format from an existing bullet and extend it to your needs. For additional information please view [this template](https://github.com/i0natan/nodebestpractices/blob/master/sections/template.md)
+
+## 5. It's About Node.js
+Each advice should be related directly to Node.js and not to software development in general. When we advise to implement generic pattern/rule in Node.js, the content should focus on the Node implementation. For example, when we advise to sanitize all requests input for security reasons, Node-lingo should be used - ‘Use middleware to sanitize request input’
+
+## 6. Leading vendors only
+Sometimes it's useful to include names of vendors that can address certain challenges and problems like npm packages, open source tools or even commercial products. To avoid overwhelmingly long lists or recommending non-reputable and unstable projects, we came up with the following rules:
+
+-	Only the top 3 vendors should be recommended – a vendor that appears in the top 3 results of a search engine (Google or GitHub sorted by popularity) for a given relevant keyword can be included in our recommendation
+-	If it’s a npm package it must also be downloaded at least 750 times a day on average
+-	If it’s an open-source project, it must have been updated at least once in the last 6 months