maintainer-decline

维护者拒绝请求

帮助开源维护者撰写回复，以关闭、拒绝或转交问题，同时让贡献者了解情况并感受到尊重。

核心理念

关闭问题不等于怠慢。措辞得当的拒绝能够帮助贡献者理解问题、解除阻碍或将其引导到合适的方向。目标是让阅读回复的人最终明白原因——即使他们没有得到自己所请求的内容。

原则

解释原因，而不只是说明结果。 贡献者明白自己被告知了“不能做”。他们需要的是理由：战略方向、设计理念、投入与收益的权衡，或实际的技术根因。

拒绝前先认可。 在转向拒绝之前，先认可贡献者的观点。像“是的”“这是个合理的想法”或“我觉得……”这样的表达，表明你在作出决定前听取了对方的意见。

尽可能提供前进的路径。 即使是“不能”，也可以补充“但你可以……”或“改用 X”。让贡献者能够继续推进，或知道正确的方向。

涉及设计决策时使用“我们”。 “我们认为”“我们决定了”“我们曾尝试过……”将决策表述为团队的选择，而不是个人把关。

每条回复只作出一个决定。 不要含糊其辞；除非你确实是这个意思，否则不要说“以后也许会考虑”。明确结论——即使结论是“这会在 X 之后发生”。

简洁体现尊重。 大多数拒绝用 1–3 句话就能说清楚。只有在存在重大误解或确实需要解释时才写得更长。

认可对方付出的努力。 如果贡献者确实做了工作（编写 reprex、起草代码、做了调研），就明确提出来。“感谢你提供详细的报告”毫不费力，却能表明你重视对方的时间。

回复模式

选择适合情境的模式。这些不是模板，而是可以灵活运用的结构。

重复问题

一句话即可。链接到原始问题。无需展开说明。

与 #7651 重复

已修复 / 已解决

链接到修复内容。无需其他说明。

已在 #1430 中修复

不予修复——已被取代或弃用

说明战略方向，指出替代方案，并感谢用户。

gather() 已不再积极开发，因为它已被 pivot_longer() 取代。很抱歉我们无法提供更多帮助，也感谢你使用 tidyr！

鉴于我们正逐步弃用此警告（转而使用 .by），我认为遗憾的是，处理它所需的成本并不值得。

结构：[当前的战略方向] + [迁移路径或替代方案] + [简短的感谢或致意]

设计理念

当某种行为看起来像是 bug，实际上却符合预期时。将其表述为一项原则，并解释后续影响。

总体而言，我们认为这种宽松的类型转换弊大于利，因为它可能导致数据质量问题被悄然传递，最终引发难以理解的错误。

我们过去曾尝试过这种做法，但许多 tidyr 函数会生成列表列，而 data.frame 的 print() 方法并不擅长处理这类列，因此我们决定始终使用 tibbles。

结构：[原则：“我们认为……”／“我们决定……”] + [允许这种做法会导致什么问题] + [可选：促成这一决定的过往探索]

变通方案 / 帮助继续推进的替代方案

不会实现这项请求，但仍有可行路径。先认可对方，再提供具体替代方案。将变通方案作为最佳做法来介绍，而非安慰性质的替代品。

是的，我觉得你最好在 expand_grid() 外部创建公式。

你可以使用 coalesce() 简化代码：[代码示例]。我们没有太多跨列操作的函数，因为当各列类型不兼容时，很难决定如何处理。

结构：[认可：“是的，”／“我觉得……”] + [具体替代方案，可附代码] + [可选：说明为什么没有这项功能]

澄清 / 讲解根本原因

贡献者误解了实际行为。通过最小可复现示例、文档引文，或一句话解释他们忽略的机制，说明实际发生了什么。

问题在于你的模式无法匹配，而在这种情况下，预期行为是输出 NA。遗憾的是，我们无法根据部分匹配组填充结果，因为正则表达式引擎并未填充任何匹配组。

它没有显示出来，是因为你创建了许多个简短的 map() 调用，而不是一个较长的 map() 调用。

