コントリビュートガイドの作成提案

[rdon-key]

このissueでは明文化するべき具体的な課題と項目について整理したいと思います。

• コーディング規約やスタイルガイドが不明
• プルリクエストの作成・提出方法が不明
• テストの実行方法や要件が不明確
• 作例を登録する場合の方法
• その他

[rdon-key]

https://discord.com/channels/1267846866444226721/1332545292544901150/1382877120992116817

これはgithub上でREADME.mdを編集したもの。

[rdon-key]

これは、このプロジェクトがドキュメントだったのでファイル単位で担当が決められていて気にしていなかった。

[rdon-key]

ざっくりコントリビューションガイドを検討してみました。

ｰｰｰ
・コードの書き方。
　□go fmt で整形する。
　□go.modは個別には作成せず、/go.modを使う。必要に応じて/go.modを修正する。
・プルリクエストの仕方。
　□関連するissueがあれば、issue #123 などをコミットメッセージに含める。
　□意味単位になるようにsquashを行う。
　□mainブランチに対して最新状態からのforkになるようにrebaseを行う。
　□新しく作例を追加する場合はMakefileにスモークテストを加える。
・コードレビューの対応。
マージ以外にもコードレビューのコメントがpull requestに追加される場合があります。議論してから提案された修正を行い、フィーチャーブランチに追加のコミットをプッシュしてください。プッシュ後にコメントを投稿してください。新しいコミットは自動的にpull requestに表示されますが、レビュアーはコメントした時のみ通知されます。pull requestは複数のブランチが混在することなく、mainブランチに対して最新状態からのforkになるようにrebaseされている必要があります。

[sago35]

とてもよさそう。

意味単位になるようにsquashを行う。
無理に squash しなくてよいと思っています。
分かれている commit を squash するのは簡単なので。
squash が必要かどうか考えなくてもよいぐらい小さい範囲の PR だと嬉しいですね。

[sago35]

これはgithub上でREADME.mdを編集したもの。

あぁ、なるほどそういう話なのか。

[rdon-key]

　□意味単位になるようにsquashを行う。

私もsquashの扱いって難しいと感じています。
ガイドラインからは削除しましょうか。

[rdon-key]

あとは作例の入れ方かな...
README.mdは書いてもらったほうがいいかと。
番号はどうしましょうか?

[sago35]

番号はいったんなるべく小さい値で、というぐらいかな。
Checker とか、運営都合のものは 81 とかにするかも、ですが通常のは 24 とか 25 とかが良いです。

[sago35]

新しく、midi を使う例、とかを書いてもらったときは専用の解説も欲しいですが、たぶん PR 内で都度調整するか、私が書くか、という感じになりそう。

[rdon-key]

ありがとうございます。README.mdは書いても書かなくてもいいって感じにしましょうか。

[rdon-key]

適当に文を加えてpull requestしました。

[sago35]

merged.
ありがとうございました！ @rdon-key