关于改进 HMCL 仓库维护的意见 #4921
Replies: 2 comments
-
|
本来想发个新帖，但突然想起这个帖子。对于当下 PR 列表的情况有感而发。 目前只有 Glavo 一个人持续推送、合并代码。但是，我感觉摸不出 Glavo 合并 PR 的规律。有一些规模小、看起来没啥大分歧的 PR 能晾好几天甚至数周。有的 PR 放了很久，本以为能合并时，突然被 Glavo 质疑。有的 PR 合并后突然又被撤回。 而且 Glavo 很多时候是有自己的「计划表」的，这也导致一些 PR 迟迟得不到合并。 不过，看看当下的 PR 列表，似乎也能理解。PR 页面目前没有一个条目附带 label，而且 PR 的标题、内容可谓是「五花八门」：
这些给 PR 快速归类、安排审查/合并的次序带来了难度。 反观其他 Minecraft 启动器乃至其他开源项目，很多都为各 PR 安排了 label，而且 PR 标题、正文有模有样，读起来赏心悦目。 如果 HMCL 的 PR 合并策略继续这样下去，想想吧。一些人可能心灰意冷，甚至质疑、攻击 Glavo 和 HMCL 社群。一些人可能要不断 merge / rebase 自己的分支，心力交瘁。一些人可能由于各种原因没办法继续改进 PR，PR 可能就此晾着。 对于 HMCL 的 issue 管理，我认为 WhatDamon 已经说的很详细了，没啥补充的，最多就是 label 的具体设置、标记流程有争议。 对于 PR，我建议 HMCL 尽快实施以下内容：
至于和 issue 类似的精细分类，本想列在上面。但是呢，想到 Glavo 等维护者不太有时间随时上 label，而且目前没有协作者机制；就算引入，对于某个 issue / PR 如何归类可能引发的争议，又会带来噪音。所以我又咽了回去。 |
Beta Was this translation helpful? Give feedback.
-
|
个人认为 PR 也需要 issue 类似的标签，其中一部分是贡献者可自选的，另一部分是只有项目成员可以为 PR 设置的 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
考虑到这并非一个针对 HMCL 项目的提议，故在此发表一些意见
引入自动关闭骚扰信息的工作流
为什么？
2025年11月29日，本仓库遭到了某用户的骚扰：
经过举报后，GitHub对此账户采取了措施
两个Issue也被删除（虽然我不清楚他人在Issue删除前是否也进行了举报），但我觉得这次骚扰后这一条真的可以进行考虑，来减少不必要的麻烦，与对他人产生影响
如何做？
可以尝试引入 JohnsonRan/nomore-spam 工作流，自动关闭这类Issue（删除建议在完成举报后再手动操作）
为每个 Issue 添加标签：
目前本项目 Issue 常用标签只有两个：
enhancementbug以此为基础来搜索 Issue，很容易因找不到相同的 Issue 而非主观地发送重复 Issue，并且也很难让用户及贡献者了解 Issue 的优先级，另外也很难吸引新的贡献者
例如，针对
macOS的这个关键词，可能会存在以下别称：Mac OS、Mac OS X、OS X、Darwin，考虑不周动很容易遗漏，带来不必要的管理负担如何做？
在现有标签基础上，添加以下标签：
platform:windowslinuxmacosfreebsdarch:x86_64x86arm64arm32mips64elriscv64loongarch64_nw// New Worldloongarch64_ow// Old Worldppc64les390xpriority:0// 非常重要，需立即处理1// 重要，优先考虑2// 一般，可以稍后考虑3// 最低，但有意义future// 短期无意义，未来可能有价值good first issue// 标记一些简单的 Issue，鼓励新贡献者参与此外还可以按照需要添加
area:系列标签，来确定问题指向的功能上面提及的工作流似乎可以自动添加标签
Beta Was this translation helpful? Give feedback.
All reactions