diff --git a/content/practitioner guides/practitioner-guide-demonstrating-org-value.md b/content/practitioner guides/practitioner-guide-demonstrating-org-value.md
index 94da4e3..18b3a49 100644
--- a/content/practitioner guides/practitioner-guide-demonstrating-org-value.md	
+++ b/content/practitioner guides/practitioner-guide-demonstrating-org-value.md	
@@ -5,14 +5,12 @@ type: page
 date: 2025-07-22T15:25:31+00:00
 ppma_authors_name:
   - elizabeth
-  - elizabeth
 nectar-metabox-portfolio-display:
   - all
 nectar-metabox-portfolio-display-sortable:
   - off
 url: /practitioner-guide-demonstrating-org-value
 ---
-\[vc\_row type=&#8221;in\_container&#8221; full\_screen\_row\_position=&#8221;middle&#8221; column\_margin=&#8221;default&#8221; column\_direction=&#8221;default&#8221; column\_direction\_tablet=&#8221;default&#8221; column\_direction\_phone=&#8221;default&#8221; scene\_position=&#8221;center&#8221; text\_color=&#8221;dark&#8221; text\_align=&#8221;left&#8221; row\_border\_radius=&#8221;none&#8221; row\_border\_radius\_applies=&#8221;bg&#8221; overlay\_strength=&#8221;0.3&#8243; gradient\_direction=&#8221;left\_to\_right&#8221; shape\_divider\_position=&#8221;bottom&#8221; bg\_image\_animation=&#8221;none&#8221;\]\[vc\_column column\_padding=&#8221;no-extra-padding&#8221; column\_padding\_tablet=&#8221;inherit&#8221; column\_padding\_phone=&#8221;inherit&#8221; column\_padding\_position=&#8221;all&#8221; background\_color\_opacity=&#8221;1&#8243; background\_hover\_color\_opacity=&#8221;1&#8243; column\_shadow=&#8221;none&#8221; column\_border\_radius=&#8221;none&#8221; column\_link\_target=&#8221;\_self&#8221; gradient\_direction=&#8221;left\_to\_right&#8221; overlay\_strength=&#8221;0.3&#8243; width=&#8221;1/1&#8243; tablet\_width\_inherit=&#8221;default&#8221; tablet\_text\_alignment=&#8221;default&#8221; phone\_text\_alignment=&#8221;default&#8221; column\_border\_width=&#8221;none&#8221; column\_border\_style=&#8221;solid&#8221; bg\_image\_animation=&#8221;none&#8221;\]
 
 # Practitioner Guide: Demonstrating Organizational Value
 
@@ -20,7 +18,7 @@ If you haven’t already read the [Practitioner Guide: Introduction - Things to
 
 # Audience / Scope
 
-The audience for this guide is open source teams and Open Source Program Offices working within organizations where there is a need to demonstrate the value of the work and justify the resources being used for open source initiatives. 
+The audience for this guide is open source teams and Open Source Program Offices working within organizations where there is a need to demonstrate the value of the work and justify the resources being used for open source initiatives.
 
 # Introduction
 
@@ -28,8 +26,8 @@ Many people contribute to open source projects as part of their employment. In a
 
 **A few notes about terminology:**
 
-  * This guide uses the term "**organization**" deliberately because demonstrating organizational value is important for a wide variety of different types of organizations (e.g., university / government OSPOs, research groups, corporations).
-  * Throughout this guide, the term “**goals**” is being used to describe what the organization is planning to achieve. Depending on the organization, the goals might be described as part of the vision, mission, or strategy. In the context of a company business unit, the goals might be part of a product line strategy or plan. These goals are a key component of demonstrating **value** to your organization because organizational leadership is more likely to see the value in work that is clearly aligned with the goals of the organization. 
+- This guide uses the term "**organization**" deliberately because demonstrating organizational value is important for a wide variety of different types of organizations (e.g., university / government OSPOs, research groups, corporations).
+- Throughout this guide, the term “**goals**” is being used to describe what the organization is planning to achieve. Depending on the organization, the goals might be described as part of the vision, mission, or strategy. In the context of a company business unit, the goals might be part of a product line strategy or plan. These goals are a key component of demonstrating **value** to your organization because organizational leadership is more likely to see the value in work that is clearly aligned with the goals of the organization.
 
 # Challenges
 
@@ -41,10 +39,10 @@ In other cases, open source teams provide an overview of what they use internall
 
 Another challenge for many organizations is that they have no overall open source strategy for their contributions. Employees are frequently encouraged to contribute to open source directly or indirectly without proper guidance about how to demonstrate the value of these efforts, and this can create a negative feedback loop:
 
-  * Employees are encouraged to contribute.
-  * The value is not understood, so leadership asks: “Why are we spending time on something that doesn’t help us?”
-  * Employees are told to spend less time on open source, creating the feeling of being unrecognized and undervalued, which leads to burnout.
-  * Both the open source project AND the organization begin to suffer.
+- Employees are encouraged to contribute.
+- The value is not understood, so leadership asks: “Why are we spending time on something that doesn’t help us?”
+- Employees are told to spend less time on open source, creating the feeling of being unrecognized and undervalued, which leads to burnout.
+- Both the open source project AND the organization begin to suffer.
 
 This negative feedback loop can be even more pronounced in organizations where there is no official open source team, and demonstrating the value of this work falls to unofficial teams made up of individual contributors who may not be in a position or have the time to justify this work. In some cases, these individuals might be contributing because an open source project needs bug fixes or features that would help with their job duties, but this isn’t seen as part of their official role.
 
@@ -52,37 +50,39 @@ This negative feedback loop can be even more pronounced in organizations where t
 
 Leadership wants answers to the following questions:
 
-  * What is the criticality of the open source projects the organization is helping maintain?
-  * What is the organization getting out of contributing to open source projects?
-  * How much software engineering time is being spent on maintaining open source projects? 
+- What is the criticality of the open source projects the organization is helping maintain?
+- What is the organization getting out of contributing to open source projects?
+- How much software engineering time is being spent on maintaining open source projects?
 
 Creating an open source contribution strategy can help organizations frame their discussions with leadership to demonstrate the value of their open source efforts in ways that resonate with leadership. At a minimum, the open source strategy should contain details in the following areas, which are each addressed in the “How to Take Action” sections below:
 
-  * Supporting your organization’s **goals**
-  * Determining which open source projects are the most **critical** for your organization 
-  * Assessing open source project **health risk**
-  * **Prioritizing** within your organization’s limited resources
-  * Measuring & framing **value** 
+- Supporting your organization’s **goals**
+- Determining which open source projects are the most **critical** for your organization
+- Assessing open source project **health risk**
+- **Prioritizing** within your organization’s limited resources
+- Measuring & framing **value**
 
 # How to Take Action
 
-By creating a robust open source strategy that demonstrates the value of your organization’s open source efforts, these efforts and outcomes can be described in ways that resonate with leadership by clearly articulating how the work in open source helps your organization achieve its goals. This helps to frame the rest of the strategy that describes the influence of open source project health, how your organization’s resources are being used, and finally how the value is being measured. 
+By creating a robust open source strategy that demonstrates the value of your organization’s open source efforts, these efforts and outcomes can be described in ways that resonate with leadership by clearly articulating how the work in open source helps your organization achieve its goals. This helps to frame the rest of the strategy that describes the influence of open source project health, how your organization’s resources are being used, and finally how the value is being measured.
 
 ## Supporting your organization’s _goals_
 
 Taking some time and effort to make sure that your open source strategy supports the overall organization’s goals makes it much easier to justify continuing organizationally-relevant open source projects. Explaining how open source contributions support the goals of the organization can help the executive team understand the strategic importance of this work.
 
-Having a solid open source strategy is important because successful participation in open source requires a long-term commitment. Individuals and organizations spend months and years building trust and reputations within specific open source communities, and all of that hard work is wasted if those people keep getting pulled off of open source projects to work on internal efforts. Keeping people working on the open source projects that are critical to your organization requires planning and strategic thinking to prioritize these open source efforts and align them with the overall goals for your organization. 
+Having a solid open source strategy is important because successful participation in open source requires a long-term commitment. Individuals and organizations spend months and years building trust and reputations within specific open source communities, and all of that hard work is wasted if those people keep getting pulled off of open source projects to work on internal efforts. Keeping people working on the open source projects that are critical to your organization requires planning and strategic thinking to prioritize these open source efforts and align them with the overall goals for your organization.
 
 However, every organization has a limited number of people and other finite resources, so **_prioritizing_** your open source efforts can help you focus on the activities that demonstrate the most value to your organization and most directly help the organization achieve its goals. This prioritization helps to facilitate efficient use of limited resources. For this guide, priority is defined as a formula made up of criticality multiplied by health risk.
 
-<img decoding="async" src="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/priority-formula.png?raw=true" alt="Priority = Criticality X Health Risk" title="Priority = Criticality X Health Risk" /> 
+<div align="center">
+<img src="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/priority-formula.png?raw=true" alt="Priority = Criticality X Health Risk" title="Priority = Criticality X Health Risk" />
+</div>
 
 **_Criticality_** is where these efforts align with the goals of your organization. By showcasing the criticality of certain open source projects for your organization, these critical projects can be used to frame the strategies in a way that leadership will understand how important it is to continue this work over the long-term to ensure that the company can achieve its goals.
 
-**_Project health risk_** is important in this equation because some open source projects are healthier and more sustainable than others, so some projects are riskier and need more help. A healthy open source project that is critical to your organization is likely to be a lower priority than an equally critical, but more risky project that needs your organization’s help to become healthy and reduce the risk of using it. 
+**_Project health risk_** is important in this equation because some open source projects are healthier and more sustainable than others, so some projects are riskier and need more help. A healthy open source project that is critical to your organization is likely to be a lower priority than an equally critical, but more risky project that needs your organization’s help to become healthy and reduce the risk of using it.
 
-Thus, the priority for investment (allocating staff or other resources) is a combination of criticality and project health risk that is unique to your organization. 
+Thus, the priority for investment (allocating staff or other resources) is a combination of criticality and project health risk that is unique to your organization.
 
 ## Determining which open source projects are the most _critical_ for your organization
 
@@ -90,801 +90,344 @@ For all of the important open source projects used, it’s important to determin
 
 To better illustrate this concept, here are some example categories with descriptions and questions that might help determine criticality.
 
-**Dependency**: Determine how your organization depends on this open source project. 
+**Dependency**: Determine how your organization depends on this open source project.
 
-  * Is it a core component to the function of your organization?
-  * Does it have high usage rates across the organization?
-  * What are downstream impacts to your organization’s projects, products, services, or teams?
-  * How difficult would it be to switch to something else? Or fork and maintain internally? And what would that cost be?
-  * What would the impact of an unplanned security event be?
+- Is it a core component to the function of your organization?
+- Does it have high usage rates across the organization?
+- What are downstream impacts to your organization’s projects, products, services, or teams?
+- How difficult would it be to switch to something else? Or fork and maintain internally? And what would that cost be?
+- What would the impact of an unplanned security event be?
 
 **Opportunities**: There are opportunities to drive or influence the open source project to better suit your organization’s needs.
 
-  * Does it currently have features or initiatives on the roadmap that would be beneficial? If yes, how so? 
-  * If it went in another direction, how would it affect your organization?
-  * What opportunities make it worth investing resources in?
-  * Could development create a competitive advantage?
-  * Does your organization want to be seen as a leader in this space? Or be strongly associated with it?
+- Does it currently have features or initiatives on the roadmap that would be beneficial? If yes, how so?
+- If it went in another direction, how would it affect your organization?
+- What opportunities make it worth investing resources in?
+- Could development create a competitive advantage?
+- Does your organization want to be seen as a leader in this space? Or be strongly associated with it?
 
 **Supportability**: Determine your organization’s ability to support using the open source project.
 
-  * How easy is it to support? Is it well documented?
-  * How difficult is it to skill-up employees or backfill on expertise?
-  * Does it help reduce or manage costs (e.g. right-sizing pods)? If so, by what factor? 
-  * Would using and committing resources to it be a better option than a vendored option?
-  * Does using it enable picking from multiple solutions and avoid vendor lock-in?
+- How easy is it to support? Is it well documented?
+- How difficult is it to skill-up employees or backfill on expertise?
+- Does it help reduce or manage costs (e.g. right-sizing pods)? If so, by what factor?
+- Would using and committing resources to it be a better option than a vendored option?
+- Does using it enable picking from multiple solutions and avoid vendor lock-in?
 
 The answers to these questions can help you map each open source project on a criticality scale. Here are some examples that can be used as a starting point to assign criticality using a 1 (low) to 10 (high) scale, which you’ll see again in the prioritization section later in this guide:
 
-<table>
-  <tr>
-    <td colspan="2" >
-      <strong>Example Criticality Scale</strong>
-    </td>
-  </tr>
-  
-  <tr>
-    <td>
-      <strong>High (8 - 10)</strong>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          Critical to core functions
-        </li>
-        <li>
-          High usage rates across the organization
-        </li>
-        <li>
-          Extremely difficult to swap or maintain internally
-        </li>
-        <li>
-          Difficult to backfill expertise
-        </li>
-        <li>
-          Roadmap has features that would be very beneficial to organization
-        </li>
-      </ul>
-    </td>
-  </tr>
-  
-  <tr>
-    <td>
-      <strong>Moderate (4 - 7)</strong>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          Software that supports core functionality
-        </li>
-        <li>
-          Could be swapped out with reasonable effort
-        </li>
-        <li>
-          Easy to backfill expertise
-        </li>
-      </ul>
-    </td>
-  </tr>
-  
-  <tr>
-    <td>
-      <strong>Low (1 - 3)</strong>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          Non-essential tools/apps with minimal organizational impact
-        </li>
-        <li>
-          Could be swapped out with minimal effort (API compatible)
-        </li>
-      </ul>
-    </td>
-  </tr>
-</table>
+| Example Criticality Scale | |
+| :--- | :--- |
+| **High (8 - 10)** | <ul><li>Critical to core functions</li><li>High usage rates across the organization</li><li>Extremely difficult to swap or maintain internally</li><li>Difficult to backfill expertise</li><li>Roadmap has features that would be very beneficial to organization</li></ul> |
+| **Moderate (4 - 7)** | <ul><li>Software that supports core functionality</li><li>Could be swapped out with reasonable effort</li><li>Easy to backfill expertise</li></ul> |
+| **Low (1 - 3)** | <ul><li>Non-essential tools/apps with minimal organizational impact</li><li>Could be swapped out with minimal effort (API compatible)</li></ul> |
 
 ## Assessing open source project _health risk_
 
-Now that the criticality has been determined, it’s time to think about the other part of the equation, open source project health risk (Priority = Criticality x Health Risk). 
+Now that the criticality has been determined, it’s time to think about the other part of the equation, open source project health risk (Priority = Criticality x Health Risk).
 
 There are many ways to think about open source project health risk, but it can help to start with a few things:
 
-  * [Quality codebase][4]: Sound architectural design, static code analysis, sufficient testing
-  * [Responsive][5] to issues / PRs: Time to first response / review
-  * Healthy [organizational participation][6]: No single vendor drives the whole project
-  * Has future plans and a roadmap: They are planning and have a design review process
-  * [Quality documentation][7] for [both users & contributors][8]: Docs are critical for both adoption and [contributor sustainability][9] and growth
-  * Good [security][10] and releasing controls: Do they have a history of triaging and resolving security issues, are they using/investigating supply chain security best practices
+- [Quality codebase][4]: Sound architectural design, static code analysis, sufficient testing
+- [Responsive][5] to issues / PRs: Time to first response / review
+- Healthy [organizational participation][6]: No single vendor drives the whole project
+- Has future plans and a roadmap: They are planning and have a design review process
+- [Quality documentation][7] for [both users & contributors][8]: Docs are critical for both adoption and [contributor sustainability][9] and growth
+- Good [security][10] and releasing controls: Do they have a history of triaging and resolving security issues, are they using/investigating supply chain security best practices
 
-Similarly to criticality, the health risk of a project can be scored while also potentially looking even deeper at core areas that matter the most to your organization. If a project is unhealthy and it’s critical, it’s likely worth allocating resources to improve the project to bring it into a healthier state. 
+Similarly to criticality, the health risk of a project can be scored while also potentially looking even deeper at core areas that matter the most to your organization. If a project is unhealthy and it’s critical, it’s likely worth allocating resources to improve the project to bring it into a healthier state.
 
-As an example, when the CNCF Helm project was found to have several project health concerns due to having a single maintainer, the risk was escalated to the CNCF. Jorge Castro, a CNCF staff member, got involved and helped the project to realign on a target ([the launch of helm v4][11]), as a focal point for contributor growth. This led to building a better contributor ladder, engagement with other projects, organizations, and vendors to invest and make the open source project more sustainable. 
+As an example, when the CNCF Helm project was found to have several project health concerns due to having a single maintainer, the risk was escalated to the CNCF. Jorge Castro, a CNCF staff member, got involved and helped the project to realign on a target ([the launch of helm v4][11]), as a focal point for contributor growth. This led to building a better contributor ladder, engagement with other projects, organizations, and vendors to invest and make the open source project more sustainable.
 
 ## _Prioritizing_ within your organization’s limited resources
 
 With insight on how to score both criticality and health, the following example combines them to set priority. The example uses two made up open source projects “Foo” and “Bar” with some information about their status, a rough scoring, and how that would map to establishing a priority. Assuming each section is worth 10 points, they’re scored with comments in each, and then the criticality score is multiplied by the health risk score. Some important notes:
 
-  * The three components of criticality (Dependency, Opportunity, and Supportability) are averaged to create a single criticality score, but using a weighted average might be a better solution depending on your organization’s needs. A higher score means that the project is more critical.
-  * Health is scored as health risk, which means that lower numbers are better, since a healthy project would have a low risk score.
+- The three components of criticality (Dependency, Opportunity, and Supportability) are averaged to create a single criticality score, but using a weighted average might be a better solution depending on your organization’s needs. A higher score means that the project is more critical.
+- Health is scored as health risk, which means that lower numbers are better, since a healthy project would have a low risk score.
 
 Example:
 
-<table>
-  <tr>
-    <td>
-      <strong>Project</strong>
-    </td>
-    
-    <td>
-      <strong>Dependency</strong>
-    </td>
-    
-    <td>
-      <strong>Opportunity</strong>
-    </td>
-    
-    <td>
-      <strong>Supportability</strong>
-    </td>
-    
-    <td>
-      <strong>Health Risk</strong>
-    </td>
-  </tr>
-  
-  <tr>
-    <td rowspan="2" >
-      <strong>Foo (50)</strong>
-    </td>
-    
-    <td colspan="3" >
-      <strong>Criticality: 8.3 (average of 10, 7, and 8)</strong>
-    </td>
-    
-    <td>
-      <strong>Health Risk: 6</strong>
-    </td>
-  </tr>
-  
-  <tr>
-    <td>
-      <ul>
-        <li>
-          <strong>Score: </strong>10
-        </li>
-        <li>
-          Critical to core functions
-        </li>
-        <li>
-          Migrating to an alternative would be extremely difficult
-        </li>
-      </ul>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          <strong>Score: </strong>7
-        </li>
-        <li>
-          Roadmap has very useful features
-        </li>
-        <li>
-          High barrier of entry to contribute and will require more time to engage
-        </li>
-      </ul>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          <strong>Score: </strong>8
-        </li>
-        <li>
-          Extremely difficult to backfill expertise
-        </li>
-        <li>
-          Not well documented internally
-        </li>
-      </ul>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          <strong>Score: 6</strong>
-        </li>
-        <li>
-          Project has a large contributor base, but few senior maintainers and contributor ladder needs work
-        </li>
-        <li>
-          Time to first response is too long
-        </li>
-      </ul>
-    </td>
-  </tr>
-  
-  <tr>
-    <td rowspan="2" >
-      <strong>Bar (21)</strong>
-    </td>
-    
-    <td colspan="3" >
-      <strong>Criticality: 7 (average of 6, 9, and 6)</strong>
-    </td>
-    
-    <td>
-      <strong>Health Risk: 3</strong>
-    </td>
-  </tr>
-  
-  <tr>
-    <td>
-      <ul>
-        <li>
-          <strong>Score: </strong>6
-        </li>
-        <li>
-          Not critical to core function
-        </li>
-      </ul>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          <strong>Score:</strong> 9
-        </li>
-        <li>
-          Project is a better option than <Baz> and easy to drive features
-        </li>
-        <li>
-          Popular, strong branding opportunity to be associated with it
-        </li>
-      </ul>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          <strong>Score: </strong>6
-        </li>
-        <li>
-          Easy to backfill expertise
-        </li>
-        <li>
-          Could be swapped out with reasonable effort
-        </li>
-      </ul>
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          <strong>Score: 3</strong>
-        </li>
-        <li>
-          Project has enough maintainers and a decent contributor pipeline.
-        </li>
-        <li>
-          Codebase has solid quality processes
-        </li>
-        <li>
-          Documentation could be improved.
-        </li>
-      </ul>
-    </td>
-  </tr>
+<table style="width: 100%; border-collapse: collapse; border: 1px solid #ddd;">
+  <thead>
+    <tr style="background-color: #f2f2f2;">
+      <th style="border: 1px solid #ddd; padding: 8px;">Project</th>
+      <th style="border: 1px solid #ddd; padding: 8px;">Dependency</th>
+      <th style="border: 1px solid #ddd; padding: 8px;">Opportunity</th>
+      <th style="border: 1px solid #ddd; padding: 8px;">Supportability</th>
+      <th style="border: 1px solid #ddd; padding: 8px;">Health Risk</th>
+    </tr>
+  </thead>
+  <tbody>
+    <!-- Foo Section -->
+    <tr>
+      <td rowspan="2" style="border: 1px solid #ddd; padding: 8px; font-weight: bold; vertical-align: top;">Foo (50)</td>
+      <td colspan="3" style="border: 1px solid #ddd; padding: 8px; font-weight: bold;">Criticality: 8.3 (average of 10, 7, and 8)</td>
+      <td style="border: 1px solid #ddd; padding: 8px; font-weight: bold; vertical-align: top;">Health Risk: 6</td>
+    </tr>
+    <tr>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 10</li>
+          <li>Critical to core functions</li>
+          <li>Migrating to an alternative would be extremely difficult</li>
+        </ul>
+      </td>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 7</li>
+          <li>Roadmap has very useful features</li>
+          <li>High barrier of entry to contribute and will require more time to engage</li>
+        </ul>
+      </td>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 8</li>
+          <li>Extremely difficult to backfill expertise</li>
+          <li>Not well documented internally</li>
+        </ul>
+      </td>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 6</li>
+          <li>Project has a large contributor base, but few senior maintainers and contributor ladder needs work</li>
+          <li>Time to first response is too long</li>
+        </ul>
+      </td>
+    </tr>
+    <!-- Bar Section -->
+    <tr>
+      <td rowspan="2" style="border: 1px solid #ddd; padding: 8px; font-weight: bold; vertical-align: top;">Bar (21)</td>
+      <td colspan="3" style="border: 1px solid #ddd; padding: 8px; font-weight: bold;">Criticality: 7 (average of 6, 9, and 6)</td>
+      <td style="border: 1px solid #ddd; padding: 8px; font-weight: bold; vertical-align: top;">Health Risk: 3</td>
+    </tr>
+    <tr>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 6</li>
+          <li>Not critical to core function</li>
+        </ul>
+      </td>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 9</li>
+          <li>Project is a better option than &lt;Baz&gt; and easy to drive features</li>
+          <li>Popular, strong branding opportunity to be associated with it</li>
+        </ul>
+      </td>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 6</li>
+          <li>Easy to backfill expertise</li>
+          <li>Could be swapped out with reasonable effort</li>
+        </ul>
+      </td>
+      <td style="border: 1px solid #ddd; padding: 8px; vertical-align: top;">
+        <ul style="margin: 0; padding-left: 20px;">
+          <li><strong>Score:</strong> 3</li>
+          <li>Project has enough maintainers and a decent contributor pipeline.</li>
+          <li>Codebase has solid quality processes</li>
+          <li>Documentation could be improved.</li>
+        </ul>
+      </td>
+    </tr>
+  </tbody>
 </table>
 
 The final step in determining priority is mapping the resources your organization has to the open source projects that have just been assessed for criticality. The example in the table above shows that Foo has a priority score of 50, making it a higher priority than Bar with a priority score of 21. In this case, more resources should be allocated to Foo, but it might make sense to allocate some resources to both.
 
 It can help to think about this in terms of software engineers and software engineering hours, but if your organization can’t commit people, donating funds or hiring contractors to help in these areas might be helpful.
 
-<img decoding="async" src="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/putting-together-formula.png?raw=true" alt="Priority = Criticality X Health Risk" title="Resources you have available" /> 
+<div align="center">
+<img src="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/putting-together-formula.png?raw=true" alt="Priority = Criticality X Health Risk" title="Resources you have available" />
+</div>
 
 ## Measuring & Framing the _Value_
 
 Now that the most critical open source projects have been identified, this information can be measured and framed in ways that resonate with the leadership team. One of the most common pitfalls is that organizations tend to bias towards easy to measure metrics such as total contributions, but these do not hold up under scrutiny. Metrics should support the goals and be able to be tied back to “value” and the types of resources being invested in the open source project:
 
-  * Are the features we’re interested in progressing?
-  * Are the issues we’re concerned about being addressed?
-  * Is stability being improved and bugs being fixed?
-  * Is the project itself healthy?
+- Are the features we’re interested in progressing?
+- Are the issues we’re concerned about being addressed?
+- Is stability being improved and bugs being fixed?
+- Is the project itself healthy?
 
 Ultimately, your organization needs to decide if it is this worth the resource investment vs. maintaining internally or accepting the risk, and it can help think about these across three focus areas:
 
-  * **Classifying Features & Initiatives**: How to determine and prioritize what features & initiatives to track
-  * **Issues & Change Requests**: Tracking the value of contributions to organizational goals
-  * **Overall Project Health**: Tracking overall open source project health and how it can benefit your organization
+- **Classifying Features & Initiatives**: How to determine and prioritize what features & initiatives to track
+- **Issues & Change Requests**: Tracking the value of contributions to organizational goals
+- **Overall Project Health**: Tracking overall open source project health and how it can benefit your organization
 
 ### Classifying Features and Initiatives
 
 When investing or contributing to an open source project and that project has a roadmap, it can help to start with the features in a project and evaluate them to determine alignment with your organization’s needs. These classifications are useful when reporting about where people are allocated and why.
 
-  * **Invest**: Direct benefit to your organization that warrants allocating more staff to drive the feature or initiative. Frequently these are important features to organization implementation or initiatives deemed important to overall health of the open source project. 
-  * **Watch**:Feature or initiative that has the potential to either be disruptive or beneficial depending on implementation.
-  * **Ignore**: No features or initiatives that are expected to benefit or impact how the project is used by your organization.
+- **Invest**: Direct benefit to your organization that warrants allocating more staff to drive the feature or initiative. Frequently these are important features to organization implementation or initiatives deemed important to overall health of the open source project.
+- **Watch**: Feature or initiative that has the potential to either be disruptive or beneficial depending on implementation.
+- **Ignore**: No features or initiatives that are expected to benefit or impact how the project is used by your organization.
 
 ### Issues and Change Requests
 
 Bugs, security, and issues are useful because most people understand them without having to know a lot about the details of the open source project itself. These are a few example metrics that are not too difficult to get from GitHub and other code platforms. Note that within the CHAOSS project, we use the term Change Request (CR) to include pull requests (GitHub), merge requests (GitLab), patches, and similar processes for merging changes into a repository, since the different tools have different names for this.
 
-<table>
-  <tr>
-    <td>
-      <strong>Type</strong>
-    </td>
-    
-    <td>
-      <strong>Metric</strong>
-    </td>
-    
-    <td>
-      <strong>Source</strong>
-    </td>
-  </tr>
-  
-  <tr>
-    <td>
-      Bugs
-    </td>
-    
-    <td>
-      <ul>
-        <li>
-          <a href="https://chaoss.community/?p=3633">Bugs reported vs resolved</a>
-        </li>
-        <li>
-          <a href="https://chaoss.community/?p=3630">Time to resolution</a>
-        </li>
-        <li>
-          What % are resolved by your org vs others
-        </li>
-      </ul>
-    </td>
-    
-    <td>
-      Bugs closed this year (GitHub Query):</p> 
-      
-      <p>
-        <strong>is:issue closed:2024-01-01..2024-11-01 label:kind/bug</strong> </td> </tr> 
-        
-        <tr>
-          <td>
-            Security
-          </td>
-          
-          <td>
-            <ul>
-              <li>
-                <a href="https://chaoss.community/?p=3633">Security issues reported vs resolved</a>
-              </li>
-              <li>
-                <a href="https://chaoss.community/?p=3630">Time to resolution</a>
-              </li>
-            </ul>
-          </td>
-          
-          <td>
-            Time to resolve security issues (GitHub cli tool):<strong> \<br /> gh issue list –search “is:closed label:security” –json “id,openedAt, closedAt”</strong>
-          </td>
-        </tr>
-        
-        <tr>
-          <td>
-            Issue / Change Request
-          </td>
-          
-          <td>
-            <ul>
-              <li>
-                <a href="https://chaoss.community/?p=3587">Time to resolution</a>
-              </li>
-              <li>
-                What % are resolved by your org vs others
-              </li>
-            </ul>
-          </td>
-          
-          <td>
-            GitHub queries can be tailored with <strong>author:</strong> keyword look at organization created items to track own items vs. project as a whole. \<br /> \<br /> Issues/PR queries can be tailored to track initiatives
-          </td>
-        </tr></table> 
-        
-        <h3>
-          Overall Project Health
-        </h3>
-        
-        <p>
-          Improving the project health for your organization’s critical open source projects is crucial for reducing the risk associated with using those projects. Within the CHAOSS project, we have <a href="https://chaoss.community/about-chaoss-practitioner-guides/">Practitioner Guides</a> and <a href="https://chaoss.community/kbtopic/all-metrics/">metrics</a> that can help identify areas within those open source projects that aren’t as healthy as they could be and take steps to improve in those areas. This is not an exhaustive list, but it should provide a good starting point.
-        </p>
-        
-        <ul>
-          <li>
-            <a href="https://chaoss.community/practitioner-guide-organizational-participation/">Organizational Participation</a>
-          </li>
-          <li>
-            <a href="https://chaoss.community/practitioner-guide-contributor-sustainability/">Contributor Sustainability</a>
-          </li>
-          <li>
-            <a href="https://chaoss.community/practitioner-guide-responsiveness/">Responsiveness</a>
-          </li>
-          <li>
-            <a href="https://chaoss.community/practitioner-guide-security/">Security</a>
-          </li>
-          <li>
-            <a href="https://chaoss.community/?p=3573">Adoption</a>
-          </li>
-          <li>
-            <a href="https://chaoss.community/?p=3532">Documentation Usability</a>
-          </li>
-        </ul>
-        
-        <p>
-          There are also a number of other important roles in open source projects that can provide value to your organization and improve the health of a project. These are covered in more detail in the Appendix and include, but aren’t limited to:
-        </p>
-        
-        <ul>
-          <li>
-            Triage and program management
-          </li>
-          <li>
-            Documentation
-          </li>
-          <li>
-            Communications and marketing
-          </li>
-          <li>
-            Events
-          </li>
-        </ul>
-        
-        <h1>
-          Conclusion
-        </h1>
-        
-        <p>
-          To tie all of this back together, here is an example report for the 2 open source projects, Foo and Bar described earlier that can be delivered as a quarterly report. This report highlights the percentage of bugs and security issues fixed by others along with the average time to fix them. Below the table shows a breakdown of Software Engineer (SWE) investment, along with the notes related to the categories that were identified as important.
-        </p>
-        
-        <p>
-          Telling the story and communicating to leadership might include examples like these:
-        </p>
-        
-        <ul>
-          <li>
-            For Bar, we have allocated 1 SWE per quarter, and have seen a good improvement in overall security with bugs trending down and the bugs we filed are all being fixed.
-          </li>
-          <li>
-            For Foo, feature baz is set to release next month, and it should drastically improve our developer productivity. We estimate a lag of 2 weeks from release before we can roll it out internally. We made a strategic hire, and they are helping drive that feature upstream and are also spending time upskilling our own team to better engage the project.
-          </li>
-        </ul>
-        
-        <p>
-          <img decoding="async" src="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/conclusion-communication.png?raw=true" alt="Summary of a report communicating the value of contributions to Foo and Bar" title="Report Summary" />
-        </p>
-        
-        <p>
-          One guide can’t possibly cover everything about demonstrating the value of your organization’s open source efforts, so this is just a fraction of the potential ways that open source investments can be tracked and tied back to goals while effectively describing the value of the contributions. It requires the right framing and ensuring that resources are allocated where they may have the most value; however, the framing and resource allocation will be different in almost every situation, since it depends on your organization’s unique needs.
-        </p>
-        
-        <h1>
-          Cautions and Considerations
-        </h1>
-        
-        <ul>
-          <li>
-            Demonstrating organizational value is highly dependent on your organization’s needs, so these activities should be interpreted in light of your organization’s goals.
-          </li>
-          <li>
-            Return on Investment (ROI) is notoriously difficult to measure, but it’s even more difficult to measure when talking about investments in open source software. Coming up with a single ROI number is unlikely, so telling stories and giving examples will be an important part of helping your organization understand the value of your open source efforts.
-          </li>
-        </ul>
-        
-        <h1>
-          Additional Reading
-        </h1>
-        
-        <ul>
-          <li>
-            We have a <a href="https://www.youtube.com/watch?v=Gy9ZI-1_SMA&list=PL60k37cxI-HSHV4-rEsWMzExw2y2Oq79Z&index=8">short video</a> (6 minutes) devoted to this guide on the CHAOSS YouTube channel.
-          </li>
-          <li>
-            <a href="https://podcast.chaoss.community/120">CHAOSScast Episode 120: Practitioner Guide - Demonstrating Organizational Value</a>
-          </li>
-          <li>
-            KubeCon talk by Bob Killen: <a href="https://kccnceu2024.sched.com/event/1YeQH/why-is-this-so-hard-conveying-the-business-value-of-open-source-bob-killen-google">Why is this so hard? Conveying the Business Value of Open Source</a> (slides and video) and the <a href="https://static.sched.com/hosted_files/lfms24/f9/Chasing%20the%20White%20Whale%20of%20Open%20Source%20-%20ROI.pdf">White Whale</a> talk from the Linux Foundation Member Summit.
-          </li>
-          <li>
-            <a href="https://chaoss.community/about-chaoss-practitioner-guides/">CHAOSS Practitioner Guides</a> on topics that include improving responsiveness, contributor sustainability, organizational participation, and security.
-          </li>
-        </ul>
-        
-        <h1>
-          Contributors
-        </h1>
-        
-        <p>
-          The following people contributed to this guide:
-        </p>
-        
-        <ul>
-          <li>
-            Bob Killen
-          </li>
-          <li>
-            Dawn Foster
-          </li>
-          <li>
-            Justin Gosses
-          </li>
-          <li>
-            Ria Schalnat
-          </li>
-          <li>
-            Matt Germonprez
-          </li>
-          <li>
-            Mike Gif?raw=trueford
-          </li>
-        </ul>
-        
-        <h1>
-          References
-        </h1>
-        
-        <ul>
-          <li>
-            Eghbal, N. (2016). <a href="https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/">Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure</a>. New York, NY: Ford Foundation.
-          </li>
-          <li>
-            Foster, D. (2018). Understanding Collaboration in Fluid Organizations, a Proximity Approach [Doctoral Dissertation, University of Greenwich].
-          </li>
-          <li>
-            Linåker, J., Link, G., & Lumbard, K. (2024, October). Sustaining Maintenance Labor for Healthy Open Source Software Projects through Human Infrastructure: A Maintainer Perspective. In <em>Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement</em> (pp. 37-48).
-          </li>
-          <li>
-            Linux Foundation (2023). <a href="https://project.linuxfoundation.org/hubfs/LF%20Research/Open%20Source%20Maintainers%202023%20-%20Report.pdf">Open Source Maintainers</a>: Exploring the people, practices, and constraints facing the world’s most critical open source software projects.
-          </li>
-          <li>
-            Vargas, Sophia (2023). <a href="https://opensource.google/static/documentation/publications/WhatBringsYouToOpenSource_2023.pdf">What brings you to open source?</a> How can projects encourage sustainable open source participation? Google Open Source.
-          </li>
-        </ul>
-        
-        <p>
-          CHAOSS Practitioner Guides are MIT licensed, living documents, and we welcome your feedback and input. You can suggest edits to this document at <a href="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/demonstrating-org-value.md"><a href="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/demonstrating-org-value.md">https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/demonstrating-org-value.md</a></a>.
-        </p>
-        
-        <h1>
-          Appendix
-        </h1>
-        
-        <p>
-          There are a number of important roles in open source projects that can provide value to your organization and improve the health of a project. These include, but aren’t limited to:
-        </p>
-        
-        <ul>
-          <li>
-            Triage and program management
-          </li>
-          <li>
-            Documentation
-          </li>
-          <li>
-            Communications and marketing
-          </li>
-          <li>
-            Events
-          </li>
-        </ul>
-        
-        <p>
-          <strong>Triage and Program Management</strong>
-        </p>
-        
-        <p>
-          Having a product manager or program manager can help cut down on engineering time spent on things that aren’t really engineering efforts and that engineers might not be able to as efficiently as someone with expertise managing products and programs. Doing triage can provide awareness of open source project activities and issues that are important to your organization much earlier than if you were not involved. By reviewing incoming issues, assigning labels and priorities, and aiding in roadmap planning, your organization gets a number of benefits:
-        </p>
-        
-        <ul>
-          <li>
-            Prioritized triage of issues & bugs
-          </li>
-          <li>
-            Decreased time to resolve
-          </li>
-          <li>
-            Early awareness of potential breaking changes & security issues
-          </li>
-          <li>
-            De-risk usage of project by improving overall project health
-          </li>
-          <li>
-            Introduces better data to answer questions & track trends.
-          </li>
-        </ul>
-        
-        <p>
-          Key Metrics:
-        </p>
-        
-        <ul>
-          <li>
-            Decreased <a href="https://chaoss.community/?p=3448">time to first response</a> on issues and change requests
-          </li>
-          <li>
-            Decreased time to assignment
-          </li>
-          <li>
-            Decreased <a href="https://chaoss.community/?p=3630">issue resolution duration</a> / <a href="https://chaoss.community/?p=3587">change request duration</a>
-          </li>
-        </ul>
-        
-        <p>
-          Long Term Health Metrics:
-        </p>
-        
-        <ul>
-          <li>
-            Increased contributor engagement and sustainability across a variety of metrics (e.g., <a href="https://chaoss.community/?p=3630">number of contributors</a>, <a href="https://chaoss.community/?p=3572">project velocity</a>, frequency of contributions, retention)
-          </li>
-          <li>
-            Positive sentiment on issues / change requests and other communication channels
-          </li>
-        </ul>
-        
-        <p>
-          <strong>Documentation</strong>
-        </p>
-        
-        <p>
-          Many people rely on an open source project’s documentation when getting started, and good documentation can help reduce support requests for common questions or issues that can be headed off with good documentation. In particular, a well documented contributor guide can help with onboarding new people and creating a good start for a contributor funnel. They can increase adoption and general overall positive sentiment with improved site traffic, search engine findability, and other web statistics. Contributors rarely want to do the big initial heavy lift to create documentation from scratch, but if a project has good docs to start, folks are much more open to keeping them updated. <strong>“Having good docs leads to better docs.”</strong> Well-documented open source projects are easier for users to understand and utilize, thus aiding in contributor sustainability, and your organization gets the following benefits:
-        </p>
-        
-        <ul>
-          <li>
-            Better developer experience
-          </li>
-          <li>
-            Increases ability to self-service / decreased engineering time
-          </li>
-          <li>
-            De-risk usage of project by improving overall project health
-          </li>
-        </ul>
-        
-        <p>
-          Metrics:
-        </p>
-        
-        <ul>
-          <li>
-            Decreased support questions opened
-          </li>
-          <li>
-            Increased site traffic & accompanying site metrics
-          </li>
-        </ul>
-        
-        <p>
-          Long Term Health Metrics:
-        </p>
-        
-        <ul>
-          <li>
-            Increased <a href="https://chaoss.community/?p=3613">new contributor</a> engagement & retention
-          </li>
-          <li>
-            Positive sentiment on issues and change requests
-          </li>
-        </ul>
-        
-        <p>
-          <strong>Communications and Marketing</strong>
-        </p>
-        
-        <p>
-          Open source projects often lack both the knowledge and skills regarding communication & marketing best practices. Maintainers and engineers do not always have the skills required to craft the right message to get attention, and they often appreciate help with marketing and outreach, which allows them to focus on the technical aspects that are more comfortable for them (Linåker et al., 2024). As an example of unclear and overcomplicated messaging, the description for an enhancement proposal was originally, “This KEP proposes to allow mutating spec.completions for Indexed job if spec.completions equals to spec.parallelism before and after the update, meaning that spec.completions is mutable only in tandem with spec.parallelism.” It was rewritten as, “Enables autoscaling for Indexed Jobs.” By providing resources for communications and marketing, your organization can see the following benefits:
-        </p>
-        
-        <ul>
-          <li>
-            Improved brand awareness & association
-          </li>
-          <li>
-            De-risk usage of project by driving more adoption and conversion to contributors
-          </li>
-          <li>
-            Early awareness of potential breaking changes
-          </li>
-        </ul>
-        
-        <p>
-          Metrics
-        </p>
-        
-        <ul>
-          <li>
-            Increased traffic to website and accompanying site metrics
-          </li>
-          <li>
-            Increased social engagement
-          </li>
-          <li>
-            Increased share of voice
-          </li>
-        </ul>
-        
-        <p>
-          Long Term Health Metrics
-        </p>
-        
-        <ul>
-          <li>
-            Growth in <a href="https://chaoss.community/?p=3573">adoption</a> (e.g., downloads, stars / forks, share of voice)
-          </li>
-          <li>
-            Positive sentiment on communication channels
-          </li>
-        </ul>
-        
-        <p>
-          <strong>Events</strong>
-        </p>
-        
-        <p>
-          Events serve many purposes, from new contributor workshops to help with onboarding, to summits with many high-bandwidth conversations that can unblock development. Many open source projects resolve blockers and bigger issues at events (Foster, 2018), and being in the room can be a huge advantage to make sure your organization’s needs are considered. They’re also useful for workshops and training new contributors. Events are often underestimated, but they help with creating a healthy project, and are important. Your organization benefits in several ways:
-        </p>
-        
-        <ul>
-          <li>
-            Workshops can serve as onboarding or additional skill-up opportunities
-          </li>
-          <li>
-            Being “in-the-room” can ensure organizational needs are addressed
-          </li>
-          <li>
-            De-risk usage of project by improving overall project health
-          </li>
-        </ul>
-        
-        <p>
-          Metrics:
-        </p>
-        
-        <ul>
-          <li>
-            Tracking contributions from attendees
-          </li>
-          <li>
-            Conversions from attendees / contributors to maintainers
-          </li>
-          <li>
-            Unblocked issues/features
-          </li>
-        </ul>
-        
-        <p>
-          Long Term Health Metrics:
-        </p>
-        
-        <ul>
-          <li>
-            Increased contributor engagement and sustainability across a variety of metrics (e.g., <a href="https://chaoss.community/?p=3630">number of contributors</a>, <a href="https://chaoss.community/?p=3572">project velocity</a>, frequency of contributions, retention)
-          </li>
-          <li>
-            Increase in conversion from contributors to maintainers<br /> CHAOSS Practitioner Guides are MIT licensed, living documents, and we welcome your feedback and input. You can suggest edits to this document at <a href="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/demonstrating-org-value.md"><a href="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/demonstrating-org-value.md">https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/demonstrating-org-value.md</a></a>.
-          </li>
-        </ul>
-        
-        <p>
-          [/vc_column][/vc_row]
-        </p>
+| Type | Metric | Source |
+| :--- | :--- | :--- |
+| Bugs | <ul><li>[Bugs reported vs resolved](https://chaoss.community/?p=3633)</li><li>[Time to resolution](https://chaoss.community/?p=3630)</li><li>What % are resolved by your org vs others</li></ul> | Bugs closed this year (GitHub Query): **is:issue closed:2024-01-01..2024-11-01 label:kind/bug** |
+| Security | <ul><li>[Security issues reported vs resolved](https://chaoss.community/?p=3633)</li><li>[Time to resolution](https://chaoss.community/?p=3630)</li></ul> | Time to resolve security issues (GitHub cli tool): **gh issue list –search “is:closed label:security” –json “id,openedAt, closedAt”** |
+| Issue / Change Request | <ul><li>[Time to resolution](https://chaoss.community/?p=3587)</li><li>What % are resolved by your org vs others</li></ul> | GitHub queries can be tailored with **author:** keyword look at organization created items to track own items vs. project as a whole.<br/><br/>Issues/PR queries can be tailored to track initiatives |
+
+### Overall Project Health
+
+Improving the project health for your organization’s critical open source projects is crucial for reducing the risk associated with using those projects. Within the CHAOSS project, we have [Practitioner Guides](https://chaoss.community/about-chaoss-practitioner-guides/) and [metrics](https://chaoss.community/kbtopic/all-metrics/) that can help identify areas within those open source projects that aren’t as healthy as they could be and take steps to improve in those areas. This is not an exhaustive list, but it should provide a good starting point.
+
+- [Organizational Participation](https://chaoss.community/practitioner-guide-organizational-participation/)
+- [Contributor Sustainability](https://chaoss.community/practitioner-guide-contributor-sustainability/)
+- [Responsiveness](https://chaoss.community/practitioner-guide-responsiveness/)
+- [Security](https://chaoss.community/practitioner-guide-security/)
+- [Adoption](https://chaoss.community/?p=3573)
+- [Documentation Usability](https://chaoss.community/?p=3532)
+
+There are also a number of other important roles in open source projects that can provide value to your organization and improve the health of a project. These are covered in more detail in the Appendix and include, but aren’t limited to:
+
+- Triage and program management
+- Documentation
+- Communications and marketing
+- Events
+
+# Conclusion
+
+To tie all of this back together, here is an example report for the 2 open source projects, Foo and Bar described earlier that can be delivered as a quarterly report. This report highlights the percentage of bugs and security issues fixed by others along with the average time to fix them. Below the table shows a breakdown of Software Engineer (SWE) investment, along with the notes related to the categories that were identified as important.
+
+Telling the story and communicating to leadership might include examples like these:
+
+- For Bar, we have allocated 1 SWE per quarter, and have seen a good improvement in overall security with bugs trending down and the bugs we filed are all being fixed.
+- For Foo, feature baz is set to release next month, and it should drastically improve our developer productivity. We estimate a lag of 2 weeks from release before we can roll it out internally. We made a strategic hire, and they are helping drive that feature upstream and are also spending time upskilling our own team to better engage the project.
+
+<div align="center">
+<img src="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/conclusion-communication.png?raw=true" alt="Summary of a report communicating the value of contributions to Foo and Bar" title="Report Summary" />
+</div>
+
+One guide can’t possibly cover everything about demonstrating the value of your organization’s open source efforts, so this is just a fraction of the potential ways that open source investments can be tracked and tied back to goals while effectively describing the value of the contributions. It requires the right framing and ensuring that resources are allocated where they may have the most value; however, the framing and resource allocation will be different in almost every situation, since it depends on your organization’s unique needs.
+
+# Cautions and Considerations
+
+- Demonstrating organizational value is highly dependent on your organization’s needs, so these activities should be interpreted in light of your organization’s goals.
+- Return on Investment (ROI) is notoriously difficult to measure, but it’s even more difficult to measure when talking about investments in open source software. Coming up with a single ROI number is unlikely, so telling stories and giving examples will be an important part of helping your organization understand the value of your open source efforts.
+
+# Additional Reading
+
+- We have a [short video](https://www.youtube.com/watch?v=Gy9ZI-1_SMA&list=PL60k37cxI-HSHV4-rEsWMzExw2y2Oq79Z&index=8) (6 minutes) devoted to this guide on the CHAOSS YouTube channel.
+- [CHAOSScast Episode 120: Practitioner Guide - Demonstrating Organizational Value](https://podcast.chaoss.community/120)
+- KubeCon talk by Bob Killen: [Why is this so hard? Conveying the Business Value of Open Source](https://kccnceu2024.sched.com/event/1YeQH/why-is-this-so-hard-conveying-the-business-value-of-open-source-bob-killen-google) (slides and video) and the [White Whale](https://static.sched.com/hosted_files/lfms24/f9/Chasing%20the%20White%20Whale%20of%20Open%20Source%20-%20ROI.pdf) talk from the Linux Foundation Member Summit.
+- [CHAOSS Practitioner Guides](https://chaoss.community/about-chaoss-practitioner-guides/) on topics that include improving responsiveness, contributor sustainability, organizational participation, and security.
+
+# Contributors
+
+The following people contributed to this guide:
+
+- Bob Killen
+- Dawn Foster
+- Justin Gosses
+- Ria Schalnat
+- Matt Germonprez
+- Mike Gifford
+
+# References
+
+- Eghbal, N. (2016). [Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure](https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/). New York, NY: Ford Foundation.
+- Foster, D. (2018). Understanding Collaboration in Fluid Organizations, a Proximity Approach [Doctoral Dissertation, University of Greenwich].
+- Linåker, J., Link, G., & Lumbard, K. (2024, October). Sustaining Maintenance Labor for Healthy Open Source Software Projects through Human Infrastructure: A Maintainer Perspective. In *Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement* (pp. 37-48).
+- Linux Foundation (2023). [Open Source Maintainers](https://project.linuxfoundation.org/hubfs/LF%20Research/Open%20Source%20Maintainers%202023%20-%20Report.pdf): Exploring the people, practices, and constraints facing the world’s most critical open source software projects.
+- Vargas, Sophia (2023). [What brings you to open source?](https://opensource.google/static/documentation/publications/WhatBringsYouToOpenSource_2023.pdf) How can projects encourage sustainable open source participation? Google Open Source.
+
+CHAOSS Practitioner Guides are MIT licensed, living documents, and we welcome your feedback and input. You can suggest edits to this document at [https://github.com/chaoss/hugo/blob/main/content/practitioner%20guides/practitioner-guide-demonstrating-org-value.md](https://github.com/chaoss/hugo/blob/main/content/practitioner%20guides/practitioner-guide-demonstrating-org-value.md).
+
+# Appendix
+
+There are a number of important roles in open source projects that can provide value to your organization and improve the health of a project. These include, but aren’t limited to:
+
+- Triage and program management
+- Documentation
+- Communications and marketing
+- Events
+
+**Triage and Program Management**
+
+Having a product manager or program manager can help cut down on engineering time spent on things that aren’t really engineering efforts and that engineers might not be able to as efficiently as someone with expertise managing products and programs. Doing triage can provide awareness of open source project activities and issues that are important to your organization much earlier than if you were not involved. By reviewing incoming issues, assigning labels and priorities, and aiding in roadmap planning, your organization gets a number of benefits:
+
+- Prioritized triage of issues & bugs
+- Decreased time to resolve
+- Early awareness of potential breaking changes & security issues
+- De-risk usage of project by improving overall project health
+- Introduces better data to answer questions & track trends.
+
+Key Metrics:
+
+- Decreased [time to first response](https://chaoss.community/?p=3448) on issues and change requests
+- Decreased time to assignment
+- Decreased [issue resolution duration](https://chaoss.community/?p=3630) / [change request duration](https://chaoss.community/?p=3587)
+
+Long Term Health Metrics:
+
+- Increased contributor engagement and sustainability across a variety of metrics (e.g., [number of contributors](https://chaoss.community/?p=3630), [project velocity](https://chaoss.community/?p=3572), frequency of contributions, retention)
+- Positive sentiment on issues / change requests and other communication channels
+
+**Documentation**
+
+Many people rely on an open source project’s documentation when getting started, and good documentation can help reduce support requests for common questions or issues that can be headed off with good documentation. In particular, a well documented contributor guide can help with onboarding new people and creating a good start for a contributor funnel. They can increase adoption and general overall positive sentiment with improved site traffic, search engine findability, and other web statistics. Contributors rarely want to do the big initial heavy lift to create documentation from scratch, but if a project has good docs to start, folks are much more open to keeping them updated. **“Having good docs leads to better docs.”** Well-documented open source projects are easier for users to understand and utilize, thus aiding in contributor sustainability, and your organization gets the following benefits:
+
+- Better developer experience
+- Increases ability to self-service / decreased engineering time
+- De-risk usage of project by improving overall project health
+
+Metrics:
+
+- Decreased support questions opened
+- Increased site traffic & accompanying site metrics
+
+Long Term Health Metrics:
+
+- Increased [new contributor](https://chaoss.community/?p=3613) engagement & retention
+- Positive sentiment on issues and change requests
+
+**Communications and Marketing**
+
+Open source projects often lack both the knowledge and skills regarding communication & marketing best practices. Maintainers and engineers do not always have the skills required to craft the right message to get attention, and they often appreciate help with marketing and outreach, which allows them to focus on the technical aspects that are more comfortable for them (Linåker et al., 2024). As an example of unclear and overcomplicated messaging, the description for an enhancement proposal was originally, “This KEP proposes to allow mutating spec.completions for Indexed job if spec.completions equals to spec.parallelism before and after the update, meaning that spec.completions is mutable only in tandem with spec.parallelism.” It was rewritten as, “Enables autoscaling for Indexed Jobs.” By providing resources for communications and marketing, your organization can see the following benefits:
+
+- Improved brand awareness & association
+- De-risk usage of project by driving more adoption and conversion to contributors
+- Early awareness of potential breaking changes
+
+Metrics
+
+- Increased traffic to website and accompanying site metrics
+- Increased social engagement
+- Increased share of voice
+
+Long Term Health Metrics
+
+- Growth in [adoption](https://chaoss.community/?p=3573) (e.g., downloads, stars / forks, share of voice)
+- Positive sentiment on communication channels
+
+**Events**
+
+Events serve many purposes, from new contributor workshops to help with onboarding, to summits with many high-bandwidth conversations that can unblock development. Many open source projects resolve blockers and bigger issues at events (Foster, 2018), and being in the room can be a huge advantage to make sure your organization’s needs are considered. They’re also useful for workshops and training new contributors. Events are often underestimated, but they help with creating a healthy project, and are important. Your organization benefits in several ways:
+
+- Workshops can serve as onboarding or additional skill-up opportunities
+- Being “in-the-room” can ensure organizational needs are addressed
+- De-risk usage of project by improving overall project health
+
+Metrics:
+
+- Tracking contributions from attendees
+- Conversions from attendees / contributors to maintainers
+- Unblocked issues/features
+
+Long Term Health Metrics:
+
+- Increased contributor engagement and sustainability across a variety of metrics (e.g., [number of contributors](https://chaoss.community/?p=3630), [project velocity](https://chaoss.community/?p=3572), frequency of contributions, retention)
+- Increase in conversion from contributors to maintainers
+
+CHAOSS Practitioner Guides are MIT licensed, living documents, and we welcome your feedback and input. You can suggest edits to this document at [https://github.com/chaoss/hugo/blob/main/content/practitioner%20guides/practitioner-guide-demonstrating-org-value.md](https://github.com/chaoss/hugo/blob/main/content/practitioner%20guides/practitioner-guide-demonstrating-org-value.md).
 
  [1]: https://chaoss.community/practitioner-guide-introduction/
  [2]: https://project.linuxfoundation.org/hubfs/LF%20Research/Open%20Source%20Maintainers%202023%20-%20Report.pdf?hsLang=en
@@ -896,4 +439,4 @@ Bugs, security, and issues are useful because most people understand them withou
  [8]: https://chaoss.community/?p=3534
  [9]: https://chaoss.community/practitioner-guide-contributor-sustainability/
  [10]: https://chaoss.community/practitioner-guide-security/
- [11]: https://helm.sh/blog/the-road-to-helm-4/
\ No newline at end of file
+ [11]: https://helm.sh/blog/the-road-to-helm-4/
diff --git a/content/practitioner guides/practitioner-guide-funding-impact.md b/content/practitioner guides/practitioner-guide-funding-impact.md
index bf9a824..3eeaef2 100644
--- a/content/practitioner guides/practitioner-guide-funding-impact.md	
+++ b/content/practitioner guides/practitioner-guide-funding-impact.md	
@@ -11,7 +11,6 @@ nectar-metabox-portfolio-display-sortable:
   - off
 url: /practitioner-guide-funding-impact
 ---
-\[vc\_row type=&#8221;in\_container&#8221; full\_screen\_row\_position=&#8221;middle&#8221; column\_margin=&#8221;default&#8221; column\_direction=&#8221;default&#8221; column\_direction\_tablet=&#8221;default&#8221; column\_direction\_phone=&#8221;default&#8221; scene\_position=&#8221;center&#8221; text\_color=&#8221;dark&#8221; text\_align=&#8221;left&#8221; row\_border\_radius=&#8221;none&#8221; row\_border\_radius\_applies=&#8221;bg&#8221; overlay\_strength=&#8221;0.3&#8243; gradient\_direction=&#8221;left\_to\_right&#8221; shape\_divider\_position=&#8221;bottom&#8221; bg\_image\_animation=&#8221;none&#8221;\]\[vc\_column column\_padding=&#8221;no-extra-padding&#8221; column\_padding\_tablet=&#8221;inherit&#8221; column\_padding\_phone=&#8221;inherit&#8221; column\_padding\_position=&#8221;all&#8221; background\_color\_opacity=&#8221;1&#8243; background\_hover\_color\_opacity=&#8221;1&#8243; column\_shadow=&#8221;none&#8221; column\_border\_radius=&#8221;none&#8221; column\_link\_target=&#8221;\_self&#8221; gradient\_direction=&#8221;left\_to\_right&#8221; overlay\_strength=&#8221;0.3&#8243; width=&#8221;1/1&#8243; tablet\_width\_inherit=&#8221;default&#8221; tablet\_text\_alignment=&#8221;default&#8221; phone\_text\_alignment=&#8221;default&#8221; column\_border\_width=&#8221;none&#8221; column\_border\_style=&#8221;solid&#8221; bg\_image\_animation=&#8221;none&#8221;\]
 
 # Practitioner Guide: Funding Impact Measurement
 
@@ -25,13 +24,13 @@ The audience for this guide is organizations who seek to demonstrate and/or just
 
 Open source software has become ubiquitous and can be found in almost every codebase, but sustaining those open source projects and communities over the long-term can be a challenge. Historically, much of the funding provided to open source projects has been for development of new projects and/or new features with the goal of fostering novel innovation. However, only funding innovation is not enough to ensure the sustainability of open source projects (Osborne, 2024). Several high profile, widely spread security vulnerabilities in open source projects (e.g., Log4Shell, Heartbleed) have also highlighted the need to fund maintenance and security and maintenance work in critical projects. With the push toward digital sovereignty and the recognition of the role that open source software can play, governments are now funding the maintenance of popular open source projects (e.g., [Sovereign Tech Agency in Germany][4], the work toward an [EU Sovereign Tech Fund][5]). Similarly, many companies are also seeking to support the open source projects that they rely on and use in their business operations. The role of open source software for supply chain security is also becoming increasingly important as governments, corporate procurement teams, and other groups start to create Software Bill of Materials (SBOMs) mandates.
 
-Much of the critical infrastructure that we all rely on is made up of open source projects that lack the resources to be properly maintained over the long term. Companies, public institutions, and philanthropic organizations are beginning to fill this gap, but measuring the impact of this funding is an ongoing challenge (Osborne et al., 2024). Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as to adapting and/or innovating [funding approaches][6] whilst mitigating ineffective or even harmful approaches. We all benefit from more public institutions, philanthropic organizations, and companies giving money to open source; when done in a way that positive impact is the ultimate goal and objective. 
+Much of the critical infrastructure that we all rely on is made up of open source projects that lack the resources to be properly maintained over the long term. Companies, public institutions, and philanthropic organizations are beginning to fill this gap, but measuring the impact of this funding is an ongoing challenge (Osborne et al., 2024). Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as to adapting and/or innovating [funding approaches][6] whilst mitigating ineffective or even harmful approaches. We all benefit from more public institutions, philanthropic organizations, and companies giving money to open source; when done in a way that positive impact is the ultimate goal and objective.
 
 # Challenges
 
 Interest in open source funding is increasing, but there is little consensus on how to measure them in a meaningful way. Not only is the measurement of the impacts of open source funding challenging, but it is complicated by the fact that introducing funding into open source projects may change contributor incentives and the balance of voluntary and paid participation when some contributors become funded for project work. Funding may or may not be the right solution for all projects, and funders need to think about the best way to achieve their goals when funding projects. For example, general funding may not improve the security posture of open source projects as well as targeted support designed to strengthen security (Brackett, et. al., 2025) By better understanding the impacts of funding (or lack of), funders can learn more about what works well for different types of open source projects so that the funding provided can have the greatest benefit for fundees and more widely across the entire ecosystem.
 
-Developing standardized funding impact measurement frameworks also presents challenges because the goals and objectives for the funding varies widely by funding organization and open source project, and how impact is measured depends on those goals and objectives. For example, providing funding for new feature development vs. funding for security fixes and maintenance require different funding impact measurement approaches. 
+Developing standardized funding impact measurement frameworks also presents challenges because the goals and objectives for the funding varies widely by funding organization and open source project, and how impact is measured depends on those goals and objectives. For example, providing funding for new feature development vs. funding for security fixes and maintenance require different funding impact measurement approaches.
 
 # Lessons Learned
 
@@ -53,7 +52,7 @@ Different funding instruments and procurement – whether milestone-based contra
 
 ### Consider Project Life Stages and Social Structures
 
-The impacts of funding vary depending on both a project's life stage and its social structure. For example, a new prototype project will have very different needs and potential outcomes compared to a mature project with an established community. While the prototype might need funding to build initial features and attract contributors, the mature project might require support for security improvements or maintenance work. 
+The impacts of funding vary depending on both a project's life stage and its social structure. For example, a new prototype project will have very different needs and potential outcomes compared to a mature project with an established community. While the prototype might need funding to build initial features and attract contributors, the mature project might require support for security improvements or maintenance work.
 
 Similarly, considering the social structure of a project is crucial for understanding funding impacts. For instance, Nadia Asparouhova (was Eghbal) (2020) identifies four distinct models of open source projects based on their contributor and user ratios: federations, clubs, stadiums, and toys. Funding for a federation-type project might need to account for complex governance processes and multiple working groups, while funding for a stadium-type project might focus on supporting its small core of maintainers who serve a large user base. These structural differences affect not only how funding should be allocated but also how its impact should be measured.
 
@@ -65,257 +64,78 @@ Salary structures and cost factors across regions and organizations should also
 
 Funding can have many different types of impacts, which funders might want to consider (see also the [Superbloom toolkit][7]). The potential social, economic, and technological impacts can be both positive and negative, direct and indirect, internal (i.e. within a project) and external (i.e. among a project’s ecosystem of dependents and users), and manifest over various time horizons.
 
-When assessing the impacts of open source funding, there may be a tendency to focus on technological impacts, which may in part be due to the technological nature of open source development or the relative ease of measuring technological impacts due to data availability from repositories. However, the potential impacts of funding extend beyond the code itself, and it is crucial to consider economic and social impacts on projects and their wider ecosystems of dependents and users. It is also important to note that impacts are not linear or unidirectional; funding can lead to both improvements and degradations across different metrics. This multidirectional nature of impacts means that measurement frameworks need to be flexible to capture both positive and negative changes, rather than assuming funding inherently leads to improvements or that metrics only move in one direction. Illustrative examples of various impacts can be found in the table below. 
+When assessing the impacts of open source funding, there may be a tendency to focus on technological impacts, which may in part be due to the technological nature of open source development or the relative ease of measuring technological impacts due to data availability from repositories. However, the potential impacts of funding extend beyond the code itself, and it is crucial to consider economic and social impacts on projects and their wider ecosystems of dependents and users. It is also important to note that impacts are not linear or unidirectional; funding can lead to both improvements and degradations across different metrics. This multidirectional nature of impacts means that measurement frameworks need to be flexible to capture both positive and negative changes, rather than assuming funding inherently leads to improvements or that metrics only move in one direction. Illustrative examples of various impacts can be found in the table below.
 
 **Examples of Social, Economic, Technological Impact Areas of Open Source Funding**
 
-<table>
-  <tr>
-    <td>
-    </td>
-    
-    <td>
-      <strong>Internal Impacts (Project-level)</strong>
-    </td>
-    
-    <td>
-      <strong>External Impacts (Ecosystem-level)</strong>
-    </td>
-  </tr>
-  
-  <tr>
-    <td>
-      <strong>Direct</strong></p> 
-      
-      <p>
-        <strong>Impacts</strong> </td> 
-        
-        <td>
-          <ul>
-            <li>
-              <em>Social:</em> <a href="https://chaoss.community/?p=3630">Contributor</a> retention, <a href="https://chaoss.community/?p=3432">community engagement</a>, <a href="https://chaoss.community/?p=3507">community events</a>, <a href="https://chaoss.community/?p=4889">contributor diversity</a>, work-life balance, reduced <a href="https://chaoss.community/?p=3537">burnout</a>, <a href="https://chaoss.community/?p=3524">mentorship</a>
-            </li>
-            <li>
-              <em>Economic:</em> <a href="https://chaoss.community/?p=3559">Paid developer time</a> / support roles, infrastructure coverage, conference sponsorship, project-related revenue via various channels
-            </li>
-            <li>
-              <em>Technological:</em> <a href="https://chaoss.community/?p=3448">Maintainer responsiveness</a>, commit <a href="https://chaoss.community/?p=3572">velocity</a>, code <a href="https://chaoss.community/?p=3939">security</a>, <a href="https://chaoss.community/?p=3976">dependency management</a>, <a href="https://chaoss.community/?p=3532">documentation quality</a>, <a href="https://chaoss.community/?p=4765">consistent releases</a>
-            </li>
-          </ul>
-        </td>
-        
-        <td>
-          <ul>
-            <li>
-              <em>Social:</em> User trust, ecosystem community, ecosystem events
-            </li>
-            <li>
-              <em>Economic:</em> Cost savings for adopters, integration/support costs, shared maintenance burden
-            </li>
-            <li>
-              <em>Technological:</em> Stability of APIs, ecosystem-wide security updates, interoperability
-            </li>
-          </ul>
-        </td></tr> 
-        
-        <tr>
-          <td>
-            <strong>Indirect</strong></p> 
-            
-            <p>
-              <strong>Impacts</strong> </td> 
-              
-              <td>
-                <ul>
-                  <li>
-                    <em>Social:</em> <a href="https://chaoss.community/?p=3522">Leadership development</a>, <a href="https://chaoss.community/?p=3516">governance</a> and decision-making processes, knowledge preservation, <a href="https://chaoss.community/?p=5430">conflict resolution/prevention mechanisms</a>
-                  </li>
-                  <li>
-                    <em>Economic: </em><a href="https://chaoss.community/?p=3567">Job</a> market value for developers, partnership opportunities, <a href="https://chaoss.community/?p=3583">academic</a> collaborations, consulting opportunities, funding diversity
-                  </li>
-                  <li>
-                    <em>Technological: </em>Standardisation, interoperability
-                  </li>
-                </ul>
-              </td>
-              
-              <td>
-                <ul>
-                  <li>
-                    <em>Social:</em> Cross-project collaboration, training & education resources, ecosystem engagement
-                  </li>
-                  <li>
-                    <em>Economic: </em>Market growth, job creation, industry cost reduction, start-up creation
-                  </li>
-                  <li>
-                    <em>Technological: </em>Standardisation, research papers, patents, ecosystem-wide security improvements
-                  </li>
-                </ul>
-              </td></tr> </table> 
-              
-              <p>
-                When measuring the impact of funding on open source development, it is crucial to consider the effects across different time horizons. The influence of funding can manifest differently in the <strong>short, medium, and long term</strong>, which is essential for a comprehensive understanding of funding impacts.
-              </p>
-              
-              <ol>
-                <li>
-                  Short term (<1 year): These are the immediate effects of funding, which may be easier to observe and attribute to the funding received. Short-term impacts might include immediate increases in <a href="https://chaoss.community/?p=3444">development activity</a>, improvements in code quality, or rapid growth in <a href="https://chaoss.community/?p=3484">community size</a>.
-                </li>
-                <li>
-                  Medium term (1-3 years): Medium-term impacts may reveal how the project adapts and grows with the resources provided. This period might show the development of new features, expansion of the project’s reach, or evolution of the project’s governance structures.
-                </li>
-                <li>
-                  Long term (>3 years): Long-term impacts are the enduring effects of funding that manifest over an extended period, which can be the most challenging to measure and attribute directly to funding.
-                </li>
-              </ol>
-              
-              <h2>
-                Methods
-              </h2>
-              
-              <p>
-                When it comes to measuring the impacts, funders can consider a breadth of methods for impact measurement. We recommend using a mixed methods approach, which provides a way to combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact.
-              </p>
-              
-              <p>
-                <strong>Quantitative methods</strong> offer a structured, scalable approach for measuring relationships between funding and outcomes in open source projects and their ecosystems. Starting with the funding objectives provides a focus for metric selection, rather than trying to cast a wide net that includes metrics that aren’t as relevant. These quantitative metrics can be gathered from repositories, surveys, and other sources, but there are also challenges. Some data isn’t often available for open source projects (e.g., <a href="https://chaoss.community/?p=3573">usage</a>, non-code contributions), and open source projects have different ways of working (e.g., commit strategies, <a href="https://chaoss.community/?p=4712">code review</a> processes) that make analysis more difficult.
-              </p>
-              
-              <p>
-                <strong>Qualitative</strong> <strong>methods</strong>, such as case studies, interviews, and participant observation, are useful strategies for collecting contextual data about the history, role, and impacts of funding on open source projects. A major strength of interviews lies in their ability to provide rich, contextual understandings by gaining insights into the perspective of the funding recipients, revealing why funding was needed and how it has influenced project dynamics, individual motivations, and community structures. Qualitative methods are useful for capturing intangible outcomes and hard-to-quantify impacts, such as changes in project culture or enhancements in the overall sustainability of the project, which often play a crucial role in the long-term success of open source projects but can be challenging to measure through quantitative means alone. Challenges can include securing the right people for interviews, ensuring representation, and the time required to conduct and analyze qualitative data.
-              </p>
-              
-              <p>
-                <strong><a href="https://arxiv.org/pdf/2411.06027">Mixed-Methods</a></strong> approaches that combine qualitative and quantitative techniques offer the best of both words: scalability and contextual depth. Mixed-methods approaches are particularly useful for examining complex open source ecosystems, where development spans multiple channels and goes beyond repositories. There are several ways to conduct mixed methods approaches. By starting with quantitative data the subsequent qualitative phase can be used to better explain the earlier data, which can be especially useful when looking at a large number of projects. On the other hand, starting with qualitative data offers a more exploratory approach that can be used to decide which quantitative measures to use, which may offer a better way to discover unanticipated impacts. They can also be collected and analyzed concurrently using a maturity model approach to create a holistic view of the development of an open source project, but this can be time-consuming and challenging to get agreement on what constitutes maturity.
-              </p>
-              
-              <p>
-                A much more detailed assessment of the strengths and weaknesses of qualitative, quantitative, and mixed methods approaches can be found in Section 3.4 of Osborne et al., (2024) with a summary in Table 3 on page 10.
-              </p>
-              
-              <h1>
-                Conclusion
-              </h1>
-              
-              <p>
-                While measuring the impact of funding open source projects can be challenging, this guide provides a framework for ways that impact(s) can be measured based on lessons learned from organizations already doing this work. By starting with the organization’s funding objectives, understanding the open source projects being funded, and accounting for cost factors, the funding initiatives can be put in the proper context before starting to measure the impact. This can be followed by an assessment of the economic, social and technological impacts that consider direct / indirect impacts along with project-level / ecosystem level impact to think about the metrics and timelines that might be important in your context. The final step is to consider how using a mixed-methods approach can combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact. The case studies section includes examples of organizations who are already doing this work.
-              </p>
-              
-              <p>
-                Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as to adapting and/or innovating funding approaches whilst mitigating ineffective or even harmful approaches. We all benefit from more public institutions, philanthropic organizations, and companies giving money to open source; when done in a way that positive impact is the ultimate goal and objective. We hope that this guide helps organizations measure the impact of their funding initiatives so that we can increase the funding to open source projects to drive future improvements and allow these projects, and the people working on them, to become healthier and more sustainable over time.
-              </p>
-              
-              <h1>
-                Cautions and Considerations
-              </h1>
-              
-              <ul>
-                <li>
-                  There is no one-size-fits-all approach to measuring impact. Measuring the impact(s) of open source project funding is something that we’re all figuring out as we go along, so we expect this space to evolve over time as we learn more about the best ways to measure impact.
-                </li>
-                <li>
-                  Funding may or may not be the right solution for all projects and can result in both positive and negative impacts for projects. Funding can introduce unanticipated challenges for open source projects, especially the first time they receive funding, and some projects struggle to use their funding.
-                </li>
-                <li>
-                  Open source projects are made up of people, and money can create complications. Funding into open source projects can change contributor incentives and the balance of voluntary and paid participation, which should be considered when measuring impact.
-                </li>
-              </ul>
-              
-              <h1>
-                Additional Resources
-              </h1>
-              
-              <ul>
-                <li>
-                  <a href="https://arxiv.org/abs/2411.06027">A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development</a> - this paper was the starting point for this guide, and it provides many more details on the subject.
-                </li>
-                <li>
-                  <a href="https://github.com/chaoss/wg-funding-impact">CHAOSS Funding Impact Measurement Working Group</a> - join us!
-                </li>
-                <li>
-                  <a href="https://recommendations.implicit-development.org/">Roadwork ahead: Evaluating the needs of FOSS communities working on digital infrastructure in the public interest</a>
-                </li>
-                <li>
-                  <a href="https://podcast.chaoss.community/106">Podcast: Funding Impact Measurement Working Group on CHAOSScast</a> in March 2025.
-                </li>
-                <li>
-                  <a href="https://25.foss-backstage.de/schedule/#session/7UJYUR/">Toolkit for Measuring the Impacts of Public Funding for OSS</a> at FOSS Backstage in Berlin in March 2025 (<a href="https://25.foss-backstage.de/session/toolkit-for-measuring-the-impacts-of-public-funding-for-foss/">video</a>).
-                </li>
-                <li>
-                  <a href="https://sched.co/1zfhR">Panel: The Impact of Funding for Sustainable Open Source Projects</a> with Georg Link, Andrew Nesbitt, and Alyssa Wright at the Open Source Summit NA in Denver in June 2025 (<a href="https://www.youtube.com/watch?v=8sD81Dqw0Os">video</a>).
-                </li>
-                <li>
-                  <a href="https://fossfunders.com/">FOSS Funders</a>
-                </li>
-                <li>
-                  <a href="https://infrastructureinsights.fund/projects/oss-research-software/">OSS Research-Software: Incentivizing Investment in and Adoption of Open Infrastructure for Research through Community Health Assessments</a>
-                </li>
-                <li>
-                  <a href="https://investinopen.org/blog/building-bridges-how-trust-and-community-health-frameworks-can-strengthen-open-infrastructure-decision-making/">Building bridges: How trust and community health frameworks can strengthen open infrastructure decision-making</a>
-                </li>
-                <li>
-                  <a href="https://buildingblocks.superbloom.design/about/">Building Blocks: Digital Infrastructure Funding Toolkit</a>
-                </li>
-              </ul>
-              
-              <h1>
-                Contributors
-              </h1>
-              
-              <p>
-                The following people contributed to this guide:
-              </p>
-              
-              <ul>
-                <li>
-                  Dawn Foster
-                </li>
-                <li>
-                  Cailean Osborne
-                </li>
-                <li>
-                  Paul Sharratt
-                </li>
-                <li>
-                  Mirko Boehm
-                </li>
-                <li>
-                  Serkan Holat
-                </li>
-                <li>
-                  Katharina Meyer
-                </li>
-              </ul>
-              
-              <h1>
-                References
-              </h1>
-              
-              <ul>
-                <li>
-                  Brackett, S. A., Scott, S., and Chen, C. (2025). <a href="https://infrastructureinsights.fund/wp-content/uploads/2025/12/CSINTPolicyPaperNo22025BrackettScottandCheng.pdf">Buying Security: Open Source Software Funding and Security Posture</a>. CSINT Policy Paper Series. Fall 2025.
-                </li>
-                <li>
-                  Casari, A., Ferraioli, J., & Lovato, J. (2023). <a href="https://dl.acm.org/doi/pdf/10.1145/3605160">Beyond the Repository</a>. <em>Communications of the ACM</em>, <em>66</em>(10), 50-55.
-                </li>
-                <li>
-                  Asparouhova, N. (2020). <em>Working in public: the making and maintenance of open source software</em>. Stripe Press.
-                </li>
-                <li>
-                  Osborne, C., Sharratt, P., Foster, D., & Boehm, M. (2024). <a href="https://arxiv.org/abs/2411.06027">A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development</a>. <em>arXiv preprint arXiv:2411.06027</em>.
-                </li>
-                <li>
-                  Osborne, C. (2024). <a href="https://dl.acm.org/doi/abs/10.1145/3678884.3681844">Open Source Software Developers' Views on Public and Private Funding: A Case Study on scikit-learn</a>. In Companion Publication of the 2024 Conference on Computer-Supported Cooperative Work and Social Computing (CSCW Companion '24). Association for Computing Machinery, New York, NY, USA, 154–161. <a href="https://doi.org/10.1145/3678884.3681844">https://doi.org/10.1145/3678884.3681844</a>
-                </li>
-              </ul>
-              
-              <p>
-                CHAOSS Practitioner Guides are MIT licensed, living documents, and we welcome your feedback and input. You can suggest edits to this document at <a href="https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/funding-impact.md">https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/funding-impact.md</a>
-              </p>
-              
-              <p>
-                [/vc_column][/vc_row]
-              </p>
+| | Internal Impacts (Project-level) | External Impacts (Ecosystem-level) |
+| :--- | :--- | :--- |
+| **Direct Impacts** | <ul><li>*Social:* [Contributor](https://chaoss.community/?p=3630) retention, [community engagement](https://chaoss.community/?p=3432), [community events](https://chaoss.community/?p=3507), [contributor diversity](https://chaoss.community/?p=4889), work-life balance, reduced [burnout](https://chaoss.community/?p=3537), [mentorship](https://chaoss.community/?p=3524)</li><li>*Economic:* [Paid developer time](https://chaoss.community/?p=3559) / support roles, infrastructure coverage, conference sponsorship, project-related revenue via various channels</li><li>*Technological:* [Maintainer responsiveness](https://chaoss.community/?p=3448), commit [velocity](https://chaoss.community/?p=3572), code [security](https://chaoss.community/?p=3939), [dependency management](https://chaoss.community/?p=3976), [documentation quality](https://chaoss.community/?p=3532), [consistent releases](https://chaoss.community/?p=4765)</li></ul> | <ul><li>*Social:* User trust, ecosystem community, ecosystem events</li><li>*Economic:* Cost savings for adopters, integration/support costs, shared maintenance burden</li><li>*Technological:* Stability of APIs, ecosystem-wide security updates, interoperability</li></ul> |
+| **Indirect Impacts** | <ul><li>*Social:* [Leadership development](https://chaoss.community/?p=3522), [governance](https://chaoss.community/?p=3516) and decision-making processes, knowledge preservation, [conflict resolution/prevention mechanisms](https://chaoss.community/?p=5430)</li><li>*Economic:* [Job](https://chaoss.community/?p=3567) market value for developers, partnership opportunities, [academic](https://chaoss.community/?p=3583) collaborations, consulting opportunities, funding diversity</li><li>*Technological:* Standardisation, interoperability</li></ul> | <ul><li>*Social:* Cross-project collaboration, training & education resources, ecosystem engagement</li><li>*Economic:* Market growth, job creation, industry cost reduction, start-up creation</li><li>*Technological:* Standardisation, research papers, patents, ecosystem-wide security improvements</li></ul> |
+
+When measuring the impact of funding on open source development, it is crucial to consider the effects across different time horizons. The influence of funding can manifest differently in the **short, medium, and long term**, which is essential for a comprehensive understanding of funding impacts.
+
+1. Short term (<1 year): These are the immediate effects of funding, which may be easier to observe and attribute to the funding received. Short-term impacts might include immediate increases in [development activity](https://chaoss.community/?p=3444), improvements in code quality, or rapid growth in [community size](https://chaoss.community/?p=3484).
+2. Medium term (1-3 years): Medium-term impacts may reveal how the project adapts and grows with the resources provided. This period might show the development of new features, expansion of the project’s reach, or evolution of the project’s governance structures.
+3. Long term (>3 years): Long-term impacts are the enduring effects of funding that manifest over an extended period, which can be the most challenging to measure and attribute directly to funding.
+
+## Methods
+
+When it comes to measuring the impacts, funders can consider a breadth of methods for impact measurement. We recommend using a mixed methods approach, which provides a way to combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact.
+
+**Quantitative methods** offer a structured, scalable approach for measuring relationships between funding and outcomes in open source projects and their ecosystems. Starting with the funding objectives provides a focus for metric selection, rather than trying to cast a wide net that includes metrics that aren’t as relevant. These quantitative metrics can be gathered from repositories, surveys, and other sources, but there are also challenges. Some data isn’t often available for open source projects (e.g., [usage](https://chaoss.community/?p=3573), non-code contributions), and open source projects have different ways of working (e.g., commit strategies, [code review](https://chaoss.community/?p=4712) processes) that make analysis more difficult.
+
+**Qualitative methods**, such as case studies, interviews, and participant observation, are useful strategies for collecting contextual data about the history, role, and impacts of funding on open source projects. A major strength of interviews lies in their ability to provide rich, contextual understandings by gaining insights into the perspective of the funding recipients, revealing why funding was needed and how it has influenced project dynamics, individual motivations, and community structures. Qualitative methods are useful for capturing intangible outcomes and hard-to-quantify impacts, such as changes in project culture or enhancements in the overall sustainability of the project, which often play a crucial role in the long-term success of open source projects but can be challenging to measure through quantitative means alone. Challenges can include securing the right people for interviews, ensuring representation, and the time required to conduct and analyze qualitative data.
+
+**[Mixed-Methods](https://arxiv.org/pdf/2411.06027)** approaches that combine qualitative and quantitative techniques offer the best of both words: scalability and contextual depth. Mixed-methods approaches are particularly useful for examining complex open source ecosystems, where development spans multiple channels and goes beyond repositories. There are several ways to conduct mixed methods approaches. By starting with quantitative data the subsequent qualitative phase can be used to better explain the earlier data, which can be especially useful when looking at a large number of projects. On the other hand, starting with qualitative data offers a more exploratory approach that can be used to decide which quantitative measures to use, which may offer a better way to discover unanticipated impacts. They can also be collected and analyzed concurrently using a maturity model approach to create a holistic view of the development of an open source project, but this can be time-consuming and challenging to get agreement on what constitutes maturity.
+
+A much more detailed assessment of the strengths and weaknesses of qualitative, quantitative, and mixed methods approaches can be found in Section 3.4 of Osborne et al., (2024) with a summary in Table 3 on page 10.
+
+# Conclusion
+
+While measuring the impact of funding open source projects can be challenging, this guide provides a framework for ways that impact(s) can be measured based on lessons learned from organizations already doing this work. By starting with the organization’s funding objectives, understanding the open source projects being funded, and accounting for cost factors, the funding initiatives can be put in the proper context before starting to measure the impact. This can be followed by an assessment of the economic, social and technological impacts that consider direct / indirect impacts along with project-level / ecosystem level impact to think about the metrics and timelines that might be important in your context. The final step is to consider how using a mixed-methods approach can combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact. The case studies section includes examples of organizations who are already doing this work.
+
+Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as to adapting and/or innovating funding approaches whilst mitigating ineffective or even harmful approaches. We all benefit from more public institutions, philanthropic organizations, and companies giving money to open source; when done in a way that positive impact is the ultimate goal and objective. We hope that this guide helps organizations measure the impact of their funding initiatives so that we can increase the funding to open source projects to drive future improvements and allow these projects, and the people working on them, to become healthier and more sustainable over time.
+
+# Cautions and Considerations
+
+- There is no one-size-fits-all approach to measuring impact. Measuring the impact(s) of open source project funding is something that we’re all figuring out as we go along, so we expect this space to evolve over time as we learn more about the best ways to measure impact.
+- Funding may or may not be the right solution for all projects and can result in both positive and negative impacts for projects. Funding can introduce unanticipated challenges for open source projects, especially the first time they receive funding, and some projects struggle to use their funding.
+- Open source projects are made up of people, and money can create complications. Funding into open source projects can change contributor incentives and the balance of voluntary and paid participation, which should be considered when measuring impact.
+
+# Additional Resources
+
+- [A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development](https://arxiv.org/abs/2411.06027) - this paper was the starting point for this guide, and it provides many more details on the subject.
+- [CHAOSS Funding Impact Measurement Working Group](https://github.com/chaoss/wg-funding-impact) - join us!
+- [Roadwork ahead: Evaluating the needs of FOSS communities working on digital infrastructure in the public interest](https://recommendations.implicit-development.org/)
+- [Podcast: Funding Impact Measurement Working Group on CHAOSScast](https://podcast.chaoss.community/106) in March 2025.
+- [Toolkit for Measuring the Impacts of Public Funding for OSS](https://25.foss-backstage.de/schedule/#session/7UJYUR/) at FOSS Backstage in Berlin in March 2025 ([video](https://25.foss-backstage.de/session/toolkit-for-measuring-the-impacts-of-public-funding-for-foss/)).
+- [Panel: The Impact of Funding for Sustainable Open Source Projects](https://sched.co/1zfhR) with Georg Link, Andrew Nesbitt, and Alyssa Wright at the Open Source Summit NA in Denver in June 2025 ([video](https://www.youtube.com/watch?v=8sD81Dqw0Os)).
+- [FOSS Funders](https://fossfunders.com/)
+- [OSS Research-Software: Incentivizing Investment in and Adoption of Open Infrastructure for Research through Community Health Assessments](https://infrastructureinsights.fund/projects/oss-research-software/)
+- [Building bridges: How trust and community health frameworks can strengthen open infrastructure decision-making](https://investinopen.org/blog/building-bridges-how-trust-and-community-health-frameworks-can-strengthen-open-infrastructure-decision-making/)
+- [Building Blocks: Digital Infrastructure Funding Toolkit](https://buildingblocks.superbloom.design/about/)
+
+# Contributors
+
+The following people contributed to this guide:
+
+- Dawn Foster
+- Cailean Osborne
+- Paul Sharratt
+- Mirko Boehm
+- Serkan Holat
+- Katharina Meyer
+
+# References
+
+- Brackett, S. A., Scott, S., and Chen, C. (2025). [Buying Security: Open Source Software Funding and Security Posture](https://infrastructureinsights.fund/wp-content/uploads/2025/12/CSINTPolicyPaperNo22025BrackettScottandCheng.pdf). CSINT Policy Paper Series. Fall 2025.
+- Casari, A., Ferraioli, J., & Lovato, J. (2023). [Beyond the Repository](https://dl.acm.org/doi/pdf/10.1145/3605160). *Communications of the ACM*, *66*(10), 50-55.
+- Asparouhova, N. (2020). *Working in public: the making and maintenance of open source software*. Stripe Press.
+- Osborne, C., Sharratt, P., Foster, D., & Boehm, M. (2024). [A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development](https://arxiv.org/abs/2411.06027). *arXiv preprint arXiv:2411.06027*.
+- Osborne, C. (2024). [Open Source Software Developers' Views on Public and Private Funding: A Case Study on scikit-learn](https://dl.acm.org/doi/abs/10.1145/3678884.3681844). In Companion Publication of the 2024 Conference on Computer-Supported Cooperative Work and Social Computing (CSCW Companion '24). Association for Computing Machinery, New York, NY, USA, 154–161. [https://doi.org/10.1145/3678884.3681844](https://doi.org/10.1145/3678884.3681844)
+
+CHAOSS Practitioner Guides are MIT licensed, living documents, and we welcome your feedback and input. You can suggest edits to this document at https://github.com/chaoss/hugo/blob/main/content/practitioner%20guides/practitioner-guide-funding-impact.md
 
  [1]: https://chaoss.community/practitioner-guide-introduction/
  [2]: https://chaoss.community/practitioner-guide-demonstrating-org-value
@@ -323,4 +143,4 @@ When assessing the impacts of open source funding, there may be a tendency to fo
  [4]: https://www.bundeswirtschaftsministerium.de/Redaktion/EN/Pressemitteilungen/2022/10/20221018-the-sovereign-tech-fund-launches-funding-an-investment-in-europes-digital-sovereignty.html
  [5]: https://eu-stf.openforumeurope.org/
  [6]: https://recommendations.implicit-development.org/
- [7]: https://buildingblocks.superbloom.design/about/
\ No newline at end of file
+ [7]: https://buildingblocks.superbloom.design/about/