上にあるものほど、個人的に気にしているもの。
英語！！！
とにかく英語を使う。プロジェクト参加者の共通言語として、言語を英語に統一しましょう。翻訳機とかを使っても可。
まぁ、日本語でも他の言語でも良いのですが、英語以外の言語は、プロジェクト認知機会の損失が大きいんですよね。
GitHub がそもそも英語のプラットフォームですし、オープンソースコミュニティの共通認識として英語でやりとりする人が多いため、英語じゃないリポジトリは、それだけでそっぽを向かれる可能性もあります。
「翻訳として日本語のドキュメントを用意する」などは問題ないですが、あくまでプライマリの言語は英語であることを徹底しましょう。
仮に日本語で Issue が来ても、母国語で返信したい気持ちをグッと堪えて英語で返信して、英語にしてもらうようお願いする、なども大事。そうしないと、プロジェクトの参加者に対して、言語の差による不公平感が出てしまいます。
コミュニケーションの透明化
オープンソースプロジェクトで大事なのが、透明化。
とはいえ、例えばプロジェクトに対する方針決定とかを全部オープンにしろ、と言っているわけではありません。
重要なのは、コミュニケーションを透明化することです。
例えば、プロジェクトに関して、メールやSNSのDMなど、メンテナーに直接コンタクトを取ってくるケース。これは公平性が無くなりますので、パブリックなコミュニケーションの場に引き出すべきです。
これはオープンソースガイドでも、「コントリビューターの規範」としても「メンテナーの規範」としても言及されています。
コントリビューター
全てのコミュニケーションを公開の場でしましょう。 いくらやりたくなったとしても、機密情報（セキュリティイシューや重大な行動指針違反など）を共有するのでもない限り、メンテナーに非公開に接触するのはやめましょう。会話を公開の場で行い続ければ、あなたの会話からより多くの人が学び、利益を得ることができます。会話することはそれ自体がコントリビュートとなりうるのです。
メンテナー
可能な限りどこでも、プロジェクトについてのコミュニケーションを公開しましょう。機能要望やサポートリクエストについてプライベートにコンタクトしてくる人がいたら、彼らをメーリングリストやイシュートラッカーのようなパブリックなコミュニケーションチャネルに丁寧に誘導しましょう。
オープンなコミュニケーションの例外は、セキュリティ系の問題。対処されるまでは、攻撃手段が広く知られるとまずいですからね。
例えば私の Marp では、専用のメールアドレスを窓口として用意しています。
全部を自分でやる必要はない
こんな機能入れて！という要望が来ても、全部自分でこなしてると疲れます。「プルリク出してね」と、とにかく促す。
難易度がそれほど高くなさそうな Issue なら、 "good first issue" ラベルをつけておくのも手です。
コントリビューターが多ければ多いほど、プロジェクトが盛り上がるきっかけにもなるので、任せられるところは任せてあげて良いでしょう。
譲れない線は譲れない
上で言っていることと相反することですが、何でもかんでもプルリクを受け入れてはいけません。
プロジェクトの意図に沿わないものや、プロジェクトのスコープからはみ出そうなものは、断腸の思いで No と言ったり、軌道を修正してあげる必要があるかもしれません。
自分は、プロジェクトのスコープを事前に明記しておいたり、大規模なプロジェクトではリポジトリそのものを分割して、スコープを分けたりしています。
「やらないことリスト」を作る
上記に関連してくるかも。
「やることリスト」は Issue として見える形でどんどん溜まっていきますが、「やらないことリスト」は不思議と注目されないことが多いです。
公開・非公開問わず、「やらないことリスト」があると、コントリビュートを受け入れるかどうかの決断がスムーズになります。
Issue だけで管理すると、ユーザーの要望で ToDo が発散してしまいがち。あまり深く考えずに受け入れた結果、想定していないような機能まで入れてしまった…なんてことになりかねません。
なにより、「やらないこと」の裏側が「プロジェクトの価値」に自然とつながりますので、それを炙り出すためにもこのリストは有効です。