theopensourceway · semioticrobotic · Jun 11, 2026 · May 26, 2026 · May 26, 2026 · Jun 11, 2026
diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md
@@ -39,7 +39,7 @@
   * Author(s): [Andy Oram](mailto:andyo@praxagora.com), [Karsten Wade](mailto:kwade@redhat.com)
 * Community Manager Self-Care
   * Author(s): [Ashley Nicolson](mailto:ashjayne.nicolson@gmail.com)
-  * Editor(s)/Reviewer(s): [Karsten Wade](mailto:kwade@redhat.com) (lead), [Dr. Karen Hixson](https://www.karenhixsonlpc.com/) (subject matter expert (SME) reviewer), Editorial team
+  * Editor(s)/Reviewer(s): [Karsten Wade](mailto:kwade@redhat.com) (lead), [Dr. Karen Hixson](https://www.drhixson.com/) (subject matter expert (SME) reviewer), Editorial team
 * Defining Healthy Communities
   * Author(s): [Karsten Wade](mailto:kwade@redhat.com)
 * Understanding Community Metrics

diff --git a/...sers/building-diverse-open-source-communities-by-making-them-includive-first.md b/...sers/building-diverse-open-source-communities-by-making-them-includive-first.md
@@ -74,7 +74,7 @@ If creating an inclusive community sounds overwhelming, remember that the commun
 
 ### Step one: Stop saying you're a meritocracy
 
-The first step to a more inclusive open source project involves understanding the meritocracy myth: The more you believe in meritocracy, the more biased your project is [likely to be](https://www2.deloitte.com/au/en/blog/diversity-inclusion-blog/2019/meritocracy-unraveling-paradox.html).
+The first step to a more inclusive open source project involves understanding the meritocracy myth: The more you believe in meritocracy, the more biased your project is likely to be.
 
 Why? Purely meritocratic projects [don't acknowledge](https://gap.hks.harvard.edu/paradox-meritocracy-organizations) that people enter on unequal playing fields. If an open source maintainer isn't aware that women often have less time to contribute, or that LGBTQ+ contributors are more likely to endure online abuse, they won't take steps to make the community more inclusive. As a result, they risk losing the diverse contributors they worked hard to recruit.
 

diff --git a/attracting-users/communication-norms-in-open-source-software-projects.md b/attracting-users/communication-norms-in-open-source-software-projects.md
@@ -79,7 +79,7 @@ In this description—just a single paragraph—we learn:
 
 Let's take another example from a popular project: Kubernetes.
 
-When visiting the project home page, [kubernetes.io](http://kubernetes.io/), a visitor immediately sees the following explanation:
+When visiting the project home page, [kubernetes.io](https://kubernetes.io/), a visitor immediately sees the following explanation:
 
 > Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and [practices from the community](https://kubernetes.io/).
 
@@ -159,7 +159,7 @@ Do yourself and your community a favor and make your issue tracker very easy to
 
 Not everyone who uses your software will be familiar with your community's conventions for filing a useful bug report. To save you and the bug reporter time, offer an issue template to ensure you receive the information you need to reproduce the reported error and effectively triage it. For example, you may need to know what version of the software or what operating system was in use when an error occurred. If common information is required for reproducing errors, ask for it in an issue template.
 
-Common fields in issue templates include a summary of the issue, steps to reproduce it, the actual behavior the user observes, the intended behavior for the software, and a request for log files or screenshots to help guide the issue reviewer in better understanding the bug report. Several issue trackers support templates for bug reports, including [GitHub](https://docs.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository), [GitLab](https://docs.gitlab.com/ee/user/project/description_templates.html), [Redmine](https://www.redmine.org/plugins/redmine_issue_templates), and [Trac](https://trac-hacks.org/wiki/TracTicketTemplatePlugin).
+Common fields in issue templates include a summary of the issue, steps to reproduce it, the actual behavior the user observes, the intended behavior for the software, and a request for log files or screenshots to help guide the issue reviewer in better understanding the bug report. Several issue trackers support templates for bug reports, including [GitHub](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository), [GitLab](https://docs.gitlab.com/user/project/description_templates/), [Redmine](https://www.redmine.org/plugins/redmine_issue_templates), and [Trac](https://trac-hacks.org/wiki/TracTicketTemplatePlugin).
 
 If you find yourself asking for the same information over and over again in response to different bug reports, then congratulations. You have uncovered an area of your template in need of improvement.
 
@@ -322,7 +322,7 @@ When a project launches or consists of a small group of people working together,
 
 The most effective way to achieve communication in open source projects is to show others kindness and courtesy, and to assume good intent upon first contact with people you've never met. Though this chapter contains any number of helpful best practices for effective communication, simply acting with graciousness to other people is the most important step one can take to communicate well. Remember there is a human being reading what you have written, and remember to treat them with the same respect you want for yourself.
 
-[^guides]: For a sample style guide, see [PEP 8 — Style Guide for Python Code](https://www.python.org/dev/peps/pep-0008/) or the [style guide for contributing to Mozilla Firefox](https://firefox-source-docs.mozilla.org/code-quality/coding-style/index.html), a project that employs multiple programming languages in its development.
+[^guides]: For a sample style guide, see [PEP 8 — Style Guide for Python Code](https://peps.python.org/pep-0008/) or the [style guide for contributing to Mozilla Firefox](https://firefox-source-docs.mozilla.org/code-quality/coding-style/index.html), a project that employs multiple programming languages in its development.
 
 [^not-working]: The authors are grateful for the work of Kent C.Dodds and Sara Drasner in their article [An Open Source Etiquette Guidebook](https://css-tricks.com/open-source-etiquette-guidebook/).
 

diff --git a/getting-started/building-a-strategy.md b/getting-started/building-a-strategy.md
@@ -224,4 +224,4 @@ This chapter explained the importance of developing a strategy for your open sou
 [^fogel-producing-oss]: [https://producingoss.com/en/producingoss-letter.pdf](https://producingoss.com/en/producingoss-letter.pdf), page 13.
 [^istio]: Incidentally, at the time of this writing, Istio described itself this way: "Istio extends Kubernetes to establish a programmable, application-aware network. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments."
 [^open-source-archetypes]: Mozilla. (2018). Open source archetypes: A framework for purposeful open source. Available at: https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf
-[^contributor-pathways]: See "[Constructing an Onboarding Experience](growing-contributors/constructing-an-onboarding-experience.md)," specifically the section on "contributor pathways," for more on this.
+[^contributor-pathways]: See "[Constructing an Onboarding Experience](../growing-contributors/constructing-an-onboarding-experience.md)," specifically the section on "contributor pathways," for more on this.