Bilibili-Evolved 开源项目 Issue 提交与 Bug 反馈实战指南【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved本指南围绕 doc/issue-rules.md即仓库根目录下维护的《New Issue / Issues 须知》展开系统讲解 Bilibili-Evolved 项目的 Issue 使用规则、Bug 反馈的完整流程、处理优先级与标签语义。读完本文你将掌握如何区分 Issues 与 Discussions 两个板块的用途、如何提交一份能被维护者高效处理的高质量 Bug 报告、仓库内部对 Issue 的四种处置方式与各类标签的含义以及项目为降低沟通成本在仓库中配套提供的模板与工具。先分清两个板块Issues 与 DiscussionsBilibili-Evolved 项目将用户反馈渠道明确拆分为两个独立板块规则默认所有发起者均已了解这一分工Issues仅用于记录 Bug 等发生异常问题的情况Discussions讨论区用于新功能建议、提问与答疑讨论区于 2020-12-10 启用。需要注意两点两个板块的搜索结果是相互独立的——Issues 里搜不到的内容可能能在 Discussions 里搜到反之亦然在讨论区启用2020-12-10之前的新功能建议、提问、答疑讨论仍然保留在 Issues 中可被搜索到历史内容并未被丢弃。仓库中也落实了这一分流机制查看 .github/ISSUE_TEMPLATE/config.yml 可以看到blank_issues_enabled被设置为false不开放空白 Issue并通过contact_links将转到讨论区查看 Issues 须知查看讨论区指南查看置顶问题查看常见问题等入口直接列在新建 Issue 页面引导用户先去对的地方而 .github/DISCUSSION_TEMPLATE/功能建议-ideas.yml 则是讨论区的功能建议模板其顶部同样注明默认您已阅读常见问题解答如果需要反馈 Bug请前往 Issues 发起形成了双向闭环的分流设计。提交前的三项功课在新建 Issue 之前规则要求完成以下检查以避免重复劳动和无意义噪音1. 查看置顶PinnedIssue。当遇到会影响绝大部分用户的情况时维护者会将该 Issue 置顶其中往往包含近期最常见的问题与官方说明务必先看。2. 搜索确认是否已有人汇报。由于每个 Issue 乃至整个项目都是可以订阅通知的对于已经有人汇报过的 Bug如果你也遇到了且没有其他信息可以补充正确的做法是在该 Issue 左下角点个赞reaction 1表示我也遇到而不要新增评论——每一条无信息量的评论都会让所有订阅者收到一封提醒邮件本质上等同于给整个订阅列表发送垃圾邮件这对维护者和其他订阅者都是一种打扰。3. 重复问题直接关闭。若提交的内容与现有 Issue 重复维护者可能提示你已重复也可能不予理会在下一次更新时直接关闭该 Issue带有duplicate标签。一条高质量 Bug 反馈应包含什么Bug 反馈的核心不仅是描述你遇到了什么样的 bug更重要的是总结一套步骤按照这套步骤就能稳定复现该 bug对应模板中的问题描述。其次是环境信息通常包括脚本版本浏览器版本错误信息必要时维护者还会要求导出脚本设置仓库为这些字段提供了标准化的收集入口。查看 .github/ISSUE_TEMPLATE/bug_report.yml 可以发现Bug 反馈模板中所有关键字段均被标记为required: true并逐项给出填写指引模板字段是否必填填写指引对应功能必填指脚本自身的某项具体功能而非 B 站的功能可尝试开启/关闭某功能来排查最好附上功能的 Commit 值在设置里功能选项的底部问题描述必填如何重现此问题、在哪个页面出现视频相关可提供 av / BV 号脚本版本必填在设置面板的关于弹窗中可找到脚本管理器及版本必填例如 Tampermonkey v4.19.6176浏览器及版本必填在浏览器关于页面中可找到播放器日志选填在视频页面时可通过脚本设置面板关于弹窗中的反馈按钮自动带入播放策略必填在 B 站播放器设置 - 更多播放设置 中查看默认 / AV1 / HEVC / AVC错误信息必填脚本直接报告的错误信息或浏览器开发者工具F12 / CtrlShiftIConsole 控制台的输出附加截图选填直接粘贴图片模板中还有一段致遇到了相同问题准备回复的人的固定内容重申太长不看版本的三条规则遇到相同问题用左下角 reaction 点赞、关注进展用 Subscribe 订阅功能、回复前务必确认自己补充了 Log 等新的信息。从源码实现看播放器日志自动带入并非模板文案——feedback.ts见 src/components/settings-panel/sub-pages/feedback.ts中维护了指向新建 Issue 页面的反馈表单地址而 AboutPage.vue 会根据运行环境动态判断feedbackSupported在支持时渲染反馈按钮把播放器日志等调试信息随表单一起带出这正是模板中自动带入能力的落地实现。维护者的四种处置方式与优先级项目对 Bug 反馈的处理方式明确分为四档优先级从高到低给出所有必要信息的反馈尽量尝试重现并修复优先级高于功能请求信息不全或无法重现的有空时追问更多信息争取升级为第 1 种情况没空时可能没有回复但会留意若日后自己遇到会再回来解决——当然你主动补充信息更好只描述 bug 现象、未提供任何其他信息或只写个标题、正文随便放几句话导致无法确定问题所在的不予理会下次更新时直接关闭带有bad-issue标签。除非你有十足把握让其他人一看标题就能明白整个 bug 的来龙去脉否则尽量不要只写标题与现有 Issue 重复的可能提示你重复也可能不予理会下次更新时直接关闭带有duplicate标签。另外需要说明的是Bug 反馈不一定会得到回复。当内容写得非常清晰时维护者会直接加上bug标签表示已确认将会处理不再逐条回复以免造成多余的邮件通知。标签体系从提交到闭环的语义信号文档末尾附上了部分标签含义的解释讨论区功能对应的标签不在其列这是理解 Issue 状态机的一把钥匙标签含义bug确认为 Bug将会处理maybe-bug可能是 Bug待测试验证adaptationB 站的变化导致脚本未跟进适配bad-issue不符合提交规范的 issuecompatibility兼容性问题duplicate重复help-wanted没啥解决思路long-term需要长期开发短时间内无法完成wontfix不予考虑可以看到标签体系覆盖了从提交质量不合格bad-issue、待验证maybe-bug、已确认待处理bug、由站点变化引发adaptation到暂时无法/不打算解决help-wanted、long-term、wontfix的完整生命周期为维护者排定优先级、为社区跟进进展提供了统一的语义信号。正面案例与反面案例的启示文档给出了两组历史案例Issue 编号 #221、#604 为正面例子#562、#564 为反面例子。从中可以提炼的实战要点是正面案例的共同特征提供了可复现的步骤 完整的环境信息脚本版本、浏览器版本、错误信息让维护者可以直接定位问题反面案例的共同特征只描述了现象或只有标题/寥寥数语信息不足以定位问题根源最终走向bad-issue被关闭的结局。配套设施设置面板中的导出/导入与分支策略除了文档本身仓库还提供了与维护者可能需要您导出脚本设置直接对应的功能。查看 src/components/settings-panel/sub-pages/about-page.ts 可知设置面板的关于页内置了exportSettings导出设置与importSettings导入设置两个动作导出设置便于你在反馈时把完整配置随 Issue 一并提供方便维护者复现导入设置则在恢复环境时使用导入成功后会有导入成功正在刷新页面的 Toast 提示。这解释了文档中有时候我可能还会需要您导出脚本设置这一要求的实现路径。此外从仓库的自动化脚本 .github/scripts/auto-publish-classify.mjs 可以看出项目在发布流程上维护了preview-fixes、preview-features、preview、master、master-cdn等多条分支并通过分类脚本判断改动是否影响脚本构建产物来决定是否自动发布——这从侧面说明用户在反馈时提供的功能 Commit 值与脚本版本正是维护者跨分支定位问题出在哪个版本的重要线索也再次印证了填写模板字段的必要性。小结一份合格的 Bilibili-Evolved Bug 反馈本质上是可复现步骤 环境信息 错误信息三要素的完整组合配合提交前的搜索与置顶检查、以及点赞代替无意义评论的社区礼仪就能让维护者以最高效率处理你的问题。Issue 处理流程修复优先、追问补全、无效关闭、重复关闭与九类标签共同构成了一套闭环的反馈治理机制而这套机制在仓库中的具体载体正是 doc/issue-rules.md 连同 .github/ISSUE_TEMPLATE/bug_report.yml、.github/ISSUE_TEMPLATE/config.yml 与设置面板的导出/反馈工具链。【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Bilibili-Evolved 开源项目 Issue 提交与 Bug 反馈实战指南
Bilibili-Evolved 开源项目 Issue 提交与 Bug 反馈实战指南【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved本指南围绕 doc/issue-rules.md即仓库根目录下维护的《New Issue / Issues 须知》展开系统讲解 Bilibili-Evolved 项目的 Issue 使用规则、Bug 反馈的完整流程、处理优先级与标签语义。读完本文你将掌握如何区分 Issues 与 Discussions 两个板块的用途、如何提交一份能被维护者高效处理的高质量 Bug 报告、仓库内部对 Issue 的四种处置方式与各类标签的含义以及项目为降低沟通成本在仓库中配套提供的模板与工具。先分清两个板块Issues 与 DiscussionsBilibili-Evolved 项目将用户反馈渠道明确拆分为两个独立板块规则默认所有发起者均已了解这一分工Issues仅用于记录 Bug 等发生异常问题的情况Discussions讨论区用于新功能建议、提问与答疑讨论区于 2020-12-10 启用。需要注意两点两个板块的搜索结果是相互独立的——Issues 里搜不到的内容可能能在 Discussions 里搜到反之亦然在讨论区启用2020-12-10之前的新功能建议、提问、答疑讨论仍然保留在 Issues 中可被搜索到历史内容并未被丢弃。仓库中也落实了这一分流机制查看 .github/ISSUE_TEMPLATE/config.yml 可以看到blank_issues_enabled被设置为false不开放空白 Issue并通过contact_links将转到讨论区查看 Issues 须知查看讨论区指南查看置顶问题查看常见问题等入口直接列在新建 Issue 页面引导用户先去对的地方而 .github/DISCUSSION_TEMPLATE/功能建议-ideas.yml 则是讨论区的功能建议模板其顶部同样注明默认您已阅读常见问题解答如果需要反馈 Bug请前往 Issues 发起形成了双向闭环的分流设计。提交前的三项功课在新建 Issue 之前规则要求完成以下检查以避免重复劳动和无意义噪音1. 查看置顶PinnedIssue。当遇到会影响绝大部分用户的情况时维护者会将该 Issue 置顶其中往往包含近期最常见的问题与官方说明务必先看。2. 搜索确认是否已有人汇报。由于每个 Issue 乃至整个项目都是可以订阅通知的对于已经有人汇报过的 Bug如果你也遇到了且没有其他信息可以补充正确的做法是在该 Issue 左下角点个赞reaction 1表示我也遇到而不要新增评论——每一条无信息量的评论都会让所有订阅者收到一封提醒邮件本质上等同于给整个订阅列表发送垃圾邮件这对维护者和其他订阅者都是一种打扰。3. 重复问题直接关闭。若提交的内容与现有 Issue 重复维护者可能提示你已重复也可能不予理会在下一次更新时直接关闭该 Issue带有duplicate标签。一条高质量 Bug 反馈应包含什么Bug 反馈的核心不仅是描述你遇到了什么样的 bug更重要的是总结一套步骤按照这套步骤就能稳定复现该 bug对应模板中的问题描述。其次是环境信息通常包括脚本版本浏览器版本错误信息必要时维护者还会要求导出脚本设置仓库为这些字段提供了标准化的收集入口。查看 .github/ISSUE_TEMPLATE/bug_report.yml 可以发现Bug 反馈模板中所有关键字段均被标记为required: true并逐项给出填写指引模板字段是否必填填写指引对应功能必填指脚本自身的某项具体功能而非 B 站的功能可尝试开启/关闭某功能来排查最好附上功能的 Commit 值在设置里功能选项的底部问题描述必填如何重现此问题、在哪个页面出现视频相关可提供 av / BV 号脚本版本必填在设置面板的关于弹窗中可找到脚本管理器及版本必填例如 Tampermonkey v4.19.6176浏览器及版本必填在浏览器关于页面中可找到播放器日志选填在视频页面时可通过脚本设置面板关于弹窗中的反馈按钮自动带入播放策略必填在 B 站播放器设置 - 更多播放设置 中查看默认 / AV1 / HEVC / AVC错误信息必填脚本直接报告的错误信息或浏览器开发者工具F12 / CtrlShiftIConsole 控制台的输出附加截图选填直接粘贴图片模板中还有一段致遇到了相同问题准备回复的人的固定内容重申太长不看版本的三条规则遇到相同问题用左下角 reaction 点赞、关注进展用 Subscribe 订阅功能、回复前务必确认自己补充了 Log 等新的信息。从源码实现看播放器日志自动带入并非模板文案——feedback.ts见 src/components/settings-panel/sub-pages/feedback.ts中维护了指向新建 Issue 页面的反馈表单地址而 AboutPage.vue 会根据运行环境动态判断feedbackSupported在支持时渲染反馈按钮把播放器日志等调试信息随表单一起带出这正是模板中自动带入能力的落地实现。维护者的四种处置方式与优先级项目对 Bug 反馈的处理方式明确分为四档优先级从高到低给出所有必要信息的反馈尽量尝试重现并修复优先级高于功能请求信息不全或无法重现的有空时追问更多信息争取升级为第 1 种情况没空时可能没有回复但会留意若日后自己遇到会再回来解决——当然你主动补充信息更好只描述 bug 现象、未提供任何其他信息或只写个标题、正文随便放几句话导致无法确定问题所在的不予理会下次更新时直接关闭带有bad-issue标签。除非你有十足把握让其他人一看标题就能明白整个 bug 的来龙去脉否则尽量不要只写标题与现有 Issue 重复的可能提示你重复也可能不予理会下次更新时直接关闭带有duplicate标签。另外需要说明的是Bug 反馈不一定会得到回复。当内容写得非常清晰时维护者会直接加上bug标签表示已确认将会处理不再逐条回复以免造成多余的邮件通知。标签体系从提交到闭环的语义信号文档末尾附上了部分标签含义的解释讨论区功能对应的标签不在其列这是理解 Issue 状态机的一把钥匙标签含义bug确认为 Bug将会处理maybe-bug可能是 Bug待测试验证adaptationB 站的变化导致脚本未跟进适配bad-issue不符合提交规范的 issuecompatibility兼容性问题duplicate重复help-wanted没啥解决思路long-term需要长期开发短时间内无法完成wontfix不予考虑可以看到标签体系覆盖了从提交质量不合格bad-issue、待验证maybe-bug、已确认待处理bug、由站点变化引发adaptation到暂时无法/不打算解决help-wanted、long-term、wontfix的完整生命周期为维护者排定优先级、为社区跟进进展提供了统一的语义信号。正面案例与反面案例的启示文档给出了两组历史案例Issue 编号 #221、#604 为正面例子#562、#564 为反面例子。从中可以提炼的实战要点是正面案例的共同特征提供了可复现的步骤 完整的环境信息脚本版本、浏览器版本、错误信息让维护者可以直接定位问题反面案例的共同特征只描述了现象或只有标题/寥寥数语信息不足以定位问题根源最终走向bad-issue被关闭的结局。配套设施设置面板中的导出/导入与分支策略除了文档本身仓库还提供了与维护者可能需要您导出脚本设置直接对应的功能。查看 src/components/settings-panel/sub-pages/about-page.ts 可知设置面板的关于页内置了exportSettings导出设置与importSettings导入设置两个动作导出设置便于你在反馈时把完整配置随 Issue 一并提供方便维护者复现导入设置则在恢复环境时使用导入成功后会有导入成功正在刷新页面的 Toast 提示。这解释了文档中有时候我可能还会需要您导出脚本设置这一要求的实现路径。此外从仓库的自动化脚本 .github/scripts/auto-publish-classify.mjs 可以看出项目在发布流程上维护了preview-fixes、preview-features、preview、master、master-cdn等多条分支并通过分类脚本判断改动是否影响脚本构建产物来决定是否自动发布——这从侧面说明用户在反馈时提供的功能 Commit 值与脚本版本正是维护者跨分支定位问题出在哪个版本的重要线索也再次印证了填写模板字段的必要性。小结一份合格的 Bilibili-Evolved Bug 反馈本质上是可复现步骤 环境信息 错误信息三要素的完整组合配合提交前的搜索与置顶检查、以及点赞代替无意义评论的社区礼仪就能让维护者以最高效率处理你的问题。Issue 处理流程修复优先、追问补全、无效关闭、重复关闭与九类标签共同构成了一套闭环的反馈治理机制而这套机制在仓库中的具体载体正是 doc/issue-rules.md 连同 .github/ISSUE_TEMPLATE/bug_report.yml、.github/ISSUE_TEMPLATE/config.yml 与设置面板的导出/反馈工具链。【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考