社区意见调查:基底、方法与边界

[Minecraft269]

草稿不包含任何结论。所有结论由本讨论的参与者在回应开放式问题时自行提出。
本文由 AI 生成。
注:本讨论范围限于有争议性的 PR/issue 的去留问题,欢迎各社区的玩家与开发者提出建议(多渠道意见收集见第六节)。
说明:本讨论由社区成员起草,不代表 HMCL 维护团队的官方立场。
本调查草稿用于替换讨论 #6062 的原有内容,作为其修订版正文(2.3 节所记录的是该讨论修订前的原始内容)。

---

一、背景

本节只陈述事实。

2025 年 9 月至 2026 年 8 月期间,HMCL 仓库中出现了若干条相互关联的公开讨论、PR 与 issue,主题涉及:

• 新功能的实现路径:设置界面开关还是配置文件(#4375、#5812、#5653、#6062);
• 仓库维护流程:PR/issue 的标签体系、贡献指南、合并节奏(#4921、#6602);
• AI 生成内容(AI slop)与 spam PR 的处置(#6598;相关背景事件 修复多个Bug: macOS主题跟随、Linux更新、模组UI对齐、不兼容提示、文件占用回滚 #6575、fix: JFXPopup hide()空指针保护 & 其他稳定性改进 #6576 见 2.1)。

这些讨论与 PR 之间存在直接引用关系(例如讨论 #6062 引用 PR #5812 与 #5653;讨论 #6598 的评论指向 issue #6602 与讨论 #4921)。

在以上讨论中,贡献指南与 AI 使用规则的状态被多次提及(以下均为原文摘录,不构成整理者的判断):

• 讨论 是否应该自动关闭新贡献者的 PR？ #6598 评论:"目前的 Contributing.md 并不算正式的贡献指南,没有一个明确的标准和指南"(来源,3gf8jv4dv);
• issue [Feature] [Doc] 更新贡献指导 #6602 原帖:"现在的 Contributing.md 只是作为对环境配置和一些变量的介绍,对 PR 贡献不具有指导意义"(来源,ToobLac);
• 讨论 关于改进 HMCL 仓库维护的意见 #4921 评论:"修订 Contributing 文档,明确 PR 的标题、正文、commit message 格式、AI 使用披露、AI review 规则等"(来源,3gf8jv4dv)。

本次调查的动机:将这些已公开发生的讨论材料原样整理为一份基底,列出调查方法与边界,供社区在统一的信息基础上回应开放式问题。本调查不归集任何结论。

---

二、调查基底

说明

以下内容为材料的整理,不是结论的凝练。每条观点保留原貌并标注来源链接与作者。凡引文为转述或改写之处,均已注明。材料整理的时间点为 2026-08-14;此后发生的评论不在本基底内。

2.1 讨论 #6598「是否应该自动关闭新贡献者的 PR?」

基本信息

• 发起人:Glavo(仓库成员/MEMBER);发起时间:2026-08-03T11:37:39Z;分类:日常闲聊 | General
• 原帖反应:共 16 个(👍 1、👎 5、🤔 3、👀 7)
• 评论:5 条;评论者:3gf8jv4dv、MoYuan-CN、fatelove42、Minecraft269(2 条)

原帖主张(Glavo, 来源)

"我在考虑是否要借鉴 pi 的贡献者策略,自动关闭所有新贡献者的 PR,我们再从中选择有意义的 PR 开放。"

理由如下:

1. 当前环境下有大量 AI Agent 全自动化投递无意义的 PR,这些 PR 会污染 PR 列表。
2. HMCL 仓库时不时会遭到 bot 攻击,部分 bot 会投递大量有害 PR 来污染仓库。
3. 手动 reopen 有意义的 PR 可以给真实贡献者正面的反馈,告诉他我们正在关注此 PR,只是暂时没有精力审查。

我想征求一下大家的意见,看看大家的看法。

各方回应

1. 3gf8jv4dv(贡献者,2026-08-03,评论获 👍 10) — 要点(原文摘录,来源):

   • "目前 HMCL 并不是每天都会收到大量 spam。如果真的和一些项目类似,每天有大量 spam,那听起来还比较合理,但现在还没到一定的阈值。"
   • "我感觉这个提议,是因为最近两天突然有俩用户共提交了四个疑似 spam PR 而引发的。说直白点,感觉像「应激」了,而不是深思熟虑后发起的提议。我认为这两条理由比较牵强。"
   • "与其如此,不如添加合适的 label,这样更能给「真实贡献者」正面反馈。"
   • "「有意义的 PR」的解释权在哪里呢?目前的 Contributing.md 并不算正式的贡献指南,没有一个明确的标准和指南。"
   • "如无必要,勿增实体。我认为,不到不得已,不应该祭出这样的规则。"
   • "至少,先打好基础,把 Contributing.md 给拎清楚。目前确实没有一个明确的规则说「你不能用 AI 生成后直接提交」……我还愿意相信「AI slop」中的一部分,是没看到明确的规则而产生了侥幸心理,而不是主观恶意。"

2. MoYuan-CN(2026-08-03) — "可以做一个 Label 来标识这个 PR 已经通过了早期预审查,如果十分钟内之内没有人挂上已经预审查了的标签,则自动关闭这些 First-Time Contributor 的 PR"(预审查指"和代码逻辑、质量等影响最终合并无关的,仅针对 PR 本身是否为 AI slop 或无意义内容的检查")。来源

3. fatelove42(2026-08-03,评论获 😂 3、👀 1) — "我是用的ai啊但是都是测试后手动pr的,请问对审核造成压力了吗😭,我想如果提出feature request要等好久就自己用ai修了"。来源

4. Minecraft269(2026-08-03,评论获 👍 1) — 要点(原文摘录,来源):

   • "现在 不是「是否应该自动关闭新贡献者的 PR?」的问题 现在是目前的HMCL规则不完善的问题"……"Contributing.md 里面其实没有什么东西 仅仅只是说明了怎么部署以及「调试选项」";
   • 引用 issue #6602 中 3gf8jv4dv 的评论:"而且也要对维护者有一些约束。"——"是的 不仅仅是要对贡献者进行一些约束 更要对维护者自身增加一些约束(公开透明 而不是维护者临时说什么就是什么 还有PLAN 计划板块(文件/issue/pr(而且现在不是有堆叠PR了吗 这样可以将规划的东西堆叠到一个PR进行统一回复 讨论 #6548)/discussion 防止出现类似于 feat: 添加自定义标题栏设置 #5653 此类情况发生))"(引文括号的配对情况与原文一致);
   • "防止出现类似于 feat: 添加自定义标题栏设置 #5653 此类情况发生";
   • "当前情况看起来就是 Glavo「应激」了 而不是目前的仓库的根本问题 3gf8jv4dv 已经说的很详细了"。

5. Minecraft269(2026-08-13) — "相关讨论 : https://github.com/HMCL-dev/HMCL/discussions/4921"。[来源](https://github.com/HMCL-dev/HMCL/discussions/6598)

维护者回应与处置

• 原帖本身由维护者 Glavo 发起(见上)。截至 2026-08-14,原帖下无维护者的进一步回复;相关的后续行动发生在 issue #6602(见 2.5.2)。
• 背景事实(不纳入调查议题):是否应该自动关闭新贡献者的 PR？ #6598 发起前一日(2026-08-02),仓库关闭了两个疑似 AI 生成的 spam PR(#6575、#6576;作者账号显示为 ghost,即已删除账号)。Glavo 在 #6576 中说明处置理由:"把其他 PR([Bugfix] 修复 #6526: macOS 下 主题模式-跟随系统设置 失效 #6555)的修改拉进自己的 PR 里装作是自己的东西""目测人类含量 0%……我决定屏蔽此账号,如果有异议可以对我发起申诉"。是否应该自动关闭新贡献者的 PR？ #6598 评论中 3gf8jv4dv 所述"最近两天突然有俩用户共提交了四个疑似 spam PR"与该时段事件存在对应关系(该表述为评论者观点,公开可见的记录仅有上述两个 PR,本基底不进行认定)。

2.2 讨论 #4921「关于改进 HMCL 仓库维护的意见」

基本信息

• 发起人:WhatDamon(贡献者);发起时间:2025-12-05T05:14:06Z;分类:日常闲聊 | General
• 原帖反应:共 14 个(全部为 👍)
• 评论:3 条;评论者:3gf8jv4dv(2026-06-29)、ToobLac(2026-07-03)、TheWhiteDog9487(2026-07-19)

原帖主张(WhatDamon,来源)

1. 引入自动关闭骚扰信息的工作流:
   • "2025年11月29日,本仓库遭到了某用户的骚扰"……"经过举报后,GitHub对此账户采取了措施"……"两个Issue也被删除";
   • "可以尝试引入 JohnsonRan/nomore-spam 工作流,自动关闭这类Issue(删除建议在完成举报后再手动操作)"。
2. 为每个 Issue 添加标签:
   • "目前本项目 Issue 常用标签只有两个:enhancement、bug",导致难以检索、难以了解优先级、难以吸引新贡献者;
   • 建议添加 platform:/arch:/priority:/future/good first issue/area: 等标签(原帖给出了具体取值列表)。

各方回应

1. 3gf8jv4dv(贡献者,2026-06-29,评论获 👍 14) — 要点(原文摘录,来源):

   • "目前只有 Glavo 一个人持续推送、合并代码。但是,我感觉摸不出 Glavo 合并 PR 的规律。有一些规模小、看起来没啥大分歧的 PR 能晾好几天甚至数周。有的 PR 放了很久,本以为能合并时,突然被 Glavo 质疑。有的 PR 合并后突然又被撤回。";
   • "PR 页面目前没有一个条目附带 label,而且 PR 的标题、内容可谓是「五花八门」"(列举:中英文混杂、commit 风格不一、只带 issue 编号、评论多但"不断召唤 AI"、"AI 一把梭、看都不看直接发出"等);
   • "如果 HMCL 的 PR 合并策略继续这样下去……一些人可能心灰意冷,甚至质疑、攻击 Glavo 和 HMCL 社群。一些人可能要不断 merge / rebase 自己的分支,心力交瘁。";
   • 建议:① "修订 Contributing 文档,明确 PR 的标题、正文、commit message 格式、AI 使用披露、AI review 规则等";② "仿照 SJMCL,添加一个 action workflow,为新老 PR 打上 label 标记其规模"(链接到 SJMCL 的 pr-size-label.yml);
   • "对于 HMCL 的 issue 管理,我认为 WhatDamon 已经说的很详细了,没啥补充的"。

2. ToobLac(2026-07-03,评论获 👍 4) — "个人认为 PR 也需要 issue 类似的标签,其中一部分是贡献者可自选的,另一部分是只有项目成员可以为 PR 设置的"。来源

3. TheWhiteDog9487(2026-07-19,评论获 👍 1) — "PCL那边的情况看着就要舒服得多,最主要的两个标签 当前状态 和 处理优先级 都有,一眼扫过去就能知道大致情况"。来源

维护者回应与处置

• 截至 2026-08-14,原帖与评论下未见维护者的回复记录。

2.3 草稿讨论 #6062「[社区民意调查] PR 的去留问题与真实的民意意见」

注:本节记录的是本讨论(6062)在本次修订前的原始内容;本次修订以本调查草稿替换了该讨论的原有正文。

基本信息

• 发起人:Minecraft269;发起时间:2026-05-04T11:03:47Z;分类:日常闲聊 | General
• 原帖反应:共 5 个(👎 1、👀 4)
• 评论:0 条(截至 2026-08-14 查询时)
• 原帖自述:"注: 此Discussion为非官方提出 请注意分别"、"以下为AI生成"、文末附 DeepSeek 分享链接

原帖内容(Minecraft269,来源)

• 指出现象:"之前有好几个关于界面自定义的 PR 被关闭了,比如隐藏帮助按钮、自定义标题栏等。关闭原因各不相同,但大多指向同一个方向:维护者倾向于用配置文件来实现这类功能,而不是在设置界面里加开关。"
• 引用两条评论(注意:原帖标注"以下为AI生成",其引文为压缩改写版本,与 PR 内的原始评论措辞不完全一致,对照阅读见 2.4.2):
  1. 引用 Minecraft269 的观点(与 PR #5653 评论 为同一人的近似观点):"HMCL 是一个社区驱动的启动器……它的最终服务对象是每一位使用它的玩家,包括那些刚接触电脑、想玩 Minecraft 却不知道怎么改配置文件的新手。""用户的需求应该能直接在软件内表达,而不是被赶到外部去。"
  2. 引用 3gf8jv4dv 的观点(与 PR #5653 评论 大意对应,但措辞不同):"项目方向通常是维护者基于技术认知和路线图设定的……这类 PR 的去留不应该由一个 community poll 来决定。维护者有权利基于技术判断和项目方向做出决定,我们应该尊重。"
• 提出 4 个讨论问题:① 新功能实现路径(设置界面 UI 还是配置文件)如何取舍;② "配置文件对新手不友好"这一观点如何看;③ 维护者决定方向与社区诉求如何平衡;④ 未来类似 PR 是否有更清晰的指引避免贡献者浪费精力。
• 原帖结尾:"这个讨论的目的是为未来类似 PR 的处理找出一个更清晰的原则,让大家减少冲突和重复工作,不是针对某个具体的 PR 或贡献者。"

回应缺失情况

• 该讨论自发布(2026-05-04)至本次查询(2026-08-14)没有收到任何评论;5 个反应中 1 个为 👎。原帖正文所引两条 PR 评论的完整原文见 2.4.2。

2.4 草稿 #6062 引用的两个 PR

2.4.1 PR #5812「添加隐藏标题栏"帮助"按钮的选项」

基本信息

• 作者:WhatDamon(贡献者);创建:2026-03-20T14:50:47Z;关闭:2026-03-30T13:29:41Z(由 Glavo 关闭);未合并
• 规模:1 commit、+26 行、6 个文件;正文为空;无 review、无行内审查评论;仅 1 条 PR 评论

维护者回应与处置

• Glavo(2026-03-21,来源) — "未来如果我们新增了针对整合包/包管理器的配置文件的话可以考虑允许用户通过配置文件来控制这个按钮,但我认为在设置中添加这样的选项没有意义。"
• 该评论发布 9 天后(2026-03-30)PR 被关闭。关闭时无其他讨论记录。

2.4.2 PR #5653「feat: 添加自定义标题栏设置」

基本信息

• 作者:MinecraftYJQ(贡献者);创建:2026-02-26T06:33:06Z;关闭:2026-04-01T13:17:48Z(由 Glavo 关闭,与 Glavo 最后一条评论同一时刻);未合并
• 规模:4 commits、+76 −2 行、7 个文件;9 条 PR 评论;1 次 formal review(CiiLu,状态 COMMENTED,2026-02-26)+ 1 条行内审查评论(标题栏颠倒显示效果)

讨论过程(按时间顺序)

以下各条为引文与转述混排:引号内为原文摘录,未加引号的连接语为整理者转述。

1. 3gf8jv4dv(2026-02-26,来源) — "我记得 Glavo 在 issue #4375 里提到过要做这个。"
2. WhatDamon(2026-03-03,评论获 ❤ 1,来源) — 设计批评:"我并不认为将版本标签单独分出来并添加背景是好的,一方面这违反了 Material 设计规范……当前修改会导致这个标签比「启动游戏」更加容易强占用户的视觉重点""并且当前实现并未考虑开启透明标题栏后的视觉效果";建议"使用莫奈调色板进行视觉元素弱化"。
3. Glavo(2026-04-01 13:17:48,评论获 🤔 1,来源) — "我们希望能够通过配置文件让用户能够调整这些内容。"——同一时刻(13:17:48)PR 被关闭。
4. Minecraft269(2026-04-03,评论获 👎 4,来源) — 长文(自述为 AI 生成,附原始内容与 DeepSeek 分享链接),要点:HMCL 是社区驱动的启动器;设置界面直接调整对新手友好("不需要打开文件管理器,不需要找 .hmcl 文件夹,不需要知道 JSON 格式怎么写");配置文件方案(指 [Feature] 增强启动器的可定制性 #4375)的三个问题(新手不友好、只读配置"等于告诉用户:你不够格,请用专业工具"、两者可以共存);"为什么不继续推进这个 PR,而是把它关掉?";"如果连用户一个小小的、已经有了实现的需求都拒绝合并,那它跟闭源的「开发者施舍给用户」有什么区别?"
5. 3gf8jv4dv(2026-04-03,评论获 👍 5、❤ 2,来源) — 回应,要点:认可 Minecraft269 关于新手友好、只读配置门槛、两种方式共存的论点;批评其"后半部分(其他 AI)……像是一篇命题作文或演讲稿";"你能声明使用了 AI,这是个好事,也值得鼓励";"开发者(维护者)、贡献者、用户是平等的,基于兴趣和共识驱动的。很多开源协议——包括 HMCL 的 GPLv3——都有一段免责声明,表明软件「按原样提供」「不提供担保」。开发者并非服务员,用户也不是消费者";"在目前主流的开源社群实践中,维护者通常是拥有最高决策权的,是完全有权利拒绝他/她不满意、不认同的反馈和意见的";"遇到一些重大的分歧时,一个常见的做法就是 fork。Forge > NeoForge、MultiMC > PolyMC > Prism Launcher、PCL > PCL CE 等就是鲜明的例子";"坦白讲,难免让人感受到一种「道德绑架」的压力";"如果维护者们出现了「头脑一热」而合并/拒绝的情况,我也支持各位去批评(例如 PR #4828 的评论)"。
6. Minecraft269(2026-04-04,评论获 😂 3、👀 2,来源) — 致歉并修正立场:"我之前的措辞(「如果连用户小小的需求都拒绝合并,那跟闭源有什么区别」)确实过激了,听起来像在逼宫。这不是我的本意,我向你、向 Glavo 和其他维护者道歉";同时保留部分诉求:"能不能开一个 Discussion,把 [Feature] 增强启动器的可定制性 #4375 的设计思路、feat: 添加自定义标题栏设置 #5653 的实现、以及大家对标题栏自定义的真实需求放在一起讨论?";并说明"以上所有的答复"来自 DeepSeek 分享链接。
7. burningtnt(仓库成员,2026-04-04,来源) — "这个功能应该是给整合包作者或第三方打包用的,普通用户不应该碰这个东西"。
8. MinecraftYJQ(PR 作者,2026-04-04,来源) — "我认为普通用户也可以使用这个功能,而不是仅局限于第三方打包;其次,既然都使用了配置文件来启用部分功能,那配置文件内是否可以设置是否启用用户自定义标题呢,而不是直接限定只有第三方打包可以使用"。
9. WhatDamon(2026-04-04,评论获 ❤ 6,来源) — 要点:此功能与 添加隐藏标题栏“帮助”按钮的选项 #5812 相似、同因关闭;"我依旧坚信用户应当有足够的掌控力去控制启动器的多数选项,特别是个性化选项";"HMCL 在几年前关闭旧联机的公告中说到各启动器开发者都是以玩家心去开发启动器";"HMCL 多数玩家并不像看这条 Comment 的各位一样懂计算机,编辑配置很容易出现语法错误导致序列化出现问题(特别在使用记事本等纯文本编辑器时),不然也不会有请求诊断游戏崩溃不提供日志只是截张图的人了";"HMCL 作为一个开源项目离不开社区支撑,相关决策我觉得应该保持开放";"使用 QQ 群聊进行收集和公开我觉得不应该被定义为开放透明,因为许多未加入群聊的用户并不能知晓相关计划……综合而言上述的 Discussions 显然是更恰当的选择";"这也契合 GPLv3 的自由理念,即便这样短期内或许会导致维护压力的增加,我也相信这样操作以长远视角看有利于 HMCL 的可持续的健康发展"。

维护者回应与处置(汇总)

• Glavo 以一条评论(配置文件方向)与同步关闭 PR 作为处置;此后未在 PR 内进一步回应(截至 2026-08-14)。
• burningtnt(仓库成员)对功能定位提出意见(面向整合包作者/第三方打包)。

2.5 与上述主题相关的已关闭 PR、关联 issue

2.5.1 已关闭 PR 一览

A. PR #4828「[Feature] 模组等的更新日志以及 HTMLRenderer 的完善」(Calboot)

• 时间:2025-11-19 创建 → 2026-05-01 关闭(操作者为 burningtnt);未合并;规模 +796 −148 行、23 个文件、126 commits、46 条评论
• 背景:该 PR 目标为"在 HMCL 内展示(即渲染)更新日志"。审查过程中出现大量 AI 审核机器人的行内评论(copilot-pull-request-reviewer、chatgpt-codex-connector、gemini-code-assist),以及维护者与作者的长期往返讨论。
• 关键对话(来源):Glavo "为什么要在 HMCL 里渲染这个更新日志?我没有看出必要性。我认为点击按钮后在浏览器里查看就可以了";3gf8jv4dv "如果你一开始就是这么想的话,就应该早一点,在去年 11 月 PR 提交后的一段时间里就提出,而不是在 PR 滞留数月,甚至分配给 Copilot 审核的几周后,又给出这个结论";Calboot "现在国内访问 Modrinth 和 CF 都会卡好半天才加载好,体验远不如 HMCL 几乎瞬间渲染完成"。
• 关闭原因:该 PR 的关闭并非由上述讨论得出结论所致;自 2026-04-17(Glavo 在 PR 内调用 codex 审查)之后,PR 内不再有新的处理,直至 2026-05-01 被关闭,关闭时无说明性评论。据草稿作者在起草时核实的信息,该 PR 的关闭与作者 Calboot 的账号被 GitHub 封禁有关(注:GitHub 不公开封禁记录,该信息无法通过公开 API 独立回溯)。
• 后续:作者于 2026-05-14 注册新账号 ToobLac,并于 2026-05-16 以同一功能内容重新提交 PR(即下列 B 项,正文与 [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828 一致并标注 "Reference: [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828")。
• 该 PR 被 3gf8jv4dv 在 PR #5653 评论 中引用,作为"维护者出现「头脑一热」而合并/拒绝时,支持各位去批评"的例子。

B. PR #6098「[Feature] 模组等的更新日志以及 HTMLRenderer 的完善」(ToobLac)—— 同一功能的重新提交

• 时间:2026-05-16 创建 → 2026-08-05 合并(Glavo);23 条评论
• 关系说明:该 PR 与 [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828 为同一功能内容(正文一致,标注 "Reference: [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828");作者 ToobLac 的账号创建于 2026-05-14,即 [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828 关闭(2026-05-01)后 13 天。据草稿作者核实,ToobLac 为 [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828 作者 Calboot 的后续账号。
• 讨论过程要点:Glavo 多次在 PR 内调用 AI 审查("gemini review"、"codex review");3gf8jv4dv 参与实测反馈("拉锯战"、指出 Fresh Animations/Collective 更新日志的渲染问题);3gf8jv4dv 表示"如果没有维护者难以接受的问题,这个 PR 应该尽早合并到开发版里供大伙试用"(来源);2026-08-05 合并。
• 该 PR 与 [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828 主题相同(更新日志渲染),结果不同(合并 vs 关闭),故一并列出供对照。

2.5.2 关联 issue 与讨论

issue #4375「[Feature] 增强启动器的可定制性」(Glavo)

• 创建:2025-09-01;状态:打开(enhancement);获 👍 4;3 条评论
• 内容(来源):允许用户(尤其是整合包作者)在不修改源码的情况下配置启动器更多功能,包括:
  1. 新的只读配置文件 ./.hmcl/config.json(与 hmcl.json 不同,用户无法在 HMCL 内修改,只能通过外部编辑器创建),可配置:更新源、右上角「帮助」按钮的链接、左下角「官方群组」按钮的链接、启动器的标题、首次打开时的弹出公告;
  2. ./.hmcl 中新的可选文件:icon.png(替换标题栏图标)、java//default(启动器用 Java);
  3. 为 HMCLauncher 提供 Lite HMCLLauncher 模式(hmcl.jar 独立存放,便于定制 exe 图标并保留自动更新)。
• 评论:Glavo 曾对垃圾评论者发布限时解释警告(来源);zkitefly 建议"或许也可以增加禁用、隐藏部分页面的入口?"(来源);WhatDamon 提供了示例 config.json(含 titlebar 的 title/icon/extra_item/show_version/show_help/show_window_controls 等可配置项,来源)。

issue #6602「[Feature] [Doc] 更新贡献指导」(ToobLac)

• 创建:2026-08-03;状态:打开(enhancement);获 👍 4、👀 2;7 条评论
• 内容(来源):更新贡献指导,使其"对 PR 的提出与推进具有约束与指导意义,并能成为维护者处理 spam PR 的根据";原帖称"现在的 Contributing.md 只是作为对环境配置和一些变量的介绍,对 PR 贡献不具有指导意义。同时随着 AI Code Agent 的发展,HMCL 仓库中涌现出一大批纯 vibe 的无效 PR";并引用 讨论 #4921 中 3gf8jv4dv 的评论作为 PR 格式参考。原帖结尾注明"以上内容全都不是 AI 生成的"。
• 评论要点(引号内为原文摘录):3gf8jv4dv"Contributing.md 不仅局限于贡献者(包括 issue 和 PR 作者),而且也要对维护者有一些约束"(来源,获 👍 4)并称"我抽时间尽早起草一个草稿吧"(来源);TheWhiteDog9487"除非绝对必要,否则这种文档不应该过于冗长"、"看到总共三十多个规则还是直接把我这个没参与过贡献的人吓跑了"(来源);ToobLac"严肃性我觉得还是要有的,但是严肃也不代表要冗长……要让阅读者能感受到这是一份有效力的文件,类似社区公约"(来源);WhatDamon 提出 AI 贡献政策框架(接受 AI 但非无条件、Human-in-the-loop、提交者负责、质量高于数量并定义 Slop;引入轻度提醒→严重警告→限制贡献→公示的递进惩罚机制;AI 工具披露倾向 PR 层面;以上原则"应同时适用于维护者,而非单一限贡献者"),并注明其思路整理使用 DeepSeek V4 Flash 0731(来源)。

讨论 #6548「堆叠 PR (Stacked pull requests)」(3gf8jv4dv)

• 创建:2026-07-30;获 4 个反应;1 条评论
• 内容:转发 GitHub 官方公告《Stacked pull requests are now in public preview》,称"对大型 PR 来说似乎有用?";ToobLac 评论"这可太有用了,要不然我每个大型 pr 都要解决一堆自己写出来的 merge conflict"(来源)。
• 该讨论被 Minecraft269 在 讨论 #6598 的评论 中引用(建议以堆叠 PR 承载规划内容)。

2.6 各数据源中存在的直接分歧(仅记录分歧存在)

• 自动关闭新贡献者 PR 与否:Glavo 的提议(见 2.1 原帖)与 3gf8jv4dv、Minecraft269 的反对意见(阈值不足、应激反应、应规则先行)构成分歧;MoYuan-CN 提出中间方案(预审查 label)。
• 功能实现路径:维护者(Glavo)主张经配置文件实现(见 添加隐藏标题栏“帮助”按钮的选项 #5812、feat: 添加自定义标题栏设置 #5653 处置),与 WhatDamon、Minecraft269、MinecraftYJQ 主张设置界面/两者共存(见 2.4.2 第 4、6、8、9 条)构成分歧;burningtnt 主张该功能仅面向整合包作者/第三方打包,与 MinecraftYJQ、WhatDamon 的"普通用户也可用"主张构成分歧。
• 社区诉求与维护者决策的关系:3gf8jv4dv 主张维护者拥有最终决定权、用户不应道德绑架(见 2.4.2 第 5 条),与 Minecraft269 初版评论中的"社区驱动、需求应被满足"表述构成分歧(Minecraft269 随后已致歉并修正立场,见 2.4.2 第 6 条)。
• 功能必要性判断的时机:PR [Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828 中 Glavo 对更新日志渲染必要性的质疑,与 3gf8jv4dv "应更早提出"的批评、Calboot "国内访问 Modrinth/CF 慢"的辩护构成分歧(见 2.5.1-A)。
• AI 在贡献中的角色:fatelove42 自述使用 AI 辅助贡献并询问是否造成压力(见 2.1 第 3 条);Glavo 对无人类审查的疑似 AI spam PR 采取关闭并屏蔽账号的处置(见 2.1 维护者回应与处置);3gf8jv4dv 在 feat: 添加自定义标题栏设置 #5653 批评"演讲稿式 AI 长文"但认可 AI 使用声明(见 2.4.2 第 5 条);WhatDamon 在 [Feature] [Doc] 更新贡献指导 #6602 提出 AI 贡献政策(见 2.5.2)。
• 透明度渠道:WhatDamon 主张公开决策应使用 GitHub Discussions 而非 QQ 群(见 2.4.2 第 9 条);该主张与 2.2 第 1 条中 3gf8jv4dv 的表述构成分歧。

---

三、调查方法

本节说明本次调查(即本讨论的收集与分析)将如何操作,供参与者了解规则后参与。

3.1 数据采集

• 范围:以本讨论为本体;同时穷尽关联数据源——本基底中引用的讨论(是否应该自动关闭新贡献者的 PR？ #6598、关于改进 HMCL 仓库维护的意见 #4921、社区意见调查:基底、方法与边界 #6062、堆叠 PR (Stacked pull requests) #6548)、PR(添加隐藏标题栏“帮助”按钮的选项 #5812、feat: 添加自定义标题栏设置 #5653、[Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #4828、[Feature] 模组等的更新日志以及 HTMLRenderer 的完善 #6098,另见 2.1 中作为背景事实提及的 修复多个Bug: macOS主题跟随、Linux更新、模组UI对齐、不兼容提示、文件占用回滚 #6575、fix: JFXPopup hide()空指针保护 & 其他稳定性改进 #6576)、issue([Feature] 增强启动器的可定制性 #4375、[Feature] [Doc] 更新贡献指导 #6602),以及参与者在本讨论中另行指出的新关联条目(欢迎在回复中给出链接)。
• 检索方式:对关联条目逐一点开,阅读原帖、全部评论(含折叠的审查评论)、关闭/合并事件;使用 GitHub 搜索(关键词:标题栏、配置文件、贡献指南、spam、AI、label 等)补充可能遗漏的关联 PR/issue;检查被引用条目的反向引用(哪些讨论/PR 提到了本讨论)。
• 历史版本:涉及"规则是否曾存在"的事实性断言(如 Contributing.md 的内容),以 docs/Contributing.md 的当前版本及提交历史为准。
• 缺失处理:任何数据源无法访问或确认的内容,在本调查中标注为"缺失/未核实",不推测其内容。

3.2 主题归类

• 将收集到的观点按议题维度聚类,拟定维度(可调整):
  1. 功能实现路径(设置界面 vs 配置文件 vs 两者共存);
  2. 贡献规则与文档(Contributing.md、AI 披露、Slop 界定、惩罚机制);
  3. PR/issue 管理流程(标签、规模标记、堆叠 PR、自动关闭);
  4. 决策权与透明度(维护者决策、社区诉求、公开渠道);
  5. spam/AI slop 的识别与处置。
• 归类标准:一条观点按其主张的"对象"(功能、流程、权力、内容质量)归类;跨主题观点按其主要主张归入一类,并在其它相关类目下注明其存在(不拆分原句);归类结果与归类争议将随调查结果一起公开,参与者可指出归类不当。

3.3 参与度量化

• 统计口径:每条讨论/PR 的评论数、原帖与评论的各类反应(👍👎🤔❤👀等)数量、参与者账号身份(仓库成员 MEMBER / 贡献者 CONTRIBUTOR / 普通用户 NONE)。
• 解读边界:反应数与评论数仅反映"GitHub 可见互动",不折算为"支持率";不区分反应者的身份与动机;不将任何单条评论的获赞数解释为"社区共识";参与者身份按 GitHub 的 author_association 字段记录,不推断账号背后的人。
• 情绪性反应(😂等)单独列出,不并入正反立场计数。

3.4 立场呈现

• 各方论点以相同篇幅与尊重呈现:每条立场给出其原文要点、作者、来源链接;不做篇幅加权;不合并相似观点;不按整理者偏好排序。
• 立场呈现遵循"保留原貌"原则:引文不改写;转述必须标注;被引述方已撤回或修正的内容,同时保留修正前后版本(如 2.4.2 第 4、6 条)。
• 身份提示:整理者会在立场旁标注发言者的公开身份(维护者/贡献者/普通用户),仅作背景信息,不作可信度排序依据。

3.5 验证手段

• 交叉验证:同一事实(如某 PR 的关闭时间、某规则是否存在)至少以两处独立来源核对(原帖时间线、事件记录、文件历史)。
• 引文核对:任何"某人说过 X"的表述,必须可回溯到对应链接;无法回溯的引文(如 社区意见调查:基底、方法与边界 #6062 原帖中的 AI 改写引文)标注为"改写版本"并给出原文出处(本基底 2.3 已示范)。
• 缺失与未答复识别:整理时单独列出"提出问题但未获答复"的记录(如 社区意见调查:基底、方法与边界 #6062 自发布以来 0 评论;关于改进 HMCL 仓库维护的意见 #4921 原帖下无维护者回复),不替未答复方补写立场。

---

四、合理调查声明

4.1 用户群构成

• HMCL 以中文玩家为主要用户群,其中低龄学生比例较高,技术水平差异大(该描述为整理者的观察,未经统计验证);同时,参与者不只有"玩家"——还包括贡献者、整合包作者、模组/资源包生态从业者、第三方打包方(见 feat: 添加自定义标题栏设置 #5653 评论中 burningtnt 与 WhatDamon 对"第三方打包"的讨论,来源)。
• 本次调查不对参与者的技术水平、使用时长或身份作任何预设;任何观点都按其原文记录。

4.2 样本偏差声明(适用范围与局限)

• 本调查以 GitHub Discussion 为主渠道。普通用户大量活跃于 QQ 群、B 站评论区、贴吧、Discord 等渠道;这些渠道的意见将通过参与者自愿转述或志愿者汇总的方式纳入本调查(方式与局限见第六节),转述/汇总内容无法逐条回溯核验,会与可核验的 GitHub 评论分开标注,其代表性由阅读者自行判断(WhatDamon 在 PR #5653 评论 中亦指出 QQ 群渠道的覆盖局限)。
• 因此:本调查可核验的结果只代表"在 GitHub 上表达意见的人",不声称代表 HMCL 全部用户;经转述纳入的其他渠道意见单列标注,不与其他可核验数据混同;本讨论的参与者构成(低龄学生、技术背景、活跃度)本身就构成样本特征,解读结果时须计入。
• 参与量化的指标(见 3.3)只用于描述本调查的可见互动,不用于推断未参与人群的立场。

4.3 中立性要求

• 本调查的提问不带倾向、不预设结论(问题清单见第五节,均为开放式问题)。
• 全篇区分事实与观点:事实须带来源;观点标注作者;整理者不发表自己的判断。
• 不出现任何施压式表述:本调查不包含"社区应该……""维护者有义务……""不支持就是……"类句式;参与者发言时也不应以此类表述要求他人表态。
• 结论的认定权在讨论本身:任何"大多数人""社区认为"的表述,只有在本讨论中由参与者以可验证的方式(如逐条表态)得出时方可成立,且须注明统计口径。

4.4 边界声明(本次调查范围之外)

• 具体实现细节(代码方案、配置文件格式、UI 设计)不在本调查范围内;本调查只收集"方向与原则"层面的意见。
• 发布日期、版本计划承诺不在本调查范围内;本调查不要求任何人承诺时间表。
• 对个人(具体维护者、具体贡献者)的功过评价不在本调查范围内;涉及个人的讨论仅在其与议题直接相关时保留(如 是否应该自动关闭新贡献者的 PR？ #6598、feat: 添加自定义标题栏设置 #5653 中的既有表述,均按原文记录)。
• 已被明确认定为恶意骚扰/滥用账号的事件(如 fix: JFXPopup hide()空指针保护 & 其他稳定性改进 #6576 的处置)不作为本调查的辩论对象,仅作为背景事实记录。
• 本调查不收集任何个人信息;参与者无需提供身份、设备、网络环境等敏感信息。

---

五、开放式问题

以下问题供参与者回应。问题只提问,不带倾向;可在任一问题下发表任何方向的意见,也可指出问题本身的不当之处。

1. 新功能在"设置界面开关"与"配置文件选项"之间的取舍,应当依据什么原则?两者是否可以并存?判定权应当如何归属?
2. 对于"某项功能只提供配置文件方式"的做法,你认为它对不同用户群体(新手玩家、进阶用户、整合包作者、第三方打包方)分别意味着什么?
3. 维护者基于技术方向与路线图作出的决定,与社区中表达的功能诉求之间,应当是一种什么关系?当两者冲突时,你希望看到怎样的处理过程?
4. 贡献指南(Contributing.md)应当覆盖哪些内容?对 AI 辅助贡献(AI slop 之外,也包括正常使用 AI)应当如何规定?
5. 对"自动关闭新贡献者 PR"这类流程性措施,你的看法是什么?你认为仓库当前面临的 spam/AI slop 压力处于什么水平?
6. PR 与 issue 的标签、规模标记、优先级呈现等管理手段,对你(作为贡献者或阅读者)有多大价值?你希望看到哪些改进?
7. 在 PR 被关闭或被要求返工的过程中,你希望获得怎样的反馈(包括反馈的时机、方式、标准)?
8. 关于公开决策渠道(如 GitHub Discussions)与其它渠道(如 QQ 群)的信息传递,你认为现状如何?理想的公开程度是什么样的?
9. 你认为一个开源启动器项目的"社区"应当由哪些人构成?他们的意见分别应在多大程度上影响项目方向?
10. 你是否还有本调查未覆盖、但你认为应当讨论的问题?请在回复中提出。

---

六、调查范围与渠道补充说明

本讨论专注于那些有争议性的 PR/issue 的去留问题,需要的是社区成员基于本调查材料、来自各渠道的意见。

除 GitHub Discussion 外,意见收集渠道还包括 QQ 群、B 站、贴吧、Discord 等社区聚集地。通过上述渠道收集意见的方式:

1. 自愿转述:参与者将其他渠道中与本次调查相关的公开讨论转述到本讨论,注明原始渠道与大致时间(无需提供账号信息);
2. 志愿者汇总:由志愿者将其他渠道的公开讨论整理为摘要,附于本讨论之下。

需要提前说明的是:跨渠道收集可能导致工作量激增,且转述与摘要无法像 GitHub 评论一样逐条回溯核验。因此,经上述方式纳入的意见将标注其渠道来源,与 GitHub 内的可核验评论分开呈现(见 3.5 与 4.2),其代表性与准确性由阅读者自行判断。参与转述与汇总均为自愿行为。