maintainer-decline

メンテナーによる却下

オープンソースのメンテナーが、コントリビューターに情報を伝え、敬意を示しながら、課題を終了、却下、または適切な方向へ誘導する返信を作成できるよう支援します。

基本理念

終了は、門前払いではありません。よく練られた却下は、コントリビューターに知識を与え、次の行動を可能にし、または有益な方向へ導きます。返信を読んだ人が、たとえ求めていたものが得られなかったとしても、その理由を理解して帰れるようにすることが目標です。

原則

何をするかではなく、その理由を説明します。 コントリビューターは「いいえ」と言われていることを理解しています。必要なのは、その判断の根拠です。たとえば、戦略的な方向性、設計理念、労力と効果の比較、あるいは実際の技術的な根本原因です。

却下する前に、相手の意見を受け止めます。 別の方向へ導く前に、コントリビューターの指摘を認めます。「そうですね」「妥当なアイデアだと思います」「私はこう考えます」といった言葉で、判断を伝える前に相手の意見を聞いていることを示せます。

可能であれば、次に進む道筋を示します。 「いいえ」という返答にも、「ただし、こうすることはできます」や「代わりに X を使ってください」と添えられます。コントリビューターが先へ進める状態にするか、適切な方向を示しましょう。

設計上の判断には「私たち」を使います。 「私たちはそう考えています」「私たちはそう決めました」「私たちは試してみました」と表現することで、判断が個人による門前払いではなく、チームとしての決定であることを示せます。

1つの返信で伝える判断は1つにします。 どっちつかずの表現や、本気でそう思っているのでなければ「いずれ対応するかもしれません」といった言葉は避けます。「X の後に対応する」という判断も含め、明確に終了を伝えましょう。

簡潔さは敬意の表れです。 却下の返信のほとんどは、1～3文で十分です。誤解が大きい場合や、説明が本当に必要な場合に限り、長めに書きましょう。

相手の労力を認めます。 コントリビューターが実際に作業した場合（再現例の作成、コードの草案、調査など）は、そのことに触れましょう。「詳細な報告をありがとうございます」と伝えることに負担はなく、相手の時間を大切にしていることを示せます。

返信のパターン

状況に合ったパターンを選びましょう。これらは定型文ではなく、応用できる構成例です。

重複

1行で、元の課題にリンクします。それ以上の説明は必要ありません。

#7651 と重複しています

修正済み／解決済み

修正へのリンクを貼ります。それ以外は必要ありません。

#1430 で修正済みです

対応しない — 後継機能への移行または非推奨

戦略的な方向性を説明し、代替手段を示して、ユーザーに感謝します。

gather() は pivot_longer() に置き換えられたため、現在は積極的に開発していません。これ以上お役に立てず申し訳ありません。tidyr をお使いいただき、ありがとうございます！

この警告を使わない方向に進んでいるため（代わりに .by を使う方針です）、残念ながら、対応にかかる労力に見合わないと思います。

構成：［戦略的に何が起きているか］＋［移行先または代替手段］＋［簡潔な感謝または謝意］

設計理念

バグのように見えるものの、意図どおりに動作している場合です。原則として説明し、その結果として何が起きるかを示します。

一般に、私たちはこの寛容な型変換を、全体としてマイナスだと考えています。データ品質の問題が気づかれないまま引き継がれ、最終的に役に立たないエラーにつながる可能性があるためです。

以前、これを試したことがあります。しかし、tidyr の多くの関数はリスト列を生成し、data.frame の print() メソッドはリスト列をうまく扱えないため、すべての場面で tibble を使うことにしました。

構成：［原則：「私たちはこう考えています」／「私たちはこう決めました」］＋［それを許容した場合に起きる問題］＋［必要に応じて、過去の検討経緯］

回避策／先へ進むための代替案

要望には対応しませんが、先へ進む方法があります。まず相手の意見を受け止め、具体的な代替案を提示しましょう。回避策を、妥協案ではなく最善の方法として示します。

そうですね。expand_grid() の外で数式を作成するのが最善だと思います。

coalesce() を使えば、コードを少し簡潔にできます。[コード例] 型に互換性がない場合の処理が難しいため、列をまたいで動作する関数はあまり用意していません。

構成：［相手の意見を受け止める：「そうですね」／「私はこう考えます」］＋［具体的な代替案（必要に応じてコードを含む）］＋［必要に応じて、機能が存在しない理由］

明確化／原因の説明

コントリビューターが動作を誤解しています。reprex、ドキュメントからの引用、または見落としている仕組みを一文で説明して、実際に何が起きているのかを示します。

問題はパターンが一致しておらず、その場合は出力が NA になるのが想定される動作だということです。残念ながら、マッチグループの一部から結果を埋める方法はありません。正規表現エンジンによって、どのグループにも値が格納されないためです。

長い map() 呼び出しを一つ作るのではなく、短い呼び出しを複数作っているため、表示されていません。

