contributor_docs/zh-Hans/steward_guidelines.md
无论你是刚加入我们的管理员，还是 p5.js 经验丰富的维护者，或者介于两者之间，本指南包含了许多信息、技巧和诀窍，将帮助你和其他贡献者有效地为 p5.js 做出贡献。除非另有说明，这里所写的大部分内容都是指南，这意味着你可以根据自己的工作流程来适应这里所指示的做法。
我们鼓励大多数源代码贡献以 issue 为起点，因此 issues 是大多数讨论发生的地方。你在审查 issue 时可以采取的步骤取决于 issue 的类型。该存储库使用 GitHub issue 模板来更好地组织不同类型的 issues，并鼓励 issue 作者提供有关其问题的所有相关信息。审查 issue 的第一步通常是查看填写的模板，确定是否需要额外的信息（可能是因为某些字段未填写或使用了错误的模板）。
对于 bug 报告 issues，应使用 “发现了一个 bug” issue 模板。通常使用下面流程来处理 bug 报告：
需要帮助 的标签，并要求其他具有 issue 指定设置的人尝试复现该 bug。对于功能请求 issues，应使用“新功能请求” issue 模板。通常使用下面流程来处理功能请求：
join(["Hello", "world!"])，而应优先使用原生 JavaScript 的 ["Hello", "world!"].join()。对于功能增强 issues，应使用“现有功能增强” issue 模板。这里的流程与新增功能请求非常相似。新增功能请求与功能增强之间的区别可能有些模糊，但是功能增强主要涉及 p5.js 的现有功能，而新增功能请求可能是请求添加全新的功能。
此类 issue 有一个简洁的模板（“讨论”），在把主题整合为更具体的内容（如功能请求）之前，用这个模板来收集有关主题的一般性反馈。当这一类的反馈结束并产生更具体的内容后，这类的讨论问题就可以关闭了：
几乎所有对 p5.js 存储库的代码贡献都是通过拉取请求进行的，管理者和维护者可能具有对存储库的推送访问权限，但在贡献代码时仍然鼓励他们遵循相同的 issue > PR > 审查流程。以下是审查 PR 时可以采取的一些步骤：
像小的拼写错误修复之类的简单修复可以由具有合并访问权限的任何人直接合并，只需在 PR 的“更改的文件”选项卡中快速检查，并确保自动化 CI 测试通过。
[contribution type]代替，可用贡献类型的完整列表可以在上面的链接中找到。@all-contributors please add @[GitHub handle] for [contribution type]
新功能或功能增强的 PR 的流程与 bug 修复类似，只有一个显着的区别：
Dependabot 的 PR 通常只对存储库管理员可见，如果这与你无关，请跳过此部分。
本节不涵盖一般的构建设置和命令，而是关于幕后发生的详细信息。关于构建信息，请参阅贡献者指南。
Gruntfile.js 文件包含了 p5.js 及其他内容的主要构建定义。构建库和文档所使用的不同工具包括但不限于 Grunt、Browserify、YUIDoc、ESLint、Babel、Uglify 和 Mocha。从default任务开始，逆向分析可能会有所帮助。在阅读下面的说明时，参考 Gruntfile.js 文档可能会有所帮助。
grunt.registerTask('default', ['lint', 'test']);
当我们运行grunt或 npm 脚本npm test时，我们运行包含lint和test的默认任务。
lint 任务grunt.registerTask('lint', ['lint:source', 'lint:samples']);
lint任务包括两个子任务：lint:source和lint:samples。lint:source又进一步分为三个子任务：eslint:build、eslint:source和eslint:test，它们使用 ESLint 检查构建脚本、源代码和测试脚本。
lint:samples任务首先运行yui任务，该任务本身包括yuidoc:prod、clean:reference和minjson，它们从源代码中提取文档到一个 JSON 文件中，删除上一步骤中未使用的文件，并将生成的 JSON 文件压缩为data.min.json。
接下来，在lint:samples中有一个名为eslint-samples:source的自定义任务，其定义位于./tasks/build/eslint-samples.js中，它将使用 ESLint 检查文档示例代码，以确保其遵循与p5.js的其余部分相同的编码规范（这里首先运行yui，因为我们需要先构建 JSON 文件，然后才能对示例进行检查）。
test 任务grunt.registerTask('test', [
'build',
'connect:server',
'mochaChrome',
'mochaTest',
'nyc:report'
]);
首先，让我们看一下test中的build任务。
grunt.registerTask('build', [
'browserify',
'browserify:min',
'uglify',
'browserify:test'
]);
以browserify开头的任务在./tasks/build/browserify.js中定义。它们执行相似的步骤，但有一些细微的差异。以下是将众多 p5.js 源代码文件整合为一个完整库的主要步骤：
browserify负责构建 p5.js，而browserify:min则构建下一步要进行压缩的中间文件。browserify和browserify:min之间的区别在于，browserify:min不包含 FES 运行所需的数据。uglify将browserify:min的输出文件压缩，生成最终的 p5.min.js 文件（此步骤的配置在主 Gruntfile.js 中）。browserify:test构建的版本与完整的 p5.js 版本相同，只是添加了用于测试代码覆盖率报告的代码（使用 Istanbul ）。在 browserify 步骤中，除了将各种文件合并为一个文件外，还执行了其他几个步骤。首先，使用brfs-babel将fs.readFileSync() node.js 特定代码的使用替换为文件的实际内容。这主要用于 WebGL 代码，以将作为独立文件编写的着色器代码内联到源代码中。
接下来，使用 Babel 将来自 node_modules 的所有依赖项的源代码进行转译，以匹配在 package.json 中定义的 Browserslist 要求，并将 ES6 导入语句转换为 browserify 能理解的 CommonJS require()。这也使我们能够使用 ES6 及更高版本中可用的较新语法，而不必担心浏览器兼容性问题。
在捆绑之后但将捆绑代码写入文件之前，代码会在pretty-fast中运行。如果代码不应被缩小，我们则需清理代码，以使最终格式更加一致。 （如果有需要的话， p5.js 源代码应保持可读、可查阅）
这里省略了一些小的详细步骤；你可以查看上面链接的 browserify 构建定义文件，以更详细地了解所有内容。
connect:server
此步骤启动一个本地服务器，托管测试文件和构建的源代码文件，以便可以在 Chrome 中运行自动化测试。
mochaChrome
此步骤在./tasks/test/mocha-chrome.js中定义。它使用 Puppeteer 来启动一个无头版本的 Chrome，可以进行远程控制，并运行与./test文件夹中的 HTML 文件相关联的测试，包括对未缩小和缩小版本的库进行单元测试，以及测试所有参考示例。
mochaTest
与mochaChrome不同，此步骤在 node.js 中运行，而不是在 Chrome 中运行，并且仅测试库中的一小部分功能。p5.js 中的大多数功能都需要浏览器环境，因此只有在新的测试确实不需要浏览器环境时，才应扩展此测试集合。
nyc:report
最后，在完成所有构建和测试之后，此步骤将收集mochaChrome对库的完整版本进行的测试覆盖率报告，并将测试覆盖数据打印到控制台。p5.js 的测试覆盖率主要用于监控和提供一些额外的数据点，我们的目标不是达到100%的测试覆盖率。
以上内容涵盖了 Gruntfile.js 配置中的默认任务！
如果需要，可以直接使用npx grunt [step]运行所有步骤、子步骤和子子步骤，尽管对于某些步骤而言，如果依赖于此链中的较早步骤，可能没有太大意义进行操作。还有一些未在上面提到但在某些情况下可能有用的任务。
grunt yui:dev
此任务将运行上述描述的文档和库构建，然后启动一个网站，提供与网站上http://localhost:9001/docs/reference/的参考页面功能相似的版本。然后，它将监视源代码的更改，并重新构建文档和库。
当你在处理内联文档的参考资料时，使用grunt yui:dev将非常有用，因为你无需在每次更改后都将 p5.js 存储库中构建好的文件移动至本地的 p5.js-website 存储库并重新构建网站，而是可以直接在浏览器中预览你的更改，这样就可以通过这个略微简化的参考版本来查看更改了。依此方法，你也可以更有信心地认为你所做的更改会在网站上正确显示。请注意，这仅适用于对内联文档的修改；对参考页面本身（包括样式和布局）的更改，应在网站存储库上进行修改和测试。
grunt watch
grunt watch:main
grunt watch:quick
watch 任务将观察一系列文件的更改，并根据所更改的文件运行相关任务以构建参考文档或库。这些任务的作用是相同的，唯一的区别在于范围。
watch任务将在检测到源代码更改时运行所有构建和测试，类似于在源代码中运行完整的默认任务。
watch:main任务将在检测到源代码更改时运行库构建和测试，但不会重新构建参考文档。
watch:quick任务将仅在检测到源代码更改时运行库构建。
根据你的工作内容，选择最简化的 watch 任务可以节省手动重新构建的时间。
有时，需要审核的 issues 和 PRs 的数量太多，可能会令人手足无措，尽管我们尽力采取一些简化流程的措施，但以下是你可以利用的一些提示和技巧，以帮助你审核 issues 和 PR。
你可以使用 GitHub 的 Saved Replies 功能，这是一个方便的功能，可在回复 issues 或 PR 时使用。上面描述的工作流程中的一些步骤可能需要使用相同或非常相似的回复（比如将 issues 重定向到论坛、接受 issues 以进行修复等），使用 Saved Replies 可以稍微提高效率。
以下是 p5.js 维护者使用的一些 Saved Replies，你可以自己使用或创建你自己的 Saved Replies！
我们无法重现这个 issue，但如果你能提供一个演示问题的代码示例，请随时重新打开这个 issue。谢谢！
为了组织的目的，我们关闭了此 issue。如果您能提供一个说明问题的代码片段，请重新打开该 issue。谢谢！
这里的 GitHub issues 是报告 p5.js 库本身的错误和问题的好地方。如果你有关于编写自己的代码、测试或遵循教程的问题，请在论坛上发布。谢谢！
谢谢！讨论 GSOC 提案的最佳地方是我们的论坛。
目前看来，这个功能并没有引起太多关注，而且我们还没有一个清晰的解释来说明它是如何扩大扩大访问权限的，因此我们现在将关闭这个 issue。如果能够在 issue 请求中添加一个关于访问权限的声明，请随时重新打开此 issue。
我们暂时关闭了此 issue，因为没有看到对此 issue 的较详细解释扩大访问权限。如果可以在 issue 请求中添加更详细的访问权限说明，请随时重新打开。谢谢！
我们认为这个功能超出了 p5.js API 的范围（我们尽量保持最简化），但它可以成为一个很好的插件库的起点。请查看此处的文档，了解如何创建一个插件： https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md
谢谢。作为提醒，必须在打开拉取请求之前打开 issues 并使用 issues 标记拉取请求。这对于跟踪开发并保持讨论清晰是必要的。谢谢！
你可以继续进行修复。谢谢。
看起来不错。谢谢！
使用看似复杂的 git 命令来获取 PR 版本的代码并在本地进行测试，可能会使复杂的 PR 审查变得更加困难。幸运的是，GitHub CLI 工具可以极大地帮助简化这个过程以及其他操作。
安装完 CLI 并登录后，你只需要运行命令 gh pr checkout [pull_request_id] 就可以在本地审查 PR。这个命令会自动为你获取远程 fork，创建一个分支，并切换到该分支。如果要返回到主分支，只需像切换分支一样运行 git checkout main 即可。你甚至可以直接从 CLI 在 PR 中留下评论，而无需访问网页页面！
GitHub CLI 还提供了许多其他命令，你可能会发现它们有用。无论如何，这是一个很好的工具。
不再需要手动监视存储库的"Issues"或"Pull Requests"选项卡以获取新的 issues 或 PRs。你可以通过在存储库页面顶部与存储库名称相对的地方点击带有眼睛图标的"Watch"按钮来“关注”该存储库。
通过关注存储库，诸如新 issues、新 PRs、提及你的用户名以及其他你在存储库上订阅的活动都会作为通知发送到你的通知页面，你可以将其标记为已读或忽略，就像处理电子邮件收件箱一样。
在某些情况下，你可能会收到 GitHub 发送的与你关注的存储库中的活动相关的电子邮件，你可以在通知设置页面上进行自定义设置，包括完全取消订阅。
根据你的工作方式设置这些通知，可以避免手动查找相关 issues /PR 并避免被 GitHub 的无休止的通知淹没。在这里需要保持良好的平衡。作为起始建议，你可以关注该存储库的"Issues"和"Pull Requests"，并设置仅在“参与、提及和自定义”时接收电子邮件通知。