コードなしでプルリクエストを作成することは意味がありますか
バックグラウンド
私たちのスタートアップのドキュメントでは、これを手に入れました：
プルリクエストと課題ページの違い
簡単に言えば、問題ページには問題自体に関する情報とディスカッションのみが含まれている必要があります（つまり、要件の明確化、要件への編集の提案など）。実際のソリューションに関する情報やデータは含めないでください。
一方、PRページには、ソリューションに関するデータ/ディスカッションのみを含める必要があります。要件の性質に関する情報は決して含めないでください。問題のページにのみ含める必要があります。
どうして？
b/c問題とその解決策は2つの異なるものです。問題の要件は修正して明確にする必要がありますが、同じ要件には多くの異なるソリューションとソリューションパスがある場合があります。したがって、提案されたソリューションが問題の要件に影響を与えることを望まないため、提案されたソリューションは問題ページとは別にホストする必要があります。たとえば、エンジニアにタスクを割り当てると、エンジニアは1週間を費やして、絶対に許容できないソリューションを提示できます。そのソリューションが別のPRページでホストされている場合、そのソリューションを完全に拒否し、同じタスクを別のエンジニアなどに割り当てることができます。
質問
上記を踏まえて、ブランチをまったく持たずにPRを作成できることは理にかなっていますか？主要なgitベースのオンラインプロジェクト管理ツールプレーヤーはそれを許可していませんが（私はgithub/gitlabとbitbucketを確認しました）、理論的にはgitlabのコードをいじれば実行できます。
更新（以下の回答に追加）
Karl Bielefeldtの answer ..がとても気に入りました。これを追加したいだけです。私たちが取り組んでいるプロジェクトには非常に積極的なリリースとデプロイサイクルがあるため、スタブされたコードが主枝。これに対処するには、トピックブランチに対してR＆D PRを作成するのが理にかなっていると思います。出力は、ディスカッション、Googleドキュメントなどに加えて、スタブ化されたコードであり、最終的に実装が発生したときに（スタブ化されたコードを削除し、実際のコードで置き換えてください。.そのためのPRは、masterブランチに対して実行できます。
プルリクエストを開くためにcodeを変更する必要はありませんが、branchが必要です。その意図が常に実現するとは限らない場合でも、いくつかのコードをプッシュします。
コーディングを開始する前にプルリクエストを使用して実装の詳細を伝達することには、メーリングリストに比べていくつかの大きな利点があります。興味のあるバグまたは機能のみをサブスクライブすることができます。これは、作業を分割する必要がある大規模なプロジェクトのメンテナーと、1つまたは2つの今後の機能またはバグ修正のみに関心があるサードパーティの両方に役立ちます。興味のあるものを見るためだけに、メーリングリスト全体をフィルタリングする必要はありません。
また、実装のディスカッションはバージョン管理のコミットに永遠に関連付けられているため、そのように設計された理由、またはどの代替案が議論されて破棄されたのかについて人々が質問した場合、参照するディスカッションを見つけるのは簡単です。
これらの2つの理由から、新しい大規模なオープンソースプロジェクトでは、少なくとも広範な実装の議論を必要とする機能のために、空のブランチでプルリクエストを開くことがますます一般的になっています。 Kubernetes が良い例です。 Githubには タスクリスト などの機能があり、このようなワークフローを容易にしています。
いいえ。あなたが引用したことの主なポイントは、解決策と問題を分離しておくことです。これは、コードが書かれる前に実際のプルリクエストを必要としません。提案のディスカッションは別のドキュメントに保存できます（ドキュメントがPR pageで意味しているのではないかと思います）。