これは十分明確にドキュメントに記載されていると思います：[ドキュメントからの引用]。既存のコードの多くに影響を与えずにこの種の動作を変更するのはかなり難しく、問題になることもまれなようなので、残念ながら労力をかける価値はないと思います。

構成：［実際に何が起きているか］＋［なぜそのように動作するか］＋［必要に応じて：なぜ簡単には変更できないか］

労力の評価

リクエストは妥当ですが、労力に見合うメリットがありません。アイデアを認めたうえで、実現を妨げる要因を説明し、必要に応じて外部での解決策に期待を残します。

妥当な最適化だと思いますが、どこに実装すべきかは明らかではありません。残念ながら、この問題を進展させるには不明点が多すぎると思いますが、tidyverse 全体で使える整理された解決策があるとよいですね。

構成：［妥当性を認める］＋［本当の障壁を明示する］＋［必要に応じて：代わりにどこで実現できるか］

スコープ／「まだここではありません」

アイデアには価値がありますが、このパッケージには適さないか、実現の準備ができていません。

上記の理由から、これをクローズします。興味深いアイデアだと思いますが、tidyr にはまだしっくりこないと感じます。

構成：［価値を認める］＋［適合性を疑問視する：「X にはまだしっくりこない」／「Y は適切な場所か？」］

リダイレクト診断

コントリビューターが、誤ったレイヤーまたはパッケージを見ています。別の方向をそれとなく提案します。

これは stringr の問題に見えますか？

構成：［別の診断を提案する。多くの場合は疑問形］

適切なパターンを選ぶ

次のヒューリスティックを使って、どのパターンが適切かを判断します。

イシューに見られる兆候	使用するパターン
報告者が非推奨または後継機能に置き換えられた関数のバグに遭遇した	修正しない — 後継機能あり
リクエストは妥当だが、関数や機能が意図的にそのように設計されている	設計方針
報告者のコードに修正可能な誤りがある、または既存の代替手段がある	回避策
報告者が関数の動作について誤ったメンタルモデルを持っている	明確化
リクエストは妥当だが、実装コストが高すぎる、またはアーキテクチャが不明確	労力の評価
アイデアは興味深いが、別のパッケージに適している、または実現の準備ができていない	スコープ
バグや動作の原因がこのパッケージではなく、依存関係にある	リダイレクト診断

複数のパターンが当てはまる場合： 最も役に立つパターンから始めます。動作を誤解していて、かつ回避策がある場合は、まず根本原因を説明し、その後に代替案を示します。後継機能に置き換えられており、移行方法もある場合は、後継機能のパターンに今後の移行方法も含まれます。

イシューが単なる重複、またはすでに修正済みの場合： 定型の一文だけを使います。説明や共感を添える必要はありません。簡潔さこそが、敬意ある対応です。

避けること

• 単純な判断に対する長々とした説明。「いいえ」であれば、簡潔に説明します。
• **防御的な口調。**原則を説明せずに「そういう仕組みだから」と言うのは避けます。
• 相手を見下す表現。「当然ですが」「前にも言いましたが」「これは意味がありません」といった表現は使いません。
• 過度な謝罪。「申し訳ありません」や「残念ながら」は一度で十分です。
• **根拠のない約束。**実際に対応するつもりがないのに「調査します」と言わないでください。
• 曖昧な返答。「いずれは」「検討します」などではなく、判断を明確に伝えます。
• 受動攻撃的な態度。「前にも言いましたが」や、コントリビューターが知っているべきだったという含みのある表現は使いません。
• **見下した態度。**明らかな内容を締めくくる場合でも、事実に即した口調を保ちます。

口調の調整

• 制約について正直に伝える。「残念ながら」「私にははっきりしません」「不明な点があります」など、わからないことは率直に伝えます。
• 自分の意見として述べる。「私はそう思いません」「私たちはこう考えています」「そうしたのだと思います」などと述べ、責任を回避しません。
• 感謝が適切な場合は伝える。「報告ありがとうございます」「X をご利用いただきありがとうございます」など、相手が時間を割いてくれたことに感謝を示します。
• **ユーモアは控えめに。**本心からの個性として使う場合に限り、断りを和らげるためやコントリビューターを犠牲にするためには使いません。

このスキルの適用方法

回答の作成を依頼された場合：

1. **パターンを特定します。**どのクローズ方法が適切でしょうか？（重複、対応しない、設計方針、回避策、確認、作業量の見積もり、対象範囲、別の場所への案内）
2. **回答を下書きします。**該当する構成に沿って作成します。
3. **確認します。**理由を説明していますか？断る前に相手の意見を受け止めていますか？次に進む方法を示していますか？明確さを保ちつつ、できるだけ簡潔ですか？
4. **下書きを提示します。**メンテナーが確認し、自分の口調に合わせて調整できるようにします。