From 93b95eb6935d43c3e350bcdd293e19c128dc7aa3 Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 14:46:08 +0100 Subject: [PATCH 1/5] Describe the framework workflow directly --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c2d2257e..924672d7 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Process-PSModule -Process-PSModule is the corner-stone of the PSModule framework — an end-to-end GitHub Actions workflow that builds, tests, versions, documents, and publishes PowerShell modules to the PowerShell Gallery. +Process-PSModule is the core workflow of the PSModule framework. This end-to-end GitHub Actions workflow builds, tests, versions, documents, and publishes PowerShell modules to the PowerShell Gallery. Documentation site generation is powered by Zensical. Repositories define site configuration in `zensical.toml`. From 05d24e1364630636b64e28eceb745ea54b2602bf Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 14:47:19 +0100 Subject: [PATCH 2/5] Describe framework automation and guidance directly --- docs/content/index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/content/index.md b/docs/content/index.md index 02cc155f..03a57bba 100644 --- a/docs/content/index.md +++ b/docs/content/index.md @@ -15,7 +15,7 @@ default-branch push is the sole authority for a stable release. When that push i request, its labels and release notes supply the release metadata. See the [scenario matrix](reference/scenario-matrix.md) for the resulting job execution. -Everything is packaged into a single reusable workflow so that a module repository only needs a small caller workflow and one settings file. A user configures the behaviour by editing `.github/PSModule.yml`. +Everything is packaged into a single reusable workflow so that a module repository only needs a small caller workflow and one settings file. A user configures the behavior by editing `.github/PSModule.yml`. ![Process diagram](media/Process-PSModule.png) @@ -77,16 +77,16 @@ The requirements and architecture behind the pipeline. Primarily for those maint ## A GitHub & PowerShell development framework -PSModule **infuses GitHub with PowerShell** and brings more to the PowerShell ecosystem by using the GitHub platform to its fullest extent. -The framework is two things in one: a collection of reusable PowerShell modules, and a set of GitHub Actions workflows that automate the full PowerShell module (software) delivery lifecycle — the DevOps functionality that the ecosystem is missing. +The PSModule framework has reusable PowerShell modules and GitHub Actions workflows. +The workflows automate the PowerShell module delivery lifecycle. -We empower PowerShell-savvy developers to effortlessly transform their ideas into impactful solutions, automating the repetitive tasks so developers — whether consumers or contributors — can concentrate on coding without distractions. +The framework automates repeated tasks so developers can write code for their PowerShell solutions. This applies to both consumers and contributors. -Where we are headed is tracked as [objectives and initiatives](https://msx.no/docs/Ways-of-Working/Goal-Setting/). +See [objectives and initiatives](https://msx.no/docs/Ways-of-Working/Goal-Setting/) for the goal-setting model. ## Cross-org guidance -Cross-org standards and reusable solution documentation are now canonical in [MSXOrg/docs](https://msx.no/docs/): +Cross-org standards and reusable solution documentation are canonical in [MSXOrg/docs](https://msx.no/docs/): - [Coding Standards](https://msx.no/docs/Coding-Standards/) - [Capabilities](https://msx.no/docs/Capabilities/) From a363f39a289d6116086b5f6d78d8d997bbf629ea Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 14:47:59 +0100 Subject: [PATCH 3/5] State the coverage example requirement in present tense --- docs/content/guides/configuring-the-pipeline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/guides/configuring-the-pipeline.md b/docs/content/guides/configuring-the-pipeline.md index b77d4cdf..af88f5d5 100644 --- a/docs/content/guides/configuring-the-pipeline.md +++ b/docs/content/guides/configuring-the-pipeline.md @@ -14,7 +14,7 @@ This page shows the common changes. For the complete list of settings and their ## Example 1 - Defaults with Code Coverage target -This example runs all steps and will require that code coverage is 80% before passing. +This example runs all steps and requires 80% code coverage to pass. ```yaml Test: From 13e93f1df5a7503d90926ef33a395e455e0417c9 Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 14:48:45 +0100 Subject: [PATCH 4/5] Use en-US spelling in release descriptions --- docs/content/guides/versioning-and-releases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/content/guides/versioning-and-releases.md b/docs/content/guides/versioning-and-releases.md index fe226002..7694d507 100644 --- a/docs/content/guides/versioning-and-releases.md +++ b/docs/content/guides/versioning-and-releases.md @@ -19,7 +19,7 @@ the configured default branch. Test and lint stages run before the publish gates, and publish is blocked when required checks fail. -An open labelled pull request can publish a prerelease. A closed pull request only cleans up its prereleases. When a +An open labeled pull request can publish a prerelease. A closed pull request only cleans up its prereleases. When a pull request merges, the resulting push to the default branch resolves that pull request's labels and creates the stable release from the exact pushed commit. @@ -55,7 +55,7 @@ short-lived pull requests targeting `main`. ## Prereleases -A pull request labelled `Prerelease` publishes a prerelease version (for example `v1.2.3-pr.1.5`) that is installable +A pull request labeled `Prerelease` publishes a prerelease version (for example `v1.2.3-pr.1.5`) that is installable but not promoted as latest. When that pull request is merged with a version label, the stable version is computed from the label and the current version on `main`. From 79bac09b581e80b27bae5dad5d87adffac0ff219 Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 14:54:59 +0100 Subject: [PATCH 5/5] Clarify the coverage example minimum --- docs/content/guides/configuring-the-pipeline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/guides/configuring-the-pipeline.md b/docs/content/guides/configuring-the-pipeline.md index af88f5d5..ae643ebc 100644 --- a/docs/content/guides/configuring-the-pipeline.md +++ b/docs/content/guides/configuring-the-pipeline.md @@ -14,7 +14,7 @@ This page shows the common changes. For the complete list of settings and their ## Example 1 - Defaults with Code Coverage target -This example runs all steps and requires 80% code coverage to pass. +This example runs all steps and requires at least 80% code coverage to pass. ```yaml Test: