[PATCH v1] docs: ja_JP: process: translate 'Describe your changes'

[Akiyoshi Kurita]

Translate the "Describe your changes" section in
Documentation/translations/ja_JP/process/submitting-patches.rst.

Signed-off-by: Akiyoshi Kurita <weibu@xxxxxxxxxxxx>
---
 .../ja_JP/process/submitting-patches.rst      | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index d61583399ef4..daf02b8983cf 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -54,3 +54,34 @@ Documentation/devicetree/bindings/submitting-patches.rst を読んでくださ
 
 変更内容を説明する
 ------------------
+
+問題を説明してください。あなたのパッチが 1 行のバグ修正であっても、
+5000 行の新機能であっても、それを行う動機となった根本的な問題が必ずあるはずです。
+修正すべき価値のある問題が存在し、レビューアが最初の段落以降を読む意味があることを
+納得させてください。
+
+ユーザーから見える影響を説明してください。クラッシュやハング（ロックアップ）は
+分かりやすいですが、すべてのバグがそこまで露骨とは限りません。たとえコードレビュー中に
+見つかった問題であっても、ユーザーにどのような影響があり得るかを説明してください。
+Linux の多くの環境は、上流から特定のパッチだけを取り込む二次的な安定版ツリーや
+ベンダー／製品固有のツリーのカーネルで動いています。したがって、変更を下流へ
+適切に流す助けになる情報（発生条件、dmesg の抜粋、クラッシュ内容、性能劣化、
+レイテンシのスパイク、ハング／ロックアップ等）があれば記載してください。
+
+最適化とトレードオフを定量的に示してください。パフォーマンス、メモリ消費量、
+スタックフットプリント、バイナリサイズの改善を主張する場合は、それを裏付ける数値を
+記載してください。また、目に見えないコストについても説明してください。最適化は通常、
+CPU、メモリ、可読性などのコストを伴います。ヒューリスティクスの場合は、異なる
+ワークロード間のトレードオフも発生します。レビューアがコストとメリットを比較検討できるよう、
+最適化によって予想されるデメリットについても説明してください。
+
+問題が特定できたら、実際にどのような対策を講じているかを技術的に詳しく説明してください。
+レビューアがコードが意図したとおりに動作しているかを確認できるよう、変更内容を平易な言葉で
+説明することが重要です。
+
+パッチ説明を Linux のソースコード管理システム ``git`` の「コミットログ」としてそのまま
+取り込める形で書けば、メンテナは助かります。詳細は :ref:`the_canonical_patch_format` を
+参照してください。
+
+1 つのパッチでは 1 つの問題だけを解決してください。説明が長くなり始めたら、パッチを
+分割すべきサインです。:ref:`split_changes` を参照してください。

base-commit: a592a36e49372172d7c7551ec19ed18184c935e1
prerequisite-patch-id: 5569479a56e04681cfd6b22f5de9d850e10c8f5f
-- 
2.47.3