オープンソースコミュニティをみんなでサポートしましょう

この数週間、世界中で起きているカンファレンスやイベントのキャンセルは、オープンソースコミュニティに多大な影響を及ぼしています。FOSS をサポートするエコシステムの中で、これらのイベントは重要な役割を担っており、このエコシステムの健全性を維持するために、私たちが今行動を起こすことが必要です。

今こそ支援が求められる理由

カンファレンスやイベントは、オープンソースコミュニティに次のような機会を提供する大切な場となっています。

  • 活動の取りまとめ
  • 資金の調達
  • ユーザー基盤の拡大
  • 相互サポート
  • 技術の普及
  • 新規コントリビューターの育成と講習会
  • 新作のリリース
  • 知識の共有

オープンソースイベントの運営には、多くの時間や労力、資金が必要であり、イベントのキャンセルは主催者側にとって重い負担となります。イベントの継続やオープンソースコミュニティの存続と発展のためには、FOSS ユーザー全員が行動を起こさなければなりません。

FOSS Responders

業界から一同に集結したオープンソースコミュニティのリーダーたちは、FOSS Responders と呼ばれるワーキンググループを結成しました。 最もサポートを必要としているオープンソースのイベントやコミュニティ、財団、コミュニティのメンバーを特定するのが主な活動内容で、イベントのキャンセル料の負担が難しい個人のサポートもしていく予定です。コミュニティが今必要としている支援内容を広く取りまとめ、組織や個人のリソースを動員してサポートすることが活動の目的です。

ワーキンググループの参加メンバーは、IndeedGitLabOpen CollectiveSustain コミュニティ、Drupal Association などの業界の専門家で構成されています。ワーキンググループへの参加方法を含む詳細は fossresponders.com をご覧ください。

バーチャルファンディングイベント

Indeed と Open Collective は、2020年5月22日にバーチャルファンディングイベントを共催し、イベントのキャンセルによって損失が出ているカンファレンス主催者の資金調達を行います。また、同業者にも、FOSS Funders としてこのイベントに参加するよう呼びかけています。

知識の共有、意思決定の連携、協働による対応策の調整を一丸となって行うことで、オープンソースイベントを今後も継続して開催し、コミュニティをサポートすることが可能になります。このイベントに関する詳細は、 こちらを参照してください。

あなたにできること

できる支援の範囲やニーズに関わらず、今こそ行動すべき時です。今すぐ取れる具体的な行動例には次のようなものがあります。

支援する場合

今こそ、恩恵を得てきたプロジェクトを支援しましょう。次の方法で、オープンソースの将来的なインフラ投資に備え、恩恵を受けてきたソフトウェアを開発した何百万人もの人々を支援できます。

  • 自分のプロジェクトをサポートしてくれている財団への寄付や有料メンバーシップの登録
  • GitHub Sponsors や Open Collective から、自分が使っているプロジェクトの作成者への寄付
  • FOSS Responders Open Collective へ寄付し、支援が行き届かない可能性がある個人エンジニアへの資金調達をサポート

支援を受ける場合

FOSS Responders 上で、支援が必要な人々や希望する支援内容などの情報を取りまとめています。あなたの希望の内容を共有することで、多くの支援者とつながることが可能になります。

  • カンファレンス関連のキャンセル料の支払いにおいて支援を必要としている個人の方は、FOSS Responders Individual Request に記入してください。
  • キャンセルを余儀なくされた結果、資金援助が必要となったイベントの主催者は、EVENT issue を参照してください。
  • その他の支援については、ORGANIZE issue を参照してください

参加するには

FOSS Responders のグループは急成長しており、あなたのサポートを必要としています。

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone

Making Our Code More Inclusive

At Indeed, inclusion extends beyond employee resource groups and celebrations. Diversity of background, experience, and thought makes for a stronger workforce, more effective decision-making, and powerful innovation. To foster inclusion, we want to build a psychologically safe environment at every level and in every area of the business. That’s why we’re removing terminology that works against such inclusion from our codebase.

Image of five Indeed inclusion group members smiling and wearing shirts labeled "Women at Indeed" in a relaxed office setting

Diversity and inclusion is an ingredient for success. Leaders of Indeed Amsterdam’s Women at Indeed employee resource group (l-r): Edwin Moses, Trudy Danso-Osei, Freek van Schaik, Renske van der Linden, and Valerie Sampimon. 

What does technical terminology have to do with inclusion?

Like all words, technical terms have connotations that give them immense expressive power. Some connotations are well known and generally understood. Others depend on context and are understood differently by people with varying lived experiences. The original etymology of a term often has little to do with the connotations it accrues over time.

