没有星标，就不给修复

政策与规则合规性

• 有些人认为，这种“星标门槛”机器人（在报告者给仓库点星之前关闭问题）很可能违反 GitHub 关于自动点星 / “协同不真实活动”的规则。
• 也有人反驳说，这并不明显违反规则，因为：这是用户发起的，需要明确同意，不是自动点星，而且仓库所有者没有义务提供支持。
• 还有人指出，无论当前规则如何，这类做法 都应该 被禁止，因为它扭曲了平台信号。

星标的含义与完整性

• 许多人把星标看作个人书签或真实认可；把问题处理与星标挂钩，被视为污染了这一信号。
• 批评者说，这会让星标数因烦躁或需求而上涨（例如依赖项出问题），而不是因为欣赏或受欢迎。
• 支持者则认为，报错的人本来就是“感兴趣的用户”，因此要求点星反而会让星标更贴近真实使用。

伦理、权力关系与“勒索”框架

• 一些评论者把这种做法称为卑劣、琐碎，或“像勒索”： “我甚至不会考虑你的问题，除非你公开喜欢我。”
• 担忧包括：情感操控、对于评估该项目的组织来说是声誉红旗，以及会劝退有价值的路过式报告（包括潜在安全问题）。
• 也有人认为维护者可以为免费的劳动设定任意边界，而要求一个星标只是为获得关注而付出的最低代价。

维护者负担与减少噪音

• 支持者强调维护者过载：问题队列被挤爆，而一点点摩擦（比如星标）可以过滤掉低投入的报告。
• 批评者回应说，这并不能区分好报告和坏报告，甚至会挡住愿意贡献代码的高质量提议。

实际后果与边缘情况

• 评论者指出，有些人提交问题时并不是因为“喜欢”这个项目：自动化工具、安全研究、传递依赖，或者在多个选项之间做评估。
• 有些人会先点星，等问题处理完再取消；另一些人则原则上拒绝，更愿意捐款或提供赏金。
• 还有人指出，如果这种做法扩散，就会引发一场“星标通胀战争”，使星标像市场上被操纵的评价一样失去价值。