コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
GitHub 英語例文集
GitHub で参考になった英語表現をまとめました。文脈がわかるように原文の URL も記載しています。 🙅 方針に異議を唱える it's hard to ~~~ Select onInput doesn't function in Microsoft Edge · Issue #2331 · preactjs/preact 🤦 誤解を解く We never said that ~~~ Select onInput doesn't function in Microsoft Edge · Issue #2331 · preactjs/preact 🙊 誤解していたことを伝える now I see you suggested this in your original feature request. Type EffectCallback - allow async function
Latest topics > Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか - outsider reflex
Latest topics > Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた Main 「同調圧力は忌むべきものだ」と思考停止していたことに気付いた話 » Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか - Jun 16, 2020 1つ前のエントリにちょいちょい追記してるんだけど、見通しが悪くなってしまったので別エントリにした。
君は GitHub の Suggested change を知っているか？ - BASEプロダクトチームブログ
これは「BASE Advent Calendar 2018」の2日目の記事です。 devblog.thebase.in Native Application Group の右京です。 ネットショップ作成サービス「BASE」では日々機能追加や改善の為、無数の Pull Request が作成され、レビューされています。今日はそんな中で知っているととっても便利な機能を紹介します。 レビューをしていたら typo をみつけてしまった... ありませんか？前後に真面目なレビューがあるとなんとなく指摘するのを躊躇してしまいますね...。シレッと修正するにも編集するなりブランチを切るなりして...はコンフリクトの可能性などもあり、コストが高く面倒ですよね。 そんなときはこれ、「Suggested change」です。 Incorporating feedback in your pull reques
Microsoftのドキュメントの誤訳を報告したら炎上した件について(当事者目線での話) - 水まんじゅう2
この件について改善がなされるとの発表がMicrosoft DOCS International Teamからありました。 少なくとも、誤訳の報告についてはやりやすくなるそうです。 ご担当者様及びに尽力してくださった方々には感謝いたします。 https://github.com/dotnet/docs.ja-jp/issues/118#issuecomment-408283458 今回の私の記事に憤ってる人たちは改善されたことを確認するためにドキュメントフィードバックを送りまくってそれをブログにでもまとめればいいと思うんですよ。— 軒先のネコ (@megascus) 2018年7月28日 -----------------------------------追記ここまで---------------------------------------------- ということで、おとといぐらいか
GitLab、Slackライクなサービス「Gitter」をオープンソースで公開。MacOS対応。Windows版とLinux版も作業中
GitLab、Slackライクなサービス「Gitter」をオープンソースで公開。MacOS対応。Windows版とLinux版も作業中 ソースコード管理サービスを提供するGitLabは、GitHubなどに対応する開発者向けチャットサービス「Gitter」をオープンソースとして公開しました。 公開先は当然ながらGitHubではなくGitLab.orgです。 Gitterは今年3月にGitLabに買収されました。このときには有償プランが廃止され、何人でも無料で利用可能になっています。そしてこのときに同じくGitterをオープンソースにすることも約束されており、今回その約束が果たされたことになります。 Gitterとは、GitHubやTwitterのアカウントを用いて誰でも簡単にチャットルームを開始できるサービスです。Slackに似ていて、GitHubと連携して開発中のソフトウェアに関するコミュ
なぜあなたのPull Requestは読まれないのか - Qiita
Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま
組織全体でGitHubを使うようになるまで（前編）～ 使い方が分からない？ 使うのが怖い？ Cookpad TechConf 2017
組織全体でGitHubを使うようになるまで（前編）～ 使い方が分からない？ 使うのが怖い？ Cookpad TechConf 2017 クックパッドの子会社である「クックパッド料理教室」では、GitHubの利用をユーザーサポートや料理教室の講師にまで広げることで、組織全体のコミュニケーションを活性化し、働きやすくなるという効果を実現したといいます。 エンジニアのツールだと思われていたGitHubを組織全体でどうやって使うようにしたのでしょうか？ 21日に都内で行われたイベント「Cookpad TechConf 2017」のセッション「組織全体でGitHubを使うようになるまで」で紹介されたその内容を、ダイジェストでまとめました。 「クックパッド料理教室」は、簡単に言うと町中の料理教室をWebで予約できるというサービスです。 料理でレシピは大事なのですが、レシピだけでは伝えられないこともいっ
非英語ネイティブにとってのOSSのメンテナンスコスト - once upon a time,
disclaimer: この記事を書いている人はClouderaというHadoop/Sparkのディストリビューターの会社にいます。 codelunch.fmの20回目を聞いていろいろ思うところがあったのでつらつら買いてみます。 codelunch.fm この回のcodelunch.fmでは、前職の同僚である丸山さん（@h13i32maru）と@hokacchaさんが、お互いの家庭環境の変化を交えながら個人プロダクトの開発について話しているエピソードです。これ自体なかなかおもしろい回なので、趣味でプロダクト開発している人は聞いてみるといいんじゃないかなと思います。 丸山さんはJasperやESDocを精力的に開発していますし、hokacchaさんはnodebrewやadventarを作られています。彼らの話していた、個人で趣味プロダクトを開発するモチベーションは何かというところは、以下のよ
よりよい機能をより早く届けるためにGit/GitHubを使いこなす10の方法 - Qiita
この記事は freee Engineers Advent Calendarの6日目です。 こんにちは。freee株式会社でアプリエンジニアをしている @kompiroです。主に会計freeeの開発に携わっています。 僕には「よりよい機能を、より早くユーザーに届けたい」という信念があります。今日はよりよい機能を、より早くユーザーに届けるためのGit/GitHubを活用する10の方法と題してGitやGitHubの便利な使い方や日々のTipsをお届けします。1 PRのレビュー完了までの時間を最速にするための工夫 freeeではGitHub上でレビューをしながら開発を進めています。レビューをするのもされるのも、うまく進めないと結構時間がかかります。もちろんコードをより良くする作業に時間を割いているのであれば時間がかかるのも致し方ないです。しかし、進め方による問題でも数日〜数週間デプロイが延期されれ
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
Github issue で質問してはいけない - Qiita
この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ
GitHubを使って法務コミュニケーションのスピードを2倍にした話 | Wantedly Engineer Blog
ウォンテッドリー株式会社コーポレートチームの大谷です。 カスタマサービスチーム仲野さんが書いた ”GitHubで実現する、カスタマーサービスとエンジニアの非同期コミュニケーションのすすめ” に良い反響がありましたので、コーポレートチームでも行っている活動をお話したいと思います。 Wantedlyのコーポレートチームは”働くメンバーの生産性を上げる”ことをミッションとしています。インフラチームが開発チーム全体の生産性をあげることをミッションとしているように、コーポレートチームは会社としてやらないといけないことを担保しつつ、メンバーの負担を増やさないという観点で、会社全体の生産性を上げることを目指しています。 他社で契約書や規程の文書管理としてのGitを使う話はいくつか事例があるのですが、今回Wantedlyで行ったのはGitHubを使ったコミュニケーションを使って生産性を上げた話になります。
Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
一休.com におけるフロントエンド開発 // Speaker Deck
3.29 Sansan✕一休.com 勉強会での発表資料です
【ソースコードの品質向上】デザイナーもコードレビューしよう｜dwango creators' blog（ドワンゴクリエイターズブログ）
ドワンゴデザイナーのマカロフです。 私がドワンゴに入社したのはニコニコ動画のバージョンが原宿の時でした。それからPS4生放送対応等を行ったり、ニコニコ生放送のサービスに携わって来ました。仕事の領域的にグラフィックデザインをするより、エンジニアさんと連携を取りながらコードを書くことが多いです。 そんな背景もありコードレビューの大切さを日々痛感しておりますので、今回はデザイナーの開発環境の紹介としてコードレビューを取り上げたいと思います。 デザイナーもコードレビューをする時代 ドワンゴのデザイナーも世間のデザイナーと同じくimage、HTML、CSS、JavaScript等を日々、編集してコミットしています。 新しいテンプレートエンジンの採用によりHTMLの記述方法が変わったり、自動化したり、コンポーネントなcss設計を考えたり、JavaScriptも日々進化していき新しく採用したフレームワー
複数のエンジニアと開発を円滑に進めるためのissueの立て方 - クックパッド開発者ブログ
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
怖くない！エンジニア以外のメンバに気持ちよく GitHub を使い始めてもらうには - クックパッド開発者ブログ
ヘルスケア事業部の濱田です。チームで楽しく開発してますか？ コードベースの置き場として絶大な支持を集める GitHub。コードを管理するだけでなく、issue を使って様々な議論や報告を行い、その結果をスムーズに製品に反映させることができます。エンジニアだけでなく他の職種のメンバも巻き込んで GitHub で議論ができたら、開発はもっと活発になるでしょう。 一方、 GitHub にはちょっと敷居が高い、敬遠したくなるような雰囲気を感じる人も多いようです。 本記事では、様々な職種のメンバが GitHub を気持ちよく使い始めてもらうにはどうすればよいか、という観点から気をつけるべきことを紹介します。 GitHub は非エンジニアにとっては怖い場所？ エンジニアは GitHub が大好きです。自分たちの作ったコードがあり、ドキュメントがあり、仲間がおり、コードレビューを通じて自分の新たに作った
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログイン - はてな
