Change wording from Maturity ladder to Maturity Profiles

dotnet-foundation · Sep 28, 2019 · 9725fe3 · 9725fe3
1 parent 341a061
commit 9725fe3
Show file tree

Hide file tree

Showing 3 changed files with 4 additions and 4 deletions.
diff --git a/maturity-profiles-policies.md b/maturity-profiles-policies.md
@@ -40,7 +40,7 @@ Project users cannot register on the behalf of a maintainer. They are free to re
 
 Why link the maturity profiles with Foundation membership? In short, this is how other foundations work, and it is considered a good model for growing projects from incubation to graduation for broad ecosystem benefit. However, the working group sees significant value in making the maturity profiles a more generally applicable definition of quality for the ecosystem to use. That's why Foundation membership is part of the maturity profiles but doesn't start with it. Maturity profile #3 is considered a good point to include Foundation membership as a required characteristic.
 
-There are also more practical considerations. Maturity profiles 3 and 4 include requirements that require paying for things (like signing certificates). Maturity profile #4 includes a requirement to use trusted infrastructure. It is much easier to avoid maintainers having out-of-pocket expenses and to satisfy trust requirements if maturity profiles 3 and 4 are limited to .NET Foundation projects. It is also easier to add potentially costly ($) requirements later on, due to the changing requirements of the industry, if the Foundation simply pays those costs for Foundation projects. For example, the Foundation may upgrade to a higher cost version of static analysis tools and publish that as a new benefit of all maturity profile 3 and 4 projects.
+There are also more practical considerations. Maturity profiles #3 and #4 include requirements that require paying for things (like signing certificates). Maturity profile #4 includes a requirement to use trusted infrastructure. It is much easier to avoid maintainers having out-of-pocket expenses and to satisfy trust requirements if maturity profiles 3 and 4 are limited to .NET Foundation projects. It is also easier to add potentially costly ($) requirements later on, due to the changing requirements of the industry, if the Foundation simply pays those costs for Foundation projects. For example, the Foundation may upgrade to a higher cost version of static analysis tools and publish that as a new benefit of all maturity profile 3 and 4 projects.
 
 ## Existing .NET Foundation Projects
 

diff --git a/maturity-profiles.md b/maturity-profiles.md
@@ -24,7 +24,7 @@ The maturity profiles are described in terms of three categories: health, practi
 
 The health and practices listed for each maturity profile are intended as valuable and important, however, projects may be considered to achieve a maturity profile without satisfying every single line item. Some of the qualities are critical and others are more supporting (they are listed in order of importance, per category). Assessment of projects is intended to hit the sweet spot between rewarding maintainers for an honest effort to meet the requirements of a maturity profile and deliver on a confidence promise to users.
 
-### 1, Incubator
+### 1. Incubator
 
 This profile describes a project that is healthy, enabling easy and pleasant interaction and use for consumers. It is intended to be within reach of any project.
 
@@ -110,6 +110,6 @@ Corporate-backed projects can use .NET Foundation infrastructure (as described a
 
 The maturity profiles are intended to define and provide major improvements in quality and confidence improvements for project consumers. However, it provides no absolute guarantees. Even when viewed through the lens of "best effort and best intentions" on the part of maintainers, bad things can still happen that cause harm.
 
-Maturity profiles [Continuity practices](#Continuity-practices) and [Full security practices](#Full-security-practices) put stronger safeguards in place to mitigate a variety of undesired scenarios. They define a model for building confidence using open source community projects.
+Maturity profiles [Continuity practices](#3-continuity-practices) and [Full security practices](#4-full-security-practices) put stronger safeguards in place to mitigate a variety of undesired scenarios. They define a model for building confidence using open source community projects.
 
 Some projects may display badges that do not use the badge server, and therefore are based on self-assessment and may even be intentionally deceptive. This is not expected to be common and will be discouraged. The community may actively discourage maintainers from this practice. On GitHub, it is easy to tell the source of a badge.
diff --git a/project-continuation-policies.md b/project-continuation-policies.md
@@ -6,7 +6,7 @@ Project continuation is one of the most important, but least obvious, concerns f
 
 Level 3 projects must register a trusted successor in the case that the maintainer becomes unavailable. The successor can be a specific person or an organization. In the case that the project maintainer becomes unavailable, the trusted successor will be given access to project source, packages and any other critical assets, so that the project can continue functioning.
 
-The [project application process](project-ladder-policies#application) includes listing trusted successors.
+The [project application process](maturity-profiles-policies.md#application) includes listing trusted successors.
 
 The (yet unproven) assumption is that services like NuGet.org and GitHub will respect these maintainer-defined policies and enable adding the trusted successor(s) as an admin to an org, repo or package. Alternatively, projects can add a .NET Foundation account to act as a mechanical mediator between the maintainer and their successor, as required, using the same "unavailable" policy.