我认为文档对此已经说明得相当清楚：[引用文档]。要改变这类行为，很难不影响大量现有代码；考虑到这似乎很少成为问题，遗憾的是，我认为不值得为此投入精力。

结构： [实际发生了什么] + [为什么会这样] + [可选：为什么不容易更改]

工作量评估

这个请求是合理的，但投入与收益不成正比。认可这个想法，解释阻碍；也可以为外部解决方案留有余地。

这似乎是个合理的优化，但我不清楚它应该放在哪里。遗憾的是，要推动解决这个问题，我们面临太多未知因素；不过，如果能有一个适用于整个 tidyverse 的解决方案就好了。

结构： [认可合理性] + [指出真正的障碍] + [可选：说明它更适合放在哪里]

范围 /“目前还不适合”

这个想法有价值，但不属于这个包，或尚未成熟。

基于上述原因关闭此问题；我认为这是个有趣的想法，但目前感觉还不适合 tidyr。

结构： [认可其价值] + [质疑是否适合：“目前感觉不适合 X” / “Y 是合适的地方吗？”]

指引问题方向

贡献者关注错了层级或包。委婉地建议换个方向。

这看起来更像是 stringr 的问题？

结构： [建议另一种问题判断，通常以提问的形式表达]

选择合适的模式

使用以下启发式规则，判断适用哪种模式：

问题中的信号	应使用的模式
报告者在已弃用 / 已被取代的函数中遇到了 Bug	不予修复 — 已被取代
请求合理，但函数 / 功能本来就是有意如此设计的	设计理念
报告者的代码有可修正的错误，或已有替代方案	解决方法
报告者对函数的工作方式存在错误的认知	澄清
请求有效，但实现成本过高或架构尚不明确	工作量评估
想法很有趣，但属于其他包或尚未成熟	范围
Bug 或行为源自依赖项，而非此包	指引问题方向

适用多个模式时： 优先采用最有帮助的模式。如果有人误解了行为，而且有解决方法，先解释根本原因，再提供替代方案。如果某项功能已被取代，而且有迁移路径，“已被取代”模式本身就包含了后续做法。

问题只是重复项或已修复时： 使用机械式的一句话回复。无需解释，也不用铺垫同理心——简洁本身就是尊重。

应避免的做法

• 为简单决定提供冗长的理由。 如果答案是“否”，简要说明即可。
• 采取防御性语气。 不要只说“事情就是这样”，却不解释原则。
• 使用轻慢的措辞。 不要说“显而易见”“我们之前说过了”或“这说不通”。
• 过度道歉。 一句“抱歉”或“遗憾的是”就够了。
• 做出无法兑现的承诺。 如果你不会跟进，就不要说“我们会研究一下”。
• 含糊其辞。 不要说“以后可能会”“我们会考虑”——明确说明决定。
• 消极攻击。 不要说“我们之前说过了……”，也不要暗示贡献者本该知道。
• 居高临下。 即使要结束一个显而易见的问题，也要就事论事。

调整语气

• 坦诚说明限制： “遗憾的是”“我不太确定”“还有一些未知因素”——真诚说明你不了解的情况。
• 明确表达自己的观点： 使用“我认为……”“我们相信……”“我猜当时是这样做的……”——不要推卸责任。
• 适时表达感谢： “感谢反馈”“感谢使用 X”——认可对方花费的时间。
• 谨慎使用幽默： 只有确实体现个性时才使用，绝不要借此缓和拒绝的语气或取笑贡献者。

应用此技巧

当有人要求你起草回复时：

1. 判断模式。 适合哪种结束问题的方式？（重复问题、不予修复、设计理念、变通方案、澄清、工作量评估、范围、转介）
2. 起草回复，遵循相应的结构。
3. 检查： 是否解释了原因？拒绝之前是否认可了对方的诉求？是否提供了后续途径？是否已足够简短，同时表达清楚？
4. 提交草稿，供维护者审阅并调整为符合其风格的版本。