cncf · thisisobate · Jan 7, 2026 · Jan 7, 2026 · Jan 7, 2026
diff --git a/.cspell.yml b/.cspell.yml
@@ -24,13 +24,17 @@ words:
   - CLOTributor
   - CNCF
   - Docsy
+  - dwelsch
   - keda
+  - knative
   - kedacore
   - krook
+  - mkdocs
   - nate
   - nvmrc
   - subpages
   - techdocs
   - toolkits
   - toto
   - triaging
+  - Welsch
diff --git a/analyses/0001-contour.md b/analyses/0001-contour.md
@@ -47,7 +47,6 @@ criterion’s definition.
 ### Comments
 
 - **Information Architecture**:
-
   - Documentation is feature complete!
   - A clear "About" or "What is Contour?" page is missing. It partially exists
     on [Architecture](https://projectcontour.io/docs/v1.13.1/architecture) and
@@ -83,7 +82,6 @@ criterion’s definition.
     - What's the next doc I should read _after_ this to understand Contour and
       how to customize it for my use case?
 - **Content maintainability**:
-
   - Your documentation is searchable, which is great!
     - However, because there are docs on your site that live _outside_ of the
       docs directory, the entire site needs to be searchable.
@@ -111,7 +109,6 @@ criterion’s definition.
 ### Recommendations
 
 - **Information Architecture**:
-
   - The main issue with information architecture is titling.
   - **The guides section:** Having "Guides" as a top-level section which appears
     in the nav before documentation is a bit confusing. I recommend having
@@ -139,7 +136,6 @@ criterion’s definition.
     a small win and a great first issue.
 
 - **New user content**:
-
   - Work with a technical writer to revise your getting started page to provide
     a bit more background information about Contour for the true new learner and
     provide more "next steps" documentation.
@@ -221,7 +217,6 @@ website, and in the repo. Great job team!
 
 - **Branding and design**: one extremely small styling suggestion which would
   make a great first issue:
-
   - for `<h2>` elements on documentation pages, change the margin from
     `margin-bottom: 2rem` to `margin-top: 1rem; margin-bottom: 1rem` or
     (preferred) `margin-top: 1.5rem; margin-bottom: 0.5rem;`. In general it's
@@ -266,7 +261,6 @@ website, and in the repo. Great job team!
 The revised content could have the following structure, if desired:
 
 - Getting started guide:
-
   - Introduction to Project Contour
     - Project philosophy
     - Why choose Contour over another (less opinionated) ingress controller

diff --git a/analyses/0002-notary-project.md b/analyses/0002-notary-project.md
@@ -75,7 +75,6 @@ Criteria:
 
 - Is the documentation feature complete, as in each product feature is
   documented?
-
   - As the project is in ongoing development, not every feature is completed and
     so there are some holes in the documentation.
   - The
@@ -86,14 +85,12 @@ Criteria:
 
 - Are there step-by-step instructions (tasks, tutorials) documented for
   features?
-
   - Since V2's documentation is so conceptual at this point (consisting mostly
     of specification), it may be best to leave it as is &mdash; linking to it
     directly during the development process, and planning documentation along
     side the development of the system as a whole.
 
 - Is the “happy path”/most common use case documented?
-
   - The V1 Getting Started Guide is very good. Will V2 be able to draw from it?
 
 - If the documentation does not suffice, is there a clear escalation path for
@@ -181,7 +178,6 @@ Criteria
 ### Comments & recommendations
 
 - Most of the issues in this section are a function of not having a website yet.
-
   - As the website build process starts, put together a skeleton IA that can be
     filled in as the project grows.
 
@@ -190,7 +186,6 @@ Criteria
   https://prometheus.io/community/.
 
 - There is no documentation for:
-
   - Triaging docs issues
   - Clearly marking a way for new contributors to make code or documentation
     contributions (i.e. a “good first issue” label), and define what makes a

diff --git a/analyses/0003-krator.md b/analyses/0003-krator.md
@@ -54,7 +54,6 @@ Criteria:
 ### Comments
 
 - **Information Architecture**:
-
   - Documentation is currently in several locations and will need to be brought
     into one repo. The current resources are:
     - The project [README](https://github.com/krator-rs/krator)

diff --git a/analyses/0004-tremor.md b/analyses/0004-tremor.md
@@ -52,7 +52,6 @@ Scale:
 - **Information Architecture:** Project Tremor's documentation makes a number of
   individually small IA choices that culminate in a confusing experience for the
   user.
-
   - The [Getting Started](https://www.tremor.rs/getting-started/) section covers
     a number of seemingly random topics, with some appearing to be focused on
     selling the project to new users (i.e.
@@ -112,7 +111,6 @@ Scale:
 - **New user content:** Project Tremor has a Getting Started section but it's a
   little disorganized as mentioned above. This makes it difficult for an actual
   new user to understand.
-
   - [Starting Tremor for the first time](https://www.tremor.rs/getting-started/starting/)
     is the best part of the getting started guide. However, it mentions that
     there are "many ways" to install Tremor - it would be good to point users to
@@ -172,7 +170,6 @@ Scale:
 
 - **Get specific about your Getting Started:** Getting Started Guides contain a
   very predictable set of content:
-
   - In one paragraph or less, what is this piece of software
   - What prerequisite software (i.e. Kubernetes) and knowledge (i.e., Go) do I
     need on my system to launch this?
@@ -183,7 +180,6 @@ Scale:
 
 - **Reorganize the Operations section and retitle it "Using Tremor"**:
   Additionally, move some topics from the existing Getting Started section:
-
   - [Configuring Tremor](https://docs.tremor.rs/operations/configuration-walkthrough/)
     - [Walkthrough: Configure a Tremor Deployment](https://docs.tremor.rs/operations/configuration-walkthrough/)
   - [Connectivity: Onramps and Offramps](https://www.tremor.rs/getting-started/connectivity/)
@@ -207,7 +203,6 @@ Scale:
 - **Reorganize [Overview](https://docs.tremor.rs/overview/) with
   user-centeredness in mind**: I suggest creating a new section with the
   following content:
-
   - The information on [The docs index](https://docs.tremor.rs/) as a page
     titled "Overview", with subpages:
     - [Architecture Overview](https://docs.tremor.rs/overview/) (note: you could
@@ -218,7 +213,6 @@ Scale:
 
 - **Audit for colloquial/casual language, abbreviations, and other "basic"
   English:**
-
   - This recommendation has less to do with casual language or abbreviations
     being _bad_, and more to do with the perception of professionalism for the
     project.
@@ -269,7 +263,6 @@ Scale:
   and
   [issues for new users are tagged](https://github.com/tremor-rs/tremor-www-docs/issues?q=is%3Aissue+is%3Aclosed).
   Great work!
-
   - One thing to note is when tagging an issue
     [as a good first issue](https://github.com/tremor-rs/tremor-www-docs/issues/101),
     assume the reader knows nothing and must be hand-held through the entire
@@ -280,7 +273,6 @@ Scale:
   [Community](https://www.tremor.rs/community/) page exists but doesn't provide
   much guidance for new users. How do I get involved? When do community meetings
   happen? Where do I find the team on Discord or Slack?
-
   - As mentioned above, [Development](https://docs.tremor.rs/development/) and
     [Governance](https://docs.tremor.rs/CodeOfConduct/) are targeted at
     contributor users and should be under the community section.
@@ -296,7 +288,6 @@ Scale:
 
 - **Turn the Community page into a subsection and house Governance and
   Development documentation under it:**
-
   - Specifically, move [Development](https://docs.tremor.rs/development/) to
     /community/development
   - Move
@@ -325,7 +316,6 @@ Scale:
 **Comments**
 
 - **Branding and design:**
-
   - On the whole, the Tremor docs site looks professional, if a little plain.
   - Because of the way the site deploys (from different repositories via GitHub
     pages), navigation is disjointed: if you're in the RFCs, you don't have the
@@ -340,7 +330,6 @@ Scale:
       content you can showcase about the project?
 
 - **Case studies/social proof**: None available.
-
   - Case studies/talks/generally showing that other projects use Tremor is one
     of the most powerful ways to gain new users. People love real-world examples
     of a codebase in action.

diff --git a/analyses/0005-fluxcd.md b/analyses/0005-fluxcd.md
@@ -89,7 +89,6 @@ Scale:
   high-level concepts better before beginning code: providing a bit more
   explanation up front, particularly around the object's required fields and
   what the expected values are. An example would be helpful for this audience.
-
   - Items under the **Project** top level navigation section. At a glance I
     couldn't figure out how these were being pulled in via (I assume) the
     [Community repository](https://github.com/fluxcd/community), meaning they

diff --git a/analyses/0006-gateway-api.md b/analyses/0006-gateway-api.md
@@ -92,7 +92,6 @@ as well as where to find them.
 - The main task with information architecture is conceptualization and
   development as the documents are currently in different places. The following
   areas would establish a foundation:
-
   - Introduction
   - Quick Start
   - Concepts
@@ -270,7 +269,6 @@ The [website](https://gateway-api.sigs.k8s.io/) is accessible via HTTPS.
   [Copyright notices](https://github.com/cncf/foundation/blob/master/copyright-notices.md).
 
 - CNCF Branding elements
-
   - “We are a Cloud Native Computing Foundation project.” or “We are a Cloud
     Native Computing Foundation sandbox project.” are present (depending on
     status)

diff --git a/analyses/0007-porter.md b/analyses/0007-porter.md
@@ -69,14 +69,12 @@ Scale:
 - There appear to be two different operator quick starts (or is it the
   difference between desired state and operator? maybe the operator one needs to
   be in Get Started)
-
   - https://getporter.org/quickstart/desired-state/
   - https://getporter.org/operator/quickstart/
 
 - Mixins & Plugins sections duplicated in sidebar (and could potentially be
   organized under Concepts?)
 - Current info architecture
-
   - root
     - Get started
     - Contribute

diff --git a/analyses/0008-backstage/backstage-analysis.md b/analyses/0008-backstage/backstage-analysis.md
@@ -118,11 +118,11 @@ such, and pertain to legal requirements such as copyright and licensing issues.
 
 | Criteria                   | 1   | 2   | 3   | 4   | 5   |
 | -------------------------- | --- | --- | --- | --- | --- |
-| Information architecture   |     | ✔︎ |     |     |     |
-| New user content           |     |     |     | ✔︎ |     |
-| Content maintainability    |     |     | ✔︎ |     |     |
-| Content creation processes |     |     | ✔︎ |     |     |
-| Inclusive language         |     |     |     | ✔︎ |     |
+| Information architecture   |     | ✔︎   |     |     |     |
+| New user content           |     |     |     | ✔︎   |     |
+| Content maintainability    |     |     | ✔︎   |     |     |
+| Content creation processes |     |     | ✔︎   |     |     |
+| Inclusive language         |     |     |     | ✔︎   |     |
 
 Scale:
 
@@ -352,10 +352,10 @@ these navigation aids are adequate.
 
 | Criteria                                  | 1   | 2   | 3   | 4   | 5   |
 | ----------------------------------------- | --- | --- | --- | --- | --- |
-| Communication methods documented          |     |     |     | ✔︎ |     |
-| Beginner friendly issue backlog           |     |     |     | ✔︎ |     |
-| “New contributor” getting started content |     |     | ✔︎ |     |     |
-| Project governance documentation          |     |     |     |     | ✔︎ |
+| Communication methods documented          |     |     |     | ✔︎   |     |
+| Beginner friendly issue backlog           |     |     |     | ✔︎   |     |
+| “New contributor” getting started content |     |     | ✔︎   |     |     |
+| Project governance documentation          |     |     |     |     | ✔︎   |
 
 Scale:
 
@@ -423,19 +423,19 @@ from the product documentation.
 
 | Criteria                                    | 1   | 2   | 3   | 4   | 5   |
 | ------------------------------------------- | --- | --- | --- | --- | --- |
-| Single source for all files                 |     |     | ✔︎ |     |     |
-| Meets min website req. (for maturity level) |     | ✔︎ |     |     |     |
-| Branding and design                         |     |     |     | ✔︎ |     |
-| Case studies/social proof                   |     |     | ✔︎ |     |     |
-| SEO, Analytics, and site-local search       |     |     |     |     | ✔︎ |
-| Maintenance planning                        |     |     | ✔︎ |     |     |
-| A11y plan & implementation                  |     |     |     | ✔︎ |     |
-| Mobile-first plan & impl.                   |     |     | ✔︎ |     |     |
-| HTTPS access & HTTP redirect                |     |     |     |     | ✔︎ |
-| Google Analytics 4 for production only      |     |     |     |     | ✔︎ |
-| Indexing allowed for production server only |     |     |     |     | ✔︎ |
-| Intra-site / local search                   |     |     |     |     | ✔︎ |
-| Account custodians are documented           | ✔︎ |     |     |     |     |
+| Single source for all files                 |     |     | ✔︎   |     |     |
+| Meets min website req. (for maturity level) |     | ✔︎   |     |     |     |
+| Branding and design                         |     |     |     | ✔︎   |     |
+| Case studies/social proof                   |     |     | ✔︎   |     |     |
+| SEO, Analytics, and site-local search       |     |     |     |     | ✔︎   |
+| Maintenance planning                        |     |     | ✔︎   |     |     |
+| A11y plan & implementation                  |     |     |     | ✔︎   |     |
+| Mobile-first plan & impl.                   |     |     | ✔︎   |     |     |
+| HTTPS access & HTTP redirect                |     |     |     |     | ✔︎   |
+| Google Analytics 4 for production only      |     |     |     |     | ✔︎   |
+| Indexing allowed for production server only |     |     |     |     | ✔︎   |
+| Intra-site / local search                   |     |     |     |     | ✔︎   |
+| Account custodians are documented           | ✔︎   |     |     |     |     |
 
 Scale:
 

diff --git a/analyses/0008-backstage/backstage-implementation.md b/analyses/0008-backstage/backstage-implementation.md
@@ -153,7 +153,6 @@ The following artifacts should be written and made findable for developers.
 
 1. A getting started guide for developers. Provide a clear work path that
    describes how to:
-
    1. Download and install any necessary software components
    1. Integrate Backstage with an existing development environment
 

diff --git a/analyses/0009-in-toto/in-toto-doc-issues.md b/analyses/0009-in-toto/in-toto-doc-issues.md
@@ -21,7 +21,6 @@ repurposed as the new overall **Doc home page**.
 
   This is a necessary step in raising the maturity level of this project. The
   roadmap should initially describe and provide access to:
-
   - Specification
   - Basic demo
   - Python reference implementation along with its reference docs (which need to
@@ -40,7 +39,6 @@ repurposed as the new overall **Doc home page**.
 - [ ] Move the content of the
       [README for the main repo](https://github.com/in-toto/in-toto) to a
       separate **"Getting Started" document**.
-
   - [ ] Add a prominent pointer to the new **"Getting Started" document** on the
         in-toto home page, such as the top menu item in the "Get Started" menu.
   - [ ] Replace the README with brief introductory notes that link to the

diff --git a/analyses/0009-in-toto/in-toto-implementation.md b/analyses/0009-in-toto/in-toto-implementation.md
@@ -88,7 +88,6 @@ following general plan.
 
    d. Expose parts of the product specification as separate named documents on
    the website, as:
-
    - [System Overview](https://github.com/in-toto/docs/blob/master/in-toto-spec.md#2-system-overview)
      (compare content to https://in-toto.io/in-toto and current website About -
      create versions of increasing depth to address to specific audiences)
@@ -159,7 +158,6 @@ following general plan.
 
    2.3 Move important sections out of the spec into separate documents, and add
    them to the Doc home-page TOC.
-
    - Evaluate the depth of the
      [System Overview](https://github.com/in-toto/docs/blob/master/in-toto-spec.md#2-system-overview)
      and decide which user population it is most suitable for, or adapt it to
@@ -229,7 +227,6 @@ following general plan.
 
    5.2 Publish the policy and procedures for developers to document their
    implementations.
-
    - Develop a documentation policy for implementers. For example, the
      auto-generated doc for the
      [Go implementation](https://pkg.go.dev/github.com/in-toto/in-toto-golang)
@@ -252,7 +249,6 @@ following general plan.
    the project doc repo.
 
    6.3 Make sure the policy pages include or link to:
-
    - Contact info for maintainer/reviewer for documentation contributions.
    - Available doc style guides/templates (as well as code standards)
    - Usage guidelines for RTD (or other doc tool) and any project-specific usage

diff --git a/analyses/0009-in-toto/survey-of-existing-doc.md b/analyses/0009-in-toto/survey-of-existing-doc.md
@@ -33,7 +33,6 @@ https://github.com/in-toto/attestation
   https://github.com/in-toto/demo
 
 - Doc generation repo: https://github.com/in-toto/docs
-
   - Generated (read-the-docs) for Python reference implementation
 
   - Installation https://in-toto.readthedocs.io/en/latest/installing.html