From 68826fbe058a2cec5110f7946b644fe4093a706b Mon Sep 17 00:00:00 2001 From: Gilbert Sanchez Date: Tue, 21 Apr 2026 14:22:13 -0700 Subject: [PATCH] feat: add governance model and CoC placeholder MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Full governance doc covering roles (Steward, Council, Maintainer, Contributor), decision-making (72h silent-assent, council-gated list), maintainer lifecycle, succession, and repo lifecycle states. CODE_OF_CONDUCT.md is a placeholder — paste CC 3.0 text before publishing. --- .github/CODE_OF_CONDUCT.md | 205 +++++++++++++++++++++++++++++++++ .github/GOVERNANCE.md | 225 +++++++++++++++++++++++++++++++++++++ 2 files changed, 430 insertions(+) create mode 100644 .github/CODE_OF_CONDUCT.md create mode 100644 .github/GOVERNANCE.md diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..a4aeb02 --- /dev/null +++ b/.github/CODE_OF_CONDUCT.md @@ -0,0 +1,205 @@ +# PowerShellOrg Code of Conduct + +PowerShellOrg has adopted the Contributor Covenant version 3.0 as our Code of +Conduct. The full text follows, with PowerShellOrg-specific reporting and +enforcement details filled in. + +## Our Pledge + +We as members, contributors, leaders, and participants in the PowerShellOrg +community pledge to make participation in our community a harassment-free +experience for everyone, regardless of age, body size, visible or invisible +disability, ethnicity, sex characteristics, gender identity and expression, +level of experience, education, socio-economic status, nationality, personal +appearance, race, caste, color, religion, sexual identity and orientation, or +any other dimension of diversity. + +We pledge to act and interact in ways that contribute to an open, welcoming, +diverse, inclusive, and healthy community, focused on the shared goal of +building and maintaining open source PowerShell tooling. + +## Encouraged Behaviors + +We encourage all community members to: + +- Demonstrate empathy, kindness, and respect toward other people +- Be respectful of differing opinions, viewpoints, and experiences +- Give and gracefully accept constructive feedback +- Accept responsibility, apologize to those affected by our mistakes, and learn + from the experience +- Focus on what is best not just for us as individuals, but for the overall + community +- Use welcoming and inclusive language +- Help newcomers feel welcome and supported +- Credit others' contributions generously + +## Unacceptable Behaviors + +The following behaviors are considered violations of this Code of Conduct: + +- Harassment of any participant, in any form +- Discrimination, particularly against members of vulnerable or underrepresented + groups +- The use of sexualized language or imagery, and sexual attention or advances of + any kind +- Trolling, insulting or derogatory comments, and personal or political attacks +- Public or private harassment, including stalking, doxxing, or sustained + disruption of discussions +- Publishing others' private information, such as a physical or email address, + without their explicit permission +- Advocating for, or encouraging, any of the above behavior +- Other conduct which could reasonably be considered inappropriate in a + professional setting + +We recognize that even well-intentioned actions can cause harm. Impact matters +more than intent. When informed that our behavior has caused harm, the +appropriate response is to listen, take responsibility, apologize sincerely, and +change the behavior — not to defend the original intent. + +## Consent and Boundaries + +Community members must respect stated boundaries immediately. When a member asks +another to stop a behavior, end a line of conversation, or leave them alone, the +request must be honored without argument. + +Repeated boundary violations after a clear request to stop will be treated as +harassment. + +## Scope + +This Code of Conduct applies within all PowerShellOrg community spaces, +including: + +- All repositories within github.com/PowerShellOrg +- GitHub Discussions, Issues, and Pull Requests +- Any official PowerShellOrg communication channels (chat platforms, mailing + lists, video calls) +- Public events where someone is officially representing PowerShellOrg + +It also applies when an individual is officially representing the community in +public spaces. Examples of representing our community include using an official +email address, posting via an official social media account, or acting as an +appointed representative at an online or offline event. + +This Code of Conduct also applies to behavior outside these spaces when that +behavior has the potential to adversely affect the safety and well-being of +community members. + +## Reporting Concerns + +If you experience or witness behavior that violates this Code of Conduct, please +report it. You will not be retaliated against for making a good-faith report. + +**Primary contact:** + +**Alternate contact:** Direct message to the Steward via GitHub or Discord. + +When reporting, please include: + +- Your contact information (so we can follow up) +- Names (real or usernames) of any individuals involved, including witnesses +- A description of what happened, with as much specificity as possible +- The approximate date and time +- Links to any relevant public records (issues, pull requests, chat messages) +- Any additional context that would help us understand the situation +- Whether you believe the situation is ongoing + +Reports will be acknowledged within 72 hours. + +All reports will be handled with discretion. We will not share your identity +with the person you are reporting without your explicit consent, except where +required by law. + +## Addressing and Repairing Harm + +When a Code of Conduct violation is reported, the Steward (with input from the +Council where appropriate) will determine an appropriate response. Our goal is +to address harm, support those affected, and where possible find a path for the +person who caused harm to repair the relationship and reintegrate into the +community. + +The following is a guideline. The Steward retains discretion to apply responses +appropriate to the specific situation, including responses not listed here. + +### 1. Private Conversation + +**Community impact:** Use of inappropriate language, a single instance of +unprofessional behavior, or behavior that, while not severe, was unwelcome. + +**Response:** A private written communication from the Steward, providing +clarity around the nature of the violation and an explanation of why the +behavior was inappropriate. A public apology may be requested. + +### 2. Warning + +**Community impact:** A violation through a single incident or series of +actions, or a pattern of behavior that has caused harm to one or more community +members. + +**Response:** A written warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction with +those enforcing the Code of Conduct, for a specified period of time. This +includes avoiding interactions in community spaces as well as external channels +like social media. Violating these terms may lead to a temporary or permanent +ban. + +### 3. Temporary Ban + +**Community impact:** A serious violation of community standards, including +sustained inappropriate behavior or harassment of an individual. + +**Response:** A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No public or +private interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, is allowed during this period. +Violating these terms may lead to a permanent ban. + +### 4. Permanent Ban + +**Community impact:** Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of individuals. + +**Response:** A permanent ban from any sort of public interaction within the +community. + +## Restorative Paths + +Where appropriate, and at the discretion of the Steward and the affected +parties, we may offer paths for community members who have caused harm to repair +the relationship and re-engage with the community. This may include: + +- A private acknowledgment of the harm caused +- A public apology, when requested by those harmed +- A defined period of restricted participation +- A clear set of expectations for re-engagement + +Restorative paths are not available for severe violations, including but not +limited to harassment, doxxing, threats of violence, or sexual misconduct. + +## Appeals + +A person who has been subject to enforcement action may appeal the decision by +writing to the Steward within 30 days. The Steward will review the appeal with +input from the Council and respond within 30 days. + +If the appeal involves the Steward's own decision and the appellant believes the +Steward cannot review it impartially, they may request that the Council review +the appeal collectively. In that case, the Council reviews and decides by +majority, and the Steward does not vote. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 3.0, available at +. + +[homepage]: https://www.contributor-covenant.org + +For answers to common questions about this Code of Conduct, see the FAQ at +. Translations are available at +. + +--- + +*Last updated: 2026/04/21. Reports go to .* diff --git a/.github/GOVERNANCE.md b/.github/GOVERNANCE.md new file mode 100644 index 0000000..6217363 --- /dev/null +++ b/.github/GOVERNANCE.md @@ -0,0 +1,225 @@ +# PowerShellOrg Governance + +PowerShellOrg is a community-run GitHub organization that adopts and maintains +open source PowerShell tooling. This document describes how decisions get made, +how people join and leave, and how projects move through their lifecycle. + +The model is deliberately lightweight. We are a small volunteer community, not a +foundation. Speed and clarity matter more than process. + +## Roles + +### Steward + +One person. The Steward is the org's tiebreaker, external face, and +direction-setter. + +Responsibilities: + +- Holds the GitHub org admin role +- Owns the PowerShell Gallery account that issues per-repo scoped API keys +- Decides contested questions with input from the Council +- Represents PowerShellOrg externally +- Maintains the private API key tracking record + +The role is named ("Steward of PowerShellOrg") rather than tied to an individual +so that succession is possible without renaming the role. + +### Council + +Up to seven people. Active maintainers across the org's repositories. + +By default, one Council seat per actively-maintained repository. The Steward may +invite additional members for cross-cutting work (CI infrastructure, security +response, documentation). The Council's role is **input, not consensus** — they +raise issues, propose changes, review adoption requests, and surface concerns. +The Steward decides. + +Council members are expected to: + +- Be reachable on the Council channel +- Respond to adoption requests and governance proposals within the comment + window +- Flag concerns about other maintainers, repositories, or the direction of the + org + +### Maintainer + +Per-repository role. Has write access to a specific repository, can merge pull +requests, can cut releases. + +Maintainers are added per-repo, not org-wide. A maintainer on one repository has +no special standing on others. + +### Contributor + +Anyone with a merged pull request to any PowerShellOrg repository. No special +permissions; recognition only. + +## How decisions get made + +**Default: Steward decides with Council input.** Speed is the explicit priority. + +For non-urgent decisions, the Steward will normally: + +1. Post a "thinking about doing X" note in the Council channel +2. Wait 72 hours for input +3. Act + +Silence is assent. The Steward may act immediately for urgent matters and post +the rationale afterward. + +### Decisions that require Council input before action + +The Steward may not act unilaterally on these. Each requires a posted proposal +and a comment window before action. + +- Adopting a new tool into the org +- Adding or removing a maintainer +- Graduating a tool to the `stable` lifecycle state +- Archiving or deprecating a tool +- Changing this governance document +- Changing the Code of Conduct +- Changing the standard build stack + +Comment windows: + +- Adoption decisions: 7 to 30 days from the adoption request being filed +- Maintainer changes: 72 hours +- Graduation: 7 days +- Archival: 30 days +- Governance, Code of Conduct, or standard stack changes: 14 days + +### Decisions at maintainer discretion + +Within a repository, maintainers have full discretion over: + +- Routine pull request review and merge +- Releases (within the standard pipeline) +- Issue triage and labeling +- Day-to-day technical direction +- Repository-specific contributing guidelines that supplement the org-wide ones + +## How maintainers get added + +Three paths. + +**Sustained contribution.** Several merged pull requests and demonstrated +judgment over weeks to months. An existing maintainer nominates the contributor +in the Council channel; the Steward confirms within 72 hours. + +**Adoption.** When PowerShellOrg adopts a tool, the submitter is offered +maintainer status on that repository by default. This is part of the adoption +commitment. + +**Steward appointment.** For repositories with no active maintainer (typically +newly adopted or a maintainer departure), the Steward can directly appoint +someone willing to take it on. This is announced to the Council, not gated by +it. + +## How maintainers get removed + +Three paths. All preserve the contributor's commit history and credit. + +**Self-departure.** Anyone can step down at any time. We thank them, remove +access, archive their context, and move on. No questions asked. + +**Inactivity.** No commits, reviews, or Council participation for nine months +triggers a Steward check-in. No response within thirty days of that check-in +results in write access being removed. Access can be reinstated at any time on +request. + +**For cause.** Code of Conduct violation, security incident, or sustained +pattern of behavior that damages the project. This is a Steward decision after +Council input. We document the decision privately for the Council and +communicate it publicly only to the extent necessary. + +## Succession + +If the Steward steps down, the Council selects a new Steward by majority vote. +The outgoing Steward, if available, confirms the selection. + +If the Steward becomes unavailable without stepping down (extended +unresponsiveness, incapacity), the Council may proceed with selection after a +thirty-day attempt to reach them. The selection is documented publicly. + +To make this resilient: the Steward designates a backup with org admin access at +all times. The backup is not formally the Steward but has the technical access +to keep operations running during a transition. + +## Lifecycle states + +Every repository in the org is in one of four lifecycle states, tracked via a +topic tag on the repository. + +**`status-incoming`** — Just adopted, working through the revival playbook. +Time-bounded; should not exceed 90 days. + +**`status-active`** — Default working state. Modernized build, clean releases, +responsive maintainership. First-response targets apply (7 days for issues and +PRs). + +**`status-stable`** — Graduated. Mature, slow-changing tool that does not need +active feature development. Stays in the org with reduced stewardship cadence. +First-response target relaxes to 30 days. Security response time stays at the +SECURITY.md baseline regardless of state. + +**`status-archived`** — No longer maintained. Repository is read-only on GitHub. +PowerShell Gallery package is left in place (existing users would otherwise +break) with a deprecation note added to the package description. + +State transitions follow the criteria in the Revival Playbook (`incoming` to +`active`), the graduation criteria below, and the archival process below. + +### Graduation criteria + +Moving from `active` to `stable` requires all of the following to be true. + +- At least 12 months in `active` state with consistent maintenance +- At least 2 clean releases under PowerShellOrg +- Test coverage adequate to catch regressions (judgment, not a percentage) +- No critical open issues, no known unaddressed security issues +- At least 2 active maintainers (so the project is not a single point of + failure) +- Documentation reasonably complete + +The repository's maintainers propose graduation in the Council channel. After a +7-day comment window, the Steward decides. + +### Archival process + +A repository may be considered for archival when any of the following is true. + +- No commits, releases, or substantive issue activity for 24 months +- Superseded by a clearly better in-org or external tool +- No willing maintainer found after a 90-day open call +- The original problem space no longer exists + +The Steward proposes archival in the Council channel. After a 30-day comment +window, if no compelling objection is raised, the repository is archived: marked +read-only on GitHub, README updated to point at successors where applicable, +deprecation note added to the PowerShell Gallery package description, repository +topic tag updated to `status-archived`. + +## Scope + +PowerShellOrg adopts and maintains community PowerShell tooling — modules, build +tools, and developer utilities. + +Out of scope: + +- Microsoft-owned tooling or anything that would compete with active first-party + maintenance +- Single-vendor commercial tools +- Anything that would compete with an active upstream maintainer +- Anything we do not have the bandwidth to actually maintain + +## Changing this document + +Changes to this governance document follow the rules above: Council comment +window of 14 days, Steward decides. Material changes are announced on the org +profile and in a pinned discussion. + +--- + +*Last updated: 2026/04/21. Maintained by the Steward with input from the Council.*