Computer science and software engineering employ many terms that are convenient, meaningful, and useful. However, some terms ask groups of people to ignore the powerful negative and exclusive connotations they carry.

The terms “master” and “slave” exemplify this. Some engineers see these words and are privileged to deduce a benign connotation—a slave is a subordinate process that acts in accordance with the demands of the master. However, for many people, particularly people of color, these terms immediately conjure images of human slavery’s horrors. This connotation doesn’t just exist in the context of one country’s history, such as American slavery. With an estimated 21-45 million people currently enslaved worldwide, the terms master and slave represent both an historic and current global humanitarian crisis.

Many other terms have similar negative connotations. Words that associate colors with value judgments, such as “blacklist,” and language around the exploitation or denigration of cultures, such as “tribal knowledge,” represent just a couple. Ableist language such as “lame” and “blind” used in the wrong context can negatively impact people with disabilities. People continually fight bigotry and prejudice based on these characteristics, and these terms invoke and perpetuate those injustices.

Some of these terms might surprise those of us who don’t share the lived experiences of marginalized individuals. But when our colleagues tell us we are using terms that exclude or hurt them, we should trust them and find new words to use.

Starting the conversation

Even before Indeed officially introduced inclusion and belonging as one of our company values in 2019, our engineers began removing problematic terms from our technology.

We started by opening up the discussion on our internal wiki, with internal blog posts and a dedicated content hub for identifying and deprecating exclusive terminology. All engineers can contribute to and comment on the Inclusive Terminology wiki page. From contributions made there, we created a non-exhaustive quick reference guide to help each other make responsible terminology decisions.

Instead of Use Why
master* primary, main, trunk These terms represent an inherently oppressive relationship.*The removal of “slave” from the set in common usage does not remove the implied oppressive relationship. Historically, the usage of the term “master” in relation to a Git branch stems from a master / slave relationship.
slave replica, secondary
whitelist allowlist, unblocklist These terms imply a culturally specific binary of good versus evil.
blacklist denylist, blocklist, banned
backlog grooming backlog refinement “Grooming” is a term with specific legal meaning in British English.
tribal knowledge institutional knowledge “Tribe” is a loaded term with negative connotations for First Nations and African communities.
grandfathered legacy, pre-existing Grandfather clauses originated from Jim Crow era discrimination laws in the United States.

Each engineering team chose how to implement the new language in their code. Then, teams shared best practices and processes. We continue these conversations today.

Case study: Replacing “master” with “primary” in a Git project

Renaming the master branch of a Git project is not a trivial exercise, especially for projects with lengthy histories. Recently, our Design Systems team completed this work for one of their projects. To do this, the team:

  1. Cloned the master branch and named the clone “primary.”
  2. Updated the default branch in GitLab from master to primary.
  3. Locked down the master branch. It still exists for historical purposes, but it can no longer be used.
  4. Applied the former settings for the master branch to the new primary branch.

A couple of issues could arise in this scenario. For example, a user could create a branch off master before the team created the new primary branch. Because primary and master share a common history, the user could theoretically merge the feature into primary. To mitigate such issues, the team enacted a code freeze while they made the change. They also tested their process on a smaller project before renaming the main project.

Tangible results

To track this work, Indeed engineers leaned on Atlassian’s Jira, our tool for software development tracking. We added a label to Jira tickets that involve inclusive terminology so we can filter and sort them. This gives us a high-level view of where exclusive language exists, our ongoing efforts to remove that language, and our progress. To date, we’ve closed 97 of 113 issues and counting.

Pie graph showing the number of Jira issues labeled "inclusive-terminology" by status, with 97 closed, 1 deferred, 9 on backlog, 1 pending review, 2 pending triage, and 3 in wish list status.

Jira issues labeled “inclusive-terminology” by status

Challenges to making this happen

This work sparked lots of discussion among our engineers. The last thing we wanted to do was turn these language changes into a policing and shaming process. So, we decided to make this a grassroots effort instead of a top-down mandate. That way, everyone is empowered to respectfully discuss terminology changes while learning from one another. Leadership provides support and guidance when necessary and actively participates in the conversation.

One subject that came up in these discussions was cost and level of effort. Changing terminology throughout all our products is a long-term project that requires many engineer hours. In fact, as of today we still need to remove over 5000 instances of the term “slave” from our codebase. We’re committed, and the psychological safety generated by this work far outweighs the time and effort required to remove exclusive terminology.

A way forward

Language constantly evolves to meet the needs of those who use it, and words fall out of fashion as we progress. Because of this, we know changing the terms in our codebase is an ongoing practice, not a one-time effort.

