開発者のための手引きを整備する

[misogihagi]

内容

docs/CONTRIBUTING.md
にreadmeより詳しい開発環境を用意する。

ベストプラクティスとかあれば

その他

[tarepan]

初回コントリビューション時にかなり迷ったため、こちらの issue に賛成です。

現在の README.md には「ユーザー向け」「forkするエンジニア向け」「コントリビュータ向け」の内容が混在しています。
ゆえに現在出されている CONTRIBUTING.md 追加PRと平行して、README.md の整理が必要です。
README.md コンテンツのうち、コントリビュータのみに関連する内容を新設の「貢献者ガイド」節へ集約することでひとまず整理が可能だと考えます（後に CONTRIBUTING.md と統合）。
よって貢献者ガイド節への集約によるリファクタリングを提案します。

@Hiroshiba
こちらの方針でリファクタリングPRを作成しても良いでしょうか？
draft PRを作成した（#838）ので、判断材料にご利用ください。

[Hiroshiba]

@tarepan 良いと思います！！
「ユーザー向け」「コントリビュータ向け」「その他」という手もありそうに思いました！
続きはPRの方にコメントさせていただきます！！

[tarepan]

CONTRIBUTING.md 品質向上

リリース前に改善すべき点:

すみません、ちょっとリリースするにはCONTRIBUTING.mdのリファクタリングがもうちょっと必要かなと思いました！

まだパッと見ただけですが気になった点を列挙してみます 🙇

• フォーマットされてない
• 表記ゆれ（VOICEVOX/voicevox）
• ####の数がおかしいときがありそう
• 「インストール」項目でインストール案内していない（多分言いたいことは「環境構築」）
• 「セットアップ」項目がかなり説明不足（「以下のコマンドで使用できるようになります。」で何が使用できるのかがわからない、とか）

Hiroshiba. (2024). #1119 (review).

[tarepan]

@Hiroshiba
#1119 のレビューありがとうございました。
#1119 はリリース PR であるため、別 PR として更なるリファクタリングを先行させます（#1119 は draft 化しています）。

---

フォーマットされてない

markdown フォーマッタが README.md で案内されていないと認識しています。
VOICEVOX ENGINE として「commit 前に markdown フォーマッタをかける」のであれば、フォーマッタ指定が必要そうです。

[Hiroshiba]

markdown フォーマッタが README.md で案内されていないと認識しています。
VOICEVOX ENGINE として「commit 前に markdown フォーマッタをかける」のであれば、フォーマッタ指定が必要そうです。

たしかにです。
今まではなんとなくVSCodeのデフォルトのフォーマッタに従って、たまにフォーマットしてあげる感じで運用していました。

以前はpythonのmarkdownのlinterがあまり発展してなかった印象なのですが、最近は結構いいのもありそう？
https://pypi.org/project/pymarkdownlnt

ちなみにエディタの方は導入されているのでActionsの流れとか参考になるかもです
https://github.com/VOICEVOX/voicevox#markdownlint
https://github.com/VOICEVOX/voicevox/blob/05926fbd02c210a8ef151420bc703a33b0fd293f/.github/workflows/test.yml#L204

[tarepan]

Actionsの流れとか参考

👍
ありがとうございます、参考になります。

VSCodeのデフォルトのフォーマッタ

VSCode でフォーマットを実行した（> Format Document）ところ、フォーマッタ指定が必須でした。
おそらくですが、VSCode はデフォルトのフォーマッタを持っていません。@Hiroshiba さんが別用途でインストールしたフォーマッタが自動利用されているのかと推察します。

となると、各自がそれぞれのフォーマッタをかけて無為な diff が増える懸念があります。
統一フォーマッタが最善策ですが、確かに（成熟度的な観点から）Python の markdown フォーマッタ選びはそれなりに気を使いそうです。

提案ですが、markdown フォーマッタの選定は将来展望とし、#1130 に関してはフォーマッタを掛けないで resolve し、その後 @Hiroshiba さん側で追加 PR としてフォーマットしていただき、そのうえでリリース #1119 という形はどうでしょうか？
markdown のフォーマットは実際のところそんな高頻度でないことを考えると、コスパを考慮した折衷案としてありうるかと考えます。

[sevenc-nanashi]

pythonのmarkdownのlinter

個人的な気持ちですが、Linterとかのツールの言語は気にしなくても良いと思います（それ言いだしたらtyposやactionlintはどうなるのってなりますし）

[Hiroshiba]

markdownのフォーマッターは、主にwebフロント側でフォーマッタとして利用しているPrettierでフォーマットしていました 🙇
たぶんこちらです！ https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode

気を向いた時に気が向いた人がフォーマットをかける方針で問題ないと思います！