エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント3件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
業務時間で書いたパッチは誰のもの? OSS 活動にまつわる罠 - builderscon tokyo 2018
Abstract 本セッションでは、OSS 活動にまつわる様々な罠と、エンジニアが OSS 開発を安心・円滑に行う... Abstract 本セッションでは、OSS 活動にまつわる様々な罠と、エンジニアが OSS 開発を安心・円滑に行うために必要なルールを定めた OSS ポリシーの概説を行います。 業務で OSS を使用する中で不具合があればパッチを書く必要があります。そのパッチが社内に閉じていると、アップストリームの更新のたびにパッチしなおす手間が発生するため、なるべくアップストリームにマージしておきたいです。しかも、そうすることで OSS コミュニティへの寄与にもなります。しかし、業務で書いたコードを社外に公開してよいかどうか不安に思ったり、OSS によってはパッチ提供に際し(部長や会社として)CLA への署名を求められたりするため、パッチ提供をしないで済ませる方向に傾きがちです。適切なルールを定めることは、それらの不安をなくし、エンジニア個人にも、チームにも、コミュニティにも資することとなります。 また
2018/07/10 リンク