We continue to document words we want to replace and offer suitable alternatives. We avoid using those terms in any new code and ask our vendors to avoid those terms in their products as well. As we change our codebase, we methodically and carefully locate and replace the existing usages.

We still have work to do. We constantly increase our awareness of exclusive terms and their implications, and we engage in respectful conversations about these topics with each other. Together, we want to create a work environment that is psychologically safe, inclusive, and welcoming for all people at Indeed. By sharing these practices, we hope to model inclusivity and improve the tech industry as well.


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone

インシデントのレトロスペクティブの改善

この記事は最初に『learningfromincidents.io』に掲載されました。

man standing in front of waterfall with rainbow

Photo by Jared Erondu on Unsplash

Indeed の Site Reliability Engineer (SRE) として、インシデントの後のレトロスペクティブという振り返りの工程に数多く参加しています。Indeed では2015年後半頃から導入されているレトロスペクティブは、我々のエンジニアリングカルチャーの一部になっています。その重要性に疑問を感じたことはありませんでしたが、最近のレトロスペクティブでは次のような傾向が見られるようになり、レトロスペクティブの本来の利点が活かされていないのではないかと思い始めました。

  • 割り当てられた時間の30% 程度しか活用していない。
  • 出席しなくても、インシデントのチケットやレトロスペクティブの議事録などを見れば、内容がわかる。
  • インシデントを「引き起こした」条件に時間が割かれすぎている。
  • レトロスペクティブ開催の要否の判断基準が、影響が大きいものや、ビジビリティの高いインシデントに偏りがちである。
  • 参加者は新しい事を学んでいるのか? インシデントに基づく学びの機会を最大限に活用できていない。

私は、なぜこのように感じたのか、どうしたら改善できるのか考えることにしました。

典型的なレトロスペクティブとは

Indeed のレトロスペクティブは通常1時間で、多い時は70〜80人が参加します。社内の誰でも参加できますが、インシデントのレスポンスに関わった人やインシデントの結果に関心がある人たちが参加することが多いです。

ファシリテーターは次のような、あらかじめ決められた手順に従ってレトロスペクティブを進行させます。

  1. タイムラインの振り返り
  2. テンプレート内の改善項目の確認
  3. 改善項目の担当者の決定
  4. 質疑応答

改善点

2018年の夏、Indeed のテックオフィスでレトロスペクティブに数回参加し、最近のインシデントについて話し合いました。私は SRE なので、レトロスペクティブに参加するのは珍しいことではありませんし、当該インシデントに関するテクノロジーは、私の専門分野でした。

ファシリテーターは5分ほどタイムラインに触れ、8 〜10分かけて改善項目を確認し、インシデントの原因と結果に関わるテクノロジーについての質疑応答でレトロスペクティブを終えました。新たな学びはありませんでした。インシデントのチケット、レトロスペクティブの議事録やスライドを見れば同じ情報を得ることができました。総力を結集して問題に立ち向かおう、という意欲を持った熱心なメンバーが1つの会議室に集まるという滅多にない機会でしたが、そのチャンスを最大限に活かすことはできませんでした。

どのレトロスペクティブもこうだと言うわけではありません。出席者が詳細な情報を提供し、議論が1時間というタイムリミットを越え、最後には会議室の外で身を寄せ合って話し続けるようなレトロスペクティブに参加したこともあります。

先ほどのファシリテーターは、レトロスペクティブをきちんと進行させてはいましたが、時間を30%程度しか活用できていませんでした。レトロスペクティブのやり方そのものに改善が必要なことは、明らかでした。

セーフティカルチャーを育てる

改善点を把握するため、レトロスペクティブを行う理由を聞くことから始めました。集まった主な意見は次のとおりで、ソフトウェア開発に携わる人たちには馴染みのあるものだと思います。

  • アウテージの原因を解明するため
  • 影響の大きさを測定するため
  • アウテージの再発防止を徹底するため
  • 改善項目をリストアップし、担当者を決めるため

これらの意見には、Indeed 社員の強い当事者意識が表れています。あるサービスがインシデントに関係していた場合、そのチームは、自分たちが思っていた以上に障害発生が近かったのかもしれないという懸念を持ちます。優先順位を一時的に変更し、チームのメンバーはプロセスや設計の選択肢をより注意深く検討するようになります。

重要なのは、このような機会を活用して Indeed のシステム (人とテクノロジーの両方) と立てた推測をより詳しく分析するように労力をシフトさせることです。これまでとは異なる Indeed 社内でのセーフティカルチャーへのこのようなアプローチはまだ比較的新しく、広がりを見せ始めている段階です。

提案: 改善をレトロスペクティブから切り離す

