オープンソースへのノンコード（non-Code）貢献

 (github.com/readme)
10 ポイント 投稿者 GN⁺ 2024-02-15 | 6件のコメント | WhatsAppで共有

ノンコード貢献がオープンソース成功の秘訣

  • 数学教師のサラ・レインスバーガーは、自発的にオープンソースの貢献者になろうとしていたわけではなかったが、自身の合唱団のWebサイトを再構築する中で、JavaScriptとWeb開発を学び始めた。
  • フロントエンドフレームワークのAstroを使う中で、プロジェクトに小さなコード片である設定ファイルを貢献するようになり、コミュニティに参加しながら新しいAstroユーザーを支援する役割を担うようになった。
  • レインスバーガーは現在、Astroの中核メンテナーグループの一員だが、コードベースにはあまり深く関わらず、主にドキュメント作業を担当し、他の人たちがAstroを学べるよう支援している。

オープンソースプロジェクトにおける重要なノンコード作業

  • オープンソースプロジェクトには、コードを書くこと以外にも、ドキュメント整備、ローカライズ、マーケティング、グラフィックデザイン、テスト、コミュニティ運営、リリース管理などが必要である。
  • ノンコード貢献の重要性は非常に大きく、複雑なプロジェクトほど、より多くのドキュメント、チュートリアル、サポートが必要になり、それによってコードが有用なものになる。
  • グラフィックデザイン、ブランディング、アウトリーチは、プロジェクトの健全性や本気度を示すシグナルとして機能し、他のプロジェクトや企業が依存先として採用する助けにもなる。

ノンコード貢献を始めるべき理由

  • ノンコード貢献は、テクニカルコミュニケーション、グラフィックデザイン、ユーザー体験デザインなど、プログラミングを含まない役割に関心のある人に、ポートフォリオを構築する機会を提供する。
  • プログラマーにとっても、文章力やコミュニケーション能力を磨くうえで有益であり、デベロッパーリレーションズやプロダクトマネジメントのような役割へ移行する助けにもなりうる。
  • オープンソースプロジェクトには、あらゆるスキルレベルの人が参加できる機会があり、プロジェクトへの深い理解がなければ、意味のあるコード貢献をするのは難しい。

ノンコード貢献者を見つけ、感謝を示す

  • メンテナーは、特定の作業を明確に依頼することで貢献者を見つけるのが最もよく、コミュニティを築き、"help wanted" や "good first issue" とタグ付けされたIssueを作成することが役立つ。
  • メンタリングは、貢献者を成功へ導く最良の方法の一つであり、ノンコード貢献者を高く評価し認知することは、現在の貢献者のモチベーションを高め、新たな貢献者を呼び込む助けになる。

GN⁺の見解

  • オープンソースプロジェクトの成功には、単にコードを書くこと以上に、多様な貢献が必要である点が重要だ。これはプロジェクトの持続可能性と成長に不可欠な要素である。
  • ノンコード貢献は、技術者ではない人にもオープンソースに参加する機会を提供し、技術的な能力を育てるうえでも役立つ。
  • この記事は、オープンソースコミュニティに関心のある人にインスピレーションを与え、自分のスキルを活かしてコミュニティに貢献する方法を見つける助けになるだろう。

関連記事

6件のコメント

 
secret3056 2024-02-15

少し話は違いますが、少し前に誰かがExpress.jsのREADMEファイルにPRを送ることを講座として公開し、その結果、何百件もの意味のないPRが上がりました。

Pull requests · expressjs/express
 
mdisprgm 2024-02-16

迷惑…うう
 
edunga1 2024-02-15

100件を超えるPRですね、すごい…
 
sagee 2024-02-15

「バーコード」でどう参加するのかと一瞬混乱しましたが…w
詳細なドキュメント化というのは、見方によっては諸刃の剣かもしれませんね。
開発者が抱えきれないほどドキュメントやスクリーンショットが詳細になり、ドキュメントを更新する自信がなくて改善開発を諦めてしまうケースも起こり得るかも…
 
cosine20 2024-02-16

("非") コードです)
 
GN⁺ 2024-02-15
Hacker Newsの意見

  • 小規模ライブラリの作者・メンテナーとして、外部からの貢献がなければマニュアルは今ほど良くならなかったと断言できる。マニュアルはプロジェクトの使いやすさに大きく寄与する。

    • libcurlの新規ユーザーとして、チュートリアルとAPIドキュメントのおかげでFTPアップロードをすばやく実装し、特定のユースケースに合わせて調整できた。
    • ドキュメントを通じて旧バージョンのスレッドセーフ性の不足を認識し、チームにアップデートを警告できた。
    • ドキュメントはコードやテストスイートと同じくらい重要だ。

  • オープンソースプロジェクトへの願い:

    • 多くのスクリーンショット
    • 非常に長く詳細なREADME.md
    • チュートリアル、リファレンスドキュメント、設計文書、アーキテクチャ図
    • 作者の思考方法を説明するメンタルモデルの文書

  • オープンソースではドキュメントやアセットなどが重要だが、非開発者に権限を与えることでプロジェクトを壊してしまう可能性もある。

    • UXをリリースごとに作り直すなど、安定性・機能性・採用に悪影響を及ぼすことがある。
    • 政治に強い関心を持つ人を引き寄せ、誰でもできると思われがちな領域で「bikeshedding」が起こりやすい。

  • コミュニティ構築のためにDiscord、Gitter、Slackのようなチャットプラットフォームを使うのは良い。

    • 人々がリポジトリで質問することをためらわないようにできる。
    • GitHubで質問したり、問題を解決するプルリクエストを作ったりすることが、しばしば無意味に感じられる。
    • GitHubプロジェクトの作成者の間では、「コードを公開したのだから、それ以上のことをする義務はない」という態度が広く見られる。

  • WordPressコミュニティで活動した経験から、初期の文書化とCodexの強力なドキュメントがWordPressの成長に大きく貢献したと思う。

    • Joomla、Drupal、WordPressのインストールベースが似通っていた時期、WordPressは豊富なドキュメントのおかげで始めやすかった。

  • オープンソースプロジェクトへの最大の願いは、人々がそれを使い、使った内容について何らかの形で記録を残すことだ。

    • プロジェクトのDiscordチャンネルにメッセージを残すこと、ツイート、短いメッセージ、スクリーンショット、gist、公開GitHubリポジトリ、YouTubeやTikTokの動画などは、どれもプロジェクトにとって非常に価値のある貢献だ。

  • ノンコードの貢献がプロジェクト成功の秘訣かどうかは確信がないが、非常に重要だという点には同意する。

    • たとえば、Eclipse Foundationはバグレポートも価値ある貢献だとユーザーに思い出させている。

  • オープンソースプロジェクトを始める過程では、実際にコードを書くエンジニアよりも10倍多くのエンジニアがそのソフトウェアを使うだろうという見込みがある。

    • ユーザーはドキュメントを改善する方法で貢献できるべきだ。
    • Hugoのような静的サイトジェネレーターでドキュメント（ユーザーマニュアル）を生成する場合、ユーザーがGitHub Issueを作成しなくてもドキュメントの修正・更新を送信できる方法が必要だ。

  • 非技術的な人々がそのプロジェクトを理解し、価値を見いだせるなら、それはプロジェクト成功の良い指標だ。

  • 製品がまだ知られておらずファンに使われている段階から、より多くのユーザーを見つける段階へ移るとき、ドキュメント化が重要になる。

    • 良いドキュメントがなければ、この段階を越えるのは難しい。
    • Neural Amp Modellerのユーザーガイドを書かなければならないことを思い出させられる。