テーマ： open-source
-
日程を決めたドキュメンテーションデーは、常設のドキュメント支援募集より多くの初参加コントリビューターを呼び込む
仮説: 厳選された小さなドキュメント課題のリストを用意し、当日中にレビューできるメンテナーを配置し、各タスクにgood-first-issueラベルを付けた1日を告知するプロジェクトは、同じリストを1年中オープンにしておく場合に比べて、これまで貢献したことのない人によるマージ済みドキュメント変更を多く受け取る。1つのプロジェクト自身の履歴を用いた比較を提案する。
-
After a vulnerability report arrives: acknowledge, assess, fix in private, disclose
Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.
-
小規模プロジェクトの Issue トリアージ：固定ラベルと定期的な確認
トリアージとは、新しい各 Issue が何か、対応可能か、次に誰が動くかを決めることである。種類、状態、領域の3系統の小さなラベル集合と、固定の間隔での短い確認により、トラッカーを実態に合わせる。GitHub の既定ラベル（bug、enhancement、documentation、duplicate、question、wontfix、good first issue、help wanted など）は出発点として使える。
-
Recognising contributors: a contributors table by contribution type, without rankings
The All Contributors specification calls for a Contributors section in a prominent place, as a table of name, link and contribution category, inclusive of every kind of contribution at any level, with order immaterial; it recommends against excluding anyone for a perceived low level of contribution. Git's Co-authored-by trailer credits co-authors of a single commit. Together they let a small project credit documentation, triage, design and reports, not only merged code.
-
小規模プロジェクトのリリース周期：定期リリース列車と準備が整ってからのリリース
バージョン番号はリリースが何を約束するかを示し、周期の方針はいつリリースするかを示す。Rust は nightly、beta、stable の列車で六週間ごとに安定版を出し、Python は PEP 602 で年一回の機能リリースへ移行した。Django は機能リリースを定期的に、パッチを必要に応じて出す。小規模プロジェクトも、機能は日程または目立った変更の蓄積に合わせ、パッチは修正が取り込まれるたびに出すという形を取り入れられる。
-
新規貢献者の最初の5つの問いに答える CONTRIBUTING ファイル
貢献しようとする人はコードを書く前に、その変更は求められているか、どう提案するか、プルリクエストに何が必須か、返信までどれほど待つか、マージした変更がどうユーザーに届くかを尋ねる。5つの問いに順番に答え、その他はリンクで案内する CONTRIBUTING ファイルは、スコープやテスト不足で却下されるプルリクエストを未然に防ぐことを意図している。
-
貢献者を失わずに機能要求を断る
文書化したスコープを示し、速やかに届き、代替案を挙げてスレッドを閉じる断り方は、沈黙より親切で、要求者を貢献者としてつなぎ止める。Open Source Guides は、書いておくと断りやすくなり、返答はたいてい一、二文で足りると述べている。
-
Deprecating a function in a library: warn, document the replacement, remove on schedule
A library deprecation has four parts: a replacement that exists first, a runtime warning plus a documentation note naming the version and the replacement, a changelog entry, and a removal release fixed in advance by policy. PEP 387 requires a deprecation period of at least two years under Python's annual cadence and describes a documentation-only soft deprecation; Django removes shims no earlier than two feature releases after the warning.
-
Repositories whose setup runs as one verified command receive more first-time contributions than repositories with a manual setup list
Hypothesis: GitHub's scripts-to-rule-them-all README claims that lowering setup friction is key to faster and happier contributions; the proposal restates this measurably, predicting that repositories with a single self-checking setup command show more first-time contributor pull requests, more of them green on first push, and fewer setup issues than matched repositories with manual README steps.
-
小規模プロジェクトのガバナンス：必要になる前に決定権を書き残す
ガバナンス文書は、誰がマージできるか、誰がスコープの争いを収めるか、メンテナーをどう追加・除外するか、ルール自体をどう変えるかを定める。Python の PEP 13 は、権限の行使を少なく抑え公開で審議する評議会モデルを示す。Apache の用語集は、定めた期間内に反対がなければ提案を通すレイジーコンセンサスを定義している。メンテナーが1〜3人のプロジェクトなら1ページで足りる。
-
How do maintainers of small projects actually spend their hours, and what shifted the split away from writing code?
Open question: the Open Source Guides observe that maintainers of widely used projects end up coding less and responding to issues more, and recommend documentation, saying no, sharing the load and automation as remedies; what is missing is measured time per activity for small projects, and evidence about which of those remedies changed the split.
-
Maintainer hand-over and bus factor: what a successor must be able to do on day one
A project survives its maintainer when a second person already holds every account and key, can perform a release from the written steps alone, and knows where decisions are recorded. PEP 541 shows what happens otherwise on PyPI: a project counts as abandoned only when the owner is unreachable, no release has appeared for twelve months and its home page shows no activity, and only then can it be handed to a new owner under the abandonment rule. GitHub's repository transfer moves issues, pull requests, stars and watchers with the code.
-
複数のリリース系列を支える：どの修正をどこに適用するか
サポート方針は、各リリース系列の状態（機能開発、バグ修正、セキュリティのみ、サポート終了）の表と、修正の種類ごとのバックポート先の規則で構成される。Pythonは系列に2年間のバグ修正リリースと、その後3年間のセキュリティのみのリリースを提供する。Djangoは重大な修正を直近の機能リリースに、安全性とデータ損失の修正を直近2つと長期サポート系列に戻す。Rustは最新の安定版のみを支える。小規模プロジェクトは表を公開し、守れる最小限の約束を標準とすべきである。
-
IBM i のオープンソース環境：yum、既定シェルとしての bash、SSH デーモンの起動
IBM がサポートする IBM i 向けオープンソーススタック（Node.js、Python、git、bash など）は、yum を通じて RPM として /QOpenSys/pkgs にインストールされます。推奨の対話型シェルとして bash が付属し、これらにリモートでアクセスするには、まず STRTCPSVR *SSHD で SSH デーモンを明示的に起動する必要があります。
機械可読： JSON