update.何も考えずに書き始めたけど10の方法って書いちゃった。いくつになるかはわかりません。一般的なプロジェクト運用でもある程度同じ方法論でイケると思います。筆者であるvvakameはDefinitelyTypedのメンテナをしています。そのため、これから先の文章について、TypeScriptやJavaScript関係固有の事象が含まれていると思います。書かれている内容について、contributeする側、される側、両側へのアドバイスを書きます。Linuxに学ぶ説得術とかはすごい参考になりました。こまけぇことはいいんだよ!まずはやろう!貴方が世界に存在するためにはまず誰かに存在を知ってもらわなければいけません。requestのmergeを拒否されたとしても、ちょっと悲しいだけで特に損をするわけではありません。最初のうちはわけもなく恥ずかしさとかを感じた気になったりするかもしれませんが、電車に乗ってる時にお腹が痛くなってきた時に比べればなんてことはありません。英語を使う頑張りましょう。基本的にみんな優しいので、こっちが変な英語を書いても、意味がそれなりに汲み取れれば何も問題にはなりません。最終的にはコードで語りましょう。英語でちゃんと説明できたか不安な時は、サンプルコード書いて、コードにコメント英語でちょいちょい入れて、「ここが辛い」とか「こうすると良さそう」とか一言添えるだけでとりあえずなんとかなります。日本人同士の会話でも、後から来た人が理解できるよう、なるべく英語でやります。しても日本語を使いたい場合、Twitterとかを使って直接連絡する場合がちょいちょいあります。その場合も、GitHub上に残す証跡として英語でサマリを書いておきます。敵はどこにもいないオープンソースプロジェクト上で関わりが生まれる人は、全員敵ではありません。喧嘩したり、主張がぶつかり合ったりする時もあるでしょうが、敵ではないのです。仲間か、悪く言っても好敵手くらいのもんでしょう。「俺はこれが正しいと思う!」より、「私達はこうするのが正しいと思う。前者はただの主張の表明にすぎません。後者はこれから行う意見のすり合わせの予告です。この後は必ず「なぜなら△△だからである。場合、"自分が理解している理屈"が△△に入るでしょう。相手がどう感じるかはわかりません。場合、"相手に理解してほしい理屈"が△△に入るでしょう。相手が共感できればOK、できなかった場合、質問を受け取ることができるでしょう。困ってもあんまり怒ってIssueとか書いたりしないようにしましょう。怒るんじゃなくて、相談するのです。あなたが困っていて、それが他の人にも起こりうるとわかってもらえたら、ちゃんと対応してもらえるでしょう。ない場合、もしかしたら「StackOverflowで聞け」などのアドバイスが貰えるかもしれません。謝意を伝えて、アドバイスに従うのがよいでしょう。requestをくれたりする人というのは、大変優しい行為を行ってくれる人なので、アザッス!という気持ちを胸に応対しましょう。これは、相手を非難しないようにしようね、ということであって、批判してはいけない、という意味ではありません。相手はなにか困ったり不便に思ったからアクションを起こしてきたのです。解決してあげたいものです。欧米人(というくくりでいいのか?)の会話術に、「その意見はいいね!でも、○○という問題点があるので、××にしたらどうかな?」みたいなのがある気がします。この言い回しは、問題を他人事にせず、俺達事として解決するために有効だと思います。つけとけば間違いなくどういう立場かは伝わる。http://www.emoji-cheat-sheet.com/便利。利用者を守るライブラリやツールなどを提供している時、既存の利用者を守る、というのは大事なことです。具体的に、破壊的変更を気軽に行ったり、取り込んではいけません。"改善だったらなんでもかんでもやっていいわけではない"という意味です。requestは、おそらくmergeされることはないでしょう。自分の使っているツールやライブラリがある日バージョンアップしたら動かなくなってしまった!というのは、ユーザとしては非常に強いストレスを感じます。いうのは、メジャーバージョンアップをする時だけにしましょう。できれば、migrate用のドキュメントも書きましょう。GitHubの仕様をよく理解する具体的に以下の事をやられると地味に辛いです。やらないでくれると嬉しいなー、くらいなので、やっちゃっても大丈夫!「それしんどいからこうしてくれ...」と言われたら素直に従いましょう。いいのは、自分のリポジトリをGitHubに置いて、色々やってみることです。request出して、1人でmergeしてみたっていいんですよ!!ローカルルールに従うローカルルールには従いましょう。Node.js界隈でのルール、そのプロジェクトでのルール、色々なレイヤーの色々なローカルルールがあります。ローカルルールには意味があります。プロジェクトでのルールは大抵、README.mdかCONTRIBUTING.mdなどにまとめられていると思うので目を通します。逆に言うと、ローカルルールを整備しておくことで、"このルールを見てくれ!"と言うだけで色々と済ませることができます。DefinitelyTypedではこの辺にまとまってたりします。理不尽なローカルルールが設けられている場合、たぶんそのリポジトリはバカが管理しているので利用を避けましょう。人には好み、主義・主張がある人には好み、主義・主張があります。それは、話して変えられる場合もありますが、変えられない場合のほうが多いです。自分の主張が受け入れられなかった場合、諦めましょう。議論を切り上げてもいいですし、自分でforkを作ってもいいと思います。これは、自分についても言えます。自分には好みがあり、主義・主張があります。誰に何を言われようとも、嫌なことはやらなくてよいのです。契約結んでたりお金貰ってるわけじゃないからね。これは自分のやり方が常にベストだ!という意味ではありません。「TypeScriptじゃなくてCoffeeScriptで書けよ」と言われたら「嫌だよ」でよいですが、「○○という構造にしたほうがいいんじゃない?」と言われたら、感情抜きに、良し悪しで判断するのが良いでしょう。プライドは自分の底力は後押ししてくれますがその時点での技術力にはなんのプラスにもなりません。やりたいようにやるお金を貰ってるわけでは多分ないので、やりたくない事はやらなくていいと思います。requestStockLike705@vvakameFollowMercariフリマアプリ「メルカリ」を、グローバルで開発しています。upLoginユーザーは見つかりませんでした。