私は、改善項目の作成プロセスの変更を提案しました。レトロスペクティブは、改善項目のリストアップと担当者の決定を促すための会議ではありません。

プロダクション環境が安定してから改善項目のピックアップが行われるのを日々目にしますが、インシデント発生後には、たくさんの修正が必要になってきます。

「発生後」のアクティビティをレトロスペクティブから切り離すべきだと考える理由は一つではありません。

  • 改善項目のピックアップは、暗黙の停止地点となり、それ以降のより詳しい調査を止めてしまう。
  • 改善項目の担当者決定の責任は、インシデントの担当者と確実に結びつけられるべき。
  • レトロスペクティブは、任意のアクティビティとすべき。担当チームは、義務だから、チェックリストにあるから、ではなく、参加する価値があるかどうかで参加を決定する。
  • 参加者は、改善項目のピックアップや浅薄な説明といった負担から解放され、より深い調査ができるようになる。

提案: テンプレートの柔軟性を高める

レトロスペクティブ用のテンプレートの変更は有益でした。

レトロスペクティブ用のテンプレートを使用すると、空欄に情報を入力するだけの作業になってしまいます。自由な議論ではなく、アクティビティを完結させることに焦点が向けられてしまいます。テンプレートではなく、何も書かれていない白紙のドキュメントを使用すると、別の形での共有が始まります。白紙のドキュメントに変えただけで回答者のモチベーションが高まり、自分の意見や説明を共有し、詳細な分析を書いてくれたことが何度かありました。

もし、インシデントが雪の結晶のような形をしていたら、インシデントごとの特徴を捉えられるテンプレートを作成するのは不可能です。テンプレートを使用すると、詳しく説明しようとした時に制約が出てしまい、回答選択式の質問を使用した説明になってしまいます。白紙というキャンバスであれば、自由に答えられます。テンプレートは、深い分析の妨げになる、もうひとつの暗黙の停止地点なのです。インシデント分析にテンプレートを応用するのはおすすめですが、レトロスペクティブでは白紙のドキュメントをおすすめします。

組織的な変化を促す

急成長を続ける Indeed では、変化を促すことで、多くのことを学んできました。社内での経歴や、何百というインシデントに立ち会った経験、そのドキュメントとの関わりなどが、自分の取り組みに役立ちました。前進はしていますが、まだまだやることがあります。

ここまでの前進は、社内で賛同者を見つけ、連絡を取り続けてきたから実現できたと思っています。

賛同者を見つける

賛同者は、同じ目標を持っている同僚たちで、改善できる点を指摘してくれ、どう改善できるかというビジョンを共有してくれます。こうした賛同者を見つけるのにはまったく苦労しませんでした。同僚たちは、熱心に話を聞いてくれ、自分とは異なる視点を受け入れられる広い心と忍耐強さを持っています。組織内のリーダーや関係者とも何度も1対1で話し合いましたし、ミーティングでもこのようなトピックを提案する機会がありました。世界各地の Indeed のテックオフィスに行くときは、テックトークを行い、潜在的な賛同者に働きかけてきました。

何度も伝える

自分が取り組んでいることをしっかり伝えられていると自分では思っていましたが、十分には伝わっていませんでした。何度も何度も伝える必要があるのだと気づきました。複数の方法でくり返し伝えてきたので、私の身近にいた人たちは、同じことばかり、何度も言っているなと思ったでしょう。しかし、こうでもしないと私の話が耳に入らないような、社内でも遠く離れた誰かには伝わりませんでした。メールや社内ブログにすべて目を通す時間がある人ばかりではないからです。

先を見据える

こうした変更への反応は、おおむね好意的です。レトロスペクティブでの焦点は、人的要素に注目すべき場合でも、やはり技術的な要素に向けられています。こうした取り組みをさらに多くの人たちに広めて効果をあげるために、さまざまな方法を検討しています。これには、Instructional Design チームと連携したデブリーフのファシリテータープログラムの作成、より頻繁に幅広くコミュニケーションを取ること、さらなるプロセスの変更、継続したチームの生産性向上の支援と質の高いドキュメントの共有、教育の機会の提供などがあります。現時点では、この取り組みはまだ始まったばかりですが、成果が楽しみです。


投稿者の紹介

Alex Elman は、Indeed の Site Reliability Engineering (SRE) チームの創立メンバーです。現在は、Resilience Engineering チームと、Job Search という Indeed の主要プロダクトのチームのリーダーです。過去8年間にわたり、複雑さを増しつづけるシステムの拡張に対応するために、信頼性の施策の導入支援を行っています。Alex を Twitter でぜひフォローしてみてください。 @_pkill.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone