diff --git a/.cspell.json b/.cspell.json index 9c2501fa5..de85e6180 100644 --- a/.cspell.json +++ b/.cspell.json @@ -77,7 +77,14 @@ "whiteboarding", "ˈpræksɪs", "πρᾶξις", - "agentic" + "agentic", + "chaosdinosaur", + "katriendg", + "agreaves", + "bindsi", + "rezatno", + "Msirh", + "Risner" ], "reporters": [ "default", diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 50dc9d082..6ecc14beb 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -10,8 +10,10 @@ # Default owner for all files (fallback) * @microsoft/edge-ai-core-dev -# Self-protection: CODEOWNERS file changes require core team approval +# Self-protection: governance files require core team approval /.github/CODEOWNERS @microsoft/edge-ai-core-dev +/GOVERNANCE.md @microsoft/edge-ai-core-dev +/.github/MAINTAINERS.md @microsoft/edge-ai-core-dev # GitHub configuration (workflows, templates, instructions) /.github/ @microsoft/edge-ai-core-dev @@ -24,3 +26,43 @@ # Documentation /docs/ @microsoft/edge-ai-core-dev + +# --------------------------------------------------------------------------- +# SIG-scoped ownership (commented stubs) +# +# The following per-SIG entries are commented out until GitHub Teams +# `@microsoft/hve-core-sig-` are provisioned. Uncomment one entry per SIG +# when its team exists; see `docs/community/sigs//CHARTER.md`. +# --------------------------------------------------------------------------- + +# Engineering — build, scripts, packaging, CI, intake/triage +# /scripts/ @microsoft/hve-core-sig-engineering +# /extension/ @microsoft/hve-core-sig-engineering +# /.github/workflows/ @microsoft/hve-core-sig-engineering +# /.github/instructions/ado/ @microsoft/hve-core-sig-engineering +# /.github/instructions/github/ @microsoft/hve-core-sig-engineering +# /.github/instructions/jira/ @microsoft/hve-core-sig-engineering +# +# Emerging AI — experimental incubation surface +# /.github/agents/experimental/ @microsoft/hve-core-sig-emerging-ai +# /.github/skills/experimental/ @microsoft/hve-core-sig-emerging-ai +# /collections/experimental.collection.* @microsoft/hve-core-sig-emerging-ai +# +# Standards — coding standards, prompt-builder, doc IA +# /.github/instructions/coding-standards/ @microsoft/hve-core-sig-standards +# /.github/instructions/hve-core/ @microsoft/hve-core-sig-standards +# /docs/contributing/ @microsoft/hve-core-sig-standards +# /docs/templates/ @microsoft/hve-core-sig-standards +# +# Security — review, threat modeling, supply chain, CI hardening +# (overrides Engineering for security-scoped paths via later-match-wins) +# /.github/instructions/security/ @microsoft/hve-core-sig-security +# /.github/skills/security/ @microsoft/hve-core-sig-security +# /scripts/security/ @microsoft/hve-core-sig-security +# /scripts/linting/ @microsoft/hve-core-sig-security +# +# RAI — responsible AI planning +# /.github/instructions/rai-planning/ @microsoft/hve-core-sig-rai +# +# Data Science — DS collection and DS-scoped artifacts +# /collections/data-science.collection.* @microsoft/hve-core-sig-data-science diff --git a/.github/MAINTAINERS.md b/.github/MAINTAINERS.md new file mode 100644 index 000000000..9c369f009 --- /dev/null +++ b/.github/MAINTAINERS.md @@ -0,0 +1,20 @@ +--- +title: Maintainers +description: Current maintainers of microsoft/hve-core including pro tem assignments +--- + +This file is the canonical roster of `microsoft/hve-core` maintainers. The Maintainer Continuity and Quorum rules in [GOVERNANCE.md](../GOVERNANCE.md) govern additions, leaves of absence, and pro tem assignments. + +| Name | Handle | Role | Notes | +|-------------------|------------------|---------------------|-------------------------------------------------| +| Bill Berry | @WilliamBerryiii | Maintainer | Project lead | +| Katrien De Graeve | @katriendg | Project lead | | +| Allen Greaves | @agreaves-ms | Project lead (on LOA) | Seat backfilled pro tem | +| Chris Risner | @ChrisRisner | Maintainer | Standards & Practices lead | +| Emmeline Hoops | @chaosdinosaur | Maintainer Pro Tem | Promoted 2026-04-25; backfills @agreaves-ms LOA | + +Last updated: 2026-04-25. + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers. diff --git a/GOVERNANCE.md b/GOVERNANCE.md index e1294076d..eb774999e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -2,7 +2,7 @@ title: Governance description: Project governance model, roles, decision-making processes, and contribution authority for HVE Core author: HVE Core Team -ms.date: 2026-02-07 +ms.date: 2026-04-25 ms.topic: reference keywords: - governance @@ -10,7 +10,7 @@ keywords: - roles - maintainers - contributors -estimated_reading_time: 5 +estimated_reading_time: 8 --- HVE Core uses a liberal contribution model where active contributors are recognized for current work. Microsoft maintains stewardship of the project while welcoming community contributions and leadership. @@ -28,14 +28,14 @@ This project operates under a corporate-sponsored maintainer model: The following matrix summarizes capabilities by role: -| Capability | Maintainer | Triage | Contributor | -|:-----------------------|:----------:|:------:|:-----------:| -| Code review | ✅ | ✅ | ✅ | -| Merge pull requests | ✅ | ❌ | ❌ | -| Release management | ✅ | ❌ | ❌ | -| Architecture decisions | ✅ | Advise | Propose | -| Issue triage | ✅ | ✅ | ❌ | -| Label management | ✅ | ✅ | ❌ | +| Capability | Maintainer | SIG Chair | Triage | Contributor | +|:-----------------------|:----------:|:---------:|:------:|:-----------:| +| Code review | ✅ | Advise | ✅ | ✅ | +| Merge pull requests | ✅ | Advise | ❌ | ❌ | +| Release management | ✅ | ❌ | ❌ | ❌ | +| Architecture decisions | ✅ | Advise | Advise | Propose | +| Issue triage | ✅ | Advise | ✅ | ❌ | +| Label management | ✅ | ❌ | ✅ | ❌ | ### Maintainers @@ -48,7 +48,34 @@ Maintainers guide project direction, manage releases, and resolve conflicts. | Community health | Enforce code of conduct and foster inclusive participation | | Access management | Grant and revoke repository permissions | -Current maintainers are members of the [@microsoft/edge-ai-core-dev](https://github.com/orgs/microsoft/teams/edge-ai-core-dev) team. +The current maintainer roster is published in [.github/MAINTAINERS.md](.github/MAINTAINERS.md). Membership in the [@microsoft/edge-ai-core-dev](https://github.com/orgs/microsoft/teams/edge-ai-core-dev) team backs repository permissions. + +#### Maintainer Continuity and Quorum + +The active maintainer roster maintains a minimum of three members. Maintainer status is +earned through sustained contribution and is added as the bar described in Role +Progression is met; there is no upper cap on the number of maintainers. + +If a maintainer takes a Leave of Absence (LOA), is otherwise unable to serve, or the +active roster would drop below three, the remaining maintainers vote under the +Governance-tier decision rules (consensus + one-week comment window) to promote a +contributor to **Maintainer Pro Tem**. + +A Maintainer Pro Tem holds full maintainer authority and serves until the earlier of: + +1. Three months elapsed since promotion, or +2. The LOA maintainer returning to active service. + +At the end of the pro tem term, the pro tem either steps down, is reaffirmed as a +permanent maintainer under the standard Role Progression rules if their contribution +record qualifies, or, by re-vote of the remaining maintainers, has the pro tem term +extended for one additional three-month period if the original LOA continues. + +Reaffirmation requires an explicit vote of the remaining maintainers under +Governance-tier rules. The vote process and discussion are conducted privately; the +**outcome** (promotion confirmed, pro tem ended, or term extended) is announced +publicly in the `Maintainers` GitHub Discussions category and reflected in +`MAINTAINERS.md`. ### Triage Contributors @@ -71,6 +98,47 @@ Contributors improve the project through code, documentation, and community enga | Issue reporting | Report bugs with reproduction steps and suggest enhancements | | Community participation | Engage in discussions and help other users | +## Special Interest Groups + +A Special Interest Group (SIG) is an artifact-owning team that takes responsibility for a defined surface of the repository (directories, collections, and instructional content). Each SIG operates under a charter and is attached to [.github/CODEOWNERS](.github/CODEOWNERS) once its GitHub Team is provisioned. + +| SIG | Owned Surface | +|:--------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------| +| [SIG Engineering](docs/community/sigs/sig-engineering/CHARTER.md) | Build, scripts, packaging, plugin generation, CI workflows, and backlog/intake/triage instruction surface. | +| [SIG Standards](docs/community/sigs/sig-standards/CHARTER.md) | Coding standards, prompt-builder standards, agent/prompt/instruction information architecture, and documentation style. | +| [SIG Security](docs/community/sigs/sig-security/CHARTER.md) | Security review, threat modeling, OWASP skills, supply-chain security, CI hardening, dependency pinning, and scorecards. | +| [SIG RAI](docs/community/sigs/sig-rai/CHARTER.md) | Responsible AI planning artifacts and review rubric. | +| [SIG Data Science](docs/community/sigs/sig-data-science/CHARTER.md) | Data Science collection, notebook and Python skill conventions, and data-handling guidance. | +| [SIG Emerging AI](docs/community/sigs/sig-emerging-ai/CHARTER.md) | Experimental agents, prompts, skills, and collections (incubation surface that promotes proven patterns to receiving SIG). | + +Full charters live under [docs/community/sigs/](docs/community/sigs/README.md). + +### Chair Recruitment + +SIG chairs are recruited in two phases. Phase 0 seeds chairs internally from the active maintainer pool to bootstrap each SIG. Phase 1 opens a public call inviting non-maintainer contributors who have demonstrated sustained contribution to the owned surface. + +Eligibility: + +* Candidate is not a current maintainer. +* Candidate has demonstrated prior contribution to the SIG's owned surface (code, review, documentation, or triage). +* Candidate declares any conflicts of interest in the charter pull request. + +Terms and onboarding: + +* Chair term: 12 months, renewable once for a maximum of 24 consecutive months. +* 6-month cooldown before a former chair may be re-nominated for the same SIG. +* Onboarding: (1) charter PR opened, (2) COI declaration recorded, (3) chair listed in `MAINTAINERS.md` and the SIG charter, (4) repository team membership granted, (5) public announcement in the `Maintainers` GitHub Discussions category. + +Removal: + +* Voluntary step-down at any time. +* Inactivity removal after 90 days of no SIG activity. +* For-cause removal by Governance-tier vote of the remaining maintainers. + +### Working Groups (Deferred) + +Working Groups (WGs) may be added through a future amendment to this document. The structural charter template, sponsoring-SIG mechanic, and chair-eligibility rules will mirror those defined for SIGs above. + ## Decision-Making Process Decisions follow a tiered model based on impact and reversibility. @@ -106,6 +174,20 @@ Modifications to this governance document or project policies: * Require consensus among active maintainers * Allow one-week comment period for community input +### Public Activity + +All SIG activity (design proposals, decision logs, scope debates, and routine +deliberation) SHALL occur in public channels (GitHub Discussions, public issues, +public PRs) wherever possible. Private deliberation is permitted only for: + +1. Security disclosures handled under `SECURITY.md`, +2. Personnel matters (e.g., maintainer pro tem and reaffirmation votes), and +3. Pre-publication coordination with Microsoft stewardship. + +For private deliberations, the resulting **decision** is published in the appropriate +public channel (Discussions category, `MAINTAINERS.md`, or `GOVERNANCE.md` amendment) +even when the deliberation itself remains private. + ## Role Progression Contributors advance through demonstrated commitment and quality work. diff --git a/docs/community/sigs/README.md b/docs/community/sigs/README.md new file mode 100644 index 000000000..c7f14ad4a --- /dev/null +++ b/docs/community/sigs/README.md @@ -0,0 +1,28 @@ +--- +title: Special Interest Groups +description: Index of artifact-owning SIGs in microsoft/hve-core with links to each charter +ms.topic: overview +ms.date: 2026-04-25 +author: HVE Core Maintainers +--- + +A Special Interest Group (SIG) is an artifact-owning team in microsoft/hve-core that takes responsibility for a defined surface of the repository (directories, collections, and instructional content). Each SIG operates under a charter, will be attached to [.github/CODEOWNERS](https://github.com/microsoft/hve-core/blob/main/.github/CODEOWNERS) once its GitHub Team is provisioned, and is led by chairs recruited under the Chair Recruitment Plan defined in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## SIGs + +| SIG | Owned Surface | Charter | +|-------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|----------------------------------------| +| [SIG Engineering](sig-engineering/CHARTER.md) | Build, scripts, packaging, plugin generation, CI workflows, and backlog/intake/triage instruction surface. | [Charter](sig-engineering/CHARTER.md) | +| [SIG Standards](sig-standards/CHARTER.md) | Coding standards, prompt-builder standards, agent/prompt/instruction information architecture, and documentation style. | [Charter](sig-standards/CHARTER.md) | +| [SIG Security](sig-security/CHARTER.md) | Security review, threat modeling, OWASP skills, supply-chain security, CI hardening, dependency pinning, and scorecards. | [Charter](sig-security/CHARTER.md) | +| [SIG RAI](sig-rai/CHARTER.md) | Responsible AI planning artifacts and review rubric. | [Charter](sig-rai/CHARTER.md) | +| [SIG Data Science](sig-data-science/CHARTER.md) | Data Science collection, notebook and Python skill conventions, and data-handling guidance. | [Charter](sig-data-science/CHARTER.md) | +| [SIG Emerging AI](sig-emerging-ai/CHARTER.md) | Experimental agents, prompts, skills, and collections (incubation surface that promotes proven patterns to the receiving SIG). | [Charter](sig-emerging-ai/CHARTER.md) | + +## Working Groups + +Working Groups (WGs) are deferred. A future amendment will introduce WGs; see the forward-reference in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers. diff --git a/docs/community/sigs/sig-data-science/CHARTER.md b/docs/community/sigs/sig-data-science/CHARTER.md new file mode 100644 index 000000000..ad6e7e534 --- /dev/null +++ b/docs/community/sigs/sig-data-science/CHARTER.md @@ -0,0 +1,156 @@ +--- +title: SIG Data Science +description: Charter for the data-science Special Interest Group in microsoft/hve-core +ms.topic: reference +ms.date: 2026-04-25 +author: HVE Core Maintainers +--- + +**Status:** Proposed +**Created:** 2026-04-25 +**Last Reviewed:** 2026-04-25 +**Next Review:** 2027-04-25 + +## Mission + +SIG Data Science owns the Data Science collection, notebook conventions, Python data-work standards, and dataset-handling guidance for microsoft/hve-core. The SIG ensures notebook-bearing and data-bearing artifacts shipped from this repository are reproducible, evaluable, and maintainable across releases. + +## Vision + +A repository where notebook and Python data artifacts are authored to a consistent, reproducible standard; where dataset handling, evaluation, and MLOps lifecycle expectations are documented and easy to follow; and where downstream consumers of the Data Science collection can rerun, audit, and extend the work without bespoke onboarding. + +## Goals (Current Cycle) + +1. Curate the Data Science collection (`collections/data-science.collection.*`) and ensure its membership remains accurate, scoped, and validated. +2. Publish notebook reproducibility conventions covering environment pinning, deterministic seeds, kernel selection, and output stripping. +3. Publish Python data-work conventions consistent with `python-foundational` and `uv-projects` instructions. +4. Document dataset-handling guidance: provenance, licensing, sensitivity classification, and storage location norms. +5. Define evaluation-harness expectations for data-driven artifacts, including reporting structure and reproducibility floor. + +## Reproducibility Floor + +Notebook and Python artifacts owned by the SIG meet a documented reproducibility floor: pinned environments, deterministic seeds where applicable, declared input data shape and location, declared kernel and runtime, and stripped or redacted outputs in committed notebooks unless preserved deliberately. + +## Deliverables + +Owned surfaces (durable artifacts under stewardship): + +* Curated Data Science collection manifests. +* Notebook authoring and review conventions. +* Python data-work conventions and lint configuration tied to `lint:py`. +* Dataset-handling guidance document. +* Evaluation-harness expectations and example artifacts. +* MLOps lifecycle guidance covering training, evaluation, packaging, and handoff. + +Recurring artifact types produced by the SIG: + +* Feature requests and data-science RFCs covering notebook, Python, dataset, and evaluation surfaces. +* Dataset specifications documenting provenance, licensing, sensitivity classification, and storage location. +* Reproducibility audits scoring notebook and Python artifacts against the reproducibility floor. +* MLOps lifecycle gap analyses identifying missing training, evaluation, packaging, or handoff coverage. +* Evaluation-set drift reports comparing current eval results against the prior baseline. +* Notebook quality reviews summarizing convention conformance and reproducibility findings. +* Synthetic-data and data-handling risk briefs prepared in coordination with SIG Security and SIG RAI. +* Quarterly model card and dataset card roll-up across the Data Science collection. +* Annual collection health report covering currency, reproducibility, and accepted graduations from SIG Emerging AI. + +## In Scope + +* Data Science collection (`collections/data-science.collection.*`) curation and lifecycle. +* Data-Science-scoped agents, instructions, and skills. +* Notebook authoring conventions (Jupyter, Quarto) and reproducibility expectations. +* Python skill conventions for data work, including environment management and dataset handling guidance. +* Evaluation harness conventions and reporting structure for data-driven artifacts. +* MLOps lifecycle guidance for data-driven artifacts owned by the SIG. + +## Out of Scope + +* General Python coding standards (owned by SIG Standards). +* Responsible AI rubrics applied to data work (owned by SIG RAI; SIG Data Science consults). +* Experimental data-science prototypes (owned by SIG Emerging AI until promoted). +* Build and CI tooling (owned by SIG Engineering; SIG Data Science consults on data-specific validators). + +## Stakeholders + +* Authors of notebooks, Python data artifacts, and data-related skills. +* Reviewers within the SIG who validate reproducibility and conventions. +* Consumers of the Data Science collection who rerun or extend the work. +* SIG Emerging AI as the upstream source of incubating data-science work. +* SIG RAI as a consultant on fairness and evaluation methodology. + +## Cross-SIG Dependencies + +* **SIG Standards** owns the `python-foundational` and `uv-projects` instructions; SIG Data Science extends these with data-specific conventions and defers to Standards on style. +* **SIG Engineering** owns CI; SIG Data Science requests notebook and Python validators be wired into `lint:py`, `validate:skills`, and related scripts. +* **SIG RAI** consults on fairness, evaluation methodology, and principle alignment for data-driven artifacts. +* **SIG Emerging AI** hands off graduating data-science artifacts; SIG Data Science accepts handoffs that meet the reproducibility floor. +* **SIG Security** consults on data-sensitivity classification and handling. + +## Roles and Responsibilities + +* **Chairs (1-3):** TBD (external recruit; per the Chair Recruitment Plan, no microsoft/hve-core maintainer may chair). Chairs prioritize the Data Science backlog, run cadence, and represent the SIG in cross-SIG escalations. +* **Tech Leads (1-3):** TBD. Tech leads own architectural direction for notebook and Python conventions, evaluation-harness expectations, and dataset-handling guidance; they mentor reviewers. +* **Reviewers:** TBD. Reviewers validate notebook and Python artifacts against conventions and the reproducibility floor. +* **Members:** TBD. Members contribute PRs, propose convention updates, triage issues, and participate in discussions. + +## Subprojects and Owned Directories + +* `collections/data-science.collection.*` +* Data-Science-scoped artifacts as introduced under `.github/agents/data-science/`, `.github/instructions/data-science/`, and `.github/skills/data-science/`. + + + +## Membership and Onboarding + +Joining is open to any contributor in good standing under the [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Prospective members introduce themselves in the SIG: Data Science discussion category and indicate the area of focus (collection curation, notebook conventions, Python conventions, datasets, or evaluation). Reviewer and approver privileges accrue through demonstrated contribution as described in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +New-contributor starting points: + +* Run `npm run lint:py` and `npm run validate:skills` and propose a small fix or convention extension. +* Audit one notebook in the Data Science collection against the reproducibility floor and file an issue. +* Pair with a tech lead on a review of a recent PR to learn the conventions. + +## Cadence + +* **Async:** GitHub Discussions category SIG: Data Science for proposals, convention updates, and reviews. +* **Reviews:** PRs touching owned directories receive review acknowledgment within five business days. +* **Optional sync:** Frequency, time zone, and meeting link TBD by the inaugural chair on ratification; meetings are recorded or summarized publicly per the Public Activity rule. + +## Decision-Making + +* **Lazy consensus** on routine convention and collection updates: 72-hour open window without objection. +* **Chair tie-break** when reviewers disagree within seven days. +* **Escalation** to the maintainer set for charter-affecting changes or cross-SIG conflicts. +* All deliberation occurs in public channels per the Public Activity rule in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Escalation Path + +1. Open a discussion in SIG: Data Science and tag chairs. +2. Chairs triage within five business days. +3. If unresolved, chairs file a decision request to the maintainer set per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Health and Success Metrics + +* Currency of the Data Science collection manifests against the artifacts they reference. +* Notebook and Python artifacts meeting the reproducibility floor on first review. +* Median age of open SIG Data Science PRs. +* Quarterly review cadence completion. +* Number of artifacts graduated from SIG Emerging AI and accepted into the collection. + +## Lifecycle and Review + +The SIG conducts an annual self-review on or before **Next Review** above. The review reaffirms scope, refreshes goals, updates membership, and either renews or proposes retirement. Retirement requires a maintainer vote per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md) and reassignment of all owned directories. + +## Amendment Process + +Charter amendments are proposed via pull request. Material changes (scope, role definitions, owned directories) require a 7-day comment window and chair approval; non-material changes follow lazy consensus. + +## Code of Conduct + +All participants follow the Microsoft Open Source [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers. diff --git a/docs/community/sigs/sig-emerging-ai/CHARTER.md b/docs/community/sigs/sig-emerging-ai/CHARTER.md new file mode 100644 index 000000000..dcc768141 --- /dev/null +++ b/docs/community/sigs/sig-emerging-ai/CHARTER.md @@ -0,0 +1,193 @@ +--- +title: SIG Emerging AI +description: Charter for the emerging-AI Special Interest Group in microsoft/hve-core +ms.topic: reference +ms.date: 2026-04-25 +author: HVE Core Maintainers +--- + +**Status:** Proposed +**Created:** 2026-04-25 +**Last Reviewed:** 2026-04-25 +**Next Review:** 2027-04-25 + +## Mission + +SIG Emerging AI runs the incubation surface for microsoft/hve-core. The SIG hosts experimental agents, prompts, skills, and the experimental collection, manages a defined incubation lifecycle, and promotes proven artifacts to the receiving SIG that owns the relevant durable surface. + +## Vision + +A transparent, time-boxed incubator where new agentic patterns are explored without polluting durable surfaces, where promotion criteria are explicit and consistently applied, and where graduating artifacts arrive at receiving SIGs with the metadata, tests, and review evidence required for production adoption. + +## Goals (Current Cycle) + +1. Document the incubation lifecycle stages, entry criteria, and exit criteria for experimental artifacts. +2. Publish promotion criteria covering reproducibility, RAI principle alignment, security review, and standards conformance. +3. Curate the experimental collection (`collections/experimental.collection.*`) and ensure each entry has an owner and a review window. +4. Define a deprecation policy for experimental artifacts that fail to graduate within the review window. +5. Establish a handoff matrix mapping graduating artifact types to receiving SIGs. + +## Incubation Lifecycle + +Experimental artifacts move through four stages: + +1. **Proposal:** authored as a discussion or draft PR; captured in the experimental collection with an owner and a 6-month default review window. +2. **Incubating:** merged under `.github/{agents,prompts,skills}/experimental/` or in `collections/experimental.collection.*`; iterated openly; eligible for breaking changes without notice. +3. **Graduating:** entry criteria for the receiving SIG are met; SIG Emerging AI files a promotion proposal that the receiving SIG reviews against its own conventions. +4. **Promoted or Archived:** on acceptance, the receiving SIG takes ownership and the artifact moves out of `experimental/`; on rejection or review-window lapse, the artifact is archived per the deprecation policy. + +## Promotion Criteria + +A graduating artifact provides: + +* **Reproducibility:** documented dependencies, deterministic behavior where applicable, and a working invocation example. +* **RAI alignment:** documented evaluation against the SIG RAI rubric for the principles relevant to the artifact (consult SIG RAI). +* **Security review:** dependency, secret-handling, and supply-chain review acknowledgment from SIG Security. +* **Standards conformance:** frontmatter, instructions, and authoring conventions per SIG Standards (`prompt-builder`, `markdown`, `writing-style`). +* **Receiving-SIG acceptance:** explicit acknowledgment from the receiving SIG that the artifact meets that SIG's conventions and is ready for ownership transfer. + +## Time-Boxed Experiments + +Each incubating artifact has a default 6-month review window recorded in the experimental collection manifest. At the window boundary, SIG Emerging AI: + +* Promotes the artifact (graduating path), or +* Renews the window with documented rationale, or +* Archives the artifact per the deprecation policy. + +## Deprecation Policy + +Artifacts that lapse without renewal or promotion are removed from the experimental collection, moved to a documented archived state, and listed in the SIG's annual review. Archived artifacts may be revived through a fresh proposal. + +## Handoff Matrix + +| Graduating Artifact Type | Receiving SIG | +|--------------------------------------|------------------| +| Notebook, Python data, dataset guide | SIG Data Science | +| RAI rubric or evaluation instruction | SIG RAI | +| Security skill or instruction | SIG Security | +| Authoring convention or template | SIG Standards | +| CI, packaging, release tooling | SIG Engineering | + +A receiving SIG may decline a handoff with documented rationale; the declined artifact returns to incubation or proceeds to archive. + +## Deliverables + +Owned surfaces (durable artifacts under stewardship): + +* Documented incubation lifecycle, promotion criteria, and deprecation policy. +* Curated experimental collection manifests with per-entry owners and review windows. +* Handoff matrix and promotion proposal template. + +Recurring artifact types produced by the SIG: + +* Feature requests and incubation RFCs for new experimental patterns, agents, prompts, or skills. +* Per-entry stage-gate review reports issued at proposal, mid-window, and review-window boundaries. +* Technology-radar and trend reports surveying emerging agentic patterns the SIG is tracking. +* Feasibility spike write-ups documenting scope, learnings, and graduate-or-archive recommendation. +* Promotion proposals delivered to receiving SIGs with the full promotion-criteria evidence package. +* Deprecation and sunset notices for artifacts that lapse without renewal or promotion. +* Quarterly experimental collection audit summarizing stage distribution and ownership freshness. +* Semi-annual incubation portfolio review covering throughput, acceptance rate, and policy adjustments. +* Annual archive and graduation report. + +## In Scope + +* Experimental agents under `.github/agents/experimental/`. +* Experimental skills under `.github/skills/experimental/`. +* Experimental prompts under `.github/prompts/experimental/` (where present). +* Experimental collection (`collections/experimental.collection.*`) curation. +* Promotion pathway: graduating proven experimental artifacts to the receiving SIG (Engineering, Standards, Security, RAI, Data Science). + +## Out of Scope + +* Durable, production-tier agents, prompts, and skills (owned by the receiving SIG after promotion). +* Build and CI for experimental artifacts beyond what is needed for incubation (handed off to SIG Engineering on promotion). +* Security review of experimental artifacts at promotion time (coordinated with SIG Security). +* Standards conformance enforcement on the durable surface (owned by SIG Standards). + +## Stakeholders + +* Authors of experimental agents, prompts, and skills. +* Receiving SIGs that accept graduating artifacts. +* Consumers of the experimental collection who use incubating artifacts with explicit awareness of breaking-change risk. + +## Cross-SIG Dependencies + +* **SIG Engineering** owns CI; SIG Emerging AI requests minimal validation for incubating artifacts and full validation gating on promotion. +* **SIG Standards** owns authoring conventions; SIG Emerging AI defers to Standards for the conformance review portion of promotion. +* **SIG Security** owns security review; SIG Emerging AI requests review at promotion and on demand for incubating artifacts that handle sensitive surfaces. +* **SIG RAI** consults on principle alignment for artifacts with RAI surface area. +* **SIG Data Science** receives notebook, Python data, and dataset-related graduating artifacts. + +## Roles and Responsibilities + +* **Chairs (1-3):** TBD (external recruit; per the Chair Recruitment Plan, no microsoft/hve-core maintainer may chair). Chairs run the incubation backlog, schedule review-window decisions, and represent the SIG in cross-SIG promotion negotiations. +* **Tech Leads (1-3):** TBD. Tech leads own the lifecycle documentation, the promotion criteria, and the handoff matrix; they mentor reviewers. +* **Reviewers:** TBD. Reviewers triage incoming proposals, validate incubating artifacts against minimal hygiene rules, and prepare promotion packages for receiving SIGs. +* **Members:** TBD. Members propose experiments, contribute PRs, and participate in discussions. + +## Subprojects and Owned Directories + +* `.github/agents/experimental/` +* `.github/skills/experimental/` +* `.github/prompts/experimental/` (where present) +* `collections/experimental.collection.*` + + + +## Membership and Onboarding + +Joining is open to any contributor in good standing under the [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Prospective members introduce themselves in the SIG: Emerging AI discussion category and indicate the area of focus (incubation triage, lifecycle docs, promotion review, or experimental authoring). Reviewer and approver privileges accrue through demonstrated contribution as described in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +New-contributor starting points: + +* Audit one entry in the experimental collection against the lifecycle definition and file an owner-and-window issue. +* Draft a promotion proposal for an artifact you believe is graduating-ready. +* Pair with a tech lead to review an incoming experimental proposal. + +## Cadence + +* **Async:** GitHub Discussions category SIG: Emerging AI for proposals, lifecycle decisions, and promotion negotiations. +* **Reviews:** PRs touching owned directories receive review acknowledgment within five business days. +* **Optional sync:** Frequency, time zone, and meeting link TBD by the inaugural chair on ratification; meetings are recorded or summarized publicly per the Public Activity rule. + +## Decision-Making + +* **Lazy consensus** on routine incubation and collection updates: 72-hour open window without objection. +* **Chair tie-break** when reviewers disagree within seven days. +* **Escalation** to the maintainer set for charter-affecting changes, lifecycle policy changes, or cross-SIG promotion conflicts. +* All deliberation occurs in public channels per the Public Activity rule in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Escalation Path + +1. Open a discussion in SIG: Emerging AI and tag chairs. +2. Chairs triage within five business days. +3. If unresolved, chairs file a decision request to the maintainer set per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Health and Success Metrics + +* Number of artifacts in each lifecycle stage (proposal, incubating, graduating, promoted, archived). +* Median time from proposal to promotion or archive. +* Promotion acceptance rate by receiving SIG. +* Quarterly review cadence completion. +* Annual archive and graduation report published. + +## Lifecycle and Review + +The SIG conducts an annual self-review on or before **Next Review** above. The review reaffirms scope, refreshes goals, updates membership, audits the experimental collection against the lifecycle definition, and either renews or proposes retirement. Retirement requires a maintainer vote per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md) and reassignment of all owned directories. + +## Amendment Process + +Charter amendments are proposed via pull request. Material changes (scope, lifecycle stages, promotion criteria, handoff matrix, role definitions, owned directories) require a 7-day comment window and chair approval; non-material changes follow lazy consensus. + +## Code of Conduct + +All participants follow the Microsoft Open Source [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers. diff --git a/docs/community/sigs/sig-engineering/CHARTER.md b/docs/community/sigs/sig-engineering/CHARTER.md new file mode 100644 index 000000000..4d337a259 --- /dev/null +++ b/docs/community/sigs/sig-engineering/CHARTER.md @@ -0,0 +1,160 @@ +--- +title: SIG Engineering +description: Charter for the engineering Special Interest Group in microsoft/hve-core +ms.topic: reference +ms.date: 2026-04-25 +author: HVE Core Maintainers +--- + +**Status:** Proposed +**Created:** 2026-04-25 +**Last Reviewed:** 2026-04-25 +**Next Review:** 2027-04-25 + +## Mission + +SIG Engineering owns the build, packaging, plugin generation, CI, and backlog/intake/triage tooling that turns microsoft/hve-core content into shippable artifacts. The SIG keeps day-to-day developer ergonomics healthy, ensures release pipelines are reproducible and auditable, and provides the integration surface every other SIG depends on for shipping their content. + +## Vision + +A repository where any contributor can validate, package, and release any artifact locally with a single `npm run` or `just` target, where CI gives a clear pass/fail signal in under fifteen minutes, and where the path from instruction file authored to plugin published is fully scripted and signed. + +## Goals (Current Cycle) + +1. Standardize the `npm run lint:*` and `validate:*` surface so every artifact category has a one-line validation command. +2. Reduce average green-CI time on pull requests through caching, matrix pruning, and selective regeneration. +3. Stabilize plugin generation outputs so collection edits produce deterministic diffs in `plugins/`. +4. Document the release pipeline end-to-end so a new maintainer can cut a release without tribal knowledge. +5. Land a backlog/intake/triage instruction surface that ADO, GitHub Issues, and Jira workflows share without duplication. + +## Deliverables + +Owned surfaces (durable artifacts under stewardship): + +* Build and packaging scripts under `scripts/` (non-security) and the extension packaging pipeline under `extension/`. +* GitHub Actions workflows under `.github/workflows/` and the installer collection (`collections/installer.collection.*`). +* Plugin generation pipeline (`npm run plugin:generate`, `plugin:validate`) and the resulting outputs under `plugins/`. +* Backlog, intake, and triage instructions under `.github/instructions/ado/`, `.github/instructions/github/`, and `.github/instructions/jira/`. +* Release engineering automation: `release-please` configuration, changelog generation, version consistency checks. +* Developer ergonomics: `package.json` script catalog, `justfile` targets, local validation tooling, devcontainer parity with the Copilot Coding Agent environment. + +Recurring artifact types produced by the SIG: + +* Feature requests and developer-experience RFCs for the build, CI, and release surfaces. +* CI and tooling gap analyses (e.g., missing validators, cache misses, flaky steps) filed as issues with remediation plans. +* Quarterly CI health and trend reports covering median PR duration, cache hit rate, runner cost, and flake rate. +* Refactor proposals for `scripts/`, `npm run` catalog consolidation, and `justfile` target reorganization. +* Performance benchmarks for plugin generation idempotency and end-to-end release pipeline runs. +* Per-release retrospectives summarizing scope, regressions, and follow-on work. +* Devcontainer and Copilot Coding Agent parity audits whenever either environment changes. +* Annual roadmap update aligned with maintainer planning. + +## In Scope + +* Build, packaging, and plugin generation pipelines under `scripts/` (excluding `scripts/security/` and security-relevant linters). +* CI workflows under `.github/workflows/`. +* Installer collection (`collections/installer.collection.*`). +* Backlog/intake/triage instruction surfaces (ADO, GitHub, Jira). +* `npm run` script catalog, `justfile` targets, local validation tooling. +* Release engineering, semantic versioning, and changelog automation. +* Devcontainer and Copilot Coding Agent setup steps (`copilot-setup-steps.yml`, `.devcontainer/`). + +## Out of Scope + +* Security-specific scripts and linters (owned by SIG Security). +* Coding standards content and prompt-builder authoring conventions (owned by SIG Standards). +* Experimental agents, skills, and prompts (owned by SIG Emerging AI). +* Responsible AI rubrics and review criteria (owned by SIG RAI). +* Data-science notebook and skill conventions (owned by SIG Data Science). + +## Stakeholders + +* Repository maintainers shipping releases. +* Contributors authoring agents, prompts, instructions, and skills who depend on validation tooling. +* Downstream consumers of the VS Code extension and plugin marketplace artifacts. +* Other SIGs that depend on Engineering for CI, packaging, and release plumbing. + +## Cross-SIG Dependencies + +* **SIG Standards** authors the rules; SIG Engineering enforces them in CI. +* **SIG Security** owns `scripts/security/` and security-relevant linters; SIG Engineering integrates their results into CI gates. +* **SIG Emerging AI** hands off promoted artifacts; SIG Engineering ensures the artifact is wired into the appropriate collection and release flow. +* **SIG RAI** and **SIG Data Science** consume Engineering's collection and release tooling and contribute requirements for new validation surfaces. + +## Roles and Responsibilities + +* **Chairs (1-3):** TBD (external recruit; per the Chair Recruitment Plan, no microsoft/hve-core maintainer may chair). Chairs set the agenda, run cadence, drive prioritization, represent the SIG to maintainers, and are accountable for charter health. +* **Tech Leads (1-3):** TBD. Tech leads own architectural direction for the build, CI, and release pipelines, perform PR review on subproject changes, and mentor contributors. +* **Members:** TBD. Members contribute PRs, review changes, triage issues, and participate in SIG discussions. + +## Subprojects and Owned Directories + +* `scripts/` (excluding `scripts/security/` and security-relevant linters under `scripts/linting/`) +* `extension/` +* `collections/installer.collection.*` +* `.github/workflows/` +* `.github/instructions/ado/` +* `.github/instructions/github/` +* `.github/instructions/jira/` +* `package.json`, `justfile`, `release-please-config.json`, `audit-ci.json`, `codecov.yml` + + + +## Membership and Onboarding + +Joining is open to any contributor in good standing under the [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Prospective members open a discussion in the SIG: Engineering category introducing themselves and the area they want to work on. Reviewer and approver privileges accrue through demonstrated contribution as described in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +New-contributor starting points: + +* Pick an issue labeled `good-first-issue` in a SIG Engineering subproject. +* Run the full `npm run lint:all` chain locally and report any environment friction. +* Review a recent PR touching `scripts/` or `.github/workflows/` and leave constructive feedback. + +## Cadence + +* **Async:** GitHub Discussions category SIG: Engineering for design proposals, decision logs, and open questions. +* **Issue triage:** Weekly review of open issues against the SIG's owned directories. +* **Optional sync:** Frequency, time zone, and meeting link TBD by the inaugural chair on ratification; meeting notes are posted publicly. + +## Decision-Making + +* **Lazy consensus** on routine work: a proposal stands if no objections are raised within 72 hours on an open PR or discussion thread. +* **Chair tie-break** when reviewers disagree and consensus is not reachable within seven days. +* **Escalation** to the maintainer set if a decision is contested across SIGs or affects governance. +* All deliberation occurs in public channels per the Public Activity rule in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Escalation Path + +1. Open a discussion in SIG: Engineering and tag chairs. +2. Chairs attempt resolution within seven days. +3. If unresolved, chairs file a decision request to the maintainer set per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Health and Success Metrics + +* Median CI duration on `main` branch PRs. +* Number of `npm run` scripts producing structured logs under `logs/`. +* Plugin generation idempotency rate (regeneration produces no diff). +* Open issue age distribution in owned directories. +* Backlog/intake instruction file freshness (no stale references in linked workflows). + +## Lifecycle and Review + +The SIG conducts an annual self-review on or before **Next Review** above. The review confirms scope, refreshes goals, updates membership, and either renews or proposes retirement. Retirement requires a maintainer vote per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md) and reassignment of all owned directories. + +## Amendment Process + +Charter amendments are proposed via pull request. Material changes (scope, role definitions, owned directories) require a 7-day comment window and chair approval; non-material changes (typos, link fixes) follow lazy consensus. + +## Code of Conduct + +All participants follow the Microsoft Open Source [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Concerns are reported per [SECURITY.md](https://github.com/microsoft/hve-core/blob/main/SECURITY.md) for security issues and to maintainers for conduct issues. + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers. diff --git a/docs/community/sigs/sig-rai/CHARTER.md b/docs/community/sigs/sig-rai/CHARTER.md new file mode 100644 index 000000000..f523171fe --- /dev/null +++ b/docs/community/sigs/sig-rai/CHARTER.md @@ -0,0 +1,153 @@ +--- +title: SIG RAI +description: Charter for the Responsible AI Special Interest Group in microsoft/hve-core +ms.topic: reference +ms.date: 2026-04-25 +author: HVE Core Maintainers +--- + +**Status:** Proposed +**Created:** 2026-04-25 +**Last Reviewed:** 2026-04-25 +**Next Review:** 2027-04-25 + +## Mission + +SIG RAI owns Responsible AI planning, review rubrics, and authoring guidance for microsoft/hve-core. The SIG ensures every AI-assisted artifact shipped from this repository (agents, prompts, skills, instructions, planning workflows) is evaluated against the project's RAI planning rubric and that the planning surfaces other SIGs depend on remain current, actionable, and auditable. + +## Vision + +A repository where Responsible AI is a first-class concern of every authoring workflow rather than an afterthought; where contributors have rubrics, examples, and review partners that make RAI evaluation straightforward; and where the planning content the wider HVE ecosystem consumes reflects the SIG's current rubric and review practice. + +## Goals (Current Cycle) + +1. Maintain the RAI planning instruction set under `.github/instructions/rai-planning/` and keep it current with the SIG's evolving rubric. +2. Publish a documented RAI review rubric and intake process that other SIGs can call against. +3. Coordinate with SIG Security on threat modeling for agentic and LLM surfaces (joint ownership of AI-specific threat content). +4. Maintain disclaimer language and shared planning content under `.github/instructions/shared/disclaimer-language.instructions.md`. +5. Establish a quarterly content audit cadence to surface stale rubrics and out-of-date principle mappings. + +## Principles Alignment + +Rubrics, templates, and reviews align to the principle set defined in the SIG's RAI planning rubric. Each rubric in the RAI planning instruction set traces explicitly back to one or more of those principles, and the principle set itself is maintained as a versioned artifact owned by this SIG. + +## Deliverables + +Owned surfaces (durable artifacts under stewardship): + +* RAI planning instructions under `.github/instructions/rai-planning/` (identity, capture coaching, risk classification, standards, security model, impact assessment, backlog handoff). +* Disclaimer language under `.github/instructions/shared/disclaimer-language.instructions.md`. +* RAI review rubric and intake documentation. +* Examples and templates illustrating principle-by-principle evaluation. + +Recurring artifact types produced by the SIG: + +* Feature requests and RAI RFCs for new rubric items, principle mappings, and disclaimer patterns. +* Impact assessments produced through the RAI planning workflow for in-scope artifacts. +* Gap analyses against the SIG's RAI planning rubric for owned and consulted surfaces. +* Evaluation-harness reports for AI-assisted artifacts undergoing RAI review. +* Dataset and persona audits commissioned in coordination with SIG Data Science. +* Harm-pattern advisories distilling recurring failure modes observed during reviews. +* Quarterly RAI content audit reports covering rubric currency, principle coverage, and contributor adoption. +* Quarterly RAI compliance digest summarizing reviews completed, principle coverage, and outstanding risks. +* Annual roll-up of RAI review trends and recommended rubric evolutions. + +## In Scope + +* Responsible AI planning instruction surfaces and prompts. +* Review rubrics, intake, and SLA for RAI review of new or changed artifacts. +* Coordination with SIG Security on AI-specific threat content. +* Coordination with SIG Standards on writing conventions for RAI content. +* Disclaimer language and consistent disclosure patterns across planning agents. + +## Out of Scope + +* General security review and supply-chain content (owned by SIG Security except where it intersects with AI-specific threats). +* Authoring style and Markdown conventions (owned by SIG Standards). +* Engineering tooling and CI (owned by SIG Engineering). +* Data-science-specific dataset and evaluation content (owned by SIG Data Science) except where principles cross over. + +## Stakeholders + +* Authors of agents, prompts, skills, and instructions that touch user-facing AI behavior. +* RAI reviewers within the SIG who execute reviews against the rubric. +* Other SIG chairs who request RAI reviews on their content. +* External consumers of the RAI planning surfaces who need confidence that the content reflects current practice. + +## Cross-SIG Dependencies + +* **SIG Security** jointly owns threat modeling for agentic and LLM systems; SIG RAI owns the principle-mapping, SIG Security owns the threat enumeration tooling. +* **SIG Standards** owns Markdown and writing conventions; SIG RAI defers to Standards on style and asserts authority on RAI technical content. +* **SIG Engineering** integrates RAI linters or validators into CI when SIG RAI publishes them. +* **SIG Emerging AI** consults SIG RAI on principle alignment before promoting experimental artifacts to durable surfaces. +* **SIG Data Science** consults SIG RAI on fairness and evaluation methodology for data-driven artifacts. + +## Roles and Responsibilities + +* **Chairs (1-3):** TBD (external recruit; per the Chair Recruitment Plan, no microsoft/hve-core maintainer may chair). Chairs prioritize the RAI backlog, run cadence, lead reviews of contentious cases, and represent the SIG in cross-SIG escalations. +* **Tech Leads (1-3):** TBD. Tech leads own architectural direction for the RAI planning instruction set, the review rubric, and disclaimer language; they perform PR review and mentor reviewers. +* **RAI Reviewers:** TBD. Reviewers conduct RAI reviews requested by other SIGs against the documented rubric and accrue privileges through demonstrated review quality. +* **Members:** TBD. Members contribute PRs, draft rubric updates, triage issues, and participate in discussions. + +## Subprojects and Owned Directories + +* `.github/instructions/rai-planning/` +* `.github/instructions/shared/disclaimer-language.instructions.md` +* RAI-relevant prompts and agents (paths cataloged on ratification) + + + +## Membership and Onboarding + +Joining is open to any contributor in good standing under the [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Prospective members introduce themselves in the SIG: RAI discussion category and indicate the area of focus (rubric authoring, review, principle mapping, or coordination). Reviewer and approver privileges accrue through demonstrated contribution as described in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +New-contributor starting points: + +* Read the RAI planning identity and risk classification instructions and file a single observation as an issue. +* Pair with a tech lead on a review of a recent PR to learn the rubric. +* Audit one rubric in the RAI planning instruction set against current SIG practice and propose updates. + +## Cadence + +* **Async:** GitHub Discussions category SIG: RAI for proposals, rubric updates, and review requests. +* **Review intake:** RAI-review requests are filed as issues with the `rai-review` label and routed to a reviewer within five business days. +* **Optional sync:** Frequency, time zone, and meeting link TBD by the inaugural chair on ratification; meetings are recorded or summarized publicly per the Public Activity rule. + +## Decision-Making + +* **Lazy consensus** on routine rubric and content updates: 72-hour open window without objection. +* **Chair tie-break** when reviewers disagree within seven days. +* **Escalation** to the maintainer set for charter-affecting changes or contested principle interpretations. +* All deliberation occurs in public channels per the Public Activity rule in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Escalation Path + +1. Open a discussion in SIG: RAI and tag chairs. +2. Chairs triage within five business days. +3. If unresolved, chairs file a decision request to the maintainer set per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Health and Success Metrics + +* Currency of RAI planning instructions versus the SIG's published rubric. +* Median age of open RAI-review requests. +* Number of artifacts reviewed per quarter and the principle-by-principle distribution. +* Quarterly content-audit completion rate. +* Number of contributors qualified as reviewers. + +## Lifecycle and Review + +The SIG conducts an annual self-review on or before **Next Review** above. The review reaffirms scope, refreshes goals, updates membership, and either renews or proposes retirement. Retirement requires a maintainer vote per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md) and reassignment of all owned directories. + +## Amendment Process + +Charter amendments are proposed via pull request. Material changes (scope, role definitions, owned directories) require a 7-day comment window and chair approval; non-material changes follow lazy consensus. + +## Code of Conduct + +All participants follow the Microsoft Open Source [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers. diff --git a/docs/community/sigs/sig-security/CHARTER.md b/docs/community/sigs/sig-security/CHARTER.md new file mode 100644 index 000000000..589ba90a7 --- /dev/null +++ b/docs/community/sigs/sig-security/CHARTER.md @@ -0,0 +1,161 @@ +--- +title: SIG Security +description: Charter for the security Special Interest Group in microsoft/hve-core +ms.topic: reference +ms.date: 2026-04-25 +author: HVE Core Maintainers +--- + +**Status:** Proposed +**Created:** 2026-04-25 +**Last Reviewed:** 2026-04-25 +**Next Review:** 2027-04-25 + +## Mission + +SIG Security owns end-to-end security posture for microsoft/hve-core: threat modeling, security review, OWASP and secure-by-design skill content, supply-chain hardening, dependency pinning, CI hardening, and scorecard projections. The SIG absorbs the prior sssc-ci scope and acts as the security review partner for every other SIG when their work touches sensitive surfaces. + +## Vision + +A repository whose every workflow is pinned, signed, and scanned; whose security guidance is current and discoverable; whose supply-chain posture is measurable against an adopted standard; and whose contributors can request and receive a clear security review on any artifact they ship. + +## Goals (Current Cycle) + +1. Bring all GitHub Actions workflows into compliance with dependency pinning and action version consistency policies. +2. Publish and maintain projected OpenSSF Scorecard ratings as a tracked health metric. +3. Refresh the OWASP skill set (Top 10, LLM, MCP, Agentic, CI/CD, Docker, Infrastructure) against the latest published versions. +4. Stand up a public security-review intake that other SIGs can call against on a known SLA. +5. Document the supply-chain story end-to-end: what is signed, by whom, with what tooling, and how a consumer verifies. + +## Deliverables + +Owned surfaces (durable artifacts under stewardship): + +* Security planning, threat modeling, and review instructions under `.github/instructions/security/`. +* Security skills (OWASP variants, secure-by-design, security reviewer formats) under `.github/skills/security/`. +* Security collection (`collections/security.collection.*`) curation and maintenance. +* Security-focused scripts under `scripts/security/` and security-relevant linters under `scripts/linting/` (dependency pinning, action version consistency, SHA staleness, copyright validation). +* Repository security policy (`SECURITY.md`) and disclosure process documentation. +* Supply-chain artifacts: SBOMs, signed releases, scorecard projections, signed plugin manifests. + +Recurring artifact types produced by the SIG: + +* Feature requests and security RFCs for hardening workflows, scripts, and review tooling. +* Threat models for new and changed agent, prompt, skill, and workflow surfaces. +* Security advisories coordinated through `SECURITY.md` and published post-embargo. +* Gap analyses against the Microsoft SDL, OpenSSF Scorecard, SLSA, and Best Practices Badge. +* SBOM coverage and signature-verification reports per release. +* Vulnerability triage notes and remediation plans for issues filed against owned surfaces. +* Secure-by-design checklists tailored to common artifact categories. +* Quarterly supply-chain trend reports covering pinning compliance, SHA staleness, and Scorecard score deltas. +* Annual repository security posture report summarizing audits, advisories, and outstanding risks. + +## In Scope + +* Threat modeling, security review, and security planning instruction surfaces. +* OWASP and secure-by-design skill content. +* Supply-chain hardening: dependency pinning, signed artifacts (cosign), Sigstore integration, SBOM generation, Best Practices Badge, OpenSSF Scorecard, SLSA alignment. +* CI hardening: workflow permissions, action version consistency, SHA pinning, secrets scanning configuration. +* Security-relevant linters: `Test-DependencyPinning`, `Test-ActionVersionConsistency`, `Test-ShaStaleness`, copyright header validation. +* Security policy and vulnerability disclosure process. + +## Out of Scope + +* General build and packaging scripts (owned by SIG Engineering). +* Coding standards and authoring conventions outside the security domain (owned by SIG Standards). +* Responsible AI planning content (owned by SIG RAI). +* Data-science-specific data handling guidance (owned by SIG Data Science) except where it intersects with security skills. + +## Stakeholders + +* Repository maintainers responsible for shipping signed, hardened releases. +* Authors of security-adjacent agents, prompts, and skills who need review. +* Downstream consumers verifying provenance and integrity of published artifacts. +* Other SIGs requesting security review on their work product. +* External security researchers reporting vulnerabilities through `SECURITY.md`. + +## Cross-SIG Dependencies + +* **SIG Engineering** integrates security linters and validators into CI; SIG Security supplies the rules and tooling. +* **SIG Standards** owns general authoring style; SIG Security defers to Standards on writing conventions and asserts authority on security technical content. +* **SIG RAI** coordinates with SIG Security on threats specific to AI systems; the two SIGs jointly own threat modeling for agentic surfaces. +* **SIG Emerging AI** requests security review at promotion time before experimental artifacts graduate to durable surfaces. +* **SIG Data Science** consults SIG Security on data-handling and dataset provenance concerns. + +## Roles and Responsibilities + +* **Chairs (1-3):** TBD (external recruit; per the Chair Recruitment Plan, no microsoft/hve-core maintainer may chair). Chairs prioritize the security backlog, run cadence, lead incident coordination, and represent the SIG in cross-SIG escalations. +* **Tech Leads (1-3):** TBD. Tech leads own architectural direction for threat models, the OWASP skill surface, supply-chain tooling, and security CI; they perform PR review on owned subprojects and mentor reviewers. +* **Security Reviewers:** TBD. Reviewers conduct security reviews requested by other SIGs against the documented rubric; they accrue privileges through demonstrated review quality. +* **Members:** TBD. Members contribute PRs, draft skill updates, triage issues, and participate in discussions. + +## Subprojects and Owned Directories + +* `.github/instructions/security/` +* `.github/skills/security/` +* `collections/security.collection.*` +* `scripts/security/` +* `scripts/linting/` (security-relevant linters only) +* `SECURITY.md` +* `audit-ci.json` (in coordination with SIG Engineering) + + + +## Membership and Onboarding + +Joining is open to any contributor in good standing under the [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Prospective members introduce themselves in the SIG: Security discussion category and indicate the security area they want to work on (threat modeling, OWASP skills, supply-chain, CI hardening, or review). Reviewer and approver privileges accrue through demonstrated contribution as described in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +New-contributor starting points: + +* Run `npm run lint:dependency-pinning` and address any flagged workflows. +* Review the most recent OWASP skill against the current published edition and file an update issue. +* Pair with a tech lead on a security review of a recent PR to learn the rubric. + +## Cadence + +* **Async:** GitHub Discussions category SIG: Security for design proposals, security advisories coordination, and review requests. +* **Review intake:** Security-review requests are filed as issues with the `security-review` label and routed to a reviewer within five business days. +* **Optional sync:** Frequency, time zone, and meeting link TBD by the inaugural chair on ratification; sensitive content is handled in private channels per disclosure policy and summarized publicly when safe. + +## Decision-Making + +* **Lazy consensus** on routine skill updates and non-sensitive guidance: 72-hour open window without objection. +* **Chair tie-break** when reviewers disagree within seven days. +* **Escalation** to the maintainer set for cross-SIG security policy changes or release-blocking findings. +* **Embargoed work:** Vulnerability response follows the disclosure policy in [SECURITY.md](https://github.com/microsoft/hve-core/blob/main/SECURITY.md); decisions on embargo timing are made by chairs in coordination with maintainers and surfaced publicly post-embargo. +* All non-embargoed deliberation occurs in public channels per the Public Activity rule in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Escalation Path + +1. Open a discussion in SIG: Security and tag chairs (use `SECURITY.md` channel for embargoed issues). +2. Chairs triage within five business days. +3. If unresolved or release-blocking, chairs file a decision request to the maintainer set per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Health and Success Metrics + +* OpenSSF Scorecard projected and actual ratings. +* Percentage of `.github/workflows/` files passing dependency pinning, action version consistency, and SHA staleness checks. +* Median age of open security-review requests. +* Currency of OWASP skill content versus latest published versions. +* Number of vulnerabilities resolved within disclosure SLA. + +## Lifecycle and Review + +The SIG conducts an annual self-review on or before **Next Review** above. The review reaffirms scope, refreshes goals, updates membership, and either renews or proposes retirement. Retirement requires a maintainer vote per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md) and reassignment of all owned directories. + +## Amendment Process + +Charter amendments are proposed via pull request. Material changes (scope, role definitions, owned directories) require a 7-day comment window and chair approval; non-material changes follow lazy consensus. + +## Code of Conduct + +All participants follow the Microsoft Open Source [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Vulnerability reports are handled per [SECURITY.md](https://github.com/microsoft/hve-core/blob/main/SECURITY.md); conduct concerns are reported to maintainers. + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers. diff --git a/docs/community/sigs/sig-standards/CHARTER.md b/docs/community/sigs/sig-standards/CHARTER.md new file mode 100644 index 000000000..10ee92dd5 --- /dev/null +++ b/docs/community/sigs/sig-standards/CHARTER.md @@ -0,0 +1,153 @@ +--- +title: SIG Standards +description: Charter for the standards Special Interest Group in microsoft/hve-core +ms.topic: reference +ms.date: 2026-04-25 +author: HVE Core Maintainers +--- + +**Status:** Proposed +**Created:** 2026-04-25 +**Last Reviewed:** 2026-04-25 +**Next Review:** 2027-04-25 + +## Mission + +SIG Standards is the guardian of authoring conventions for microsoft/hve-core. The SIG owns coding standards, prompt-builder standards, the agent/prompt/instruction information architecture, frontmatter schemas, and documentation style so that every artifact across the repository is coherent, discoverable, reviewable, and high quality. + +## Vision + +A repository where any contributor can author a new agent, prompt, instruction, or skill by following a single linked standard, where naming and information architecture are predictable across collections, and where reviewers can resolve style debates by pointing at a documented rule rather than personal preference. + +## Goals (Current Cycle) + +1. Complete coverage of `applyTo` patterns for every coding-standards instruction file so language-specific guidance is auto-applied during authoring. +2. Publish a prompt-builder reference that defines the canonical structure for `.agent.md`, `.prompt.md`, `.instructions.md`, and `SKILL.md` files. +3. Stabilize frontmatter schemas in `scripts/linting/schemas/` and document the schema-to-file mapping so contributors know which schema applies. +4. Land a writing-style guide that resolves the most common review comments (voice, tone, hedging, em-dash policy). +5. Refresh `docs/contributing/` and `docs/templates/` so a new contributor can start a custom agent or prompt from a working template. + +## Deliverables + +Owned surfaces (durable artifacts under stewardship): + +* Per-language coding standards under `.github/instructions/coding-standards/`. +* Core authoring instructions under `.github/instructions/hve-core/` (markdown, writing-style, prompt-builder, commit-message, pull-request). +* Frontmatter schemas under `scripts/linting/schemas/` and the `schema-mapping.json` registry. +* Contributor guides and templates under `docs/contributing/` and `docs/templates/`. +* Information architecture decisions for naming, categorization, collection layout, and skill structure. + +Recurring artifact types produced by the SIG: + +* Feature requests and writing-style RFCs covering voice, tone, hedging, and structural conventions. +* Information-architecture proposals for new artifact types, naming patterns, and directory layouts. +* Naming-convention and frontmatter-schema gap analyses across collections. +* Quarterly cross-plugin consistency audits flagging style, structural, and IA drift. +* Deprecation notices and migration guides for retired conventions, schemas, or templates. +* Glossary updates and template additions or revisions in `docs/templates/` and `docs/contributing/`. +* Style-debate decision logs published in the SIG: Standards discussion category. +* Annual standards drift report comparing on-disk content against the documented standard. + +## In Scope + +* Per-language coding standards (`.github/instructions/coding-standards/`). +* Core authoring instructions (`.github/instructions/hve-core/`). +* Contributor guides (`docs/contributing/`) and templates (`docs/templates/`). +* Frontmatter schemas and schema-to-file mapping. +* Information architecture for agents, prompts, instructions, skills, and collections (naming, categorization, directory layout). +* Style review of cross-cutting documentation (READMEs, announcements, role guides) for consistency with the writing-style instruction. + +## Out of Scope + +* Build and CI tooling that enforces standards (owned by SIG Engineering). +* Security-specific guidance and standards content (owned by SIG Security). +* Domain-specific content for RAI, Data Science, or Emerging AI surfaces. +* Per-collection curation (owned by the SIG that owns the collection). + +## Stakeholders + +* Authors of new agents, prompts, instructions, and skills. +* Reviewers who need a documented rule to cite during PR review. +* Other SIGs whose content must comply with repository-wide style and structural standards. +* Downstream consumers reading published documentation and plugin marketplace listings. + +## Cross-SIG Dependencies + +* **SIG Engineering** enforces standards via linting and validation; SIG Standards authors the rules and supplies schemas. +* **SIG Security** depends on Standards for cross-cutting style; Standards defers to Security on security-specific guidance. +* **SIG Emerging AI** uses Standards templates when promoting experimental artifacts to durable surfaces. +* **SIG RAI** and **SIG Data Science** consume Standards' authoring conventions and contribute domain-specific extensions. + +## Roles and Responsibilities + +* **Chairs (1-3):** TBD (external recruit; per the Chair Recruitment Plan, no microsoft/hve-core maintainer may chair). Chairs prioritize standards work, mediate style disputes, run cadence, and represent the SIG to maintainers. +* **Tech Leads (1-3):** TBD. Tech leads own architectural direction for the instruction surface, frontmatter schemas, and template library; perform PR review on standards changes; and mentor authors. +* **Members:** TBD. Members propose and review standards updates, draft templates, and triage style-related issues. + +## Subprojects and Owned Directories + +* `.github/instructions/coding-standards/` +* `.github/instructions/hve-core/` +* `docs/contributing/` +* `docs/templates/` +* `scripts/linting/schemas/` (schema definitions; SIG Engineering owns the validators that consume them) + + + +## Membership and Onboarding + +Joining is open to any contributor in good standing under the [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Prospective members introduce themselves in the SIG: Standards discussion category and indicate the standards area they want to work on (a language, the prompt-builder surface, IA, or templates). Reviewer and approver privileges accrue through demonstrated contribution as described in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +New-contributor starting points: + +* Pick an instruction file lacking an `applyTo` pattern and propose one. +* Review a recent PR adding a new agent or skill and confirm it follows the prompt-builder standard; file an issue if not. +* Convert a frequent review comment into a documented rule in the writing-style instruction. + +## Cadence + +* **Async:** GitHub Discussions category SIG: Standards for proposals, decision logs, and IA debates. +* **Style review:** Rolling review of PRs touching docs, instructions, prompts, agents, and skills for cross-cutting style adherence. +* **Optional sync:** Frequency, time zone, and meeting link TBD by the inaugural chair on ratification; meeting notes are posted publicly. + +## Decision-Making + +* **Lazy consensus** on routine clarifications and template additions: 72-hour open window without objection. +* **Chair tie-break** when reviewers disagree on a style or IA call within seven days. +* **Escalation** to the maintainer set for repository-wide breaking changes (e.g., directory restructures, schema migrations affecting every collection). +* All deliberation occurs in public channels per the Public Activity rule in [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Escalation Path + +1. Open a discussion in SIG: Standards and tag chairs. +2. Chairs attempt resolution within seven days, consulting affected SIGs as needed. +3. If unresolved, chairs file a decision request to the maintainer set per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md). + +## Health and Success Metrics + +* Coverage of `applyTo` patterns across instruction files (target: 100%). +* Frontmatter validation pass rate (target: 100% with `-WarningsAsErrors`). +* Time-to-decision on style debates raised in SIG: Standards discussions. +* Number of templates available in `docs/templates/` versus number of distinct artifact categories. +* Style consistency audit results across collections. + +## Lifecycle and Review + +The SIG conducts an annual self-review on or before **Next Review** above. The review reaffirms scope, refreshes goals, updates membership, and either renews or proposes retirement. Retirement requires a maintainer vote per [GOVERNANCE.md](https://github.com/microsoft/hve-core/blob/main/GOVERNANCE.md) and reassignment of all owned directories. + +## Amendment Process + +Charter amendments are proposed via pull request. Material changes (scope, role definitions, owned directories) require a 7-day comment window and chair approval; non-material changes follow lazy consensus. + +## Code of Conduct + +All participants follow the Microsoft Open Source [Code of Conduct](https://github.com/microsoft/hve-core/blob/main/CODE_OF_CONDUCT.md). Concerns are reported per [SECURITY.md](https://github.com/microsoft/hve-core/blob/main/SECURITY.md) for security issues and to maintainers for conduct issues. + +--- + +🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.