feat(governance): split technical authority into subproject committees

.github/ISSUE_TEMPLATE/committee_member_add.yml

@@ -0,0 +1,52 @@
+name: "Subproject Committee: Add Member"
+description: "Propose adding a member to a subproject maintainer committee"
+title: "[Committee Add]: <name> to <subproject>"
+labels: ["committee-membership"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        See [GOVERNANCE.md's Changes in subproject maintainer committee
+        membership section](https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#changes-in-subproject-maintainer-committee-membership)
+        for the full process. Once this issue has the nominee's details
+        below, run the vote for the target subproject using its own
+        profile in `.gitvote.yml` (simple majority, per person):
+
+        - Core: `/vote-core`
+        - Supply Chain: `/vote-supply-chain`
+        - Community, Docs & Ecosystem: `/vote-community-ecosystem`
+        - Extensibility: `/vote-extensibility`
+
+        Committees are self-selecting: Steering does not vote on an
+        addition. The exception is a committee that has fallen below its
+        three-member floor, which is too small to self-select: while
+        Steering is its caretaker, Steering decides additions instead, by
+        simple majority with `/vote` (see the section linked above).
+  - type: dropdown
+    id: subproject
+    attributes:
+      label: Subproject
+      options:
+        - Core
+        - Supply Chain
+        - Community, Docs & Ecosystem
+        - Extensibility
+    validations:
+      required: true
+  - type: input
+    id: nominee
+    attributes:
+      label: Nominee
+      description: GitHub handle of the person being proposed
+    validations:
+      required: true
+  - type: textarea
+    id: justification
+    attributes:
+      label: Justification
+      description: >
+        Which component(s) is the nominee an established Component Owner
+        of within this subproject? See CONTRIBUTOR_LADDER.md's Subproject
+        Maintainer section for eligibility.
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/committee_member_remove.yml

@@ -0,0 +1,67 @@
+name: "Subproject Committee: Remove Member"
+description: "Propose removing a member from a subproject maintainer committee"
+title: "[Committee Remove]: <name> from <subproject>"
+labels: ["committee-membership"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        See [GOVERNANCE.md's Changes in subproject maintainer committee
+        membership section](https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#changes-in-subproject-maintainer-committee-membership)
+        for the full process. Once this issue has the details below, run
+        the removal vote for the target subproject using its own
+        `-removal` profile in `.gitvote.yml` (⅔ majority, per person, of
+        the committee, with the member under review abstaining):
+
+        - Core: `/vote-core-removal`
+        - Supply Chain: `/vote-supply-chain-removal`
+        - Community, Docs & Ecosystem: `/vote-community-ecosystem-removal`
+        - Extensibility: `/vote-extensibility-removal`
+
+        The member under review stays in the electorate GitVote counts
+        against, so ask them to abstain rather than vote on their own
+        removal: the ⅔ bar is measured against the whole committee
+        either way. If the committee can't reach ⅔ without them, or can't
+        convene the vote at all, any other committee member requests
+        Steering's backstop on this same issue; Steering then decides by
+        simple majority using `.gitvote.yml`'s `default` profile, `/vote`
+        (see the section linked above).
+  - type: dropdown
+    id: subproject
+    attributes:
+      label: Subproject
+      options:
+        - Core
+        - Supply Chain
+        - Community, Docs & Ecosystem
+        - Extensibility
+    validations:
+      required: true
+  - type: input
+    id: member
+    attributes:
+      label: Member proposed for removal
+      description: GitHub handle
+    validations:
+      required: true
+  - type: dropdown
+    id: reason
+    attributes:
+      label: Reason
+      options:
+        - Inactivity
+        - Code of Conduct violation
+        - Out-of-remit / no longer meets requirements
+    validations:
+      required: true
+  - type: textarea
+    id: details
+    attributes:
+      label: Details
+      description: >
+        Explain the reason above. For inactivity, see
+        CONTRIBUTOR_LADDER.md's Inactivity section (6 months with no
+        contribution or communication, not counting a communicated
+        absence).
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/component-owner-proposal.yml

@@ -0,0 +1,110 @@
+name: "Propose a Component Owner"
+description: "Nominate a Contributor to become Component Owner of a repository"
+title: "[Component Owner Proposal]: <name>"
+labels: ["component-owner-proposal"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ## Component Owner proposal
+
+        This template is an org-wide default (defined in `cloudnative-pg/.github`),
+        but **the issue itself must be created in the repository the nominee is
+        being proposed for** -- if you opened "New issue" from that repository's
+        own page, you're already in the right place; don't move this to
+        `governance`, `.github`, or `cnpg-infra`. gitvote reads a repository's
+        own `.gitvote.yml`, so the vote this issue leads to only uses the right
+        voters (that repository's Component Owners) if the issue lives there.
+
+        Promotion process, thresholds, and who may propose: see
+        `CONTRIBUTOR_LADDER.md` in
+        [cloudnative-pg/governance](https://github.com/cloudnative-pg/governance).
+        That document arrives with the federated-model rewrite, which is
+        pending ratification; progress is tracked in
+        [cloudnative-pg/governance#67](https://github.com/cloudnative-pg/governance/issues/67).
+
+  - type: input
+    id: nominee
+    attributes:
+      label: Proposed Component Owner
+      description: GitHub handle of the person being nominated.
+      placeholder: "@handle"
+    validations:
+      required: true
+
+  - type: input
+    id: lfid
+    attributes:
+      label: Nominee's LFID profile
+      description: "Component Owner status requires a Linux Foundation ID (LFID) with the nominee's GitHub account linked to it -- this is what lets CNCF's own tooling map the GitHub handle above to an organization at all. Look it up, or register/link one, at https://openprofile.dev. Paste the profile URL."
+      placeholder: "e.g. https://openprofile.dev/profile/gabriele.bartolini"
+    validations:
+      required: true
+
+  - type: input
+    id: organization
+    attributes:
+      label: Nominee's organization (employer)
+      description: "Must match the LFID profile's own \"Current Organization\" field above, not just what you believe it to be. This is what org-balanced voting and the Steering seat cap actually count -- a profile with no employer set, or the wrong one, silently misstates an organization's real seat count. Use the literal word Independent (not blank, not N/A) if the nominee has no employer tied to their contribution."
+      placeholder: "e.g. EDB -- or literally: Independent"
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: eligibility
+    attributes:
+      label: Proposer eligibility
+      description: "Per CONTRIBUTOR_LADDER.md, a nomination comes from a member of the body that decides it: this repository's Component Owners, or, where fewer than three of them are named, its subproject's maintainer committee. If that isn't you, ask one of them to open this issue instead of opening it on their behalf, so the record shows who actually nominated. Nobody here can verify the LFID/organization fields above by API -- this is a self-attestation, same as the two below."
+      options:
+        - label: I am a Component Owner of this repository, or a member of its subproject's maintainer committee.
+          required: true
+        - label: I opened this issue inside the target repository itself (see note above), not in governance, .github, or cnpg-infra.
+          required: true
+        - label: I opened the LFID profile above myself and confirmed the nominee's GitHub account is linked to it, and its "Current Organization" field matches the organization given above (or Independent).
+          required: true
+
+  - type: textarea
+    id: justification
+    attributes:
+      label: Track record / justification
+      description: Why does this contributor merit Component Owner status on this repository? Reference specific contributions -- PRs authored or reviewed, issue triage, sustained involvement, etc.
+    validations:
+      required: true
+
+  - type: textarea
+    id: links
+    attributes:
+      label: Relevant links
+      description: PRs, issues, or discussions that support this nomination.
+    validations:
+      required: false
+
+  - type: markdown
+    attributes:
+      value: |
+        ## Next steps
+
+        1. Let this issue sit long enough for this repository's other Component
+           Owners to weigh in.
+        2. An existing Maintainer or Component Owner of this repository comments
+           `/vote-component-owner` to open voting: two-thirds majority of this
+           repository's Component Owners, one week, per this repository's own
+           `.gitvote.yml`. If this repository has fewer than three named
+           Component Owners (or none), the vote defaults to the subproject
+           maintainer committee instead -- see `CONTRIBUTOR_LADDER.md` in the
+           governance repository.
+        3. If the vote passes: open a PR against
+           [cloudnative-pg/cnpg-infra](https://github.com/cloudnative-pg/cnpg-infra)
+           adding the nominee to this repository's `owners:` list in
+           `repo-tiers.yaml`. Once merged, `scripts/sync-project-owner-teams.sh
+           <repository> --apply` (run by an admin, from their own machine --
+           see that repo's README) grants the actual GitHub access.
+           Automating this step from a passed vote is on the roadmap; for now
+           it's a manual follow-up.
+        4. The LFID and organization collected above have nowhere durable to
+           land yet: `.project`'s `maintainers.yaml` doesn't have fields for
+           either today (confirmed against the
+           [dot-project schema](https://github.com/cncf/automation/tree/main/utilities/dot-project)
+           -- it only lists GitHub handles). Until that's resolved, note the
+           organization in this issue and in the `cnpg-infra` PR from step 3,
+           so it's at least on the record somewhere.

.github/ISSUE_TEMPLATE/delegated_team_membership.yml

@@ -0,0 +1,58 @@
+name: "Delegated Team: Membership Change"
+description: "Propose adding or removing an Infrastructure Team or Security Response Team member"
+title: "[Team]: <add|remove> <name> to/from <team>"
+labels: ["team-membership"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Both teams below hold responsibilities the Steering Committee has
+        delegated rather than given away, so Steering decides their
+        membership: see [GOVERNANCE.md's Infrastructure
+        Administration](https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#infrastructure-administration)
+        and [Security Response
+        Team](https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#security-response-team)
+        sections for what each one does.
+
+        Once this issue has the details below, run the vote using
+        `.gitvote.yml`'s `default` profile, `/vote` (lazy consensus,
+        falling back to simple majority, per person, of the Steering
+        Committee).
+
+        A passed vote is not the end of it. Adding someone means putting
+        them in the roster table in `MAINTAINERS.md`, in the GitHub team
+        (`admins` for Infrastructure), and, for the Security Response
+        Team, on the intake address, in the private channel where
+        embargoed reports are discussed, and in `SECURITY-INSIGHTS.yml`.
+        Removing someone reverses each of those in the same pass.
+  - type: dropdown
+    id: team
+    attributes:
+      label: Team
+      options:
+        - Infrastructure Team
+        - Security Response Team
+    validations:
+      required: true
+  - type: dropdown
+    id: change
+    attributes:
+      label: Change
+      options:
+        - Add
+        - Remove
+    validations:
+      required: true
+  - type: input
+    id: member
+    attributes:
+      label: Member
+      description: GitHub handle
+    validations:
+      required: true
+  - type: textarea
+    id: reason
+    attributes:
+      label: Reason
+    validations:
+      required: true