#1 OSSプロジェクト立ち上げ初日の4つの設定 - PythonOSS開発記録
karrinn
著者
OSSプロジェクトを立ち上げる時、最初の1時間で何をやるべきなのか？実はここでの意思決定が後々めちゃくちゃ効いてきます。
今回は実際に私が立ち上げたwagtail-reusable-blocksプロジェクトを例に、初日にやった4つの設定を振り返ります。
KEY TAKEAWAYS
この記事でわかること
- リポジトリ作成時に「なぜこう決めたか」の判断基準
- README・LICENSE・.gitignoreの実践的な設計方法
- 実プロジェクトの生々しい初日作業記録
用語の定義
TERM 01
GitHubリポジトリ
プロジェクトのコード・ドキュメント・Issue・PRを一元管理するGit版管理システムのホスティングサービス。OSSプロジェクトの中心的なコミュニケーション基盤。
TERM 02
README.md
プロジェクトの「顔」となるドキュメント。What・Why・Howを伝え、コントリビューターを獲得するための営業資料的役割を持つ。
TERM 03
LICENSEファイル
ソフトウェアの利用・改変・再配布の条件を明示する法的文書。適切なライセンス選択は、コントリビューター参加障壁を下げる。
TERM 04
.gitignore
Gitの追跡対象から除外するファイルパターンを定義。ビルド成果物・IDE設定・機密情報の誤コミットを防ぐセキュリティ対策。
そもそも何を作っているの？
まず、この記事シリーズで題材にしているwagtail-reusable-blocksについて簡単に説明しておきます。
解決したかった課題
Wagtail CMSで普段いろんな実装をしていく中で、「レイアウトブロックを再利用して、その中の特定の位置に他のブロックを差し込みたい」というニーズがずっとありました。
Reactのslot概念みたいに、デプロイなしでコンテンツ管理者が管理画面だけで柔軟にレイアウトを組めたら便利じゃないですか？
コアアイデア: ReusableBlock（外枠テンプレート） + SlotPlaceholder（差し込み位置） + SlotFill（実際の中身）
Phase 1
v0.1.0 MVP
基本的な再利用ブロック
Phase 2
v0.2.0 Slot
スロットベーステンプレート
Phase 3
v0.3.0 Polish
パフォーマンスと運用機能
ステップ0: そもそもどう作るか？
※脱線、長文のため折りたたんでいます
ステップ0: そもそもどう作るか？
※脱線、長文のため折りたたんでいますリポジトリを作る前に、超重要な意思決定がありました。「外部ライブラリとして作るか、Wagtail本体への機能リクエスト（PR）にするか」です。
2つの選択肢
| 選択肢 | メリット | デメリット |
|---|---|---|
| 外部ライブラリ |
・自分のペースで開発できる ・意思決定権を持てる ・実験的な機能を試せる ・リリースタイミング自由 |
・自分でメンテナンス必要 ・ユーザー獲得が大変 ・Wagtailバージョン対応 |
| Wagtail本体PR |
・全ユーザーに届く ・コアチームがメンテナンス ・認知度が高い |
・レビュープロセスが厳しい ・コーディング規約が厳格 ・マージまで時間かかる ・挫折しやすい |
結論: 外部ライブラリで始めた
wagtail-reusable-blocksは外部ライブラリとして開発することにしました。理由は3つ。
理由1
自分のペースで開発したい。本体PRだとレビュー待ちで止まる。
理由2
実験的な機能だから。Slot Systemが本当に使えるか試したい。
理由3
意思決定権を持ちたい。APIとか命名とか、自分で決めたい。
Wagtail自体の「Lean Core」哲学を理解する
外部ライブラリで作ると決める前に、Wagtailというエコシステムの哲学を理解しておくのが超重要でした。
Wagtail ≠ WordPress
WagtailはWordPressのような「最初から全機能入り」を意図的に避けてるCMSです。
WordPress:
- ブログ・プラグイン・テーマ・コメント・メディア管理、全部標準搭載
- 初心者でもすぐ使えるが、カスタマイズは複雑
Wagtail:
- コアは軽量で柔軟、必要な機能だけ追加
- 開発者が自由に設計できる（Django + Wagtail）
実例: wagtail-modeladmin
Wagtail 6.0でwagtail.contrib.modeladminがcoreから削除され、外部パッケージwagtail-modeladminとして切り出されました。
理由:
- Wagtailは「lean core（軽量なコア）」を維持したい
- 高度な機能は外部パッケージとして提供
- 必要な人だけインストールすればいい
他の事例: wagtail-localize
多言語対応の高度な機能を提供するwagtail-localizeも、最初から外部パッケージとして開発されています。
つまり: Wagtailエコシステムでは外部パッケージで始めるのが正しい戦略。
「外部→本体」への道もある
外部パッケージで始めても、後から本体に提案する道は残ってます。
推奨される流れ
- 外部パッケージで開発 → 自由に実験・フィードバック収集
- コミュニティで成熟 → 実際のプロジェクトで使われて改善
- ニーズが証明される → 「これ便利だよね」が広まる
- 本体への提案を検討 → または外部パッケージとして維持（それも全然あり）
周辺理解をサボると、取り返しのつかない手戻りになる
超重要:作るものの関連技術・周辺エコシステムの理解をサボると、あとあと地獄を見ます。
wagtail-reusable-blocksで最低限やったこと:
Wagtailのlean core哲学を理解 → 既存パッケージ調査 → 外部ライブラリとして開発と判断。これだけで方向性が決まった。
実例: Django拡張機能開発案件での失敗
私自身、toBのDjango拡張機能開発案件に関わった時、初期設計のミスで地獄を見ました。
何が起きたか
- 拡張機能の導入方法の設計ミス → インストール手順が複雑すぎた
- ほとんどの人が構造的欠陥に気づいていない → 「なんか大変だけど、こういうものか」で進行
- 新部署へのオンボーディングコストが異常に高い → 導入に毎回数週間
- 後から直せない → 既に10部署が導入済み、全部に影響
なぜこうなったか
Djangoの拡張機能開発の「お作法」を理解せずに設計してしまった。
- Django appの標準的なインストール方法を調査しなかった
- 既存の成功してるDjango拡張の導入フローを研究しなかった
- 「とりあえず動けばいい」で初期設計を急いだ
- → 結果、独自の複雑な導入手順になり、全社展開で破綻
一般化すると、こういう手戻りが起きる
周辺理解をサボると、「車輪の再発明」「方向性の大転換」「エコシステム違反」「技術選定ミス」のどれかに必ずハマります。
プロジェクト初日に調査すべきこと
OSSでも企業プロジェクトでも、最低限この5項目は初日に調査してください。
| 調査すべき項目 | OSS（Wagtail拡張） | 企業PJ（社内システム） |
|---|---|---|
| 既存ソリューション | 類似パッケージ調査 | 社内の既存システム・ライブラリ |
| 技術スタック | Wagtail/Djangoバージョン対応 | 社内標準技術、インフラ制約 |
| エコシステム | Wagtailの哲学・慣習 | 社内アーキテクチャ方針 |
| 将来計画 | 本体ロードマップ | 社内IT戦略・技術ロードマップ |
| コミュニティ | Slack、GitHub Discussions | 社内の他チーム・部署との調整 |
だからプロジェクト初日に、チームでガッツリ時間をかけて
- 「どう作るか」は、後から変更すると影響範囲がデカすぎる
- リポジトリ名、パッケージ構造、命名規則、すべてこの判断に影響される
- 「あとで変えればいいや」は絶対に通用しない
- チームメイトと1日かけて議論・調査する価値がある
ステップ1: GitHubリポジトリ作成
「外部ライブラリで作る」と決まったら、次はリポジトリ名どうするか問題。これも後から変えるとリンク全部壊れるので初日に決めます。
どう決めたか
1. リポジトリ名の命名
これはPyPIパッケージ名と完全一致させることにしました。後でユーザーが混乱しないためです。
| 項目 | 判断 | 理由 |
|---|---|---|
| リポジトリ名 | wagtail-reusable-blocks | PyPIパッケージ名と完全一致 |
| 命名規則 | ハイフン区切り | GitHub標準、視認性が高い |
| プレフィックス | wagtail- | エコシステム内での発見性向上 |
2. Public vs Private（プロジェクト種別で変わる）
これ、プロジェクトの性質で判断が全然違います。両方のケースを見てみましょう。
Public 一択
wagtail-reusable-blocksはこっち。理由：
- どうせPyPIで公開するんだから最初から見せちゃう
- 開発の透明性を保ってコミュニティからフィードバックもらえる
- GitHub Actionsが無制限（Private repos: 月2,000分の制限あり）
- GitHub Pagesも無料で使える
ポイント: OSSは開発過程を見せること自体が価値。「まだ未完成だから...」と隠す必要ゼロです。
Private 推奨
企業の社内システム・クライアントワークはこっち。理由：
- ビジネスロジックや機密情報が含まれる可能性
- クライアントとのNDA（秘密保持契約）がある
- 競合他社に見られたくない独自機能
- 公開前提じゃないコード品質でもOK
注意: Privateでも.envファイルはコミットしない！内部犯行リスクもあるので。
コスト: GitHub Freeでも無制限のPrivateリポジトリ＆コラボレーター利用可能。高度な機能（Code owners、必須レビュアーなど）が必要ならGitHub Team（月$4/人）。
3. GitHubプランの選択（企業は予算検討が必要）
Privateリポジトリを作る場合、GitHubの無料プランと有料プランで使える機能が全然違います。
特に企業プロジェクトでは、後から「あの機能使えない...」となって予算申請するのは地獄なので、初日に確認しておきましょう。
超重要: Privateリポジトリでは無料プランで使えない機能がある
GitHubの無料プランではPrivateリポジトリで制限される機能があります。
この記事シリーズで扱うトピックのうち、以下は有料プラン必須です（Privateリポジトリの場合）：
- トピック#5: GitHub Rulesets（ブランチ保護）→ Privateは有料プラン必須
- トピック#7: CODEOWNERS（自動レビュー割り当て）→ Privateは有料プラン必須
Publicリポジトリなら、全機能無料
wagtail-reusable-blocksのようなOSSプロジェクトは、Publicリポジトリで作る限り、GitHub Freeで全機能使えます。
無料で使える主な機能（Publicリポジトリ）:
- GitHub Rulesets: ブランチ保護・命名規則の強制
- CODEOWNERS: 自動レビュー割り当て
- GitHub Actions: 無制限（Publicリポジトリのみ）
- GitHub Pages: 静的サイトホスティング
- GitHub Packages: 500MB無料ストレージ
結論:OSSプロジェクトならGitHub Freeで問題なし。この記事シリーズの全トピックが無料で実践できます。
Privateリポジトリは有料プラン検討が必要
企業の社内システムやクライアントワークでPrivateリポジトリを使う場合、予算申請時に必要な機能を明確化しておかないと、後で困ります。
| プラン | 料金 | Privateリポジトリで使える主な機能 | トピックとの関係 |
|---|---|---|---|
| GitHub Free | 無料 |
・無制限のPrivateリポジトリ ・無制限のコラボレーター ・GitHub Actions: 2,000分/月 ・基本的なブランチ保護のみ | Rulesets使えない CODEOWNERS使えない |
| GitHub Pro | $4/月 （個人アカウント） |
・Freeの全機能 ・GitHub Rulesets ・CODEOWNERS ・Actions: 3,000分/月 ・GitHub Codespaces | トピック#5〜#7対応 |
| GitHub Team | $4/人/月 （組織） |
・Proの全機能 ・組織レベルのアクセス管理 ・チームレビュー機能 ・Actions: 3,000分/月/人 | 全トピック対応 企業推奨 |
| GitHub Enterprise | $21/人/月〜 |
・Teamの全機能 ・SAML SSO ・GitHub Advanced Security ・監査ログ ・50,000分 Actions/月 | 全トピック対応 大企業・セキュリティ要件高い場合 |
プロジェクト初日に確認すべき質問
企業プロジェクトでは、以下の質問に答えてからプラン選択してください：
Q1: ブランチ保護を強制したい？
→ YES: GitHub Team以上必要
→ NO: GitHub Free
関連トピック: #5 Rulesets、#6 ブランチ命名規則
Q2: レビュアー自動割り当て使いたい？
→ YES: GitHub Team以上必要
→ NO: GitHub Free
関連トピック: #7 CODEOWNERS
Q3: CI/CDをどれくらい回す？
→ 月2,000分以上: GitHub Team推奨
→ 月2,000分未満: GitHub Free
補足: 10人チームなら月30,000分使える（Team）
Q4: 組織の権限管理が必要？
→ YES: GitHub Team以上必須
→ NO: Personal + Freeで可
補足: 5人以上のチームなら最初からOrganization + Team推奨
コスト試算例
5人チーム、Privateリポジトリ、Rulesets + CODEOWNERS使いたい:
- GitHub Team: $4/人/月 × 5人 = $20/月（約3,000円/月）
- 年間: 約36,000円
- → 新人1人のオンボーディングコスト削減だけで元が取れる
予算申請時のアピールポイント
「GitHub有料プランの予算ください」を通すための説明材料：
1. システムによる自動防御 = 人的ミスの削減
- Rulesets: ブランチ命名ミス・直pushをシステムが防ぐ
- CODEOWNERS: レビュー漏れをシステムが防ぐ
- → 「注意して！」と人に頼るより確実
2. 新人の萎縮を防ぎ、開発効率を維持
- 「これやったらシステム壊れるぞ」と脅す必要がなくなる
- 安心して失敗できる環境 → 新人が「えい」って試せる
- → オンボーディング期間が半分になる（実体験）
3. 属人化の解消
- 「〇〇さんがいないとレビューできない」をなくす
- CODEOWNERSで自動的に適切な人にレビュー依頼
- → ボトルネック解消、休暇取りやすくなる
まとめ:企業でPrivateリポジトリを使うなら、GitHub Team（$4/人/月）を初日から予算確保しておくのが正解。後から「使えません」は地獄です。
4. Organization vs Personal
→ wagtail-reusable-blocksはPersonal（kkm-horikawa）
これは正直悩みました。でも：
- まだ個人開発の段階、スピード重視で進めたい
- 後でOrganizationに移譲できる（GitHubの標準機能）
- v0.3.0くらいでコミュニティができたら考え直せばいい
実際、初期は自分ひとりで爆速で進める方が効率いいので、Personalで正解だったと思います。
企業プロジェクトの場合: 最初からOrganizationにしておくと、メンバー追加・権限管理がラク。退職者のリポジトリ問題も防げます。
実装: ghコマンドでの作成
GitHub CLIを使うと、コマンドラインで効率的にリポジトリを作成できます。
このコマンドで一発:
- リポジトリ作成
- ローカルクローン
- 初期コミット
手動でGitHub開いてポチポチするより断然速いです。
gh repo create wagtail-reusable-blocks \ --public \ --description "Reusable content blocks with slot-based templating for Wagtail CMS" \ --clone
ステップ2: README.md設計
READMEって実はプロジェクトの営業資料なんですよね。ここで「お、これ良さそう」と思ってもらえるかが勝負。
どう設計したか
必須セクションの構成（プロジェクト種別で変わる）
READMEの構成も目的によって最適解が違います。
wagtail-reusable-blocksのような公開パッケージ:
| セクション | 目的 | 読者の疑問 |
|---|---|---|
| バッジ | 信頼性の可視化 | 「このパッケージは信頼できる？」 |
| What is this? | 1行で価値を伝える | 「これは何をするもの？」 |
| Use Cases | 具体的な利用シーン提示 | 「自分のプロジェクトで使える？」 |
| Installation | 最速で試せる手順 | 「どうやって始める？」 |
| Quick Start | 5分で動く最小コード | 「すぐに試せる？」 |
| Roadmap/Milestones | 開発状況の透明性 | 「開発は続いてる？」 |
社内システム・クライアントワークの場合:
| セクション | 目的 | 読者（チームメンバー）の疑問 |
|---|---|---|
| プロジェクト概要 | ビジネス目的を明示 | 「なぜこのシステムを作ってる？」 |
| 環境構築 | 新メンバーが即座に始められる | 「自分のPCで動かすには？」 |
| アーキテクチャ | システム構成の把握 | 「どんな技術スタック？」 |
| 開発フロー | コミット・デプロイルール | 「ブランチ戦略は？」 |
| テスト実行 | 品質保証の手順 | 「テストどうやって回す？」 |
| デプロイ手順 | 本番反映の方法 | 「staging/productionへの上げ方は？」 |
| トラブルシューティング | よくあるエラーと対処 | 「これエラー出たんだけど...」 |
ポイント: 企業プロジェクトのREADMEは「新人が1日目で開発環境構築できる」が目標。マーケティング要素ゼロ、実用性100%でOK。
バッジは信頼の証
あのカラフルなバッジ、実は「このプロジェクト大丈夫？」という不安を消す効果があります。
- PyPI version: ちゃんと公開されてるよアピール
- License: 安心して使っていいよの証明
- 将来追加予定: CI status（テスト通ってるよ）、Coverage（品質高いよ）、Downloads（人気あるよ）
初期はバッジ少なくても全然OK。むしろ後で充実させていく過程もプロジェクト成長の証になります。
英語 vs 日本語問題（意外と迷う）
README・コメント・コミットメッセージ、英語で書くべき？日本語でいい？これ日本では超悩みますよね。
wagtail-reusable-blocks は全部英語
理由: Wagtailは英語圏のユーザーが圧倒的に多いから。
| 項目 | 言語 | 理由 |
|---|---|---|
| README | 英語 | PyPI・GitHubでの発見性向上 |
| コード・コメント | 英語 | 国際的なコントリビューター対応 |
| コミットメッセージ | 英語 | 履歴を英語圏の人も読める |
| Issue・PR | 英語 | 誰でも参加できる環境 |
| ドキュメント | 英語 | グローバル展開を想定 |
判断基準:
- ターゲットユーザーが英語圏なら迷わず英語
- Django・Flask・FastAPI系 → 英語推奨
- 完璧な英語じゃなくてOK。Grammarly使えば十分
日本企業プロジェクトは全部日本語でOK
結論: チーム全員が日本人なら日本語の方が圧倒的に効率的。
| 項目 | 言語 | 理由 |
|---|---|---|
| README | 日本語 | 新人がすぐ理解できる |
| コメント | 日本語 | ビジネスロジックを母国語で説明 |
| コミットメッセージ | 日本語 | 「なぜこの変更？」が伝わりやすい |
| Issue・PR | 日本語 | 議論の速度が上がる |
| 変数名・関数名 | 英語 | コードの可読性（慣習） |
日本語のメリット:
- ドメイン知識（業務用語）を正確に表現できる
- レビューコメントが圧倒的に速い
- 「英語にするとニュアンスが...」のストレスゼロ
注意点:
- 変数名・関数名は英語で（
ユーザー名取得()じゃなくgetUserName()） - 将来的に外国人メンバー参加の可能性があるなら英語検討
- OSSライブラリにコントリビュートする時は英語で
実装: wagtail-reusable-blocksの実例
1. バッジの追加
READMEの冒頭にこれを貼るだけ。
表示される内容:
- PyPIの最新バージョン番号
- ライセンス情報
[](https://badge.fury.io/py/wagtail-reusable-blocks) [](https://opensource.org/licenses/BSD-3-Clause)
2. 価値提案の明確化
既存ソリューションとの差別化ポイントを表で可視化。
なぜ表形式？
- 比較が一目瞭然
- 「何が違うの？」に即答
- 太字で強調できる
| Feature | Snippets | Page Blocks | **Reusable Blocks** | |---------|----------|-------------|---------------------| | Reusable across pages | No | No | **Yes** | | StreamField support | Limited | Yes | **Yes** | | Single source of truth | Yes | No | **Yes** | | Slot/placeholder support | No | No | **Yes (v0.2.0+)** |
3. ビジョンの可視化（Mermaid図）
実例:README内のMermaid図でSlot Systemの動作を可視化
GitHubが標準対応してるので、コードブロックに書くだけで自動で図になります。「テンプレートの再利用 + ページごとに異なるコンテンツ注入」の概念を1つの図で表現できて超便利。
ステップ3: LICENSE選択
ライセンス選び、これ地味にめちゃくちゃ重要です。でもプロジェクトの種類で必要性が全然違います。
LICENSE要る？要らない？
LICENSE必須（超重要）
wagtail-reusable-blocksはBSD-3-Clauseを選択。
なぜLICENSEが必要？
- ライセンスファイルがないと「使っていいのか分からない」
- 企業の法務部が許可出せない
- 著作権保護のため（勝手に商用利用される危険）
なぜBSD-3-Clauseを選んだか:
| ライセンス | 特徴 | wagtail-reusable-blocksでの評価 |
|---|---|---|
| BSD-3-Clause |
・寛容なライセンス ・商用利用OK ・著作権表示必須 ・派生物でのライセンス強制なし | 採用 ・Django/Wagtail本体と同じ ・エコシステムの慣習に従う ・企業利用の障壁が低い |
| MIT |
・最も寛容 ・商用利用OK ・著作権表示必須 |
選択肢として有力だが、 Wagtailとの統一感を優先 |
| Apache 2.0 |
・特許条項あり ・商用利用OK ・より法的保護が強い |
過剰に厳格、 コントリビューター障壁が高い |
| GPL系 |
・コピーレフト ・派生物も同じライセンス必須 | 不採用 企業利用の障壁が高すぎる |
決め手になったポイント
- Django・Wagtail本体と同じライセンスだから違和感ゼロ
- Pythonエコシステムでは定番（Django拡張はだいたいBSD）
- 企業が「これ使っていいの？」って法務に聞かなくて済む
LICENSE不要（社内のみ）
結論: 社内システム・クライアントワークならLICENSEファイルは不要です。
なぜ不要？
- 外部に公開しないので、利用条件を明示する必要がない
- 著作権は会社または雇用契約で既に定義されている
- むしろLICENSEがあると「誰が使える？」で混乱する
- クライアントワークは契約書で権利関係が決まっている
例外: 社内OSSとして他部署や関連会社にも公開する場合は、社内向けライセンスを検討。でもレアケース。
代わりに必要なもの:
- README: 「このシステムは○○社の資産です」と明記
- 雇用契約: 業務で作ったコードの著作権が会社にあることを確認
- クライアント契約書: 納品物の権利帰属先を明確に
実装: LICENSEファイルの追加
方法1: GitHub UIでの設定（初心者向け）
- リポジトリページで「Add file」→「Create new file」
- ファイル名に「LICENSE」と入力
- 「Choose a license template」ボタンをクリック
- 「BSD 3-Clause License」を選択
- 著作権者名（karrinn）と年（2025）を入力してコミット
方法2: コマンドでサクッと追加
コマンドライン派はこっちが速い。
やってること:
- 公式サイトからテンプレート取得
- 年と名前を置換
- コミット＆プッシュ
# LICENSE テンプレートをダウンロード curl -sL https://opensource.org/licenses/BSD-3-Clause \ | sed 's/<year>/2025/g' \ | sed 's/<copyright holders>/karrinn/g' \ > LICENSE # コミット git add LICENSE git commit -m "chore: add BSD-3-Clause license" git push
忘れずに: pyproject.tomlにもlicense = { text = "BSD-3-Clause" }って書いておくと、PyPI公開時にライセンス情報が正しく表示されます。
ステップ4: .gitignore設計
.gitignore、地味だけどセキュリティ的に超重要。.envファイルをうっかりコミットしてAPIキー漏れとか、マジで洒落にならないので。
これはOSSでも企業でも必須
Public/Privateに関わらず、.gitignoreは絶対に設定してください。機密情報の漏洩リスクは両方とも同じです。特に.envファイル・データベースファイル・IDE設定は必ず除外。
何を除外するか
Pythonプロジェクトの定番
| カテゴリ | パターン | 理由 |
|---|---|---|
| Pythonバイトコード | __pycache__/*.pyc | 実行環境ごとに生成、共有不要 |
| ビルド成果物 | dist/build/*.egg-info/ | PyPI公開時に自動生成、バージョン管理不要 |
| 仮想環境 | .venv/venv/ENV/ | 環境ごとに再構築、容量が大きい |
| IDE設定 | .idea/.vscode/*.swp | 個人の環境設定、他者と共有不要 |
| テストキャッシュ | .pytest_cache/.mypy_cache/.coverage | 実行ごとに生成、共有不要 |
| 機密情報 | .env*.db*.sqlite3 | セキュリティリスク、絶対に共有してはいけない |
| OS固有 | .DS_StoreThumbs.db | OS自動生成、開発に不要 |
絶対に除外すべきもの
.envファイル → APIキー漏れたら終わり*.db,*.sqlite3→ 開発用データベースに個人情報入ってたらアウト- IDE設定（
.vscode/など） → ローカルパスとか個人情報が紛れ込む
実装: wagtail-reusable-blocksの実例
実際に使っている.gitignoreファイルの全文です。
カテゴリ別に整理:
- Pythonバイトコード
- ビルド成果物
- 仮想環境
- IDE設定
- テストキャッシュ
- 機密情報（超重要）
- OS固有ファイル
ラクする方法:GitHubの公式テンプレートをコピペして、プロジェクト固有の設定を足すだけ。
将来Docker使うならdocker-compose.override.ymlも追加推奨。
# Byte-compiled / optimized / DLL files __pycache__/ *.py[cod] *$py.class # Distribution / packaging dist/ build/ *.egg-info/ *.egg # Virtual environments .venv/ venv/ ENV/ # IDE .idea/ .vscode/ *.swp *.swo # Testing .pytest_cache/ .coverage htmlcov/ .tox/ .mypy_cache/ # Local development *.db *.sqlite3 .env .env.local # OS .DS_Store Thumbs.db
次の記事はこちら
#2 GitHub ProjectとMilestonesでロードマップ設計 - Python OSS開発記録
記事を読む参考リンク
プロジェクト関連
- wagtail-reusable-blocks リポジトリ - 実際のREADME・LICENSE・.gitignoreを確認
- GitHub Project Board - 開発状況の透明性
- Milestones - v0.1.0〜v0.3.0のロードマップ
公式ドキュメント
ライセンス選択
- Choose a License - ライセンス選択ガイド
- BSD 3-Clause License 全文
- Django License (BSD-3-Clause) - エコシステム参考
Wagtailエコシステム
- Wagtail 6.0 release notes - wagtail-modeladminのcore削除について
- wagtail-modeladmin - PyPI - coreから切り出された外部パッケージ
- wagtail-localize - 最初から外部パッケージの事例
- Wagtail Packages - 250+の外部パッケージ一覧
まだコメントはありません。最初のコメントを残しませんか？