PRテンプレートで変更対象とカテゴリを分けて書くようにする #1814
Conversation
|
ということで、 @dep5 さんにも意見を求めておきます。 |
| - リファクタリング | ||
| - ドキュメント修正 | ||
| - プログラムの動作上の問題 | ||
| - サクラエディタ本体 | ||
| - 正式リリース版 | ||
| - Azure Pipelines ビルド版 | ||
| - AppVeyor ビルド版 | ||
| - GitHub Actions ビルド版 | ||
| - ローカルビルド版 |
There was a problem hiding this comment.
「～ビルド版」って要らないですね、たぶん（指摘ではないです。
There was a problem hiding this comment.
「ビルド」は確かに要らないですね。
ところで、バージョン情報ダイアログ以外にCIサービスの違いが動作に影響しそうな箇所はない気がするのですが、区別したほうがいいのでしょうか？
こういう書き方になったのは #914 からのようですが、これには理由が書かれていません。
There was a problem hiding this comment.
わからないです。
「Appveyorだけに影響する修正」とか「Azure Pipelinesだけに影響する修正」とかあったので作ったんだと思います。
よくよく考えてみるとそれは「CIスクリプトの不具合修正orプロセス改善」であるような気がします。
「ビルド環境の違いがCDlgAboutに影響する」というのも実は「githash.batの出力結果はビルド環境によって変わる」に依存する結合テスト的影響の産物なので、「何」を修正して「どこ」に影響するか？の「どこ」を分かりやすくするためのものだったと考えられます。
で、結局「影響範囲」に書ける内容なので「カテゴリ」に「～ビルド版」があるのはおかしいように思います。
| - 正式リリース版 | ||
| - Azure Pipelines ビルド版 | ||
| - AppVeyor ビルド版 | ||
| - GitHub Actions ビルド版 | ||
| - ローカルビルド版 | ||
| - ヘルプ | ||
| - インストーラ | ||
| - ビルド関連 | ||
| - ビルド手順 | ||
| - Azure Pipelines | ||
| - AppVeyor | ||
| - GitHub Actions | ||
| - ローカルビルド |
There was a problem hiding this comment.
- MSVCビルド（全ビルド環境に影響）
- MinGWビルド（現状はAzpのみに影響）
- 本体以外のビルド（全ビルド環境に影響）
あたりを追加したら分かりやすくなる気がしました（指摘ではないです。
|
|
||
| - 機能追加 | ||
| - 仕様変更 | ||
| - 不具合修正 |
There was a problem hiding this comment.
「不具合修正」を小分けにできないか？ということを考えていました。
- アプリ不具合修正
- 仕様変更あり
- 仕様変更なし
- その他不具合修正
- 仕様変更あり
- 仕様変更なし
もっと小分けにできるかも・・・（指摘ではないです。
| - 仕様変更 | ||
| - 不具合修正 | ||
| - 速度向上 | ||
| - リファクタリング |
There was a problem hiding this comment.
「速度向上」と「リファクタリング」はレベルが違うのが前から気になっていました。
- 速度向上 修正の目的「速度向上」を表す。
- リファクタリング 修正の手段「リファクタリング」を表す。
「 速度向上」させる手段「リファクタリング」は有効です。
ニュアンス伝わりますかね？
２つの単語の意味するものの粒度というか種類が違うんです。。。
結論が出ないので、これも指摘ではないです。
There was a problem hiding this comment.
変更目的は「PRの目的」欄に記述され、そのためにどんな手段をとるのかがここに来るものと考えました。
なので…ここに「速度向上」が残っているのはちょっと変でしたね。
There was a problem hiding this comment.
- 「プログラム構造が煩雑なのを分かりやすくしたい」が目的だとして、手段「リファクタリング」はアリ。
- 「～したときに～となるのが困るので対処したい」が目的だとして、手段「仕様変更」はアリ。
- 「～したときに～となるのが困るので対処したい」が目的だとして、手段「不具合修正」はアリ。
- 「～したときにアプリが固まって困るので対処したい」が目的だとして、手段「速度向上」は意味不明。
「カテゴリ」は「手段である」と考えるとしっくりきそうです。
ghost
marked this pull request as draft
|
@kazasaku TODO: issue templates |
| - 不具合修正 | ||
| - 速度向上 | ||
| - リファクタリング | ||
| - ドキュメント修正 | ||
| - GitHub 関連の問題 | ||
| - 実験 (master へのマージを目的としない) | ||
| - その他の問題 |
There was a problem hiding this comment.
これも指摘ではないですが「カテゴリは手段である」と置いたとき、
「GitHub関連の問題」と「その他の問題」が意味不明になります
*「～したときに～となるのが困るので対処したい」が目的だとして、手段「GitHub関連の問題」は意味不明。
*「～したときに～となるのが困るので対処したい」が目的だとして、手段「実験 (master へのマージを目的としない)」はアリ。
*「～したときに～となるのが困るので対処したい」が目的だとして、手段「その他の問題」は意味不明。
issue templateを導入した時のスタンスが「とりあえず入れてみようぜ！」で中身を真面目に見てなかったことが原因と思います。
|
ん？「カテゴリは手段である」と置くと「サクラエディタ本体」と「ビルド関連」も意味不明になるような（笑 |
ghost
closed this
PR の目的
PRの変更対象と内容のカテゴリを分離します。
カテゴリ
PR の背景
Originally posted by @dep5 in #1806 (comment)
現状は「何に対する」カテゴリなのかよくわからないので、レビュー過程で「その選択は間違っている」と言われることがあります。
PR のメリット
「何」に対して「どんな変更」をしたいかを書きやすくなります。
PR のデメリット (トレードオフとかあれば)
仕様・動作説明
PR の影響範囲
テスト内容
関連 issue, PR