[Marius Storhaug (MariusStorhaug)]

Feature contributors can describe what they need, why it matters, and the behavior they expect in a real situation without proposing an implementation. PSModule repositories using the inherited feature form keep the same template identity, title prefix, declared feature/triage labels, and single required response.

Changed: Feature requests start with consumer needs

The response is labeled Consumer need and expected behavior. Three prompts ask about the contributor's goal and who benefits, why the outcome matters, and what should happen in a real situation. Optional starters use ordinary language; no extra required fields, implementation plan, or literal Gherkin syntax is introduced. Maintainers still review feedback and choose the appropriate native issue type.

Adopting this release

No consumer-local edit is required. After merge, repositories using GitHub's inherited PSModule issue templates receive the organization-owned feature form. Repositories with local issue-template overrides are unchanged; this PR does not copy the form or the full standard into consumer repositories.

Release impact

Field	Value
Effective decision	Non-versioned community-default update under this repository's existing special GitHub role; not a Process-PSModule product release. No release resolver, release settings, or live labels are changed.
Semantic effect	Small compatible feature-intake improvement, framed as Patch; no module, action, or reusable-workflow release.
Release/base coordinates	No version is produced by this draft. The change baseline is f424237c98b5b020f80e8c9563dbc37256fc1ec0, and the immutable candidate head is a747f719e55056056ab4053e423643c031bf9028. No numeric publication coordinates are assigned.

---

Technical details

Consumer change record

Identifier / surface	Before	After	Applicability / prerequisites	Consumer action	Verification
FEATURE-EXPECTATIONS / inherited feature textarea	Description asks for an idea, implementation suggestions, and alternatives.	Consumer need and expected behavior asks for need/beneficiary, motivation, and expected behavior in a real situation; optional plain-language starters.	Contributors using an inherited PSModule feature form.	No local copy or configuration edit required.	All 10 consumer checks fail before the form edit and pass afterward.
FEATURE-ROUTING / feature feedback intake	One required description textarea, original template name/description/title, declared feature/triage labels, and no native type.	Those declarations, field identity, submission constraints, and blank-issue fallback are unchanged. Maintainer feedback routing is explicit.	GitHub uses labels that exist in each receiving repository; current hub metadata is noted below.	Continue submitting feedback; no internal Task/Epic/PBI is forced by the form.	All 13 original form-structure/routing checks remain green.
FEATURE-GUIDANCE / canonical pointers	No canonical issue/planning links in the feature introduction.	Links to the currently working MSX Issues and Issue Planning pages; no immutable snapshot or unlanded anchor is shipped.	Contributors and maintainers following the shared process.	Follow the linked canonical guidance when accepted feedback is refined.	Both current canonical pages resolve; frozen-source correspondence is verified separately.

Template baseline

The existing feature form and unchanged PR scaffold were inspected at immutable baseline PSModule/.github@f424237c98b5b020f80e8c9563dbc37256fc1ec0. The candidate source is a747f719e55056056ab4053e423643c031bf9028; its parsed GitHub form contract retains the existing identity and routing declarations. This repository is the organization-default source, not a Process-PSModule integration-template consumer, so no framework template upgrade applies. The repository PR scaffold itself is not changed.

Maintainer evidence

Only the organization-owned feature form and its focused Pester test change. The passing baseline checks were committed before opening the early draft. All 10 exact consumer checks were demonstrated red against the unchanged form before implementation; the passing final state was then pushed in three small logical commits. Internal PSModule/.github#88 remains a native Task with technical decisions and its test-first plan. GitHub's native closingIssuesReferences contains exactly that Task.

Exact command/check	Result
Invoke-Pester -Path .\tests\FeatureIntake.Tests.ps1 -Output Detailed -CI	Passed after implementation: 23 tests, 0 failed, 0 skipped, 0 not run. The initial baseline run passed 13 tests.
Invoke-Pester -Path .\tests\FeatureIntake.Tests.ps1 -Output Normal -CI before the form edit	Expected red, exit 10: 13 structure/routing tests passed and all 10 consumer tests failed. The form had no diff before that run.
Invoke-ScriptAnalyzer -Path .\tests\FeatureIntake.Tests.ps1 -Severity Error,Warning	Passed: 0 errors or warnings. The narrowly scoped unused-variable suppression documents Pester setup/test block scopes.
yamllint --strict .github\ISSUE_TEMPLATE\10-feature.yml	Passed, exit 0. Before editing, the same command reproduced a missing-document-start warning and the long-introduction error; the edited form's document marker and wrapped new prose resolve both without lint configuration changes.
git --no-pager diff f424237c98b5b020f80e8c9563dbc37256fc1ec0 HEAD --check	Passed. The full branch file set is asserted to be exactly the feature form and its focused test, not an empty diff or a broader rollout. The worktree is clean.
Current canonical page fetches: https://msx.no/docs/Ways-of-Working/Issues/ and https://msx.no/docs/Ways-of-Working/Issues/Process/Planning/	Both resolve to their current published content. No new consumer-expectations anchor is used in the shipped form.
gh pr edit 89 --repo PSModule/.github --add-reviewer '@copilot', followed by bounded reviews/comments polling for the exact head	Passed: Copilot approved a747f719e55056056ab4053e423643c031bf9028 at 2026-10-31T16:35:54Z, covered both changed files, left 0 inline comments, and reported no active review issues.
gh pr view 89 --repo PSModule/.github --json closingIssuesReferences	Verified: exactly PSModule/.github#88, with no aggregate or unrelated issue closed by this PR.

