![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2026-04-29T17:04:31+09:00","","") #author("2026-04-29T17:12:20+09:00","","") * Zenn + awesome list (neovim) [#f5589970] ** AI:初めてawesome listにPRを出して通った話 [#k78e778c] # 初めてawesome listにPRを出して通った話 ** はじめに [#s1184cbd] ## はじめに Neovimの自作プラグインをGitHubでOSS公開しました。 ZennとRedditで告知したので次は「awesome list掲載」を目指しました。 結果無事掲載されたのでその流れとポイントをまとめます。 ZennとRedditで告知したので、次は「awesome list掲載」を目指しました。 これから同じことをやろうとしている方の参考になれば嬉しいです。 結果、無事に掲載されたので、その流れとハマりどころをまとめます。 ** awesome listとは [#h5ffe6d7] これから挑戦する方の参考になれば嬉しいです。 --- ## awesome listとは awesome listは、特定分野の良質なツールをまとめたキュレーションリストです。 Neovimの場合は「[[awesome-neovim:https://github.com/rockerBOO/awesome-neovim]] 」があり、ここに掲載されると： Neovimには「awesome-neovim」があり、ここに掲載されると： - 信頼性が上がる - 継続的な流入が期待できる - 他のサイトにも拾われやすくなる * 信頼性が上がる [#cdbe75d3] * 継続的な流入が期待できる [#j45dc71f] * 他サイトにも拾われやすくなる [#w8afbb50] といったメリットがあります。 ** やったこと（全体の流れ） [#a9de39bb] 大まかな流れは以下の通りです。 1. [[Contribution Guidelines:https://github.com/rockerBOO/awesome-neovim/blob/main/CONTRIBUTING.md]]を読む 2. forkする 3. README.mdに1行追加 4. PRを作成 5. CIエラー対応 6. Suggested change対応 7. マージ --- ** Step 1: Contribution Guidelinesを読む [#j4431073] ## やったこと（全体の流れ） まずはルール確認です。 1. Contribution Guidelinesを読む 2. forkしてREADMEに1行追加 3. PR作成 4. CIエラー対応 5. Suggested change対応 6. マージ 特に重要だったポイント： - 1行の説明はシンプルに - 「for Neovim」などは書かない - 文末はピリオドをつける - 絵文字禁止 ここを外すとCIで落ちます。 --- ** Step 2: forkして編集 [#d408a201] ## PR作成まで リポジトリをforkして、README.mdに自分のプラグインを追加します。 最初に悩んだのは「どのセクションに入れるか」でした。 ここで少し悩んだのが「どのセクションに入れるか」でした。 - Editing Support - Markdown and LaTeX - CSV files * Editing Support [#k97a2dac] * Markdown and LaTeX [#w98e909a] * CSV files [#tcd6f8ef] などが候補でしたが、 > 一番ユーザーが探しそうな場所 という観点で「Markdown and LaTeX」に入れました。 --- ** Step 3: 1行説明を書く [#v78b95e3] ## CIで落ちる（ここが一番のハマりどころ） 最初はこんな感じにしました： 最初のPRはCIで落ちました。 原因は、説明文に `&` を使っていたことです。 ```text Structural Markdown & CSV table editor with lossless round-trip. ``` ただし後で修正が入ります（後述）。 awesomeのルールでは `&` は使わず、`and` にする必要があります。 --- ** Step 4: PRを作成 [#i3ffcfd8] forkしたリポジトリからPRを作成します。 ここで重要だったのは： - テンプレートを壊さない - checklistを全部満たす --- ** Step 5: CIで落ちる [#w56fc27d] 最初のPRはCIで落ちました。次で失敗している様です。 ./scripts/readme-check.sh -v ... Fixing and ==> CHANGED ... 「"&" はNG」でした。次のように直しました。 ```text Structural Markdown and CSV table editor with lossless round-trip. ``` こういったフォーマットの違いでCIが落ちるので注意が必要です。 --- ** Step 6: Suggested changeが来る [#j7c80a99] ## Suggested changeが来る レビューでこういう提案が来ました： レビューで次のような修正提案が来ました： ```diff - Structural Markdown and CSV table editor with lossless round-trip. + Edit Markdown and CSV tables with lossless round-trip. ``` ここで学んだのは： ポイントは： - 抽象的な言葉は避ける - 動詞で始めると分かりやすい * 抽象的な表現（Structural）を削る [#u6e064a0] * 動詞（Edit）で始める [#g7a5aebf] 👉 そのまま「Commit suggestion」を押して反映しました --- ** Step 7: マージ [#i4f038a6] ## マージ 修正後、CIが通り、そのままマージされました。 特に追加のやり取りはなく、比較的スムーズでした。 --- ** やってみて分かったこと [#u7ad3f95] ## やってみて分かったこと **# �� シンプルが正義 [#l82c7f1e] ### �� シンプルが通る 説明は短く・具体的にする方が通りやすいです。 説明は短く・具体的な方が通りやすいです。 --- **# �� フォーマットが重要 [#a5657ef6] ### �� フォーマットで落ちる 内容よりも： - ピリオド - 空白 - 書式 * 記号（& など） [#y38b8a6a] * ピリオド [#w605e2f2] * 空白 [#o2f53146] で落ちることが多いです。 でCIが落ちることがあります。 --- **# �� Suggested changeには従う [#g28d6c35] ### �� Suggested changeには従う メンテナのスタイルに合わせるのが一番早いです。 --- **# �� カテゴリ選びが重要 [#r591ac3c] ### �� カテゴリ選びが重要 どこに置くかで「見られる数」が変わります。 どこに置くかで見られ方が変わります。 --- ** マージ後に起きたこと [#a7bf18bf] ## マージ後 - GitHub starsが少し増加 - 信頼性が上がった感触 - 他サイトに載る可能性が出てきた * GitHub starsが少し増加 [#g033dff4] * 信頼性が上がった感触 [#w25b1c33] * 他サイトに載る可能性が出てきた [#hf8db090] ※即バズるわけではなく「じわじわ効く」タイプです --- ** これからやること [#e494b459] ## まとめ - neovimcraftへの掲載を待つ - READMEの微調整 - 他の場所での軽い再告知 --- ** まとめ [#yf5c75c1] awesome listへの掲載は、 - 難易度はそこまで高くない - ただしルールは厳密 - 小さな改善の積み重ねが大事 * 難易度はそこまで高くない [#afbdd166] * ただしルールは厳密 [#tdb4d4c2] * 小さな差分でCIに落ちる [#x8d535e7] という印象でした。 --- ** おわりに [#he601562] ## おわりに 初めてのPRでしたが、思ったよりスムーズに進みました。 同じように： * 自作プラグインを広めたい [#p570267a] * 信頼性を上げたい [#ca4a7c96] - 自作プラグインを広めたい - 信頼性を上げたい と考えている方にはおすすめです。 もしこれから挑戦する方の参考になれば嬉しいです。 もし参考になれば嬉しいです。
