尧图网页设计 
p5.js 管理者Steward指南Issue 与 PR 审查、构建流程与维护技巧全解析【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js本篇技术指南以 p5.js 官方《管理者ガイド》Steward Guidelines为骨架系统讲解在 p5.js 开源仓库中担任管理者/维护者所需掌握的全部工作流从 Issue 分类处理、PR 审查与合并策略到构建与测试流水线的内部原理再到提升日常维护效率的回复模板、GitHub CLI 与通知管理技巧。读完本文你将能够按照 p5.js 项目实际采用的治理规范独立完成 Issue 分流、代码评审、版本管理与社区协作并理解仓库中 stewards.yml 所定义的职责分工。一、管理者Steward角色定位无论你是刚接触 p5.js 贡献的新手、已活跃在 p5.js GitHub 仓库的维护者还是介于两者之间这份指南都包含了帮助你与他人高效协作的大量信息、提示与技巧。除非特别说明本文内容大多属于**指南性建议guidelines**而非强制规则——你可以根据自身工作流灵活调整这些惯例。从仓库根目录的 stewards.yml 可以看到当前管理者的实际分工结构例如davepagurek: - Core - Maintainers - Graphics: - WebGL - WebGPU limzykenneth: - Maintainers - DevOps - Documentation - Color - i18n: - zh从中可以总结出 p5.js 管理领域Areas的典型划分这些领域大多与 GitHub Labels 一一对应Accessibility无障碍数字与 Web 无障碍例如通过describe(..)等 API 提供屏幕阅读器支持以及参考网站上的无障碍支持Core核心p5.js 核心 API包括渲染与环境DevOps构建流程、单元测试及其他开发体验相关方面Documentation文档核心代码库中展示在网站上的参考文档、贡献者文档及其他网站内容i18n国际化/翻译审阅翻译尤其是es、hi、ko、zhGraphics图形包含 WebGL 与 p5.strands 子领域Color颜色Color、ColorMode 及颜色相关的无障碍改进Typography排版文本与字体处理的所有主题Math数学外部数学 API 与内部性能优化Shapes形状p5.js 1.11.x 与 2.x 版本中的自定义形状Maintainers维护者拥有合并 PR 权限的群体p5.sound.js / p5.js-website / p5.js-web-editor分别对应音效插件库、参考网站、Web 编辑器的非内容层面工作。成为管理者的两种途径一是由维护者或其他管理者提名如在 Discord、Discourse 或 GitHub 上沟通二是主动申请——向stewards.yml提交一个 PR写入你的 GitHub 账号与申请领域每个领域通常 1~3 名管理者项目长期欢迎翻译管理者。申请 PR 提交后其他维护者可能要求你补充支撑材料例如提交一个与你感兴趣领域相关的 PR或参与相关讨论。要保持管理者身份你需要在最近 2 个次要版本minor release如 2.1.0 或 1.11.0中至少以管理者身份贡献过 1 个版本。实践中这意味着管理者大约每 4~6 个月活跃一次通过讨论或代码评审支持其他贡献者——不一定要写代码。如需卸任提交 PR 将自己从stewards.yml中移除即可未来随时欢迎重新申请。二、Issues分类处理的标准工作流绝大多数源码贡献都以 issue 为起点issue 也是讨论发生的主要场所。审查 issue 的步骤取决于其类型。仓库使用 GitHub Issue 模板 来组织不同类型的 issue并鼓励提交者提供完整信息。审查 issue 的第一步通常是核对已填写的模板判断是否需要补充信息例如某些字段未填写或使用了错误的模板。当前仓库的模板目录包含五类模板与本文的 issue 分类一一对应1-p5.js-2.0-bug-report.yml2.0 版本 bug2-found-a-bug.yml发现 bug3-existing-feature-enhancement.yml既有功能增强4-feature-request.yml新功能请求5-discussion.yml讨论2.1 错误报告Bug Report错误报告应使用「发现 Bug」模板典型处理流程如下复现 Bug模板的目标是提供足够信息让审查者能够尝试复现所报告的 Bug如果报告的 Bug 与当前仓库p5.js、p5.js-website 等无关有权限时将该 issue转移到相关仓库否则留下评论说明该错误报告应提交到哪里附直接链接然后关闭 issue审查的第一步是确认信息是否足以复现若是则按描述尝试复现。Bug 可复现时有时需要讨论才能确定最佳修复方案可能简单也可能棘手做决定时可参考 p5.js 设计原则若 issue 作者表示愿意提供修复留下评论表示同意并使用右侧「Assignee」旁的齿轮图标将 issue 分配给作者若作者不愿提供修复留下评论确认 Bug 可复现尝试自己修复或为 issue 添加help wanted标签标记需要修复。Bug 无法复现时若模板中尚未提供附加信息p5.js 版本、浏览器版本、OS 版本等向作者索要若你的测试环境与 issue 报告的不同不同浏览器或 OS留下评论说明你在特定环境下无法复现添加help wanted标签请拥有该环境的人尝试复现有时 Bug 只在 Web 编辑器中出现而本地测试正常此时应将该 issue 转至 p5.js Web 编辑器仓库之后若能复现回到第 2 步。Bug 源于用户提供的代码而非 p5.js 行为时考虑能否通过改进 p5.js 文档、代码实现或友好错误系统Friendly Error System来避免类似错误若 p5.js 无需进一步改动将后续问题引导至 Processing 官方论坛或 Discord并关闭 issue。2.2 新功能请求Feature Request功能请求应使用「New Feature Request」模板典型流程如下无障碍论证作为 p5.js 提升可及性承诺的一部分所有功能请求必须说明该功能如何提升对历史上被边缘化社区的访问。详细说明参见 access.md。若「Increasing Access」字段填写不足可要求作者说明该功能如何提升可及性功能的无障碍陈述也可由社区其他成员包括 issue 审查者提供。这一点在模板中已被设为必填项见 4-feature-request.yml 中的required: true。纳入评估标准是否符合项目范围与设计原则例如新增一个绘制图元primitive shape的请求可以考虑但采用基于浏览器的 IoT 协议则很可能超出范围。总体而言 p5.js 的范围应保持相对狭窄避免因少用功能导致代码库过度膨胀不符合范围的特性建议作者以插件库addon library形式实现不确定是否合适时建议先做一个插件库作为概念验证proof-of-concept既能让用户用上该功能也能更具体地展示其用途与重要性日后合适再并入核心是否可能造成破坏性变更是否会与既有 p5.js 函数和变量冲突是否会与已为 p5.js 编写的典型 sketch 冲突凡可能引发上述冲突的功能均视为破坏性变更在未发布主版本major version之前不应引入能否用现有能力实现是否能用 p5.js 已有功能、较简单的原生 JavaScript 或现有易用库实现例如无需提供join([Hello, world!])这样的数组拼接函数应优先使用原生 JavaScript 的[Hello, world!].join()。双人审批在满足无障碍要求与其他考量之后新功能请求在进入 PR 工作前必须获得至少 2 位管理者或维护者的批准。新功能的 PR 审查流程详见后文。2.3 功能增强Feature Enhancement功能增强应使用「Existing Feature Enhancement」模板流程与新功能请求非常相似。二者的界限有时模糊功能增强主要针对 p5.js既有函数而新功能请求是请求添加全新函数。与新功能请求相同功能增强只有在提升 p5.js 可及性时才应被接受纳入标准类似但需特别关注潜在破坏性变更若修改既有函数所有先前有效且已记录的函数签名必须以相同方式工作在进入 PR 工作前功能增强必须获得至少 1 位管理者或维护者的批准。2.4 讨论Discussion此类 issue 使用极简模板「Discussion」用于在将主题收敛为更具体的内容如功能请求之前收集通用反馈。当讨论结束且已创建更具体的 issue 后可以关闭讨论型 issue若以讨论形式提交的 issue 实际上是 Bug 报告应打上正确标签并移除「discussion」标签同时向作者索要 Bug 报告中缺失的其他信息若讨论与源码贡献无关、或与 GitHub 仓库/贡献流程/贡献社区无关例如「哪种投影仪最适合 p5.js sketch」应引导至论坛或 Discord 并关闭 issue适用时可为讨论 issue 添加额外标签以便一眼看出讨论类型。三、Pull Requests审查与合并规范p5.js 仓库的几乎全部代码贡献都通过 PR 完成。管理者和维护者可能拥有仓库的推送权限但贡献代码时同样被鼓励遵循「issue → PR → 审查」流程。审查 PR 的要点如下PR 模板见 .github/PULL_REQUEST_TEMPLATE.md其中要求 PR 描述中包含resolves #XXXX完全解决或addresses #XXXX部分解决不自动关闭原 issue几乎所有 PR 都必须先有已开且经过讨论的关联 issue即管理者审查 PR 前应已遵循前文 issue 工作流唯一例外是极小的拼写修正无需先开 issue拥有合并权限的任何人都可直接合并即使不是特定领域的管理者虽然存在该例外实践中仍鼓励贡献者先开 issue——如果不确定是否适用此例外直接开一个 issue 即可若 PR 未完全解决其引用的 issue可编辑原文将「Resolves #OOOO」改为「Addresses #OOOO」这样 PR 合并时不会自动关闭原 issue。3.1 简单修复Simple Fix类似小拼写修正的简单修复拥有合并权限者可直接合并。操作要点在 PR 的「Files Changed」标签页快速检查改动并确认自动化 CI 测试通过。3.2 错误修复Bug Fix错误修复应由相关领域的管理者审查最好由批准该 issue 修复的同一人负责使用 PR 的「Files Changed」标签页初步审查修复是否与 issue 讨论一致尽可能在本地测试 PRGitHub CLI 可简化此过程详见后文「提示与技巧」。修复应满足以下检查清单修复应充分解决原 issue除非原 issue 中已达成共识修复不应改变既有行为修复不应显著影响 p5.js 性能修复不应影响 p5.js 的无障碍特性修复应使用现代 JavaScript 标准编写修复应通过所有自动化测试并在相关时包含新测试。若需要其他修改应在相关行添加行级评论可用**建议模块Suggest Change**提出具体修改若需多处修改不要多次添加单行评论而应按照 GitHub 文档使用多行评论并一次性「Request changes」若行级评论仅为澄清或讨论应选择「Comment」而非「Request changes」。PR 审查完毕且无需更多修改时管理者选择「Approve」将 PR 标记为「Approved」可附评论。之后视需要请另一位管理者/维护者复审有合并权限则自行合并否则请维护者合并。应调用 all-contributors 机器人将新贡献者加入 README.md 的贡献者列表。各类贡献类型以[contribution type]占位all-contributors please add [GitHub handle] for [contribution type]3.3 新功能/功能增强New Feature / Feature Enhancement流程与错误修复类似但有一个显著区别新功能/功能增强 PR 在合并前必须由至少 2 位管理者或维护者审查并批准可以是批准原 issue 的同一批人也可以是其他人。3.4 Dependabot 自动依赖更新Dependabot 的 PR 通常只有仓库管理员可见若不适用可直接跳过本节。**补丁版本patch**更新且自动化 CI 测试通过可直接合并**次要版本minor**更新且 CI 通过通常可直接合并但建议快速查看所更新依赖的 changelog**主版本major**更新可能影响构建流程或 p5.js 功能。建议审查从当前版本到目标版本的 changelog并在本地测试 PR 以确保所有流程正常针对依赖的潜在破坏性变更做必要修改。注意很多依赖提升主版本号仅仅是因为停止支持非常古老的 Node.js 版本这并不一定意味着依赖 API 变更带来的破坏性变化。四、构建流程从 Grunt 时代到现代工具链本节不讨论通用构建配置与命令而是聚焦背后发生的事。更详细的构建信息参见 贡献者指南。4.1 历史上的构建任务v1.x原版管理者指南记录了基于 Grunt 的构建体系Gruntfile.js包含 p5.js 及其他内容的主要构建定义使用 Grunt、Browserify、YUIDoc、ESLint、Babel、Uglify、Mocha 等工具。从default任务开始逆向分析最有帮助。default任务grunt.registerTask(default, [lint, test]);执行grunt或 npm 脚本npm test即运行包含lint和test的默认任务。lint任务grunt.registerTask(lint, [lint:source, lint:samples]);lint:source进一步分为eslint:build、eslint:source、eslint:test使用 ESLint 检查构建脚本、源码与测试脚本lint:samples先执行yui任务包含yuidoc:prod、clean:reference、minjson负责从源码提取文档为 JSON、清理未使用文件、压缩为data.min.json再运行自定义任务eslint-samples:source用 ESLint 检查文档示例代码是否符合与 p5.js 其余部分相同的编码标准先执行yui是因为检查示例前需要先构建 JSON 文件。test任务grunt.registerTask(test, [ build, connect:server, mochaChrome, mochaTest, nyc:report ]);build任务browserify负责将大量 p5.js 源文件合并为单一完整库browserify:min构建用于下一步压缩的中间文件区别在于browserify:min不包含 FES 运行所需数据uglify压缩browserify:min输出生成最终 p5.min.jsbrowserify:test构建与完整版相同的库但使用 Istanbul 注入代码覆盖率报告所需的附加代码Browserify 内部还做了几件事用brfs-babel将fs.readFileSync()Node.js 专有代码替换为文件实际内容主要用于 WebGL 代码将独立文件中的着色器代码内联进源码用 Babel 转译 node_modules 依赖源码以匹配 package.json 中按 Browserslist 定义的要求并把 ES6 import 转成 Browserify 可理解的 CommonJSrequire()打包后写盘前还会用pretty-fast清理代码格式保证非压缩版源码可读可引用connect:server启动本地服务器托管测试文件与构建产物供 Chrome 自动化测试使用mochaChrome使用 Puppeteer 启动无头 Chrome远程控制执行./test文件夹中 HTML 文件关联的测试包括未压缩版与压缩版库的单元测试及全部参考示例测试mochaTest在 Node.js 上运行而非 Chrome只测试极少数不需要浏览器环境的库功能——p5.js 大多数功能需要浏览器环境因此仅当新测试确实不需要浏览器时才应扩充此测试集合nyc:report收集mochaChrome对完整版库的测试覆盖率报告并输出到控制台。p5.js 的测试覆盖率主要用于监控与附加数据点目标并非 100% 覆盖率。杂务任务Miscellaneous Tasksnpx grunt [step]可直接运行任意步骤/子步骤/子子步骤但某步骤依赖链上前序步骤时单独运行可能无意义grunt yui:dev构建文档与库后启动 Web 服务器在本地提供类似参考页面的预览http://localhost:9001/docs/reference/并监视源码变更自动重建。处理内联文档时非常有用无需把构建产物搬运到 p5.js-website 仓库即可在浏览器中预览效果但该用法仅限内联文档改动参考页面本身的改动样式、布局仍需在网站仓库中测试grunt watch/grunt watch:main/grunt watch:quick监视一组文件变更并触发相关构建。三者功能相同、范围不同watch在检测到源码变更时运行全部构建与测试相当于完整 default 任务watch:main只构建并测试库、不重建参考文档watch:quick只构建库。按工作内容选择最简化的 watch 任务可节省手动重建时间。4.2 当前构建与测试现状v2.x需要指出的是上述 Grunt/Browserify/Mocha 流水线在 p5.js 2.0 起已被移除英文版指南明确记载了这一变更。从当前仓库的 package.json版本 2.3.1可以核实构建与测试已迁移到现代工具链脚本定义如下scripts: { build: rolldown -c, test: vitest, lint: oxlint ., lint:fix: oxlint --fix ., docs: documentation build ./src/**/*.js ... -o ./docs/data.json node ./utils/convert.mjs, generate-types: npm run docs node utils/typescript.mjs }lint任务v2.x直接通过 npm 脚本使用 ESLint实际仓库使用 oxlint见 eslint.config.mjs 与 .oxlintrc.jsonnpm run lint该命令检查源文件、构建脚本、测试文件与文档示例。若只想对特定文件或目录执行 lint可直接调用npx eslint src/ npx eslint test/v2.x 不再有独立的示例 linter 或基于 YUIDoc 的流水线。test任务v2.x测试系统改用 Vitest通过 npm 脚本运行npm test该命令依次执行ESLint 代码风格检查 → 单元测试 → 视觉测试基于渲染快照的 snapshot 测试。测试位于test/unit目录其结构镜像src目录——例如src/color/p5.Color.js的测试位于 test/unit/color/p5.Color.js视觉测试位于 test/unit/visual。调试时可运行浏览器环境下的交互式测试npx vitest --ui代码覆盖率使用 Vitest 内置工具npx vitest run --coverage从 vitest.config.js 可以看到测试还拆分为常规单元测试与 WebGPU 专项测试两个 project并通过 Playwright 驱动 Chromium 浏览器执行CI 环境下会附加--no-sandbox、--headlessnew等 WebGPU 软渲染参数。五、发布流程Release Processp5.js 的完整发布流程详见 release_process.md。该文档覆盖版本号策略、发布前置检查、构建产物发布、参考文档与类型声明同步等环节管理者在主导或参与发布前务必通读。六、提示与技巧高效维护的实用工具有时需要审查的 issue 和 PR 数量会令人应接不暇。虽然项目已尽量简化流程但仍有不少技巧可以帮助你更高效地审查。6.1 回复模板Saved RepliesGitHub 的 Saved Replies已保存回复功能非常适合此类场景工作流中的某些步骤将问题引导至论坛、接受 issue 修复等需要给出相同或高度相似的回复使用 Saved Replies 能显著提升效率。以下是 p5.js 维护者实际使用的一些 Saved Replies你可以直接使用或创建自己的版本关闭无法复现我们无法复现此问题但如果你能提供展示该问题的代码示例请随时重新打开。谢谢关闭需要代码片段出于组织管理目的我将关闭此问题。如果你能提供说明问题的代码片段请重新打开。谢谢关闭请使用论坛这里的 GitHub issue 适合报告 p5.js 库本身的 Bug 与问题。关于编写你自己的代码、测试或跟随教程的问题请发布在 Processing 官方论坛。谢谢关闭GSOC谢谢讨论 GSOC 提案的最佳地点是我们的论坛Summer of Code 板块。关闭可及性我没有看到该功能能带来很多关注且我们也没有清楚说明它如何「扩大可及性」见 access.md因此我将暂时关闭。如果能在 issue 请求中补充可及性陈述欢迎重新打开。我们没有看到此问题如何「扩大可及性」见 access.md的进一步说明因此暂时关闭此 issue。如果能在功能请求中补充更详细的可及性陈述欢迎重新打开。谢谢关闭插件库我认为此功能超出了 p5.js API 的范围我们尽量保持其最小化但它可能是插件库的良好起点。关于如何创建插件的文档请参见 Creating an Addon Library。关闭 PR请先提交 issue谢谢。提醒一下pull request 打开之前需要先打开 issue并在 PR 中标记该 issue。这对于跟踪开发进度和保持讨论清晰是必要的。谢谢批准 issue 修复你可以继续进行修复。谢谢。合并 PR看起来不错。谢谢6.2 GitHub CLI本地审查复杂 PR审查复杂 PR 时用复杂的 git 命令将 PR 的代码拉到本地测试可能很困难。幸运的是 GitHub CLI 工具能大幅简化此过程。安装 CLI 并登录后本地审查 PR 只需运行gh pr checkout [pull_request_id]该命令会自动完成「获取远程 fork、创建分支、切换分支」的全过程。回到主分支与切换分支相同运行git checkout main即可。你甚至可以直接从 CLI 给 PR 留言完全无需访问网页。GitHub CLI 还提供了许多其他命令是一个值得常备的工具。6.3 管理通知Managing Notifications与其手动刷新仓库的「Issues」或「Pull Requests」标签页来检查新内容不如「Watch关注」仓库——点击仓库页顶部仓库名对侧的带眼睛图标的「Watch」按钮即可。关注仓库后新 issue、新 PR、对你的用户名的提及以及你在该仓库订阅的其他活动都会作为通知发送到 GitHub 通知页面可以像处理电子邮件收件箱一样标记已读或忽略。在某些情况下你还会收到关于所关注仓库活动的 GitHub 邮件可在通知设置页面自定义包括完全退订。将这些设置调整为适合你的工作方式是「手动寻找待审查 issue/PR」与「被 GitHub 无尽通知淹没」之间的关键平衡。作为起步建议管理者应关注本仓库的「Issues」和「Pull Requests」并将邮件通知设置为仅在「参与、提及和自定义」时发送。结语把治理规范落到仓库实处p5.js 的维护体系建立在「issue 先行、双人审批、分类审查、文档与贡献者并重」的共识之上。这套规范在仓库中有迹可循Issue 模板见 .github/ISSUE_TEMPLATEPR 模板见 .github/PULL_REQUEST_TEMPLATE.md领域分工见 stewards.yml构建测试配置见 package.json 与 vitest.config.js。无论是想成为管理者、协助评审他人代码还是希望自己的 PR 更快被合并理解这套流程都能让你在 p5.js 的贡献与维护之路上事半功倍。【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 p5.js 管理者（Steward）指南：Issue 与 PR 审查、构建流程与维护技巧全解析
p5.js 管理者Steward指南Issue 与 PR 审查、构建流程与维护技巧全解析【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js本篇技术指南以 p5.js 官方《管理者ガイド》Steward Guidelines为骨架系统讲解在 p5.js 开源仓库中担任管理者/维护者所需掌握的全部工作流从 Issue 分类处理、PR 审查与合并策略到构建与测试流水线的内部原理再到提升日常维护效率的回复模板、GitHub CLI 与通知管理技巧。读完本文你将能够按照 p5.js 项目实际采用的治理规范独立完成 Issue 分流、代码评审、版本管理与社区协作并理解仓库中 stewards.yml 所定义的职责分工。一、管理者Steward角色定位无论你是刚接触 p5.js 贡献的新手、已活跃在 p5.js GitHub 仓库的维护者还是介于两者之间这份指南都包含了帮助你与他人高效协作的大量信息、提示与技巧。除非特别说明本文内容大多属于**指南性建议guidelines**而非强制规则——你可以根据自身工作流灵活调整这些惯例。从仓库根目录的 stewards.yml 可以看到当前管理者的实际分工结构例如davepagurek: - Core - Maintainers - Graphics: - WebGL - WebGPU limzykenneth: - Maintainers - DevOps - Documentation - Color - i18n: - zh从中可以总结出 p5.js 管理领域Areas的典型划分这些领域大多与 GitHub Labels 一一对应Accessibility无障碍数字与 Web 无障碍例如通过describe(..)等 API 提供屏幕阅读器支持以及参考网站上的无障碍支持Core核心p5.js 核心 API包括渲染与环境DevOps构建流程、单元测试及其他开发体验相关方面Documentation文档核心代码库中展示在网站上的参考文档、贡献者文档及其他网站内容i18n国际化/翻译审阅翻译尤其是es、hi、ko、zhGraphics图形包含 WebGL 与 p5.strands 子领域Color颜色Color、ColorMode 及颜色相关的无障碍改进Typography排版文本与字体处理的所有主题Math数学外部数学 API 与内部性能优化Shapes形状p5.js 1.11.x 与 2.x 版本中的自定义形状Maintainers维护者拥有合并 PR 权限的群体p5.sound.js / p5.js-website / p5.js-web-editor分别对应音效插件库、参考网站、Web 编辑器的非内容层面工作。成为管理者的两种途径一是由维护者或其他管理者提名如在 Discord、Discourse 或 GitHub 上沟通二是主动申请——向stewards.yml提交一个 PR写入你的 GitHub 账号与申请领域每个领域通常 1~3 名管理者项目长期欢迎翻译管理者。申请 PR 提交后其他维护者可能要求你补充支撑材料例如提交一个与你感兴趣领域相关的 PR或参与相关讨论。要保持管理者身份你需要在最近 2 个次要版本minor release如 2.1.0 或 1.11.0中至少以管理者身份贡献过 1 个版本。实践中这意味着管理者大约每 4~6 个月活跃一次通过讨论或代码评审支持其他贡献者——不一定要写代码。如需卸任提交 PR 将自己从stewards.yml中移除即可未来随时欢迎重新申请。二、Issues分类处理的标准工作流绝大多数源码贡献都以 issue 为起点issue 也是讨论发生的主要场所。审查 issue 的步骤取决于其类型。仓库使用 GitHub Issue 模板 来组织不同类型的 issue并鼓励提交者提供完整信息。审查 issue 的第一步通常是核对已填写的模板判断是否需要补充信息例如某些字段未填写或使用了错误的模板。当前仓库的模板目录包含五类模板与本文的 issue 分类一一对应1-p5.js-2.0-bug-report.yml2.0 版本 bug2-found-a-bug.yml发现 bug3-existing-feature-enhancement.yml既有功能增强4-feature-request.yml新功能请求5-discussion.yml讨论2.1 错误报告Bug Report错误报告应使用「发现 Bug」模板典型处理流程如下复现 Bug模板的目标是提供足够信息让审查者能够尝试复现所报告的 Bug如果报告的 Bug 与当前仓库p5.js、p5.js-website 等无关有权限时将该 issue转移到相关仓库否则留下评论说明该错误报告应提交到哪里附直接链接然后关闭 issue审查的第一步是确认信息是否足以复现若是则按描述尝试复现。Bug 可复现时有时需要讨论才能确定最佳修复方案可能简单也可能棘手做决定时可参考 p5.js 设计原则若 issue 作者表示愿意提供修复留下评论表示同意并使用右侧「Assignee」旁的齿轮图标将 issue 分配给作者若作者不愿提供修复留下评论确认 Bug 可复现尝试自己修复或为 issue 添加help wanted标签标记需要修复。Bug 无法复现时若模板中尚未提供附加信息p5.js 版本、浏览器版本、OS 版本等向作者索要若你的测试环境与 issue 报告的不同不同浏览器或 OS留下评论说明你在特定环境下无法复现添加help wanted标签请拥有该环境的人尝试复现有时 Bug 只在 Web 编辑器中出现而本地测试正常此时应将该 issue 转至 p5.js Web 编辑器仓库之后若能复现回到第 2 步。Bug 源于用户提供的代码而非 p5.js 行为时考虑能否通过改进 p5.js 文档、代码实现或友好错误系统Friendly Error System来避免类似错误若 p5.js 无需进一步改动将后续问题引导至 Processing 官方论坛或 Discord并关闭 issue。2.2 新功能请求Feature Request功能请求应使用「New Feature Request」模板典型流程如下无障碍论证作为 p5.js 提升可及性承诺的一部分所有功能请求必须说明该功能如何提升对历史上被边缘化社区的访问。详细说明参见 access.md。若「Increasing Access」字段填写不足可要求作者说明该功能如何提升可及性功能的无障碍陈述也可由社区其他成员包括 issue 审查者提供。这一点在模板中已被设为必填项见 4-feature-request.yml 中的required: true。纳入评估标准是否符合项目范围与设计原则例如新增一个绘制图元primitive shape的请求可以考虑但采用基于浏览器的 IoT 协议则很可能超出范围。总体而言 p5.js 的范围应保持相对狭窄避免因少用功能导致代码库过度膨胀不符合范围的特性建议作者以插件库addon library形式实现不确定是否合适时建议先做一个插件库作为概念验证proof-of-concept既能让用户用上该功能也能更具体地展示其用途与重要性日后合适再并入核心是否可能造成破坏性变更是否会与既有 p5.js 函数和变量冲突是否会与已为 p5.js 编写的典型 sketch 冲突凡可能引发上述冲突的功能均视为破坏性变更在未发布主版本major version之前不应引入能否用现有能力实现是否能用 p5.js 已有功能、较简单的原生 JavaScript 或现有易用库实现例如无需提供join([Hello, world!])这样的数组拼接函数应优先使用原生 JavaScript 的[Hello, world!].join()。双人审批在满足无障碍要求与其他考量之后新功能请求在进入 PR 工作前必须获得至少 2 位管理者或维护者的批准。新功能的 PR 审查流程详见后文。2.3 功能增强Feature Enhancement功能增强应使用「Existing Feature Enhancement」模板流程与新功能请求非常相似。二者的界限有时模糊功能增强主要针对 p5.js既有函数而新功能请求是请求添加全新函数。与新功能请求相同功能增强只有在提升 p5.js 可及性时才应被接受纳入标准类似但需特别关注潜在破坏性变更若修改既有函数所有先前有效且已记录的函数签名必须以相同方式工作在进入 PR 工作前功能增强必须获得至少 1 位管理者或维护者的批准。2.4 讨论Discussion此类 issue 使用极简模板「Discussion」用于在将主题收敛为更具体的内容如功能请求之前收集通用反馈。当讨论结束且已创建更具体的 issue 后可以关闭讨论型 issue若以讨论形式提交的 issue 实际上是 Bug 报告应打上正确标签并移除「discussion」标签同时向作者索要 Bug 报告中缺失的其他信息若讨论与源码贡献无关、或与 GitHub 仓库/贡献流程/贡献社区无关例如「哪种投影仪最适合 p5.js sketch」应引导至论坛或 Discord 并关闭 issue适用时可为讨论 issue 添加额外标签以便一眼看出讨论类型。三、Pull Requests审查与合并规范p5.js 仓库的几乎全部代码贡献都通过 PR 完成。管理者和维护者可能拥有仓库的推送权限但贡献代码时同样被鼓励遵循「issue → PR → 审查」流程。审查 PR 的要点如下PR 模板见 .github/PULL_REQUEST_TEMPLATE.md其中要求 PR 描述中包含resolves #XXXX完全解决或addresses #XXXX部分解决不自动关闭原 issue几乎所有 PR 都必须先有已开且经过讨论的关联 issue即管理者审查 PR 前应已遵循前文 issue 工作流唯一例外是极小的拼写修正无需先开 issue拥有合并权限的任何人都可直接合并即使不是特定领域的管理者虽然存在该例外实践中仍鼓励贡献者先开 issue——如果不确定是否适用此例外直接开一个 issue 即可若 PR 未完全解决其引用的 issue可编辑原文将「Resolves #OOOO」改为「Addresses #OOOO」这样 PR 合并时不会自动关闭原 issue。3.1 简单修复Simple Fix类似小拼写修正的简单修复拥有合并权限者可直接合并。操作要点在 PR 的「Files Changed」标签页快速检查改动并确认自动化 CI 测试通过。3.2 错误修复Bug Fix错误修复应由相关领域的管理者审查最好由批准该 issue 修复的同一人负责使用 PR 的「Files Changed」标签页初步审查修复是否与 issue 讨论一致尽可能在本地测试 PRGitHub CLI 可简化此过程详见后文「提示与技巧」。修复应满足以下检查清单修复应充分解决原 issue除非原 issue 中已达成共识修复不应改变既有行为修复不应显著影响 p5.js 性能修复不应影响 p5.js 的无障碍特性修复应使用现代 JavaScript 标准编写修复应通过所有自动化测试并在相关时包含新测试。若需要其他修改应在相关行添加行级评论可用**建议模块Suggest Change**提出具体修改若需多处修改不要多次添加单行评论而应按照 GitHub 文档使用多行评论并一次性「Request changes」若行级评论仅为澄清或讨论应选择「Comment」而非「Request changes」。PR 审查完毕且无需更多修改时管理者选择「Approve」将 PR 标记为「Approved」可附评论。之后视需要请另一位管理者/维护者复审有合并权限则自行合并否则请维护者合并。应调用 all-contributors 机器人将新贡献者加入 README.md 的贡献者列表。各类贡献类型以[contribution type]占位all-contributors please add [GitHub handle] for [contribution type]3.3 新功能/功能增强New Feature / Feature Enhancement流程与错误修复类似但有一个显著区别新功能/功能增强 PR 在合并前必须由至少 2 位管理者或维护者审查并批准可以是批准原 issue 的同一批人也可以是其他人。3.4 Dependabot 自动依赖更新Dependabot 的 PR 通常只有仓库管理员可见若不适用可直接跳过本节。**补丁版本patch**更新且自动化 CI 测试通过可直接合并**次要版本minor**更新且 CI 通过通常可直接合并但建议快速查看所更新依赖的 changelog**主版本major**更新可能影响构建流程或 p5.js 功能。建议审查从当前版本到目标版本的 changelog并在本地测试 PR 以确保所有流程正常针对依赖的潜在破坏性变更做必要修改。注意很多依赖提升主版本号仅仅是因为停止支持非常古老的 Node.js 版本这并不一定意味着依赖 API 变更带来的破坏性变化。四、构建流程从 Grunt 时代到现代工具链本节不讨论通用构建配置与命令而是聚焦背后发生的事。更详细的构建信息参见 贡献者指南。4.1 历史上的构建任务v1.x原版管理者指南记录了基于 Grunt 的构建体系Gruntfile.js包含 p5.js 及其他内容的主要构建定义使用 Grunt、Browserify、YUIDoc、ESLint、Babel、Uglify、Mocha 等工具。从default任务开始逆向分析最有帮助。default任务grunt.registerTask(default, [lint, test]);执行grunt或 npm 脚本npm test即运行包含lint和test的默认任务。lint任务grunt.registerTask(lint, [lint:source, lint:samples]);lint:source进一步分为eslint:build、eslint:source、eslint:test使用 ESLint 检查构建脚本、源码与测试脚本lint:samples先执行yui任务包含yuidoc:prod、clean:reference、minjson负责从源码提取文档为 JSON、清理未使用文件、压缩为data.min.json再运行自定义任务eslint-samples:source用 ESLint 检查文档示例代码是否符合与 p5.js 其余部分相同的编码标准先执行yui是因为检查示例前需要先构建 JSON 文件。test任务grunt.registerTask(test, [ build, connect:server, mochaChrome, mochaTest, nyc:report ]);build任务browserify负责将大量 p5.js 源文件合并为单一完整库browserify:min构建用于下一步压缩的中间文件区别在于browserify:min不包含 FES 运行所需数据uglify压缩browserify:min输出生成最终 p5.min.jsbrowserify:test构建与完整版相同的库但使用 Istanbul 注入代码覆盖率报告所需的附加代码Browserify 内部还做了几件事用brfs-babel将fs.readFileSync()Node.js 专有代码替换为文件实际内容主要用于 WebGL 代码将独立文件中的着色器代码内联进源码用 Babel 转译 node_modules 依赖源码以匹配 package.json 中按 Browserslist 定义的要求并把 ES6 import 转成 Browserify 可理解的 CommonJSrequire()打包后写盘前还会用pretty-fast清理代码格式保证非压缩版源码可读可引用connect:server启动本地服务器托管测试文件与构建产物供 Chrome 自动化测试使用mochaChrome使用 Puppeteer 启动无头 Chrome远程控制执行./test文件夹中 HTML 文件关联的测试包括未压缩版与压缩版库的单元测试及全部参考示例测试mochaTest在 Node.js 上运行而非 Chrome只测试极少数不需要浏览器环境的库功能——p5.js 大多数功能需要浏览器环境因此仅当新测试确实不需要浏览器时才应扩充此测试集合nyc:report收集mochaChrome对完整版库的测试覆盖率报告并输出到控制台。p5.js 的测试覆盖率主要用于监控与附加数据点目标并非 100% 覆盖率。杂务任务Miscellaneous Tasksnpx grunt [step]可直接运行任意步骤/子步骤/子子步骤但某步骤依赖链上前序步骤时单独运行可能无意义grunt yui:dev构建文档与库后启动 Web 服务器在本地提供类似参考页面的预览http://localhost:9001/docs/reference/并监视源码变更自动重建。处理内联文档时非常有用无需把构建产物搬运到 p5.js-website 仓库即可在浏览器中预览效果但该用法仅限内联文档改动参考页面本身的改动样式、布局仍需在网站仓库中测试grunt watch/grunt watch:main/grunt watch:quick监视一组文件变更并触发相关构建。三者功能相同、范围不同watch在检测到源码变更时运行全部构建与测试相当于完整 default 任务watch:main只构建并测试库、不重建参考文档watch:quick只构建库。按工作内容选择最简化的 watch 任务可节省手动重建时间。4.2 当前构建与测试现状v2.x需要指出的是上述 Grunt/Browserify/Mocha 流水线在 p5.js 2.0 起已被移除英文版指南明确记载了这一变更。从当前仓库的 package.json版本 2.3.1可以核实构建与测试已迁移到现代工具链脚本定义如下scripts: { build: rolldown -c, test: vitest, lint: oxlint ., lint:fix: oxlint --fix ., docs: documentation build ./src/**/*.js ... -o ./docs/data.json node ./utils/convert.mjs, generate-types: npm run docs node utils/typescript.mjs }lint任务v2.x直接通过 npm 脚本使用 ESLint实际仓库使用 oxlint见 eslint.config.mjs 与 .oxlintrc.jsonnpm run lint该命令检查源文件、构建脚本、测试文件与文档示例。若只想对特定文件或目录执行 lint可直接调用npx eslint src/ npx eslint test/v2.x 不再有独立的示例 linter 或基于 YUIDoc 的流水线。test任务v2.x测试系统改用 Vitest通过 npm 脚本运行npm test该命令依次执行ESLint 代码风格检查 → 单元测试 → 视觉测试基于渲染快照的 snapshot 测试。测试位于test/unit目录其结构镜像src目录——例如src/color/p5.Color.js的测试位于 test/unit/color/p5.Color.js视觉测试位于 test/unit/visual。调试时可运行浏览器环境下的交互式测试npx vitest --ui代码覆盖率使用 Vitest 内置工具npx vitest run --coverage从 vitest.config.js 可以看到测试还拆分为常规单元测试与 WebGPU 专项测试两个 project并通过 Playwright 驱动 Chromium 浏览器执行CI 环境下会附加--no-sandbox、--headlessnew等 WebGPU 软渲染参数。五、发布流程Release Processp5.js 的完整发布流程详见 release_process.md。该文档覆盖版本号策略、发布前置检查、构建产物发布、参考文档与类型声明同步等环节管理者在主导或参与发布前务必通读。六、提示与技巧高效维护的实用工具有时需要审查的 issue 和 PR 数量会令人应接不暇。虽然项目已尽量简化流程但仍有不少技巧可以帮助你更高效地审查。6.1 回复模板Saved RepliesGitHub 的 Saved Replies已保存回复功能非常适合此类场景工作流中的某些步骤将问题引导至论坛、接受 issue 修复等需要给出相同或高度相似的回复使用 Saved Replies 能显著提升效率。以下是 p5.js 维护者实际使用的一些 Saved Replies你可以直接使用或创建自己的版本关闭无法复现我们无法复现此问题但如果你能提供展示该问题的代码示例请随时重新打开。谢谢关闭需要代码片段出于组织管理目的我将关闭此问题。如果你能提供说明问题的代码片段请重新打开。谢谢关闭请使用论坛这里的 GitHub issue 适合报告 p5.js 库本身的 Bug 与问题。关于编写你自己的代码、测试或跟随教程的问题请发布在 Processing 官方论坛。谢谢关闭GSOC谢谢讨论 GSOC 提案的最佳地点是我们的论坛Summer of Code 板块。关闭可及性我没有看到该功能能带来很多关注且我们也没有清楚说明它如何「扩大可及性」见 access.md因此我将暂时关闭。如果能在 issue 请求中补充可及性陈述欢迎重新打开。我们没有看到此问题如何「扩大可及性」见 access.md的进一步说明因此暂时关闭此 issue。如果能在功能请求中补充更详细的可及性陈述欢迎重新打开。谢谢关闭插件库我认为此功能超出了 p5.js API 的范围我们尽量保持其最小化但它可能是插件库的良好起点。关于如何创建插件的文档请参见 Creating an Addon Library。关闭 PR请先提交 issue谢谢。提醒一下pull request 打开之前需要先打开 issue并在 PR 中标记该 issue。这对于跟踪开发进度和保持讨论清晰是必要的。谢谢批准 issue 修复你可以继续进行修复。谢谢。合并 PR看起来不错。谢谢6.2 GitHub CLI本地审查复杂 PR审查复杂 PR 时用复杂的 git 命令将 PR 的代码拉到本地测试可能很困难。幸运的是 GitHub CLI 工具能大幅简化此过程。安装 CLI 并登录后本地审查 PR 只需运行gh pr checkout [pull_request_id]该命令会自动完成「获取远程 fork、创建分支、切换分支」的全过程。回到主分支与切换分支相同运行git checkout main即可。你甚至可以直接从 CLI 给 PR 留言完全无需访问网页。GitHub CLI 还提供了许多其他命令是一个值得常备的工具。6.3 管理通知Managing Notifications与其手动刷新仓库的「Issues」或「Pull Requests」标签页来检查新内容不如「Watch关注」仓库——点击仓库页顶部仓库名对侧的带眼睛图标的「Watch」按钮即可。关注仓库后新 issue、新 PR、对你的用户名的提及以及你在该仓库订阅的其他活动都会作为通知发送到 GitHub 通知页面可以像处理电子邮件收件箱一样标记已读或忽略。在某些情况下你还会收到关于所关注仓库活动的 GitHub 邮件可在通知设置页面自定义包括完全退订。将这些设置调整为适合你的工作方式是「手动寻找待审查 issue/PR」与「被 GitHub 无尽通知淹没」之间的关键平衡。作为起步建议管理者应关注本仓库的「Issues」和「Pull Requests」并将邮件通知设置为仅在「参与、提及和自定义」时发送。结语把治理规范落到仓库实处p5.js 的维护体系建立在「issue 先行、双人审批、分类审查、文档与贡献者并重」的共识之上。这套规范在仓库中有迹可循Issue 模板见 .github/ISSUE_TEMPLATEPR 模板见 .github/PULL_REQUEST_TEMPLATE.md领域分工见 stewards.yml构建测试配置见 package.json 与 vitest.config.js。无论是想成为管理者、协助评审他人代码还是希望自己的 PR 更快被合并理解这套流程都能让你在 p5.js 的贡献与维护之路上事半功倍。【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考