GitHub Discussionsでチームの暗黙知を共有する
Tebiki社のWebアプリケーションエンジニアの中山と申します。前職では、SIerでAIアプリの開発を3年弱経験し、現職のTebiki社では、to B向けSaaSの機能開発を行なっています。好きな言語は、C++, Python, Ruby です！ この記事では、GitHub Discussionsの運用による知識のストック化と、新人オンボーディング時の負担軽減についてご紹介します！ Tebiki社のDiscussionsとは？Tebiki社では、エンジニアチーム内の知識を共有するツールとして、GitHubのDiscussions機能を活用しており、これまでチーム内で議論した内容や暗黙知であった内容をQ&A形式で記録しています。 TebikiのDiscussionsDiscussionsの運用ルールDiscussionsを運用するにあたって、以下のようなルールを作っています。 Discus
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
チャットで即答しづらい質問に回答するコツ - onigra.github.io
はじめに: 個人の見解ですチャットのオープンなチャンネルで即答しづらい質問（難しい、鋭い、自分の意見だけでは回答できない）ような質問に回答するコツです。 こういう質問は比較的管理職やマネージャーっぽい人たちに向けられることが多いので、そういう方々へのアドバイスです。 良くない例: 時間をかけてきちんとした回答をするありがちなのが、 多方面に配慮して、勘違いされないように、きちんとした回答をしようとして、時間をかけて長文で回答する ことです。 ファーストレスポンスに時間をかけるこれが一番よくない。 パブリックなチャンネルでこうしてしまうと、質問が放置されてるように見えるので、質問者はイライラするし周囲への心象も良くありません。 長文でレスするきちんとした回答をしようとした結果、長文レスになるのもありがちです。 基本的に、チャットではあまり長文投稿をしない方がいいです。短い投稿をした結果、最終
Microsoftのドキュメントの誤訳を報告したら炎上した件について(当事者目線での話) - 水まんじゅう2
この件について改善がなされるとの発表がMicrosoft DOCS International Teamからありました。 少なくとも、誤訳の報告についてはやりやすくなるそうです。 ご担当者様及びに尽力してくださった方々には感謝いたします。 https://github.com/dotnet/docs.ja-jp/issues/118#issuecomment-408283458 今回の私の記事に憤ってる人たちは改善されたことを確認するためにドキュメントフィードバックを送りまくってそれをブログにでもまとめればいいと思うんですよ。— 軒先のネコ (@megascus) 2018年7月28日 -----------------------------------追記ここまで---------------------------------------------- ということで、おとといぐらいか
GitHub - yoshiori/manager-readme
僕は自分と自分のチームが幸せに仕事が出来るようにしようと思っています。そしてあなたの給与と市場価値を上げるのが僕の仕事です。 僕はあなたが楽しく仕事が出来るようにしています。そのためにはエンジニアとしてもキャリアとしても成長が必要だし、それに対する納得も必要だと思っています。たんに甘やかすとかではなく、一緒にエキサイティングに仕事を楽しみたいと思っています。 あなたとあなたのチームがどの方向に向うのかを考え伝えます。全体として進む先を考えそのために何をすべきかを一緒に考えていきます。 他のチームとの交渉が難航した時はすぐに動きます。僕に頼らなきゃいけなくなった時点で問題がややこしくなっていると認識し、情報を集め適切に動きます。また、必ず結果を報告するようにします。 コードを書く事をやめません。自分自身で触ってみないとわからない事が多いので手を動かす事はやめません。ただし立場上スケジュールの
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
Slack 上のエンジニア同士の会話を増やした一つの工夫 + ちょっとした OSS の紹介 - クックパッド開発者ブログ
こんにちは、技術部開発基盤グループの小室 (id:hogelog) です。 最近エンジニアが全員集まる Slack のチャンネルからデプロイ通知等の機械的な通知を排除したらエンジニア同士のコミュニケーションがほぼ毎日発生するようになり満足しています。自分のような無名なペーペーエンジニアも業界に名を馳せる著名エンジニアもフラットに属しているチャンネルが通知で埋まっていて人間の会話がまったく発生しないなんてもったいないですからね。Slack のチャンネルをどう運用するか会社によって文化の違いがあると思いますが、良い運用は参考にしたいので各社どんどん発信してほしいのでよろしくおねがいします。 さてそんな話で終わっても良いのですが、ここは開発者ブログだしせっかくなので最近開発した Slack 関連のアプリケーションを紹介します。 tokite で GitHub から Slack への通知をカスタマ
なぜあなたのPull Requestは読まれないのか - Qiita
Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま
非英語ネイティブにとってのOSSのメンテナンスコスト - once upon a time,
disclaimer: この記事を書いている人はClouderaというHadoop/Sparkのディストリビューターの会社にいます。 codelunch.fmの20回目を聞いていろいろ思うところがあったのでつらつら買いてみます。 codelunch.fm この回のcodelunch.fmでは、前職の同僚である丸山さん（@h13i32maru）と@hokacchaさんが、お互いの家庭環境の変化を交えながら個人プロダクトの開発について話しているエピソードです。これ自体なかなかおもしろい回なので、趣味でプロダクト開発している人は聞いてみるといいんじゃないかなと思います。 丸山さんはJasperやESDocを精力的に開発していますし、hokacchaさんはnodebrewやadventarを作られています。彼らの話していた、個人で趣味プロダクトを開発するモチベーションは何かというところは、以下のよ
GitHubはオープンソースのプロセスを標準化した。これからはコード開発以外にも使われていく。AWS Summit Tokyo 2015
GitHubはオープンソースのプロセスを標準化した。これからはコード開発以外にも使われていく。AWS Summit Tokyo 2015 Amazonクラウドのイベント「AWS Summit Tokyo 2015」が都内で開催されています。1日目の6月2日、デベロッパー向けのDevConセッションの基調講演には、GitHub, Inc.共同創業者 Scott Chacon氏が登壇。GitHubの登場がオープンソースの世界をどう変化させ、これから企業や社会にどのような影響を与えていくのかについて語りました。 基調講演の内容をダイジェストで紹介します。 この会場にいる人たちはこの10年でもっとも重要な人たち GitHub, Inc.共同創業者 Scott Chacon氏。 現在、あらゆる企業はソフトウェア企業だと言える。電気自動車を作っているテスラでさえ、製品のために多くのソフトウェアを作り続
RQ
RQ: Better Living Through Asynchronicity Douglas Crockford 2017-09-20 RQ is a small JavaScript library for managing asynchronicity in server applications. The source is available at https://github.com/douglascrockford/RQ. This page is available at http://RQ.crockford.com/. It is in the Public Domain. Asynchronicity Asynchronicity is becoming the preferred method for solving a large class of proble
コードレビューをしよう - ppworks.jp
Sendagaya.rb #86 - Sendagaya.rb | Doorkeeperに参加してコードレビューについて思うところをみんなでディスカッションしたので、自分の思いをまとめておきます。（ポエム） ソニックガーデンの @mah_labさんのスライドにある7つの秘訣に同意です基本。あと、github上のプルリクでコードレビューするという前提でまとめます。 1. レビューの観点を明確に いま何の話をすべきかという状況を判断して、どの観点で物を言うのかっていうのはコードレビューだけに限らず打ち合わせ時にも大事ですね。今この観点で議論を進めますよ！ということを表明することで齟齬が防げます。 観点が明確だと議論のテーマが明確になるので、コードレビューで修正すべき点も分かりやすくなりますね。 コーディング規約の観点 セキュリティの観点 メンテンスの観点 設計の観点 リリース前にこれで出来るレ
VOC.js作った。 視覚と見た目に基づいた非同期コミュニケーションができるよ - 標高+1m
昨日の記事で書いたVOC (Vision Oriented Communication) の実装を支援するライブラリを作った。 https://github.com/ympbyc/VOC READMEを英語で書いたのでここに日本語版を書いとく。 VOCのコンセプト オブジェクト指向やアクターはpushベースだけど、実世界のコミュニケーションの多くはpullベースだ。 僕らはレシーバを指定したメッセージを送らない。 僕らは自分の見た目(e.g. 表情)や自分の周りの状態(e.g. 声)を変える能力を持っている。 僕らは自分の周りの景色を見て、情報を引き出して、それに基づいて行動する。 僕らはそれぞれバラバラに勝手に非同期に行動している 僕らは赤信号が見えたらブレーキを踏むわけで、赤信号が僕らのbrakeメソッドを呼んでくれるわけじゃない。 実装 VOC.Visual(state)は見た目を作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rewatch
Geek Women Japan keynote