Frozen-source correspondence

The coordinator supplied the frozen handoff for MSXOrg/docs#228 and MSXOrg/docs#230 at 1c8f98cabe64b12aaa5fa9fb5f51b9d03f5de9de. Its relevant owning pages were read at that immutable source, rather than inferred from an old green check.

Requirement	Form/delivery evidence	Owning frozen source
Consumer need and motivation	First two prompts ask for the goal, beneficiary, and why the need matters.	Consumer expectations
Context, action/event, observable result without mandatory formal syntax	The real-situation prompt and When I ..., I expect ... starter invite an equally clear ordinary-language scenario. No architecture inventory or implementation checklist is solicited.	Consumer expectations
Preserve external feedback refinement and native routing	Maintainers review and route feedback. No native type is added, a feature label is not treated as containment, and every submission is not forced into Task/Epic/PBI.	Native routing
Preserve Task/Bug technical plans	This delivery uses a native Task with technical decisions and a test-first plan; Bug forms and delivery-plan guidance are untouched.	Task plans, Bug plans

These immutable links are review evidence only. The source PR is still unmerged, and the current canonical planning page does not yet contain the new guidance. Frozen correspondence is complete; source adoption on main is not claimed.

Standards and framework alignment

Changed surface	Standards checked	Framework/domain docs checked	Result
Feature issue form (YAML and consumer copy)	MSX YAML, Code Layout, Natural Language, Testing; Issues/Planning/native routing	GitHub issue forms and form schema	Fixed in this PR
Focused Pester test	MSX PowerShell Scripts/Testing, Naming, Error Handling, Documentation; Pester 6 major bound	None (no framework-specific module docs apply to this organization-default test)	Aligned

The existing README still correctly describes the repository's inherited-default role, and contribution guidance still points to the central process. The consumer documentation lives in the changed form, with the runnable check documented in the test's help; unrelated README/scaffold expansion remains outside this delivery.

Scoped convergence

The open-issue sweep was limited to the exact feature-form path. It returned this delivery Task and PSModule/.github#87. This diff improves strict lint for the edited feature form, but it does not satisfy that broader Task's all-form formatting or local/CI YAML enforcement. No additional issue is fully delivered; only this Task is closed by the PR.

Remaining readiness gates and out-of-scope observations

• After author review, the actual candidate head has one successful copilot-pull-request-reviewer check and 0 commit statuses; combined commit-status state is pending. The active strict main rule requires Community file validation, bound to integration 15368, and that required check is absent on this head (gh api repos/PSModule/.github/rules/branches/main). Copilot approval is not a substitute for that CI gate. PSModule/.github#84, PSModule/.github#85, and PSModule/.github#86 own the separate validation/governance work. This PR does not change their configuration or containment guards and does not use an old green result as proof of the correction.
• Live hub metadata is a separate, pre-existing routing gap: gh api repos/PSModule/.github/labels/feature returns 404, while gh api repos/PSModule/.github/labels/triage resolves the existing Triage label. The form's declared labels are preserved exactly; no live label is created, renamed, or changed. This observation is limited to this repository, not a fleet-wide claim.
• The source guidance PR remains unmerged. Shipped links deliberately use currently working canonical page routes; source landing/adoption must remain explicit before final readiness.
• The explicitly requested Copilot round is clean on the exact candidate head. The PR nevertheless remains draft and unmerged for human review because the external readiness gates above remain open. Auto-merge is not enabled.

Relevant issues (or links)

• Resolves PSModule/.github#88

Related work

• References MSXOrg/docs#228
• References MSXOrg/docs#230
• References PSModule/.github#87
• References PSModule/.github#84
• References PSModule/.github#85
• References PSModule/.github#86

[Copilot]

🟢 Approved

No active review issues remain for the feature-request form update.

No open issues 🎉

What changed in this PR

Updates the organization’s inherited feature-request form so contributors describe their needs, motivation, and expected behavior without proposing an implementation. Existing template identity, routing labels, and the single required response remain unchanged.

Changes:

• Replaces implementation-oriented prompts with consumer-focused questions and optional plain-language starters.
• Clarifies maintainer routing and links canonical MSX issue and planning guidance.
• Adds 23 focused Pester checks covering form structure, preserved routing, and consumer-facing prompts.

File	Description
tests/​FeatureIntake.Tests.ps1	Adds regression checks for the feature form’s structure, routing, and consumer expectations.
.github/​ISSUE_TEMPLATE/​10-feature.yml	Updates feature-request guidance and prompts while preserving submission requirements.

_{Review effort: Balanced}