在 Devin 中试用 DeepWiki 处理私有仓库
DeepWiki

goldbergyoni/nodebestpractices

菜单

对仓库的贡献

相关源文件

此页面概述了如何为 Node.js 最佳实践仓库贡献内容，详细介绍了提交新内容、翻译以及修复现有内容的流程。它还解释了如何认可贡献者的工作。有关仓库结构和内容组织的更多信息，请参阅仓库结构。

贡献原则

Node.js 最佳实践仓库遵循协作社区模式，强调包容性和高质量内容。该项目保持友好、专业的氛围，所有贡献者都受到欢迎和赞赏。

我们的核心原则包括：

  • 友好的氛围：“我们都是朋友”——我们力求做到专业且友善。
  • 基于事实的内容：所有贡献都应可靠且基于事实信息。
  • 社区驱动：项目通过社区的多元化贡献蓬勃发展。

来源：.operations/CONTRIBUTING.md4-7

贡献类型

仓库接受多种类型的贡献，每种类型的处理方式因其性质而异：

贡献类型描述复杂性
新的最佳实践添加全新的建议或模式高
内容编辑通过实质性修改改进现有内容中等
纯文本更改语法、拼写或其他微小文本更正低
翻译创建或更新翻译中等
技术讨论就 Node.js 实践发起讨论低

来源：.operations/CONTRIBUTING.md18-28

贡献工作流程

一般贡献流程

下图展示了为仓库贡献内容的典型流程：

分步指南

  1. Fork 仓库：在 https://github.com/goldbergyoni/nodebestpractices 创建你自己的仓库副本。
  2. 创建分支：为你的贡献创建一个新分支。
  3. 进行更改：在添加或编辑内容时，请遵循编写指南。
  4. 验证你的 Markdown：提交前运行 linter。
  5. 提交 PR：创建包含你更改的拉取请求。
  6. 审查流程：核心团队成员将审查你的贡献。
  7. 认可：合并后，你将被认可为贡献者。

来源：.operations/CONTRIBUTING.md36-47 .github/workflows/lint-and-generate-html-from-markdown.yml13-31

审查流程

根据贡献类型，仓库有结构化的审查流程。

按贡献类型划分的特定审查标准

新的最佳实践或重大内容更改

  • 至少需要一名其他团队成员提供反馈。
  • 遵循 编写指南。
  • 允许社区评论至少一周。

纯文本更改

  • 简单的措辞编辑或语法更正可以快速获得批准和合并。

翻译

  • 新的翻译需要遵循翻译指南。
  • 对现有翻译的编辑可能需要原翻译者的反馈。

来源：.operations/CONTRIBUTING.md9-30 .operations/common-answers.md1-18 .operations/operations-manual.md70-90

运行 Linter

在提交任何贡献之前，您应该验证您的 Markdown 是否通过了 linter。

用于自动修复基本错误

Linter 确保仓库中所有内容都具有一致的格式和结构。

来源：.operations/CONTRIBUTING.md36-47 .github/workflows/lint-and-generate-html-from-markdown.yml13-31

写作指南

仓库有特定的编写指南，以确保内容的质量和一致性。关键方面包括：

  1. 简洁性：使复杂主题易于理解。
  2. 基于事实的内容：包含参考、基准和可靠来源。
  3. MECE（相互独立且完全穷尽）：提供对主题的全面覆盖。
  4. Node.js 重点：将建议直接与 Node.js 实现相关联。
  5. 一致的格式：使用既定的模板。
  6. 供应商推荐：遵循推荐工具/库的特定规则。

有关详细的编写指南，请参阅编写指南文档。

来源：.operations/writing-guidelines.md1-31

翻译流程

该仓库欢迎翻译，以便让非英语使用者能够访问内容。该项目目前提供多种语言的内容，包括俄语、中文、法语等。

翻译工作流程

翻译的关键指南

  1. 保持原始结构：不要修改内容结构，只翻译文本。
  2. 使用语言后缀复制文件：例如，readme.md 变成 readme.french.md。
  3. 注重翻译准确性：确保技术术语翻译恰当。
  4. 与其他译者协作：多位贡献者可以处理同一语言。

来源：.operations/common-answers.md1-18 .operations/operations-manual.md70-90

贡献者鸣谢

该仓库使用 All Contributors 机器人来认可贡献。每个合并的 PR 都会带来贡献者的认可。

认可系统

在合并 PR 时，核心团队成员将使用 all-contributors 机器人通过类似以下的命令添加贡献者：

@all-contributors please add @username for content

机器人会更新 .all-contributorsrc 文件，并将贡献者的头像和姓名添加到 README 文件中。

来源：.operations/CONTRIBUTING.md14-16 .all-contributorsrc1-1182

仓库维护结构

仓库由不同角色维护，各自承担特定职责。

角色结构

维护角色

  1. 指导委员会：为项目提供指导和未来方向，批准新的最佳实践，并确保内容保持相关性。
  2. 协作者：定期贡献者，通过建议最佳实践、分类问题和审查 PR 来帮助维护仓库。
  3. 贡献者：提交 PR、报告问题或参与讨论的社区成员。

每月维护任务由轮换的维护者执行，以确保仓库的及时更新。

来源：.operations/CONTRIBUTING.md49-62 .operations/operations-manual.md14-51

专业路由系统

该仓库使用复杂的路由系统，将特定类型的贡献引导给正确的专家。

主题示例负责人
代码标准代码拼写错误、示例优化Bruno
翻译新语言、翻译 PR每月轮换
写作质量拼写错误、文本清晰度Bruno
JS 运行时语法正确性Sagir
DevOps监控、部署Kyle
架构项目结构、微服务Yoni
测试CI、lintingYoni
安全安全实践、软件包Kyle
错误处理异常管理Yoni

每种语言的翻译也分配给特定的维护者，以确保质量和一致性。

来源：.operations/operations-manual.md54-90

创建成员头像

团队成员拥有带有颜色编码边框的个人资料图标，以指示其角色。

  • 委员会成员：绿色边框 (#33cd32)
  • 协作者：蓝色边框 (#0efeff)

要创建成员个人资料图标，请使用 SVG 模板，并根据您的角色替换占位符为您 GitHub 用户名和适当的边框颜色。

来源：assets/images/members/create-member-icon.md1-45 assets/images/members/josh-hemphill.png

其他资源